idnits 2.17.1 draft-cohn-mpls-tp-pw-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6073], [RFC5654], [LinearProt], [SurvivFwk]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2012) is 4493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group D. Cohn 2 R. Ram 3 Internet Draft Orckit-Corrigent 4 Intended status: Standards Track 5 M. Yuxia 6 Expires: July 4, 2012 ZTE Corp. 8 M. Daikoku 9 KDDI 11 January 4, 2012 13 MPLS-TP Linear Protection Applicability to MS-PW 14 draft-cohn-mpls-tp-pw-protection-02.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on July 4, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 One of the requirements of the MPLS transport profile [RFC5654] is 57 to provide linear protection for transport paths, which include both 58 LSPs and PWs. The functional architecture described in [SurvivFwk] 59 is applicable to both LSP and PWs, however [LinearProt] does not 60 explicitly describe mechanisms for PW protection in MPLS-TP. 62 This document extends the applicability of the linear protection 63 mechanism described in [LinearProt] to MPLS-TP segmented PWs as 64 defined in [RFC6073]. 66 Table of Contents 68 1. Introduction ................................................ 2 69 1.1. Background on MS-PW..................................... 3 70 1.2. MS-PW protection requirements........................... 3 71 2. Conventions used in this document............................ 4 72 3. PSC applicability to PW...................................... 4 73 4. Security Considerations...................................... 5 74 5. IANA Considerations ......................................... 5 75 6. References .................................................. 5 76 6.1. Normative References.................................... 5 77 6.2. Informative References.................................. 5 78 7. Acknowledgments ............................................. 6 80 1. Introduction 82 When specifying the requirements for an MPLS Transport Profile, 83 [RFC5654] states that "In an MPLS-TP environment, a transport path 84 corresponds to an LSP or a PW". It follows that recovery 85 requirements in section 2.5 of [RFC5654] apply to PWs as well as to 86 LSPs. The MPLS-TP survivability framework described in [SurvivFwk] 87 states that "The general description of the functional architecture 88 is applicable to both LSPs and pseudowires (PWs), however, PW 89 recovery is only introduced in Section 7, and the relevant details 90 are beyond the scope of this document and are for further study". 91 Finally, the MPLS-TP OAM framework described in [OamFwk] provides 92 tools for PW monitoring that are suitable for PW protection 93 triggering. 95 [LinearProt] describes a protection state coordination (PSC) 96 protocol that can be used to provide linear protection for LSPs. 98 This document extends the applicability of the PSC control logic and 99 protocol to support MPLS-TP segmented PW (aka MS-PW) protection 100 against S-PE failure. 102 1.1. Background on MS-PW 104 This section reviews operator motivations for MS-PW usage in an 105 MPLS-TP framework. Some of these are mentioned in [RFC5254] and 106 [RFC6073]. 108 o PSN Internetworking: The PW route may go across nodes that are 109 interconnected using different PSN protocols. In this case, it is 110 not possible to establish a single LSP between the terminating 111 PEs, and therefore a single-segment PW (SS-PW) cannot be used. 113 o Domain separation: The PW route may cross different 114 administrative domains, either intra- or inter-operator. In this 115 scenario, it may not be possible to establish a single transport 116 path (LSP or PW) between nodes in different operators, so SS-PW 117 cannot be used. 119 o Reduce network delay variations: Some end users (e.g. financial 120 customers) are very sensitive to the network delay provided by 121 the operator service. Operators therefore want to minimize both 122 the absolute network delay provided, and the variations in 123 network delay upon different events, specifically node or link 124 failures. SS-PW recovery from a link failure requires end-to-end 125 switching to another SS-PW which will typically have a different 126 network route and thus provide a significantly different network 127 delay. MS-PW, on the other hand, allows link failure recovery by 128 local switching on the failed segment, which typically achieves 129 much lower network delay variation. 130 MS-PW end-to-end switching, involving higher network delay 131 variation, is performed only upon node (S-PE) failure. 133 1.2. MS-PW protection requirements 135 PW protection is required to support PW recovery upon node failure 136 of an S-PE in an MS-PW application. MS-PW and S-PE are defined in 137 [RFC6073]. LSP recovery is not helpful in this scenario and 138 therefore a separate mechanism is required to provide MS-PW 139 recovery. It should be noted that LSP recovery does provide PW 140 recovery in the link failure scenario. 142 Figure 1 illustrates such a scenario, where two MS-PWs are 143 established between T-PE A and T-PE Z, over S-PEs 1-2 and 3-4 144 respectively. Each PW segment is established over an LSP (e.g. PW- 145 s12 over LSP12). 147 <--------------MS-PW A12Z-------------> 149 +----+ +-----+ +-----+ +----+ 150 | |LSPA1 |SPE1 |LSP12 |SPE2 |LSP2Z | | 151 | |------| X |------| X |------| | 152 | |PW-sA1| |PW-s12| |PW-s2Z| | 153 |TPEA| +-----+ +-----+ |TPEZ| 154 | | | | 155 | | +-----+ +-----+ | | 156 | |PW-sA3|SPE3 |PW-s34|SPE4 |PW-s4Z| | 157 | |------| X |------| X |------| | 158 | |LSPA3 | |LSP34 | |LSP4Z | | 159 +----+ +-----+ +-----+ +----+ 161 <--------------MS-PW A34Z-------------> 163 Figure 1: MS-PW protection 165 Without loss of generality, it is assumed that MS-PW A12Z is active 166 in the normal state. In the event of a failure in S-PE 1, LSPs A1 167 and 12 cannot recover by using LSP protection mechanisms, but the 168 MS-PW can recover by switching to MS-PW A34Z. 170 This mechanism requires coordination between the two MS-PW endpoints 171 to decide which of the two MS-PWs will be active, i.e. transmitting 172 data traffic. 174 2. Conventions used in this document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC-2119 [1]. 180 In this document, these words will appear with that interpretation 181 only when in ALL CAPS. Lower case uses of these words are not to be 182 interpreted as carrying RFC-2119 significance. 184 3. PSC applicability to PW 186 PSC control logic and protocol for MS-PW protection SHALL be as 187 defined in sections 3 and 4 of [LinearProt]. 189 All references therein to OAM indications SHALL be applied as 190 referring to MS-PW OAM, i.e. provided by the MS-PW MEG (PMEG, as 191 defined in section 4.3. of [OamFwk] ). 193 All references therein to LER SHALL be applied as referring to T-PE. 195 All references therein to the server layer SHALL be applied as 196 referring to the LSPs over which the MS-PW is carried. 198 Protocol format SHALL be the same defined in section 4.2 of 199 [LinearProt]. All references therein to the G-ACh SHALL be applied 200 to the PW Associated Channel (PWAC), as described in [RFC4385]. 202 4. Security Considerations 204 No security considerations other than those mentioned in 205 [LinearProt] apply. 207 5. IANA Considerations 209 No new IANA considerations 211 6. References 213 6.1. Normative References 215 [1] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 6.2. Informative References 220 [SurvivFwk] Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol 221 Label Switching Transport Profile Survivability 222 Framework", RFC 6372, Sep 2011 224 [LinearProt] S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Y. 225 Weingarten, "MPLS-TP Linear Protection", RFC 6378, Oct 226 2011 228 [OamFwk] I. Busi, D. Allan, "Operations, Administration and 229 Maintenance Framework for MPLS-based Transport 230 Networks", RFC 6371, Sep 2011 232 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 233 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word 234 for Use over an MPLS PSN", RFC 4385, Feb 2006. 236 [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., 237 "Requirements for Multi-Segment Pseudowire Emulation 238 Edge-to-Edge (PWE3)", RFC 5254, Oct 2008. 240 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, 241 N., and S. Ueno, "Requirements of an MPLS Transport 242 Profile", RFC 5654, Sep 2009 244 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 245 Aissaoui, "Segmented Pseudowire", RFC 6073, Jan 2011. 247 7. Acknowledgments 249 This document was prepared using 2-Word-v2.0.template.dot. 251 Authors' Addresses 253 Daniel Cohn 254 Orckit-Corrigent 255 Yigal Alon 126, Tel Aviv 256 Israel 258 Email: danielc@orckit.com 260 Rafi Ram 261 Orckit-Corrigent 262 Yigal Alon 126, Tel Aviv 263 Israel 265 Email: rafir@orckit.com 267 Ma Yuxia 268 ZTE Corp. 269 China 271 Email: ma.yuxia@zte.com.cn 273 Masahiro Daikoku 274 KDDI 275 Japan 277 Email: ms-daikoku@kddi.com