Internet DRAFT - draft-liu-mpls-tp-p2mp-shared-protection
draft-liu-mpls-tp-p2mp-shared-protection
MPLS Working Group G. Liu
Internet-Draft ZTE Corporation
Intended status: Standards Track Y. Ji
Expires: September 2, 2012 Beijing University of Posts and
Telecommunications
j. Yu
X. Xu
ZTE Corporation
Z. Du
Beijing University of Posts and
Telecommunications
March 1, 2012
Multiprotocol Label Switching Transport Profile p2mp Shared Protection
draft-liu-mpls-tp-p2mp-shared-protection-03
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 September 2, 2012 [Page 1]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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 September 2, 2012.
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.
Liu, et al. Expires September 2, 2012 [Page 2]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Liu, et al. Expires September 2, 2012 [Page 3]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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 p2mp protection path to protect each
protected p2mp working path, and these p2mp protection path maybe
share common segment resource. when detecting defects on a p2mp
working path 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 implement
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 wasted 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 September 2, 2012 [Page 4]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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 p2mp protection path to
protect its corresponding protected p2mp working path.and these
protection paths maybe shared common segment resource. When a
failure is detected on a protected p2mp working path, the leaf node
which has already detected the failure will notify root node of the
failure message. then the root node of protection path will be basis
on the priority of protected service or failure to select the highest
priority service to be protected. then it will notity all leaf nodes
of which working path will be protected by extensive PSC packet as
the following figure 1.As a result, the selected failure service will
switch to the protection path to be transported .
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
path to protect many p2mp working paths. However, in this mechanism
since the protected traffics are transported by different working
Liu, et al. Expires September 2, 2012 [Page 5]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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
which have defect and need to be protected. this p2mp LSP ID TLV
format is as the following figure 2
Liu, et al. Expires September 2, 2012 [Page 6]
Internet-Draft MPLS-TP p2mp shared protection March 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 September 2, 2012 [Page 7]
Internet-Draft MPLS-TP p2mp shared protection March 2012
+---+
+->| 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 September 2, 2012 [Page 8]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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 p2mp protection path to protect its
corresponding p2mp working path.and these protection paths will share
a few common segment resource.when a failure is detected on some
protected p2mp working path, it must notify the failure message to
the root node of its corresponding protection path. when the root
node of the protection path received the failure message, it must
compare the priority among these protection paths and select the
highest priority service to be tranported on its corresponding
protection path.and it notify each leaf node of the protection path
which protection path will be selected to use the common protection
resource by extending PSC message.
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
Liu, et al. Expires September 2, 2012 [Page 9]
Internet-Draft MPLS-TP p2mp shared protection March 2012
1-L1,L2) identified by ($) and p2mp working path 2(r2-p2mp Path
2-L2,L3) identified by (#).in order to protect the service, its
corresponding protection path( P-shared path-L1,L2) and (P-shared
path-L2,L3) identified by(@) will be pre-configured for working path
1 and working path 2. and the two protection path will share common
segment.
$ +----+
$ | L1 |
+-------------+ $ @ +----+
$ | P2MP Path 1 |
$ +-------------+ @
$ $ +----+
$ @ | L2 |
$ $ @ +----+
+----+ @ #
| R1 | @
+----+ @ X
| @
| @ #
+----+ +-------------+ @
| P | @ @ @ @ | shared path | #
+----+ +-------------+ @
| @ # +----+
| @ | L3 |
+----+ # @ +----+
| R2 | # #
+----+ # +-------------+ # #
# | P2MP Path 2 | #
# +-------------+
NOTE:
@: P2MP protection path LSP;
$: P2MP Working Path LSP 1
#: P2MP Working Path LSP 2
X: failure
Figure 4
Liu, et al. Expires September 2, 2012 [Page 10]
Internet-Draft MPLS-TP p2mp shared protection March 2012
when the p2mp working path LSP 1 and the p2mp working path LSP 2 have
a failure at the same time, The leaf node L2 will generate failure
notify message to send to the root node R1 and R2 . Then R1 and R2
will notify the root node(P) of the failure. so the root node P will
select the higher priority working path to be protected and notify
all leaf nodes of the protection path which working path will be
protected by extensive PSC packet including selective protected p2mp
LSP identifier. when these leaf nodes receive the extensive PSC
packet, they decide which path to receive the service packet. here if
the root node P select working path 1 to be protected. so the leaf
nodes L1,L2 will receive the service packet from protection path(P-
shared path-L1,L2).but the leaf nodes(L2,L3) of the working path 2
will still receive the service packet from their working path 2. .
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. .
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 September 2, 2012 [Page 11]
Internet-Draft MPLS-TP p2mp shared protection March 2012
7.1. Normative References
[RFC 5654]
IETF, "IETF RFC5654(MPLS-TP requirement)", September 2009.
[RFC 5921]
IETF, "IETF RFC5654(MPLS-TP framework)", July 2010.
[RFC 6372]
IETF, "MPLS Transport Profile (MPLS-TP) Survivability
Framework", September 2011.
[RFC 6378]
IETF, "MPLS Transport Profile (MPLS-TP) Linear
Protection", November 2011.
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]
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>.
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
Liu, et al. Expires September 2, 2012 [Page 12]
Internet-Draft MPLS-TP p2mp shared protection March 2012
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
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
Xu xueqiong
ZTE Corporation
No.68, Zijinghua Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 52871606
Email: xu.xueqiong@zte.com.cn
Zongpeng Du
Beijing University of Posts and Telecommunications
Email: duzongpeng@gmail.com
Liu, et al. Expires September 2, 2012 [Page 13]
