Service Function Chaining J. Napper
Internet-Draft S. Kumar
Updates: draft-napper-sfc-nsh-mobility- Cisco Systems, Inc.
allocation-03 (if approved) P. Muley
Intended status: Standards Track W. Hendericks
Expires: September 22, 2016 Nokia
March 21, 2016

NSH Context Header Allocation -- Broadband


This document provides a recommended allocation of context headers for a Network Service Header (NSH) within the broadband 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

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 September 22, 2016.

Copyright Notice

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

Service function chaining provides a mechanism for network traffic to be steered through multiple service functions in a sequence. Metadata can be useful to service functions. The Network Service Header (NSH) provides support for carrying shared metadata between service functions (and devices) either using 4 fixed-length 32-bit context headers or as optional TLVs 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 and for TLV types 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].

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) in the case of MD Type 0x01 and optional TLVs in the case of MD Type 0x02 as described in [ietf-sfc-nsh].

The following Figure 1 shows the MD Type 0x01 mandatory context headers.

 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

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

 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 = 0x02| Next Protocol | BH1
|          Service Path ID                      | Service Index | SH1
|                                                               |
~              Variable Length Context Headers  (opt.)          ~
|                                                               |

Figure 2: Network Service Header - MD Type 0x02

4. Recommended Context Allocation

The following header allocations provide information to support service function chaining in a mobile service provider network as described in [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 context 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
| R | Sub | Tag |                 Context ID                    | CH1
|                       Sub/Endpoint ID                         ~ CH2
~                   Sub/Endpoint ID (cont.)                     | CH3
|                    Service Information                        | CH4

Figure 3: NSH Context Allocation

 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

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

- Reserved.
- Sub/Endpoint ID type field. These bits determine the type of the 64-bit Sub/Endpoint ID field that spans CH2 and CH3.
- 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.
- The Sub/Endpoint ID field contains an IMSI [itu-e-164].
- The Sub/Endpoint ID field contains an MSISDN (8-15 digit) [itu-e-164].
- The Sub/Endpoint ID field contains a 64-bit identifier that can be used to group flows (e.g., in Machine-to-Machine, M2M).
- The Sub/Endpoint IP field contains a wireline subcriber ID in CH2, and CH3 contains the home identifier.
- Reserved.

- The Tag field indicates the type of the Service Information field in CH4. Some types for this field are specified by the Tag field as follows:
- 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 service functions as determined by the control plane.
- 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). 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].
- IP-CAN-Type for IP Connectivity Access Network (Diameter AVP code 1027).
- QoS-Class-Identifier AVP (Diameter AVP code 1028) or Differentiated Services Code Point (DSCP) marking as described in [RFC2474].
- 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 in the control plane and is out of the scope of this document.
- Reserved.

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

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

5. Context Allocation and Control Plane Considerations

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

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

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.

9.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.
[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.
[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.
[RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015.
[RFC7665] Halpern, J. and C. Pignataro, Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.
[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:
Surendra Kumar Cisco Systems, Inc. EMail:
Praveen Muley Nokia EMail:
Wim Hendericks Nokia EMail: