Network Working Group WQ. Cheng
Internet-Draft L. Wang
Intended status: Informational H. Li
Expires: April 18, 2013 China Mobile
K. Liu
J. He
Huawei Technologies Co., Ltd.
F. Li
Research Institute of
Telecommunication
Transmission,China Academy of
Telecommunication Research,
MIIT. China
J. Yang
ZTE Corporation P.R.China
J. Wang
Fiberhome Telecommunication
Technologies Co.,LTD
October 15, 2012
MPLS-TP Shared Ring protection (MSRP) mechanism
draft-cheng-mpls-tp-shared-ring-protection-00
Abstract
This document describes requirements and solutions for MPLS-TP Shared
ring protection (MSRP) in ring topology for point to point (P2P)
services. The mechanisms of MSRP are illustrated and analyzed how to
satisfy the MPLS-TP requirements in RFC5654 for optimized ring
protection. MSRP could support wrapping and steering protection
mechanisms for P2P services, which provide a simple and reliable
protection switching. The survivability of the network could be
improved and the operation and maintain could be more easy. Ring
protection solution for p2mp services will be documented in another
draft latterly.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
Cheng, et al. Expires April 18, 2013 [Page 1]
Internet-Draft MSRP October 2012
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cheng, et al. Expires April 18, 2013 [Page 2]
Internet-Draft MSRP October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Recovery for Multiple failures . . . . . . . . . . . . 4
1.1.2. Upgrade from linear protection to ring protection . . 5
1.1.3. Configuration complexity . . . . . . . . . . . . . . . 5
1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6
2. Shared ring protection for P2P . . . . . . . . . . . . . . . . 6
2.1. Basic conception . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. The establishment of the Ring tunnels . . . . . . . . 7
2.1.2. The distribution and management of ring labels . . . . 8
2.1.3. Failure detection . . . . . . . . . . . . . . . . . . 9
2.2. P2P wrapping . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Wrapping Link Failure . . . . . . . . . . . . . . . . 10
2.2.2. Wrapping node Failure . . . . . . . . . . . . . . . . 11
2.3. P2P steering . . . . . . . . . . . . . . . . . . . . . . . 11
3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 14
4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Cheng, et al. Expires April 18, 2013 [Page 3]
Internet-Draft MSRP October 2012
1. Introduction
As described in 2.5.6.1. Ring Protection of MPLS-TP requirements
[RFC5654], several service providers have expressed a high level of
interest in operating MPLS-TP in ring topologies and require a high
level of survivability function in these topologies. MPLS-TP
networks are often constructed with ring topologies which allow
service providers setting up a efficient and optimized ring
protection mechanism to achieve simplified operation and fast
recovery performance.
The requirements for MPLS-TP [RFC5654] state that recovery mechanisms
are optimized for Ring topologies may be developed if it can provide
following optimization scenarios:
a. Minimize the number of OAM entities for protection
b. Minimize the number of elements of recovery
c. Minimize the number of labels required
d. Minimize the amount of control and management-plane transactions
e. Minimize the impact on information exchange if control plane
supported
This document specifies MPLS-TP Shared-Ring Protection mechanisms
which can meet all those requirements on Ring protection listed in
[RFC5654].
This document focus on the solutions for Point-to-point transport
path and a related topic in [RFC5654] states the required support for
point-to-multipoint transport path. The solution for point-to-
multipoint solution is under evaluation and will be illustrated in a
separate document based on the basic conception in this document.
1.1. Problem statement
1.1.1. Recovery for Multiple failures
MPLS-TP is expected to be used in carrier grade metro networks and
backbone networks for providing mobile backhauling, business
customers' services and etc., in such kind of application scenarios
the network survivability are very important.
According to R106 B in RFC5654, MPLS-TP recovery mechanisms in a ring
SHOULD protect against multiple failures. It's expected deploying
ring protection in ring topology could enhance the network
Cheng, et al. Expires April 18, 2013 [Page 4]
Internet-Draft MSRP October 2012
survivability to against multiple failures in many cases. Following
context provide some more detail illustration to "multiple failures".
In metro and backbone networks, the single risk factor often affects
multiple links or nodes. Some examples of risk factors are given in
follows:
- multiple links using fibers in one cable or pipeline
- Several nodes shared one power supply system
- weather sensitive micro-wave system
Once one risk factor happens, multiple near-simultaneous links or
nodes failures occur and those failed links or nodes may locate on
single ring as well as on interconnected multiple rings. The ability
of ring protecting against multiple failures should cover both
multiple failures on single ring scenario and multiple failures on
interconnected multiple rings.
1.1.2. Upgrade from linear protection to ring protection
It is beneficial for service providers to upgrade their MPLS-TP based
network from the linear protection to ring protection without service
interruption, and supporting in-service insertion and removal of a
node on the ring. In order to realize this requirement, the ring
protection Mechanisms should be developed and optimized to comply
with this upgrading principle.
1.1.3. Configuration complexity
In the application scenarios of deploying linear protection in
MPLS-TP network, the configuration of protection has close
relationship with the services, LSP quantities. Especially in some
large metro networks with more than ten thousands of services access
node, the LSP linear protection capabilities of the metro core nodes
should be large enough to meet the network planning requirements,
which also leads to the complexity of network protection
configurations and operations. While the ring protection is based on
the mechanisms on section layer, it has loose relationship with the
services quantities which could simplify the network protection
configurations and operations.
1.2. Terminology and Notation
The following syntax will be used to describe the contents of the
label stack:
Cheng, et al. Expires April 18, 2013 [Page 5]
Internet-Draft MSRP October 2012
1. The label stack will be enclosed in square brackets ("[]").
2. Each level in the stack will be separated by the '|' character.
It should be noted that the label stack may contain additional levels
however, we only present the levels that are germane to the
protection mechanism.
3. If the Label is assigned by Node x, the Node Name will enclosed
in bracket(" ()")
1.3. Contributing Authors
Wen Ye(China Mobile)
2. Shared ring protection for P2P
None
2.1. Basic conception
This document introduces an independent logic layer of ring for both
working path and protection path for shared ring protection in
MPLS-TP networks. The logic layer is a ring tunnel on top of the
working path or the protection path as shown in Figure 1, namely
working ring tunnel or protection ring tunnel respectively. 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, while one ring tunnel can carry
several LSPs.
|-------------
|-------------|
|-------------| |
=====PW1======| | |
| | Ring | Physical
=====PW2======| LSP | Tunnel | Port
| | |
=====PW3======| | |
|-------------| |
|-------------|
|-------------
Figure 1 the logic layers of the ring
The label stack used in MPLS-TP Shared Ring Protection mechanism are
shown as below.
Cheng, et al. Expires April 18, 2013 [Page 6]
Internet-Draft MSRP October 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Label Stack used in MPLS-TP Shared Ring Protection
2.1.1. The establishment of the Ring tunnels
A ring tunnel is created as per exit node. The exit node means the
node on the ring where the traffic leaves the ring. All the LSPs
which transverse the ring and exit at the same ring node share the
same working ring tunnels and protection ring tunnels. For each exit
node, 4 ring tunnels are established:
- 1 clockwise working ring tunnel, protected by
- 1 anticlockwise protection ring tunnel,
- 1 anticlockwise working ring tunnel, protected by
- 1 clockwise protection ring tunnel.
An example is shown in Figure 3 where Node D behaves as an exit node.
LSP 1 entering the ring at Node E, LSP2 at Node A and LSP 3 at Node
B, all leave the ring at Node D. . To protect these LSPs traversing
the ring, a clockwise working ring tunnel (RcW_D), E->F->A->B->C->D
and its protection ring tunnel in the reverse direction (RaP_D),
D->C->B->A->F->E->D ; Ananticlockwise working ring channel (RaW_D),
C->B->A->F->E->D and its clockwise protection ring tunnel (RcP_D),
D->E->F->A->B->C->D are established for Node D. Figure 3 only shows
RcW_D and RaP_D for readability. The similar provisioning should be
repeated for every other node on the ring. The ring tunnels created
for the other nodes in Figure 3 when acting as exit node are provided
as follows:
To Node A: RcW_A, RaW_A, RcP_A, RaP_A;
To Node B: RcW_B, RaW_B, RcP_B, RaP_B;
To Node C: RcW_C, RaW_C, RcP_C, RaP_C;
To Node E: RcW_E, RaW_E, RcP_E, RaP_E;
Cheng, et al. Expires April 18, 2013 [Page 7]
Internet-Draft MSRP October 2012
To Node F: RcW_F, RaW_F, RcP_F, RaP_F;
In Node D, two working ring tunnels, RcW_D and RaW_D are terminated;
and two protection ring tunnels, RcP_D and RaP_D, are transit. That
means through those working ring tunnels with protection ring
tunnels, LSPs which enter the ring from Node D can reach any other
nodes on the ring, while Node D can also receive the traffic from any
other nodes.
+---+#############+---+
| F |-------------| A | +-- LSP2
+---+*************+---+
#/* *\#
#/* *\#
#/* *\#
+---+ +---+
LSP1-+ | E | | B |+-- LSP3
+---+ +---+
#\ */#
#\ */#
#\ */#
+---+*************+---+
LSP1 +--| D |-------------| C |
LSP2 +---+#############+---+
LSP3
---- physical links
**** RcW_D
#### RaP_D
Figure 3 the Ring tunnels of the ring
2.1.2. The distribution and management of ring labels
Ring tunnel labels are distributed by means of downstream-assigned
mechanism as defined in [RFC3031]. When an MPLS-TP transport path,
e.g. LSP, enters the ring, according to the ring ID and the exit
node, the ingress node pushes the working ring tunnel label and sends
the traffic to the next hop; The transit nodes of the working ring
tunnel swap the ring tunnel label and forward the packets to the next
hop; When arriving at the egress node, the egress node pops the ring
tunnel label and forwards the packets based on the inner LSP label
and PW label.Figure 4 shows the label operation in MPLS-TP Shared
Ring Protection mechanism. Suppose LSP 1 enters the ring at Node A
and exit at Node D, the following label operations are executed.
1. The traffic LSP1 arrives at Node A with a label stack [LSP1] and
Cheng, et al. Expires April 18, 2013 [Page 8]
Internet-Draft MSRP October 2012
is supposed to be forwarded in the clockwise direction of the ring.
The clockwise working ring tunnel label RcW_D will be pushed at Node
A, the label stack for the forwarded packet at Node A is changed to
[RcW_D(B)|LSP1]
2．Transit nodes, in this case Node B and C, forward the packet
by swapping the working ring tunnel label. For Example, the label
[RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node B.
3. When the packet arrives at Node D (i.e. egress node) with label
stack [RcW_D(D)|LSP1], Node D Pops RcW_D(D) and further deals with
the inner labels of LSP1.
4. All the LSPs exit at the same node share the same Ring tunnel
label.
+---+#####[RaP_D(A)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(F)]#/*[RcW_D(F)] RcW_D(B)]*\#RaP_D(B)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ */#
[RaP_D(D)]#\ [RxW_D(C)]*/#RaP_D(C)
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links ****** RcW_D ###### RaP_D
Figure 4 Label operation of the ring
2.1.3. Failure detection
The MPLS-TP section layer OAM is used to monitor the connectivity
between each two adjacent nodes on the ring using the mechanisms
defined in [RFC6371].Protection switching occurs on the detection of
failure on a link in the ring monitored by OAM functions.
Two end ports of a link form a MEG, and an MEG end point (MEP)
function is installed in each ring port. Periodic CC-V OAM packets
exchange is activated between each pair of MEPs to monitor the link
Cheng, et al. Expires April 18, 2013 [Page 9]
Internet-Draft MSRP October 2012
health. Sequential consecutive loss of CC-V packets (3 packets) is
interpreted as a link failure.
A node failure is regarded as the failure of two links attached to
the node. The two nodes adjacent to the failed node detect the
failure on the links connected to the failed node.
2.2. P2P wrapping
Normal state is shown in Figure 4. The clockwise LSP1 towards node D
enters the ring at Node A. In normal state, LSP 1 follows the path
A->B->C-D, label operation is [LSP1](original data traffic carried by
LSP 1)->[RCW_D(B)|LSP1](NodeA)->[RCW_D(C)|LSP1](NodeB)->[RCW_D(D)|
LSP1](NodeC)->[LSP1]( data traffic carried by LSP 1). Then traffic
packet will be forwarded on the basis of LSP1.
2.2.1. Wrapping Link Failure
When a link failure between Node B and Node C occurrs, both Node B
and Node C detect the failure by OAM mechanism. Node B switches the
clockwise working ring tunnel(RcW_D) to the anticlockwise protection
ring tunnel (RaP_D)and Node C switches anticlockwise protection ring
tunnel(RaP_D) to the clockwisework ring tunnel(RcW_D). The data
traffic which enters the ring at Node A and exits at Node D follows
the pathA->B->A->F->E->D->C->D. The label operation is
[LSP1](Original data packet)-> [RcW_D(B)|LSP1](NodeA)-> [RaP_D(A)|
LSP1](NodeB)->[RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1] (NodeF)->
[RaP_D(D)|LSP1] (NodeE)-> [RaP_D(C)|LSP1] (NodeD)-> [RcW_D(D)|
LSP1](NodeC)->[LSP1](Exit data packet).
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links xxxx Failure Link
Cheng, et al. Expires April 18, 2013 [Page 10]
Internet-Draft MSRP October 2012
****** RcW_D ###### RaP_D
Figure 5 Link Failure of P2P Wrapping
2.2.2. Wrapping node Failure
When Node B fails, Node A detects the failure between A and B and
switches the clockwise work ring tunnel(RcW_D) to the anticlockwise
protection ring tunnel(RaP_D), Node C detects the failure between C
and B and switches the anticlockwise protection ring tunnel(RaP_D) to
the clockwise working ring tunnel(RcW_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 [LSP1](original data traffic
carried by LSP 1)-> [RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->
[RaP_D(D)|LSP1](NodeE)-> [RaP_D(C)|LSP1] (NodeD)->[RcW_D(D)|LSP1]
(NodeC)->[LSP1](data traffic carried by LSP 1).
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ xxxxx
| E | x B x
+---+ xxxxx
#\ */#
[RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B)
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links xxxxxx Failure Node
*****RcW_D ###### RaP_D
Figure 6 Node Failure of P2P Wrapping
2.3. P2P steering
Each working ring tunnel is associated with a protection ring tunnel
in the opposite direction. Every node needs to know the ring
topology by configuration or topology discovery. When the failure
occurs, the nodes which detect the failure will spread the fault
information in the opposite direction node by node in the ring
respectively. When the node receives the message that informs the
Cheng, et al. Expires April 18, 2013 [Page 11]
Internet-Draft MSRP October 2012
failure, it will quickly figure out the location of the fault by the
topology information that is maintained by itself, so that it will
determine whether the LSPs enter the ring from itself needs switch-
over. If yes, it will switch the LSPs from the working ring tunnel
to its protection ring tunnel. If no, it will ignore the fault
indication message.
+--LSP l
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---+ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+
|I|I|I|S|I|I| |I|I|S|I|I|I|
+-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+
[RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)]
#/* [RcW_D(F)] *\#
+-+-+-+-+-+-+-+ #/* *\#
|E|F|A|B|C|D|E| +---+ +---+ +-- LSP 2
+-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+
|I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B|
+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
#\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I|
[RaP_D(D)] #\* */# +-+-+-+-+-+-+
#\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ LSP 1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+
|I|I|I|I|I|S| LSP 2 |S|I|I|I|I|I|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
----- physical links ***** RcW_D ##### RaP_D
Figure 7 the P2P steering operation and protection switching(1)
Steering Example is shown in figure 7. LSP1 enters the ring from
Node A while Node B has an LSP2, and both of them have the same
destination node D. As per Figure 7, in normal state, LSP1 follows
the path A->B->C->D, the label operation is [LSP1](original data
traffic carried by LSP 1 )->[RcW_D(B)|LSP1](NodeA)->[RcW_D(C)|
LSP1](NodeB)->[RcW_D(D)|LSP1](NodeC)->[LSP1] ( data traffic carried
by LSP 1) . LSP2 goes through the path B->C->D, the label operation
is [LSP2]->[RcW_D(C)|LSP2](NodeB)->[RcW_D(D)|LSP2](NodeC)-> [LSP2] (
data traffic carried by LSP 1) .
If the link between C and D breaks down, as Figure 7 shows, according
to the fault detection function of each link, Node D will find out
that there is a failure in the link between C and D, and it will
Cheng, et al. Expires April 18, 2013 [Page 12]
Internet-Draft MSRP October 2012
update the link state of its ring topology, changing the link state
between C and D from normal to fault, as Figure 7 shows. In the
direction that goes away from the failure point, Node D will send the
state report message to Node E, informing Node E of the fault between
C and D, and E will update the link state of its ring topology,
changing the link state between C and D from normal to fault. And
the like, the state report message is sent from node to node in the
clockwise direction.Similar to Node D, Node C will spread the failure
information in anti-clockwise direction.
Until Node A updates the link state of its ring topology, and knows
there is a fault within its working path. And at the same time it
can get the conclusion that the anticlockwise path from A to D is
working all right. so that Node A will switch the LSP1 operation to
the anticlockwise tunnel.
LSP1 will follow the path A->F->E->D, the label operation is
[LSP1](original data traffic carried by LSP 1 )->[RaP_D(F)|
LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->[RaP_D(D)|LSP1](NodeE)->[LSP1]
( data traffic carried by LSP 1).
The same goes with LSP2 operation, when Node B updates the link state
of its ring topology, and find out the working path fault, so it will
stop sending the LSP2 operation in clockwise direction and switch the
LSP2 to the anticlockwise protection tunnel. LSP2 goes through the
path B->A->F->E->D, the label operation is [LSP2](original data
traffic carried by LSP 2 )-> [RaP_D(A)|LSP2](NodeB)->[RaP_D(F)|
LSP2](NodeA)->[RaP_D(E)|LSP2](NodeF)->[RaP_D(D)|LSP2](NodeE)->[LSP2]
( data traffic carried by LSP 2).
Imagine the ring between A and B breaks down, as figure 8 shows.
Like above, Node B will find out that there is a fault in the link
between A and B, and it will update the link state of its ring
topology, changing the link state between A and B from normal to
fault. The state report message is sent from node to node in the
clockwise direction, informing every node that there is a fault
between node A and B, so that every node updates the link state of
its ring topology. Node A will find out the working path fault of
LSP1 and switch LSP1 to protection Ring tunnel, while Node B finds
out the LSP2 working path is all right and there is no need for
switching.
Cheng, et al. Expires April 18, 2013 [Page 13]
Internet-Draft MSRP October 2012
+-- LSP l
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---+ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+
|I|S|I|I|I|I| #/* x |S|I|I|I|I|I|
+-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+
[RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)]
#/* x +-- LSP 2
+-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+
|E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B|
+-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+
|I|I|S|I|I|I| #\* */# |I|I|I|I|I|S|
+-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+
[RaP_D(D)] #\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+
|I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I|
+-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+
----- physical links ***** RcW_D ##### RaP_D
Figure 8 the P2P steering operation and protection switching(2)
3. Coordination protocol
TBD
4. Conclusions and Recommendations
TBD
5. IANA Considerations
None
6. Security Considerations
TBD
Cheng, et al. Expires April 18, 2013 [Page 14]
Internet-Draft MSRP October 2012
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
Authors' Addresses
Weiqiang Cheng
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: chengweiqiang@chinamobile.com
Lei Wang
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: Wangleiyj@chinamobile.com
Han Li
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: Lihan@chinamobile.com
Cheng, et al. Expires April 18, 2013 [Page 15]
Internet-Draft MSRP October 2012
Kai Liu
Huawei Technologies Co., Ltd.
Huawei base, Bantian, Longgang District
Shenzhen 518129
China
Email: alex.liukai@huawei.com
Jia He
Huawei Technologies Co., Ltd.
Huawei base, Bantian, Longgang District
Shenzhen 518129
China
Email: hejia@huawei.com
Fang Li
Research Institute of Telecommunication Transmission,China Academy of Telecommunication Research, MIIT. China
Number 52, Huayuan street, Haidian District
Shenzhen 100191
China
Email: lifang@ritt.cn
Jian Yang
ZTE Corporation P.R.China
ZTE Industrial Zone,Liuxian Road, Xili District, Shenzhen
Shenzhen 518055
China
Email: yang.jian90@zte.com.cn
Junfang Wang
Fiberhome Telecommunication Technologies Co.,LTD
No.5, Dongxin Lu, Guandong Industrial Park, Wuhan, Hubei
Wuhan 430073
China
Email: wjf@fiberhome.com.cn
Cheng, et al. Expires April 18, 2013 [Page 16]