idnits 2.17.1 draft-ietf-pals-vccv-for-gal-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 17, 2014) is 3389 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 normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 T. Nadeau 3 Internet-Draft lucidvision 4 Updates: 4447, 5085 (if approved) L. Martini 5 Intended status: Standards Track S. Bryant 6 Expires: June 20, 2015 Cisco Systems 7 December 17, 2014 9 VCCV Default CC Types 10 draft-ietf-pals-vccv-for-gal-00 12 Abstract 14 This document specifies the default Virtual Circuit Connectivity 15 Verification (VCCV) (RFC5085) control channel type to be used when 16 the pseudowire control word is present and when it is not present. A 17 new VCCV control channel type using the Generic Associated Channel 18 Label (RFC5586) is specified for use when the control word not 19 present. 21 This document updates RFC4447 and RFC5085. 23 Note to be removed at publication: this document started out as 24 draft-ietf-pwe3-vccv-for-gal and got to version -02. When PWE3 was 25 absorbed into PALS the next version published was draft-ietf-pals- 26 vccv-for-gal-00 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 20, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Requirements Language and Terminology . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. VCCV Control Channel When The Control Word is Used . . . . . 4 65 4. VCCV Control Channel When The Control Word is Not Used . . . 4 66 5. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5 68 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 6 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 10.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Requirements Language and Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 [RFC2119]. 84 ACH Associated Channel Header [RFC4385] 86 CC Control Channel (used as CC Type). 88 CV Connectivity Verification (used as CV Type). 90 CW Control Word [RFC3985]. 92 GAL Generic Associated Channel Label [RFC5586] 93 OAM Operation and Maintenance. 95 PSN Packet Switched Network [RFC3985]. 97 PW Pseudowire [RFC3985]. 99 VCCV Virtual Circuit Connectivity Verification [RFC5085]. 101 2. Introduction 103 There is a need for fault detection and diagnostic mechanisms that 104 can be used for end-to-end fault detection and diagnostics for a 105 Pseudowire, as a means of determining the PW's true operational 106 state. Operators have indicated in [RFC4377], and [RFC3916] that 107 such a tool is required for PW operation and maintenance. To this 108 end, the IETF's PWE3 Working Group defined the Virtual Circuit 109 Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a 110 number of interoperability issues have arisen with the protocol as it 111 is defined. 113 Over time, a variety of VCCV options or "modes" have been created to 114 support legacy hardware, these modes use of the CW in some cases, 115 while in others the CW is not used. The difficulty of operating 116 these different combinations of "modes" have been detailed in an 117 implementation survey conducted by the PWE3 Working Group and 118 documented in [RFC7079]. The implementation survey and the PWE3 119 Working Group have concluded that operators have difficulty deploying 120 the VCCV OAM protocol due to the number of combinations and options 121 for its use. 123 In addition to the implementation issues just described, the ITU-T 124 and IETF have set out to enhance MPLS to make it suitable as an 125 optical transport protocol. The requirements for this protocol are 126 defined as the MPLS Transport Profile (MPLS-TP). The requirements 127 for MPLS-TP can be found in [RFC5654]. In order to support VCCV when 128 an MPLS-TP PSN is in use, the GAL-ACH had to be created [RFC5586]. 129 This resulted in yet another mode of VCCV operation. 131 This document specifies that there are two default modes of operation 132 of VCCV: 1) with a control word or 2) without a control word, both 133 with a ACH encapsulation [RFC4385] making it possible to handle all 134 of the other cases handled by the other modes of VCCV. The modes of 135 operation defined in this document MUST be implemented. 137 VCCV messages are encapsulated using the PWE3 encapsulation as 138 described in Section 3 and Section 4, so that they are handled and 139 processed in the same manner (or in some cases, a similar manner) the 140 PW PDUs for which they provide a control channel. These VCCV 141 messages are exchanged only after the capability (the VCCV Control 142 Channel and Connectivity Verification types) and the desire to 143 exchange VCCV traffic has been advertised between the PEs (see 144 Sections 5.3 of [RFC5085]), and VCCV type to use has been chosen. 146 3. VCCV Control Channel When The Control Word is Used 148 When the PWE3 Control Word is used to encapsulate pseudowire traffic, 149 the rules described for encapsulating VCCV CC Type 1 as specified in 150 section 9.5.1 of [RFC6073] and section 5.1.1 of [RFC5085] MUST be 151 used. In this case the advertised CC Type is 1, and Associated 152 Channel Types of 21, 07, or 57 are allowed. 154 4. VCCV Control Channel When The Control Word is Not Used 156 When the PWE3 Control Word is not used, the new VCCV CC Type 4 157 defined in this section MUST be used. VCCV CC Type 4 uses the 158 encapsulation shown in Figure 1. 160 0 1 161 2 3 162 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | PW LSE | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | GAL LSE | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |0 0 0 1|Version| Reserved | Associated Channel Type | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 ~ VCCV Message Body ~ 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1 178 When the PW is a single segment PW, the TTL field of the PW Label 179 Stack Entry (LSE) MUST be set to 2. TTL=2, rather than the more 180 obvious TTL=1, is used because of legacy hardware considerations. In 181 the case of multi-segment pseudo-wires, the PW LSE TTL MUST be set to 182 the value needed to reach the intended destination PE as described in 183 [RFC6073]. 185 The GAL LSE MUST contain the GAL reserved label as defined in 186 [RFC5586]. 188 As defined in [RFC4385] and [RFC4446] the first nibble of the next 189 field is set to 0001b to indicate an ACH is being carried instead of 190 PW data. The Version and the Reserved fields MUST be set to 0, and 191 the Channel Type is set to 0x0021 for IPv4, 0x0057 for IPv6 payloads 192 [RFC5085] or 0x0007 for BFD payloads [RFC5885]. 194 The Associated Channel Type defines how the "VCCV Message Body" field 195 is to be interpreted by the receiver. 197 5. FAT PWs 199 When the flow-aware transport of pseudowires over an MPLS packet 200 switched network [RFC6391] has been signalled or configured, the Flow 201 LSE MUST always be present. When VCCV CC Type 4 is in use the Flow 202 LSE MUST be immediately below the PW LSE in the label stack, and the 203 GAL MUST be at the bottom of the label stack. This is shown in 204 Figure 2. 206 0 1 207 2 3 208 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | PW LSE | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Flow LSE | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | GAL LSE | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |0 0 0 1|Version| Reserved | Associated Channel Type | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 ~ VCCV Message Body ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 2 226 The ELI mechanism [RFC6790] applies to the MPLS LSP that carries the 227 PW and is therefore out of scope of this specification. 229 6. VCCV Capability Advertisement 231 The VCCV capability advertisement MUST match the c-bit setting that 232 is advertised in the PW FEC element [RFC4447]. If the c-bit is set, 233 indicating the use of the control word, VCCV CC Type 1 MUST be 234 advertised and VCCV CC Type 4 MUST NOT be advertised. If the c-bit 235 is not set, indicating that the control word is not in use, VCCV CC 236 Type 4 MUST be advertised, and VCCV CC Type 1 MUST NOT be advertised. 238 A PE supporting VCCV CC Type 4 MAY advertise other CC types as 239 defined in [RFC5085] . If the remote PE also supports VCCV CC Type 4, 240 then VCCV CC Type 4 MUST be used superseding the Capability 241 Advertisement Selection rules of Section 7 from [RFC5085] . If a 242 remote PE does not support VCCV CC Type 4, then the rules from 243 Section 7 of [RFC5085] apply. If a CW is in use, then VCCV CC Type 4 244 is not applicable, and therefore the normal capability advertisement 245 selection rules of Section 7 from [RFC5085] apply. 247 7. Manageability Considerations 249 By introducing default VCCV CC types, and improving the compatibility 250 with MPLS-TP, the compatibility of implementations is improved and 251 management and configuration of the network becomes simpler. 253 Network operators should note that the presence of the GAL may cause 254 the PW packet and associated VCCV packets to be subjected to 255 different ECMP choices and thus not fate share. This effect is not 256 present in networks that support [RFC6790] since reserved labels are 257 ignored during ECMP path selection. 259 8. Security Considerations 261 This document does not by itself raise any new security 262 considerations beyond those described in [RFC5085]. 264 9. IANA Considerations 266 9.1. MPLS VCCV Control Channel (CC) Type 4 268 IANA is requested to assign a new bit from the MPLS VCCV Control 269 Channel (CC) Types registry in the PWE3-parameters name space in 270 order to identify VCCV type 4. It is recommended that Bit 3 be 271 assigned to this purpose which would have a value of 0x08. 273 MPLS VCCV Control Channel (CC) Types 275 Bit (Value) Description Reference 276 ============ =========== ==================== 277 Bit X (0x0Y) Type 4 [This Specification] 279 10. References 281 10.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 287 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 288 Use over an MPLS PSN", RFC 4385, February 2006. 290 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 291 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 293 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 294 Heron, "Pseudowire Setup and Maintenance Using the Label 295 Distribution Protocol (LDP)", RFC 4447, April 2006. 297 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 298 Connectivity Verification (VCCV): A Control Channel for 299 Pseudowires", RFC 5085, December 2007. 301 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 302 Associated Channel", RFC 5586, June 2009. 304 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 305 and S. Ueno, "Requirements of an MPLS Transport Profile", 306 RFC 5654, September 2009. 308 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 309 Detection (BFD) for the Pseudowire Virtual Circuit 310 Connectivity Verification (VCCV)", RFC 5885, June 2010. 312 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 313 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 315 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 316 J., and S. Amante, "Flow-Aware Transport of Pseudowires 317 over an MPLS Packet Switched Network", RFC 6391, November 318 2011. 320 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 321 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 322 RFC 6790, November 2012. 324 10.2. Informative References 326 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 327 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 328 September 2004. 330 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 331 Edge (PWE3) Architecture", RFC 3985, March 2005. 333 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 334 Matsushima, "Operations and Management (OAM) Requirements 335 for Multi-Protocol Label Switched (MPLS) Networks", RFC 336 4377, February 2006. 338 [RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and 339 Virtual Circuit Connectivity Verification (VCCV) 340 Implementation Survey Results", RFC 7079, November 2013. 342 Authors' Addresses 344 Thomas D. Nadeau 345 lucidvision 347 Email: tnadeau@lucidvision.com 349 Luca Martini 350 Cisco Systems 352 Email: lmartini@cisco.com 354 Stewart Bryant 355 Cisco Systems 357 Email: stbryant@cisco.com