idnits 2.17.1 draft-guichard-sfc-mpls-metadata-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 -- The document date (September 27, 2013) is 3864 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 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Guichard 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track S. Spraggs 5 Expires: March 31, 2014 S. Bryant 6 Cisco 7 September 27, 2013 9 Carrying Metadata in MPLS Networks 10 draft-guichard-sfc-mpls-metadata-00 12 Abstract 14 This document defines the mechanism for identifying the presence of 15 metadata carried in addition to the payload in MPLS packets. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 31, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Metadata Component Structure . . . . . . . . . . . . . . . . . 3 60 3. Metadata Channel Header Format . . . . . . . . . . . . . . . . 4 61 3.1. Metadata Encapsulation Format . . . . . . . . . . . . . . 4 62 4. Load-balancing Considerations . . . . . . . . . . . . . . . . 5 63 5. Metadata and MPLS Label Stack . . . . . . . . . . . . . . . . 5 64 6. Data Plane Processing of MPLS Packets Containing Metadata . . 6 65 6.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Ingress LER/LSR . . . . . . . . . . . . . . . . . . . . . 6 67 6.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 7 69 7. Data Plane Processing of MPLS Packets Containing Metadata . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 8 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Appendix A. Alternative Options . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 This document defines the mechanism for identifying the presence of 83 metadata carried in addition to the payload in MPLS packets. The 84 metadata header is common across all encapsulations (including IPv4, 85 IPv6, and MPLS) and is defined in [I-D.guichard-metadata-header]. 87 1.1. Terminology 89 ACH Associated Channel Header 91 AL Application Label 93 EL Entropy Label 95 ELI Entropy Label Indicator 97 G-ACh Generic Associated Channel 99 GAL Generic Associated Channel Label 101 TL Top Label 103 MCH Metadata Channel Header 105 MD Metadata 107 2. Metadata Component Structure 109 The addition of metadata to packets enables the instrumentation of 110 user packets, and service chaining, although it is anticipated that 111 the ability to allow packets to carry metadata of use to the 112 infrastructure and specific handling instructions will enable other 113 uses. 115 Metadata carried within an MPLS packet is prefaced by a Metadata 116 Channel Header (MCH) as defined in [I-D.guichard-metadata-header], 117 with the first nibble of the MCH set to 0000b. 119 Metadata is distinguished from IP payloads using similar methods to 120 those developed in pseudowires and MPLS-TP [RFC4385] [RFC5586]. 122 Two scenarios are presented for MPLS environments where metadata may 123 be required. 125 1. IPv4, IPv6 or pseudo-wire payload. In this case the metadata 126 will be carried within MPLS packets between the MCH and the 127 original MPLS payload. A GAL reserved label [RFC5586] is used to 128 indicate that metadata is carried within the MPLS packet and that 129 an MCH immediately follows the bottom of the label stack. 131 2. MPLS payload. In this case a new label stack will be created for 132 the section over which the metadata is relevant and the original 133 MPLS packet (MPLS label stack and MPLS payload) will be carried 134 in the payload section described below. An example where this 135 type of scenario may be required is when a hierarchical LSP needs 136 to be instrumented. In this case, rather than pushing the labels 137 associated with the hierarchical section onto the existing label 138 stack, the original label stack is preserved and placed along 139 with its associated payload in the payload section described 140 below. A new label stack, indicating the presence of metadata 141 (by way of the GAL), the MCH, and the metadata itself is then 142 built for the MPLS section requiring instrumentation and sent. 144 3. Metadata Channel Header Format 146 The presence of metadata within an MPLS packet must be indicated in 147 the encapsulation. This document defines that the G-ACh Generic 148 Associated Channel Label (GAL) [RFC5586] with label value 13 is 149 utilized for this purpose. The GAL label provides a method to 150 identify that a packet contains an "Associated Channel Header (ACH)" 151 followed by a non-service payload. 153 [RFC5586] identifies the G-ACh Generic Associated Channel by setting 154 the first nibble of the ACH that immediately follows the bottom label 155 in the stack if the GAL label is present, to 0001b. Further 156 [RFC5586] expects that the ACH not be used to carry user data 157 traffic. This document proposes an extension to allow the first 158 nibble of the ACH to be set to 0000b and, when following the GAL, be 159 interpreted using the semantics defined in 160 [I-D.guichard-metadata-header] to allow metadata to be carried 161 through the G-ACh channel. 163 The metadata is distinguished from OAM by the use of 0000b in the 164 first nibble. This is consistent with the practise developed in 165 pseudowire [RFC4928] which uses a first nibble of 0000b to indicate 166 the presence of information to be used by the forwarding plane to 167 correctly forward the packet (i.e. the PW control word [RFC4385]). 169 3.1. Metadata Encapsulation Format 171 Figure 1 depicts the Metadata encapsulation format: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | GAL | EXP |1| TTL | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |0 0 0 0: Metadata Channel Header (MCH) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Metadata (variable) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Original L2, L3, MPLS Payload | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: Metadata Encapsulation Format 187 The meanings of the fields in the metadata packet format are as 188 follows: 190 o The GAL (reserved label of value 13) is used to indicate that an 191 ACH or MCH appears immediately after the bottom of the label 192 stack. The first nibble of the channel header is used to identify 193 whether the format is to be interpreted as an ACH or MCH. 195 o If the first nibble is set as 0000b, this indicates that an MCH 196 will sit beneath the label stack. 198 o Immediately following the MCH will be the metadata. The length 199 and format of the metadata is outside the scope of this document 200 and will vary depending upon the "Metadata Channel Type" specified 201 in the MCH. 203 o Beneath the metadata will be the original packet payload. This 204 could be L2, L3 or MPLS payload. 206 4. Load-balancing Considerations 208 The approach in this document is consistent with the use of utilizing 209 0000b as the first nibble after the MPLS label stack, as described in 210 [RFC4928]. In this case, the MCH starts with 0000b. Load balancing 211 is achieved utilizing the entropy label and following the methods 212 defined in [RFC6790]. 214 5. Metadata and MPLS Label Stack 216 Only one piece of metadata can be carried for each payload (L2, L3, 217 or MPLS). As a consequence there MUST be only one GAL label in the 218 label stack. Entropy labels MAY be present in the label stack but 219 they MUST be indicated using the Entropy Label Indicator (ELI) as 220 described in [RFC6790]. 222 6. Data Plane Processing of MPLS Packets Containing Metadata 224 6.1. Egress LSR 226 Suppose egress LSR Y is capable of processing metadata. LSR Y 227 indicates this to all other LER's and LSR's via signaling (see 228 Section 7 for more discussion on this subject) or through direct 229 configuration. 231 LSR Y MUST be prepared to process packets carrying metadata and those 232 without. If a GAL is present in the MPLS label stack, the receiving 233 LSR MUST inspect the first nibble after the end of the label stack to 234 identify the presence of an MCH or an ACH, and process the packet 235 accordingly. An LSR SHOULD NOT push a GAL on a packet that does not 236 contain an MCH or an ACH. 238 If a particular LER or LSR chooses to send traffic without metadata, 239 LSR Y's processing of the received label stack (which might be empty) 240 and payload is based on normal MPLS processing rules. If LER/LSR X 241 chooses to send metadata, then LSR Y will receive an MPLS packet 242 constructed as follows: 244 247 LSR Y recognizes TL as the label it distributed to its upstream LER/ 248 LSR and pops the TL (note that the TL signalled by LSR Y may be an 249 implicit null label, in which case it doesn't appear in the label 250 stack and LSR Y MUST process the packet starting with the AL label 251 (if present) and/or the GAL label.) LSR Y recognizes the GAL with S 252 bit set. LSR Y then processes the metadata, starting with the MCH 253 (0000b), which will determine how LSR Y processes the underlying 254 payload. 256 6.2. Ingress LER/LSR 258 If an egress LSR Y indicates via signaling or through direct 259 configuration of other LER's/LSR's that it can process metadata, the 260 steps that Ingress LER/LSR X performs to insert metadata are as 261 follows: 263 1. On an incoming packet, identify the application to which the 264 packet belongs and from this the egress LSR; based on these two 265 components determine whether metadata needs to be added to the 266 incoming packet. 268 2. For packets requiring the insertion of metadata, build the 269 appropriate MCH and prepend the metadata and the MCH to the 270 existing payload; then, push the GAL label on to the label stack 271 with the S bit set. For packets not requiring insertion of 272 metadata, this step is a NOOP. 274 3. Push the application label (AL) label (if required) on to the 275 label stack. 277 4. If Entropy is required then pick appropriate fields as input to 278 the load-balancing function; apply the load-balancing function to 279 these input fields and generate the Entropy label (EL) value. 281 5. Push the EL and the ELI labels on to the label stack. 283 6. Determine the top label (TPL) and push it on top of the ELI and 284 EL (if present). The ordering of the AL and the ELI plus EL pair 285 is not critical other than that the egress LSR processing the ELI 286 MUST process all remaining labels in the stack and the metadata. 287 The S bit for the ELI and EL MUST be zero (i.e., S bit is not 288 set). The TTL for the EL MUST be zero to ensure that it is not 289 used inadvertently for forwarding. The TC for the EL may be any 290 value. 292 7. Determine the output interface, and transmit. 294 6.3. Transit LSR 296 Transit LSRs may operate with no change in forwarding behavior. 298 6.4. Penultimate Hop LSR 300 No change is needed at penultimate hop LSRs. 302 7. Data Plane Processing of MPLS Packets Containing Metadata 304 Two levels of set-up are required to support metadata. The first is 305 an indication that the device or LSP is capable of supporting 306 metadata. This could be done either using the NMS or by using 307 capabilities exchange mechanisms. For example an IGP ([RFC4971] in 308 ISIS) or MPLS protocols such as [RFC5036], [RFC3209], or [RFC3107]. 309 The specific mechanism for signaling the support of metadata is 310 outside the scope of this document and will be defined elsewhere. 312 The second set-up required is by the actual application using the 313 information contained in the metadata. Again this could be done 314 using either the NMS or a signaling protocol. It is anticipated this 315 type of signaling is specifically associated with the application and 316 would be specified elsewhere. 318 8. IANA Considerations 320 This document makes no request of IANA. 322 [Note to RFC Editor: this section may be removed on publication as 323 an RFC.] 325 9. Security Considerations 327 The addition of metadata to a packet increases the amount of 328 processing required by the LSR receiving the packet, and thus may be 329 a used in a denial of service attack vector. However MPLS networks 330 carefully manage their adjacencies and only accept labeled packets 331 from trusted neighbors. Provided this current level of neighbor 332 verification remains in place no additional risk results. 334 The metadata itelf may be an attack vector with either the 335 originating LSR or a man in the middle inserting malicious content. 336 The trust model of the MPLS network itself, described earlier in this 337 section guards against a man in the middle attack and ensures that 338 the originating LER/LSR is a trusted party. 340 If the ingress LER/LSR is taking instructions from a third party in 341 the specific medadata to insert, there MUST be a sufficient trust 342 relationship between the ingress LER/LSR and the third party. 344 The security considerations associated with each metadata type MUST 345 be specified as part of its definition. 347 10. Contributing Authors 349 o Clarence Filsfils 351 o Dan Frost 353 11. Acknowledgments 355 The authors would like to thank Giles Heron and Tom Nadeau for their 356 review and useful comments. 358 12. References 360 12.1. Normative References 362 [I-D.guichard-metadata-header] 363 Guichard, J., Spraggs, S., Pignataro, C., and S. Bryant, 364 "Common Metadata Header Format for IP/MPLS Networks", 365 draft-guichard-metadata-header-00 (work in progress), 366 June 2013. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 12.2. Informative References 373 [I-D.kompella-mpls-special-purpose-labels] 374 Kompella, K. and A. Farrel, "Allocating and Retiring 375 Special Purpose MPLS Labels", 376 draft-kompella-mpls-special-purpose-labels-04 (work in 377 progress), May 2013. 379 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 380 BGP-4", RFC 3107, May 2001. 382 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 383 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 384 Tunnels", RFC 3209, December 2001. 386 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 387 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 388 Use over an MPLS PSN", RFC 4385, February 2006. 390 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 391 Cost Multipath Treatment in MPLS Networks", BCP 128, 392 RFC 4928, June 2007. 394 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 395 System to Intermediate System (IS-IS) Extensions for 396 Advertising Router Information", RFC 4971, July 2007. 398 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 399 Specification", RFC 5036, October 2007. 401 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 402 Associated Channel", RFC 5586, June 2009. 404 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 405 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 406 RFC 6790, November 2012. 408 Appendix A. Alternative Options 410 This appendix lists alternative options for metadata indication that 411 were considered but ultimately discarded: 413 o Starting the MCH with the first nibble as 0010b. This first 414 nibble is overloading the IP version field, and thus the creation 415 of new first nibbles needs to be a conservative process, since 416 each new nibble used for other purposes prevents that nibble being 417 used to identify a new IP type at some time in the future. 419 o Extending a G-ACh to be able to carry user data. This has been 420 discussed at length within the IETF and it seems the consensus is 421 this structure should not carry customer payload. 423 o Assign a new reserved label, either directly or as an extension 424 label as proposed in [I-D.kompella-mpls-special-purpose-labels] to 425 indicate the presence of metadata. In the first case it utilizes 426 another reserved label, which are becoming sparse. In the second 427 case it increases the size of the label stack. 429 The method described in this document has more benefits and fewer 430 drawbacks that these three. 432 Authors' Addresses 434 Jim Guichard 435 Cisco Systems, Inc. 437 Email: jguichar@cisco.com 439 Carlos Pignataro (editor) 440 Cisco Systems, Inc. 441 7200-12 Kit Creek Road 442 Research Triangle Park, NC 27709 443 US 445 Email: cpignata@cisco.com 446 Simon Spraggs 447 Cisco Systems, Inc. 448 10 New Square Park 449 Bedfont Lakes, Feltham TW14 8HA 450 United Kingdom 452 Email: sspraggs@cisco.com 454 Stewart Bryant 455 Cisco Systems, Inc. 456 10 New Square Park 457 Bedfont Lakes, Feltham TW14 8HA 458 United Kingdom 460 Email: stbryant@cisco.com