Service Function Chaining                                      J. Napper
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                S. Kumar
Expires: July 18, 2018                            Individual Contributor
                                                                P. Muley
                                                           W. Hendericks
                                                                   Nokia
                                                            M. Boucadair
                                                                  Orange
                                                        January 14, 2018


              NSH Context Header Allocation for Broadband
               draft-ietf-sfc-nsh-broadband-allocation-00

Abstract

   This document provides a recommended allocation of Network Service
   Header (NSH) context headers within the broadband service provider
   network context.  Both fixed and mobile deployments are considered.

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 https://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 July 18, 2018.








Napper, et al.            Expires July 18, 2018                 [Page 1]


Internet-Draft      NSH Broadband Context Allocation        January 2018


Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition Of Terms . . . . . . . . . . . . . . . . . . . . .   3
   3.  Network Service Header (NSH) Context Headers  . . . . . . . .   3
   4.  Recommended Context Allocation For Broadband  . . . . . . . .   4
     4.1.  MD Type 0x01 Allocation Specifics . . . . . . . . . . . .   4
     4.2.  MD Type 0x02 Allocation Specifics . . . . . . . . . . . .   7
   5.  Context Allocation and Control Plane Considerations . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Service Function Chaining (SFC) [RFC7665] provides a mechanism for
   network traffic to be steered through an ordered list of Service
   Functions (SFs).  Furthermore, SFC allows to share metadata among
   involved SFC data functional elements (classifiers and SFs).
   Particularly, the Network Service Header (NSH) provides support for
   carrying shared metadata either using a fixed context header or as
   optional TLVs [RFC8300].

   This document provides a recommended default allocation scheme for
   the fixed-length context header used for SFC within fixed and mobile
   broadband service provider networks.  Also, the document defines
   companion TLV types when MD Type 0x02 is used.  The use cases
   describing the need for metadata in these contexts are described in
   [I-D.ietf-sfc-use-case-mobility].



Napper, et al.            Expires July 18, 2018                 [Page 2]


Internet-Draft      NSH Broadband Context Allocation        January 2018


   This document does not address control plane mechanisms.  The reader
   may refer to [I-D.ietf-sfc-control-plane].

2.  Definition Of Terms

   This document makes use of the terms as defined in [RFC7498],
   [RFC7665], and [RFC8300].

3.  Network Service Header (NSH) Context Headers

   The NSH is composed of a 4-byte base header (BH1), a 4-byte service
   path header (SH1) and a mandatory 16-byte context header in the case
   of MD Type 0x01 and optional TLVs in the case of MD Type 0x02
   [RFC8300].

   The following Figure 1 shows the format of the MD Type 0x01 NSH
   header.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol | BH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier              | Service Index | SH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                             Fixed                             |
   +                         Context Header                        +
   |                           (16 Bytes)                          |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Network Service Header (MD Type 0x01)

   The following Figure 2 shows the MD Type 0x02 NSH header format.















Napper, et al.            Expires July 18, 2018                 [Page 3]


Internet-Draft      NSH Broadband Context Allocation        January 2018


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol | BH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier              | Service Index | SH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~              Variable Length Context Headers  (opt.)          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Network Service Header (MD Type 0x02)

4.  Recommended Context Allocation For Broadband

   The following header allocations provide information to support
   service function chaining in a service provider network, for example
   as described for mobility in [I-D.ietf-sfc-use-case-mobility].

   The set of metadata headers can be delivered to service functions
   that can use the metadata within to enforce policy, communicate
   between service functions, provide subscriber information and other
   functionality.  Several of the headers are typed allowing for
   different metadata to be provided to different service functions or
   even to the same service function but on different packets within a
   flow.

   Which metadata are sent to which service functions is decided in the
   SFC control plane and is thus out of the scope of this document.

