MPLS Working Group Y. Huang
Internet-Draft Y. Jiang
Intended Status: Standards Track Huawei Technologies
Expires: April 2011 October 25, 2010
Signaling extension for MPLS ring protection
draft-huang-mpls-ring-signaling-extension-01.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 25, 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 & Jiang Expires April 25, 2011 [Page 1]
Internet-Draft Signaling Extension for MPLS 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.........................................8
4.1. LDP extension.........................................10
4.2. RSVP-TE extension......................................12
5. Security Considerations.....................................12
6. IANA Considerations........................................12
7. Conclusions................................................12
8. References.................................................12
8.1. Normative References...................................12
8.2. Informative References.................................13
9. Acknowledgments............................................13
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 solution for MPLS ring.
MPLS Fast Re-Route [MPLS-FRR] can 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 service LSPs 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 25, 2011 [Page 2]
Internet-Draft Signaling Extension for MPLS 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
MPLS Multi-Protocol Label Switching
MPLS-TP MPLS Transport Profile
SPME Sub-path Maintenance Element
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 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 packet outermost label is
service LSP label. That is to say, no SPME 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.
Huang & Jiang Expires April 25, 2011 [Page 3]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
3. Control layer, service LSPs crossing the ring can be created
normally by LSP signaling with the extension in section 4. The
extension is to send label switch information to downstream ring node
or backup node.
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 the 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. After
popping the protection label, the downstream node adjacent to the
failure can do the label switching work in working direction with
additional label switching information got from the failure node
during the setup of the service LSP. The detailed procedure and the
definition of the information is referred to section 4.
8. To protect failure of ingress or egress node of a ring, a backup
node can be assigned during MPLS ring 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 a closed LSP in CCW direction and 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
Huang & Jiang Expires April 25, 2011 [Page 4]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
3. The bottom of the stack will be denoted by the string "B" for
two or more label layer.
+---+ [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
Huang & Jiang Expires April 25, 2011 [Page 5]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
For example, the link between B and C goes down as shown in figure 2.
After recovering, the packet forwarding path is denoted by '***' in
the working direction and '###' in the protection direction.
The forwarding path and encapsulation on link 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, so 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. Then at node D, the service LSP drops the ring
after normal label switching.
3.1.2. Node Failure example
For example, the Node B goes down as shown in figure 3.
After recovering, the packet forwarding path is denoted by '***' in
working direction and '###' in protection direction.
The forwarding path and the encapsulation on link 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 25, 2011 [Page 6]
Internet-Draft Signaling Extension for MPLS 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] supported by label switching information
notified by node B during setup of the LSP. This notification
operation uses the signaling extensions defined in section 4. Node C
then sends out packet with [L4] to link C-D. At node D, the service
LSP drops the ring after normal label switching.
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
Each pair of adjacent nodes on the ring should deploy OAM continuity
check (CC) mechanism to detecting failures between each other. When
one node gets event(s) that the CC check to one peer node fails, it
will inform from the opposite direction to inform the event for the
ring. That is to say, using section OAM can do the job.
Huang & Jiang Expires April 25, 2011 [Page 7]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
Section OAM also can meet the need for multiple logical ring
instances be deployed in one physical link. The possible scenario in
industry regarding this is two tangent rings which share one or more
links between two ring nodes (the ring nodes can be adjacent or not).
Theoretically one may worry about the case that when do wrapping, how
to recognize different logical ring and push related protection label
on the packets. In reality, as long as we design the two ring under
the same policy, that is, taking CW (or vice versa) as working
direction on both rings (this is the most popular case), there is no
problem in question on the shared link(s).
How to perform the OAM CC and how to inform the failure event to the
right receiver, is out of scope of this document. We think that both
MPLS and MPLS-TP OAM mechanism can be used for the purpose.
4. Signaling extension
The purpose of the signaling extension is to backup the protected
node's label switching information to one backup node. Under ring
topology the backup type has two case:
Case 1: For protecting transit ring node, the backup node is the
immediate downstream node to the protected one.
Case 2: For protecting ingress/egress ring node, backup node is
provisioned by operator.
Case 1 can be illustrated in the same example shown in figure 3, the
normal forwarding path and labels on links are: A -> [L2] -> B -> [L3]
-> C -> [L4] -> D. During the LSP setup, when node B gets the mapping
label from C [L3], it allocate [L2] to node A and locally generate
label switching information <L2-to-L3> for forwarding. At this point
of time, Node C send a new message to Node C containing the local
switching information <L2-to-L3>.
When node C gets the message containing the label mapping information
<L2-to-L3>, combines it's local label switching information <L3-to-
L4>, and generates a new label mapping info as <L2-to-L4>. The new
label switching information can help node C to finish the work
described in section 3.1.2.
Every protected node should perform the signaling procedure like node
B in above example.
Note that above mechanism needs to do some label planning work to
avoid duplicate label for adjacent links (e.g. link C-D and link B-C
are adjacent links).
Huang & Jiang Expires April 25, 2011 [Page 8]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
Case 2 can be illustrated in figure 4.
[P1|L4|B]
+---+ ##########+---+
| F |-----------| A | <---LSP 1
+---+ +---+
#/ *\#
[P2|L4|B] #/ *\# [P6|L4|B]
#/ [L2] *\#
#/ *\#
+---+ +---+
| E | | B |
+---+ +---+
| \ */#
[L5] | \ [L3] */#
| X */# [P5|L4|B]
V \ */#
LSP 1 +---+ +---+ +---+
<---| T |<---| D |-----X-----+ C |
+---+ +---+ +---+
[L5] [L4]
Figure 4 Packet flow when node D failure
Definition for illustration:
Port E-T : Means physical port at node E which connects node T.
Backup id: An id number to correlate two ports.
To protect node D which is the egress node of some service LSPs (e.g.
LSP 1 in figure 4), a backup node E should be selected and configured.
The port E-T and port D-T are configured one same backup id for
example 1000.
When node D gets the allocated label [L5] from downstream node T
which is not the ring node, it allocate label [L4] to node C. At the
mean time, node D send a new message containing label mapping
information <L4-to-L5> and backup id 1000 to pre-configured backup
node E.
At node E, after getting the message, E generate a new local label
switching information <L4-to-L5> take in-port as ring port E-D and
out-port as the port E-T according to backup id.
Huang & Jiang Expires April 25, 2011 [Page 9]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
In figure 4, When E gets packets from the protection ring direction
with encapsulation [P2|L4|B], it pop the protection label and switch
[L4] to [l5] and send out the packet to node T. Node T can handle the
packet from port T-E just like it comes from port T-D.
4.1. LDP extension
A TLV bearing the label mapping information described above can meet
both case 1 and case 2. The TLV can be named as Label Mapping
Information TLV.
For LDP protocol, it use Notification message ([LDP] Section 3.5.1 )
to contain the new TLV. The TLV is optional.
If a LSR is configured to perform ring protection as section 3, after
it gets one label (egress label) from it's downstream peer and
allocate a new label (ingress label) to the peer LSR which stands at
upstream, it SHOULD send a Notification message containing the Label
Mapping Information TLV to the downstream LSR under the Case 1 or to
the backup LSR under the Case 2. The LSR can discriminate the
different cases by the fact that whether the egress port for the
label is the port which belongs to the ring.
If a LSR gets the Notification message which contains the Label-
Mapping-Info TLV, it SHOULD generate a new local label switching
information for forwarding. The LSR can recognize the cases by the
TLV content.
The Label-Mapping-Info TLV will be put in the optional parameter
field following the status TLV and be described as following:
Optional Parameter Type Length Value
Label-Mapping-Info TBD 20 See below
Label Mapping Information TLV 's format is shown in figure 5.
Huang & Jiang Expires April 25, 2011 [Page 10]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label Mapping Info(0x ??) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IMT | EMT | Reserved |
+---------------------------------------------------------------+
| Ingress Ring id/Backup id |
+---------------------------------------------------------------+
| Ingress Label |
+---------------------------------------------------------------+
| Egress Ring id /Backup id |
+---------------------------------------------------------------+
| Egress Label |
+---------------------------------------------------------------+
Figure 5 Label Mapping Info TLV format in LDP
Following gives some explanation of Label Mapping Info TLV.
IMT Ingress Mapping Type
0: Denote that the value in field Ingress Ring id/Backup id is the
ring id to which the LSP belongs at the ingress port.
1: Denote that the value in field Ingress Ring id/Backup id is the
backup id which the ingress port correlates.
Other: Reserved.
EMT Egress Mapping Type
0: Denote that the value in field Egress Ring id/Backup id is the
ring id to which the LSP belongs at the egress port.
1: Denote that the value in field Egress Ring id/Backup id is the
backup id which the egress port correlates.
Other: Reserved.
Ingress ring/backup id: The value of ingress ring id or backup id of
the ingress port.
Ingress Label: The value of ingress label.
Huang & Jiang Expires April 25, 2011 [Page 11]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
Egress ring/backup id: The value of egress ring id or backup id of
the egress port.
Egress Label: The value of Egress label.
4.2. RSVP-TE extension
TBD
5. Security Considerations
TBD
6. IANA Considerations
A new LDP protocol TLV code for Label-Mapping-Info TLV need to be
assigned by IANA.
RSVP-TE extension: 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.
Huang & Jiang Expires April 25, 2011 [Page 12]
Internet-Draft Signaling Extension for MPLS Ring Protection October 2010
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.
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 25, 2011 [Page 13]