idnits 2.17.1 draft-cohn-mpls-tp-pw-prot-00.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 (May 16, 2011) is 4727 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-linear-protection-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group D. Cohn 2 Internet Draft Orckit-Corrigent 3 Intended status: Standards Track 4 Expires: November 16, 2011 6 May 16, 2011 8 MPLS-TP Linear Protection Applicability to MS-PW 9 draft-cohn-mpls-tp-pw-prot-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 16, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 One of the requirements of the MPLS transport profile [RFC 5654] is 52 to provide linear protection for transport paths, which include both 53 LSPs and PWs. The functional architecture described in [SurvivFwk] 54 is applicable to both LSP and PWs, however [LinearProt] does not 55 explicitly describe mechanisms for PW protection in MPLS-TP. 57 This document extends the applicability of the linear protection 58 mechanism described in [LinearProt] to MPLS-TP segmented PWs 59 (MS-PWs) as defined in [RFC 6073]. 61 Table of Contents 63 1. Introduction ................................................ 2 64 1.1. PW protection requirements.............................. 3 65 2. Conventions used in this document............................ 4 66 3. PSC applicability to PW...................................... 4 67 4. Security Considerations...................................... 4 68 5. IANA Considerations ......................................... 4 69 6. References .................................................. 4 70 6.1. Normative References.................................... 4 71 6.2. Informative References.................................. 4 72 7. Acknowledgments ............................................. 5 74 1. Introduction 76 When specifying the requirements for an MPLS Transport Profile, RFC 77 5654 states that "In an MPLS-TP environment, a transport path 78 corresponds to an LSP or a PW". It follows that recovery 79 requirements in section 2.5 of RFC 5654 apply to PWs as well as to 80 LSPs. The MPLS-TP survivability framework described in [SurvivFwk] 81 states that "The general description of the functional architecture 82 is applicable to both LSPs and pseudowires (PWs), however, PW 83 recovery is only introduced in Section 7, and the relevant details 84 are beyond the scope of this document and are for further study". 85 Finally, the MPLS-TP OAM framework described in [OamFwk] provides 86 tools for PW monitoring that are suitable for PW protection 87 triggering. 89 [LinearProt] describes a protection state coordination (PSC) 90 protocol that can be used to provide linear protection for LSPs. 91 This document extends the applicability of the PSC control logic and 92 protocol to support MPLS-TP segmented PW (aka MS-PW) protection 93 against S-PE failure. 95 1.1. MS-PW protection requirements 97 PW protection is required to support PW recovery upon node failure 98 of an S-PE in an MS-PW application. MS-PW and S-PE are defined in 99 [RFC 6073]. LSP recovery is not possible in this scenario and 100 therefore a separate mechanism is required to provide MS-PW 101 recovery. 103 Figure 1 illustrates such a scenario, where two MS-PWs are 104 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 105 respectively. Each PW segment is established over an LSP (e.g. PW- 106 s12 over LSP12). 108 <--------------MS-PW A12Z-------------> 110 +----+ +-----+ +-----+ +----+ 111 | |LSPA1 | |LSP12 | |LSP1Z | | 112 | |------|SPE1 |------|SPE2 |------| | 113 | |PW-sA1| X |PW-s12| X |PW-s2Z| | 114 |TPEA| +-----+ +-----+ |TPEZ| 115 | | | | 116 | | +-----+ +-----+ | | 117 | |PW-sA3|SPE3 |PW-s34|SPE4 |PW-s4Z| | 118 | |------| X |------| X |------| | 119 | |LSPA3 | |LSP34 | |LSP4Z | | 120 +----+ +-----+ +-----+ +----+ 122 <--------------MS-PW A34Z-------------> 124 Figure 1: MS-PW protection 126 Without loss of generality, it is assumed that MS-PW A12Z is active 127 in the normal state. In the event of a failure in S-PE 1, LSPs A1 128 and 12 cannot recover by using LSP protection mechanisms, but the 129 MS-PW can recover by switching to MS-PW A34Z. 131 This mechanism requires coordination between the two MS-PW endpoints 132 to decide which of the two MS-PWs will be active, i.e. transmitting 133 data traffic. 135 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC-2119 [1]. 141 In this document, these words will appear with that interpretation 142 only when in ALL CAPS. Lower case uses of these words are not to be 143 interpreted as carrying RFC-2119 significance. 145 3. PSC applicability to PW 147 PSC control logic and protocol for MS-PW protection SHALL be as 148 defined in sections 3 and 4 of [LinearProt]. 150 All references therein to OAM indications SHALL be applied as 151 referring to MS-PW OAM, i.e. provided by the MS-PW MEG (PMEG, as 152 defined in section 4.3. of [OamFwk]). 154 All references therein to LER SHALL be applied as referring to T-PE. 156 All reference therein to the server layer SHALL be applied as 157 referring to the LSPs over which the MS-PW is carried. 159 Protocol format SHALL be the same defined in section 4.2 of 160 [LinearProt]. PW G-ACh is described in [RFC4385]. 162 4. Security Considerations 164 No security considerations other than those mentioned in 165 [LinearProt] apply. 167 5. IANA Considerations 169 No new IANA considerations 171 6. References 173 6.1. Normative References 175 [1] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 6.2. Informative References 180 [SurvivFwk] Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol 181 Label Switching Transport Profile Survivability 182 Framework", draft-ietf-mpls-tp-survive-fwk-06, Jun 2010 184 [LinearProt] S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Y. 185 Weingarten, "MPLS-TP Linear Protection", draft-ietf- 186 mpls-tp-linear-protection-06, Mar 2011 188 [OamFwk] I. Busi, D. Allan, "Operations, Administration and 189 Maintenance Framework for MPLS-based Transport 190 Networks", draft-ietf-mpls-tp-oam-framework-11, Feb 2011 192 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 193 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word 194 for Use over an MPLS PSN", RFC 4385, February 2006. 196 [RFC 5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, 197 N., and S. Ueno, "Requirements of an MPLS Transport 198 Profile", RFC 5654, Sep 2009 200 [RFC 6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 201 Aissaoui, "Segmented Pseudowire", RFC 6073, Jan 2011. 203 7. Acknowledgments 205 This document was prepared using 2-Word-v2.0.template.dot. 207 Authors' Addresses 209 Daniel Cohn 210 Orckit-Corrigent 211 Yigal Alon 126, Tel Aviv 212 Israel 214 Email: danielc@orckit.com