MPLS Working Group G. Liu
Internet-Draft J. Yang
Intended status: Standards Track l. Jiang
Expires: March 29, 2011 z. Fu
ZTE Corporation
September 25, 2010
Multiprotocol Label Switching Transport Profile Ring Protection
draft-liu-mpls-tp-ring-protection-01
Abstract
according to RFC 5654 MPLS-TP Requirement, there are two requirements
: requirement 56.B Recovery techniques used for P2P and P2MP should
be identical to simplify implementation and operation.another
requirement as section 2.5.6.1 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 decument will describle and provide two
types of ring protection solutions. both solutions can satisfy these
requirements of recovery in mpls-tp ring network.
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 March 29, 2011.
Copyright Notice
Liu, et al. Expires March 29, 2011 [Page 1]
Internet-Draft MPLS-TP ring protection September 2010
Copyright (c) 2010 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. proposed ring protection solution . . . . . . . . . . . . . . 4
3.1. sub-path tunnel protection solution . . . . . . . . . . . 4
3.2. Extend Steering protection . . . . . . . . . . . . . . . . 8
3.2.1. P2P Service Protection . . . . . . . . . . . . . . . . 8
3.2.2. P2MP Service Protection . . . . . . . . . . . . . . . 10
3.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Liu, et al. Expires March 29, 2011 [Page 2]
Internet-Draft MPLS-TP ring protection September 2010
1. Introduction
this draft mainly describes two new ring protection solutions,
solution 1 is based on sub-path Tunnel protection solution to
implement to protect all kind of service by protecting sub-path when
there are a few faults or defects in the ring .and there are fewer
Sub-Path Tunnels to be set up in the ring network. while solution 2
is based on Steering protection solution of G.8132 to be able to
implement to protect P2P or P2MP service very quickly. at last it
provides the comparsion of the two ring protection solutions from the
view of a protection performance and effect.
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
Liu, et al. Expires March 29, 2011 [Page 3]
Internet-Draft MPLS-TP ring protection September 2010
LER: Label Edge Router
PST: Path Segment Tunnel
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 failure of the ring by OAM or APS functions,so that the source
node of working sub-path tunnel and LSP path will switch these
protected services into protecting sub-path tunnel and LSP path.but
the two ring protection solutions also have a few differences.
solution 1 provide protection of all failure LSP services of a
working sub-path tunnel by setting up protecting sub-path tunnel
,while the later ring protection solution provides one dedicate
protection path for each working LSP path to protect and recovery all
failure services in the ring.
3.1. sub-path tunnel protection solution
This ring protection solution in MPLS-TP network mainly make use of
protecting sub-path tunnel to protect all LSP services of a failure
working sub-path tunnel .firstly two prime transfer nodes will be
selected for the ring. and the two prime transfer nodes would backup
for each other to ensure to transport service under the condition
that one prime transfer node has failure. and other nodes in the ring
need to pre-configured and set up two bidirectional sub-path tunnel
separately in the direction of clockwise and anticlockwise along the
ring to the two prime transfer nodes ; and there is CC or CV packet
to verify the connectivity of every sub-path tunnel.and each sub-path
Tunnel will reserve 50 percent bandwidth or capacity to use for
protecting another working sub-path tunnel.
when an end node of a working sub-path tunnel detects a failure in
its own sub-path tunnel by OAM fucntion, it will generate a State
notify message (APS or PSC) to send to another end node of the sub-
path tunnel through pre-configured relative protecting sub-path. and
the frame format of the state notify message is as the following:
Liu, et al. Expires March 29, 2011 [Page 4]
Internet-Draft MPLS-TP ring protection September 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0001| 0000 | 00000000 | channel type (APS or PSC)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| state control message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
when another end node of the sub-path tunnel received State Notify
messgae from peer node, it would process the message and switch to
its relative protecting sub-path to transport all LSP Services of the
failure working sub-path tunnel. for example, there is the following
ring include A ,B, C,D,E,F node. and A and D node is configured as
two prime transfer nodes separately for the ring.while working and
protecting sub-path tunnel will be set up and pre-configured between
two primer transfer nodes A ,D and other nodes include B,C,D,E,F.it
will need to configure and set up 16 sub-path tunnel in the ring. for
C node, there need to set up four bidirectional sub-path
tunnels,which are separately working sub-path tunnel(A-B-C)
identified by signal (@) and protecting sub-path tunnel ( A-F-E-D-C)
identified by signal (#) between Prime node A and source node C . at
the same time, they are including bidirectional working sub-path
tunnel(C-D) identified by signal(*) and protecting sub-path tunnel(C-
B-A-F-E-D) identified by signal($) between prime node D and soure
node C, as the following figure.
Liu, et al. Expires March 29, 2011 [Page 5]
Internet-Draft MPLS-TP ring protection September 2010
Prime node
|
+---+ ######## +---+
| F |-------------| A |
+---+ $ $ $ $ +---+
#/$ $ \@
#/$ $ \@
#/$ $ \@
+---+ +---+
sink node----| E | | B |
+---+ +---+
#\$ $ /@
#\$ $ /@
#\$ $ /@
+---+ * * * * * +---+
| D |-------------| C |
+---+ ###### +---+
| source node
Prime 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
For a LSP service from source node C to sink node E ,under normal
contidion,it would push into working sub-path tunnel (w)PCA|LC(A)|BOS
firstly,then it will pop sub-path tunnel label and swap LSP label in
the prime transfer node A .and then push into another sub-path tunnel
(w)PAE|LA(E)|BOS and transport to sink node E. here PXY denotes a
sub-path tunnel 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. when it detects a
failure in the working sub-path tunnel(C-B-A) by OAM function as the
following figure.
Liu, et al. Expires March 29, 2011 [Page 6]
Internet-Draft MPLS-TP ring protection September 2010
Prime node
|
+---+ # # # # +---+
| F |-------------| A |
+---+ +---+
#/ \@
#/ \@
#/ \@
+---+ +---+
sink node----| E | | B |
+---+ +---+
#\ /@
#\ X
#\ /@
+---+ +---+
| D |-------------| C |
+---+ # # # # +---+
| source node
prime node
NOTE:
@: working sub-path Tunnel
#: protecting sub-path Tunnel
X: failure
Figure 3
for example, there is a failure in the link(C-B),all LSP services
which would be carried and sent between C and prime node A by working
sub-path tunnel(C-B-A) should switch to protecting sub-path tunnel(C-
D-E-F-A) and push into protecting sub-path tunnel(P)PCA|LC(A)|BOS and
be transported by the protecting sub-path tunnel if the protecting
sub-path tunnel has no failure at the same time. when it arrived at
the prime node A through the protecting sub-path tunnel, the outer-
top SPME label would be poped and swap LSP label in the prime
transfer node A, then the LSP service would push into another working
sub-path tunnel (w)PAE|LA(E)|BOS and be carried to sink node E .in
addtion, when the prime transfer node A is bad or the relative
protecting sub-path tunnel has failure too, another prime transfer
node D will become active prime transfer node for the LSP service.
All LSP services of working sub-path tunnel(C-B-A) would push into
working sub-path tunnel(C-D) (w)PCD|LC(D)|BOS to be sent to backup
prime node D, and then POP outer-top sub-path tunnel label and swap
LSP label.then the LSP serivce would push into another sub-path
tunnel (w) PDE|LD(E)|BOS and be carried and sent to sink node E.
Liu, et al. Expires March 29, 2011 [Page 7]
Internet-Draft MPLS-TP ring protection September 2010
From the number of configuring sub-path tunnel, if there are n nodes
in the ring , there only need to set up and configure (n-2)*2 working
sub-path tunnels and (n-2)*2 protecting sub-path tunnel. if
configuring one working sub-path tunnel and one protecting sub-path
tunnel between each node and other nodes of the ring , then there
need to set up and configure O(n^2) sub-path tunnels. so this
solution may solve the N square problem.
3.2. Extend Steering protection
This ring protection solution can extend G.8132 Steering protection
solution to simply , quickly and effectively protect LSP service
include p2p or p2mp in the MPLS-TP network ring. in order to protect
and restore all failure services when a failure has happened in the
ring. firstly each LSP path should configure one working LSP path and
one protecting LSP path in the ring. and the direction of the two LSP
path is reverse in the ring. when a failure has been detected by OAM
function of section layer, a state notify message packet will be
generated and sent to other nodes in the ring by control channel or
other channel very quickly for the first three packets. when other
nodes receive the state notify message packet, they would analysis
and judge which LSP service would be affected by the failure by state
notify message or PRO of each LSP in the node.
3.2.1. P2P Service Protection
if the LSP service affected by the failure is P2P service , the
source node of the LSP service would switch into its own protecting
LSP path to transport to the sink node. while the sink node of the
LSP service would select protecting LSP path to receive the service
.for example , now there is a LSP service from B to E as the
following figure. its working LSP path is B-A-F-E identified by
singal @, while its protecting LSP path is B-C-D-E, Under normal
state, the LSP service would be sent by the working LSP path in the
source node .while be received by selecting working LSP path in the
sink node .
Liu, et al. Expires March 29, 2011 [Page 8]
Internet-Draft MPLS-TP ring protection September 2010
+---+ @@@@@@@@ +---+
| F |-------------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
sink node --| E | | B |Source node
+---+ +---+
#\ /#
#\ /#
#\ /#
+---+ +---+
| D |-------------| C |
+---+ # # # # +---+
NOTE:
@: working LSP path;
#: protecting LSP path;
Figure 4
if there is a failure in the working LSP path. for example a failure
happened in the link A-F as the following figure.node A or F would
detect a failure by section CC&CV packet firstly. then node A or F
would generate state notify message to other nodes in the ring. when
other nodes of the ring received the state notify message , they
would receive and process the state notify message. for the source
node B and sink node E of the LSP service, they would analysis and
judge whether the LSP service would be affected by the failure based
by state notify message and PRO of each LSP in the node. as the
link(A-F) failure would affect working LSP path of the LSP Service.
the source node B of the LSP service would switch to bridge to
protecting LSP path. At the same time, the sink node E of the LSP
Service would select protecting LSP path to accept service.
Liu, et al. Expires March 29, 2011 [Page 9]
Internet-Draft MPLS-TP ring protection September 2010
+---+ @@@@@@@@ +---+
| 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 failure clear
notify message to other nodes of the ring . when the source node B
and the sink node E of the LSP service received the failure clear
notify message , they would restore to send and receive service
packet from working LSP path.
3.2.2. P2MP Service Protection
For P2MP service of the ring , it must be unidirectional path and
more than one egress nodes. it is difficult for source node or sink
node to judge and analysis which P2MP LSP service would be affected
by the failure only based by state notify message. so when a failure
has been detected by section CC&CV function, the nodes which detect
the failure would generate state notify message to send to other
nodes of the ring. when other nodes received the state notify
message,the source nodes of P2MP service firstly make their p2mp
services bridge to the working path and the protecting path and send
the service to its destination node along the directions of working
path and protecting path. if a node in the ring is destination node
for p2mp service. It will merge select a direction of path to accept
Liu, et al. Expires March 29, 2011 [Page 10]
Internet-Draft MPLS-TP ring protection September 2010
service packet. Then each sink node will detect whether the
direction of receive service packet is changable. if it happens, the
sink nodes will periodically generate the message of receiving state
changing and send to its source node for the p2mp service. when the
source node for the p2mp service receives all the messages from other
sink nodes and processes them, judge whether all sink nodes of the
p2mp service s in the same direreceive the service packetction
include working path or protecting path. the source node of the
service will select a path(working path or protecting path) to send
service packet. or else it will continue to send service packet in
the two path(working path and protecting path). when the failure is
clear, the nodes which detect free-failure will generate a free-
failure notify message and send to all other nodes in the ring. all
other nodes receive the free-failure notify message and stop sending
the message of receiving state changing periodically ,all service
packets will come back to be transported in the working path. at the
same time , each sink node for the service will select the direction
of working path to receive service packet as idle state condition.
the implement in detail as the following figure. for example, there
is a p2mp service from source node B to sink node F,E. and working
path is B-C-D-[E]-[F] identified by signal(#) ,while protecting path
is B-A-[F]-[E] identified by singal(@).under normal situation,the
service pakcet will be transported by working path B-C-D-[E]-[F].
+---+ @@@@@@@@ +---+
sink node 2--- | F |-------------| A |
+---+ +---+
@/# \@
@/# \@
@/# \@
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
\# # /
\# # /
\# # /
+---+ # # # # +---+
| D |-------------| C |
+---+ +---+
NOTE:
@: working path ;
#: protecting path;
Liu, et al. Expires March 29, 2011 [Page 11]
Internet-Draft MPLS-TP ring protection September 2010
Figure 6
when link C-D and link D-E failure happens, node C or node E that
detects a failure will generate a state notify message packet to send
to other nodes in the ring through control channel or other channel.
when other node C,B,A,F receive the state notify message packet, they
will make all source services bridge to working path and protecting
path firstly. eg. the service from B to E,F , node B firstly send the
service packet separately along its working path B-C-D-[E]-[F] and
its protecting path B-A-[F]-[E]. As there are the failures in C-D
link and D-E link, the sink node E ,F will not receive service packet
by its working path B-C-D-E-F. so the two sink nodes E ,F must merge
select its protectiong path B-A-[F]-[E] to receive the service
packet.at the same time. As the sink node E, F is sink nodes of the
p2mp service ,so the node E,F will generate the message of receiving
state changing and send to source node B of the p2mp service
periodically. so source node B will receive the message and process
the message. because both sink nodes receive service packet from
their protecting path. then the source node B will only select
protecting path to send its service packet as the following figure:
+---+ @@@@@@@@ +---+
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
Liu, et al. Expires March 29, 2011 [Page 12]
Internet-Draft MPLS-TP ring protection September 2010
when the failure is clear , the node C,E detect the failure state
have been clear up, the node C ,E will generate a free-failure notify
message and send to all other nodes in the ring. when other nodes
receive the free-failure notify message , each node will send and
receive its own service only by its own working path .eg,the p2mp
service from B to E,F will come back to working path B-C-D-[E]-[F] to
send and receive its own service packet as the following. at the same
time, all sink nodes of p2mp services would stop generating and
sending the message of receiving state changing at once.
+---+
sink node 2--- | F |-------------| A |
+---+ +---+
#/ \
#/ \
#/ \
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
#\ /#
#\ /#
#\ /#
#\ /#
+---+ +---+
| D |-------------| C |
+---+ # # # # # +---+
NOTE:
#: transport service
X: failure
Figure 8
3.3. Comparison
The two ring protection solutions can fulfil MPLS-TP requirement of
ring recovery. but there are different protection and recovery
mechanism and different character, the detail is the following table:
Liu, et al. Expires March 29, 2011 [Page 13]
Internet-Draft MPLS-TP ring protection September 2010
+-----------------+----------+------------
| Items |solution 1|solution 2 |
| | | |
+-----------------+----------+------------+
| Amounts of the | Less | As many as |
| backup LSP | | the |
| | | protected |
| | | LSP |
+-----------------+----------+------------+
| Bandwidth | lower | high |
| utilization | | |
| ratio | | |
+-----------------+----------+------------+
| Bandwidth share | Support | Support |
+-----------------+----------+------------+
| the number of | less | more |
| elements of , | | |
| recovery | | |
+-----------------+----------+------------+
| the number of | less | more |
| OAM | | |
+-----------------+----------+------------+
| complexity | simple | complex |
+-----------------+----------+------------+
| Lable stack | Increase | Changeless |
| | one more | |
| | layer | |
+-----------------+----------+------------+
| P2P and | Support | Support |
| P2MP | | |
| service | | |
+-----------------+----------+------------+
| multi-failure | support | support |
| recovery | | |
| | | |
+-----------------+----------+------------+
| time of | slow | fast |
| recovery | | |
+-----------------+----------+------------+
Table 1: comparison of ring protection
Figure 9
Liu, et al. Expires March 29, 2011 [Page 14]
Internet-Draft MPLS-TP ring protection September 2010
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
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.
[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 Fault Management]
G. Swallow,A. Fulignoli,M. Vigoureux,S. Boutros,D. Ward ,
"MPLS Fault Management OAM", July 2010.
Liu, et al. Expires March 29, 2011 [Page 15]
Internet-Draft MPLS-TP ring protection September 2010
[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.
[MPLS-TP Survivability Framework]
N. Sprecher, A. Farrel, "Multiprotocol Label Switching
Transport Profile Survivability Framework", June 2009.
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
Yang Jian
ZTE Corporation
5F,RD Building 3,ZTE Industrial Park,XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Phone: +86 755 26773731
Email: yang_jian@zte.com.cn
Liu, et al. Expires March 29, 2011 [Page 16]
Internet-Draft MPLS-TP ring protection September 2010
Jiang lili
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52871745
Email: jiang.lili@zte.com.cn
Fu zhentao
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52877162
Email: fu.zhentao@zte.com.cn
Liu, et al. Expires March 29, 2011 [Page 17]