A Digital Subscriber Line Access Multiplexer (DSLAM) is a network device that is capable of receiving upstream signals from multiple subscribers (e.g., Customer Premises Equipment or CPE) and aggregating these upstream signals onto backbone switching equipment such as a Broadband Remote Access Server (BRAS) of a Network Service Provider (NSP). In a typical CPE/DSLAM/BRAS layout, the communications between the CPE and DSLAM is ATM-based (e.g., Point-to-Point over asynchronous transfer mode or PPPoA) while the communications between the DSLAM and the BRAS is generally packet-based.
A number of standards are available which enable encapsulation of Local Area Network (LAN) and Wide Area Network (WAN) protocols over ATM (e.g., AAL5, AAL3, RBE, PPPoE/PPPoA, IPoA, IMA, and so on). Such standards provide different alternatives for integrating ATM communications into existing WAN and/or LAN communications.
Moreover, since packets can be quite large (e.g., 8,000 bytes in length) but ATM cells are fixed at 53 bytes in length (i.e., the first 5 bytes being header information and the remaining 48 bytes being reserved for data), the overhead cost of using ATM is relatively high. That is, relatively speaking, the 5-byte header is an excessive overhead cost and cuts into the amount of data that can be transferred between the CPE and the DSLAM. Along these lines, the term “ATM cell tax” is often used to describe the overhead cost imposed by ATM cells.
Nevertheless, providers typically offer Quality of Service (QoS) support to their subscribers, and thus intelligently apportion data within the fixed 48-byte data fields of ATM cells in a hands-on manner. One way to accomplish this hands-on apportionment is for the providers to manually configure BRAS equipment to control the downstream flow of network traffic with knowledge that packetized communications between the BRAS and the DSLAM will then face ATM encapsulation from the DSLAM to the CPE. In particular, technicians of the providers manually enter knowledge of the downstream protocols in use from the DSLAM to the CPE (e.g., PPPoA) and a conversion scheme which appropriately accounts for the ATM cell tax. Such operation involves the technicians entering such information through a command line interface (CLI) of the BRAS equipment.
For example, if the BRAS receives a 64-byte packet en route to the DSLAM and if the BRAS knows that the DSLAM will split the 64-byte packet into two 53-byte ATM cells, the BRAS can impose a level of flow control which is commensurate for two 53-byte ATM cells (i.e., 106 bytes in total). Accordingly, the BRAS may impose a scheme for shaping and policing the downstream flow which is more favorable to the DSLAM. As a result, the operation of the DSLAM can be improved (e.g., less dropped packets, enhanced ability to preserve packet priorities, etc.). It should be understood that different encapsulations will have different overhead and thus require different computations.
The foregoing and other objects, features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments of the invention.
Unfortunately, the above-described conventional approach, which involves technicians manually configuring BRAS equipment to account for a particular ATM encapsulation scheme, suffers from a variety of deficiencies. For example, it is extremely burdensome for technicians to manually configure the BRAS equipment through a CLI. That is, each configuration endeavor is labor intensive and susceptible to human error. Furthermore, such manual configuring may significantly slow down the process of adding new subscribers. Furthermore, whenever the encapsulation between the DSLAM and the subscriber (CPE) changes, the technicians of the providers need to manually update the knowledge of the changed encapsulation in the BRAS device.
In contrast to the above-described conventional approach to manually configuring BRAS equipment to account for a particular ATM encapsulation scheme, an improved technique involves automatically controlling operation of a BRAS device (i.e., a data communications device configured to perform BRAS operations) based on encapsulation information obtained from communications flowing through a DSLAM device (i.e., a data communications device configured to perform DSLAM operations) and the BRAS device. Such encapsulation information (e.g., the particular type or types of ATM encapsulation) is easily acquired by the BRAS device (e.g., from a exchange of Dynamic Host Configuration Protocol or DHCP messages between the CPE and a DHCP server passing through the DSLAM and BRAS devices) thus removing the burden of a technician having to configure the BRAS device manually. Accordingly, the time delays, human error risks and related burdens associated with a technician manually configuring the BRAS device are alleviated.
One embodiment is directed to a method of controlling operation of a BRAS device. The method includes extracting encapsulation information from a communications exchange between a CPE device and an external server device (e.g., a DHCP server). The communications exchange passes through the BRAS device and a DSLAM device. The method further includes storing the encapsulation information in local memory of the BRAS device, and controlling a flow of a downstream communication passing through the BRAS device and the DSLAM device toward the CPE device based on the encapsulation information stored in the local memory of the BRAS device. Accordingly, the BRAS device is well suited for performing ATM overhead accounting as well as shaping and policing downstream traffic.
Each subscriber 22 is customer premises equipment which is configured to acquire a network address 34 using DHCP. In particular, each subscriber 22 is configured to operate as a DHCP client that obtains and renews an IP network address from the DHCP server 28. To facilitate such operation, the DSLAM device 24 includes an enhanced DHCP relay agent 36(D), and the BRAS device 26 includes another enhanced DHCP relay agent 36(B). The DHCP relay agents 36(D), 36(B) (collectively, DHCP relay agents 36) are configured to relay DHCP messages 38 from the CPE upstream to the DHCP server 28. The DHCP relay agents 36 are further configured to relay DHCP messages 40 from the DHCP server 28 downstream to the CPE.
Moreover, the DHCP relay agent 36(D) is configured to receive upstream DHCP messages 38(0) and add a “Relay Agent Information” option (e.g., option code “82” information) thus generating DHCP messages 38(1). Similarly, the DHCP relay agent 36(B) are configured to receive upstream DHCP messages 38(1) and add a “Relay Agent Information” option thus generating DHCP messages 38(2). A description of DHCP options is provided in a publication entitled “RFC 2132—DHCP Options and BOOTP Vendor Extensions” by S. Alexander and R. Droms, dated March 1997, the teachings of which are hereby incorporated by reference in their entirety.
Along these lines and as will be explained in further details later, the DHCP relay agent 36(D) is configured to participate in the addition of encapsulation information within DHCP communications through the system 20, while the DHCP relay agent 36(B) is configured to automatically acquire the encapsulation information from the DHCP communications and then shape and police downstream traffic based on the acquired encapsulation information. In contrast to conventional approaches for ATM overhead accounting, such operation by the enhanced DHCP relay agents 36 occurs dynamically and without the need for any manual adjustment thus saving substantial set-up time and effort. At this point, it should be understood that a suitable network topology for the system 20 is that of WT-101 where the DSLAM device 24 operates as an access node and is configured to add DHCP relay agent information containing information on the port (e.g., DSL line) of the subscriber 22 requesting an IP network address 34.
To obtain an IP network address 34, the subscriber 22 outputs DHCP client messages 38 (e.g., DHCPDISCOVER, DHCPREQUEST, etc.) to the DHCP server 28. The DHCP server 28 responds to the DHCP client messages 38 from the subscriber 22 with DHCP server messages 40 (e.g., DHCPOFFER, DHCPACK, etc.). Some or all of these DHCP messages 38, 40 between the subscriber 22 and the DHCP server 28 (collectively, DHCP signals 42) may be forwarded and embellished by the DHCP relay agents 36(D), 36(B) (collectively, relay agents 36). In this manner, IP addresses are robustly and reliably assigned and managed within the system 20. A suitable technique for exchanging DHCP information which involves multiple DHCP relay agents is described in U.S. patent application Ser. No. 11/495,273, entitled “TECHNIQUES FOR EXCHANGING DHCP INFORMATION AMONG DHCP RELAY AGENTS AND DHCP SERVERS”, the entire teachings of which are hereby incorporated by reference.
Once the subscribers 22 have obtained network addresses from the DHCP server 28, the subscribers 22 are then well-equipped to exchange signals 44 with a variety of external devices (e.g., the device 30). For example, the subscribers 22 can then operate as subscriber edge devices that obtain web content from various web servers over the Internet.
It should be understood that, within the flow of the DHCP signals 42 is encapsulation information which identifies the type of ATM encapsulation carried out for communications 46 between the subscribers 22 and the DSLAM device 24 (i.e., the particular protocols utilized in communications flowing through the final leg extending between the DSLAM device 24 and CPE). The BRAS device 26 is configured to (i) automatically obtain such information from the DHCP signals 42 and then (ii) control the manner in which communications 48 flow between the BRAS device 26 and the DSLAM device 24 based on that information (i.e., the communications leg between the BRAS device 26 and the DSLAM device 24). In particular, the BRAS device 26 is configured to determine the particular ATM cell tax incurred due to ATM encapsulation for the edge communications 46 and thus throttle the edge communications 46 in the downstream direction to preserve QoS to the subscribers 22. Such ATM overhead accounting enhances subscriber QoS (e.g., provides less dropped packets, enhances the ability of the system 20 to preserve packet priorities, etc.) but without the burden of forcing technicians to manually configure a BRAS as in conventional approaches.
For example, based on the encapsulation information automatically gathered by monitoring the DHCP signals 42, suppose that the BRAS device 26 determines that the type of ATM encapsulation employed between the subscribers 22 and the DSLAM device 24 results in 53-byte ATM cell transmissions with 5-byte headers. That is, the DSLAM device 24 will split a 64-byte packet from the BRAS device 26 into two 53-byte ATM cells. Armed with this knowledge, the BRAS device 26 is capable of controlling the rate of data flowing in the downstream direction to the CPE (e.g., throttling packets, dropping lower priority packets, combining or dividing packets, classifying and queuing packets, etc.) so that the subscribers 22 properly receive their prescribed QoS. Further details will now be provided with reference to
In some arrangements, the DSLAM module 64 and the DHCP relay agent module 66 operate on separate designated circuits within the DSLAM device 24. In other arrangements, the DSLAM module 64 and the DHCP relay agent module 66 run on the same circuitry (e.g., as different processes or threads on the same set of processors). In all of these arrangements, the DSLAM module 64 and the DHCP relay agent module 66 are configured to communicate with each other (e.g., via one or more internal communications buses, via one or more inter-process communications schemes, via operating system and/or application programming interfaces, combinations thereof, etc.).
In the manner of traditional DHCP relay agents, the DHCP relay agent module 66 conveys the DHCP messages 42 between the subscribers 22 and the DHCP server 28 (also see
It should be understood that the DSLAM module 64 is configured to continue to provide the encapsulation information within subsequent DHCP messages from the same subscribers 22 (i.e., DHCP clients) during IP address renewal operations. That is, when the subscribers 22 send new DHCP messages 36 to the DHCP server 28 to renew their network addresses, the DSLAM module 64 adds the encapsulation information for these clients to the DHCP messages 36 to continuously inform the BRAS device 26 of the type of ATM encapsulation carried out on behalf of the subscribers 22. Further details will now be provided with reference to
In some arrangements, the BRAS module 84 and the DHCP relay agent module 86 operate on separate designated circuits within the BRAS device 26. In other arrangements, the BRAS module 84 and the DHCP relay agent module 86 run on the same circuitry (e.g., as different processes or threads on the same set of processors). In all arrangements, the BRAS module 84 and the DHCP relay agent module 86 are configured to communicate with each other (e.g., via one or more internal communications buses, via one or more inter-process communications schemes, via operating system and/or application programming interfaces, combinations thereof, etc.).
As further shown in
In some arrangements, the encapsulation information is stored in the memory 94 as an entry of a database 96 of multiple entries 98. In these arrangements, each entry 98 corresponds to a particular subscriber 22 and the particular form of ATM overhead accounting carried out for that subscriber 22.
Furthermore, in some arrangements, the memory 94 and the database 96 resides within and is managed by the BRAS module 84 rather than the DHCP relay agent module 86. In these arrangements, the DHCP relay agent module 86 simply conveys the encapsulation information to the BRAS module 84 as part of its communications 88, 90 (see
It should be understood that the DHCP relay agent module 86 is configured to continue to provide the encapsulation information from subsequent DHCP communications 42 to the BRAS module 84 during IP address renewal operations. That is, when the subscribers 22 send new DHCP messages 38 to the DHCP server 28 to renew their network addresses, the DSLAM device 24 (
At this point, it should be understood that there are different operating modes in which the DHCP relay agent module 86 is capable of obtaining the encapsulation information from the DHCP messages 42. In one operating mode, the DHCP relay agent module 86 is configured to snoop the encapsulation information from upstream DHCP messages 38 from the DSLAM device 24 en route to the DHCP server 28. In another operating mode, the DHCP relay agent module 86 is configured obtain the encapsulation information from the DHCP server 28 within downstream DHCP response messages 40 from the DHCP server 28. Further details of these two different operating modes will now be provided with reference to
In step 104, the DHCP relay agent module 86 stores the encapsulation information in the memory 94. In some arrangements, the DHCP relay agent module 86 stores the encapsulation information as a database entry 98 associated with the particular subscriber 22 (see the database 96 in
In step 106, the BRAS module 84 of the BRAS device 26 then controls the flow of a downstream communication passing through the BRAS device 26 and the DSLAM device 24 toward the subscriber 22 based on the encapsulation information stored in the memory 94. For example, the BRAS module 84 is capable of throttling downstream traffic from other devices (see the device 30 in
In step 122, the network interface 82 of the BRAS device 26 receives a DHCP message 40 en route from the DHCP server 28 back to a particular subscriber 22 in response to an earlier DHCP request message 38. In particular, the subscriber 22 sent that DHCP request message 38 upstream to obtain an assigned network address 34 from the DHCP server 28. As that DHCP request message 38 traveled upstream through the DSLAM device 24, the DSLAM device 24 added encapsulation information as Option 82 information to the DHCP request message 38. The DHCP server 28 then generated the DHCP response message 40 and provided further encapsulation information within the DHCP response message 40 (e.g., as Option 82 information) to direct the BRAS device 26. Accordingly, the DHCP relay agent module 86 of the BRAS device 26 then extracts the encapsulation information from DHCP messages 40.
In step 124, the DHCP relay agent module 86 stores the encapsulation information in the memory 94 in a manner similar to that described above in connection with
In step 126, the BRAS module 84 of the BRAS device 26 then controls the flow of a downstream communication passing through the BRAS device 26 and the DSLAM device 24 toward the subscriber 22 based on the encapsulation information stored in the memory 94. For instance, once the subscriber 22 is operational and begins acquiring content from other devices 30 through the network 32, the BRAS module 84 is capable of throttling packets, dropping lower priority packets, combining or dividing packets, classifying and queuing packets, and so on so that the subscribers 22 properly receive their prescribed QoS. As a result, the BRAS device 26 robustly and reliably shapes and polices traffic to maintain QoS for the subscriber 22.
In the return direction, the DHCP server 28 replaces the DHCP relay agent information of the BRAS device 26 with direction as to how to perform ATM overhead accounting for downstream traffic, i.e., represented in
As described above, embodiments of the invention are directed to techniques for automatically controlling operation of a BRAS device 26 based on encapsulation information (e.g., an identifier of the type or types of encapsulation) obtained from communications flowing through a DSLAM device 24 and the BRAS device 26. Such encapsulation information is easily acquired (e.g., through monitoring of DHCP messages 42) thus removing the burden of configuring the BRAS device 26 manually (e.g., by a technician) in order to account for encapsulation overhead.
While various embodiments of the invention have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
5922049 | Radia et al. | Jul 1999 | A |
5987011 | Toh | Nov 1999 | A |
6289377 | Lalwaney et al. | Sep 2001 | B1 |
6542491 | Tari et al. | Apr 2003 | B1 |
6633563 | Lin et al. | Oct 2003 | B1 |
6640278 | Nolan et al. | Oct 2003 | B1 |
6748439 | Monachello et al. | Jun 2004 | B1 |
6751218 | Hagirahim et al. | Jun 2004 | B1 |
6751670 | Patterson | Jun 2004 | B1 |
6876667 | Synnestvedt et al. | Apr 2005 | B1 |
6903755 | Pugaczewski et al. | Jun 2005 | B1 |
6957276 | Bahl | Oct 2005 | B1 |
6993048 | Ah Sue | Jan 2006 | B1 |
7039035 | Droms et al. | May 2006 | B2 |
7051089 | Johnson et al. | May 2006 | B1 |
7131141 | Blewett et al. | Oct 2006 | B1 |
7139818 | Kinnear, Jr. et al. | Nov 2006 | B1 |
7143435 | Droms et al. | Nov 2006 | B1 |
7152117 | Stapp | Dec 2006 | B1 |
7167920 | Traversat et al. | Jan 2007 | B2 |
7254134 | Lin et al. | Aug 2007 | B2 |
20010043616 | Hild et al. | Nov 2001 | A1 |
20020059429 | Carpenter et al. | May 2002 | A1 |
20020162029 | Allen et al. | Oct 2002 | A1 |
20030005112 | Krautkremer | Jan 2003 | A1 |
20030058874 | Sahaya et al. | Mar 2003 | A1 |
20030120818 | Ho | Jun 2003 | A1 |
20030165121 | Leung et al. | Sep 2003 | A1 |
20040022258 | Tsukada et al. | Feb 2004 | A1 |
20040073600 | Elo et al. | Apr 2004 | A1 |
20040105444 | Korotin et al. | Jun 2004 | A1 |
20040113908 | Galanes et al. | Jun 2004 | A1 |
20040136394 | Onno et al. | Jul 2004 | A1 |
20040165592 | Chen et al. | Aug 2004 | A1 |
20040213234 | Koch et al. | Oct 2004 | A1 |
20040229627 | Malladi et al. | Nov 2004 | A1 |
20050044265 | Vinel et al. | Feb 2005 | A1 |
20050220099 | Igarashi | Oct 2005 | A1 |
20050232228 | Dharanikota et al. | Oct 2005 | A1 |
20050252957 | Howarth et al. | Nov 2005 | A1 |
20050252970 | Howarth et al. | Nov 2005 | A1 |
20050253717 | Howarth et al. | Nov 2005 | A1 |
20050253718 | Droms et al. | Nov 2005 | A1 |
20050253722 | Droms et al. | Nov 2005 | A1 |
20050264420 | Vogel et al. | Dec 2005 | A1 |
20050271049 | Jain et al. | Dec 2005 | A1 |
20060028982 | Wright | Feb 2006 | A1 |
20060239273 | Buckman et al. | Oct 2006 | A1 |
20070081523 | Mishra | Apr 2007 | A1 |
20070180120 | Bainbridge et al. | Aug 2007 | A1 |
20080195700 | Jonsson | Aug 2008 | A1 |
20080212598 | Kolli et al. | Sep 2008 | A1 |
20090129386 | Rune | May 2009 | A1 |
20090141717 | Cabeca et al. | Jun 2009 | A1 |
20090190584 | Gemmer et al. | Jul 2009 | A1 |
Number | Date | Country |
---|---|---|
1 494 391 | Jan 2005 | EP |
0219656 | Mar 2002 | WO |
Number | Date | Country | |
---|---|---|---|
20080109559 A1 | May 2008 | US |