4.1.  MD Type 0x01 Allocation Specifics

   The following Figure 3 provides a high-level description of the
   fields in the recommended allocation of the fixed sixteen byte
   context headers for a broadband context.  Each four byte word in the
   sixteen byte context header is referred to as CH1, CH2, CH3, and CH4,
   respectively.














Napper, et al.            Expires July 18, 2018                 [Page 4]


Internet-Draft      NSH Broadband Context Allocation        January 2018


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R | Sub | Tag |                 Context ID                    | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub/Endpoint ID                         ~ CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Sub/Endpoint ID (cont.)                     | CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Service Information                        | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: NSH Context Allocation

   The intended use for each of the context header fields is as follows:

   R: Reserved.

   Sub:  Sub/Endpoint ID type field.  These bits determine the type of
      the 64-bit Sub/Endpoint ID field that spans CH2 and CH3.

      000:  If the Sub field is not set, then the 64-bit Sub/Endpoint ID
         field is an opaque field that can be used or ignored by service
         functions as determined by the control plane.

      001:  The Sub/Endpoint ID field contains an IMSI [itu-e-164].

      010:  The Sub/Endpoint ID field contains an MSISDN (8-15 digit)
         [itu-e-164].

      011:  The Sub/Endpoint ID field contains a 64-bit identifier that
         can be used to group flows (e.g., in Machine-to-Machine (M2M)
         contexts).

      100:  The Sub/Endpoint IP field contains a wireline subscriber ID
         in CH2, and CH3 contains the home identifier.

      101-111:  Reserved.

   Tag:  Indicates the type of the Service Information field in CH4.
      The following values are defined:

      000:  If the Tag field is not set, then the Service Information
         field in CH4 is an opaque field that can be used or ignored by
         SFs as determined by the control plane.

      001:  The Service Information field in CH4 contains information
         related to the Access Network (AN) for the subscriber.  This is
         shown in Figure 4 for a 3GPP Radio Access Network (RAN).



Napper, et al.            Expires July 18, 2018                 [Page 5]


Internet-Draft      NSH Broadband Context Allocation        January 2018


         Note that these values should correspond to those that can be
         obtained for the flow from the corresponding 3GPP PCRF (Policy
         and Charging Rules Function) component using Diameter as
         described in [TS.29.230].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CAN |    QoS/DSCP   | Con |          App Id         |  Rsvd   | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Service Information RAN Allocation

         CAN:  IP-CAN-Type for IP Connectivity Access Network (Diameter
            AVP code 1027).

         QoS:  QoS-Class-Identifier AVP (Diameter AVP code 1028) or
            Differentiated Services Code Point (DSCP) marking as
            described in [RFC2474].

         Con:  Access congestion level.  An Access Congestion level
            '000' means an unknown/undefined congestion level.  An
            Access Congestion level '001' means no congestion.  For
            other values of Access Congestion level, a higher value
            indicates a higher level of congestion.

         App Id:  Application ID describing the flow type.  Allocation
            of IDs is done using the control plane and is out of the
            scope of this document.

         Rsvd:  Reserved.

      010-111:  Reserved.

   Context ID:  The Context ID field allows the Subscriber/Endpoint ID
      field to be scoped.  For example, the Context ID field may contain
      the incoming VRF, VxLAN VNID, VLAN, or policy identifier within
      which the Subscriber/Endpoint ID field is defined.

   Sub/Endpoint ID:  64-bit length Subscriber/Endpoint identifier (e.g.,
      IMSI, MSISDN, or implementation-specific Endpoint ID) of the
      corresponding subscriber/machine/application for the flow.

   Service Information:  The Service Information field is a unique
      identifier that can carry metadata specific to the flow or
      subscriber identified in the Sub/Endpoint ID field.






Napper, et al.            Expires July 18, 2018                 [Page 6]


Internet-Draft      NSH Broadband Context Allocation        January 2018


