Multiprotocol Label Switching Transport Profile p2mp Shared Protection
draft-liu-mpls-tp-p2mp-shared-protection-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yu jinghai , Zongpeng Du , Yuefeng Ji , Yu jinghai | ||
| Last updated | 2011-08-30 (Latest revision 2011-03-05) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-mpls-tp-p2mp-shared-protection-02
MPLS Working Group G. Liu
Internet-Draft ZTE Corporation
Intended status: Standards Track Y. Ji
Expires: March 2, 2012 Beijing University of Posts and
Telecommunications
J. Yang
j. Yu
ZTE Corporation
Z. Du
Beijing University of Posts and
Telecommunications
August 30, 2011
Multiprotocol Label Switching Transport Profile p2mp Shared Protection
draft-liu-mpls-tp-p2mp-shared-protection-02
Abstract
This document will describle two protection solutions to support
protection of failures in p2mp path in MPLS-TP. According to the
protection Requirements in RFC 5654, there are requirements for
MPLS-TP to support sharing of protection resources such that
protection paths that are known not to be required concurrently can
share the same protection resources. In addition, there is a
requirement for MPLS-TP to support unidirectional 1:n protection for
p2mp paths. These requirements are further addressed in
draft-ietf-mpls-tp-survive-fwk . so this draft will present proposed
solutions .
This document is a product of a joint Internet Engineering Task
Force(IETF) / International Telecommunications Union
Telecommunications Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and PWE3 architectures
to support the capabilities and functionalities of a packet transport
network as defined by the ITU-T.
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-
Liu, et al. Expires March 2, 2012 [Page 1]
Internet-Draft MPLS-TP p2mp shared protection August 2011
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 2, 2012.
Copyright Notice
Copyright (c) 2011 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.
Liu, et al. Expires March 2, 2012 [Page 2]
Internet-Draft MPLS-TP p2mp shared protection August 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. p2mp shared protection solution . . . . . . . . . . . . . . . 5
3.1. 1:n protection . . . . . . . . . . . . . . . . . . . . . . 5
3.2. (1:1)^n protection . . . . . . . . . . . . . . . . . . . . 9
3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Liu, et al. Expires March 2, 2012 [Page 3]
Internet-Draft MPLS-TP p2mp shared protection August 2011
1. Introduction
This document describes protection solutions for MPLS-TP p2mp paths.
The first solution is based on extending 1:1 protection solution to
implement 1:n protection by using one shared protection p2mp path
when there may have failures on the protected working p2mp paths. A
second solution uses one shared p2p bidirectional protection tunnel
to protect many branch paths of the protected p2mp working paths when
detecting defects on a branch path of some p2mp working paths to
implement (1:1)^n protection. Both protection solutions satisfy and
fulfill requirement 69 and 67B in [RFC 5654]. These solutions can't
exclude 1+1 and 1:1 protection solutions for p2mp path in
draft-ietf-mpls-tp-survive-fwk and
draft-ietf-mpls-tp-linear-protection. it will be used to perfect the
requirement of recovery for p2mp path. If only 1+1 protection is
used for p2mp path, there need to set up a disjoint protection path
for each working path, This will increase the cost of maintaining and
monitoring each of these paths (i.e. both the working and protection
paths). In addition, since the p2mp service must be transported on
both the working and protection paths at the same time, more
bandwidth resource will be consumed for the p2mp service . Due to
these limitations and defects, it is neccesary to consider using
shared protection resources for many p2mp working paths.
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
P2MP:Point to Multi-Point
P2P:Point to Point
PSC:Protection Switching Coordination
SD:Signal Degrade
SF:Signal Fail
RDI:Remote Defect Indication
Liu, et al. Expires March 2, 2012 [Page 4]
Internet-Draft MPLS-TP p2mp shared protection August 2011
MPLS:Multi-Protocol Label Switching
MPLS-TP:Multi-Protocol Label Switching Transport Profile
ME: Maintenance Entity
MEP:MEG End Point
ACH: Associated Channel Header
CC-V: Contunuity Check-Verification;
3. p2mp shared protection solution
This section describes two types of p2mp shared protection solutions.
The first proposed solution utilizes one p2mp protection path to
protect many p2mp working paths . When a protected p2mp working path
detects a failure, the leaf node of the p2mp working path will notify
its own root node of defective message by RDI packet by return path.
If there is no other higher priority protected p2mp working path or
control command that requires the use of the protection path, then
the defective p2mp service packet will switch to p2mp protection path
to be transported. All leaf nodes of the defective p2mp path will
select protection path to receive p2mp service packets.
The second proposed solution utilizes one p2p bidirectional
protection tunnel to protect defective branch paths of many protected
p2mp working paths. When a failure is detected on a protected branch
path of one p2mp working path, the leaf node which has already
detected the failure will notify peer node of its own p2p protection
tunnel of defective message by extensive PSC packet as the following
figure 1. As a result, the service will switch to the protection
path to be transported ,so it will bridge both working path and
protection path to be transported. But the leaf node of the
defective branch path on the p2mp working path will select the
protection p2p path to receive the service packet. But other leaf
nodes will still receive the service packet from original p2mp
working path.
The two p2mp shared protection solutions separately implement 1:n and
(1:1)^n protection for p2mp path, The following sub-section describes
the protection switching methods in detail.
3.1. 1:n protection
The 1:n protection solution should be similar to 1:1 protection
solution described in [survivability-framework] to use one protection
Liu, et al. Expires March 2, 2012 [Page 5]
Internet-Draft MPLS-TP p2mp shared protection August 2011
path to protect many p2mp working paths. However, in this mechanism
since the protected traffics are transported by different working
path. Its implication regarding the p2mp protection path will be
configured between the protection domain root node and all leaf nodes
of protected p2mp working paths. when a leaf node of a protected p2mp
working path detect a failure, The leaf node should generate RDI
packet to notify its own root node of the defective message . When
the root node of the p2mp working path receives the RDI packet and
knows some failures in one or more one branch path of the p2mp
working path, it may send protection switch requirement control
packet to the root node of its own protection path or access node of
the protected p2mp service. When the root node of the protection
path receives the protection switch requirement control packet from
any root node of the protected defective p2mp working path The root
node of the protection path MUST choose one defective path to be
protected based on the priority of these protected defective p2mp
working paths. Then the root node of protection path SHALL generate
extensive PSC packet including the selected p2mp defective path
identifier in a TLV field of the message packet .The following figure
1 is the format of extensive PSC packet .Then it will send the
extensive PSC message to all leaf nodes of the p2mp protection path .
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Channel type(PSC)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PSC PDU +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ P2MP LSP ID TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
NOTE:
P2MP LSP ID TLV: a standard TLV frame structure. including Type ,
Length,and Value, and the value field may be identifier of p2mp LSP
Liu, et al. Expires March 2, 2012 [Page 6]
Internet-Draft MPLS-TP p2mp shared protection August 2011
which have defect and need to be protected. this p2mp LSP ID TLV
format is as the following figure 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | Length | P2MP Path Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
At the same time, the root node of the protection path generates
notify message control packet including selective protected working
path identifier and send it to the root node of each defective p2mp
working path by control channel ,so the root node of each defective
p2mp working path can know whether it may be selected to be protected
based on the notify message control packet. If it has already been
selected to be protected, it will stop sending service packet on the
p2mp working path Then the protected service will switch to the p2mp
protection path to be transported.
On the other hand, all leaf nodes of the protection path receive the
extensive PSC message by the protection path. Then they will know
whether to accept and process the service packet from the protection
path based on p2mp LSP ID TLV field in the extensive PSC packet. If
the leaf node is a sink node of the protected service, it will accept
and process the service packet from the protection path. Or else, it
will drop the service packet.
the implement in detail as the following figure is 1:2(n=2)
protection instance.
Liu, et al. Expires March 2, 2012 [Page 7]
Internet-Draft MPLS-TP p2mp shared protection August 2011
+---+
+->| L1|
+ +---+
X @
+ @
+ @
+---+ +-------------+ @
| r1|+ + + + +->| P2MP path 1 | @
+---+ | | @
| +-------------+ @
| +
| @ +
+---+ +------------+ + +---+
| p |@ @ @ @ @-> | protection | @ @ @ @-> | L2|
+---+ | path | $+---+
| +------------+ X
| @ $
| $ @
+---+ +------------+ @ +---+
| r2|$ $ $ $-> | P2MP |$ $ $ @-> | L3|
+---+ | Path 2 | +---+
+------------+
NOTE:
@@@@@@: p2mp protection path
+++++: p2mp working path 1
$$$$$: p2mp working path 2
X: failure
Figure 3
For the above p2mp network topology , there are two different p2mp
services which need to be transported separately by p2mp working path
1( r1-p2mp path 1-L1,L2) identified by (+) and p2mp working path
2(r2- p2mp path 2-L2,L3) identified by ($) . under normal condition.
the p2mp service from root node r1 will be sent and transported to
leaf nodes L1,L2 by p2mp working path 1, and another p2mp service
from the root node r2 will be sent and transported to leaf nodes
L2,L3. in addition, only one p2mp protection path ( P-protection
path-L1,L2,L3)identified by (@) is used to protect the p2mp working
path 1 and the p2mp working path 2. supposing the priority of p2mp
working path 1 is higher than p2mp working path 2. if there is a
Liu, et al. Expires March 2, 2012 [Page 8]
Internet-Draft MPLS-TP p2mp shared protection August 2011
failure on separately branch path(r1-p2mp path 1-L1) of p2mp working
path 1 and branch path(r2-p2mp path 2-L2) of p2mp working path 2,
Leaf node L1 and leaf node L3 will separately send RDI packet to root
node r1 and root node r2 by return path. when root node r1 and r2
received the RDI packet and processed it. then the control packet of
protection switch requirement will be sent to the root node P of
protection path by control channel . Then the root node P will
choose one working path to be protected. As the priority of p2mp
working path 1 is higher than p2mp working path 2. so the root node P
of protection path will select p2mp working path 1 to be protected,
and send extensive PSC packet including p2mp LSP ID TLV to all Leaf
nodes(L1,L2,L3) of the protection path. At the same time, It will
generate response control packet for the protection switch
requirement of the root node r1 and r2. the service of the working
path 1 will be selected to be protected. So the root node r1 of
working path 1 will stop sending its p2mp service in the working path
1, Then the service of the working path 1 will switch to the
protection path to be transported. on the other hand, for leaf nodes(
L1,L2,L3), when they received the extensive PSC packet from the root
node P, They will decide whether to accept and process the service
packet from the protection path based on selective protected working
path identifer. As leaf nodes(L1,L2) are the leaf nodes of p2mp
working path 1, they will both accept and process the service packet
from the p2mp protection path. but for leaf node L3, as it is not the
leaf node of p2mp working path 1. it will drop the service packet
from the p2mp protection path. While the service of p2mp working
path 2 can't be selected to be protected, so the root node r2 will
continue to send their own service packet by p2mp working path 2.
3.2. (1:1)^n protection
This protection solution can use p2p bidirectional protection tunnel
to protect some branch paths of many p2mp working paths which have
the same leaf node . Under normal condition, the root node of each
p2mp working path will periodically send CC-V OAM packet to its own
leaf nodes by the p2mp working path to detect failure .In order to
protect each branch path of the p2mp working path, Firstly one
bidirectional protection p2p tunnel will be pre-configured between
source protection node and the leaf node of the protected p2mp
working path . in addtion, using an unique adress identifier
including IP multicast address,mpls label etc can identify which
service is tranported in the protection p2p tunnel. when some leaf
nodes detect a failure on some branch path of the p2mp working path,
it would select highest priority p2mp service to be protected and
generate extensive PSC packet including selective protected p2mp
identifier Just as the above figure 1 and send it to peer node of the
protection tunnel . when it received the the extensive PSC packet ,
Liu, et al. Expires March 2, 2012 [Page 9]
Internet-Draft MPLS-TP p2mp shared protection August 2011
it will encapsulate the protected service PDU by an unique adress
identifier , then it will be sent to the leaf node of the defective
branch path.
for example, there is a (1:1)^2(n=2) protection instance as the
following figure 4:
there are two p2mp working paths : p2mp working path 1(r1-p2mp Path
1-L1,L2) identified by ($) and p2mp working path 2(r2-p2mp Path
2-L2,L3) identified by (#).in order to protect the service, a
bidirectional p2p protection tunnel will be pre-configured between
each leaf node(L1,L2,L3) and its own source protection node(P). so it
need to configure three p2p protection tunnels identified by (@) in
the figure
Liu, et al. Expires March 2, 2012 [Page 10]
Internet-Draft MPLS-TP p2mp shared protection August 2011
$ +----+
$ | L1 |
+-------------+ $ @ +----+
$ | P2MP Path 1 | @
$ +-------------+ $ @
$ @ $ @ +----+
$ @ X | L2 |
$ @ @ $ +----+
+----+ @ @ #
| R1 | @
+----+ @ @ X
| @
| @ @ #
+----+ @ @
| P | @ #
+----+ @
| @ @ @ @ @ @ @ @ @ @ +----+
# | L3 |
+----+
# #
| +-------------+ #
# | P2MP Path 2 | #
+----+ # +-------------+
| R2 | #
+----+
NOTE:
@: P2P Protection Tunnel
$: P2MP Working Path LSP 1
#: P2MP Working Path LSP 2
X: failure
Figure 4
when the branch path(R1-P2MP Path 1-L2) of p2mp working path LSP 1
and the branch path(R2-P2MP Path 2-L2) of p2mp working path LSP 2
have a failure at the same time, The leaf node L2 will generate
extensive PSC packet including selective protected p2mp LSP
identifier and send it to peer node(p) of protection tunnel. while
the node(P) received the extensive PSC packet from the Leaf node L2,
it will encapsulate the protected service packet by an unique address
Liu, et al. Expires March 2, 2012 [Page 11]
Internet-Draft MPLS-TP p2mp shared protection August 2011
identifier(IP Multicast address, mpls label etc) and be trasnported
through the p2p protection tunnel(P-L2). As the priority of the p2mp
working path 1 is higher than the p2mp working path 2. The node (P)
will encapsulate the service of p2mp working path 1 by the its own
unique address identifier . then the protected service of the p2mp
working path 1 will be sent by the p2p protection tunnel. at the same
time, the leaf node L2 will select the protection tunnel to receive
service packet and be based on the unique address identifier to judge
which service is transported by p2p protection tunnel now. so that
the leaf node L2 can truly process the service packet from the p2p
protection tunnel. .
3.3. Conclusion
The two types of p2mp protection solution will individually implement
1:n and (1:1)^n protection for p2mp service. They can fulfill the
requirement of unidirectional p2mp protection and sharing protection
resource. in addition, the first solution need a special out-of-band
return path to send failure message to the root node of p2mp working
path. while for the second protection solution, as its protection
path is bidirectional , it is unnecessary to set up out-of-band
return path for sending failure message. .
4. Security Considerations
The security considerations for the authentication TLV need further
study.
5. IANA Considerations
TBD.
6. Acknowledgments
The authors would like to thank yaccov for giving a lot of good
comments and revising many syntax for the document. And thank
Malcolm Betts and other experts for Providing some good comments and
their input to and review of the current document .
7. References
Liu, et al. Expires March 2, 2012 [Page 12]
Internet-Draft MPLS-TP p2mp shared protection August 2011
7.1. Normative References
[ITU-T G.8131.1]
ITU-T, "ITU-T Recommendation(PTN Linear protection)",
Auguest 2011.
[RFC 5654]
IETF, "IETF RFC5654(MPLS-TP requirement)", September 2009.
[RFC 5921]
IETF, "IETF RFC5654(MPLS-TP framework)", July 2010.
7.2. Informative References
[L2VPN ICCP]
Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima,
Matthew Bocci, Thomas D. Nadeau, "Inter-Chassis
Communication Protocol for L2VPN PE Redundancy", Oct 2010.
[MPLS-TP Linear protection]
S. Bryant, N. Sprecher, H. van Helvoort,A. Fulignoli Y.
Weingarten, "MPLS transport profile Linear Protection",
July 2010.
[MPLS-TP Survivability Framework]
N. Sprecher, A. Farrel, "Multiprotocol Label Switching
Transport Profile Survivability Framework", June 2010.
[MPLS-TP linear protection]
Z.Haiyan, I.umansky, L. han,J.Ryoo, D'Alessandro , "Linear
Protection Switching in MPLS-TP", July 2010.
7.3. URL References
[MPLS-TP-22]
IETF - ITU-T Joint Working Team, "", 2008,
<http://www.example.com/dominator.html>.
Liu, et al. Expires March 2, 2012 [Page 13]
Internet-Draft MPLS-TP p2mp shared protection August 2011
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
Yuefeng Ji
Beijing University of Posts and Telecommunications
P.O. Box 128, No.10, Xi Tu Cheng Road
Beijing 100876
P.R.China
Email: jyf@bupt.edu.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
Yu jinghai
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52871606
Email: yu.jinghai@zte.com.cn
Zongpeng Du
Beijing University of Posts and Telecommunications
Email: duzongpeng@gmail.com
Liu, et al. Expires March 2, 2012 [Page 14]