draft-ietf-sfc-nsh-broadband-allocation-00.txt   draft-ietf-sfc-nsh-broadband-allocation-01.txt 
Service Function Chaining J. Napper Service Function Chaining J. Napper
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Kumar Intended status: Standards Track S. Kumar
Expires: July 18, 2018 Individual Contributor Expires: December 21, 2018 Individual Contributor
P. Muley P. Muley
W. Hendericks W. Hendericks
Nokia Nokia
M. Boucadair M. Boucadair
Orange Orange
January 14, 2018 June 19, 2018
NSH Context Header Allocation for Broadband NSH Context Header Allocation for Broadband
draft-ietf-sfc-nsh-broadband-allocation-00 draft-ietf-sfc-nsh-broadband-allocation-01
Abstract Abstract
This document provides a recommended allocation of Network Service This document provides a recommended allocation of Network Service
Header (NSH) context headers within the broadband service provider Header (NSH) context headers within the broadband service provider
network context. Both fixed and mobile deployments are considered. network context. Both fixed and mobile deployments are considered.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2018. This Internet-Draft will expire on December 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Service Header (NSH) Context Headers . . . . . . . . 3 3. Network Service Header (NSH) Context Headers: A Reminder . . 3
4. Recommended Context Allocation For Broadband . . . . . . . . 4 4. Recommended Context Allocation For Broadband . . . . . . . . 4
4.1. MD Type 0x01 Allocation Specifics . . . . . . . . . . . . 4 4.1. MD Type 0x01 Allocation Specifics . . . . . . . . . . . . 4
4.2. MD Type 0x02 Allocation Specifics . . . . . . . . . . . . 7 4.2. MD Type 0x02 Allocation Specifics . . . . . . . . . . . . 6
5. Context Allocation and Control Plane Considerations . . . . . 7 5. Context Allocation and Control Plane Considerations . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Service Function Chaining (SFC) [RFC7665] provides a mechanism for Service Function Chaining (SFC) [RFC7665] provides a mechanism for
network traffic to be steered through an ordered list of Service network traffic to be steered through an ordered list of Service
Functions (SFs). Furthermore, SFC allows to share metadata among Functions (SFs). Furthermore, SFC allows to share metadata among
involved SFC data functional elements (classifiers and SFs). involved SFC data functional elements (classifiers and SFs).
Particularly, the Network Service Header (NSH) provides support for Particularly, the Network Service Header (NSH, [RFC8300]) provides
carrying shared metadata either using a fixed context header or as support for carrying shared metadata either using a fixed context
optional TLVs [RFC8300]. header or as optional TLVs.
This document provides a recommended default allocation scheme for This document describes a recommended default allocation scheme for
the fixed-length context header used for SFC within fixed and mobile the fixed-length context header used for SFC within fixed and mobile
broadband service provider networks. Also, the document defines broadband service provider networks. Also, the document defines
companion TLV types when MD Type 0x02 is used. The use cases companion TLV types when MD Type 0x02 is used. The use cases
describing the need for metadata in these contexts are described in describing the need for metadata in these deployment contexts are
[I-D.ietf-sfc-use-case-mobility]. described in [I-D.ietf-sfc-use-case-mobility].
This document does not address control plane mechanisms. The reader This document does not address control plane considerations. The
may refer to [I-D.ietf-sfc-control-plane]. reader may refer to [I-D.ietf-sfc-control-plane].
2. Definition Of Terms 2. Terminology
This document makes use of the terms as defined in [RFC7498], This document makes use of the terms as defined in [RFC7498],
[RFC7665], and [RFC8300]. [RFC7665], and [RFC8300].
3. Network Service Header (NSH) Context Headers 3. Network Service Header (NSH) Context Headers: A Reminder
The NSH is composed of a 4-byte base header (BH1), a 4-byte service The NSH 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 path header (SH1), and a fixed 16-byte context header in the case of
of MD Type 0x01 and optional TLVs in the case of MD Type 0x02 MD Type 0x01 or optional TLVs in the case of MD Type 0x02 [RFC8300].
[RFC8300].
The following Figure 1 shows the format of the MD Type 0x01 NSH Figure 1 shows the format of the MD Type 0x01 NSH header.
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 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 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index | SH1 | Service Path Identifier | Service Index | SH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Fixed | | Fixed |
+ Context Header + + Context Header +
| (16 Bytes) | | (16 Bytes) |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Network Service Header (MD Type 0x01) Figure 1: Network Service Header (MD Type 0x01)
The following Figure 2 shows the MD Type 0x02 NSH header format. 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 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 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index | SH1 | Service Path Identifier | Service Index | SH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Variable Length Context Headers (opt.) ~ ~ Variable Length Context Headers (opt.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Network Service Header (MD Type 0x02) Figure 2: Network Service Header (MD Type 0x02)
4. Recommended Context Allocation For Broadband 4. Recommended Context Allocation For Broadband
The following header allocations provide information to support The following header allocations provide information to support
service function chaining in a service provider network, for example service function chaining in a service provider network, for example
as described for mobility in [I-D.ietf-sfc-use-case-mobility]. as described for mobility in [I-D.ietf-sfc-use-case-mobility].
The set of metadata headers can be delivered to service functions The set of metadata headers can be delivered to SFs that can use the
that can use the metadata within to enforce policy, communicate metadata within to enforce service policy, communicate between
between service functions, provide subscriber information and other service functions, provide subscriber information, and other
functionality. Several of the headers are typed allowing for functionality. Several of the headers are typed allowing for
different metadata to be provided to different service functions or different metadata to be provided to different SFs or even to the
even to the same service function but on different packets within a same SF but on different packets within a flow.
flow.
Which metadata are sent to which service functions is decided in the Which metadata are sent to which SFs is decided in the SFC control
SFC control plane and is thus out of the scope of this document. plane and is thus out of the scope of this document.
4.1. MD Type 0x01 Allocation Specifics 4.1. MD Type 0x01 Allocation Specifics
The following Figure 3 provides a high-level description of the Figure 3 provides a high-level description of the fields in the
fields in the recommended allocation of the fixed sixteen byte recommended allocation of the fixed sixteen byte context header for a
context headers for a broadband context. Each four byte word in the broadband context. Each four byte word in the sixteen byte context
sixteen byte context header is referred to as CH1, CH2, CH3, and CH4, header is referred to as CH1, CH2, CH3, and CH4, respectively.
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 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 | R | Sub | Tag | Context ID | CH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub/Endpoint ID ~ CH2 | Sub/Endpoint ID ~ CH2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub/Endpoint ID (cont.) | CH3 ~ Sub/Endpoint ID (cont.) | CH3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Information | CH4 | Service Information | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH Context Allocation Figure 3: NSH Context Allocation
The intended use for each of the context header fields is as follows: The intended use for each of the context header fields is as follows:
R: Reserved. 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 Sub: Sub/Endpoint ID type field. These bits determine the type of
the 64-bit Sub/Endpoint ID field that spans CH2 and CH3. 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 000: The 64-bit Sub/Endpoint ID field is an opaque field that can
field is an opaque field that can be used or ignored by service be used or ignored by SFs as determined by the control plane.
functions as determined by the control plane.
001: The Sub/Endpoint ID field contains an IMSI [itu-e-164]. 001: The Sub/Endpoint ID field contains an IMSI [itu-e-164].
010: The Sub/Endpoint ID field contains an MSISDN (8-15 digit) 010: The Sub/Endpoint ID field contains an MSISDN (8-15 digit)
[itu-e-164]. [itu-e-164].
011: The Sub/Endpoint ID field contains a 64-bit identifier that 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) can be used to group flows (e.g., in Machine-to-Machine (M2M)
contexts). contexts).
100: The Sub/Endpoint IP field contains a wireline subscriber ID 100: The Sub/Endpoint IP field contains a wireline subscriber ID
in CH2, and CH3 contains the home identifier. in CH2, and CH3 contains the line identifier.
101-111: Reserved. 101-111: Reserved.
Tag: Indicates the type of the Service Information field in CH4. Tag: Indicates the type of the Service Information field in CH4.
The following values are defined: The following values are defined:
000: If the Tag field is not set, then the Service Information 000: If the Tag field is not set, the Service Information field
field in CH4 is an opaque field that can be used or ignored by in CH4 is an opaque field that can be used or ignored by SFs as
SFs as determined by the control plane. determined by the control plane.
001: The Service Information field in CH4 contains information 001: The Service Information field in CH4 contains information
related to the Access Network (AN) for the subscriber. This is related to the Access Network (AN) for the subscriber. This is
shown in Figure 4 for a 3GPP Radio Access Network (RAN). shown in Figure 4 for a 3GPP Radio Access Network (RAN).
Note that these values should correspond to those that can be Note that these values should correspond to those that can be
obtained for the flow from the corresponding 3GPP PCRF (Policy obtained for the flow from the corresponding 3GPP PCRF (Policy
and Charging Rules Function) component using Diameter as and Charging Rules Function) component using Diameter as
described in [TS.29.230]. described in [TS.29.230].
skipping to change at page 6, line 38 skipping to change at page 6, line 13
indicates a higher level of congestion. indicates a higher level of congestion.
App Id: Application ID describing the flow type. Allocation App Id: Application ID describing the flow type. Allocation
of IDs is done using the control plane and is out of the of IDs is done using the control plane and is out of the
scope of this document. scope of this document.
Rsvd: Reserved. Rsvd: Reserved.
010-111: Reserved. 010-111: Reserved.
Context ID: The Context ID field allows the Subscriber/Endpoint ID Context ID: The Context ID field allows the Sub/Endpoint ID field to
field to be scoped. For example, the Context ID field may contain be scoped. For example, the Context ID field may contain the
the incoming VRF, VxLAN VNID, VLAN, or policy identifier within incoming VRF, VxLAN VNID, VLAN, or a policy identifier within
which the Subscriber/Endpoint ID field is defined. which the Sub/Endpoint ID field is defined.
Sub/Endpoint ID: 64-bit length Subscriber/Endpoint identifier (e.g., Sub/Endpoint ID: 64-bit length Subscriber/Endpoint identifier (e.g.,
IMSI, MSISDN, or implementation-specific Endpoint ID) of the IMSI, MSISDN, or implementation-specific Endpoint ID) of the
corresponding subscriber/machine/application for the flow. corresponding subscriber/machine/application for the flow.
Service Information: The Service Information field is a unique Service Information: The Service Information field is a unique
identifier that can carry metadata specific to the flow or identifier that can carry metadata specific to the flow or
subscriber identified in the Sub/Endpoint ID field. subscriber identified in the Sub/Endpoint ID field.
4.2. MD Type 0x02 Allocation Specifics 4.2. MD Type 0x02 Allocation Specifics
The following Figure 5 provides a high-level description of the Figure 5 depictes the format of the recommended allocation of the
fields in the recommended allocation of the variable length headers variable length headers for a mobility context.
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 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 | | TLV Class = 3GPP |C| Type |U|U|U| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Data ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: TLV Allocation Figure 5: TLV Allocation
The intended use of the header is for TLVs associated with 3GPP Radio 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 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 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. 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 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 set to 0x01, the TLV carries the 4 context headers as defined in
Section 4.1. Section 4.1.
o DISCUSSION NOTE: Should we ask for allocating a TLV class or
restrict the document to asking for a TLV code from the IETF TLV
Class 0?
5. Context Allocation and Control Plane Considerations 5. Context Allocation and Control Plane Considerations
This document describes an allocation scheme for both the fixed This document describes an allocation scheme for both the fixed
context header (MD#1) and optional TLV headers (MD#2) in the context context header (MD Type#1) and optional TLV headers (MD Type#2) in
of broadband service providers. This allocation of headers should be the context of broadband service providers. This allocation of
considered as a guideline and may vary depending on the use case. headers should be considered as a guideline and may vary depending on
the use case.
The control plane aspects of specifying and distributing the The control plane aspects of specifying and distributing the
allocation scheme among different service functions within the allocation scheme among different SFs within the Service Function
Service Function Chaining environment to guarantee consistent Chaining environment to guarantee consistent semantics for the
semantics for the metadata is beyond the scope of this document. metadata is beyond the scope of this document.
6. Security Considerations 6. Security Considerations
This specification relies on NSH to share metadata among SFC data This specification relies on NSH to share metadata among SFC data
plane elements. Security-related consideration discussed in plane elements. Security-related consideration discussed in
[RFC8300] MUST be followed. [RFC8300] MUST be followed.
The recommended header allocation in this document includes sensitive The recommended header allocation in this document includes sensitive
information that MUST NOT be revealed outside an SFC-enabled domain. information that MUST NOT be revealed outside an SFC-enabled domain.
Those considerations are already discussed in [RFC8300]. 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 Furthermore, means to prevent that illegitimate nodes insert spoofed
data MUST be supported. As a reminder, the NSH specification assumes data MUST be supported. As a reminder, the NSH specification assumes
ingress boundary nodes strip any NSH data that may be present in a ingress boundary nodes strip any NSH data that may be present in a
packet. Misbehaving nodes from within an SFC-enabled domain may packet. Misbehaving nodes from within an SFC-enabled domain may
alter the content of the NSH data. Such treats are discussed in alter the content of the NSH data. Such treats are discussed in
[RFC8300]. [RFC8300]. This document does not introduce new treats compared to
those discussed in [RFC8300].
7. IANA Considerations 7. IANA Considerations
This document requests IANA to assign a TLV class for 3GPP to be used This document requests IANA to assign a TLV class for 3GPP to be used
for its use cases. for its use cases.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Jim Guichard for his assistance The authors would like to thank Jim Guichard for his assistance
structuring the document. structuring the document.
skipping to change at page 9, line 8 skipping to change at page 8, line 31
9.2. Informative References 9.2. Informative References
[I-D.ietf-sfc-control-plane] [I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control- Plane Components & Requirements", draft-ietf-sfc-control-
plane-08 (work in progress), October 2016. plane-08 (work in progress), October 2016.
[I-D.ietf-sfc-use-case-mobility] [I-D.ietf-sfc-use-case-mobility]
Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
J. Uttaro, "Service Function Chaining Use Cases in Mobile J. Uttaro, "Service Function Chaining Use Cases in Mobile
Networks", draft-ietf-sfc-use-case-mobility-07 (work in Networks", draft-ietf-sfc-use-case-mobility-08 (work in
progress), October 2016. progress), May 2018.
[itu-e-164] [itu-e-164]
"The international public telecommunication numbering "The international public telecommunication numbering
plan", ITU-T E.164, November 2010. plan", ITU-T E.164, November 2010.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
 End of changes. 32 change blocks. 
68 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/