4.2.  MD Type 0x02 Allocation Specifics

   The following Figure 5 provides a high-level description of the
   fields in the recommended allocation of the variable length headers
   for a mobility context.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TLV Class = 3GPP          |C|    Type     |U|U|U|   Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+

                         Figure 5: TLV Allocation

   The intended use of the header is for TLVs associated with 3GPP Radio
   Access Networks as described in [TS.29.230].  This TLV can be used by
   3GPP to extend the metadata as per use cases.  Having this TLV helps
   to carry more information that does not fit within the MD Type 0x01.

   The Len field carries the total length.  Type = 0x01 is reserved.  If
   set to 0x01, the TLV carries the 4 context headers as defined in
   Section 4.1.

   o  DISCUSSION NOTE: Should we ask for allocating a TLV class or
      restrict the document to asking for a TLV code from the IETF TLV
      Class 0?

5.  Context Allocation and Control Plane Considerations

   This document describes an allocation scheme for both the fixed
   context header (MD#1) and optional TLV headers (MD#2) in the context
   of broadband service providers.  This allocation of headers should be
   considered as a guideline and may vary depending on the use case.

   The control plane aspects of specifying and distributing the
   allocation scheme among different service functions within the
   Service Function Chaining environment to guarantee consistent
   semantics for the metadata is beyond the scope of this document.

6.  Security Considerations

   This specification relies on NSH to share metadata among SFC data
   plane elements.  Security-related consideration discussed in
   [RFC8300] MUST be followed.






Napper, et al.            Expires July 18, 2018                 [Page 7]


Internet-Draft      NSH Broadband Context Allocation        January 2018


   The recommended header allocation in this document includes sensitive
   information that MUST NOT be revealed outside an SFC-enabled domain.
   Those considerations are already discussed in [RFC8300].

   Furthermore, means to prevent that illegitimate nodes insert spoofed
   data MUST be supported.  As a reminder, the NSH specification assumes
   ingress boundary nodes strip any NSH data that may be present in a
   packet.  Misbehaving nodes from within an SFC-enabled domain may
   alter the content of the NSH data.  Such treats are discussed in
   [RFC8300].

7.  IANA Considerations

   This document requests IANA to assign a TLV class for 3GPP to be used
   for its use cases.

8.  Acknowledgments

   The authors would like to thank Jim Guichard for his assistance
   structuring the document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

9.2.  Informative References

   [I-D.ietf-sfc-control-plane]
              Boucadair, M., "Service Function Chaining (SFC) Control
              Plane Components & Requirements", draft-ietf-sfc-control-
              plane-08 (work in progress), October 2016.





Napper, et al.            Expires July 18, 2018                 [Page 8]


Internet-Draft      NSH Broadband Context Allocation        January 2018


   [I-D.ietf-sfc-use-case-mobility]
              Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
              J. Uttaro, "Service Function Chaining Use Cases in Mobile
              Networks", draft-ietf-sfc-use-case-mobility-07 (work in
              progress), October 2016.

   [itu-e-164]
              "The international public telecommunication numbering
              plan", ITU-T E.164, November 2010.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/info/rfc7498>.

   [TS.29.230]
              "Diameter applications; 3GPP specific codes and
              identifiers", 3GPP TS 29.230 14.5.0, July 2017.

Authors' Addresses

   Jeffrey Napper
   Cisco Systems, Inc.

   Email: jenapper@cisco.com


   Surendra Kumar
   Individual Contributor

   Email: surendra.stds@gmail.com


   Praveen Muley
   Nokia

   Email: praveen.muley@nokia.com








Napper, et al.            Expires July 18, 2018                 [Page 9]


Internet-Draft      NSH Broadband Context Allocation        January 2018


   Wim Hendericks
   Nokia

   Email: Wim.Henderickx@nokia.com


   Mohamed Boucadair
   Orange
   France

   Email: mohamed.boucadair@orange.com








































Napper, et al.            Expires July 18, 2018                [Page 10]