MPLS Working Group Y. Huang
Internet-Draft Y. Jiang
Intended Status: Standards Track Huawei Technologies
Expires: April 2011 October 19, 2010
Signaling extension for MPLS ring protection
draft-huang-mpls-ring-signaling-extension-00.txt
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 April 19, 2011.
Abstract
When using Multi-Protocol Label Switching (MPLS) Label Switched Paths
(LSP) on a ring topology, it is needed to minimize the labels for
protection purpose and minimize the configuration effort. Though MPLS
Fast Re-Route [MPLS-FRR] can achieve automatic LSP service protection,
it is not optimized as many labels are used to create lots of detour
LSPs.
This document describes a MPLS ring mechanism and some extensions on
signaling protocol to facilitate the establishment of Label Switched
Paths (LSPs) using Label Distribution Protocol [LDP] or RSVP-TE
protocol [RSVP-TE] to achieve automated link and node protection.
Huang & Expires April 19, 2011 [Page 1]
Internet-Draft MPLS Signaling extension for ring protection October 2010
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Ring Protection Scheme.........................................3
3.1. P-to-p LSP example........................................4
3.1.1. Link Failure example.................................4
3.1.2. Node Failure example.................................6
3.2. p-t-mp LSP example........................................7
3.2.1. Link Failure example.................................7
3.2.2. Node Failure example.................................7
3.3. OAM Consideration.........................................7
4. Signaling extension............................................7
4.1. LDP extension.............................................7
4.2. RSVP-TE extension.........................................8
5. Security Considerations........................................8
6. IANA Considerations............................................8
7. Conclusions....................................................8
8. References.....................................................8
8.1. Normative References......................................8
8.2. Informative References....................................8
9. Acknowledgments................................................9
1. Introduction
More and more network operators have considered using unified IP/MPLS
technology in a single network infrastructure to provide multi-
service, including fixed and mobile services. Since a large amount of
access and aggregation network segments are fiber ring topology
network, it is expected to use MPLS on a ring topology network. The
industry is interested to find a lightweight planning, easy provision
and little resource consumption for a MPLS ring solution.
MPLS Fast Re-Route [MPLS-FRR] is a good technology to automatically
create protection LSP and minimize the network provision work, but it
is not optimized since it uses many labels and creates lots of detour
LSPs, especially in ring topology.
This document describes a simple MPLS ring mechanism under which
numerous LSP service can be created automatically across the ring
with some extensions on signaling protocol. The extensions on
signaling solves label switch disruption because of node failure.
Section 3 describes the ring protection scheme based on wrapping
Huang & Jiang Expires April 19, 2011 [Page 2]
Internet-Draft MPLS Signaling extension for ring protection October 2010
mechanism. Section 4 describes the signaling extensions for both LDP
and RSVP-TE.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [RFC2119].
CW Clock Wise
CCW Counter Clock Wise
3. Ring Protection Scheme
Several Internet Drafts on MPLS Ring said that both Steering mode and
Wrapping mode can be used in a ring network. The scheme in this
document only discusses wrapping mechanism. The idea is that steering
method takes no advantage of ring topology and can just be achieved
by known technology, such as MPLS TE FRR or PW redundancy. It is not
indented to compare the two methods and to say which one is better
than the other in this document and it should only be up to the
operator's choices.
In general, the scheme includes several technical points as following.
1. For data transport layer on the ring, for each upstream
/downstream direction, assigning CW as working path direction and
CCW as protection path direction or vice versa. (The following
examples in this document take CW as working direction on the
ring). On working ring direction (CW), the transport outermostlabel
is service LSP label. That is to say, no PSME label be added to
service LSP packet at ring working direction.
2. Pre-provision a closed protection LSP on ring protection
direction. The ring protection LSP is to protect all service LSPs
when a link or node failure occurs.
3. Control layer, service LSPs crossing the ring can be created
normally by LSP signaling with the extension provided in section
4. The extension is to send label switch information to downstream
ring node or backup node.
Huang & Jiang Expires April 19, 2011 [Page 3]
Internet-Draft MPLS Signaling extension for ring protection October 2010
4. Normally, service LSP packet is forwarded along working direction,
each ring node performs the normal MPLS forwarding at service LSP
label level.
5. When a link or node failure occurs, upstream node adjacent to the
failure performs wrapping and pushes a protection ring label to
the service LSP packet, and the packet is wrapped around in the
protection ring direction and goes to downstream node adjacent to
the failure.
6. For a link failure, the downstream node adjacent to the failure
is its immediate downstream node, it just pops the protection
label and forwards the packet to the working direction.
7. For a node failure, the downstream node adjacent to the failure
is one hop away from the upstream node adjacent to the failure
performs the wrapping operation. Then the downstream node adjacent to
the failure can do the label switching work by receiving the label
switching information from the failure node during the setup of the
service LSP. How to notify the LSP information will be defined in
section 4.
8. To protect failure of ingress or egress node of a ring, a backup
node can be assigned during provisioning. The signaling extensions
defined in section 4 also provide the ability to notify the backup
node the label switching information.
Following sections provide some examples in details.
3.1. P-to-p LSP example
3.1.1. Link Failure example
A LSP (LSP 1 in figure 1) crosses ring nodes A->B->C->D with
labels: . . . [L1]->[L2]->[L3]->[L4]->[L5]-> . . .
A protection LSP is denoted as: [p1]->[p2]->[p3]->[p4]->[p5]->[p6]-
>[p1].
Here we give some symbol illustration for the label stack
1. The label stack will be enclosed in square brackets ("[]")
2. Each level in the stack will be separated by the '|' character
3. The bottom of the stack will be denoted by the string "B" for
two or more label layer.
Huang & Jiang Expires April 19, 2011 [Page 4]
Internet-Draft MPLS Signaling extension for ring protection October 2010
+---+ [P1] +---+
| F |-------------| A | <- LSP 1 [L1]
+---+ +---+
/ \
[P2]/ [L2]\[P6]
/ \
+---+ +---+
| E | | B |
+---+ +---+
\ /
[P3]\ [L3]/[P5]
\ /
+---+ [L4] +---+
LSP 1[L5]<-- | D |-------------| C |
+---+ [P4] +---+
Figure 1: Labels allocation example for p-t-p LSP protection
+---+ +---+
| F |-----------| A | <---LSP 1
+---+ ##########+---+
/ # [P1|L3|B] # \ *
/ # # \ * [L2]
/ #[P2|L3|B] [P6|L3|B] # \ *
/ # # \ *
+---+ +---+
| E | | B |
+---+ +---+
\ #[P3|L3|B] /
\ # x
\ # /
\ # [P4|L3|B] /
+---+###########+---+
LSP 1<---| D |-----------+ C |
+---+***********+---+
[L4]
Figure 2: packet flow when link B-C failure
For example, the link between B and C goes down as shown in figure 2.
The packet forwarding path is denoted by '***' in the working
direction and '###' in the protection direction.
Huang & Jiang Expires April 19, 2011 [Page 5]
Internet-Draft MPLS Signaling extension for ring protection October 2010
The forwarding path is: A-> [l2]-> B ->[P6|L3|B] -> A -> [P1|L3|B]
-> F -> [P2|L3|B] -> E -> [P3|L3|B] -> D -> [P4|L3|B] -> C -> [L4] ->
D.
When node B finds the link to C is failed, it push protection label
[P5] to the out going packet with [L3] at egress port to C, thus the
label stack is [P5|L3|B], do wrapping and switch [P5|L3|B] to
[P6|L3|B], then send out to link B-A.
Node A,F,E,D just do Protection label switching and send the packet
to C, and C receives the packet with [P4|L3|B].
When node C finds the link to B has failed, at egress port to B, it
pops protection label [P5] and extracts [L3], do wrapping and switch
[L3] to [L4] based on normal label switching table entry, then send
out [L4] to link C-D.
3.1.2. Node Failure example
For example, the Node B goes down as shown in figure 3.
The packet forwarding path is denoted by '***' in working direction
and '###' in protection direction.
The forwarding path is: A -> [P1|L2|B] -> F -> [P2|L2|B] -> E ->
[P3|L2|B] -> D -> [P4|L2|B] -> C -> [L4] -> D.
When node A finds the link to B is failed, it push protection label
[P6] to the outgoing packet with [L2] at egress port to B, thus the
label stack is [P6|L2|B], do wrapping and switch [P6|L2|B] to
[P1|L2|B], then send out to link A-F.
Node F,E,D just do Protection label switching and send the packet to
C, and C receives the packet with [P4|L2|B].
Huang & Jiang Expires April 19, 2011 [Page 6]
Internet-Draft MPLS Signaling extension for ring protection October 2010
+---+ +---+
| F |-----------| A | <---LSP 1
+---+ ##########+---+
/ # [P1|L2|B] \
/ # \ [L2]
/ #[P2|L2|B] X
/ # \
+---+ +---+
| E | | B |
+---+ +---+
\ #[P3|L2|B] /
\ # X
\ # /
\ # [P4|L2|B] /
+---+###########+---+
LSP 1<---| D |-----------+ C |
+---+***********+---+
[L4]
Figure 3: packet flow when node B failure
When node C finds the link to B is failed, it pops the protection
label [P5] and gets [L2] at egress port to B, does wrapping and
switches [L2] to [L4] based on label switching information notified
by node B during setup of the LSP using the signaling extensions
defined in section 4, and then send out packet with [L4] to link C-D.
3.2. p-t-mp LSP example
TBD
3.2.1. Link Failure example
TBD
3.2.2. Node Failure example
TBD
3.3. OAM Consideration
TBD
4. Signaling extension
4.1. LDP extension
TBD
Huang & Jiang Expires April 19, 2011 [Page 7]
Internet-Draft MPLS Signaling extension for ring protection October 2010
4.2. RSVP-TE extension
TBD
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Conclusions
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.
[MPLS-FRR] P. Pan, G. Swallow and A. Atlas., " Fast Reroute
Extensions to RSVP-TE for LSP Tunnels ", BCP 14, RFC 4090,
May 2005.
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
8.2. Informative References
[Inf-1] Y. Weingarten, et al, "MPLS-TP Ring Protection", August
2010.
[Inf-2] I. Umansky, et al, "MPLS-TP Ring Protection Switching
(MRPS)", August 2010.
[Inf-3] S. Kini, et al, "Efficient Fast Re-route (FRR) using
Facility backup in ring topology", August 2010. [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Huang & Jiang Expires April 19, 2011 [Page 8]
Internet-Draft MPLS Signaling extension for ring protection October 2010
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yong Huang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: huang.yong@huawei.com
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: yljiang@huawei.com
Copyright Notice
Copyright (c) 2010 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.
Huang & Jiang Expires April 19, 2011 [Page 9]