Internet DRAFT - draft-guichard-sfc-mpls-metadata

draft-guichard-sfc-mpls-metadata






Network Working Group                                        J. Guichard
Internet-Draft                                         C. Pignataro, Ed.
Intended status:  Standards Track                             S. Spraggs
Expires:  March 31, 2014                                       S. Bryant
                                                                   Cisco
                                                      September 27, 2013


                   Carrying Metadata in MPLS Networks
                  draft-guichard-sfc-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 March 31, 2014.

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 March 31, 2014                 [Page 1]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                 [Page 2]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                 [Page 3]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                 [Page 4]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                 [Page 5]

Internet-Draft                MPLS Metadata               September 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:

      <Top Label (TL), AL, GAL> <MCH> <metadata> <remaining packet
      payload>

   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 March 31, 2014                 [Page 6]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                 [Page 7]

Internet-Draft                MPLS Metadata               September 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 <cfilsfil@cisco.com>

   o  Dan Frost <danfrost@cisco.com>


11.  Acknowledgments

   The authors would like to thank Giles Heron and Tom Nadeau for their
   review and useful comments.



Guichard, et al.         Expires March 31, 2014                 [Page 8]

Internet-Draft                MPLS Metadata               September 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",
              draft-guichard-metadata-header-00 (work in progress),
              June 2013.

   [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",



Guichard, et al.         Expires March 31, 2014                 [Page 9]

Internet-Draft                MPLS Metadata               September 2013


              RFC 6790, November 2012.


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 March 31, 2014                [Page 10]

Internet-Draft                MPLS Metadata               September 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 March 31, 2014                [Page 11]