Patent Application
20090154478
The present invention relates to an access node (e.g., Digital Subscriber Line Access Multiplexer) and method for proactively monitoring the connectivity of one or more end devices (e.g., residential gateways).
The following abbreviations are herewith defined, at least some of which are referred to in the following description associated with the prior art and the present invention.
LT Line Termination (customer-side of a DSLAM)
NT Network Termination (network-side of a DSLAM)
Referring to
In this broadband access network 100, a provider wants to know if anyone of the RGWs 112 is unreachable before one of the customers 114 calls in with a complaint. Thus, the BNG 104 proactively monitors the connectivity to all of the RGWs 112 so that disconnection problems can be detected before the provider receives a call from a customer 114. This proactive connectivity monitoring is achieved through the use of continuity check (CC) messages which are defined in the IEEE 802.1ag standard entitled “Virtual Bridged Local Area Networks-Amendment 5: Connectivity Fault Management” Feb. 8, 2007 (the contents of which are incorporated by reference herein). Basically, the BNG 104 proactively monitors the connectivity to each of the RGWs 112 by having CC messages 126 flowing on a MA 128 between each of the RGWs 112 and the BNG 104. However, in many applications like the IPTV application there can be a few thousand RGWs 112 connected to a single BNG 104. Thus, the BNG 104 has to process and store the corresponding state information for each of the CC messages 126 that are received from all of the RGWs 112. This scheme causes memory and processing scalability problems at the BNG 104. Accordingly, there has been a need and still is a need for addressing this shortcoming and other shortcomings which are associated with the traditional access network 100. This need and other needs are satisfied by the present invention.
In one aspect, the present invention provides a method that could be implemented by an access node (e.g., DSLAM, ONT) to proactively monitor the connectivity of a plurality of end devices (e.g., RGWs, CPEs). The method comprises the steps of: (a) receiving continuity check messages from at least one of the plurality of end devices; (b) polling the received continuity check messages to ascertain the connectivity of each end device; and (c) if at least one continuity check message is detected as missing from one of the end devices during the polling step, then sending an alarm message indicating a loss of connectivity to the one end device. Thereafter, an edge router (e.g., BNG) would receive the alarm message and know there is no longer a connection to the one end device.
In another aspect, the present invention provides an access node (e.g., DSLAM, ONT) with a processor that retrieves instructions from a memory and processes those instructions to enable an interworking function to perform the following operations: (a) receive continuity check messages from at least one of the plurality of end devices (e.g., RGWs, CPEs); (b) poll the received continuity check messages to ascertain the connectivity of each end device; and (c) if at least one continuity check message is detected as missing from one of the end devices during the polling step, then sending an alarm message indicating a loss of connectivity to the one end device. Thereafter, an edge router (e.g., BNG) would receive the alarm message and know there is no longer a connection to the one end device.
In yet another aspect, the present invention provides a method for proactively monitoring the connectivity of a plurality of end devices within an access system which also includes an edge router and an access node. The method comprising the steps of: (a) receiving continuity check messages at the access node, where the continuity check messages are sent from at least one of the plurality of end devices; (b) polling the received continuity check messages at the access node to ascertain the connectivity of each end device; and (c) if at least one continuity check message is detected as missing from one of the end devices during the polling step, then sending an alarm message from the access node to the edge router, where the alarm message indicates a loss of connectivity to the one end device.
Additional aspects of the invention will be set forth, in part, in the detailed description, figures and any claims which follow, and in part will be derived from the detailed description, or can be learned by practice of the invention. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as disclosed.
A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
Referring to
Each DSLAM 310 is shown to have a processor 320 that retrieves instructions from a memory 322 and processes those instructions to enable an interworking function 324 to implement a proactive connectivity monitoring method 350 (see flowchart in
Referring to
1. The RGWs 312 send periodic CC messages 326 over an access link MA 602 to their corresponding bridge-on-network-interface cards 313 in the DSLAMs 310. The CC message 326 is described in the IEEE 802.1 ag/D8 standard entitled “Virtual Bridged Local Area Networks-Amendment 5: Connectivity Fault Management” Feb. 8, 2007 (the contents of which are hereby incorporated by reference herein).
2. Each bridge-on-network-interface card 313 polls the received CC messages 326 to ensure the reception of at least one CC message 326 from all of the corresponding RGWs 312 (see steps 502 and 504). In one embodiment, the polling is achieved by the IWF 324 that polls the respective access link MA 602 between the corresponding bridge-on-network-interface card 313 and each of the corresponding RGWs 312. How the IWF 324 performs the polling operation is application specific and would depend on the total number of corresponding RGWs 312. In one case, the IWF 324 may have a polling rate=1/n (rate of CC messages 326 coming in) where n=number of user facing ports 315b.
3. If the required number of CC messages 326 from each of the corresponding RGWs 312 are received at the bridge-on-network-interface card 313, then the IWF 324 will do nothing and will not send any alarm message 328 to the BNG 304.
4. If the required CC messages 326 from any of the corresponding RGWs 312 are not received at the bridge-on-network-interface card 313, then the IWF 324 will send an alarm message 328 on an intra carrier MA 604 to the BNG 304 (see step 506)(note: the DSLAM 310 will not expect a response back from the BNG 304). In this example, assume the IWF 324 sends the alarm message 328 after three consecutive CC messages 326 fail to be received from the corresponding RGW 312′. The alarm message 328 identifies the particular RGW 312′ that failed to send the required number of CC messages 326. If there are multiple non-connected RGWs 312′, then the IWF 324 would send multiple alarm signals 328 to the BNG 304. Typically, the alarm message 328 would contain the MAC address or the RGW port ID 315b′ that is associated with the non-connected RGW 312′. If desired, the alarm message 328 could be an Ethernet AIS (which would identify the MAC address of the non-connected RGW 312′), an ANCP/L2CP message (which would identify the MAC address of the non-connected RGW 312′) or a SNMP trap (which would identify the RGW port ID 315b′ of the non-connected RGW 312′).
5. The BNG 304 upon receiving the alarm message 328 knows that connectivity was lost to the identified non-connected RGW 312′. As can be seen, this method 350 enables scalability processing because the bridge-on-network-interface cards 313 send an alarm message 328 to the BNG 304 only when there happens to be a non-connected RGW 312′. Plus, the bridge-on-network-interface cards 313 send an alarm message 328 as soon as they detect the loss of a certain number of CC message(s) 326 from anyone of their corresponding RGWs 312. Thus, there is no need for the BNG 304 to continuously monitor the loss of CC messages 326 for each of their corresponding RGWs 312 as was required in the prior art.
Note 1: If desired the IWF 324 and the proactive connectivity monitoring method 350 can be implemented in the bridge-on-line card 315 instead of the bridge-on-network-interface card 313. This alternate location of the IWF 324 may be used if one wanted to help alleviate the processing on the bridge-on-network-interface card 313.
Note 2: The present invention can be implemented as well in an access network that is based on a PON model in which case the DSLAM 310 would be replaced by both an OLT and an ONT. Typically, the OLT-ONT can be used in a FTTU architecture while the DSLAM would be used in a FTTN architecture.
From the foregoing, it can be seen that each DSLAM 310 effectively acts as a proxy to collect CC messages 326 received from their corresponding RGWs 312 and sends an alarm message 328 to the BNG 304 only when there is a loss of connectivity detected with any of their corresponding RGWs 312. Thus, there is a local termination of Ethernet CC messages 32 at the DSLAMs 310, combined with some protocol that indicates loss of connectivity to the BNG 304 such as an Ethernet AIS message 328, an ANCP/L2CP message 328, or a SNMP trap 328. This is a marked-improvement over the prior art in which all of the RGWs 312 would have had to send periodic CC messages 326 directly to the BNG 304 so that the BNG 304 could proactively monitor the connectivity to the corresponding RGWs 312. There are several other advantages associated with the present invention some of which are listed below:
1. The present invention described here applies not only to IPTV architectures but to other similar architectures.
2. The IWF 324 need not be standardized since it is implemented internal to the access node 310.
3. The connectivity monitoring method 350 is scalable, proactive, and relatively simple to implement in current access nodes 301.
4. The BNG 304 is aware of the loss of RGW 312 connectivity without the need to store state information nor the need to perform processing for each RGW 312. This significantly reduces memory and processing requirements on the BNG 304.
5. There is no need to change the IEEE CFM standard behaviors to implement the proactive connectivity monitoring method 350. However, there may be a need to standardize the message format between the access node 310 and the edge router 304 to enable the exchange of the alarm message 328. However, the Ethernet AIS message, an ANCP/L2CP message, or a SNMP trap are excellent candidates for the alarm message 328 because they provide the required semantics including the message type and the header plus the message layout has already been defined.
Although one embodiment of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiment, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.
