Internet DRAFT - draft-napper-sfc-nsh-mobility-allocation

draft-napper-sfc-nsh-mobility-allocation







Service Function Chaining                                      J. Napper
Internet-Draft                                                  S. Kumar
Intended status: Informational                       Cisco Systems, Inc.
Expires: May 7, 2016                                            P. Muley
                                                           W. Hendericks
                                                          Alcatel-Lucent
                                                        November 4, 2015


               NSH Context Header Allocation -- Mobility
              draft-napper-sfc-nsh-mobility-allocation-02

Abstract

   This document provides a recommended allocation of the mandatory
   fixed context headers for a Network Service Header (NSH) within the
   mobility service provider network context.  NSH is described in
   detail in [ietf-sfc-nsh].  This allocation is intended to support
   uses cases as defined in [ietf-sfc-use-case-mobility].

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 May 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Napper, et al.             Expires May 7, 2016                  [Page 1]

Internet-Draft       NSH Mobility Context Allocation       November 2015


   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
   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 . . . . . . . . . . . . . . . . . . . . .   2
   3.  Network Service Header (NSH) Context Headers  . . . . . . . .   3
   4.  Recommended Mobility Context Allocation . . . . . . . . . . .   3
   5.  Broadband Allocation Specifics  . . . . . . . . . . . . . . .   4
   6.  Context Allocation and Control Plane Considerations . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Service function chaining provides a mechanism for network traffic to
   be forced through multiple service functions in a sequence.  Metadata
   can be useful to service functions.  Network Service Headers (NSH)
   provides support for carrying shared metadata between service
   functions (and devices) using 4 fixed-length 32-bit context headers
   as defined in [ietf-sfc-nsh].  NSH is then encapsulated within an
   outer header for transport.

   This document provides a recommended default allocation scheme for
   the fixed-length context headers in the context of service chaining
   within fixed and mobile broadband service provider networks.
   Supporting use cases describing the need for a metadata header in
   these contexts are described in [ietf-sfc-use-case-mobility].  This
   draft does not address control plane mechanisms.

2.  Definition Of Terms

   This document uses the terms as defined in [RFC7498] and [RFC7665].





Napper, et al.             Expires May 7, 2016                  [Page 2]

Internet-Draft       NSH Mobility Context Allocation       November 2015


3.  Network Service Header (NSH) Context Headers

   In Service Function Chaining, the Network Service Header is composed
   of a 4-byte base header (BH1), a 4-byte service path header (SH1) and
   four mandatory 4-byte context headers (CH1-CH4) as described in
   [ietf-sfc-nsh].

    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|C|R|R|R|R|R|R|   Length  | MD Type = 0x01| Next Protocol | BH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path ID                      | Service Index | SH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Mandatory Context Header 1                     | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Mandatory Context Header 2                     | CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Mandatory Context Header 3                     | CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Mandatory Context Header 4                     | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Network Service Header - MD Type 0x01

4.  Recommended Mobility Context Allocation

   The following context header allocation provides information to
   support service function chaining in a mobile service provider
   network as described in [ietf-sfc-use-case-mobility].

   The set of context 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 context 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.












Napper, et al.             Expires May 7, 2016                  [Page 3]

Internet-Draft       NSH Mobility Context Allocation       November 2015


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ServiceTag                           | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: NSH Mobility Context Allocation

   Figure 2 provides a high-level description of the fields in the
   recommended allocation of the fixed context headers for a mobility
   context.

5.  Broadband Allocation Specifics

   The intended use for each of the context header allocations 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.

   Tag  - The Tag field indicates the type of the ServiceTag field in
      CH4.

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

   Sub/App 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.  This
      field is typed by the value of the Sub field as follows:

      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].



Napper, et al.             Expires May 7, 2016                  [Page 4]

Internet-Draft       NSH Mobility Context Allocation       November 2015


      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).

      100-111  - Reserved.

   ServiceTag  - A ServiceTag is a unique identifier that can carry
      metadata specific to the flow or subscriber identified in the Sub/
      App ID field.  Some types for this field are specified by the Tag
      field as follows:

      000  - If the Tag field is not set, then the ServiceTag field in
         CH4 is an opaque field that can be used or ignored by service
         functions as determined by the control plane.

      001  - The ServiceTag field in CH4 contains information related to
         the Radio Access Network (RAN) for the subscriber as follows in
         Figure 3.  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      |U| Con |    App Id               | Rsvd  | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Service Tag RAN Allocation

         CAN  - IP-CAN-Type (Diameter AVP code 1027).

         QoS  - QoS-Class-Identifier AVP (Diameter AVP code 1028).

         U  - QoS-Upgrade AVP (Diameter AVP code 1030).

         Con  - Congestion level.

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

         Rsvd  - Reserved.

      010-111  - Reserved.








Napper, et al.             Expires May 7, 2016                  [Page 5]

Internet-Draft       NSH Mobility Context Allocation       November 2015


6.  Context Allocation and Control Plane Considerations

   This document describes an allocation scheme for the mandatory
   context headers in the context of mobile service providers.  This
   suggested allocation of context 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.

7.  Security Considerations

   The context header allocation recommended by this document includes
   numbers that must be distributed consistently across a Service
   Function Chaining environment.  Protocols for distributing these
   numbers securely are required in the control plane, but are out of
   scope of this document.

   Furthermore, some of the metadata carried in the context headers
   require secure methods to prevent spoofing or modification by service
   function elements that may themselves be exposed to subscriber
   traffic and thus might be compromised.  This document does not
   address such security concerns.

8.  IANA Considerations

   This document has no actions for IANA.

9.  Acknowledgments

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

10.  References

10.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,
              <http://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [ietf-sfc-nsh]
              Quinn, P. and U. Elzur, "Network Service Header", I-D
              draft-ietf-sfc-nsh-01 (work in progress), July 2015.



Napper, et al.             Expires May 7, 2016                  [Page 6]

Internet-Draft       NSH Mobility Context Allocation       November 2015


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

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

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

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

   [TS.29.230]
              "Diameter applications; 3GPP specific codes and
              identifiers", 3GPP TS 29.230 13.2.0, September 2015.

Authors' Addresses

   Jeffrey Napper
   Cisco Systems, Inc.

   Email: jenapper@cisco.com


   Surendra Kumar
   Cisco Systems, Inc.

   Email: smkumar@cisco.com


   Praveen Muley
   Alcatel-Lucent

   Email: praveen.muley@alcatel-lucent.com


   Wim Hendericks
   Alcatel-Lucent

   Email: Wim.Henderickx@alcatel-lucent.com



Napper, et al.             Expires May 7, 2016                  [Page 7]