Internet DRAFT - draft-napper-sfc-nsh-broadband-allocation
draft-napper-sfc-nsh-broadband-allocation
Service Function Chaining J. Napper
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Kumar
Expires: May 16, 2018 Individual Contributor
P. Muley
W. Hendericks
Nokia
M. Boucadair
Orange
November 12, 2017
NSH Context Header Allocation -- Broadband
draft-napper-sfc-nsh-broadband-allocation-04
Abstract
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 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 May 16, 2018.
Napper, et al. Expires May 16, 2018 [Page 1]
Internet-Draft NSH Broadband Context Allocation November 2017
Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . 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 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
Napper, et al. Expires May 16, 2018 [Page 2]
Internet-Draft NSH Broadband Context Allocation November 2017
[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
a mandatory 16-byte context header 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|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 optional TLV header
format.
Napper, et al. Expires May 16, 2018 [Page 3]
Internet-Draft NSH Broadband Context Allocation November 2017
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
The following header allocations provide information to support
service function chaining in a service provider network, for example
as described for mobility 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 sixteen byte
context headers for a mobility context. Each four byte word in the
sixteen byte context header is referred as CH1, CH2, CH3 and CH4,
respectively.
Napper, et al. Expires May 16, 2018 [Page 4]
Internet-Draft NSH Broadband Context Allocation November 2017
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 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.
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).
100 - The Sub/Endpoint IP field contains a wireline subcriber ID
in CH2, and CH3 contains the home identifier.
101-111 - Reserved.
Tag - 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:
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
service functions 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
Napper, et al. Expires May 16, 2018 [Page 5]
Internet-Draft NSH Broadband Context Allocation November 2017
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].
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 in 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 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.
Napper, et al. Expires May 16, 2018 [Page 6]
Internet-Draft NSH Broadband Context Allocation November 2017
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.
Napper, et al. Expires May 16, 2018 [Page 7]
Internet-Draft NSH Broadband Context Allocation November 2017
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>.
9.2. Informative References
[ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header", I-D draft-ietf-sfc-nsh-15 (work in progress),
July 2017.
[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-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>.
Napper, et al. Expires May 16, 2018 [Page 8]
Internet-Draft NSH Broadband Context Allocation November 2017
[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>.
[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
Wim Hendericks
Nokia
Email: Wim.Henderickx@nokia.com
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Napper, et al. Expires May 16, 2018 [Page 9]
