MPLS-TP Shared Ring protection (MSRP) mechanism

MPLS-TP Shared Ring Protection
(MSRP) Mechanism
draft-cheng-mpls-tp-shared-ring-protection-02
IETF 90th , July 21- 25, 2014
Presenter :
Weiqiang Cheng(CMCC)
Authors:
Weiqiang Cheng, Lei Wang, Han Li (CMCC)
H. van Helvoort ,Kai Liu, Jia He (Huawei Technologies Co., Ltd.)
Fang Li (CATR)
Jian Yang (ZTE)
Junfang Wang (Fiberhome)
Why Need Ring protection solution
 Ring topology is deployed worldwide, which can use minimized fiber resource to
provide physical two tours.
 Traditional transport networks (such as SDH) are constructed with ring topology, so
that network infrastructure such as fiber/power supply/machine rooms are deployed
for ring topology.
 Maintenance engineers are familiar with ring topology based operation.
10GE
10GE
GE
SGW/MME
RNC/BSC
Access layer
Access links
•TDM/IMA E1
•cSTM-1
•FE、GE
Aggregation layer
Core layer
PW/LSP
The link of access layer
•GE
The link of aggregation
layer : 10GE
Service link
The link of corn layer
•cSTM-1
•10GE
•GE
•10GE
CMCC PTN network architecture
Requirements of the Ring protection
 “Multiple failures” recovery
Multiple links or nodes failures are caused by single event, Such as:
 Multiple links of rings are using fibers in one cable or pipeline, and which is cut off
 network migration/network cutover in different rings at the same time
Ring protection should cover following possible failures scenarios
 Multiple failures in single ring
 Multiple failures in connected rings



Simplify configuration and maintenance
 protection configurations should be independent of service number
 Minimize the management elements
Simplify the hardware requirements
 Minimize the number of OAM entities
 Minimize the number of elements of recovery
 Minimize the number of labels required
Linear protection using in field, operators require smooth migration from linear protection to ring
protection without service impacted.
 Simple Wrapping solution required
“Ring tunnel ” in MSRP
• A logical ring tunnel is introduced for both working LSP and protection LSP
– to minimize the number of labels for protection paths,
– to minimize the number of recovery elements in the network, and
– to optimize the number of control and management transactions necessary,.
• Once the ring tunnel is established , the configuration, management and
protection of the ring are all based on the ring tunnel.
– One port can carry more than one ring tunnel;
– One ring tunnel can carry several LSPs.
PW 1
PW 2
LSP
Ring tunnel
PW 3
The logic ring tunnel in MSRP
Port
Ring tunnel label
LSP label
PW label
Payload
Label stack used in MSRP
Why need wrapping ring protection
Ring1
A
F
D
B
Ring2
C
E
interconnected ring protection scenarios
•
•
•
Steering ring protection is hard to meet interconnected ring topology recovery requirement.
When failure occurred as the figure show above, Steering ring protection need to notify
failure information and topology to source node(as Node B). It need to introduce complex
protocols.
When using wrapping ring protection, the switching action only execute in failure detected
node(as Node D). It is simple to implement in the network devices then steering ring
protection.
SDH networks often using MSP wrapping protection to improve network survivability.
Scope
• Differences from version 01
– RPS protocols is added
• Differences from version 00
– short wrapping is added as an optimized wrapping solution
• to improve latency and bandwidth efficiency in some cases (e.g.
the destination/exit node is far from the defect)
– an interconnected ring protection mechanism is added
• To recover from interconnection node failure.
RPS Protocols communication
B->C(NR)
A->B(NR)
A
B->A(NR)
B
C->B(NR)
F->E(NR)
F
E->F(NR)

A
C->B(SF)
E
D->E(NR)
B->C(SF)
B
D
F
C->B(SF)
B->C(SF)
C
B->C(SF)
B->C(SF)
B->C(SF)
E->D(NR)
RPS communication
(No Failure in the rings)

C
D->C(NR) C->D(NR)
F->A(NR) A->F(NR)
C->B(SF)
C->B(SF)
C->B(SF)
B->C(SF)
E
C->B(SF)
D
RPS communication
(failure between nodes B and C)
When no protection switches are active on the ring: Each node MUST dispatch periodically RPS requests to
the two adjacent nodes, indicating No Request (NR);
When a node determines that a protection switching is required: it MUST send the appropriate RPS
request in both directions; 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 node receives an RPS request and it has no higher priority
local request, it MUST transfer the RPS request as received;
Ring node RPS states
 Idle state :
 A node is in the idle state when it has no RPS request and is sourcing and receiving NR
