|Publication number||US7599295 B2|
|Application number||US 11/532,951|
|Publication date||Oct 6, 2009|
|Filing date||Sep 19, 2006|
|Priority date||Sep 20, 2005|
|Also published as||CN101268663A, CN101268663B, US20070064674, WO2007033592A1|
|Publication number||11532951, 532951, US 7599295 B2, US 7599295B2, US-B2-7599295, US7599295 B2, US7599295B2|
|Inventors||Linda Dunbar, Robert Sultan|
|Original Assignee||Futurewei Technologies, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (7), Non-Patent Citations (2), Referenced by (5), Classifications (6), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention generally relates to packet based networks, and more specifically, relates to passive alarm propagation and suppression in packet based networks.
An Alarm Indication Signal (AIS) is a signal transmitted in lieu of a normal signal to maintain transmission continuity, and indicate to a receiving terminal that there is a fault located somewhere along the transmission path, which could be source node, intermediate nodes, or any links along the path. An AIS has been used by Transport networks to indicate upstream alarms. When downstream nodes receive alarms from their upstream nodes, they can suppress secondary alarms which are caused by the upstream faults.
AIS alarm propagation has been used in conventional transport networks for a long time. However, such approaches are not effective in a packet based network for propagating faults, especially in a connection-less oriented packet network, where each node can be connected to its peers via multiple connections. Such propagation used by circuit networks can flood a packet network if there are many upstream faults.
IEEE802.1ag/D4.1 has proposed another form of AIS for provider edge nodes. This form multicasts an AIS signal to an entire administration domain, so that bridges can suppress alarms of losing its connectivity to their peers. However, there are issues with the proposed methods. IEEE802.1ag/D4.1 provides two possible ways to send AIS to affected nodes. A first method is to let a provider edge node send periodic AIS message to all the nodes in an administration domain. This method can introduce too many messages, flooding an administrative domain. The excessive messages can cause congestion and unnecessary traffic within the administration domain. A second method only sends one AIS message when a provider edge detects failure. Subsequently, an AIS “clear” message is sent when the provider node recovers from connectivity failure. In this case, even though the number of AIS messages in the administrative domain may be reduced, the AIS “clear” message may not be sent to newly added bridges when the provider node recovers from its connectivity failure, or nodes being created after the failure occur may not get a failure message.
Therefore, there is a need for a system that effectively enables fault propagation and achieve alarm suppression, in a multipoint packet based network.
The present invention discloses a versatile system, in a packet based network, that determines whether an AIS message is to be propagated or suppressed to a customer node.
The present invention provides a Replicated Alarm Suppression Table (RAST), dynamically set up in a provider edge node of a packet based provider network. When a customer node detects a connectivity failure with its peers, the customer node may check the RAST to determine whether the failure is caused by the provider domain supporting the customer node to, in turn, determine whether an alarm report is to be suppressed or not, and to determine the actual cause of the connectivity failure.
In one embodiment, a customer node notifies a provider edge node, and the provider edge node then checks the RAST to determine cause of the failure. If the failure is caused by a failed connectivity between its supporting provider edge nodes, then the customer node may suppress the customer node's secondary alarm report. If no failure is detected on the connectivity between its supporting provider edge nodes, then the customer node may report the connectivity fault to its peers indicating the connectivity fault is caused by its own administration domain.
In another embodiment, a primary connection failure of a provider edge node may not necessarily affect a connectivity of a customer node to its peers. When multiple paths across a provider domain exist, a secondary connection may be found to overcome the primary connection failure. Thus there is no need for the provider edge to propagate its failure to its customer node.
For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:
The present invention is hereafter in relation to certain exemplary embodiments below. It is understood, however, that the embodiments below are not necessarily limitations to the present disclosure. Although only a few exemplary embodiments of this invention have been described in detail, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments. It is understood that modifications, changes and substitutions are intended in the foregoing disclosure, and in some instances some features of the invention will be employed without a corresponding use of other features.
A person of the ordinary skill in the art will understand some terms in the present invention may be interpreted as follows: a domain which provides connectivity to other domains may be called a “Provider Network”; a “Provider Network” may or may not be a network by service providers; a simple provider network may be a physical link connecting two domains, or set of nodes; an edge node of a “Provider Network” may be called a provider edge node; a domain which gets part of its connectivity from another domain may be called a “Customer Network”; and nodes within the “Customer Network” may be called customer nodes.
As illustrated in
In order for a provider edge node to determine whether a provider connectivity fault is a cause of a particular customer connectivity failure, the provider edge node may need to have a table to keep track of supporting customers from other edge nodes.
In one embodiment, Table (130) may be established by each customer site registering to a provider edge node of nodes belonging to this customer site. Each edge node sends its own RAST to all other edge nodes in Network (100). Table (130) is dynamically set up correlating to each MIP/MEP, with a registration process by insertion or deletion of a connection between a provider edge node (e.g. Edge Node W) and a customer node (e.g. Customer Node d).
As illustrated in
Referring now to
Also illustrated in
When connectivity fails between Customer Node (431) and Customer Node (435) due to failed connectivity between Provider Edge Node (402) and Provider Edge Node (404), Customer Node (431) may lose a primary connection route to Customer Node (435) via connection between Provider Edge Node (402) and Provider Edge Node (404). However, Customer Node (431) may connect to Customer Node (435) via an alternative route.
As illustrated in
The previous description of the disclosed embodiments is provided to enable those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art and generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6392989||Jun 15, 2000||May 21, 2002||Cplane Inc.||High speed protection switching in label switched networks through pre-computation of alternate routes|
|US6647412 *||Jun 23, 2000||Nov 11, 2003||Nokia Internet Communications Inc.||Method and network for propagating status information|
|US20030016678 *||Jul 18, 2002||Jan 23, 2003||Nec Corporation||Communications network with routing tables for establishing a path without failure by avoiding unreachable nodes|
|US20040160895 *||Feb 14, 2003||Aug 19, 2004||At&T Corp.||Failure notification method and system in an ethernet domain|
|US20080092228 *||Dec 10, 2007||Apr 17, 2008||Verizon Services Corporation||Methods and apparatus for protecting against IP address assignments based on a false MAC address|
|EP1443716A1||Feb 3, 2003||Aug 4, 2004||Alcatel Alsthom Compagnie Generale D'electricite||Establishing diverse connections via different edge nodes|
|WO2005011206A1||Jul 19, 2004||Feb 3, 2005||Siemens Aktiengesellschaft||Method and network nodes for reporting at least one dropped-out connection path within a communication network|
|1||Foreign Communication From a Related Counterpart Application-International Search Report and Written Opinion, PCT/CN2006/002464, Jan. 25, 2007, 7 pages.|
|2||IEEE Standard, 802.1ag/D4.1, "Draft Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks-Amendment 5: Connectivity Fault Management," IEEE Computer Society, Aug. 18, 2005, 188 pages.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8165031 *||Oct 13, 2008||Apr 24, 2012||Rockstar Bidco, LP||Multi-point and rooted multi-point protection switching|
|US8315173 *||Aug 3, 2009||Nov 20, 2012||Nec Corporation||Transmission apparatus and method for distributed management thereof|
|US20080307272 *||Mar 19, 2008||Dec 11, 2008||Kimio Ozawa||Backbone transmission apparatus and method having apparatus internal alarm suppression function|
|US20090175176 *||Oct 13, 2008||Jul 9, 2009||Nortel Networks Limited||Multi-point and rooted multi-point protection switching|
|US20100027990 *||Aug 3, 2009||Feb 4, 2010||Kimio Ozawa||Transmission apparatus and method for distributed management thereof|
|U.S. Classification||370/235, 709/223|
|International Classification||H04L12/28, G06F15/173|
|Cooperative Classification||H04L41/0631, H04L43/0811|
|Oct 27, 2006||AS||Assignment|
Owner name: FUTUREWEI TECHNOLOGIES, INC., TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DUNBAR, LINDA;SULTAN, ROBERT;REEL/FRAME:018445/0602
Effective date: 20061027
|Sep 28, 2010||CC||Certificate of correction|
|Mar 6, 2013||FPAY||Fee payment|
Year of fee payment: 4