Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jeffrey Napper , Surendra Kumar
Last updated 2015-05-16
Replaced by draft-napper-sfc-nsh-broadband-allocation
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-napper-sfc-nsh-mobility-allocation-01
Service Function Chaining                                      J. Napper
Internet-Draft                                                  S. Kumar
Intended status: Informational                       Cisco Systems, Inc.
Expires: November 17, 2015                                  May 16, 2015

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

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 November 17, 2015.

Copyright Notice

   Copyright (c) 2015 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

Napper & Kumar          Expires November 17, 2015               [Page 1]
Internet-Draft       NSH Mobility Context Allocation            May 2015

   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.  Mobility Allocation Specifics . . . . . . . . . . . . . . . .   4
   6.  Context Allocation and Control Plane Considerations . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   5
     10.2.  Informative References . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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)
   povides 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 mobile service provider networks.  Supporting use cases
   describing the need for a metadata header in this context 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
   [ietf-sfc-arch].

Napper & Kumar          Expires November 17, 2015               [Page 2]
Internet-Draft       NSH Mobility Context Allocation            May 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 & Kumar          Expires November 17, 2015               [Page 3]
Internet-Draft       NSH Mobility Context Allocation            May 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flow Cookie                          | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserv  |TenTy|                  Tenant ID                    | CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Sub/App ID                          ~ CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Sub/App ID (cont.)                      | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: NSH Mobility Context Allocation

5.  Mobility Allocation Specifics

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

   Flow Cookie  - unique value with respect to the Subscriber/
      Application Identifier field that can be used to identify a packet
      or flow even if the encapsulated packet changes (e.g., when a flow
      is terminated at a proxy).

   Reserv  - Reserved.

   TenTy  - Tenant Type represents type of Tenant Identifier field
      (e.g., vlan, vxlan, vrf, mpls, etc.).

   Tenant ID  - value encoded according to Tenant Type field
      corresponding to encapsulated packet (e.g., ingress VRF id).  The
      Tenant ID field allows the Base Header (BH1) and Service Headers
      (SH) to be tenant independent.

   Sub/App ID  - 64-bit length Subscriber/Application identifier (e.g.,
      IMSI [itu-e-164], MSISDN (8-15 digit) [itu-e-164], or
      implementation-specific Application ID) of the corresponding
      subscriber/application for the flow.

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.

Napper & Kumar          Expires November 17, 2015               [Page 4]
Internet-Draft       NSH Mobility Context Allocation            May 2015

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, March 1997.

10.2.  Informative References

   [RFC7498]  Quinn, P. and T. Nadeau, "Problem Statement for Service
              Function Chaining", RFC 7498, April 2015.

   [guichard-sfc-nsh-dc-allocation]
              Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
              P., Glavin, K., and Y. Laribi, "Network Service Header
              (NSH) Context Header Allocation (Data Center)", I-D draft-
              guichard-sfc-nsh-dc-allocation-01 (work in progress),
              December 2014.

   [ietf-sfc-arch]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", I-D draft-ietf-sfc-architecture-08
              (work in progress), May 2015.

Napper & Kumar          Expires November 17, 2015               [Page 5]
Internet-Draft       NSH Mobility Context Allocation            May 2015

   [ietf-sfc-nsh]
              Quinn, P. and U. Elzur, "Network Service Header", I-D
              draft-ietf-sfc-nsh-00 (work in progress), March 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-03 (work
              in progress), January 2015.

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

Authors' Addresses

   Jeffrey Napper
   Cisco Systems, Inc.

   Email: jenapper@cisco.com

   Surendra Kumar
   Cisco Systems, Inc.

   Email: smkumar@cisco.com

Napper & Kumar          Expires November 17, 2015               [Page 6]