code to/from both directions.
 Each node in Idle State MUST dispatch periodically RPS requests to the two adjacent
nodes, indicating No Request (NR);
 Switching state :
 A node not in the idle or pass-through states is in the switching state.
 A node in the switching state MUST source RPS request to adjacent node with its highest
RPS request code in both directions when it detects a failure or receives an external
command.
 A node in the switching state MUST terminate RPS requests flow in both directions.
for all protection switch requests, except EXER and LP, the node in switching state MUST
execute the switch.
 Pass-through state :
 A node is in the pass-through state when its highest priority RPS request is a request not
destined to or sourced by it.
RPS Protocols messages
 The MSRP protection operation MUST be controlled with the help of the
Ring Protection Switch Protocol(RPS). The RPS messages SHALL be sent
over the G-ACh as described in [RFC5586].
 RPS is dedicated to Ring protection and it requires a new A-Ch channel
type.
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 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
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Destination Node ID: The destination node ID MUST always be set to
value of a node ID of the adjacent node. Valid destination node ID values
are 1-127.
 Source node ID: The source node ID MUST always be set to the value of
the node ID generating the APS request. Valid source node ID values are
1-127.
 RPS request code: A code consisting of four bits which carry RPS requests;
Scope
• Differences from version 01
– RPS protocols is added
• Differences from version 00
– short wrapping is added as an optimized wrapping solution
• to improve latency and bandwidth efficiency in some cases (e.g.
the destination/exit node is far from the defect)
– an interconnected ring protection mechanism is added
• To recover from interconnection node failure.
P2P short wrapping solution
Short Wrapping path
Wrapping path
Tunnel1
Node F
Node A
Node B
physical links
RcW
RaW
Node E
Node D
Protection ring tunnel will poped
at ring destination node when
using short wrapping
wrapping path
Node C
RcP
RaP
Tunnel1
Short wrapping path
Short Wrapping v.s Wrapping (Node D as an exit node )
•
•
Wrapping: Protection switching happens at neighbouring nodes of the failure (Service is received from the working path at
the exit node) . See the black line in the figure.
Short Wrapping: Protection switching occurs at the up-stream neighboring node of the failure and the exit node (Service is
received from the protection path at the exit node).
Interconnected ring protection mechanism
 Interconnected rings will be regarded as two independent rings. Each ring runs protection
switching independently. Failure in one ring only triggers protection switching in itself and
does not affect the other ring.
 For protected interconnection node in dual-node interconnected ring, the service LSPs in the
interconnection nodes should use the same Forword table. So either interconnection node
can process service LSP if another node failure.
 Two interconnection nodes can be managed as a virtual interconnection node group. Each
ring assigns ring tunnels to the virtual interconnection node group. The interconnection
nodes in the group should terminate the same interconnected ring tunnels. Ring tunnels to
the virtual interconnection node group will be established by each rings :
– one clockwise working ring tunnel to the virtual interconnection node group;
– one anticlockwise protection ring tunnel to the virtual interconnection node group,
– one anticlockwise working ring tunnel to the virtual interconnection node group;
– one clockwise protection ring tunnel to the virtual interconnection node group.
These ring tunnel will terminated at all nodes in virtual interconnection node group.
Recovery from Interconnection node failure
1.
2.
3.
Pop Ring1 tunnel label
Switch traffic runnel label
Push ring2 tunnnel label
Tunnel1(D&E)
Tunnel1(H)
RcW_D&E(D&E)
RcW_H(F)
Node A
Node D
Node F
Tunnel1(D&E)
Tunnel1(D&E)
RcW_D&E(A)
Rap_D&E(B)
Tunnel1(in)
Node B
Ring1
Ring2
Node G
Tunnel1(D&E)
push Ring1 tunnel Label
Rap_D&E(C)
Tunnel1(D&E)
Tunnel1(H)
Rap_D&E(D&E))
Rap_H (H)
Node C
Node E
Node H
Tunnel1(out)
1.
2.
3.
pop Ring2 tunnel Label
Pop Ring1 tunnel label
Switch traffic runnel label
Push ring2 tunnnel label
Recovery from Interconnetcion node failure (Node D failure)
① NodeD and NodeE should deal with the same traffic LSP label. Tunnel1 will process correctly in any
node of NodeD and NodeE;
Next Step
• Any enhancement based on the feedbacks
from the group