Selecting a routing direction in a communications network...

Details Selecting a routing direction in a communications network... Selecting a routing direction in a communications network...

2000-03-03

2004-01-20

Chin, Wellington (Department: 2664)

Multiplex communications

Data flow congestion prevention or control

Flow control of data transmission through a network

C455S445000, C370S351000

Reexamination Certificate

active

06680912

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to communication networks and, in particular, to networks employing rings.
BACKGROUND
As data services become increasingly mission-critical to businesses, service disruptions become increasingly costly. A type of service disruption that is of great concern is span outage, which may be due either to facility or equipment failures. Carriers of voice traffic have traditionally designed their networks to be robust in the case of facility outages, e.g. fiber breaks. As stated in the Telcordia GR-253 and GR-499 specifications for optical ring networks in the telecommunications infrastructure, voice or other protected services must not be disrupted for more than 60 milliseconds by a single facility outage. This includes up to 10 milliseconds for detection of a facility outage, and up to 50 milliseconds for rerouting of traffic.
A significant technology for implementing survivable networks meeting the above requirements has been SONET rings. A fundamental characteristic of such rings is that there are one (or more) independent physical links connecting adjacent nodes in the ring. Each link may be unidirectional, e.g. allow traffic to pass in a single direction, or may be bi-directional. A node is defined as a point where traffic can enter or exit the ring. A single span connects two adjacent nodes, where a span consists of all links directly connecting the nodes. A span is typically implemented as either a two fiber or four fiber connection between the two nodes. In the two fiber case, each link is bidirectional, with half the traffic in each fiber going in the “clockwise” direction (or direction
0
), and the other half going in the “counterclockwise” direction (or direction
1
opposite to direction
0
). In the four fiber case, each link is unidirectional, with two fibers carrying traffic in direction
0
and two fibers carrying traffic in direction
1
. This enables a communication path between any pair of nodes to be maintained on a single direction around the ring when the physical span between any single pair of nodes is lost. In the remainder of this document, references will be made only to direction
0
and direction
1
for generality.
There are 2 major types of SONET rings: unidirectional path-switched rings (UPSR) and bi-directional line-switched rings (BLSR). In the case of UPSR, robust ring operation is achieved by sending data in both directions around the ring for all inter-node traffic on the ring. This is shown in FIG.
1
. This figure shows an N-node ring made up of nodes (networking devices) numbered from node
0
to node N−1 and interconnected by spans. In this document, nodes are numbered in ascending order in direction
0
starting from
0
for notational convenience. A link passing traffic from node i to node j is denoted by dij. A span is denoted by sij, which is equivalent to sji. In this document, the term span will be used for general discussion. The term link will be used only when necessary for precision. In this diagram, traffic from node
0
to node
5
is shown taking physical routes (bold arrows) in both direction
0
and direction
1
. (In this document, nodes will be numbered sequentially in an increasing fashion in direction
0
for convenience. Node
0
will be used for examples.) At the receiving end, a special receiver implements “tail-end switching,” in which the receiver selects the data from one of the directions around the ring. The receiver can make this choice based on various performance monitoring (PM) mechanisms supported by SONET. This protection mechanism has the advantage that it is very simple, because no ring-level messaging is required to communicate a span break to the nodes on the ring. Rather, the PM facilities built into SONET ensure that a “bad” span does not impact physical connectivity between nodes, since no data whatsoever is lost due to a single span failure.
Unfortunately, there is a high price to be paid for this protection. Depending on the traffic pattern on the ring, UPSR requires 100% extra capacity (for a single “hubbed” pattern) to 300% extra capacity (for a uniform “meshed” pattern) to as much as (N−1)*100% extra capacity (for an N node ring with a nearest neighbor pattern, such as that shown in
FIG. 1
) to be set aside for protection.
In the case of two-fiber BLSR, shown in
FIG. 2A
, data from any given node to another typically travels in one direction (solid arrows) around the ring. Data communication is shown between nodes
0
and
5
. Half the capacity of each ring is reserved to protect against span failures on the other ring. The dashed arrows illustrate a ring that is typically not used for traffic between nodes
0
and
5
except in the case of a span failure or in the case of unusual traffic congestion.
In
FIG. 2B
, the span between nodes
6
and
7
has experienced a fault. Protection switching is now provided by reversing the direction of the signal from node
0
when it encounters the failed span and using excess ring capacity to route the signal to node
5
. This switching, which takes place at the same nodes that detect the fault, is very rapid and is designed to meet the 50 millisecond requirement.
BLSR protection requires 100% extra capacity over that which would be required for an unprotected ring, since the equivalent of the bandwidth of one full ring is not used except in the event of a span failure. Unlike UPSR, BLSR requires ring-level signaling between nodes to communicate information on span cuts and proper coordination of nodes to initiate ring protection.
Though these SONET ring protection technologies have proven themselves to be robust, they are extremely wasteful of capacity. Additionally, both UPSR and BLSR depend intimately on the capabilities provided by SONET for their operation, and therefore cannot be readily mapped onto non-SONET transport mechanisms.
What is needed is a protection technology where no extra network capacity is consumed during “normal” operation (i.e., when all ring spans are operational), which is less tightly linked to a specific transport protocol, and which is designed to meet the Telcordia 50 millisecond switching requirement.
SUMMARY
A network protection and restoration technique is described that efficiently utilizes the total bandwidth in the network to overcome the drawbacks of the previously described networks, that is not linked to a specific transport protocol such as SONET, and that is designed to meet the Telcordia 50 millisecond switching requirement. The disclosed network includes two rings, wherein a first ring transmits data in a “clockwise” direction (or direction
0
), and the other ring transmits data in a “counterclockwise” direction (or direction
1
opposite to direction
0
). Additional rings may also be used. The traffic is removed from the ring by the destination node.
During normal operations (i.e., all spans operational and undegraded), data between nodes flows on the ring that provides the lowest-cost path to the destination node. If traffic usage is uniformly distributed throughout the network, the lowest-cost path is typically the minimum number of hops to the destination node. Thus, both rings are fully utilized during normal operations. Each node determines the lowest-cost path from it to every other node on the ring. To do this, each node must know the network topology.
A node monitors the status of each link for which it is at the receiving end, e.g. each of its ingress links, to detect a fault. The detection of such a fault causes a highest-priority link status broadcast message to be sent to all nodes. Processing at each node of the information contained in the link status broadcast message results in reconfiguration of a routing table within each node so as to identify the optimum routing of source traffic to the destination node after the fault. Hence, all nodes know the status of the network and all independently identify the optimal routing path to each destination node when there is a fault in any of the links. The processing is designed to be extremely eff

Affiliated with

Also associated with

Rating

Selecting a routing direction in a communications network... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Selecting a routing direction in a communications network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Selecting a routing direction in a communications network... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3231831