Network Working Group J. Guichard Internet-Draft C. Pignataro, Ed. Intended status: Standards Track S. Spraggs Expires: December 14, 2013 S. Bryant Cisco June 12, 2013 Carrying Metadata in MPLS Networks draft-guichard-mpls-metadata-00 Abstract This document defines the mechanism for identifying the presence of metadata carried in addition to the payload in MPLS packets. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 14, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Guichard, et al. Expires December 14, 2013 [Page 1] Internet-Draft MPLS Metadata June 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Metadata Component Structure . . . . . . . . . . . . . . . . . 3 3. Metadata Channel Header Format . . . . . . . . . . . . . . . . 4 3.1. Metadata Encapsulation Format . . . . . . . . . . . . . . 4 4. Load-balancing Considerations . . . . . . . . . . . . . . . . 5 5. Metadata and MPLS Label Stack . . . . . . . . . . . . . . . . 5 6. Data Plane Processing of MPLS Packets Containing Metadata . . 6 6.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Ingress LER/LSR . . . . . . . . . . . . . . . . . . . . . 6 6.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 7 7. Data Plane Processing of MPLS Packets Containing Metadata . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Alternative Options . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Guichard, et al. Expires December 14, 2013 [Page 2] Internet-Draft MPLS Metadata June 2013 1. Introduction This document defines the mechanism for identifying the presence of metadata carried in addition to the payload in MPLS packets. The metadata header is common across all encapsulations (including IPv4, IPv6, and MPLS) and is defined in [I-D.guichard-metadata-header]. 1.1. Terminology ACH Associated Channel Header AL Application Label EL Entropy Label ELI Entropy Label Indicator G-ACh Generic Associated Channel GAL Generic Associated Channel Label TL Top Label MCH Metadata Channel Header MD Metadata 2. Metadata Component Structure The addition of metadata to packets enables the instrumentation of user packets, and service chaining, although it is anticipated that the ability to allow packets to carry metadata of use to the infrastructure and specific handling instructions will enable other uses. Metadata carried within an MPLS packet is prefaced by a Metadata Channel Header (MCH) as defined in [I-D.guichard-metadata-header], with the first nibble of the MCH set to 0000b. Metadata is distinguished from IP payloads using similar methods to those developed in pseudowires and MPLS-TP [RFC4385] [RFC5586]. Two scenarios are presented for MPLS environments where metadata may be required. 1. IPv4, IPv6 or pseudo-wire payload. In this case the metadata will be carried within MPLS packets between the MCH and the Guichard, et al. Expires December 14, 2013 [Page 3] Internet-Draft MPLS Metadata June 2013 original MPLS payload. A GAL reserved label [RFC5586] is used to indicate that metadata is carried within the MPLS packet and that an MCH immediately follows the bottom of the label stack. 2. MPLS payload. In this case a new label stack will be created for the section over which the metadata is relevant and the original MPLS packet (MPLS label stack and MPLS payload) will be carried in the payload section described below. An example where this type of scenario may be required is when a hierarchical LSP needs to be instrumented. In this case, rather than pushing the labels associated with the hierarchical section onto the existing label stack, the original label stack is preserved and placed along with its associated payload in the payload section described below. A new label stack, indicating the presence of metadata (by way of the GAL), the MCH, and the metadata itself is then built for the MPLS section requiring instrumentation and sent. 3. Metadata Channel Header Format The presence of metadata within an MPLS packet must be indicated in the encapsulation. This document defines that the G-ACh Generic Associated Channel Label (GAL) [RFC5586] with label value 13 is utilized for this purpose. The GAL label provides a method to identify that a packet contains an "Associated Channel Header (ACH)" followed by a non-service payload. [RFC5586] identifies the G-ACh Generic Associated Channel by setting the first nibble of the ACH that immediately follows the bottom label in the stack if the GAL label is present, to 0001b. Further [RFC5586] expects that the ACH not be used to carry user data traffic. This document proposes an extension to allow the first nibble of the ACH to be set to 0000b and, when following the GAL, be interpreted using the semantics defined in [I-D.guichard-metadata-header] to allow metadata to be carried through the G-ACh channel. The metadata is distinguished from OAM by the use of 0000b in the first nibble. This is consistent with the practise developed in pseudowire [RFC4928] which uses a first nibble of 0000b to indicate the presence of information to be used by the forwarding plane to correctly forward the packet (i.e. the PW control word [RFC4385]). 3.1. Metadata Encapsulation Format Figure 1 depicts the Metadata encapsulation format: Guichard, et al. Expires December 14, 2013 [Page 4] Internet-Draft MPLS Metadata June 2013 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0: Metadata Channel Header (MCH) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original L2, L3, MPLS Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Metadata Encapsulation Format The meanings of the fields in the metadata packet format are as follows: o The GAL (reserved label of value 13) is used to indicate that an ACH or MCH appears immediately after the bottom of the label stack. The first nibble of the channel header is used to identify whether the format is to be interpreted as an ACH or MCH. o If the first nibble is set as 0000b, this indicates that an MCH will sit beneath the label stack. o Immediately following the MCH will be the metadata. The length and format of the metadata is outside the scope of this document and will vary depending upon the "Metadata Channel Type" specified in the MCH. o Beneath the metadata will be the original packet payload. This could be L2, L3 or MPLS payload. 4. Load-balancing Considerations The approach in this document is consistent with the use of utilizing 0000b as the first nibble after the MPLS label stack, as described in [RFC4928]. In this case, the MCH starts with 0000b. Load balancing is achieved utilizing the entropy label and following the methods defined in [RFC6790]. 5. Metadata and MPLS Label Stack Only one piece of metadata can be carried for each payload (L2, L3, or MPLS). As a consequence there MUST be only one GAL label in the label stack. Entropy labels MAY be present in the label stack but Guichard, et al. Expires December 14, 2013 [Page 5] Internet-Draft MPLS Metadata June 2013 they MUST be indicated using the Entropy Label Indicator (ELI) as described in [RFC6790]. 6. Data Plane Processing of MPLS Packets Containing Metadata 6.1. Egress LSR Suppose egress LSR Y is capable of processing metadata. LSR Y indicates this to all other LER's and LSR's via signaling (see Section 7 for more discussion on this subject) or through direct configuration. LSR Y MUST be prepared to process packets carrying metadata and those without. If a GAL is present in the MPLS label stack, the receiving LSR MUST inspect the first nibble after the end of the label stack to identify the presence of an MCH or an ACH, and process the packet accordingly. An LSR SHOULD NOT push a GAL on a packet that does not contain an MCH or an ACH. If a particular LER or LSR chooses to send traffic without metadata, LSR Y's processing of the received label stack (which might be empty) and payload is based on normal MPLS processing rules. If LER/LSR X chooses to send metadata, then LSR Y will receive an MPLS packet constructed as follows: LSR Y recognizes TL as the label it distributed to its upstream LER/ LSR and pops the TL (note that the TL signalled by LSR Y may be an implicit null label, in which case it doesn't appear in the label stack and LSR Y MUST process the packet starting with the AL label (if present) and/or the GAL label.) LSR Y recognizes the GAL with S bit set. LSR Y then processes the metadata, starting with the MCH (0000b), which will determine how LSR Y processes the underlying payload. 6.2. Ingress LER/LSR If an egress LSR Y indicates via signaling or through direct configuration of other LER's/LSR's that it can process metadata, the steps that Ingress LER/LSR X performs to insert metadata are as follows: 1. On an incoming packet, identify the application to which the packet belongs and from this the egress LSR; based on these two components determine whether metadata needs to be added to the Guichard, et al. Expires December 14, 2013 [Page 6] Internet-Draft MPLS Metadata June 2013 incoming packet. 2. For packets requiring the insertion of metadata, build the appropriate MCH and prepend the metadata and the MCH to the existing payload; then, push the GAL label on to the label stack with the S bit set. For packets not requiring insertion of metadata, this step is a NOOP. 3. Push the application label (AL) label (if required) on to the label stack. 4. If Entropy is required then pick appropriate fields as input to the load-balancing function; apply the load-balancing function to these input fields and generate the Entropy label (EL) value. 5. Push the EL and the ELI labels on to the label stack. 6. Determine the top label (TPL) and push it on top of the ELI and EL (if present). The ordering of the AL and the ELI plus EL pair is not critical other than that the egress LSR processing the ELI MUST process all remaining labels in the stack and the metadata. The S bit for the ELI and EL MUST be zero (i.e., S bit is not set). The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the EL may be any value. 7. Determine the output interface, and transmit. 6.3. Transit LSR Transit LSRs may operate with no change in forwarding behavior. 6.4. Penultimate Hop LSR No change is needed at penultimate hop LSRs. 7. Data Plane Processing of MPLS Packets Containing Metadata Two levels of set-up are required to support metadata. The first is an indication that the device or LSP is capable of supporting metadata. This could be done either using the NMS or by using capabilities exchange mechanisms. For example an IGP ([RFC4971] in ISIS) or MPLS protocols such as [RFC5036], [RFC3209], or [RFC3107]. The specific mechanism for signaling the support of metadata is outside the scope of this document and will be defined elsewhere. The second set-up required is by the actual application using the Guichard, et al. Expires December 14, 2013 [Page 7] Internet-Draft MPLS Metadata June 2013 information contained in the metadata. Again this could be done using either the NMS or a signaling protocol. It is anticipated this type of signaling is specifically associated with the application and would be specified elsewhere. 8. IANA Considerations This document makes no request of IANA. [Note to RFC Editor: this section may be removed on publication as an RFC.] 9. Security Considerations The addition of metadata to a packet increases the amount of processing required by the LSR receiving the packet, and thus may be a used in a denial of service attack vector. However MPLS networks carefully manage their adjacencies and only accept labeled packets from trusted neighbors. Provided this current level of neighbor verification remains in place no additional risk results. The metadata itelf may be an attack vector with either the originating LSR or a man in the middle inserting malicious content. The trust model of the MPLS network itself, described earlier in this section guards against a man in the middle attack and ensures that the originating LER/LSR is a trusted party. If the ingress LER/LSR is taking instructions from a third party in the specific medadata to insert, there MUST be a sufficient trust relationship between the ingress LER/LSR and the third party. The security considerations associated with each metadata type MUST be specified as part of its definition. 10. Contributing Authors o Clarence Filsfils o Dan Frost 11. Acknowledgments The authors would like to thank Giles Heron for his review and useful comments. Guichard, et al. Expires December 14, 2013 [Page 8] Internet-Draft MPLS Metadata June 2013 12. References 12.1. Normative References [I-D.guichard-metadata-header] Guichard, J., Spraggs, S., Pignataro, C., and S. Bryant, "Common Metadata Header Format for IP/MPLS Networks". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [I-D.kompella-mpls-special-purpose-labels] Kompella, K. and A. Farrel, "Allocating and Retiring Special Purpose MPLS Labels", draft-kompella-mpls-special-purpose-labels-04 (work in progress), May 2013. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012. Guichard, et al. Expires December 14, 2013 [Page 9] Internet-Draft MPLS Metadata June 2013 Appendix A. Alternative Options This appendix lists alternative options for metadata indication that were considered but ultimately discarded: o Starting the MCH with the first nibble as 0010b. This first nibble is overloading the IP version field, and thus the creation of new first nibbles needs to be a conservative process, since each new nibble used for other purposes prevents that nibble being used to identify a new IP type at some time in the future. o Extending a G-ACh to be able to carry user data. This has been discussed at length within the IETF and it seems the consensus is this structure should not carry customer payload. o Assign a new reserved label, either directly or as an extension label as proposed in [I-D.kompella-mpls-special-purpose-labels] to indicate the presence of metadata. In the first case it utilizes another reserved label, which are becoming sparse. In the second case it increases the size of the label stack. The method described in this document has more benefits and fewer drawbacks that these three. Authors' Addresses Jim Guichard Cisco Systems, Inc. Email: jguichar@cisco.com Carlos Pignataro (editor) Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: cpignata@cisco.com Guichard, et al. Expires December 14, 2013 [Page 10] Internet-Draft MPLS Metadata June 2013 Simon Spraggs Cisco Systems, Inc. 10 New Square Park Bedfont Lakes, Feltham TW14 8HA United Kingdom Email: sspraggs@cisco.com Stewart Bryant Cisco Systems, Inc. 10 New Square Park Bedfont Lakes, Feltham TW14 8HA United Kingdom Email: stbryant@cisco.com Guichard, et al. Expires December 14, 2013 [Page 11]