draft-ietf-mpls-tp-shared-ring-protection-00.txt | draft-ietf-mpls-tp-shared-ring-protection-01.txt | |||
---|---|---|---|---|
Network Working Group W. Cheng | Network Working Group W. Cheng | |||
Internet-Draft L. Wang | Internet-Draft L. Wang | |||
Intended status: Standards Track H. Li | Intended status: Standards Track H. Li | |||
Expires: April 12, 2016 China Mobile | Expires: September 22, 2016 China Mobile | |||
H. Helvoort | H. Helvoort | |||
Hai Gaoming BV | Hai Gaoming BV | |||
K. Liu | K. Liu | |||
J. Dong | J. Dong | |||
J. He | J. He | |||
Huawei Technologies | Huawei Technologies | |||
F. Li | F. Li | |||
China Academy of Telecommunication Research, MIIT., China | China Academy of Telecommunication Research, MIIT., China | |||
J. Yang | J. Yang | |||
ZTE Corporation P.R.China | ZTE Corporation P.R.China | |||
J. Wang | J. Wang | |||
Fiberhome Telecommunication Technologies Co., LTD. | Fiberhome Telecommunication Technologies Co., LTD. | |||
October 10, 2015 | March 21, 2016 | |||
MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology | MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology | |||
draft-ietf-mpls-tp-shared-ring-protection-00 | draft-ietf-mpls-tp-shared-ring-protection-01 | |||
Abstract | Abstract | |||
This document describes requirements, architecture and solutions for | This document describes requirements, architecture and solutions for | |||
MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point- | MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point- | |||
to-point (P2P) services. The mechanism of MSRP is illustrated and | to-point (P2P) services. The mechanism of MSRP is illustrated and | |||
how it satisfies the requirements for optimized ring protection in | how it satisfies the requirements for optimized ring protection in | |||
RFC 5654 is analyzed. This document also defines the Ring Protection | RFC 5654 is analyzed. This document also defines the Ring Protection | |||
Switch (RPS) Protocol which is used to coordinate the protection | Switch (RPS) Protocol which is used to coordinate the protection | |||
behavior of the nodes on MPLS ring. | behavior of the nodes on MPLS ring. | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 12, 2016. | This Internet-Draft will expire on September 22, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements for MPLS-TP Ring Protection . . . . . . . . . . 4 | 2. Requirements for MPLS-TP Ring Protection . . . . . . . . . . 4 | |||
2.1. Recovery of Multiple Failures . . . . . . . . . . . . . . 4 | 2.1. Recovery of Multiple Failures . . . . . . . . . . . . . . 4 | |||
2.2. Smooth Upgrade from Linear Protection to Ring Protection 4 | 2.2. Smooth Upgrade from Linear Protection to Ring Protection 5 | |||
2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5 | 2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5 | |||
3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 | 3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 | |||
4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 | 4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 | |||
4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 | 4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 | |||
4.1.2. Label Assignment and Distribution . . . . . . . . . . 8 | 4.1.2. Label Assignment and Distribution . . . . . . . . . . 8 | |||
4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 | 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 | |||
4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 | 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 | 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10 | 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12 | 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 13 | |||
4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14 | 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17 | 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 18 | |||
4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17 | 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 18 | |||
4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 18 | 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 20 | |||
4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19 | 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 20 | |||
4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21 | 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 22 | |||
4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22 | 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 23 | |||
5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23 | 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 24 | |||
5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 24 | 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.1.1. Transmission and Acceptance of RPS Requests . . . . . 26 | 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 26 | |||
5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26 | 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26 | |||
5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 | 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 | |||
5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 | 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 | |||
5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 | 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 | |||
5.2.1. Initial States . . . . . . . . . . . . . . . . . . . 31 | 5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31 | |||
5.2.2. State transitions When Local Request is Applied . . . 32 | 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 33 | |||
5.2.3. State Transitions When Remote Request is Applied . . 36 | 5.2.3. State transitions When Local Request is Applied . . . 34 | |||
5.2.4. State Transitions When Request Addresses to Another | 5.2.4. State Transitions When Remote Request is Applied . . 37 | |||
Node is Received . . . . . . . . . . . . . . . . . . 39 | 5.2.5. State Transitions When Request Addresses to Another | |||
5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 41 | Node is Received . . . . . . . . . . . . . . . . . . 40 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 43 | |||
6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 42 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 | |||
6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 43 | 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 44 | |||
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 43 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 | 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 44 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 | 10.2. Informative References . . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | ||||
1. Introduction | 1. Introduction | |||
As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP | As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP | |||
requirements , several service providers have expressed much interest | requirements, several service providers have expressed much interest | |||
in operating MPLS-TP in ring topologies and require a high-level | in operating MPLS-TP in ring topologies and require a high-level | |||
survivability function in these topologies. In operational transport | survivability function in these topologies. In operational transport | |||
network deployment, MPLS-TP networks are often constructed with ring | network deployment, MPLS-TP networks are often constructed with ring | |||
topologies. It calls for an efficient and optimized ring protection | topologies. It calls for an efficient and optimized ring protection | |||
mechanism to achieve simple operation and fast, sub 50 ms, recovery | mechanism to achieve simple operation and fast, sub 50 ms, recovery | |||
performance. | performance. | |||
The requirements for MPLS-TP [RFC5654] state that recovery mechanisms | The requirements for MPLS-TP [RFC5654] state that recovery mechanisms | |||
which are optimized for ring topologies could be further developed if | which are optimized for ring topologies could be further developed if | |||
it can provide the following features: | it can provide the following features: | |||
skipping to change at page 6, line 34 ¶ | skipping to change at page 6, line 37 ¶ | |||
| LSP Label | | | LSP Label | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| PW Label | | | PW Label | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Payload | | | Payload | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2. Label stack used in MPLS-TP Shared Ring Protection | Figure 2. Label stack used in MPLS-TP Shared Ring Protection | |||
4.1.1. Establishment of Ring Tunnel | 4.1.1. Establishment of Ring Tunnel | |||
The Ring tunnels are established based on the egress node. The | The Ring tunnels are established based on the egress nodes. The | |||
egress node is the node where traffic leaves the ring. LSPs which | egress node is the node where traffic leaves the ring. LSPs which | |||
have the same egress node on the ring share the same ring tunnels. | have the same egress node on the ring share the same ring tunnels. | |||
In other words, all the LSPs that traverse the ring and exit from the | In other words, all the LSPs that traverse the ring and exit from the | |||
same node share the same working ring tunnel and protection ring | same node share the same working ring tunnel and protection ring | |||
tunnel. For each egress node, four ring tunnels are established: | tunnel. For each egress node, four ring tunnels are established: | |||
o one clockwise working ring tunnel, which is protected by the | o one clockwise working ring tunnel, which is protected by the | |||
anticlockwise protection ring tunnel | anticlockwise protection ring tunnel | |||
o one anticlockwise protection ring tunnel | o one anticlockwise protection ring tunnel | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 6 ¶ | |||
o one clockwise working ring tunnel, which is protected by the | o one clockwise working ring tunnel, which is protected by the | |||
anticlockwise protection ring tunnel | anticlockwise protection ring tunnel | |||
o one anticlockwise protection ring tunnel | o one anticlockwise protection ring tunnel | |||
o one anticlockwise working ring tunnel, which is protected by the | o one anticlockwise working ring tunnel, which is protected by the | |||
clockwise protection ring tunnel | clockwise protection ring tunnel | |||
o one clockwise protection ring tunnel | o one clockwise protection ring tunnel | |||
The structure of the protection tunnels are determined by the | The structure of the protection tunnels are determined by the | |||
selected protection mechanism. This will be detailed in subsequent | selected protection mechanism. This will be detailed in subsequent | |||
sections. | sections. | |||
As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, | As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, | |||
Node A and Node B, respectively, and all leave the ring at Node D. | Node A and Node B respectively, and all leave the ring at Node D. To | |||
To protect these LSPs that traverse the ring, a clockwise working | protect these LSPs that traverse the ring, a clockwise working ring | |||
ring tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise | tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection | |||
protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are | ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an | |||
established, Also, an anti-clockwise working ring tunnel (RaW_D) via | anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and | |||
C->B->A->F->E->D, and its clockwise protection ring tunnel (RcP_D) | its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D | |||
via D->E->F->A->B->C->D are established. For simplicity Figure 3 | are established. For simplicity Figure 3 only shows RcW_D and RaP_D. | |||
only shows RcW_D and RaP_D. A similar provisioning should be applied | A similar provisioning should be applied for any other node on the | |||
for any other node on the ring. In summary, for each node in | ring. In summary, for each node in Figure 3 when acting as egress | |||
Figure 3 when acting as egress node, the ring tunnels are created as | node, the ring tunnels are created as follows: | |||
follows: | ||||
o To Node A: RcW_A, RaW_A, RcP_A, RaP_A | o To Node A: RcW_A, RaW_A, RcP_A, RaP_A | |||
o To Node B: RcW_B, RaW_B, RcP_B, RaP_B | o To Node B: RcW_B, RaW_B, RcP_B, RaP_B | |||
o To Node C: RcW_C, RaW_C, RcP_C, RaP_C | o To Node C: RcW_C, RaW_C, RcP_C, RaP_C | |||
o To Node D: RcW_D, RaW_D, RcP_D, RaP_D | o To Node D: RcW_D, RaW_D, RcP_D, RaP_D | |||
o To Node E: RcW_E, RaW_E, RcP_E, RaP_E | o To Node E: RcW_E, RaW_E, RcP_E, RaP_E | |||
skipping to change at page 10, line 17 ¶ | skipping to change at page 10, line 17 ¶ | |||
failure in the links that are connected to the failed node. | failure in the links that are connected to the failed node. | |||
4.3. Ring Protection | 4.3. Ring Protection | |||
This section specifies the ring protection mechanisms in detail. In | This section specifies the ring protection mechanisms in detail. In | |||
general, the description uses the clockwise working ring tunnel and | general, the description uses the clockwise working ring tunnel and | |||
the corresponding anti-clockwise protection ring tunnel as example, | the corresponding anti-clockwise protection ring tunnel as example, | |||
but the mechanism is applicable in the same way to the anti-clockwise | but the mechanism is applicable in the same way to the anti-clockwise | |||
working and clockwise protection ring tunnels. | working and clockwise protection ring tunnels. | |||
Taking the topology in Figure 4 as example, the LSP1 enters the ring | In ring network, each working ring tunnel is associated with a | |||
at Node A and leaves the ring at Node D. In normal state, LSP1 is | protection ring tunnel in the opposite direction, and every node can | |||
obtain the ring topology either by configuration or via some topology | ||||
discovery mechanism. The ring topology and the connectivity (Intact | ||||
or Severed) between the adjacent ring nodes form the ring map. Each | ||||
ring node maintains the ring map and use it to peform ring | ||||
protection. | ||||
Taking the topology in Figure 4 as example, LSP1 enters the ring at | ||||
Node A and leaves the ring at Node D. In normal state, LSP1 is | ||||
carried by clockwise working ring tunnel (RcW_D) through the path | carried by clockwise working ring tunnel (RcW_D) through the path | |||
A->B->C->D, the label operation is: | A->B->C->D, the label operation is: | |||
[LSP1](original data traffic carried by LSP1) -> | [LSP1](original data traffic carried by LSP1) -> | |||
[RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| | [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| | |||
LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D | LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D | |||
the packet will be forwarded based on label stack of LSP1. | the packet will be forwarded based on the label stack of LSP1. | |||
The following sections describes the protection mechanisms used in | Three typical ring protection mechanisms are specified in this | |||
ring topology. | section: wrapping, short wrapping and steering. | |||
In wrapping ring protection, node which detects a failure or accepts | ||||
a switch request switches the traffic impacted by the failure to the | ||||
opposite direction (away from the failure). In this way, the | ||||
impacted traffic is switched to the protection ring tunnel by the | ||||
switching node upstream to the failure, then travels around the ring | ||||
to the other switching node through the protection ring tunnel, where | ||||
it is switched back onto the working ring tunnel and reach the egress | ||||
node. | ||||
Short wrapping ring protection provides some optimization to wrapping | ||||
protection, in which the impacted traffic is only switched once to | ||||
the protection ring tunnel by the switching node upstream to the | ||||
failure. At the egress node, the traffic leave the ring from the | ||||
protection ring tunnel. This can reduce the traffic detour of | ||||
wrapping protection. | ||||
Steering ring protection implies that the node that detects a failure | ||||
sends a request along the ring to the other node adjacent to the | ||||
failure, and all nodes in the ring process this information. For the | ||||
impaced traffic, the ingress node (which adds traffic to the ring) | ||||
perform switching from working to the protection ring tunnel, and at | ||||
the egress node the traffic leaves the ring from the protection ring | ||||
tunnel. | ||||
The following sections describes these protection mechanisms in | ||||
detail. | ||||
4.3.1. Wrapping | 4.3.1. Wrapping | |||
With the wrapping mechanism, the protection ring tunnel is a closed | With the wrapping mechanism, the protection ring tunnel is a closed | |||
ring identified by the egress node. As shown in Figure 4, the RaP_D | ring identified by the egress node. As shown in Figure 4, the RaP_D | |||
is the anticlockwise protection ring tunnel for the clockwise working | is the anticlockwise protection ring tunnel for the clockwise working | |||
ring tunnel RcW_D. As specified in the following sections, the | ring tunnel RcW_D. As specified in the following sections, the | |||
closed ring protection tunnel can protect both the link failure and | closed ring protection tunnel can protect both the link failure and | |||
the node failure. | the node failure. | |||
4.3.1.1. Wrapping for Link Failure | 4.3.1.1. Wrapping for Link Failure | |||
When a link failure between Node B and Node C occurs, if it is a bi- | When a link failure between Node B and Node C occurs, if it is a bi- | |||
directional failure, both Node B and Node C can detect the failure | directional failure, both Node B and Node C can detect the failure | |||
via OAM mechanism; if it is a uni-directional failure, one of the two | via OAM mechanism; if it is a uni-directional failure, one of the two | |||
nodes would detect the failure and it would inform the other node via | nodes would detect the failure and it would inform the other node via | |||
the Ring Protection Switch Protocol (RPS) which is specified in | the Ring Protection Switch Protocol (RPS) which is specified in | |||
section 5. Then Node B switches the clockwise working ring tunnel | section 5. Then Node B switches the clockwise working ring tunnel | |||
(RcW_D) to the anticlockwise protection ring tunnel (RaP_D) and Node | (RcW_D) to the anticlockwise protection ring tunnel (RaP_D) and Node | |||
C switches anticlockwise protection ring tunnel(RaP_D) to the | C switches anticlockwise protection ring tunnel(RaP_D) back to the | |||
clockwise working ring tunnel(RcW_D). The data traffic which enters | clockwise working ring tunnel (RcW_D). The data traffic which enters | |||
the ring at Node A and leaves the ring at Node D follows the path | the ring at Node A and leaves the ring at Node D follows the path | |||
A->B->A->F->E->D->C->D. The label operation is: | A->B->A->F->E->D->C->D. The label operation is: | |||
[LSP1](Original data traffic) -> [RcW_D(B)|LSP1](Node A) -> | [LSP1](Original data traffic) -> [RcW_D(B)|LSP1](Node A) -> | |||
[RaP_D(A)|LSP1](Node B) -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] | [RaP_D(A)|LSP1](Node B) -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] | |||
(Node F) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> | (Node F) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> | |||
[RcW_D(D)|LSP1](Node C) -> [LSP1](data traffic leaves the ring). | [RcW_D(D)|LSP1](Node C) -> [LSP1](data traffic leaves the ring). | |||
+---+#####[RaP_D(F)]######+---+ | +---+#####[RaP_D(F)]######+---+ | |||
| F |---------------------| A | +-- LSP1 | | F |---------------------| A | +-- LSP1 | |||
skipping to change at page 11, line 48 ¶ | skipping to change at page 12, line 43 ¶ | |||
The data traffic which enters the ring at Node A and exits at Node D | The data traffic which enters the ring at Node A and exits at Node D | |||
follows the path A->F->E->D->C->D. The label operation is: | follows the path A->F->E->D->C->D. The label operation is: | |||
[LSP1](original data traffic carried by LSP1) -> | [LSP1](original data traffic carried by LSP1) -> | |||
[RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> | [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> | |||
[RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] | [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] | |||
(NodeC) -> [LSP1](data traffic carried by LSP1). | (NodeC) -> [LSP1](data traffic carried by LSP1). | |||
In one special case where node D fails, all the ring tunnels with | In one special case where node D fails, all the ring tunnels with | |||
node D as egress will become unusable. However, before the failure | node D as egress will become unusable. However, before the failure | |||
location is propagated to all the ring nodes, the wrapping protection | location information is propagated to all the ring nodes, the | |||
mechanism may cause temporary traffic loop: node C detects the | wrapping protection mechanism may cause temporary traffic loop: node | |||
failure and switches the traffic from the clockwise work ring tunnel | C detects the failure and switches the traffic from the clockwise | |||
(RcW_D) to the anticlockwise protection ring tunnel (RaP_D), node E | work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel | |||
also detects the failure and would switch the traffic from | (RaP_D), node E also detects the failure and would switch the traffic | |||
anticlockwise protection ring tunnel (RaP_D) back to the clockwise | from anticlockwise protection ring tunnel (RaP_D) back to the | |||
work ring tunnel (RcW_D). A possible mechanism to mitigate the | clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate | |||
temporary loop problem is: the TTL of the ring tunnel label is set to | the temporary loop problem is: the TTL of the ring tunnel label is | |||
2*N by the ingress ring node of the traffic, where N is the number of | set to 2*N by the ingress ring node of the traffic, where N is the | |||
nodes on the ring. | number of nodes on the ring. | |||
+---+#####[RaP_D(F)]######+---+ | +---+#####[RaP_D(F)]######+---+ | |||
| F |---------------------| A | +-- LSP1 | | F |---------------------| A | +-- LSP1 | |||
+---+*****[RcW_D(A)]******+---+ | +---+*****[RcW_D(A)]******+---+ | |||
#/* *\# | #/* *\# | |||
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | |||
#/* *\# | #/* *\# | |||
+---+ xxxxx | +---+ xxxxx | |||
| E | x B x | | E | x B x | |||
+---+ xxxxx | +---+ xxxxx | |||
skipping to change at page 12, line 33 ¶ | skipping to change at page 13, line 28 ¶ | |||
LSP1 +-- | D |-------------------| C | | LSP1 +-- | D |-------------------| C | | |||
+---+#####[RaP_D(C)]####+---+ | +---+#####[RaP_D(C)]####+---+ | |||
-----physical links xxxxxx Failure Node | -----physical links xxxxxx Failure Node | |||
*****RcW_D ###### RaP_D | *****RcW_D ###### RaP_D | |||
Figure 6. Wrapping for node failure | Figure 6. Wrapping for node failure | |||
4.3.2. Short Wrapping | 4.3.2. Short Wrapping | |||
With the traditional wrapping protection scheme, Protection switching | With the traditional wrapping protection scheme, protection switching | |||
is executed at both nodes detecting the failure, consequently the | is executed at both nodes adjacent to the failure, consequently the | |||
traffic will be wrapped twice. This mechanism will cause additional | traffic will be wrapped twice. This mechanism will cause additional | |||
latency and bandwidth consumption when traffic is switched to the | latency and bandwidth consumption when traffic is switched to the | |||
protection path. | protection path. | |||
With short wrapping protection, data traffic switching is executed | With short wrapping protection, data traffic switching is executed | |||
only at the upstream node detecting the failure, and data traffic | only at the node upstream to the failure, and data traffic leaves the | |||
leaves the ring in the protection ring tunnel at the egress node. | ring in the protection ring tunnel at the egress node. This scheme | |||
This scheme can reduce the additional latency and bandwidth | can reduce the additional latency and bandwidth consumption when | |||
consumption when traffic is switched to the protection path. | traffic is switched to the protection path. | |||
In the traditional wrapping solution, the protection ring tunnel is a | In the traditional wrapping solution, in normal state the protection | |||
closed ring in normal state, while in the short wrapping solution, | ring tunnel is a closed ring, while in the short wrapping solution, | |||
the protection ring tunnel is ended at the egress node, which is | the protection ring tunnel is ended at the egress node, which is | |||
similar to the working ring tunnel. Short wrapping is easy to | similar to the working ring tunnel. Short wrapping is easy to | |||
implement in shared ring protection because both the working and | implement in shared ring protection because both the working and | |||
protection ring tunnels are terminated on the egress nodes. Figure 7 | protection ring tunnels are terminated on the egress nodes. Figure 7 | |||
shows the clockwise working ring tunnel and the anticlockwise | shows the clockwise working ring tunnel and the anticlockwise | |||
protection ring tunnel with node D as the egress node. | protection ring tunnel with node D as the egress node. | |||
4.3.2.1. Short Wrapping for Link Failure | 4.3.2.1. Short Wrapping for Link Failure | |||
As shown in Figure 7, in normal state, LSP1 is carried by the | As shown in Figure 7, in normal state, LSP1 is carried by the | |||
clockwise working ring tunnel (RcW_D) through the path A->B->C->D. | clockwise working ring tunnel (RcW_D) through the path A->B->C->D. | |||
When a link failure between Node B and Node C occurs, Node B switches | When a link failure between Node B and Node C occurs, Node B switches | |||
The working ring tunnel RcW_D to the protection ring tunnel RaP_D in | The working ring tunnel RcW_D to the protection ring tunnel RaP_D in | |||
the opposite direction. The difference occurs in the protection ring | the opposite direction. The difference occurs in the protection ring | |||
tunnel at egress node. In short wrapping protection, Rap_D ends in | tunnel at egress node. In short wrapping protection, Rap_D ends in | |||
Node D and then traffic will be forwarded based on the LSP labels. | Node D and then traffic will be forwarded based on the LSP labels. | |||
Thus with short wrapping mechanism, LSP1 will follow the path | Thus with short wrapping mechanism, LSP1 will follow the path | |||
A->B->A->F->E->D when link failure between Node B and Node C happens. | A->B->A->F->E->D when link failure between Node B and Node C happens. | |||
For node failure, the protection with short wrapping is similar to | ||||
the mechanism with link failure. | ||||
+---+#####[RaP_D(F)]######+---+ | +---+#####[RaP_D(F)]######+---+ | |||
| F |---------------------| A | +-- LSP1 | | F |---------------------| A | +-- LSP1 | |||
+---+*****[RcW_D(A)]******+---+ | +---+*****[RcW_D(A)]******+---+ | |||
#/* *\# | #/* *\# | |||
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | |||
#/* *\# | #/* *\# | |||
+---+ +---+ | +---+ +---+ | |||
| E | | B | | | E | | B | | |||
+---+ +---+ | +---+ +---+ | |||
skipping to change at page 13, line 44 ¶ | skipping to change at page 14, line 40 ¶ | |||
LSP1 +-- | D |-------------------| C | | LSP1 +-- | D |-------------------| C | | |||
+---+ +---+ | +---+ +---+ | |||
----- physical links xxxxx Failure Link | ----- physical links xxxxx Failure Link | |||
****** RcW_D ###### RaP_D | ****** RcW_D ###### RaP_D | |||
Figure 7. Short wrapping for link failure | Figure 7. Short wrapping for link failure | |||
4.3.2.2. Short Wrapping for Node Failure | 4.3.2.2. Short Wrapping for Node Failure | |||
For the failure scenarios which happen on a non-egress node, short | For the node failure which happens on a non-egress node, short | |||
wrapping protection switching is similar to the link failure as | wrapping protection switching is similar to the link failure case as | |||
described in the previous section. This section specifies the | described in the previous section. This section specifies the | |||
scenario of egress node failure. | scenario of egress node failure. | |||
As shown in Figure 8, LSP1 enters the ring on node A, and leaves the | As shown in Figure 8, LSP1 enters the ring on node A, and leaves the | |||
ring on node D. in normal state, LSP1 is carried by the clockwise | ring on node D. In normal state, LSP1 is carried by the clockwise | |||
working ring tunnel (RcW_D) through the path A->B->C->D. When node D | working ring tunnel (RcW_D) through the path A->B->C->D. When node D | |||
fails, traffic of LSP1 cannot be protected by any ring tunnels which | fails, traffic of LSP1 cannot be protected by any ring tunnels which | |||
use node D as the egress node. However, before the failure location | use node D as the egress node. However, before the failure location | |||
is propagated to all the ring nodes, node C switches all the traffic | information is propagated to all the ring nodes, node C switches all | |||
on the working ring tunnel RcW_D to the protection ring tunnel RaP_D | the traffic on the working ring tunnel RcW_D to the protection ring | |||
in the opposite direction. When the traffic arrives at node E which | tunnel RaP_D in the opposite direction. When the traffic arrives at | |||
also detects the failure of node D, the protection ring tunnel RaP_D | node E which also detects the failure of node D, the protection ring | |||
cannot be used to forward traffic to node D. Since with short | tunnel RaP_D cannot be used to forward traffic to node D. Since with | |||
wrapping mechanism, protection switching can only be performed once | short wrapping mechanism, protection switching can only be performed | |||
from the working ring tunnel to the protection ring tunnel, thus node | once from the working ring tunnel to the protection ring tunnel, thus | |||
E MUST NOT switch the traffic which is already carried on the | node E MUST NOT switch the traffic which is already carried on the | |||
protection ring tunnel back to the working ring tunnel in the | protection ring tunnel back to the working ring tunnel in the | |||
opposite direction. Instead, node E will discard the traffic | opposite direction. Instead, node E will discard the traffic | |||
received on RaP_D locally. This can avoid the temporary traffic loop | received on RaP_D locally. This can avoid the temporary traffic loop | |||
when the faiulre happens on the egress node of the ring tunnel. This | when the failure happens on the egress node of the ring tunnel. This | |||
also illustrates one of the benefits of having separate working and | also illustrates one of the benefits of having separate working and | |||
protection ring tunnels in each ring direction. | protection ring tunnels in each ring direction. | |||
+---+#####[RaP_D(F)]######+---+ | +---+#####[RaP_D(F)]######+---+ | |||
| F |---------------------| A | +-- LSP1 | | F |---------------------| A | +-- LSP1 | |||
+---+*****[RcW_D(A)]******+---+ | +---+*****[RcW_D(A)]******+---+ | |||
#/* *\# | #/* *\# | |||
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) | |||
#/* *\# | #/* *\# | |||
+---+ +---+ | +---+ +---+ | |||
skipping to change at page 14, line 44 ¶ | skipping to change at page 15, line 39 ¶ | |||
LSP1 +-- x D x-------------------| C | | LSP1 +-- x D x-------------------| C | | |||
xxxxx +---+ | xxxxx +---+ | |||
-----physical links xxxxxx Failure Node | -----physical links xxxxxx Failure Node | |||
*****RcW_D ###### RaP_D | *****RcW_D ###### RaP_D | |||
Figure 8. Short Wrapping for egress node failure | Figure 8. Short Wrapping for egress node failure | |||
4.3.3. Steering | 4.3.3. Steering | |||
In ring topology, each working ring tunnel is associated with a | With steering protection mechanism, the ingress node (which adds | |||
protection ring tunnel in the opposite direction, and every node can | traffic to the ring) perform switching from working to the protection | |||
obtain the ring topology either by configuration or via some topology | ring tunnel, and at the egress node the traffic leaves the ring from | |||
discovery mechanism. The ring topology and the connectivity (Intact | the protection ring tunnel. | |||
or Severed) between the adjacent ring nodes form the ring map. Every | ||||
ring node maintains its ring map. When a failure occurs in the ring, | When a failure occurs in the ring, the node which detects the failure | |||
the nodes that detect the failure via OAM mechanism will transmit the | via OAM mechanism sends the failure information in the opposite | |||
failure information in the opposite direction of the failure hop by | direction of the failure hop by hop along the ring using RPS request | |||
hop along the ring. When a node receives the message that identifies | message. When a ring node receives the RPS message which identifies | |||
a failure, it can quickly determine the location of the fault by | a failure, it can quickly determine the location of the fault by | |||
using the topology information that is maintained by the node and | using the topology information that is maintained by the node and | |||
upate the ring map accordingly, then it can determine whether the | update the ring map accordingly, then it can determine whether the | |||
LSPs entering the ring locally need to switchover or not. For LSPs | LSPs entering the ring locally need to switchover or not. For LSPs | |||
that needs to switchover, it will switch the LSPs from the working | that needs to switchover, it will switch the LSPs from the working | |||
ring tunnels to its corresponding protection ring tunnels. | ring tunnels to its corresponding protection ring tunnels. | |||
Ring map of F +--LSPl | 4.3.3.1. Steering for Link Failure | |||
Ring map of F +--LSPl | ||||
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ | |||
|F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| | |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| | |||
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ | |||
|I|I|I|S|I|I| |I|I|S|I|I|I| | |I|I|I|S|I|I| |I|I|S|I|I|I| | |||
+-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ | +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ | |||
[RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] | [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] | |||
#/* [RcW_D(F)] *\# | #/* [RcW_D(F)] *\# | |||
+-+-+-+-+-+-+-+ #/* *\# | +-+-+-+-+-+-+-+ #/* *\# | |||
|E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 | |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 | |||
+-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ | |||
skipping to change at page 15, line 42 ¶ | skipping to change at page 16, line 39 ¶ | |||
+-+-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |||
----- physical links ***** RcW_D ##### RaP_D | ----- physical links ***** RcW_D ##### RaP_D | |||
I: Intact S: Severed | I: Intact S: Severed | |||
Figure 9. Steering operation and protection switching | Figure 9. Steering operation and protection switching | |||
As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 | As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 | |||
enters the ring from Node B, and both of them have the same | enters the ring from Node B, and both of them have the same | |||
destination node D. | destination node D. | |||
In the normal state, LSP1 is carried by the clockwise working ring | In normal state, LSP1 is carried by the clockwise working ring tunnel | |||
tunnel (RcW_D) through the path A->B->C->D, the label operation is: | (RcW_D) through the path A->B->C->D, the label operation is: [LSP1] | |||
[LSP1] -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> | -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> | |||
[RcW_D(D)|LSP1](NodeC) -> [LSP1] (data traffic carried by LSP1) . | [RcW_D(D)|LSP1](NodeC) -> [LSP1] (data traffic carried by LSP1) . | |||
LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught | LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught | |||
the path B->C->D, the label operation is: [LSP2] -> | the path B->C->D, the label operation is: [LSP2] -> | |||
[RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2] (data | [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2] (data | |||
traffic carried by LSP2) . | traffic carried by LSP2) . | |||
If the link between nodes C and D fails, according to the fault | If the link between nodes C and D fails, according to the fault | |||
detection and distribution mechanisms, Node D will find out that | detection and distribution mechanisms, Node D will find out that | |||
there is a failure in the link between C and D, and it will update | there is a failure in the link between C and D, and it will update | |||
skipping to change at page 16, line 28 ¶ | skipping to change at page 17, line 24 ¶ | |||
When Node A receives the failure report message and updates the link | When Node A receives the failure report message and updates the link | |||
state of its ring topology, it is aware that there is a fault on the | state of its ring topology, it is aware that there is a fault on the | |||
clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the | clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the | |||
ring locally and is carried by this ring tunnel, thus Node A will | ring locally and is carried by this ring tunnel, thus Node A will | |||
decide to switch the LSP1 onto the anticlockwise protection ring | decide to switch the LSP1 onto the anticlockwise protection ring | |||
tunnel to node D (RaP_D). After the switchover, LSP1 will follow the | tunnel to node D (RaP_D). After the switchover, LSP1 will follow the | |||
path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| | path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| | |||
LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> | LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> | |||
[LSP1] (data traffic carried by LSP1). | [LSP1] (data traffic carried by LSP1). | |||
The same also apply to the operation of LSP2. When Node B updates | The same procedure also applies to the operation of LSP2. When Node | |||
the link state of its ring topology, and finds out that the working | B updates the link state of its ring topology, and finds out that the | |||
ring tunnel RcW_D has failed, it will switch the LSP2 to the | working ring tunnel RcW_D has failed, it will switch the LSP2 to the | |||
anticlockwise protection tunnel RaP_D. After the switchover, LSP2 | anticlockwise protection tunnel RaP_D. After the switchover, LSP2 | |||
goes through the path B->A->F->E->D, and the label operation is: | goes through the path B->A->F->E->D, and the label operation is: | |||
[LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> | [LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> | |||
[RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data | [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data | |||
traffic carried by LSP2). | traffic carried by LSP2). | |||
Then assume the link between nodes A and B breaks down, as shown in | Assume the link between nodes A and B breaks down, as shown in | |||
Figure 10. Similar to the above failure case, Node B will detect a | Figure 10. Similar to the above failure case, Node B will detect a | |||
fault in the link between A and B, and it will update the link state | fault in the link between A and B, and it will update its ring map, | |||
of its ring topology, changing the link state between A and B from | changing the link state between A and B from normal to fault. The | |||
normal to fault. The state report message is sent hop by hop in the | state report message is sent hop by hop in the clockwise direction, | |||
clockwise direction, notifying every node that there is a fault | notifying every node that there is a fault between node A and B, and | |||
between node A and B, and every node updates the link state of its | every node updates the link state of its ring topology. As a result, | |||
ring topology. As a result, Node A will detect a fault in the | Node A will detect a fault in the working ring tunnel to node D, and | |||
working ring tunnel to node D, and switch LSP1 to the protection ring | switch LSP1 to the protection ring tunnel, while Node B determine | |||
tunnel, while Node B determine that the working ring tunnel for LSP2 | that the working ring tunnel for LSP2 still works fine, and will not | |||
still works fine, and will not perform the switchover. | perform the switchover. | |||
/-- LSPl | /-- LSPl | |||
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ | |||
|F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| | |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| | |||
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ | |||
|I|S|I|I|I|I| #/* x |S|I|I|I|I|I| | |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| | |||
+-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ | +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ | |||
[RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] | [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] | |||
#/* x +-- LSP2 | #/* x +-- LSP2 | |||
+-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ | |||
skipping to change at page 17, line 29 ¶ | skipping to change at page 18, line 29 ¶ | |||
+-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ | |||
|D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| | |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| | |||
+-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ | |||
|I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| | |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| | |||
+-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ | +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ | |||
----- physical links ***** RcW_D ##### RaP_D | ----- physical links ***** RcW_D ##### RaP_D | |||
Figure 10. Steering operation and protection switching (2) | Figure 10. Steering operation and protection switching (2) | |||
4.3.3.2. Steering for Node Failure | ||||
For node failure which happens on a non-egress node, steering | ||||
protection switching is similar to the link failure case as described | ||||
in the previous section. | ||||
If the failure occurs at the egress node of the LSP, since the | ||||
ingress node can update its ring map according to the received RPS | ||||
messages, it will determine that the egress node is not reachable | ||||
after the failure, thus it will not send traffic to either the | ||||
working or protection tunnel, and traffic loop can be avoided. | ||||
4.4. Interconnected Ring Protection | 4.4. Interconnected Ring Protection | |||
4.4.1. Interconnected Ring Topology | 4.4.1. Interconnected Ring Topology | |||
Interconnected ring topology is often used in MPLS-TP networks. This | Interconnected ring topology is widely used in MPLS-TP networks. | |||
document will discuss two typical interconnected ring topologies: | This document will discuss two typical interconnected ring | |||
topologies: | ||||
1. Single-node interconnected rings | 1. Single-node interconnected rings | |||
In single-node interconnected rings, the connection between | In single-node interconnected rings, the connection between | |||
the two rings is through a single node. Because the | the two rings is through a single node. Because the | |||
interconnection node is in fact a single point of failure, | interconnection node is in fact a single point of failure, | |||
this topology should be avoided in real transport networks. | this topology should be avoided in real transport networks. | |||
Figure 10 shows the topology of single-node interconnected | Figure 11 shows the topology of single-node interconnected | |||
rings. Node C is the interconnection node between Ring1 and | rings. Node C is the interconnection node between Ring1 and | |||
Ring2. | Ring2. | |||
2. Dual-node interconnected rings | 2. Dual-node interconnected rings | |||
In dual-node interconnected rings, the connection between the | In dual-node interconnected rings, the connection between the | |||
two rings is through two nodes. The two interconnection nodes | two rings is through two nodes. The two interconnection nodes | |||
belong to both interconnected rings. This topology can | belong to both interconnected rings. This topology can | |||
recover from one interconnection node failure. | recover from one interconnection node failure. | |||
skipping to change at page 18, line 44 ¶ | skipping to change at page 20, line 9 ¶ | |||
+---+ +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ +---+ | |||
| F |------| E |------| D |------| J |------| I | | | F |------| E |------| D |------| J |------| I | | |||
+---+ +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ +---+ | |||
Figure 12. Dual-node interconnected rings | Figure 12. Dual-node interconnected rings | |||
4.4.2. Interconnected Ring Protection Mechanisms | 4.4.2. Interconnected Ring Protection Mechanisms | |||
Interconnected rings can be treated as two independent rings. Ring | Interconnected rings can be treated as two independent rings. Ring | |||
protection switching (RPS) protocol operates on each ring | protection switching (RPS) protocol operates on each ring | |||
independently. Failure in one ring only triggers protection | independently. Failure happened on one ring only triggers protection | |||
switching on the ring itself and does not affect the other ring. | switching on the ring itself and does not affect the other ring, | |||
This way, protection switching on each ring is the same as the | unless the failure is on the interconnection node. This way, | |||
mechanisms described in section 4.3. | protection switching on each ring is the same as the mechanisms | |||
described in section 4.3. | ||||
The service LSPs that traverse the interconnected rings via the | The service LSPs that traverse the interconnected rings use seperate | |||
interconnection nodes MUST use different ring tunnels in different | ring tunnels on each ring, and the LSPs on different rings are | |||
rings, and the service LSPs traversing the interconnected rings are | ||||
stitched by the interconnection node. On the interconnection node, | stitched by the interconnection node. On the interconnection node, | |||
the ring tunnel label used in the source ring will be popped, the | the ring tunnel label of the source ring is popped, then LSP label is | |||
service LSP label will be swapped, and the ring tunnel label of the | swapped, after that the ring tunnel label of the destination ring is | |||
destination ring will be pushed. | pushed. | |||
In the dual-node interconnected ring scenario, the two | In the dual-node interconnected ring scenario, the two | |||
interconnection nodes can be managed as a virtual interconnection | interconnection nodes can be managed as a virtual node group. In | |||
node group. Each ring should assign working and protection ring | addition to the ring tunnels to each physical ring node, Each ring | |||
tunnels for the virtual interconnection node group. Both the | SHOULD assign the working and protection ring tunnels to the virtual | |||
interconnection nodes in the virtual interconnection node group can | interconnection node group. In addition, on both nodes in the | |||
terminate the working ring tunnel of each ring. The protection ring | virtual interconnection node group, the same LSP label is assigned | |||
tunnel is used to protect the working ring tunnel of each ring and | for each traversed LSP. This way, any interconnection node in the | |||
can be terminated by any node in the virtual interconnection node | virtual node group can terminate the working or protection ring | |||
group. | tunnels targeted to the virtual node group, and stitch the service | |||
LSP from the source ring tunnel to the destination ring tunnel. | ||||
On the nodes in the virtual interconnection node group of the dual- | ||||
node interconnected ring, the same label is allocated for each | ||||
service LSP. This way any interconnection node in the virtual node | ||||
group can stitch the service LSPs between the source ring tunnel and | ||||
the destination ring tunnel. | ||||
When the service traffic passes through the interconnection node, the | When the service LSP passes through the interconnected rings, the | |||
direction of the working ring tunnels in each ring for this service | direction of the working ring tunnels used on both rings SHOULD be | |||
traffic should be the same. For example, if the working ring tunnel | the same. For example, if the service LSP uses the clockwise working | |||
follows the clockwise direction in Ring1, the working ring tunnel for | ring tunnel on Ring1, when the service LSP leaves Ring1 and enters | |||
the same service traffic in Ring2 SHOULD also follow the clockwise | Ring2, the working ring tunnel used on Ring2 SHOULD also follow the | |||
direction when the service leaves Ring1 and enters Ring2. | clockwise direction. | |||
4.4.3. Ring Tunnels in Interconnected Rings | 4.4.3. Ring Tunnels in Interconnected Rings | |||
The same ring tunnels as described in section 4.1 are used in each | The same ring tunnels as described in section 4.1 are used in each | |||
ring of the interconnected rings. Note that ring tunnels to the | ring of the interconnected rings. In addition, ring tunnels to the | |||
virtual interconnection node group will be established by each ring | virtual interconnection node group are established on each ring of | |||
of the interconnected rings, i.e.: | the interconnected rings, i.e.: | |||
o one clockwise working ring tunnel to the virtual interconnection | o one clockwise working ring tunnel to the virtual interconnection | |||
node group | node group | |||
o one anticlockwise protection ring tunnel to the virtual | o one anticlockwise protection ring tunnel to the virtual | |||
interconnection node group | interconnection node group | |||
o one anticlockwise working ring tunnel to the virtual | o one anticlockwise working ring tunnel to the virtual | |||
interconnection node group | interconnection node group | |||
o one clockwise protection ring tunnel to the virtual | o one clockwise protection ring tunnel to the virtual | |||
interconnection node group | interconnection node group | |||
These ring tunnels will terminated at all nodes in the virtual | These ring tunnels will terminated at any node in the virtual | |||
interconnection node group. | interconnection node group. | |||
For example, all the ring tunnels on Ring1 of Figure 12 are | For example, all the ring tunnels on Ring1 in Figure 13 are | |||
established as follows: | provisioned as follows: | |||
o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A | o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A | |||
o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B | o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B | |||
o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C | o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C | |||
o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D | o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D | |||
o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E | o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E | |||
o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F | o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F | |||
o To the virtual interconnection node group (including Node F and | o To the virtual interconnection node group (including Node F and | |||
Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A | Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A | |||
All the ring tunnels established in Ring2 in Figure 13 are | All the ring tunnels on Ring2 in Figure 13 are provisioned as | |||
provisioned as follows: | follows: | |||
o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A | o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A | |||
o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F | o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F | |||
o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G | o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G | |||
o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H | o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H | |||
o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I | o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I | |||
o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J | o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J | |||
o To the virtual interconnection node group(including Node F and | o To the virtual interconnection node group (including Node F and | |||
Node A): R2cW_FandA, R2aW_FandA, R2cP_FandA, R2aP_FandA | Node A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A | |||
+---+cccccccccccc +---+ | +---+cccccccccccc +---+ | |||
| H |-------------| I |--->LSP1 | | H |-------------| I |--->LSP1 | |||
+---+ +---+ | +---+ +---+ | |||
c/a a\ | c/a a\ | |||
c/a a\ | c/a a\ | |||
c/a a\ | c/a a\ | |||
+---+ +---+ | +---+ +---+ | |||
| G | Ring2 | J | | | G | Ring2 | J | | |||
+---+ +---+ | +---+ +---+ | |||
c\a a/c | c\a a/c | |||
skipping to change at page 21, line 40 ¶ | skipping to change at page 22, line 40 ¶ | |||
+---+ccccccccccccc+---+ | +---+ccccccccccccc+---+ | |||
ccccccccccc R1cW_F&A | ccccccccccc R1cW_F&A | |||
aaaaaaaaaaa R1aP_F&A | aaaaaaaaaaa R1aP_F&A | |||
ccccccccccc R2cW_I | ccccccccccc R2cW_I | |||
aaaaaaaaaaa R2aP_I | aaaaaaaaaaa R2aP_I | |||
Figure 13. Ring tunnels for the interconnected rings | Figure 13. Ring tunnels for the interconnected rings | |||
4.4.4. Interconnected Ring Switching Procedure | 4.4.4. Interconnected Ring Switching Procedure | |||
As shown in Figure 13, for the service traffic LSP1 which enters | As shown in Figure 13, for the service LSP1 which enters Ring1 at | |||
Ring1 at Node D and leaves Ring1 at Node F and continues to enter | Node D and leaves Ring1 at Node F and continues to enter Ring2 at | |||
Ring2 at Node F and leaves Ring2 at Node I, the protection scheme is | Node F and leaves Ring2 at Node I, the short wrapping protection | |||
described as below. | scheme is described as below. | |||
In normal state, LSP1 follows R1cW_F&A in Ring1 and R2CW_I in Ring2. | In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. | |||
The label used for the working ring tunnel R1cW_F&A in Ring1 is | At the interconnection node F, the label used for the working ring | |||
popped and the label used for the working ring tunnel R2cW_I will be | tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the | |||
pushed based the inner label lookup at the interconnection node F. | label used for the working ring tunnel R2cW_I in Ring2 will be pushed | |||
The working path that the service traffic LSP1 follows is: | based the inner LSP label lookup. The working path that the service | |||
LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. | LSP1 follows is: LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. | |||
In case of link failure, for example, when a failure occurs on the | In case of link failure, for example, when a failure occurs on the | |||
link between Node F and Node E, Nodes F and E will detect the failure | link between Node F and Node E, Node E will detect the failure and | |||
and execute protection switching as described in 4.3.1.1. The path | execute protection switching as described in 4.3.2. The path that | |||
that the service traffic LSP1 follows after switching change to | the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- | |||
LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A->F)->R1cW_F(F) | >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. | |||
->R2cW_I(F->G->H->I)->LSP1. | ||||
In case of a non interconnection node failure, for example, when the | In case of a non-interconnection node failure, for example, when the | |||
failure occurs at Node E in Ring1, Nodes F and D will detect the | failure occurs at Node E in Ring1, Node D will detect the failure and | |||
failure and execute protection switching as described in 4.3.1.2. | execute protection switching as described in 4.3.2. The path that | |||
The path that the service traffic LSP1 follows after switching | the service LSP1 follows after switching becomes: | |||
becomes: LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A->F)-> | LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. | |||
R1cW_F(F)->R2cW_I(F->G->H->I). | ||||
In case of an interconnection node failure, for example, when the | In case of an interconnection node failure, for example, when the | |||
failure occurs at the interconnection Node F. Nodes E and A in Ring1 | failure occurs at the interconnection Node F. Node E in Ring1 will | |||
will detect the failure, and execute protection switching as | detect the failure, and execute protection switching as described in | |||
described in 4.3.1.2. Nodes G and A in Ring2 will also detects the | 4.3.2. Node A in Ring2 will also detect the failure, and execute | |||
failure, and execute protection switching. The path that the service | protection switching as described in 4.3.2. The path that the | |||
traffic LSP1 follows after switching is: | service traffic LSP1 follows after switching is: | |||
LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R1cW_A(A) | LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1. | |||
->R2aP_I(A->J->I)->LSP1. | ||||
4.4.5. Interconnected Ring Detection Mechanism | 4.4.5. Interconnected Ring Detection Mechanism | |||
As show in Figure 14, the service traffic LSP1 traverses A->B->C in | As show in Figure 13, in normal state the service traffic LSP1 | |||
Ring1 and C->G->H->I in Ring2. Node C and Node D are the | traverses D->E->F in Ring1 and F->G->H->I in Ring2. Node A and F are | |||
interconnection nodes. When both the link between Node C and Node G | the interconnection nodes. When both the link between Node F and | |||
and the link between Node C and Node D fail, the ring tunnel from | Node G and the link between Node F and Node A fail, the ring tunnel | |||
Node C to Node I in Ring2 becomes unreachable. However, Node D is | from Node F to Node I in Ring2 becomes unreachable. However, the | |||
still available, and LSP1 can still reach Node I. | other interconnection node A is still available, and LSP1 can still | |||
reach Node I via node A. | ||||
+---+ *********+---+**********+---+ +---+**********+---+ | ||||
LSP1->| A |----------| B |----------| C |XXXXXXXXXX| G |----------| H | | ||||
+---+##########+---+##########+---+ +---+##########+---+ | ||||
|# X #|* | ||||
|# X #|* | ||||
|# Ring1 X Ring2 #|* | ||||
|# X #|* | ||||
|# X #|* | ||||
+---+##########+---+##########+---+######### +---+##########+---+ | ||||
| F |----------| E |----------| D |----------| J |----------| I | ->LSP1 | ||||
+---+ +---+ +---+ +---+ +---+ | ||||
*********** R1cW_C&D | ||||
########### R1aP_C&D | ||||
*********** R2cW_I | ||||
########### R2aP_I | ||||
Figure 14. Interconnected ring | ||||
In order to achieve this, the interconnection nodes need to know the | In order to achieve this, the interconnection nodes need to know the | |||
ring topology of each ring so that they can judge whether a node is | ring topology of each ring so that they can judge whether a node is | |||
reachable. This judgment is based on the knowledge of each ring | reachable. This judgment is based on the knowledge of ring map and | |||
topology and the fault location as described in section 3.4. The | the fault location as described in section 3.4. The ring map can be | |||
ring topology can be obtained from the NMS or topology discovery | obtained from the NMS or topology discovery mechanisms. The fault | |||
mechanisms. The fault location can be obtained by transmitting the | location can be obtained by transmitting the fault information around | |||
fault information around the ring. The nodes that detect the failure | the ring. The nodes that detect the failure will transmit the fault | |||
will transmit the fault information in the opposite direction node by | information in the opposite direction hop by hop using the RPS | |||
node in the ring. When the interconnection node receives the message | protocol message. When the interconnection node receives the message | |||
that informs the failure, it will quickly calculate the location of | that informs the failure, it will quickly calculate the location of | |||
the fault by the topology information that is maintained by itself | the fault according to the topology information that is maintained by | |||
and determines whether the LSPs entering the ring at itself can reach | itself and determines whether the LSPs entering the ring at itself | |||
the destination. If the destination node is reachable, the LSP will | can reach the destination. If the destination node is reachable, the | |||
leave the source ring and enter the destination ring. If the | LSP will leave the source ring and enter the destination ring. If | |||
destination node is not reachable, the LSP will switch to the | the destination node is not reachable, the LSP will switch to the | |||
anticlockwise protection ring tunnel. | anticlockwise protection ring tunnel. | |||
In Figure 14, Node C determines that the ring tunnel to Node I is | In Figure 13, Node F determines that the ring tunnel to Node I is | |||
unreachable, the service traffic LSP1 for which the destination node | unreachable, the service LSP1 for which the destination node on the | |||
on the ring tunnel is Node I should switch to the protection LSP | ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A) | |||
(R1aP_C&D) and consequently the service traffic LSP1 traverses the | and consequently the service traffic LSP1 traverses the | |||
interconnected rings at Node D. Node D will remove the ring tunnel | interconnected rings at Node A. Node A will pop the ring tunnel | |||
label of Ring1 and add the ring tunnel label of Ring2. | label of Ring1 and push the ring tunnel label of Ring2 and send the | |||
traffic to Node I via ring tunnel (R2aW_I). | ||||
5. Ring Protection Coordination Protocol | 5. Ring Protection Coordination Protocol | |||
5.1. RPS Protocol | 5.1. RPS Protocol | |||
The MSRP protection operation MUST be controlled with the help of the | The MSRP protection operation MUST be controlled with the help of the | |||
Ring Protection Switch Protocol (RPS). The RPS processes in each of | Ring Protection Switch Protocol (RPS). The RPS processes in each of | |||
the individual ring nodes that form the ring SHOULD communicate using | the individual ring nodes that form the ring SHOULD communicate using | |||
the G-ACh channel. | the G-ACh channel. | |||
The RPS protocol MUST carry the ring status information and RPS | The RPS protocol MUST carry the ring status information and RPS | |||
requests, i.e., automatically initiated and externally initiated, | requests, either automatically initiated or externally initiated, | |||
between the ring nodes. | between the ring nodes. | |||
Each node on the ring MUST be uniquely identified by assigning it a | Each node on the ring MUST be uniquely identified by assigning it a | |||
node ID. The node ID MUST be unique on each ring. The maximum | node ID. The node ID MUST be unique on each ring. The maximum | |||
number of nodes on the ring supported by the RPS protocol is 127. | number of nodes on the ring supported by the RPS protocol is 127. | |||
The node ID SHOULD be independent of the order in which the nodes | The node ID SHOULD be independent of the order in which the nodes | |||
appear on the ring. The node ID is used to identity the source and | appear on the ring. The node ID is used to identity the source and | |||
destination nodes of each RPS request. | destination nodes of each RPS request. | |||
Every node obtains the ring topology either by configuration or via | Every node obtains the ring topology either by configuration or via | |||
some topology discovery mechanism. The ring map consists of the ring | some topology discovery mechanism. The ring map consists of the ring | |||
topology information, and connectivity status (Intact or Severed) | topology information, and connectivity status (Intact or Severed) | |||
between the adjacent ring nodes, which is determined via the OAM | between the adjacent ring nodes, which is determined via the OAM | |||
message exchange between the adjacent nodes. The ring map is used by | message exchanged between the adjacent nodes. The ring map is used | |||
every ring node to determine the switchover behavoir of the ring | by every ring node to determine the switchover behavior of the ring | |||
tunnels. | tunnels. | |||
When no protection switching is active on the ring, each node MUST | When no protection switching is active on the ring, each node MUST | |||
dispatch periodically RPS requests to the two adjacent nodes, | dispatch periodically RPS requests to the two adjacent nodes, | |||
indicating No Request (NR). When a node determines that a protection | indicating No Request (NR). When a node determines that a protection | |||
switching is required, it MUST send the appropriate RPS request in | switching is required, it MUST send the appropriate RPS request in | |||
both directions. | both directions. | |||
+---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) | +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) | |||
-------| A |-------------| B |-------------| C |------- | -------| A |-------------| B |-------------| C |------- | |||
(NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ | (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ | |||
Figure 15. RPS communication between the ring nodes in case of | Figure 14. RPS communication between the ring nodes in case of | |||
no failures in the ring | no failure in the ring | |||
A destination node is a node that is adjacent to a node that | A destination node is a node that is adjacent to a node that | |||
identified a failed span. When a node that is not the destination | identified a failed span. When a node that is not the destination | |||
node receives an RPS request and it has no higher priority local | node receives an RPS request and it has no higher priority local | |||
request, it MUST transfer in the same direction the RPS request as | request, it MUST transfer in the same direction the RPS request as | |||
received. In this way, the switching nodes can maintain direct RPS | received. In this way, the switching nodes can maintain direct RPS | |||
protocol communication in the ring. | protocol communication in the ring. | |||
+---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) | +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) | |||
-------| A |-------------| B |----- X -----| C |------- | -------| A |-------------| B |----- X -----| C |------- | |||
(SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ | (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ | |||
Figure 16. RPS communication between the ring nodes in case of | Figure 15. RPS communication between the ring nodes in case of | |||
failure between nodes B and C | failure between nodes B and C | |||
Note that in the case of a bidirectional failure such as a cable cut, | Note that in the case of a bidirectional failure such as a cable cut, | |||
the two adjacent nodes detect the failure and send each other an RPS | the two adjacent nodes detect the failure and send each other an RPS | |||
request in opposite directions. | request in opposite directions. | |||
o In rings utilizing the wrapping protection. When the destination | o In rings utilizing the wrapping protection. When the destination | |||
node receives the RPS request it MUST perform the switch from/to | node receives the RPS request it MUST perform the switch from/to | |||
the working ring tunnels to/from the protection ring tunnels if it | the working ring tunnels to/from the protection ring tunnels if it | |||
has no higher priority active RPS request. | has no higher priority active RPS request. | |||
o In rings utilizing the short wrapping protection. Only the node | ||||
which is directly upstream to the failure on the working ring | ||||
tunnel perform the switch from the working ring tunnels to the | ||||
protection ring tunnels. This may be triggered by local failure | ||||
detection or the received RPS request. | ||||
o In rings utilizing the steering protection. When a ring switch is | o In rings utilizing the steering protection. When a ring switch is | |||
required, any node MUST perform the switches if its added/dropped | required, any node MUST perform the switches if its added/dropped | |||
traffic is affected by the failure. Determination of the affected | traffic is affected by the failure. Determination of the affected | |||
traffic SHOULD be performed by examining the RPS requests | traffic SHOULD be performed by examining the RPS requests | |||
(indicating the nodes adjacent to the failure or failures) and the | (indicating the nodes adjacent to the failure or failures) and the | |||
stored ring maps (indicating the relative position of the failure | stored ring maps (indicating the relative position of the failure | |||
and the added traffic destined towards that failure). | and the added traffic destined towards that failure). | |||
When the failure has cleared and the Wait-to-Restore (WTR) timer has | When the failure has cleared and the Wait-to-Restore (WTR) timer has | |||
expired, the nodes sourcing RPS requests MUST drop their respective | expired, the nodes sourcing RPS requests MUST drop their respective | |||
switches (tail end) and MUST source an RPS request carrying the NR | switches (tail end) and MUST source an RPS request carrying the NR | |||
code. The node receiving from both directions such RPS request (head | code. The node receiving from both directions such RPS request (head | |||
end) MUST drop its protection switches. | end) MUST drop its protection switches. | |||
A protection switch MUST be initiated by one of the criteria | A protection switch MUST be initiated by one of the criteria | |||
specified in Section 3.2. A failure of the RPS protocol or | specified in Section 5.2. A failure of the RPS protocol or | |||
controller MUST NOT trigger a protection switch. | controller MUST NOT trigger a protection switch. | |||
Ring switches MUST be preempted by higher priority RPS requests. For | Ring switches MUST be preempted by higher priority RPS requests. For | |||
example, consider a protection switch that is active due to a manual | example, consider a protection switch that is active due to a manual | |||
switch request on the given span, and another protection switch is | switch request on the given span, and another protection switch is | |||
required due to a failure on another span. Then an RPS request MUST | required due to a failure on another span. Then an RPS request MUST | |||
be generated, the former protection switch MUST be dropped, and the | be generated, the former protection switch MUST be dropped, and the | |||
latter protection switch established. | latter protection switch established. | |||
MSRP mechanism SHOULD support multiple protection switches in the | MSRP mechanism SHOULD support multiple protection switches in the | |||
skipping to change at page 26, line 36 ¶ | skipping to change at page 26, line 49 ¶ | |||
an RPS message. The ACH MUST NOT include the ACH TLV Header | an RPS message. The ACH MUST NOT include the ACH TLV Header | |||
[RFC5586] meaning that no ACH TLVs can be included in the message. | [RFC5586] meaning that no ACH TLVs can be included in the message. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | | |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Dest Node ID | Src Node ID | Request | Reserved | | | Dest Node ID | Src Node ID | Request | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 17. G-ACh RPS Packet Format | Figure 16. G-ACh RPS Packet Format | |||
The following fields MUST be provided: | The following fields MUST be provided: | |||
o Destination Node ID: The destination node ID MUST always be set to | o Destination Node ID: The destination node ID MUST always be set to | |||
value of the node ID of the adjacent node. The Node ID MUST be | value of the node ID of the adjacent node. The Node ID MUST be | |||
unique on each ring. Valid destination node ID values are 1-127. | unique on each ring. Valid destination node ID values are 1-127. | |||
o Source node ID: The source node ID MUST always be set to the ID | o Source node ID: The source node ID MUST always be set to the ID | |||
value of the node generating the RPS request. The Node ID MUST be | value of the node generating the RPS request. The Node ID MUST be | |||
unique on each ring. Valid source node ID values are 1-127. | unique on each ring. Valid source node ID values are 1-127. | |||
skipping to change at page 27, line 40 ¶ | skipping to change at page 27, line 51 ¶ | |||
5.1.3.1. Idle State | 5.1.3.1. Idle State | |||
A node in the idle state MUST source the NR request in both | A node in the idle state MUST source the NR request in both | |||
directions. | directions. | |||
A node in the idle state MUST terminate RPS requests flow in both | A node in the idle state MUST terminate RPS requests flow in both | |||
directions. | directions. | |||
A node in the idle state MUST block the traffic flow on protection | A node in the idle state MUST block the traffic flow on protection | |||
LSPs/tunnels in both directions. | ring tunnels in both directions. | |||
5.1.3.2. Switching State | 5.1.3.2. Switching State | |||
A node in the switching state MUST source RPS request to adjacent | A node in the switching state MUST source RPS request to adjacent | |||
node with its highest RPS request code in both directions when it | node with its highest RPS request code in both directions when it | |||
detects a failure or receives an external command. | detects a failure or receives an external command. | |||
A node in the switching state MUST terminate RPS requests flow in | A node in the switching state MUST terminate RPS requests flow in | |||
both directions. | both directions. | |||
skipping to change at page 29, line 13 ¶ | skipping to change at page 29, line 21 ¶ | |||
flow on protection ring tunnels in both directions. | flow on protection ring tunnels in both directions. | |||
5.1.4. RPS State Transitions | 5.1.4. RPS State Transitions | |||
All state transitions are triggered by an incoming RPS request | All state transitions are triggered by an incoming RPS request | |||
change, a WTR expiration, an externally initiated command, or locally | change, a WTR expiration, an externally initiated command, or locally | |||
detected MPLS-TP section failure conditions. | detected MPLS-TP section failure conditions. | |||
RPS requests due to a locally detected failure, an externally | RPS requests due to a locally detected failure, an externally | |||
initiated command, or received RPS request shall pre-empt existing | initiated command, or received RPS request shall pre-empt existing | |||
RPS requests in the prioritized order given in Section 3.1.2, unless | RPS requests in the prioritized order given in Section 5.1.2, unless | |||
the requests are allowed to coexist. | the requests are allowed to coexist. | |||
5.1.4.1. Transitions Between Idle and Pass-through States | 5.1.4.1. Transitions Between Idle and Pass-through States | |||
The transition from the idle state to pass-through state MUST be | The transition from the idle state to pass-through state MUST be | |||
triggered by a valid RPS request change, in any direction, from the | triggered by a valid RPS request change, in any direction, from the | |||
NR code to any other code, as long as the new request is not destined | NR code to any other code, as long as the new request is not destined | |||
to the node itself. Both directions move then into a pass-through | to the node itself. Both directions move then into a pass-through | |||
state, so that, traffic entering the node through the protection Ring | state, so that, traffic entering the node through the protection Ring | |||
tunnels are transferred transparently through the node. | tunnels are transferred transparently through the node. | |||
skipping to change at page 31, line 13 ¶ | skipping to change at page 31, line 26 ¶ | |||
externally initiated command | externally initiated command | |||
o The detection of an equal priority, a higher priority, or an | o The detection of an equal priority, a higher priority, or an | |||
allowed coexisting automatic initiated command | allowed coexisting automatic initiated command | |||
o The receipt of an equal, a higher priority, or an allowed | o The receipt of an equal, a higher priority, or an allowed | |||
coexisting RPS request destined to this node | coexisting RPS request destined to this node | |||
5.2. RPS State Machine | 5.2. RPS State Machine | |||
5.2.1. Initial States | 5.2.1. Switch Initiation Criteria | |||
5.2.1.1. Administrative Commands | ||||
Administrative commands can be initiated by the network operator | ||||
through the Network Management System (NMS). The operator command | ||||
may be transmitted to the appropriate node via the MPLS-TP RPS | ||||
message. | ||||
The following commands can be transferred by the RPS message: | ||||
o Lockout of Protection (LP): This command prevents any protection | ||||
activity and prevents using ring switches anywhere in the ring. | ||||
If any ring switches exist in the ring, this command causes the | ||||
switches to drop. | ||||
o Forced Switch to protection (FS): This command performs the ring | ||||
switch of normal traffic from the working entity to the protection | ||||
entity for the span between the node at which the command is | ||||
initiated and the adjacent node to which the command is directed. | ||||
This switch occurs regardless of the state of the MPLS-TP section | ||||
for the requested span, unless a higher priority switch request | ||||
exists. | ||||
o Manual Switch to protection (MS): This command performs the ring | ||||
switch of the normal traffic from the working entity to the | ||||
protection entity for the span between the node at which the | ||||
command is initiated and the adjacent node to which the command is | ||||
directed. This occurs if the MPLS-TP section for the requested | ||||
span is not satisfying an equal or higher priority switch request. | ||||
o Exercise - Ring (EXER): This command exercises ring protection | ||||
switching on the addressed span without completing the actual | ||||
switch. The command is issued and the responses (RR) are checked, | ||||
but no normal traffic is affected. | ||||
The following commands are not transferred by the RPS message: | ||||
o Clear: This command clears the administrative command and Wait-To- | ||||
Restore timer (WTR) at the node to which the command was | ||||
addressed. The node-to-node signaling after the removal of the | ||||
externally initiated commands is performed using the no-request | ||||
code (NR). | ||||
o Lockout of Working: This command prevents the normal traffic | ||||
transported over the addressed span from being switched to the | ||||
protection entity by disabling the node's capability of requesting | ||||
switch for this span in case of failure. If any normal traffic is | ||||
already switched on the protection entity, the switch is dropped. | ||||
If no other switch requests are active on the ring, the no-request | ||||
code (NR) is transmitted. This command has no impact on any other | ||||
span. If the node receives the switch request from the adjacent | ||||
node from any side it will perform the requested switch. If the | ||||
node receives the switch request addressed to the other node, it | ||||
will enter the pass-through state. | ||||
5.2.1.2. Automatically Initiated Commands | ||||
Automatically initiated commands can be initiated based on MPLS-TP | ||||
section layer OAM indication and the received switch requests. | ||||
The node can initiate the following switch requests automatically: | ||||
o Signal Fail (SF): This command is issued when the MPLS-TP section | ||||
layer OAM detects signal failure condition. | ||||
o Wait-To-Restore (WTR): This command is issued when MPLS-TP section | ||||
detects that the SF condition has cleared. It is used to maintain | ||||
the state during the WTR period unless it is pre-empted by a | ||||
higher priority switch request. The WTR time may be configured by | ||||
the operator in 1 minute steps between 0 and 12 minutes; the | ||||
default value is 5 minutes. | ||||
o Reverse Request (RR): This command is transmitted to the source | ||||
node of the received RPS message over the short path as an | ||||
acknowledgment for receiving the switch request. | ||||
5.2.2. Initial States | ||||
+-----------------------------------+----------------+ | +-----------------------------------+----------------+ | |||
| State | Signaled RPS | | | State | Signaled RPS | | |||
+-----------------------------------+----------------+ | +-----------------------------------+----------------+ | |||
| A | Idle | NR | | | A | Idle | NR | | |||
| | Working: no switch | | | | | Working: no switch | | | |||
| | Protection: no switch | | | | | Protection: no switch | | | |||
+-----+-----------------------------+----------------+ | +-----+-----------------------------+----------------+ | |||
| B | Pass-trough | N/A | | | B | Pass-trough | N/A | | |||
| | Working: no switch | | | | | Working: no switch | | | |||
| | Protection: pass through | | | | | Protection: pass through | | | |||
skipping to change at page 32, line 44 ¶ | skipping to change at page 34, line 5 ¶ | |||
+-----+-----------------------------+----------------+ | +-----+-----------------------------+----------------+ | |||
| H | Switching - WTR | WTR | | | H | Switching - WTR | WTR | | |||
| | Working: switched | | | | | Working: switched | | | |||
| | Protection: switched | | | | | Protection: switched | | | |||
+-----+-----------------------------+----------------+ | +-----+-----------------------------+----------------+ | |||
| I | Switching - EXER | EXER | | | I | Switching - EXER | EXER | | |||
| | Working: no switch | | | | | Working: no switch | | | |||
| | Protection: no switch | | | | | Protection: no switch | | | |||
+-----+-----------------------------+----------------+ | +-----+-----------------------------+----------------+ | |||
5.2.2. State transitions When Local Request is Applied | 5.2.3. State transitions When Local Request is Applied | |||
In the state description below 'O' means that new local request will | In the state description below 'O' means that new local request will | |||
be rejected because of exiting request. | be rejected because of exiting request. | |||
===================================================================== | ===================================================================== | |||
Initial state New request New state | Initial state New request New state | |||
------------- ----------- --------- | ------------- ----------- --------- | |||
A (Idle) LP C (Switching - LP) | A (Idle) LP C (Switching - LP) | |||
LW D (Idle - LW) | LW D (Idle - LW) | |||
FS E (Switching - FS) | FS E (Switching - FS) | |||
skipping to change at page 36, line 11 ¶ | skipping to change at page 37, line 20 ¶ | |||
FS E (Switching - FS) | FS E (Switching - FS) | |||
SF F (Switching - SF) | SF F (Switching - SF) | |||
Recover from SF N/A | Recover from SF N/A | |||
MS G (Switching - MS) | MS G (Switching - MS) | |||
Clear A | Clear A | |||
WTR expires N/A | WTR expires N/A | |||
EXER N/A - if on the same span | EXER N/A - if on the same span | |||
I (Switching - EXER) | I (Switching - EXER) | |||
===================================================================== | ===================================================================== | |||
5.2.3. State Transitions When Remote Request is Applied | 5.2.4. State Transitions When Remote Request is Applied | |||
The priority of a remote request does not depend on the side from | The priority of a remote request does not depend on the side from | |||
which the request is received. | which the request is received. | |||
===================================================================== | ===================================================================== | |||
Initial state New request New state | Initial state New request New state | |||
------------- ----------- --------- | ------------- ----------- --------- | |||
A (Idle) LP C (Switching - LP) | A (Idle) LP C (Switching - LP) | |||
FS E (Switching - FS) | FS E (Switching - FS) | |||
SF F (Switching - SF) | SF F (Switching - SF) | |||
skipping to change at page 39, line 5 ¶ | skipping to change at page 40, line 8 ¶ | |||
I (Switching - EXER) LP C (Switching - LP) | I (Switching - EXER) LP C (Switching - LP) | |||
FS E (Switching - FS) | FS E (Switching - FS) | |||
SF F (Switching - SF) | SF F (Switching - SF) | |||
MS G (Switching - MS) | MS G (Switching - MS) | |||
WTR N/A | WTR N/A | |||
EXER I (Switching - EXER) | EXER I (Switching - EXER) | |||
RR I (Switching - EXER) | RR I (Switching - EXER) | |||
NR N/A | NR N/A | |||
===================================================================== | ===================================================================== | |||
5.2.4. State Transitions When Request Addresses to Another Node is | 5.2.5. State Transitions When Request Addresses to Another Node is | |||
Received | Received | |||
The priority of a remote request does not depend on the side from | The priority of a remote request does not depend on the side from | |||
which the request is received. | which the request is received. | |||
===================================================================== | ===================================================================== | |||
Initial state New request New state | Initial state New request New state | |||
------------- ----------- --------- | ------------- ----------- --------- | |||
A (Idle) LP B (Pass-trough) | A (Idle) LP B (Pass-trough) | |||
FS B (Pass-trough) | FS B (Pass-trough) | |||
End of changes. 68 change blocks. | ||||
239 lines changed or deleted | 348 lines changed or added | |||
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |