draft-ietf-mpls-tp-ring-protection-00.txt   draft-ietf-mpls-tp-ring-protection-01.txt 
Network Working Group Y. Weingarten Network Working Group Y. Weingarten
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: May 17, 2012 Cisco Expires: August 18, 2012 Cisco
N. Sprecher N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
D. Ceccarelli D. Ceccarelli
D. Caviglia D. Caviglia
F. Fondelli F. Fondelli
Ericsson Ericsson
M. Corsi M. Corsi
Altran Altran
B. Wu B. Wu
X. Dai X. Dai
ZTE Corporation ZTE Corporation
November 14, 2011 February 15, 2012
Applicability of MPLS-TP Linear Protection for Ring Topologies Applicability of MPLS-TP Linear Protection for Ring Topologies
draft-ietf-mpls-tp-ring-protection-00.txt draft-ietf-mpls-tp-ring-protection-01.txt
Abstract Abstract
This document presents an applicability statement to address the This document presents an applicability statement to address the
requirements for protection of ring topologies for Multi-Protocol requirements for protection of ring topologies for Multi-Protocol
Label Switching Transport Profile (MPLS-TP) Label Switched Paths Label Switching Transport Profile (MPLS-TP) Label Switched Paths
(LSP) on multiple layers. The MPLS-TP Requirements document (LSP) on multiple layers. The MPLS-TP Requirements document
specifies specific criteria for justification of dedicated protection specifies specific criteria for justification of dedicated protection
mechanism for particular topologies, including optimizing the number mechanism for particular topologies, including optimizing the number
of OAM entities needed, minimizing the number of labels for of OAM entities needed, minimizing the number of labels for
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2012. This Internet-Draft will expire on August 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 26 skipping to change at page 3, line 26
2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12 2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for link and node protection . . . . . . . . 14 2.3.4. Wrapping for link and node protection . . . . . . . . 14
2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15
3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19
3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20
3.2.2. Walkthrough using context labels . . . . . . . . . . . 21 3.2.2. Walkthrough using context labels . . . . . . . . . . . 22
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . . 25 9. Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 6, line 28 skipping to change at page 6, line 28
3. When applicable, the S-bit (signifying that a given label is the 3. When applicable, the S-bit (signifying that a given label is the
bottom of the label stack) will be denoted by the string '+S' bottom of the label stack) will be denoted by the string '+S'
within the label. If a label is not shown with '+S' that label within the label. If a label is not shown with '+S' that label
may or may not be the bottom label in the stack. '+S' is only may or may not be the bottom label in the stack. '+S' is only
shown when it is important to illustrate that a given label is shown when it is important to illustrate that a given label is
definitely the last one in the label stack. definitely the last one in the label stack.
4. The label of the LSP at the ingress point to the ring will be 4. The label of the LSP at the ingress point to the ring will be
denoted by the string "LI" and the label of the LSP that is denoted by the string "LI" and the label of the LSP that is
expected at the egress point from the ring will be denoted by the expected at the egress point from the ring will be denoted by the
string "LE" string "LE", and "LSE" will denote the label expected at the exit
LSR of a SPME (if it is different from the egress point from the
ring).
5. The label for a SPME will be denoted by Px(y) where x and y are 5. The label for a SPME will be denoted by Pxi(y) where x and y are
LSR identifiers and the intention is to the label for LSR-x to LSR identifiers and the intention is to the label for LSR-x to
transmit to LSR-y over the SPME. transmit to LSR-y over the SPME whose index is i.
For example - For example -
o the label stack [LI] denotes the label stack received at the o the label stack [LI] denotes the label stack received at the
ingress node of the ring. This may have additional labels after ingress node of the ring. This may have additional labels after
LI, e.g. a PW label however, this is irrelevant to the discussion LI, e.g. a PW label however, this is irrelevant to the discussion
of the protection scenario. of the protection scenario.
o [PB(G)|LE] denotes a stack whose top-label is the SPME label for o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label
LSR-B to transmit the data packet to LSR-G, the second label is for LSR-B to transmit the data packet to LSR-G, the second label
the label that would be used by the egress LSR to continue the is the label that would be used by the egress LSR to continue the
packet on the original LSP. packet on the original LSP.
o If "LE" were the bottom label in the stack, then the label stack o If "LE" were the bottom label in the stack, then the label stack
would be shown as [PB(G)|LE+S]. would be shown as [PB1(G)|LE+S].
1.3. Contributing Authors 1.3. Contributing Authors
Akira Sakurai (NEC), Rolf Winter (NEC) Akira Sakurai (NEC), Rolf Winter (NEC)
2. P2P Ring Protection 2. P2P Ring Protection
Classically there are two protection architecture mechanisms for ring Classically there are two protection architecture mechanisms for ring
topologies, based on SDH specifications [G.841], that have been topologies, based on SDH specifications [G.841], that have been
proposed in various forums to perform recovery of a topological ring proposed in various forums to perform recovery of a topological ring
skipping to change at page 11, line 19 skipping to change at page 11, line 19
of methodology and this will be detailed in the following sections. of methodology and this will be detailed in the following sections.
However, in all of these configurations the mechanism will be to However, in all of these configurations the mechanism will be to
transmit the data traffic on the primary SPME, while applying OAM transmit the data traffic on the primary SPME, while applying OAM
functionality over both the primary and the secondary SPME to detect functionality over both the primary and the secondary SPME to detect
signal fault conditions on either path. If a signal fault is signal fault conditions on either path. If a signal fault is
detected on the primary SPME, then the mechanism described in detected on the primary SPME, then the mechanism described in
[LinProtect] shall be used to coordinate a switch-over of data [LinProtect] shall be used to coordinate a switch-over of data
traffic to the secondary SPME. traffic to the secondary SPME.
Assuming that the SPME is implemented as an hierarchical LSP, packets Assuming that the SPME is implemented as an hierarchical LSP, packets
that arrive at LSR-B with a label stack [L1] will have the SPME label that arrive at LSR-B with a label stack [LI] will have the SPME label
pushed at LSR-B (i.e. the packet will arrive at LSR-A with a label pushed at LSR-B and the LSP label will be swapped for the label that
stack of [PA(F)|L1], arrive at LSR-F with [PF(F)|L1]). The SPME is expected by the egress LSR (i.e. the packet will arrive at LSR-A
label will be popped by LSR-F and the LSP label will be treated with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]).
appropriately at LSR-F and forwarded along the LSP. This scenario is The SPME label will be popped by LSR-F and the LSP label will be
true for all LSP that are aggregated by this primary SPME. treated appropriately at LSR-F and forwarded along the LSP, outside
the ring. This scenario is true for all LSP that are aggregated by
this primary SPME.
2.3.1. Path SPME for Steering 2.3.1. Path SPME for Steering
A p2p SPME that traverses part of a ring has two Maintenance Entity A p2p SPME that traverses part of a ring has two Maintenance Entity
Group End Points (MEPs), each one acts as the ingress and egress in Group End Points (MEPs), each one acts as the ingress and egress in
one direction of the bidirectional SPME. Since the SPME is one direction of the bidirectional SPME. Since the SPME is
traversing a ring we can take advantage of another characteristic of traversing a ring we can take advantage of another characteristic of
a ring - there is always an alternative path between the two MEPs, a ring - there is always an alternative path between the two MEPs,
i.e. traversing the ring in the opposite direction. This alternative i.e. traversing the ring in the opposite direction. This alternative
SPME can be defined as the protection path for the working path that SPME can be defined as the protection path for the working path that
skipping to change at page 12, line 49 skipping to change at page 12, line 51
possible to affect a wrapping protection mechanism for the LSP possible to affect a wrapping protection mechanism for the LSP
traffic that traverses the ring. The LSR on either side of the traffic that traverses the ring. The LSR on either side of the
segment would identify that there is a fault condition on the link segment would identify that there is a fault condition on the link
and redirect all LSP traffic to the secondary SPME. The traffic and redirect all LSP traffic to the secondary SPME. The traffic
would traverse the ring until arriving at the neighboring (relative would traverse the ring until arriving at the neighboring (relative
to the segment) LSR. At this point, the LSP traffic would be to the segment) LSR. At this point, the LSP traffic would be
redirected onto the original LSP, quite likely over the neighboring redirected onto the original LSP, quite likely over the neighboring
SPME. SPME.
Following the progression of the label stack through this switching Following the progression of the label stack through this switching
operation: operation (for a LSP that enters the ring at LSR B and exits the ring
at LSR E):
1. The data packet arrives at LSR-A with label stack [LI+S] (i.e. 1. The data packet arrives at LSR-A with label stack [L1+S] (i.e.
top label from the LSP and bottom-of-stack indicator) top label from the LSP and bottom-of-stack indicator)
2. In the normal case (no switching), LSR-A forwards the packet with 2. In the normal case (no switching), LSR-A forwards the packet with
label stack [PA1(F)|LE+S] (i.e. swap the label for the LSP, to be label stack [PA1(F)|LSE+S] (i.e. swap the label for the LSP, to
acceptable to the SPME egress, and push the label for the primary be acceptable to the SPME egress, and push the label for the
SPME from LSR-A to LSR-F). primary SPME from LSR-A to LSR-F).
3. When switching is in-effect, LSR-A forwards the packet with label 3. When switching is in-effect, LSR-A forwards the packet with label
stack [PA2(F)|LE+S] (i.e. LSR-A pushed the label for the stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for the
secondary SPME from LSR-A to LSR-F, after swapping the label of secondary SPME from LSR-A to LSR-F, after swapping the label of
the lower level LSP). the lower level LSP). This will be transmitted along the
secondary SPME until LSR-E forwards it to LSR-F with label stack
[PE2(F)|LSE+S].
4. When the packet arrives at LSR-F, it will pop the SPME label, 4. When the packet arrives at LSR-F, it will pop the SPME label,
process the LSP label, and forward the packet to the next point, process the LSP label, and forward the packet to the next point,
possibly pushing a SPME label if the next segment is likewise possibly pushing a SPME label if the next segment is likewise
protected. protected.
2.3.3. Wrapping node protection 2.3.3. Wrapping node protection
Implementation of protection at the node level would be similar to Implementation of protection at the node level would be similar to
the mechanism described in the previous sub-section. The difference the mechanism described in the previous sub-section. The difference
skipping to change at page 19, line 45 skipping to change at page 19, line 45
the ring at multiple nodes, we can employ a steering mechanism based the ring at multiple nodes, we can employ a steering mechanism based
on 1+1 linear protection [SurvivFwk]. We can configure two p2mp on 1+1 linear protection [SurvivFwk]. We can configure two p2mp
unidirectional SPME from each node on the ring that traverse the ring unidirectional SPME from each node on the ring that traverse the ring
in both directions. These SPME will be configured with an egress at in both directions. These SPME will be configured with an egress at
each ring node. In order to be able to properly direct the LSP each ring node. In order to be able to properly direct the LSP
traffic to the proper egress point for that particular LSP, we need traffic to the proper egress point for that particular LSP, we need
to employ context labeling as defined in [RFC5331]. The method for to employ context labeling as defined in [RFC5331]. The method for
using these labels is expanded in section 3.2.1. using these labels is expanded in section 3.2.1.
For every LSP that enters the ring at a given node the traffic will For every LSP that enters the ring at a given node the traffic will
be sent through one of these SPME (the working SPME). In case there be sent through both of these SPME, each with its own context label
is a failure condition, the traffic is transmitted on both SPME, each and the context-specific label for the particular LSP. The egress
with its own context label and the context-specific label for the nodes should select the traffic that is arriving on the working SPME.
particular LSP. In this way, all egress nodes are able to receive In case there is a failure condition, the egress nodes should select
the data traffic. While each node detects that there is connectivity the traffic from whichever of the SPME that is arrives at that node,
from the ingress point, it continues to select the data that is i.e. since one of the two (presumably the working SPME) will be
coming from the working SPME. If a particular node stops receiving blocked by the failure. In this way, all egress nodes are able to
the connectivity messages from the working SPME, it identifies that receive the data traffic. While each node detects that there is
it must switch its selector to read the data packets from the connectivity from the ingress point, it continues to select the data
protection SPME. that is coming from the working SPME. If a particular node stops
receiving the connectivity messages from the working SPME, it
identifies that it must switch its selector to read the data packets
from the protection SPME.
^ ^ ^ ^ ^ ^
_|_ _|_ _|_ _|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\ ----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/ \_A_/========\_B_/========\_C_/
+* <+++++++++*|| +* <+++++++++*||
+* +*|| +* +*||
+* +*|| +* +*||
+* +*|| +* +*||
+*_ ++++++++ ___ +++++++++*|| +*_ ++++++++ ___ +++++++++*||
 End of changes. 18 change blocks. 
36 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/