idnits 2.17.1 draft-ietf-pwe3-vccv-for-gal-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 draft header indicates that this document updates RFC5085, but the abstract doesn't seem to directly say this. It does mention RFC5085 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5085, updated by this document, for RFC5378 checks: 2003-07-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2, 2014) is 3517 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 T. Nadeau 3 Internet-Draft lucidvision 4 Updates: 5085 (if approved) L. Martini 5 Intended status: Standards Track S. Bryant 6 Expires: March 6, 2015 Cisco Systems 7 September 2, 2014 9 A Unified Control Channel for Pseudowires 10 draft-ietf-pwe3-vccv-for-gal-02 12 Abstract 14 This document describes a unified mode of operation for Virtual 15 Circuit Connectivity Verification (VCCV), which provides a control 16 channel that is associated with a pseudowire (PW). VCCV applies to 17 all supported access circuit and transport types currently defined 18 for PWs, as well as those being transported by the MPLS Transport 19 Profile. This new mode is intended to augment those described in 20 RFC5085. It describes new rules requiring this mode to be used as 21 the default/mandatory mode of operation for VCCV. The older VCCV 22 types will remain optional. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 6, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements Language and Terminology . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. VCCV Control Channel When The Control Word is Used . . . . . 5 61 4. VCCV Control Channel When The Control Word is Not Used . . . 6 62 5. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 7 63 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 7 67 8.2. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Requirements Language and Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in 79 [RFC2119]. 81 AC Attachment Circuit [RFC3985]. 83 AVP Attribute Value Pair [RFC3931]. 85 CC Control Channel (used as CC Type). 87 CE Customer Edge. 89 CV Connectivity Verification (used as CV Type). 91 CW Control Word [RFC3985]. 93 L2SS L2-Specific Sublayer [RFC3931]. 95 LCCE L2TP Control Connection Endpoint [RFC3931]. 97 OAM Operation and Maintenance. 99 PE Provider Edge. 101 PSN Packet Switched Network [RFC3985]. 103 PW Pseudowire [RFC3985]. 105 PW-ACH PW Associated Channel Header [RFC4385]. 107 VCCV Virtual Circuit Connectivity Verification [RFC5085]. 109 2. Introduction 111 There is a need for fault detection and diagnostic mechanisms that 112 can be used for end-to-end fault detection and diagnostics for a 113 Pseudowire, as a means of determining the PW's true operational 114 state. Operators have indicated in [RFC4377], and [RFC3916] that 115 such a tool is required for PW operation and maintenance. To this 116 end, the IETF's PWE3 Working Group defined the Virtual Circuit 117 Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a 118 number of interoperability issues have arisen with the protocol as it 119 is defined. 121 Over time, a variety of VCCV options or "modes" have been created to 122 support legacy hardware, these modes use of the CW in some cases, 123 while in others the CW is not used. The difficulty of operating 124 these different combinations of "modes" have been detailed in an 125 implementation survey conducted by the PWE3 Working Group and 126 documented in [RFC7079]. The implementation survey and the PWE3 127 Working Group have concluded that operators have difficulty deploying 128 the VCCV OAM protocol due to the number of combinations and options 129 for its use. 131 In addition to the implementation issues just described, the ITU-T 132 and IETF have set out to enhance MPLS to make it suitable as an 133 optical transport protocol. The requirements for this protocol are 134 defined as the MPLS Transport Profile (MPLS-TP). The requirements 135 for MPLS-TP can be found in [RFC5654]. In order to support VCCV when 136 an MPLS-TP PSN is in use, the GAL-ACH had to be created [RFC5586]. 137 This resulted in yet another mode of VCCV operation. 139 This document defines two modes of operation of VCCV: 1) with a 140 control word or 2) without a control word, both with a ACH 141 encapsulation making it possible to handle all of the other cases 142 handled by the other modes of VCCV. The modes of operation defined 143 in this document MUST be implemented. 145 Figure 1 depicts the architecture of a pseudowire as defined in 146 [RFC3985]. It further depicts where the VCCV control channel resides 147 within this architecture, which will be discussed in detail later in 148 this document. 150 |<-------------- Emulated Service ---------------->| 151 | |<---------- VCCV ---------->| | 152 | |<------- Pseudowire ------->| | 153 | | | | 154 | | |<-- PSN Tunnel -->| | | 155 | V V V V | 156 V AC +----+ +----+ AC V 157 +-----+ | | PE1|==================| PE2| | +-----+ 158 | |----------|............PW1.............|----------| | 159 | CE1 | | | | | | | | CE2 | 160 | |----------|............PW2.............|----------| | 161 +-----+ ^ | | |==================| | | ^ +-----+ 162 ^ | +----+ +----+ | | ^ 163 | | Provider Edge 1 Provider Edge 2 | | 164 | | | | 165 Customer | | Customer 166 Edge 1 | | Edge 2 167 | | 168 | | 169 Native service Native service 171 Figure 1: PWE3 VCCV Operation Reference Model 173 From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to 174 the emulated service via Attachment Circuits (AC), and to each of the 175 Provider Edge (PE) routers (PE1 and PE2, respectively). An AC can be 176 a Frame Relay Data Link Connection Identifier (DLCI), an ATM Virtual 177 Path Identifier / Virtual Channel Identifier (VPI/VCI), an Ethernet 178 port, or any other attachment type for which a PW is defined. The PE 179 devices provide pseudowire emulation, enabling the CEs to communicate 180 over the PSN. A pseudowire exists between these PEs traversing the 181 provider network. VCCV provides several means of creating a control 182 channel over the PW, between the PE routers that attach the PW. 184 Figure 2 depicts how the VCCV control channel is associated with the 185 pseudowire protocol stack. 187 +-------------+ +-------------+ 188 | Layer2 | | Layer2 | 189 | Emulated | < Emulated Service > | Emulated | 190 | Services | | Services | 191 +-------------+ +-------------+ 192 | | VCCV/PW | | 193 |Demultiplexer| < Control Channel > |Demultiplexer| 194 +-------------+ +-------------+ 195 | PSN | < PSN Tunnel > | PSN | 196 +-------------+ +-------------+ 197 | Physical | | Physical | 198 +-----+-------+ +-----+-------+ 199 | | 200 | ____ ___ ____ | 201 | _/ \___/ \ _/ \__ | 202 | / \__/ \_ | 203 | / \ | 204 +--------| MPLS/MPLS-TP or IP Network |---+ 205 \ / 206 \ ___ ___ __ _/ 207 \_/ \____/ \___/ \____/ 209 Figure 2: PWE3 Protocol Stack Reference Model including the VCCV 210 Control Channel 212 VCCV messages are encapsulated using the PWE3 encapsulation as 213 described in Section 3 and Section 4, so that they are handled and 214 processed in the same manner (or in some cases, a similar manner) the 215 PW PDUs for which they provide a control channel. These VCCV 216 messages are exchanged only after the capability (the VCCV Control 217 Channel and Connectivity Verification types) and the desire to 218 exchange VCCV traffic has been advertised between the PEs (see 219 Sections 5.3 and 6.3 of [RFC5085]), and VCCV type to use have been 220 chosen. 222 [EDITOR'S NOTE - Why are we talking about 6.3 which is L2TPv3 related 223 in a text on GAL?] 225 3. VCCV Control Channel When The Control Word is Used 227 When the PWE3 Control Word is used to encapsulate pseudowire traffic, 228 the rules described for encapsulating VCCV CC Type 1 as specified in 229 section 9.5.1 of [RFC6073] and section 5.1.1 of [RFC5085] MUST be 230 used. In this case the advertised CC Type is 1, and Associated 231 Channel Types of 21, 07, or 57 are allowed. 233 4. VCCV Control Channel When The Control Word is Not Used 235 When the PWE3 Control Word is not used a new CC Type 4 is defined as 236 follows: 238 0 1 239 2 3 240 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | PW LSE | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | GAL LSE | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |0 0 0 1|Version| Reserved | Associated Channel Type | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ VCCV Message Body ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 EDITOR's note = when we wrote RFC3985 I seem to remember that TTL=1 255 was problematic do we want to specify TTL=1 in the text below? 257 EDITOR's note = not sure if it should be MUST or SHOULD in the text 258 below. 260 When the PW is a single segment PW, the TTL field of the PW Label 261 Stack Entry (LSE) SHOULD be set to 1. In the case of multi-segment 262 pseudo-wires, the PW LSE TTL SHOULD be set to the value needed to 263 reach the intended destination PE as described in [RFC6073]. 265 The GAL LSE MUST contain the GAL reserved label as defined in 266 [RFC5586]. 268 As defined in [RFC4385] and [RFC4446] the first nibble of the next 269 field is set to 0001b to indicate an ACH associated with a pseudowire 270 instead of PW data. The Version and the Reserved fields MUST be set 271 to 0, and the Channel Type is set to 0x0021 for IPv4, 0x0057 for IPv6 272 payloads [RFC5085] or 0x0007 for BFD payloads [RFC5885]. 274 The Associated Channel Type defines how the "VCCV Message Body" field 275 is to be interpreted by the receiver. 277 5. VCCV Capability Advertisement 279 The capability advertisement MUST match the c-bit setting that is 280 advertised in the PW FEC element. If the c-bit is set, indicating 281 the use of the control word, type 1 MUST be advertised and type 4 282 MUST NOT be advertised. If the c-bit is not set, indicating that the 283 control word is not in use, type 4 MUST be advertised, and type 1 284 MUST NOT be advertised. 286 A PE supporting Type 4 MAY advertise other CC types as defined in 287 [RFC5085] . If the remote PE also supports Type 4, then Type 4 MUST 288 be used superseding the Capability Advertisement Selection rules of 289 section 7 from [RFC5085] . If a remote PE does not support Type 4, 290 then the rules from section 7 of [RFC5085] apply. If a CW is in use, 291 then Type 4 is not applicable, and therefore the normal capability 292 advertisement selection rules of section 7 from [RFC5085] apply. 294 6. Manageability Considerations 296 Editor's note - this is a placeholder - I am not sure if it sis 297 needed 299 7. Security Considerations 301 This document does not by itself raise any new security 302 considerations beyond those described in [RFC5085]. 304 8. IANA Considerations 306 8.1. VCCV Interface Parameters Sub-TLV 308 EDITOR'S NOTE ASFAICS this section can be deleted. 310 The VCCV Interface Parameters Sub-TLV code point is defined in 311 [RFC4446]. IANA has created and will maintain registries for the CC 312 Types and CV Types (bit masks in the VCCV Parameter ID). The CC Type 313 and CV Type new registries (see Sections 8.1.1 and 8.1.2, 314 respectively of[RFC5085] ) have been created in the Pseudo Wires Name 315 Spaces, . The allocations must be done using the "IETF Review" policy 316 defined in [RFC5226]. 318 8.2. MPLS VCCV Control Channel (CC) Type 4 320 IANA is requested to assign a new bit from the MPLS VCCV Control 321 Channel (CC) Types registry in the PWE3-parameters name space in 322 order to identify VCCV type 4. It is recommended that Bit 3 be 323 assigned to this purpose which would have a value of 0x08. 325 MPLS VCCV Control Channel (CC) Types 327 Bit (Value) Description Reference 328 ============ =========== ==================== 329 Bit X (0x0Y) Type 4 [This Specification] 331 9. Acknowledgements 333 10. References 335 10.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 341 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 343 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 344 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 345 Use over an MPLS PSN", RFC 4385, February 2006. 347 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 348 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 350 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 351 Connectivity Verification (VCCV): A Control Channel for 352 Pseudowires", RFC 5085, December 2007. 354 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 355 Associated Channel", RFC 5586, June 2009. 357 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 358 and S. Ueno, "Requirements of an MPLS Transport Profile", 359 RFC 5654, September 2009. 361 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 362 Detection (BFD) for the Pseudowire Virtual Circuit 363 Connectivity Verification (VCCV)", RFC 5885, June 2010. 365 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 366 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 368 10.2. Informative References 370 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 371 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 372 September 2004. 374 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 375 Edge (PWE3) Architecture", RFC 3985, March 2005. 377 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 378 Matsushima, "Operations and Management (OAM) Requirements 379 for Multi-Protocol Label Switched (MPLS) Networks", RFC 380 4377, February 2006. 382 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 383 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 384 May 2008. 386 [RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and 387 Virtual Circuit Connectivity Verification (VCCV) 388 Implementation Survey Results", RFC 7079, November 2013. 390 Authors' Addresses 392 Thomas D. Nadeau 393 lucidvision 395 Email: tnadeau@lucidvision.com 397 Luca Martini 398 Cisco Systems 400 Email: lmartini@cisco.com 402 Stewart Bryant 403 Cisco Systems 405 Email: stbryant@cisco.com