Internet DRAFT - draft-liu-mpls-tp-ring-protection-switching
draft-liu-mpls-tp-ring-protection-switching
MPLS Working Group G. Liu
Internet-Draft ZTE Corporation
Intended status: Standards Track Y. Ji
Expires: June 17, 2012 BUPT University
j. Yu
ZTE Corporation
December 15, 2011
Multiprotocol Label Switching Transport Profile Ring Protection
draft-liu-mpls-tp-ring-protection-switching-00
Abstract
according to RFC 5654 MPLS-TP Requirement, there is a paragraph for
recovery requirements just as section 2.5.6.1 in RFC5654 describles:
within the context of recovery in MPLS-TP networks,the optimization
criteria considered in ring topologies are as follows: 1 minimize the
number of OAM entities that are needed to trigger the recovery
operation; 2 Minimize the number of elements of recovery in the ring;
3 Minimize the number of labels required for the protection paths
across the ring; 4 minimize the amount of control and management
plane transactions during maintenance operation. this document will
describle two types of ring protection solutions to implement these
requirements.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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
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 June 17, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Liu, et al. Expires June 17, 2012 [Page 1]
Internet-Draft MPLS-TP ring protection December 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. proposed ring protection solution . . . . . . . . . . . . . . 4
3.1. solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. P2P Instance . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. P2MP Instance . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Liu, et al. Expires June 17, 2012 [Page 2]
Internet-Draft MPLS-TP ring protection December 2011
1. Introduction
this draft mainly describes two ring protection solutions, solution 1
will use one protecting SPME to protect one working SPME when there
is a defect on the working SPME. while solution 2 will use one
protecting LSP to protect one working LSP.They are similar to 1:1
linear protection. but the difference is the first solution may
protect many LSP working paths of one SPME. and the second one may
just protect one working LSP path.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
OAM: Operations, Administration, Maintenance
LSP: Label Switched Path.
TLV: Type Length Value
LSR:Label Switching Router
P2MP:Point to Multi-Point
P2P:Point to Point
APS:Automatic Protection Switch
PSC:Protection Switching Coordination
SD:Signal Degrade
SF:Signal Fail
BFD:Bidirectional Forward Detection
MPLS:Multi-Protocol Label Switching
MPLS-TP:Multi-Protocol Label Switching Transport Profile
TTSI:Trail Termination Source Identifier_source LER ID+LSP ID
MEP:MEG End Point
LER: Label Edge Router
Liu, et al. Expires June 17, 2012 [Page 3]
Internet-Draft MPLS-TP ring protection December 2011
CC&CV: Check continuity and connectivity verification
SPME: Sub-Path maintenace entity
3. proposed ring protection solution
this section mainly proposed two types of ring protection
solution.the two ring protection solutions need to detect and notify
the defect by OAM and APS functions,so that the source node of
working SPME and LSP path will switch these protected services into
protecting SPME and LSP path.but the two ring protection solutions
also have a few differences. solution 1 provides recovery of all LSP
services of a defective working SPME by protecting SPME ,while
another solution just provides one dedicate protecting path for each
working LSP path.
3.1. solution 1
This ring protection solution in MPLS-TP network mainly use
protecting SPME to protect working SPME .firstly two transfer nodes
will be selected in the ring. and the two transfer nodes would backup
for each other to ensure to transport service under the condition
that one prime transfer node has failure.other nodes in the ring need
to set up two bidirectional SPME separately in the direction of
clockwise and anticlockwise along the ring to the two transfer nodes
; and use CC or CV packet to detect defect on each SPME.
when an end point of a working SPME detects a defect on its own SPME
, it will generate a State notify message (PSC) to be sent to another
end point of the SPME. so that the two end point can coordinate the
switch state. and the frame format of the state notify message is the
following 1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0001| 0000 | 00000000 | channel type (PSC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PSC Control packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
when another end point of the SPME received State Notify messgae from
Liu, et al. Expires June 17, 2012 [Page 4]
Internet-Draft MPLS-TP ring protection December 2011
peer end point, it would process the message and switch to its
relative protecting SPME to transport all LSP Services of the
defective working SPME. for example, there is the following ring
including point A ,B, C,D,E and F .Point A and D are configured as
two transfer nodes separately in the ring.while working and
protecting SPME will be set up between the two transfer nodes A and D
and other nodes include B,C,D,E,F.it will need to set up 16 SPME in
the ring. Just as C node, there need to set up four bidirectional
SPME,which are separately working SPME(A-B-C) identified by signal
(@) and protecting SPME ( A-F-E-D-C) identified by signal (#) between
transfer node A and node C . at the same time, they are still
including bidirectional working SPME (C-D) identified by signal(*)
and protecting SPME(C-B-A-F-E-D) identified by signal($) between
another transfer node D and node C, just as the following figure 2.
transfer node
|
+---+ ######## +---+
| F |-------------| A |
+---+ $ $ $ $ +---+
#/$ $ \@
#/$ $ \@
#/$ $ \@
+---+ +---+
sink node----| E | | B |
+---+ +---+
#\$ $ /@
#\$ $ /@
#\$ $ /@
+---+ * * * * * +---+
| D |-------------| C |
+---+ ###### +---+
| source node
transfer node
NOTE:
@: working sub-path tunnel between A and C
#: protecting sub-path tunnel between A and C
*: working sub-path tunnel between C and D
$: protecting sub-path tunnel between C and D
Figure 2
Liu, et al. Expires June 17, 2012 [Page 5]
Internet-Draft MPLS-TP ring protection December 2011
supposing a LSP service from source node C to sink node E ,under
free-defect contidion,it would push the LSP into working SPME (w)PCA|
LC(A)|BOS firstly,then it will POP outer SPME label and swap inner
LSP label in the transfer node A .and then push it into another SPME
(w)PAE|LA(E)|BOS and transport it to sink node E. here PXY denotes a
SPME from LSR-X to LSR-Y , '|' can be used to separate each level in
label stack .LX(Y) denotes a LSP service from LSR-X to LSR-Y. BOS
denotes the bottom of label stack. Supposing a defect happened on
the working SPME(C-B-A) by OAM function as the following figure 3.
transfer node
|
+---+ # # # # +---+
| F |-------------| A |
+---+ +---+
#/ \@
#/ \@
#/ \@
+---+ +---+
sink node----| E | | B |
+---+ +---+
#\ /@
#\ X
#\ /@
+---+ +---+
| D |-------------| C |
+---+ # # # # +---+
| source node
transfer node
NOTE:
@: working sub-path Tunnel
#: protecting sub-path Tunnel
X: failure
Figure 3
for example, there is a defect on the link(C-B) just as above
figure,all LSP services which would be carried and sent between C and
transfer node A by working SPME(C-B-A) should switch to protecting
SPME(C-D-E-F-A) and push it into protecting SPME(p)PCA|LC(A)|BOS and
be transported to transfer node A if the protecting SPME has no
failure at the same time. when it arrived at the transfer node A ,
Liu, et al. Expires June 17, 2012 [Page 6]
Internet-Draft MPLS-TP ring protection December 2011
The outer SPME label would be popped and swap LSP label in the
transfer node A, Then the LSP service would be pushed into another
working SPME (w)PAE|LA(E)|BOS and be carried to sink node E .in
addtion, when the transfer node A or the relative protecting SPME has
failure too, another transfer node D will become transfer node for
all LSP services which are trasfered at the transfer node A. All LSP
services of working SPME(C-B-A) would be pushed into another working
SPME(C-D) (w)PCD|LC(D)|BOS to be sent to backup transfer node D, and
then POP outer SPME label and swap LSP label at the transfer node D
.then they would be pushed into another SPME (w) PDE|LD(E)|BOS and be
sent to sink node E.
From the view of number of configuring SPME, if there are n nodes in
the ring , there only need to set up and configure O(4N) SPME Tunnel.
if configuring one working SPME and one protecting SPME between each
node and other nodes of the ring , then there need to set up and
configure O(n^2) SPME . so this solution maybe solve the N square
problem.
3.2. solution 2
This ring protection solution can use one protecting LSP path to
protect one working LSP path,since they are both in the same ring,
the direction of the two LSP path is reverse in the ring. when a
defect has been detected by section cc&cv function, a state notify
message just as the above figure 1 will be generated and sent to all
other nodes of the ring . when other nodes receive the state notify
message , they would analysis which LSP service would be affected by
the failure based by the state notify message and segment link state
of each LSP on each node.if some working paths are affected by the
failure, they will switch to its relative protecting path or bridge
its service to both working path and protecting path.
3.2.1. P2P Instance
if the LSP service affected by the failure is P2P service in the ring
, the source node of the LSP service would switch into its own
protecting LSP path to transport to the egress node of the ring.
while the egress node of the LSP service would select protecting LSP
path to receive the service .for example , there is a LSP service
from B to E as the following figure 4. its working LSP path is
B-A-F-E identified by singal @, while its protecting LSP path is
B-C-D-E identified by signal #, Under normal condition, the LSP
service would be sent by the working LSP path(B-A-F-E).
Liu, et al. Expires June 17, 2012 [Page 7]
Internet-Draft MPLS-TP ring protection December 2011
+---+ @@@@@@@@ +---+
| F |-------------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
sink node --| E | | B |Source node
+---+ +---+
#\ /#
#\ /#
#\ /#
+---+ +---+
| D |-------------| C |
+---+ # # # # +---+
NOTE:
@: working LSP path;
#: protecting LSP path;
Figure 4
if there is a defect on the working LSP path. for example the link
A-F has a defect as the following figure 5.node A or F would detect a
defect by section CC&CV function firstly. then node A or F would
generate state notify message and send it to all other nodes of the
ring. when other nodes of the ring received the state notify message
, they would process the state notify message and analysis which LSP
service would be affected by the failure based by the state notify
message and segment link state of each LSP which must save on both
end node of each LSP.if the failure can change the segment link state
of a LSP , the LSP will switch into the protecting path to transport
service pakcet. Just as the following link(A-F) failure, when both
end nodes B and E of the LSP received the state notify message from
node A or F, they firstly would locate where the failure happened by
the two end node address of the failure in the state notify message.
then they would judge whether to affect the segment link state of the
LSP(B-A-F-E) which had saved on both node.if the segment link state
of the LSP has be changed. the source node B of the LSP service would
switch to protecting LSP path(B-C-D-E) to transport it. At the same
time, the sink node E of the LSP Service would select protecting LSP
path to accept service.
Liu, et al. Expires June 17, 2012 [Page 8]
Internet-Draft MPLS-TP ring protection December 2011
+---+ @@@@@@@@ +---+
| F |-----X-------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
sink node --| E | | B |Source node
+---+ +---+
#\ /#
#\ /#
#\ /#
+---+ +---+
| D |-------------| C |
+---+ # # # # +---+
NOTE:
@: working LSP path;
#: protecting LSP path;
X: failure
Figure 5
when the failure is clear, node A or F would generate state notify
message of defect-free to all other nodes of the ring . so the source
node B and the sink node E of the LSP service received the state
notify message , they would still analysis which LSP service would be
affected by state changing and adopt relative action.so they would
restore to send and receive service packet by working lsp
path(B-C-D-E).
3.2.2. P2MP Instance
For P2MP service of the ring , it must be unidirectional and more
than one egress nodes. it is difficult for ingress node or egress
node to judge and analysis which P2MP LSP service would need to be
switch by the failure only by state notify message and segment link
state of the p2mp path. . when a failure has been detected by section
CC&CV function, the node which detects the failure would generate
state notify message and send it to all other nodes of the ring. when
other nodes received the state notify message,the root node of the
P2MP service firstly bridge to the working path and the protecting
path . so it send the service to its egress nodes by differently
Liu, et al. Expires June 17, 2012 [Page 9]
Internet-Draft MPLS-TP ring protection December 2011
working path and protecting path. For egress nodes of the p2mp
service. They will merge select one path to accept the service
packet. when the defect is clear, the node which detects defect-free
will generate a state notify message of defect-free and send it to
all other nodes of the ring. all other nodes receive the state notify
message and restore only working path to transport the service
packet. for root node of the p2mp service, it only send p2mp service
packet by working path. while egress nodes will only select working
path to accept the p2mp service packet.
for example, there is a p2mp service from source node B to egress
nodes F and E. its working path is B-C-D-[E]-[F] identified by
signal(#) ,and its protecting path is B-A-[F]-[E] identified by
singal(@).under normal condition, the service pakcet will be
transported by working path B-C-D-[E]-[F] .just as the following
figure 6:
+---+ @@@@@@@@ +---+
sink node 2--- | F |-------------| A |
+---+ +---+
@/# \@
@/# \@
@/# \@
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
\# # /
\# # /
\# # /
+---+ # # # # +---+
| D |-------------| C |
+---+ +---+
NOTE:
@: working path ;
#: protecting path;
Figure 6
when link C-D and link D-E failure happens, node C or node E that
detects a defect will generate a state notify message of SF and send
Liu, et al. Expires June 17, 2012 [Page 10]
Internet-Draft MPLS-TP ring protection December 2011
it to all other nodes of the ring . when other nodes C,B,A,F receive
the state notify message , they will make all p2mp source services be
sent by both working path and protecting path firstly. eg. the
service from B to E,F , root node B send the p2mp service packet
separately by its working path B-C-D-[E]-[F] and its protecting path
B-A-[F]-[E]. As there is a defect in separately C-D link and D-E
link, for the egress nodes E and F, they will not receive service
packet by its working path B-C-D-E-F. so they must select its
protectiong path B-A-[F]-[E] to receive the service packet just as
the following figure 7:
+---+ @@@@@@@@ +---+
sink node 2--- | F |-------------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
\ /
X /
\ /
+---+ +---+
| D |-----X------| C |
+---+ +---+
NOTE:
@: transport service by protecting path
X: failure
Figure 7
when the defect is clear , the node C ,E will generate a state notify
message of defect-free and send it to all other nodes of the ring.
when other nodes receive the state notify message , each node will
restore to send and receive its own service only by its own working
path .for example,the p2mp service from B to E,F will restore to
working path B-C-D-[E]-[F] to send and receive the p2mp service
packet as the following 8.
Liu, et al. Expires June 17, 2012 [Page 11]
Internet-Draft MPLS-TP ring protection December 2011
+---+
sink node 2--- | F |-------------| A |
+---+ +---+
#/ \
#/ \
#/ \
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
#\ /#
#\ /#
#\ /#
#\ /#
+---+ +---+
| D |-------------| C |
+---+ # # # # # +---+
NOTE:
#: transport service
X: failure
Figure 8
4. Security Considerations
The security considerations for the authentication TLV need further
study.
5. IANA Considerations
TBD.
6. Acknowledgments
thank Huub van Helvoort ,Italo Busi, Yaacov Weingarten, malcolm.betts
and other experts providing some good comments and advices for this
draft.
7. References
Liu, et al. Expires June 17, 2012 [Page 12]
Internet-Draft MPLS-TP ring protection December 2011
7.1. Normative References
[IETF RFC4090]
IETF, "IETF RFC4090(Fast Reroute Extensions to RSVP-TE for
LSP Tunnels)", May 2005.
[IETF RFC5654]
IETF, "IETF RFC5654(Requirements of an MPLS Transport
Profile)", september 2009.
[IETF RFC5921]
IETF, "IETF RFC5921(A Framework for MPLS in Transport
Networks)", July 2010.
[IETF RFC6372]
IETF, "IETF RFC6372(Multiprotocol Label Switching
Transport Profile Survivability Framework)",
September 2011.
[IETF RFC6378]
IETF, "IETF RFC6379(Multiprotocol Label Switching
Transport Profile Linear protection)", November 2011.
[IETF RFC6427]
IETF, "IETF RFC6427(Multiprotocol Label Switching
Transport Profile Fault Management)", November 2011.
[RFC 5586]
IETF, "IETF RFC5586(MPLS Generic Associated Channel)",
June 2009.
7.2. Informative References
[ITUT-G.8132 Draft]
ITU-T, "Draft ITU-T Recommendation G.8132(T-MPLS shared
protection ring)", February 2008.
[MPLS-TP Ring protection]
Y. Weingarten, S. Bryant, N. Sprecher, D. Ceccarelli,D.
Caviglia, F. Fondelli, M. Corsi, "MPLS-TP Ring
Protection", August 2010.
[MPLS-TP Ring protection switching]
Igor Umansky, Huub van Helvoort, "MPLS-TP Ring Protection
Switching (MRPS)", August 2010.
Liu, et al. Expires June 17, 2012 [Page 13]
Internet-Draft MPLS-TP ring protection December 2011
7.3. URL References
[MPLS-TP-22]
IETF - ITU-T Joint Working Team, "", 2008,
<http://www.example.com/dominator.html>.
Authors' Addresses
Liu guoman
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52871606
Email: liu.guoman@zte.com.cn
Ji Yuefeng
BUPT University
Beijing University of Posts and Telecommunications
beijing 100876
P.R.China
Email: jyf@bupt.edu.cn
Yu jinghai
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52877162
Email: Yu.jinghai@zte.com.cn
Liu, et al. Expires June 17, 2012 [Page 14]
