idnits 2.17.1 draft-ietf-pals-vccv-for-gal-04.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 (May 26, 2015) is 3229 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 PALS T. Nadeau 3 Internet-Draft lucidvision 4 Intended status: Standards Track L. Martini 5 Expires: November 27, 2015 S. Bryant 6 Cisco Systems 7 May 26, 2015 9 Using A Generic Associated Channel Label as a Virtual Circuit 10 Connectivity Verification Channel Indicator 11 draft-ietf-pals-vccv-for-gal-04 13 Abstract 15 This document specifies a new Virtual Circuit Connectivity 16 Verification (VCCV) (RFC5085) control channel type for use with 17 pseudowires (PW) carried over an MPLS network. This new channel type 18 uses the Generic Associated Channel Label (GAL) (RFC5586) to 19 distinguish VCCV packets from packets carrying user data. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 27, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3 58 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5 60 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5 61 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 6 65 9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7 66 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The Virtual Circuit Connectivity Verification (VCCV) protocol is 75 specified in RFC 5085 [RFC5085]. This document specifies a new VCCV 76 control channel (VCCV CC) type to be used with pseudowires (PW) 77 carried over an MPLS network that do not use the PW Control Word (CW) 78 [RFC4385]. This new VCCV CC type uses the Generic Associated Channel 79 Label (GAL) [RFC5586] to distinguish VCCV packets from packets 80 carrying user data. This new VCCV CC type introduces compatibility 81 with the method of MPLS Label Switched Path (LSP) Operations, 82 Administration, and Maintenance (OAM) identification, particularly in 83 MPLS Transport Profile (MPLS-TP) networks [RFC5921]. 85 VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW 86 Control Word (CW) to distinguish VCCV packets from packets carrying 87 user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM 88 packets they carry. This was not an issue when [RFC5085] was 89 designed, but is in conflict with the design goals of MPLS-TP 90 [RFC5921] which does not otherwise require the availability of IP. 91 VCCV CC Type 2 is not applicable to multi-segment PWs (MS-PWs) 92 [RFC6073]. A MS-PW operating without the CW therefore has to use 93 VCCV CC Type 3 which identifies VCCV packets on the basis of Time to 94 Live (TTL) expiry. Whilst less of an issue with a single segment PW 95 (SS-PW), on an MS-PW this need to be accurately set to cause TTL 96 expiry at the egress Terminating Provider Edge (T-PE) [RFC6073]. In 97 the event of an error in the setting of the PW Label Stack Entry 98 (LSE) TTL this can result in VCCV packets leaking into the attachment 99 circuit which may disrupt the operation of the PW, or the native 100 service, and is a security risk. The new VCCV CC type defined in 101 this specification addresses these problems for PWs that do not use 102 the CW. 104 Note that mandating that all PWs to use the PW CW is not a viable way 105 to address this issue. This is because: 107 o PWs without the CW are already widely deployed. 109 o There is a significant deployment of existing hardware that does 110 not support usage of the PW CW for some PW types. 112 o Some operators are concerned that the inclusion of the PW CW will 113 increase the PW packet size. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 [RFC2119]. 122 3. Type 4 MPLS VCCV Control Channel Type 124 When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC) 125 type defined in this section MAY be used. This is referred to as 126 VCCV CC Type4 throughout the rest of this of this document. VCCV 127 Type 4 uses the encapsulation shown in Figure 1 in which the presence 128 of a GAL at the end of the MPLS label stack indicates that the packet 129 carries a VCCV message. 131 0 1 2 3 132 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | PW LSE | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | GAL LSE | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |0 0 0 1|Version| Reserved | Channel Type | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 ~ VCCV Message Body ~ 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1 148 The VCCV message body is preceded by a Generic Associated Channel 149 Header as defined in [RFC5586], in which the Channel Type identifies 150 the type and format of the OAM message carried in the VCCV message 151 body. 153 The GAL LSE MUST contain the GAL reserved label as defined in 154 [RFC5586]. 156 The PW LSE is constructed according to the existing procedures that 157 apply to the type of pseudowire that is in use. 159 Note that the inclusion of a GAL following the PW LSE over a label 160 switched path subject to Equal-Cost Multi-path (ECMP) load balancing 161 can cause the OAM packet to take a different path through the network 162 from the corresponding PW data packets. If that is not acceptable, 163 then an alternative VCCV type needs to be used. 165 4. FAT PWs 167 [RFC6391] specifies that when the flow-aware transport (FAT) of 168 pseudowires over an MPLS packet switched network has been signalled 169 or configured, the Flow LSE MUST be present. It further specifies 170 that "the flow label MUST NOT be an MPLS reserved label (values in 171 the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 172 MUST be checked to determine whether it carries a reserved label. If 173 it is a reserved label, the packet is processed according to the 174 rules associated with that reserved label; otherwise, the LSE is 175 discarded." 177 This document specifies that if the flow-aware transport of 178 pseudowires over an MPLS packet switched network has been signalled 179 or configured then the presence of VCCV message is indicated by the 180 use of a GAL in place of the flow LSE. 182 This is consistent with [RFC6391], and the packet structure is 183 identical to that shown in Figure 1. 185 Flow LSEs are inserted into a PW label stack in order to enable the 186 distribution of the PW traffic among multiple equal cost MPLS paths. 187 The use of GAL in place of the flow label will cause all OAM packets 188 to take exactly one of these paths, and this path may be different 189 from the paths taken by any of traffic flows. If this is not 190 acceptable, then an alternative VCCV type needs be used. 192 5. Multi-Segment Pseudowires 194 When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV 195 packet to a Switching PE (S-PE) MUST set the TTL to the appropriate 196 value to expire at that S-PE. An S-PE that supports this 197 specification MUST inspect PW packets that are received as a result 198 of TTL expiry, and determine whether a GAL follows the PW LSE. If a 199 GAL is present the S-PE then processes the VCCV packet. 201 An S-PE that does not support this specification would be expected to 202 reject as malformed a VCCV CC Type 4 packet that was received. This 203 is because the S-PE would expect the PW LSE to be bottom of stack 204 (the non FAT case) and for the LSE at bottom of stack not to be a 205 reserved label (both the FAT and the non-FAT cases). An S-PE that 206 did not make this reserved label check would then find that the first 207 nibble following the label stack was 0x1 and not the expected start 208 of an IP packet. It would hence be expected to also reject the 209 packet. This update to the behaviour of S-PEs is therefore backwards 210 compatible. 212 6. VCCV Capability Advertisement 214 The VCCV capability advertisement MUST match the c-bit setting that 215 is advertised in the PW FEC element [RFC4447]. If the c-bit is set, 216 indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be 217 advertised. If the c-bit is not set, indicating that the PW CW is 218 not in use, then an equipment supporting this specification MUST 219 advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are 220 therefore mutually exclusive. 222 A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as 223 defined in [RFC5085] . 225 If the remote PE supports VCCV CC Type 4, and the PW CW is not in 226 use, then for cases where multiple CC Types are advertised, the 227 following precedence rules apply when choosing which CC Type to use: 229 1. Type 4: GAL VCCV Control Channel. 231 2. Type 2: MPLS Router Alert Label. 233 3. Type 3: MPLS PW Label with TTL == 1. 235 If the remote PE finds that VCCV CC Types 1 and 4 are both 236 advertised, or that c-bit is set and VCCV CC Type 4 is advertised, 237 then it should report the error to the operator through the 238 management interface in use, and send a Label Release Message with a 239 status code "VCCV Type Error". 241 7. Manageability Considerations 243 Whilst the introduction of this additional VCCV CC type increases the 244 number of VCCV CC types that the operator needs to manage, it 245 addresses the issues with VCCV CC Types 2 and 3 described in 246 Section 1. 248 In the event of a misconfiguration of this VCCV CC type, the PW is 249 taken out of service and the operator advised as described in 250 Section 6. 252 Attention is drawn to the possible absence of fate sharing between PW 253 data packets and VCCV CC Type 4 packets described in Section 3 and 254 Section 4. 256 8. Security Considerations 258 This document does not by itself raise any new security 259 considerations beyond those described in [RFC5085]. It addresses the 260 possibility of packet leaking that can occur with VCCV CC Type 3. 262 9. IANA Considerations 264 9.1. MPLS VCCV Control Channel (CC) Type 4 266 IANA is requested to assign a new bit from the MPLS VCCV Control 267 Channel (CC) Types registry in the PWE3-parameters name space in 268 order to identify VCCV type 4. It is requested that Bit 3 be 269 assigned to this purpose which would have a value of 0x08. 271 MPLS VCCV Control Channel (CC) Types 273 Bit (Value) Description Reference 274 ============ =========== ================== 275 Bit X (0x0Y) Type 4: GAL This Specification 277 9.2. LDP Status Code 279 IANA is requested to assign a new Status Code from the Label 280 Distribution Protocol (LDP) Parameters name space: 282 Status Code Name Space 284 Range/Value E Description Reference 285 =========== = =============== ========= 286 0x000000xx 0 VCCV Type Error This Specification 288 10. Acknowledgments 290 The authors wish to thank Alexander (Sasha) Vainshtein for his 291 proposal to make the GAL and Flow labels mutually exclusive. This 292 proposal led to a significant simplification of this design. The 293 authors also thank Sasha, Matthew Bocci and Loa Andersson for their 294 review comments. 296 11. References 298 11.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 304 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 305 Use over an MPLS PSN", RFC 4385, February 2006. 307 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 308 Heron, "Pseudowire Setup and Maintenance Using the Label 309 Distribution Protocol (LDP)", RFC 4447, April 2006. 311 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 312 Connectivity Verification (VCCV): A Control Channel for 313 Pseudowires", RFC 5085, December 2007. 315 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 316 Associated Channel", RFC 5586, June 2009. 318 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 319 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 321 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 322 J., and S. Amante, "Flow-Aware Transport of Pseudowires 323 over an MPLS Packet Switched Network", RFC 6391, November 324 2011. 326 11.2. Informative References 328 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 329 Berger, "A Framework for MPLS in Transport Networks", RFC 330 5921, July 2010. 332 Authors' Addresses 334 Thomas D. Nadeau 335 lucidvision 337 Email: tnadeau@lucidvision.com 339 Luca Martini 340 Cisco Systems 342 Email: lmartini@cisco.com 344 Stewart Bryant 345 Cisco Systems 347 Email: stbryant@cisco.com