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

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 December 21, 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. Terminology
• 3. Network Service Header (NSH) Context Headers: A Reminder
• 4. Recommended Context Allocation For Broadband
• 4.1. MD Type 0x01 Allocation Specifics
• 4.2. MD Type 0x02 Allocation Specifics
• 5. Context Allocation and Control Plane Considerations
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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, [RFC8300]) provides support for carrying shared metadata either using a fixed context header or as optional TLVs.

This document describes 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 deployment contexts are described in [I-D.ietf-sfc-use-case-mobility].

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

2. Terminology

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

3. Network Service Header (NSH) Context Headers: A Reminder

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

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)

Figure 2 shows the MD Type 0x02 NSH 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|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 SFs that can use the metadata within to enforce service 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 SFs or even to the same SF but on different packets within a flow.

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

4.1. MD Type 0x01 Allocation Specifics

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

    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 fields is as follows:

R:

MUST be set to zero upon origination, and they MUST be ignored and preserved unmodified by other NSH supporting elements.

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:

The 64-bit Sub/Endpoint ID field is an opaque field that can be used or ignored by SFs 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 line 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, 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).

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

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 Sub/Endpoint ID field to be scoped. For example, the Context ID field may contain the incoming VRF, VxLAN VNID, VLAN, or a policy identifier within which the Sub/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

Figure 5 depictes the format of 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.

5. Context Allocation and Control Plane Considerations

This document describes an allocation scheme for both the fixed context header (MD Type#1) and optional TLV headers (MD Type#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 SFs 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.

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]. NSH allows by design to remove any NSH data before existing an SFC-enabled domain.

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]. This document does not introduce new treats compared to those 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

9.2. Informative References

Authors' Addresses