MPLS Working Group X. Dai
Internet-Draft B. Wu
Intended status: Standards Track J. Yang
Expires: January 2, 2010 G. Liu
ZTE Corpoporation
July 1, 2009
Protection for P2MP Ring in MPLS-TP Networks
draft-dai-mpls-tp-p2mp-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.
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 January 2, 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.
Abstract
This document provides two possible solutions for protecting point to
Dai, et al. Expires January 2, 2010 [Page 1]
Internet-Draft Protection P2MP Ring July 2009
multipoint (P2MP) traffic distribution over a ring topology in
MPLS-TP networks. These two methods can protect any link or
node(except the root node)failure once a failure is detected through
MPLS-TP OAM mechanism.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions and terminologies . . . . . . . . . . . . . . . 3
3. Proposed protection schemes for P2MP ring . . . . . . . . . . . 4
3.1. scheme 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. scheme 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative references . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Dai, et al. Expires January 2, 2010 [Page 2]
Internet-Draft Protection P2MP Ring July 2009
1. Introduction
MPLS-TP is a joint ITU-T/IETF effort[RFC5317] to include an MPLS
Transport Profile within the IETF MPLS architecture to support the
capabilities and functionalities of a packet transport network as
defined by ITU-T. In the MPLS-TP requirements draft[MPLS-TP
Requirements], it is highlighted that the MPLS-TP architecture must
allow a smooth migration from traditional transport networks
(e.g.SONET/SDH) to packet transport networks, as well as support the
accelerating growth of packet-based services (such as VoIP, L2/L3
VPN, IPTV, RAN backhauling, etc.). That migration must be
accomplished preserving carriers investments in both Capital
Expenditure (CAPEX) and Operational Expenditure (OPEX) as much as
possible. On the one hand, most of today's deployed SDH/SONET
networks all over the world are based on ring topology; on the other
hand, applications of P2MP services become more and more important,
so it has great significance to investigate protection for P2MP
traffic in ring topology.
The solutions proposed in this document are data plane driven and are
thought to be able to work in absence of control plane.
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.
2.1. Abbreviations
MPLS-TP: Transport Profile for Multi-protocal Label Switching
OAM: Operations, Administration and Maintenance
P2MP: Point to multi-point
CC: Continuity Check
FLN: Farthest Leaf Node
2.2. Definitions and terminologies
Working path: A transport path that is used to transport normal user
traffic, under normal conditions.
Recovery path: A transport path that is dedicated to protect normal
user traffic in case of a failure of the Working path.
Dai, et al. Expires January 2, 2010 [Page 3]
Internet-Draft Protection P2MP Ring July 2009
Farthest Leaf Node: A leaf node on a working path that is farthest
from the root node.
3. Proposed protection schemes for P2MP ring
This section proposes two protection schemes for a P2MP ring. These
two schemes are homogeneous in most aspects, but have little
differences. In both schemes, MPLS-TP OAM[MPLS-TP OAM Requirements]
SHOULD be used on a MPLS-TP transport path to perform Continuity
Check (CC) operations.
3.1. scheme 1
In order to protect a P2MP working path of a ring topology, we
establish another P2MP transport path (we call it recovery path )to
protect a P2MP working path in case of a failure on the working path.
These two transport paths have the same root node and leaves, but in
opposite directions.
In this scheme, MPLS-TP OAM SHOULD be used on each MPLS-TP transport
path to perform Continuity Check (CC) operations. Once the farthest
leaf node on the working path can't receive MPLS-TP OAM CC packets
from the working path in a prescriptive time, a failure is detected
on that path. Furthermore, there should be a return path from the
FLN to the root node, which is used to inform the root node that a
failure is detected on the working path.
As for the working path, When a failure is detected by the FLN,FLN
will initiate a failure message and transmits it to the root node
through the return path. As soon as the root node receives this
failure message, it activates the recovery path, and then P2MP
traffic will be transported through the working path and recovery
path at the same time. At this situation, each leaf will receive
user traffic either from the working path or recovery path based a
local policy.
In figure 1, an example of this scheme to a P2MP ring topology is
depicted. The source of a P2MP traffic flow is connected to node A
and two P2MP LSPs are created with A as ingress node and B, D and F
as egress nodes in order to deliver traffic to different leaves. The
working path is A-[B]-C-[D]-E-[F], and the protection path is A-[F]-
E-[D]-C-[B]. square brackets indicate a leaf node.
Dai, et al. Expires January 2, 2010 [Page 4]
Internet-Draft Protection P2MP Ring July 2009
Root Node
|
+---+ +---+
Leaf 3<-| F |-------------| A |
+---+ +---+
/ \
/ \
/ \
+---+ +---+
| E | | B |-->Leaf 1
+---+ +---+
\ /
\ /
\ /
+---+ +---+
| D |-------------| C |
+---+ +---+
|
V
Leaf 2
Figure 1: P2MP ring topology example
Under normal situations, user traffic is transmitted through the
working path to different leaves. In case of a failure, let's say on
link B-C(see figure 2), the FLN (node F in this case)can't receive
MPLS-TP OAM CC packets from the working path. As soon as detecting
this failure, node F initiates a failure message and transports it to
node A through the return path which is configured in advance. When
node A receives this failure message, it will activate the recovery
path at once. Thus, user traffic will be transported both through
the working path and the recovery path, while each leaf node will
receive user traffic either from the working path or the recovery
path. In this example, leaf node B will receive traffic from the
working path, while leaf node D and E will receive traffic from the
recovery path.
Dai, et al. Expires January 2, 2010 [Page 5]
Internet-Draft Protection P2MP Ring July 2009
Root Node
|
+---+ +---+
Leaf 3<**| F | | A |
+---+ * * * * * * +---+
* &
* &
* &
+---+ +---+
| E | | B |&&>Leaf 1
+---+ +---+
*
* XXXX
*
+---+ * * * * * +---+
| D | | C |
+---+ +---+
*
*
V
Leaf 2
Figure 2: a failure of link B-C in scheme 1
Such scheme can also protect a node failure, except a failure of the
root node, and protection procedures are the same as a link failure
described above.
3.2. scheme 2
The second scheme has many similarities with the first scheme
described above, with the difference that a transport path is a
closed ring. That is to say, the P2MP traffic is sent to all leaves
from the root's transmiting port, while will be returned to the root
node through the root's receiving port. This scheme also preserved a
P2MP recovery path for a working path, which is in opposite
directions with respect to the working path.
MPLS-TP OAM SHOULD be used on the working path to perform Continuity
Check (CC) operations. Once the root's receiving port can't receive
MPLS-TP CC packets from the working path, a failure is detected on
that path. Thus, the root node activates the recovery path, and user
traffic will be transported through both the working path and the
recovery path, and each leaf node will receive traffic either from
the working path or the recovery path, which is based on a local
policy.
Dai, et al. Expires January 2, 2010 [Page 6]
Internet-Draft Protection P2MP Ring July 2009
With respect to packets arrived at the root node through it's
receiving port, only MPLS-TP OAM CC packets will be accepted, all the
other packets MAY be disposed.
In picture 1, an example of this scheme to a P2MP ring topology is
depicted. In this scheme, the working path and recovery path are
both chosed rings. Concretely, The working path is
A-[B]-C-[D]-E-[F]-A, and the recovery path is A-[F]-E-[D]-C-[B]-A.
square brackets indicate a leaf node.
Under normal situations, user traffic is transmitted through the
working path. In case of a failure, let's say on link B-C, root node
A can't receive MPLS-TP CC packets through it's receiving port, which
means a failure has occurred on the working path. As soon as
detecting this failure, node A will activate the recovery path at
once. Thus, the user traffic will be transported both through the
working path and the recovery path, while each leaf node will receive
user traffic either from the working path or the recovery path.
Let's see an example in figure 3:
Root Node
|
+---+ +---+
Leaf 3<@@| F | @ @ @ @ @ @ | A |
+---+ +---+
@ #
@ #
@ #
+---+ +---+
| E | | B |##>Leaf 1
+---+ +---+
@
@ XXXX
@
+---+ +---+
| D | @ @ @ @ @ @ | C |
+---+ +---+
@
@
V
Leaf 2
Figure 3: a failure of link B-C in scheme 2
This scheme can also protect a node failure, except a failure of the
Dai, et al. Expires January 2, 2010 [Page 7]
Internet-Draft Protection P2MP Ring July 2009
root node, and protection procedures are the same as a link failure
described above.
Besides, this scheme is especially applicable to scenes that most of
nodes on a ring are leaves.
4. Comparison
Both schemes proposed in this document can protect the working path
from a link failure or a node failure, with little differences in the
mechanisms.
Scheme 2 is better than scheme 1 in two aspects. First, scheme 2
doesn't need a return path that prereserved to transport failure
messages, since the root node itself can detect the failure and
activates the recovery path. Secondly, in scheme 2, fault detection
point and protection implemented point are at the same point, so it
is simpler than scheme 1. But it also has some disadvantages, one of
which is on bandwidth utilization, to be more specific, it wastes
bandwidth between the FLN and the root node on the working path.
5. IANA Considerations
TBD.
6. Security Considerations
This section will be added in a future version.
7. Acknowledgement
TBD.
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
Dai, et al. Expires January 2, 2010 [Page 8]
Internet-Draft Protection P2MP Ring July 2009
8.2. Informative References
[MPLS-TP OAM Requirements]
Vigoureux, M., "Requirements for OAM in MPLS Transport
Networks", March 2009.
[MPLS-TP Requirements]
Niven-Jenkins, B., "MPLS-TP Requirements", May 2009.
Authors' Addresses
Xuehui Dai
ZTE Corpoporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: dai.xuehui@zte.com.cn
Bo Wu
ZTE Corpoporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877276
Email: wu.bo@zte.com.cn
Jian Yang
ZTE Corpoporation
5F,R&D 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
Dai, et al. Expires January 2, 2010 [Page 9]
Internet-Draft Protection P2MP Ring July 2009
Guoman Liu
ZTE Corpoporation
4F,RD Building 1,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52871606
Email: liu.guoman@zte.com.cn
Dai, et al. Expires January 2, 2010 [Page 10]