Internet DRAFT - draft-liu-mpls-tp-p2mp-linear-protection
draft-liu-mpls-tp-p2mp-linear-protection
MPLS Working Group G. Liu
Internet-Draft ZTE Corporation
Intended status: Informational March 13, 2013
Expires: September 14, 2013
Applicability of MPLS-TP Linear protection for p2mp
draft-liu-mpls-tp-p2mp-linear-protection-01
Abstract
In MPLS-TP requirement document(rfc5654), there is a requirement to
support 1+1 and 1:n protection for p2mp connectivity. The
requirement was described in MPLS-TP Survivability Framework
document(RFC 6372) and draft-ietf-mpls-tp-p2mp-framework. The basic
protocol for linear protection was specified in the MPLS-TP Linear
Protection document [RFC 6378] but is limited to 1+1 and 1:1
protection for p2p connectivity. in addtion, The 1:N protection in
which all of working transport paths and the protection path have the
same end points was specified in MPLS-TP 1:N protection document
(draft-ietf-mpls-tp-1toN-protection).This document applies the
existing PSC(RFC 6378) and extensive PSC protocol(draft-ietf-mpls-tp-
1toN-protection) to support scenarios of protecting the p2mp path by
extending the existing p2p linear protection mechanism. .
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.
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."
Liu Expires September 14, 2013 [Page 1]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
This Internet-Draft will expire on September 14, 2013.
Copyright Notice
Copyright (c) 2013 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.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. 1+1 p2mp protection . . . . . . . . . . . . . . . . . . . 3
1.2. 1:1 p2mp per-tree protection . . . . . . . . . . . . . . 4
1.3. 1:1 p2mp per-leaf protection . . . . . . . . . . . . . . 5
1.4. 1:1 p2mp branch path protection . . . . . . . . . . . . . 5
1.5. 1:n p2mp shared protection . . . . . . . . . . . . . . . 6
2. Conventions used in this document . . . . . . . . . . . . . . 7
3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 8
4. Switch Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.1. 1+1 protection operation . . . . . . . . . . . . . . . . 9
4.2. 1:1 p2mp per-tree protection operation . . . . . . . . . 9
4.3. 1:1 p2mp per-leaf protection operation . . . . . . . . . 9
4.4. 1:1 p2mp branch path protection operation . . . . . . . . 10
4.5. 1:n p2mp shared protection operation . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
8.3. URL References . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Liu Expires September 14, 2013 [Page 2]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
The MPLS Transport Profile(MPLS-TP) Requirement document(RFC5654) and
MPLS-TP P2MP Framework document both describe the requirement that
unidirectional 1+1 and 1:n protection for p2mp connectivity must be
supported. while the MPLS-TP Survivability Framework(RFC6372) is
only a framework for survivability in MPLS-TP network.
MPLS-TP Linear protection document(RFC6378) defines a Protection
State Coordination(PSC) protocol that supports 1+1 and 1:1 protection
architectures descirbed in MPLS-TP Survivability Framework. The PSC
protocol is a single-phase protocol that allows the two endpoints of
the protection domain to coordinate the protection switching
operation when a change of state is detected on the transport path of
the protection domain.
MPLS-TP 1:N protection document(draft-ietf-mpls-tp-1toN-protection)
uses a two-phase extensive PSC protocol to protect multiple working
paths by a single protection path.
As for the p2mp path, It has multiple leaf nodes and is still
undirectional, so it is not good for p2mp path to use the protection
mechanism in RFC6378 and draft-ietf-mpls-tp-1toN-protection. The
document is an applicability of the existing PSC protocol and the
extensive PSC protocol to support protection of p2mp path by
extending the existing linear protection mechanism.
1.1. 1+1 p2mp protection
This protection is a specific protection that use one designated
protection path to protect one working path. It is fully pre-
allocated in the sense that the route and bandwidth resource of the
protection path is reserved for the working path, The source root
node will bridge both the working path and the protection path at the
same time. while the sink leaf nodes will select one of the two
paths to receive the traffic . As it is unnecessary to coordinate the
switch state between the root node and the leaf nodes , the PSC
protocol is not needed in the 1+1 protection mechanism.
+---+
+| L1|
+ +---+
+ @
+ @
+ @
+---+ +-------------+ @
| r |+ + + + +->| woking path | @
Liu Expires September 14, 2013 [Page 3]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
+---+ | | @
@ +-------------+ @
@ +
@ @ +
@ +------------+ + +---+
@ | protection | @ @ @ @ | L2|
@ | path | +---+
+------------+
NOTE:
@@@@@@: p2mp protection path
+++++: p2mp working path
Figure 1: 1+1 p2mp protection
Figure 1 shows a protection domain with one working path and its
corresponding protection path.For 1+1 protection mechanism, the p2mp
traffic must be transported on both working path and protection path
at any time. So the source root node always bridges the p2mp traffic
into both working path and protection path. While the sink leaf node
L1 and L2 will select one of the two paths to receive the traffic
based on the performance of the two paths. It isn't necessary to
coordinate the switch state between the source root node and the sink
leaf nodes. So it can't use the PSC protocol for the protection
mechanism;
1.2. 1:1 p2mp per-tree protection
The protection mechanism will still use one designated p2mp
protection path to protect one p2mp working path.While the source
root node only bridges one of the two paths at any time. All sink
leaf nodes select the same p2mp path to receive the traffic. In
addition, As the root node and leaf nodes need to coordinate to
select the same p2mp path to send and receive the p2mp traffic. it
Must use the existing PSC protocol to coordinate the switch state
between the root node and the leaf nodes.
Just as the above figure 1, Under normal condition, The p2mp traffic
will be transported by only the working path from node r to node L1
and L2. When a defect is detected on the working path. the source
Liu Expires September 14, 2013 [Page 4]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
node r will bridge the traffic into its corresponding protection
path. Then it should send PSC packet to all leaf nodes L1 and L2 to
notify them to select the protection path to receive the p2mp
traffic.
1.3. 1:1 p2mp per-leaf protection
This protection is similar to the above protection mechanism.It still
needs to pre-configure one p2mp protection path to protect a p2mp
working path. When a defect is detected on the working path. the
source root node firstly bridge both the working path and the
protection path to send the traffic on both paths. While the leaf
nodes will select one of the two paths to receive the traffic based
on whether the working path has defect. Here it is unnecessary to
use PSC protocol to coordinate the switch state between the root node
and the leaf nodes.
Just as the above figure 1,When a defect is detected on one branch
path of the p2mp working path, For example, Path(r-L1) or path(r-L2)
has a defect, The source root node r will firstly send the traffic on
both the working path and the protection path. L1 or L2 will select
one of the two paths to receive the traffic based on whether to have
a defect on its branch path(r-L1) or path(r-L2)..
1.4. 1:1 p2mp branch path protection
The protection mechanism will pre-configure one p2p protection path
for each branch path of a p2mp working path. Each branch path is
disjointed from its p2p protection path. The protection mechanism is
similar to 1:1 protection mechanism in MPLS-TP linear
protection(RFC3678), It needs to use the PSC protocol to coordinate
the switch state between the root node and the leaf nodes.
+---+
@ @ @ @ @ @ | L1|
@ ++---+
@ +
@ +
@ +
+---+ @ +-------------+
| r |+ + + + +->| woking path |
+---+ | |
@ +-------------+
@ +
@ +
@ + +---+
Liu Expires September 14, 2013 [Page 5]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
@ + | L2|
@ @ @ @ +---+
NOTE:
@@@@@@: p2p protection path
+++++: p2mp working path
Figure 2
Just as the above figure 2, It will pre-configure one p2p protection
path for each branch path(r-L1) and (r-L2) individually.When a defect
is detected on the branch path. the root node r will send PSC packet
to its peer leaf node L1 or L2 immediately , Then the protected
traffic will be switched into its p2p protection path to be
transported. While the leaf node L1 or L2 will select the protection
path to receive the traffic
1.5. 1:n p2mp shared protection
The protection will pre-configure one p2mp shared protection path to
protect multiple p2mp working paths which maybe have differnet end
points. So the leaf nodes of the p2mp shared protection path are all
leaf nodes of these protected p2mp working paths.When a defect is
deteced on a working path, the root node of the protection path will
send the existing extensive PSC protocol packet to its leaf nodes to
identify which p2mp working path will be selected to be protected.
When the leaf node receives the PSC packet and decides how to process
the traffic packet from the p2mp shared protection path.Just as
figure 3.
+---+
+->| L1|
+ +---+
+ @
+ @
+ @
+---+ +-------------+ @
Liu Expires September 14, 2013 [Page 6]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
| r |+ + + + +->| P2MP path 1 | @
+---+ | | @
$ @ +-------------+ @
@ +
$ @ @ +
@ +------------+ + +---+
$ @ | protection | @ @ @ @-> | L2|
@ | path | $+---+
$ +------------+ $
@ $
$ @
+------------+ $ @ +---+
$ | P2MP |$ $ $ @-> | L3|
$ | Path 2 | +---+
+------------+
NOTE:
@@@@@@: p2mp shared protection path
+++++: p2mp working path 1
$$$$$: p2mp working path 2
Figure 3
A single p2mp shared protection path is used to protect p2mp working
path 1 and p2mp working path 2. node L1 and L2 are the sink leaf
nodes of the p2mp working path 1. While node L2 and L3 are the sink
leaf nodes of the p2mp working path 2. The leaf nodes of the p2mp
shared protection path are L1 , L2 and L3.When a defect is detected
on both the working path 1 and the working path 2 at the same time.
The root node r of the p2mp shared protection path will select a
higher priority working path to be protected. Then the source root
node sends extensive PSC protocol packet to all leaf nodes L1,L2 and
L3 by the p2mp shared protection path.The leaf nodes L1,L2 and L3 can
judge whether to receive the traffic from the protection path based
on the extensive PSC protocol packet.
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.
Liu Expires September 14, 2013 [Page 7]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
OAM: Operations, Administration, Maintenance
LSP: Label Switched Path.
TLV: Type Length Value
P2MP:Point to Multi-Point
P2P:Point to Point
PSC:Protection State Coordination
SD:Signal Degrade
SF:Signal Fail
NR No Request
MPLS:Multi-Protocol Label Switching
MPLS-TP:Multi-Protocol Label Switching Transport Profile
3. Coordination protocol
Some protection mechanisms in this document need PSC protocol to
coordinate switch state between end points of a protection domain.
It will use the existing PSC protocol to be defined in MPLS-TP Linear
protection(RFC6378) in the 1:1 p2mp protection scenario including 1:1
p2mp per-tree protection , 1:1 P2MP branch path protection. The PSC
protocol in detail maybe reference to the MPLS-TP linear
protection(RFC6378). While 1:n shared p2mp protection may use the
extensive PSC protocol defined in the MPLS-TP 1:N protection(draft-
ietf-mpls-tp-1ton-protection) to implement the protection.So the
procedure of extensive PSC protocol maybe reference to the mpls-tp
1:N protection document. But the 1:n shared p2mp protection in this
document only uses single-phase protocol which is different from the
1:n protection for p2p path. And it is only non-locking operation
and the value of L field can't be set. In addition, It is
unnecessary for the protection mechanism to wait for peer node's
Acknowledge(WFA), So the parameter of WFA timer isn't necessary in
this document.
4. Switch Procedure
Liu Expires September 14, 2013 [Page 8]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
In all above protection mechanisms, They must firstly pre-configure
protection path for one or multiple p2mp working path. Then They
detect whether to have a defect on the working path. If a defect is
detected, the end point of the p2mp working path will swich the
traffic from its working path to its pre-configurated protection path
4.1. 1+1 protection operation
The procedure of 1+1 protection operation is the following :
1 Under normal condition, The root node bridges the protected p2mp
traffic into its working path and protection path, While its sink
leaf nodes will select the working path to receive the traffic.
2 A defect is detected on the working path, some leaf nodes will
select its protection path to receive the traffic packet which have
defect on their branch path.of the working path
4.2. 1:1 p2mp per-tree protection operation
The procedure of this protection switch is the following phase:
1 Under normal condition, The root node and leaf nodes will send or
receive the traffic by their working path.And the root node will send
NR(0,0) to all leaf nodes by PSC packet.
2 When a defect is already detected on the working path, the root
node will bridge from the working path to its corresponding
protection path. Then send SF(1,1) to all leaf nodes by PSC packet..
3 The leaf nodes receive the SF(1,1) PSC packet, All of them will
switch to receive the traffic by their protection path.
4.3. 1:1 p2mp per-leaf protection operation
The procedure of the protection is the following :
1 The root node will select its working path to send the traffic
under normal condition ,And each leaf node still selects the working
path to receive the traffic.
2 When a defect is detected on a branch path of the p2mp working
path. the root node will bridge both the working path and the
protection path . The leaf node will select one of the two paths to
receive the traffic based on whether a defect happens on the working
path.
Liu Expires September 14, 2013 [Page 9]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
3 If a leaf node detect a defect on its branch path of the p2mp
working path, IT will select its corresponding protection path to
receive the p2mp traffic packet. or else, it will continue to
receive the p2mp traffic packet from its working path.
4.4. 1:1 p2mp branch path protection operation
The procedure of the protection operation is the following :
1 Under normal condition, The root node and all leaf nodes of a p2mp
traffic will select their p2mp working path to send and receive the
traffic. At the same time, The root node sends NR(0,0) PSC packet to
each leaf node by its p2p protection path periodically.
2 When a defect is detected on a branch path of the p2mp working
path, The root node will bridge the traffic into its corresponding
p2p protection path and send SF(1,1) PSC packet to the leaf node of
the failed branch path.
3 The leaf node receives SF(1,1) PSC packet,It will switch from the
working path to the p2p protection path to receive the traffic.Other
leaf nodes will still receive the traffic from the working path.
4.5. 1:n p2mp shared protection operation
the procedure of this protection operation is the following :
1 Under normal condition, The root node and all leaf nodes will
select their p2mp working path to send and receive the traffic, The
root node sends NR(0,0) PSC packet to all leaf nodes of the p2mp
protection path periodically.
2 A defect is detected on one or multiple p2mp working path , The
root node will select the highest priority working path to be
protected.and send SF(n,n) to all leaf nodes of the shared protection
path. Here n indicates the identifier index of the p2mp working path
to be protected.At the same time, The root node begin to send the
traffic to be selected on the p2mp shared protection path.
3 When all leaf nodes of the p2mp shared protection path receive
SF(n,n) PSC packet. they will know whether to receive the traffic
from the p2mp shared protection path. If a leaf node is a sink node
of the p2mp working path to be protected, it will receive the traffic
from the shared protection path. or else, It directly abandon the
traffic from the p2mp shared protection path.
5. Security Considerations
Liu Expires September 14, 2013 [Page 10]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
TBD
6. IANA Considerations
TBD
7. Acknowledgments
TBD
8. References
8.1. Normative References
[RFC5654] IETF, "IETF RFC5654(MPLS-TP requirement) ", September
2009.
[RFC5921] IETF, "IETF RFC5654(MPLS-TP framework) ", July 2010.
[RFC6372] IETF, "MPLS Transport Profile (MPLS-TP) Survivability
Framework ", September 2011.
[RFC6378] IETF, "MPLS Transport Profile (MPLS-TP) Linear Protection
", November 2011.
8.2. Informative References
[draft-ietf-mpls-tp-1ton-protection-00]
E. Osborne, F. Zhang, Y. Weingarten, , "MPLS-TP 1toN
Protection ", August 2012.
[draft-ietf-mpls-tp-p2mp-framework-00]
D. Frost, S. Bryant,M. Bocci, L. Berger, , "A Framework
for Point-to-Multipoint MPLS in Transport Networks",
January 2013.
8.3. URL References
[MPLS-TP-22]
IETF - ITU-T Joint Working Team, 2008,
<http://www.example.com/dominator.html>.
Author's Address
Liu Expires September 14, 2013 [Page 11]
Internet-Draft MPLS-TP P2MP Linear protection March 2013
Guoman Liu
ZTE Corporation
No.50, Ruanjian Road, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86 025 88014227
Email: liu.guoman@zte.com.cn
Liu Expires September 14, 2013 [Page 12]
