MPLS Working Group G. Liu
Internet-Draft J. Yang
Intended status: Informational l. Jiang
Expires: March 18, 2010 X. Dai
ZTE Corporation
September 14, 2009
Multiprotocol Label Switching Transport Profile Ring Protection
draft-liu-mpls-tp-ring-protection-00
Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 18, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Liu, et al. Expires March 18, 2010 [Page 1]
Internet-Draft MPLS-TP ring protection September 2009
Abstract
according to MPLS-TP Requirement draft, there are two requirements :
requirement 56.B Recovery techniques used for P2P and P2MP should be
identical to simplify implementation and operation.another require 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 a 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.
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.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Liu, et al. Expires March 18, 2010 [Page 2]
Internet-Draft MPLS-TP ring protection September 2009
1. Introduction
this draft mainly introduce two new ring protection solutions,
solution 1 is based on MPLS FRR-bypass solution to realize to protect
all kind of service(eg. P2P or p2mp) when there are a few fault or
detects in the ring at the same time. while solution 2 is based on
G.8132 Steering protection solution to be able to realize to protect
P2P or P2MP services very rapidly. at last it provide the comparsion
of the two ring protection solutions from the view of a protection
performance.
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 18, 2010 [Page 3]
Internet-Draft MPLS-TP ring protection September 2009
3. proposed ring protection solution
this section mainly proposed two kinds of ring protection
solution.the two ring protection solutions can need to detect and
notify the failure of the ring by MPLS or MPLS-TP OAM functions,so
that the source node or the local failure node will switch these
relative services to protection path.but the two ring protection
solutions also have a few differences. solution 1 provide protection
of all failure services by setting up protection tunnel,while the
later ring protection solution provide one dedicate protection path
for each working LSP path to protect and recovery all failure
services in the ring.
3.1. Solution 1
The ring protection solution in MPLS-TP network mainly make use of
protection tunnel to protect all failure services.firstly a prime
node will be choosed in the ring. at the same time. in order to
continue to protect all failure services when the prime node have a
failure, a secondary node will be choosed to be backup node for the
prime node in the ring. and other node in the ring need to pre-
configured and set up a bidirectional protection tunnel to the prime
node and the secondary node; and there is BFD function packet to
detect link or node failure between two directly interconnection node
in the ring.
when a node of the ring detects a failure include link failure or
peer node failure, it will generate a failure notify message to send
to prime node and secondary node of the ring by pre-configured
protection tunnel. and the frame format of the failure notify message
is as the following:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0001| 0000 | 00000000 | channel type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP identifier TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
NOTE:
LSP Identifier TLV: a standard TLV frame construct. including Type ,
Liu, et al. Expires March 18, 2010 [Page 4]
Internet-Draft MPLS-TP ring protection September 2009
Length,and Value, and the value field may be divided into two parts:
the former is the identifier of LSP path, the later is Entry Label of
the LSP path in the ring. this LSP Identifier TLV format is as the
following:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | Length | LSP Identifier | Entry label|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
NOTE:
LSP Identifier: it identify solely LSP path in the ring, eg: TTSI;
Entry Label: Local Entry Label of the LSP Path in the node .
when the prime node of the ring received the failure notify message
packet from two end nodes that have detected the failure. the prime
node will bind the relation of the two protection tunnel .so the
failure notify messages that have received from a protection tunnel
can continue to transport by another protection tunnel. at last the
failure notify message will be transported to another upstream node.
and the upstream node receives the failure notify message packet and
analysises the message packet. if the failure notify message has no
any LSP Identifier TLV or NULL TLV, all working LSP services in the
upstream node are still transported by working label. or else it will
look up label swithing table by LSP Identifier in LSP Identifier TLV.
if there exist a few working services that need to switch into
protection path. Entry Label in LSP Identifier TLV will replace of
the export label for the same LSP Identifier. when a normal service
packet reachs the node, the node will change switch label into entry
label of LSP Identifier TLV ,Then the service packet will be
transported by protection tunnel between the node and the prime node
in the ring. when the prime node receives the service packet from the
upstream node.the service packet will continue to be tranported in
another protection tunnel that has already been bound by switching
label of protection tunnel layer. at last the service packet will be
transported to the downstream node and continue to be transported in
original working LSP like wrapping solution.
the implement in detail as the following figure :
Liu, et al. Expires March 18, 2010 [Page 5]
Internet-Draft MPLS-TP ring protection September 2009
secondary node Prime node
|
+---+ @@@@@@@@ +---+
sink node---- | F |-------------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
| E | | B |Source node
+---+ +---+
\ /@
X /@
\ /@
+---+ +---+
| D |-----X------| C |
+---+ +---+
NOTE:
@@@@@@: protection tunnel path
X: failure
Figure 3
if there is a service from node B to node F , under the normal
condition,the service will be transported by B-C-D-E-F working path.
when there is a failure individually in link (C-D) and link(D-E),
firstly C,D,E node will detect the failure by BFD function and the
three node will generate a failure notify message individually and
send the failure notify message packet to the prime node A and the
secondary node F by their own specail protection tunnels.as the D
node have already been a isolate point , its failure notify message
will not be transported to the prime node by its own protection
tunnel. only the failure notify message from C,E node will be
transported to the prime node A individually through C-A and E-A
protection tunnel.when prime node A receives failure notify message
from C and E node protection tunnel. it will bind the two protection
tunnels and the failure notify message packet from C will be sent to
E node. at the same time. the failure notify message packet from E
node will be sent to C node. and for the service from B to F , C will
be upstream node to E node. when C node receive the failure notify
message from E , It will look up its own switching table by LSP
Identifier in the LSP Identifier TLV. we suppose that entry label is
1 and export label is 2 at the C node for the service from B to F ,
while entry label is 100 and out label is 200 at the E node for the
Liu, et al. Expires March 18, 2010 [Page 6]
Internet-Draft MPLS-TP ring protection September 2009
service and the service LSP Identifer is 300 under normal condition.
when a failure have happened ,C node will look for which LSP
Identifier is 300. if it find the LSP service. and the service will
be transported by protection path and entry label in E node will
replace of export label in C node for the service from B to F node.
then the service packets in C node will be transported to the prime
node A by C to A protection tunnel path. then by switching protection
tunnel, the service packets will be transported to E by A-E
protection tunnel.at last the serivce packets will be tranported by
switching originate working LSP path and to destination node F.
when the nodes detect no failure in the ring. They will send a free-
failure notify message packet to the prime node A and the secondary
node F through their own protection tunnel.and the prime node A
receives the free-failure notify message packet and sends to its
upstream node , so the upstream node will make all service pakcets be
transported by originate working LSP path.
3.2. Solution 2
This ring protection solution can extend G.8132 Steering protection
solution to simply , quickly and effectively protect all service
include p2p or p2mp in the MPLS-TP ring. in order to protect and
restore all failure services when a failure has happened in the ring.
firstly each LSP service 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 BFD
function, a failure notify message packet will be generated and sent
to other nodes in the ring by control channel or other channel. when
other nodes receive the failure notify message packet, they firstly
make their source services bridge to the working path and the
protecting path and double send the service to its destination node
in the directions of working path and protecting path. if a node in
the ring is destination node for a service. It will select a
direction of path to receive service packet. each sink node will
detect whether the direction of receive service packet is changable.
if it happens, the sink node will return the message of receiving
state change to its source node for a LSP service. when the source
node for a LSP service receives all messages from other sink nodes
and analysis. if all sink nodes receive service packets in the same
direction 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). after a period of
time, when a node detects the failure is clear, the node 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 double their service pakcets ,all service packets will
Liu, et al. Expires March 18, 2010 [Page 7]
Internet-Draft MPLS-TP ring protection September 2009
only be transported in the direction of working path. at the same
time , each sink node for a service will select the direction of
working path to receive service packet as normal condition.
the implement in detail as the following figure :
+---+ @@@@@@@@ +---+
sink node 2--- | F |-------------| A |
+---+ +---+
@/ \@
@/ \@
@/ \@
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
\ /@
X /@
\ /@
+---+ +---+
| D |-----X------| C |
+---+ +---+
NOTE:
@: direction of transport packet;
X: failure
Figure 4
If there is a P2MP service from source node B to sink node 1 E and
sink node 2 F in the above ring.under normal situation,the service
pakcet will be transported by working path B-C-D-[E]-[F]; when link
C-D and link D-E failure happens, node C or node E that detects a
failure will generate a failure notify message packet to send to
other node in the ring through control channel or other channel. when
other node C(E),B,A,F receive the failure notify message packet, they
will make all source services bridge to working LSP path and
protecting LSP path firstly. eg. the service from B to E,F , node B
firstly send doule packet separately along its working path B-C-D-E-F
and its protecting path B-A-[F]-[E]. As there are the failure in C-D
link and D-E link, service sink node E ,F will not receive service
packets by its working path B-C-D-E-F. so the two sink nodes must
receive the service packet by its protectiong path B-A-[F]-[E].at the
Liu, et al. Expires March 18, 2010 [Page 8]
Internet-Draft MPLS-TP ring protection September 2009
same time. the sink node E, F have changed the direction of receiving
service packet ,so the node E,F will generate the message of
receiving state change and send to service source node B. so source
node B will receive the message and anylisis the message. because
both sink nodes receive service from their protecting path. so the
source node 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:
@: direction of transport packet;
X: failure
Figure 5
when the failure is clear up, the node C,E detect the failure state
have changed, 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 in the working path .eg,the p2mp service
from B to E,F will return to working path B-C-D-[E]-[F] to send and
receive its own service packet as the following.
Liu, et al. Expires March 18, 2010 [Page 9]
Internet-Draft MPLS-TP ring protection September 2009
+---+
sink node 2--- | F |-------------| A |
+---+ +---+
@/ \
@/ \
@/ \
+---+ +---+
sink node 1--| E | | B |Source node
+---+ +---+
@\ /@
@\ /@
@
\ /@
+---+ +---+
| D |-------------| C |
+---+ @@@@@@@@ +---+
NOTE:
@: direction of transport packet;
X: failure
Figure 6
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 18, 2010 [Page 10]
Internet-Draft MPLS-TP ring protection September 2009
+-----------------+----------+------------
| 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 | more | less |
| 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 | | |
| | | |
+-----------------+----------+------------+
Table 1: comparison of ring protection
Figure 7
Liu, et al. Expires March 18, 2010 [Page 11]
Internet-Draft MPLS-TP ring protection September 2009
4. Security Considerations
The security considerations for the authentication TLV need further
study.
5. IANA Considerations
TBD.
6. Acknowledgments
TBD.
7. References
7.1. Normative References
[IETF RFC4090]
IETF, "IETF RFC4090(Fast Reroute Extensions to RSVP-TE for
LSP Tunnels)", May 2005.
[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 Framework]
M. Bocci, S. Bryant, L. Levrau , "A Framework for MPLS in
Transport Networks", August 2009.
[MPLS-TP Requirements]
B.Niven-Jenkins, D.Brungard, M.Betts,N. Sprecher ,S.Ueno,
"MPLS transport profile Requirements", August 2009.
[MPLS-TP Survivability Framework]
N. Sprecher, A. Farrel, "Multiprotocol Label Switching
Transport Profile Survivability Framework", April 2009.
Liu, et al. Expires March 18, 2010 [Page 12]
Internet-Draft MPLS-TP ring protection September 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
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
Dai Xuehui
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52877162
Email: dai.xuihui@zte.com.cn
Liu, et al. Expires March 18, 2010 [Page 13]