draft-ietf-mpls-tp-ring-protection-01.txt   draft-ietf-mpls-tp-ring-protection-02.txt 
Network Working Group Y. Weingarten Network Working Group Y. Weingarten
Internet-Draft Nokia Siemens Networks Internet-Draft
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: August 18, 2012 Cisco Expires: October 31, 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
February 15, 2012 April 29, 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-01.txt draft-ietf-mpls-tp-ring-protection-02.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 August 18, 2012. This Internet-Draft will expire on October 31, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5 1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7
2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. P2P ring protection using SPME . . . . . . . . . . . . . . 10 2.3. P2P ring protection using SPME . . . . . . . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . 22 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
skipping to change at page 14, line 14 skipping to change at page 14, line 14
The protection mechanism would work similarly - based on 1:1 linear The protection mechanism would work similarly - based on 1:1 linear
protection [SurvivFwk], triggered by OAM functions on both SPMEs, and protection [SurvivFwk], triggered by OAM functions on both SPMEs, and
wrapping the data packets onto the secondary SPME at the ingress MEP wrapping the data packets onto the secondary SPME at the ingress MEP
(e.g. LSR-A in the figure) of the SPME and back onto the (e.g. LSR-A in the figure) of the SPME and back onto the
continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) continuation of the LSP at the egress MEP (e.g. LSR-E in the figure)
of the SPME. of the SPME.
2.3.4. Wrapping for link and node protection 2.3.4. Wrapping for link and node protection
In the different types of wrapping presented in sections 2.3.2 and In the different types of wrapping presented in Section 2.3.2 and
2.3.3, there is a limitation that the protection mechanism must a Section 2.3.3, there is a limitation that the protection mechanism
priori decide whether it is protecting for link or node failure. In must a priori decide whether it is protecting for link or node
addition, the neighboring LSR, that detects the fault, cannot readily failure. In addition, the neighboring LSR, that detects the fault,
differentiate between a link failure or a node failure. cannot readily differentiate between a link failure or a node
failure.
It is possible to combine the link protection mechanism presented in It would be possible to configure extra SPME to protect both for link
section 2.3.2 with the protection mechanism of section 2.3.3 to give and node failures, arriving at a configuration of the ring that is
more complete coverage. For each segment, we configure both a shown in Figure 5. Choosing the SPME to use for the wrapping would,
secondary link protection SPME as well as two secondary node however, then involve considerable effort and could result in the
protection SPME, i.e. one for each direction of the bidirectional protected traffic not sharing the same protection path in both
segment SPME (see Figure 5). When a protection switch is triggered, directions.
the ingress LSR of the segment will examine the packet ring
destination. Only if this destination is for the LSR connected to
the "secondary link" SPME, then the packets will be wrapped onto this
secondary SPME. For all other cases, the data packets will be
wrapped onto the "secondary node" SPME. In all cases the egress LSR
for the secondary SPME will wrap the data traffic back onto the
working LSP/SPME.
___ ++++++++ ___ ___ ___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/ \_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$ $+*@ +*$
$+*@ +*$ $+*@ +*$
$+*@ +*$ $+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$ $+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
skipping to change at page 15, line 8 skipping to change at page 14, line 48
*** physical link *** physical link
### primary SPME @@@ secondary node#1 SPME ### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME $$$ secondary node#2 SPME +++ secondary segment SPME
Figure 5: Segment & Node protection SPMEs Figure 5: Segment & Node protection SPMEs
2.4. Analysis of p2p protection 2.4. Analysis of p2p protection
Analyzing the mechanisms described in the above subsections we can Analyzing the mechanisms described in the above subsections we can
point to the following observations (based on a ring with N nodes): point to the following observations (based on a ring with N nodes,
assumed to be not more than 16):
o Number of SPME that need to be configured - for path SPME (sec o Number of SPME that need to be configured - for steeing SPME
2.3.1) = O(2N^2) [two SPME from each ingress LSR to each other protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress
node in the ring], for segment SPME (sec 2.3.4) = O(4N) [four SPME LSR to each other node in the ring], for wrapping based on SPME
for each link in the ring] either as described in Section 2.3.2 and Section 2.3.3 = O(2N)
[however, the operator must decide a priori on whether to protect
for link failures or node failures at each point]
o Number of OAM sessions at each node - for path SPME = O(2N), for o Number of OAM sessions at each node - for steering = O(2N), for
segment SPME = 4 SPME wrapping = 3
o Bandwidth requirements - for path SPME: single bandwidth at each o Bandwidth requirements - for SPME-based steering: single bandwidth
link, for segment SPME: double bandwidth at links that are between at each link, for wrapping: double bandwidth at links that are
ingress and wrapping node and between second wrapping node and between ingress and wrapping node and between second wrapping node
egress. and egress.
o Special considerations - for path SPME: latency of OAM detection o Special considerations - for SPME based steering: latency of OAM
of fault condition by ingress MEP [using Alarm-reporting could detection of fault condition by ingress MEP [using Alarm-reporting
optimize over using CC-V only], for segment SPME: need to examine could optimize over using CC-V only], for SPME wrapping: at each
data packet ring destination before selecting bypass SPME. node must decide a priori whether protecting for link or node
failures. To protect for both node and link failures would
increase the complexity of deciding which protection path to use,
as well as, violating the co-routedness of the protected traffic.
Based on this analysis, using steering as described in Section 2.3.1
would be the recommended protection mechanism due to its simplicity,
even though it may involve the use of additional resources (i.e.
SPME) for monitorng the traffic. It should be pointed out that the
number of SPME involved in this protection could be reduced by
eliminating SPME between pairs of LSR that are not used as an ingress
and egress pair.
3. P2MP protection 3. P2MP protection
[TPReqs] requires that ring protection must provide protection for [TPReqs] requires that ring protection must provide protection for
unidirectional point-to-multipoint paths through the ring. Ring unidirectional point-to-multipoint paths through the ring. Ring
topologies provide a ready platform for supporting such data paths. topologies provide a ready platform for supporting such data paths.
A p2mp LSP in an MPLS-TP ring would be characterized by a single A p2mp LSP in an MPLS-TP ring would be characterized by a single
ingress LSR and multiple egress LSRs. The following sub-sections ingress LSR and multiple egress LSRs. The following sub-sections
will present methods to address the protection of the ring-based will present methods to address the protection of the ring-based
sections of these LSP. sections of these LSP.
skipping to change at page 26, line 10 skipping to change at page 26, line 10
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, Aug 2008. RFC 5331, Aug 2008.
[TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, [TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
"Requirements for the Transport Profile of MPLS", "Requirements for the Transport Profile of MPLS",
RFC 5654, April 2009. RFC 5654, April 2009.
[TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP [TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP
Framework", ID draft-ietf-mpls-tp-framework-12, May 2010. Framework", RFC 5921, May 2010.
[OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM [OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM
Framework", ID draft-ietf-mpls-tp-oam-framework-06, Framework", RFC 6371, May 2010.
May 2010.
[SurvivFwk] [SurvivFwk]
Sprecher, N. and A. Farrel, "MPLS-TP Survivability Sprecher, N. and A. Farrel, "MPLS-TP Survivability
Framework", ID draft-ietf-mpls-tp-survive-fwk-06, Framework", RFC 6372, June 2010.
June 2010.
[LinProtect] [LinProtect]
Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A.,
and Y. Weingarten, "MPLS-TP Linear Protection", and Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378,
ID draft-ietf-mpls-tp-linear-protection-02, October 2009. October 2009.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specifications", RFC 2205, September 1997. Specifications", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for GMPLS", RFC 4427, March 2006. Restoration) Terminology for GMPLS", RFC 4427, March 2006.
[G.841] ITU, "Types and characteristics of SDH network protection [G.841] ITU, "Types and characteristics of SDH network protection
architectures", ITU-T G.841, October 1998. architectures", ITU-T G.841, October 1998.
Authors' Addresses Authors' Addresses
Yaacov Weingarten Yaacov Weingarten
Nokia Siemens Networks 34 Hagefen St.
3 Hanagar St. Neve Ne'eman B Karnei Shomron, 4485500
Hod Hasharon, 45241
Israel Israel
Phone: +972-9-775 1827 Phone:
Email: yaacov.weingarten@nsn.com Email: wyaacov@gmail.com
Stewart Bryant Stewart Bryant
Cisco Cisco
United Kingdom United Kingdom
Email: stbryant@cisco.com Email: stbryant@cisco.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Danielle Ceccarelli Danielle Ceccarelli
Ericsson Ericsson
skipping to change at page 28, line 4 skipping to change at page 27, line 35
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Francesco Fondelli Francesco Fondelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: francesco.fondelli@ericsson.com Email: francesco.fondelli@ericsson.com
Marco Corsi Marco Corsi
Altran Altran
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: marco.corsi@altran.it Email: corsi.marco@gmail.com
Bo Wu Bo Wu
ZTE Corporation ZTE Corporation
4F,RD Building 2,Zijinghua Road 4F,RD Building 2,Zijinghua Road
Nanjing, Yuhuatai District Nanjing, Yuhuatai District
P.R.China P.R.China
Email: wu.bo@zte.com.cn Email: wu.bo@zte.com.cn
Xuehui Dai Xuehui Dai
ZTE Corporation ZTE Corporation
 End of changes. 22 change blocks. 
54 lines changed or deleted 59 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/