draft-ietf-sfc-nsh-19.txt   draft-ietf-sfc-nsh-20.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: February 13, 2018 Intel Expires: March 5, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
August 12, 2017 September 1, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-19 draft-ietf-sfc-nsh-20
Abstract Abstract
This document describes a Network Service Header (NSH) inserted onto This document describes a Network Service Header (NSH) imposed on
packets or frames to realize service function paths. NSH also packets or frames to realize service function paths. The NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service paths. NSH is the SFC encapsulation required to support the service paths. The NSH is the SFC encapsulation required to support
Service Function Chaining (SFC) architecture (defined in RFC7665). the Service Function Chaining (SFC) architecture (defined in
RFC7665).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 13, 2018. This Internet-Draft will expire on March 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 16 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5
1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5 1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5
2. Network Service Header . . . . . . . . . . . . . . . . . . . 6 2. Network Service Header . . . . . . . . . . . . . . . . . . . 6
2.1. Network Service Header Format . . . . . . . . . . . . . . 6 2.1. Network Service Header Format . . . . . . . . . . . . . . 7
2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7
2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10
2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 10 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 11
2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 11 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1. Optional Variable Length Metadata . . . . . . . . . . 12 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 12
3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 15 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16
5. Fragmentation Considerations . . . . . . . . . . . . . . . . 15 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17
6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 16 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17
6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 16 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17
6.2. Mapping NSH to Network Transport . . . . . . . . . . . . 19 6.2. Mapping the NSH to Network Transport . . . . . . . . . . 20
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 20 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 20 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 20 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 20 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 22 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23
7.3. Service Path Identifier and Metadata . . . . . . . . . . 24 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 28 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 28
11.2. Network Service Header (NSH) Parameters . . . . . . . . 28 11.2. Network Service Header (NSH) Parameters . . . . . . . . 28
11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29 11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29
11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29 11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 29 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 29
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 30 11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 30
11.2.6. New IETF Assigned Optional Variable Length Metadata 11.2.6. New IETF Assigned Optional Variable Length Metadata
skipping to change at page 3, line 15 skipping to change at page 3, line 15
1. Introduction 1. Introduction
Service functions are widely deployed and essential in many networks. Service functions are widely deployed and essential in many networks.
These service functions provide a range of features such as security, These service functions provide a range of features such as security,
WAN acceleration, and server load balancing. Service functions may WAN acceleration, and server load balancing. Service functions may
be instantiated at different points in the network infrastructure be instantiated at different points in the network infrastructure
such as the wide area network, data center, campus, and so forth. such as the wide area network, data center, campus, and so forth.
Prior to development of the SFC architecture [RFC7665] and the Prior to development of the SFC architecture [RFC7665] and the
protocol specified in this document, current service function protocol specified in this document, current service function
deployment models have been relatively static, and bound to topology deployment models have been relatively static and bound to topology
for insertion and policy selection. Furthermore, they do not adapt for insertion and policy selection. Furthermore, they do not adapt
well to elastic service environments enabled by virtualization. well to elastic service environments enabled by virtualization.
New data center network and cloud architectures require more flexible New data center network and cloud architectures require more flexible
service function deployment models. Additionally, the transition to service function deployment models. Additionally, the transition to
virtual platforms demands an agile service insertion model that virtual platforms demands an agile service insertion model that
supports dynamic and elastic service delivery. Specifically, the supports dynamic and elastic service delivery. Specifically, the
following functions are necessary: following functions are necessary:
The movement of service functions and application workloads in the 1. The movement of service functions and application workloads in
network. the network.
The ability to easily bind service policy to granular information, 2. The ability to easily bind service policy to granular
such as per-subscriber state. information, such as per-subscriber state.
The capability to steer traffic to the requisite service 3. The capability to steer traffic to the requisite service
function(s). function(s).
The Network Service Header (NSH) specification defines a new protocol The Network Service Header (NSH) specification defines a new protocol
for the creation of dynamic service chains, operating at the service and associated encapsulation for the creation of dynamic service
plane. NSH is composed of the following elements: chains, operating at the service plane. The NSH is designed to
encapsulate an original packet or frame, and in turn be encapsulated
by an outer transport (which is used to deliver the NSH to NSH-aware
network elements), as shown in Figure 1:
+------------------------------+
| Transport Encapsulation |
+------------------------------+
| Network Service Header (NSH) |
+------------------------------+
| Original Packet / Frame |
+------------------------------+
Figure 1: Network Service Header Encapsulation
The NSH is composed of the following elements:
1. Service Function Path identification. 1. Service Function Path identification.
2. Indication of location within a Service Function Path. 2. Indication of location within a Service Function Path.
3. Optional, per packet metadata (fixed length or variable). 3. Optional, per packet metadata (fixed length or variable).
NSH is designed to be easy to implement across a range of devices, The NSH is designed to be easy to implement across a range of
both physical and virtual, including hardware platforms. devices, both physical and virtual, including hardware platforms.
The intended scope of NSH is for use within a single provider's The intended scope of the NSH is for use within a single provider's
operational domain. This deployment scope is deliberatedly operational domain. This deployment scope is deliberately
constrained, as explained also in [RFC7665], and limited to a single constrained, as explained also in [RFC7665], and limited to a single
network administrative domain. In this context, a "domain" is a set network administrative domain. In this context, a "domain" is a set
of network entities within a single administration. For example, a of network entities within a single administration. For example, a
network administrative domain can include a single data center, a network administrative domain can include a single data center, a
campus physical network, or an overlay domain using virtual campus physical network, or an overlay domain using virtual
connetions and tunnels. A corollary is that a network administrative connections and tunnels. A corollary is that a network
domain has a well defined perimeter. administrative domain has a well defined perimeter.
An NSH-aware control plane is outside the scope of this document. An NSH-aware control plane is outside the scope of this document.
[RFC7665] provides an overview of a service chaining architecture [RFC7665] provides an overview of a service chaining architecture
that clearly defines the roles of the various elements and the scope that clearly defines the roles of the various elements and the scope
of a service function chaining encapsulation. NSH is the SFC of a service function chaining encapsulation. The NSH is the SFC
encapsulation referenced in [RFC7665]. encapsulation referenced in [RFC7665].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Definition of Terms 1.2. Definition of Terms
Byte: All references to "bytes" in this document refer to 8-bit Byte: All references to "bytes" in this document refer to 8-bit
bytes, or octets. bytes, or octets.
Classification: Defined in [RFC7665]. Classification: Defined in [RFC7665].
Classifier: Defined in [RFC7665]. Classifier: Defined in [RFC7665].
Metadata: Defined in [RFC7665]. Metadata: Defined in [RFC7665]. The metadata, or context
information shared between classifiers and SFs, and among SFs, is
carried on the NSH's Context Headers. It allows summarizing a
classification result in the packet itself, avoiding subsequent
re-classifications. Examples of metadata include classification
information used for policy enforcement and network context for
forwarding post service delivery.
Network Locator: Dataplane address, typically IPv4 or IPv6, used to Network Locator: Data plane address, typically IPv4 or IPv6, used to
send and receive network traffic. send and receive network traffic.
Network Node/Element: Device that forwards packets or frames based Network Node/Element: Device that forwards packets or frames based
on an outer header (i.e., encapsulation) information. on an outer header (i.e., encapsulation) information.
Network Overlay: Logical network built on top of existing network Network Overlay: Logical network built on top of existing network
(the underlay). Packets are encapsulated or tunneled to create (the underlay). Packets are encapsulated or tunneled to create
the overlay network topology. the overlay network topology.
NSH-aware: NSH-aware means SFC-encapsulation-aware, with NSH as the NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH
SFC encapsulation. This specification uses NSH-aware as a more provides the SFC encapsulation. This specification uses NSH-aware
specific term from the more generic term SFC-aware [RFC7665]. as a more specific term from the more generic term SFC-aware
[RFC7665].
Service Classifier: Logical entity providing classification Service Classifier: Logical entity providing classification
function. Since they are logical, classifiers may be co-resident function. Since they are logical, classifiers may be co-resident
with SFC elements such as SFs or SFFs. Service classifiers with SFC elements such as SFs or SFFs. Service classifiers
perform classification and impose NSH. The initial classifier perform classification and impose the NSH. The initial classifier
imposes the initial NSH and sends the NSH packet to the first SFF imposes the initial NSH and sends the NSH packet to the first SFF
in the path. Non-initial (i.e., subsequent) classification can in the path. Non-initial (i.e., subsequent) classification can
occur as needed and can alter, or create a new service path. occur as needed and can alter, or create a new service path.
Service Function (SF): Defined in [RFC7665]. Service Function (SF): Defined in [RFC7665].
Service Function Chain (SFC): Defined in [RFC7665]. Service Function Chain (SFC): Defined in [RFC7665].
Service Function Forwarder (SFF): Defined in [RFC7665]. Service Function Forwarder (SFF): Defined in [RFC7665].
Service Function Path (SFP): Defined in [RFC7665]. Service Function Path (SFP): Defined in [RFC7665].
Service Plane: The collection of SFFs and associated SFs creates a Service Plane: The collection of SFFs and associated SFs creates a
service-plane overlay in which all SFs reside [RFC7665]. service-plane overlay in which all SFs and SFC Proxies reside
[RFC7665].
SFC Proxy: Defined in [RFC7665]. SFC Proxy: Defined in [RFC7665].
1.3. Problem Space 1.3. Problem Space
NSH addresses several limitations associated with service function The NSH addresses several limitations associated with service
deployments. [RFC7498] provides a comprehensive review of those function deployments. [RFC7498] provides a comprehensive review of
issues. those issues.
1.4. NSH-based Service Chaining 1.4. NSH-based Service Chaining
NSH creates a dedicated service plane, more specifically, NSH The NSH creates a dedicated service plane; more specifically, the NSH
enables: enables:
1. Topological Independence: Service forwarding occurs within the 1. Topological Independence: Service forwarding occurs within the
service plane, the underlying network topology does not require service plane, so the underlying network topology does not
modification. NSH provides an identifier used to select the require modification. The NSH provides an identifier used to
network overlay for network forwarding. select the network overlay for network forwarding.
2. Service Chaining: NSH enables service chaining per [RFC7665]. 2. Service Chaining: The NSH enables service chaining per [RFC7665].
NSH contains path identification information needed to realize a The NSH contains path identification information needed to
service path. Furthermore, NSH provides the ability to monitor realize a service path. Furthermore, the NSH provides the
and troubleshoot a service chain, end-to-end via service-specific ability to monitor and troubleshoot a service chain, end-to-end
OAM messages. NSH fields can be used by administrators (via, for via service-specific OAM messages. The NSH fields can be used by
example, a traffic analyzer) to verify (account, ensure correct administrators (via, for example, a traffic analyzer) to verify
chaining, provide reports, etc.) the path specifics of packets (account, ensure correct chaining, provide reports, etc.) the
being forwarded along a service path. path specifics of packets being forwarded along a service path.
3. NSH provides a mechanism to carry shared metadata between 3. The NSH provides a mechanism to carry shared metadata between
participating entities and service functions. The semantics of participating entities and service functions. The semantics of
the shared metadata is communicated via a control plane, which is the shared metadata is communicated via a control plane, which is
outside the scope of this document, to participating nodes. outside the scope of this document, to participating nodes.
[I-D.ietf-sfc-control-plane] provides an example of such in [I-D.ietf-sfc-control-plane] provides an example of such in
Section 3.3. Examples of metadata include classification Section 3.3. Examples of metadata include classification
information used for policy enforcement and network context for information used for policy enforcement and network context for
forwarding post service delivery. Sharing the metadata allows forwarding post service delivery. Sharing the metadata allows
service functions to share initial and intermediate service functions to share initial and intermediate
classification results with downstream service functions saving classification results with downstream service functions saving
re-classification, where enough information was enclosed. re-classification, where enough information was enclosed.
4. NSH offers a common and standards-based header for service 4. The NSH offers a common and standards-based header for service
chaining to all network and service nodes. chaining to all network and service nodes.
5. Transport Agnostic: NSH is encapsulation-independent, meaning it 5. Transport Agnostic: The NSH is encapsulation-independent, meaning
can be transported by a variety of protocols. An appropriate it can be transported by a variety of protocols. An appropriate
(for a given deployment) encapsulation protocol can be used to (for a given deployment) encapsulation protocol can be used to
carry NSH-encapsulated traffic. This transport may form an carry NSH-encapsulated traffic. This transport may form an
overlay network and if an existing overlay topology provides the overlay network and if an existing overlay topology provides the
required service path connectivity, that existing overlay may be required service path connectivity, that existing overlay may be
used. used.
2. Network Service Header 2. Network Service Header
NSH contains service path information and optionally metadata that An NSH is imposed on the original packet/frame. This NSH contains
are added to a packet or frame and used to create a service plane. service path information and optionally metadata that are added to a
An outer transport header is imposed, on NSH and the original packet/ packet or frame and used to create a service plane. Subsequently, an
frame, for network forwarding. outer encapsulation is imposed on the NSH, which is used for network
forwarding.
A Service Classifier adds NSH. NSH is removed by the last SFF in the A Service Classifier adds the NSH. The NSH is removed by the last
service chain or by an SF that consumes the packet. SFF in the service chain or by an SF that consumes the packet.
2.1. Network Service Header Format 2.1. Network Service Header Format
NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header The NSH is composed of a 4-byte Base Header, a 4-byte Service Path
and optional Context Headers, as shown in Figure 1 below. Header and optional Context Headers, as shown in Figure 2 below.
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header | | Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Header | | Service Path Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Context Header(s) ~ ~ Context Header(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Network Service Header Figure 2: Network Service Header
Base header: Provides information about the service header and the Base header: Provides information about the service header and the
payload protocol. payload protocol.
Service Path Header: Provides path identification and location within Service Path Header: Provides path identification and location within
a service path. a service path.
Context header: Carries metadata (i.e., context data) along a service Context header: Carries metadata (i.e., context data) along a service
path. path.
2.2. NSH Base Header 2.2. NSH Base Header
Figure 2 depicts the NSH base header: Figure 3 depicts the NSH base header:
0 1 2 3 0 1 2 3
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 | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH Base Header Figure 3: NSH Base Header
Base Header Field Descriptions: Base Header Field Descriptions:
Version: The version field is used to ensure backward compatibility Version: The version field is used to ensure backward compatibility
going forward with future NSH specification updates. It MUST be set going forward with future NSH specification updates. It MUST be set
to 0x0 by the sender, in this first revision of NSH. Given the to 0x0 by the sender, in this first revision of the NSH. Given the
widespread implementation of existing hardware that uses the first widespread implementation of existing hardware that uses the first
nibble after an MPLS label stack for ECMP decision processing, this nibble after an MPLS label stack for equal-cost multipath (ECMP)
document reserves version 01b and this value MUST NOT be used in decision processing, this document reserves version 01b. This value
future versions of the protocol. Please see [RFC7325] for further MUST NOT be used in future versions of the protocol. Please see
discussion of MPLS-related forwarding requirements. [RFC7325] for further discussion of MPLS-related forwarding
requirements.
O bit: Setting this bit indicates an Operations, Administration, and O bit: Setting this bit indicates an Operations, Administration, and
Maintenance (OAM) packet. The actual format and processing of SFC Maintenance (OAM) packet. The actual format and processing of SFC
OAM packets is outside the scope of this specification (see for OAM packets is outside the scope of this specification (see for
example [I-D.ietf-sfc-oam-framework] for one approach). example [I-D.ietf-sfc-oam-framework] for one approach).
The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM
packets. The O bit MUST NOT be modified along the SFP. packets. The O bit MUST NOT be modified along the SFP.
SF/SFF/SFC Proxy/Classifier implementations that do not support SFC SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
OAM procedures SHOULD discard packets with O bit set, but MAY support OAM procedures SHOULD discard packets with O bit set, but MAY support
a configurable parameter to enable forwarding received SFC OAM a configurable parameter to enable forwarding received SFC OAM
packets unmodified to the next element in the chain. Forwarding OAM packets unmodified to the next element in the chain. Forwarding OAM
packets unmodified by SFC elements that do not support SFC OAM packets unmodified by SFC elements that do not support SFC OAM
procedures may be acceptable for a subset of OAM functions, but can procedures may be acceptable for a subset of OAM functions, but can
result in unexpected outcomes for others, thus it is recommended to result in unexpected outcomes for others; thus, it is recommended to
analyze the impact of forwarding an OAM packet for all OAM functions analyze the impact of forwarding an OAM packet for all OAM functions
prior to enabling this behavior. The configurable parameter MUST be prior to enabling this behavior. The configurable parameter MUST be
disabled by default. disabled by default.
TTL: Indicates the maximum SFF hops for an SFP. This field is used TTL: Indicates the maximum SFF hops for an SFP. This field is used
for service plane loop detection. The initial TTL value SHOULD be for service plane loop detection. The initial TTL value SHOULD be
configurable via the control plane; the configured initial value can configurable via the control plane; the configured initial value can
be specific to one or more SFPs. If no initial value is explicitly be specific to one or more SFPs. If no initial value is explicitly
provided, the default initial TTL value of 63 MUST be used. Each SFF provided, the default initial TTL value of 63 MUST be used. Each SFF
involved in forwarding an NSH packet MUST decrement the TTL value by involved in forwarding an NSH packet MUST decrement the TTL value by
1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming
value of 0 shall result in a TTL value of 63. The packet MUST NOT be value of 0 shall result in a TTL value of 63. The packet MUST NOT be
forwarded if TTL is, after decrement, 0. forwarded if TTL is, after decrement, 0.
All other flag fields, marked U, are unassigned and available for This TTL field is the primary loop prevention This TTL mechanism
future use, see Section 11.2.1. Unassigned bits MUST be set to zero represents a robust complement to the Service Index, as the TTL is
upon origination, and MUST be ignored and preserved unmodified by decrement by each SFF. The handling of incoming 0 TTL allows for
other NSH supporting elements. Elements which do not understand the better, although not perfect, interoperation with pre-standard
meaning of any of these bits MUST NOT modify their actions based on implementations that do not support this TTL field.
those unknown bits.
Length: The total length, in 4-byte words, of NSH including the Base Unassigned bits: All other flag fields, marked U, are unassigned and
Header, the Service Path Header, the Fixed Length Context Header or available for future use, see Section 11.2.1. Unassigned bits MUST
Variable Length Context Header(s). The length MUST be 0x6 for MD be set to zero upon origination, and MUST be ignored and preserved
unmodified by other NSH supporting elements. At reception, all
elements MUST NOT modify their actions based on these unknown bits.
Length: The total length, in 4-byte words, of the NSH including the
Base Header, the Service Path Header, the Fixed Length Context Header
or Variable Length Context Header(s). The length MUST be 0x6 for MD
Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
0x2. The length of the NSH header MUST be an integer multiple of 4 0x2. The length of the NSH header MUST be an integer multiple of 4
bytes, thus variable length metadata is always padded out to a bytes, thus variable length metadata is always padded out to a
multiple of 4 bytes. multiple of 4 bytes.
MD Type: Indicates the format of NSH beyond the mandatory Base Header Metadata (MD) Type: Indicates the format of the NSH beyond the
and the Service Path Header. MD Type defines the format of the mandatory Base Header and the Service Path Header. MD Type defines
metadata being carried. Please see the IANA Considerations the format of the metadata being carried. Please see the IANA
Section 11.2.3. Considerations Section 11.2.3.
This document specifies the following four MD Type values: This document specifies the following four MD Type values:
0x0 - This is a reserved value. Implementations SHOULD silently 0x0 - This is a reserved value. Implementations SHOULD silently
discard packets with MD Type 0x0. discard packets with MD Type 0x0.
0x1 - This indicates that the format of the header includes a fixed 0x1 - This indicates that the format of the header includes a fixed
length Context Header (see Figure 4 below). length Context Header (see Figure 5 below).
0x2 - This does not mandate any headers beyond the Base Header and 0x2 - This does not mandate any headers beyond the Base Header and
Service Path Header, but may contain optional variable length Context Service Path Header, but may contain optional variable length Context
Header(s). The semantics of the variable length Context Header(s) Header(s). The semantics of the variable length Context Header(s)
are not defined in this document. The format of the optional are not defined in this document. The format of the optional
variable length Context Headers is provided in Section 2.5.1. variable length Context Headers is provided in Section 2.5.1.
0xF - This value is reserved for experimentation and testing, as per 0xF - This value is reserved for experimentation and testing, as per
[RFC3692]. Implementations not explicitly configured to be part of [RFC3692]. Implementations not explicitly configured to be part of
an experiment SHOULD silently discard packets with MD Type 0xF. an experiment SHOULD silently discard packets with MD Type 0xF.
The format of the Base Header and the Service Path Header is The format of the Base Header and the Service Path Header is
invariant, and not affected by MD Type. invariant, and not affected by MD Type.
NSH MD Type 1 and MD Type 2 are described in detail in Sections 2.4 The NSH MD Type 1 and MD Type 2 are described in detail in Sections
and 2.5, respectively. NSH implementations MUST support MD types 0x1 2.4 and 2.5, respectively. NSH implementations MUST support MD types
and 0x2 (where the length is 0x2). NSH implementations SHOULD 0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD
support MD Type 0x2 with length greater than 0x2. There exists, support MD Type 0x2 with length greater than 0x2. There exists,
however, a middle ground, wherein a device will support MD Type 0x1 however, a middle ground, wherein a device will support MD Type 0x1
(as per the MUST) metadata, yet be deployed in a network with MD Type (as per the MUST) metadata, yet be deployed in a network with MD Type
0x2 metadata packets. In that case, the MD Type 0x1 node, MUST 0x2 metadata packets. In that case, the MD Type 0x1 node, MUST
utilize the base header length field to determine the original utilize the base header length field to determine the original
payload offset if it requires access to the original packet/frame. payload offset if it requires access to the original packet/frame.
This specification does not disallow the MD Type value from changing This specification does not disallow the MD Type value from changing
along an SFP; however, the specification of the necessary mechanism along an SFP; however, the specification of the necessary mechanism
to allow the MD Type to change along an SFP are outside the scope of to allow the MD Type to change along an SFP are outside the scope of
this document, and would need to be defined for that functionality to this document and would need to be defined for that functionality to
be available. Packets with MD Type values not supported by an be available. Packets with MD Type values not supported by an
implementation MUST be silently dropped. implementation MUST be silently dropped.
Next Protocol: indicates the protocol type of the encapsulated data. Next Protocol: indicates the protocol type of the encapsulated data.
NSH does not alter the inner payload, and the semantics on the inner The NSH does not alter the inner payload, and the semantics on the
protocol remain unchanged due to NSH service function chaining. inner protocol remain unchanged due to NSH service function chaining.
Please see the IANA Considerations section below, Section 11.2.5. Please see the IANA Considerations section below, Section 11.2.5.
This document defines the following Next Protocol values: This document defines the following Next Protocol values:
0x1: IPv4 0x1: IPv4
0x2: IPv6 0x2: IPv6
0x3: Ethernet 0x3: Ethernet
0x4: NSH 0x4: NSH
0x5: MPLS 0x5: MPLS
0xFE: Experiment 1 0xFE: Experiment 1
skipping to change at page 9, line 48 skipping to change at page 10, line 29
Packets with Next Protocol values not supported SHOULD be silently Packets with Next Protocol values not supported SHOULD be silently
dropped by default, although an implementation MAY provide a dropped by default, although an implementation MAY provide a
configuration parameter to forward them. Additionally, an configuration parameter to forward them. Additionally, an
implementation not explicitly configured for a specific experiment implementation not explicitly configured for a specific experiment
[RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE [RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE
and 0xFF. and 0xFF.
2.3. Service Path Header 2.3. Service Path Header
Figure 3 shows the format of the Service Path Header: Figure 4 shows the format of the Service Path Header:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index | | Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path Identifier (SPI): 24 bits Service Path Identifier (SPI): 24 bits
Service Index (SI): 8 bits Service Index (SI): 8 bits
Figure 3: NSH Service Path Header Figure 4: NSH Service Path Header
The meaning of these fields is as follows: The meaning of these fields is as follows:
Service Path Identifier (SPI): Identifies a service path. Service Path Identifier (SPI): Identifies a service path.
Participating nodes MUST use this identifier for Service Function Participating nodes MUST use this identifier for Service Function
Path selection. The initial classifier MUST set the appropriate SPI Path selection. The initial classifier MUST set the appropriate SPI
for a given classification result. for a given classification result.
Service Index (SI): Provides location within the SFP. The initial Service Index (SI): Provides location within the SFP. The initial
classifier for a given SFP SHOULD set the SI to 255, however the classifier for a given SFP SHOULD set the SI to 255, however the
skipping to change at page 10, line 39 skipping to change at page 11, line 17
and the new decremented SI value MUST be used in the egress packet's and the new decremented SI value MUST be used in the egress packet's
NSH. The initial Classifier MUST send the packet to the first SFF in NSH. The initial Classifier MUST send the packet to the first SFF in
the identified SFP for forwarding along an SFP. If re-classification the identified SFP for forwarding along an SFP. If re-classification
occurs, and that re-classification results in a new SPI, the occurs, and that re-classification results in a new SPI, the
(re)classifier is, in effect, the initial classifier for the (re)classifier is, in effect, the initial classifier for the
resultant SPI. resultant SPI.
The SI is used in conjunction the with Service Path Identifier for The SI is used in conjunction the with Service Path Identifier for
Service Function Path Selection and for determining the next SFF/SF Service Function Path Selection and for determining the next SFF/SF
in the path. The SI is also valuable when troubleshooting or in the path. The SI is also valuable when troubleshooting or
reporting service paths. Additionally, while the TTL field is the reporting service paths. While the TTL provides the primary SFF
main mechanism for service plane loop detection, the SI can also be based loop prevention for this mechanism, SI decrement by SF serves
used for detecting service plane loops. as a limited loop prevention mechanism. NSH packets, as described
above, are discarded when an SFF decrements the TTL to 0. In
addition, an SFF which is not the terminal SFF for a Service Function
Path will discard any NSH packet with an SI of 0, as there will be no
valid next SF information.
2.4. NSH MD Type 1 2.4. NSH MD Type 1
When the Base Header specifies MD Type = 0x1, a Fixed Length Context When the Base Header specifies MD Type = 0x1, a Fixed Length Context
Header (16-bytes) MUST be present immediately following the Service Header (16-bytes) MUST be present immediately following the Service
Path Header, as per Figure 4. The value of a Fixed Length Context Path Header, as per Figure 5. The value of a Fixed Length Context
Header that carries no metadata MUST be set to zero. Header that carries no metadata MUST be set to zero.
0 1 2 3 0 1 2 3
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 | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index | | Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Fixed Length Context Header | | Fixed Length Context Header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSH MD Type=0x1 Figure 5: NSH MD Type=0x1
This specification does not make any assumptions about the content of This specification does not make any assumptions about the content of
the 16 byte Context Header that must be present when the MD Type the 16 byte Context Header that must be present when the MD Type
field is set to 1, and does not describe the structure or meaning of field is set to 1, and does not describe the structure or meaning of
the included metadata. the included metadata.
An SFC-aware SF MUST receive the data semantics first in order to An SFC-aware SF MUST receive the data semantics first in order to
process the data placed in the mandatory context field. The data process the data placed in the mandatory context field. The data
semantics include both the allocation schema and the meaning of the semantics include both the allocation schema and the meaning of the
included data. How an SFC-aware SF gets the data semantics is included data. How an SFC-aware SF gets the data semantics is
skipping to change at page 11, line 44 skipping to change at page 12, line 22
the event occurs (subject to thresholding). the event occurs (subject to thresholding).
[I-D.guichard-sfc-nsh-dc-allocation] and [I-D.guichard-sfc-nsh-dc-allocation] and
[I-D.napper-sfc-nsh-broadband-allocation] provide specific examples [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples
of how metadata can be allocated. of how metadata can be allocated.
2.5. NSH MD Type 2 2.5. NSH MD Type 2
When the base header specifies MD Type = 0x2, zero or more Variable When the base header specifies MD Type = 0x2, zero or more Variable
Length Context Headers MAY be added, immediately following the Length Context Headers MAY be added, immediately following the
Service Path Header (see Figure 5). Therefore, Length = 0x2, Service Path Header (see Figure 6). Therefore, Length = 0x2,
indicates that only the Base Header followed by the Service Path indicates that only the Base Header followed by the Service Path
Header are present. The optional Variable Length Context Headers Header are present. The optional Variable Length Context Headers
MUST be of an integer number of 4-bytes. The base header Length MUST be of an integer number of 4-bytes. The base header Length
field MUST be used to determine the offset to locate the original field MUST be used to determine the offset to locate the original
packet or frame for SFC nodes that require access to that packet or frame for SFC nodes that require access to that
information. information.
0 1 2 3 0 1 2 3
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 | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index | | Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Variable Length Context Headers (opt.) ~ ~ Variable Length Context Headers (opt.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NSH MD Type=0x2 Figure 6: NSH MD Type=0x2
2.5.1. Optional Variable Length Metadata 2.5.1. Optional Variable Length Metadata
The format of the optional variable length Context Headers, is as The format of the optional variable length Context Headers, is as
depicted in Figure 6. depicted in Figure 7.
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata | | Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variable Context Headers Figure 7: Variable Context Headers
Metadata Class (MD Class): Defines the scope of the 'Type' field to Metadata Class (MD Class): Defines the scope of the 'Type' field to
provide a hierarchical namespace. The IANA Considerations provide a hierarchical namespace. The IANA Considerations
Section 11.2.4 defines how the MD Class values can be allocated to Section 11.2.4 defines how the MD Class values can be allocated to
standards bodies, vendors, and others. standards bodies, vendors, and others.
Type: Indicates the explicit type of metadata being carried. The Type: Indicates the explicit type of metadata being carried. The
definition of the Type is the responsibility of the MD Class owner. definition of the Type is the responsibility of the MD Class owner.
Unassigned bit: One unassigned bit is available for future use. This Unassigned bit: One unassigned bit is available for future use. This
skipping to change at page 13, line 14 skipping to change at page 13, line 44
the remaining bytes up to the nearest 4-byte word boundary. The the remaining bytes up to the nearest 4-byte word boundary. The
Length may be 0 or greater. Length may be 0 or greater.
A value of 0 denotes a Context Header without a Variable Metadata A value of 0 denotes a Context Header without a Variable Metadata
field. field.
This specification does not make any assumption about Context Headers This specification does not make any assumption about Context Headers
that are mandatory-to-implement or those that are mandatory-to- that are mandatory-to-implement or those that are mandatory-to-
process. These considerations are deployment-specific. However, the process. These considerations are deployment-specific. However, the
control plane is entitled to instruct SFC-aware SFs with the data control plane is entitled to instruct SFC-aware SFs with the data
structure of context header together with its scoping (see structure of context header together with its scoping (see e.g.,
Section 3.3.3 of [I-D.ietf-sfc-control-plane]). Section 3.3.3 of [I-D.ietf-sfc-control-plane]).
Upon receipt of a packet that belongs to a given SFP, if a mandatory- Upon receipt of a packet that belongs to a given SFP, if a mandatory-
to-process context header is missing in that packet, the SFC-aware SF to-process context header is missing in that packet, the SFC-aware SF
MUST NOT process the packet and MUST log at least once per the SPI MUST NOT process the packet and MUST log an error at least once per
for which the mandatory metadata is missing. the SPI for which the mandatory metadata is missing.
If multiple mandatory-to-process context headers are required for a If multiple mandatory-to-process context headers are required for a
given SFP, the control plane MAY instruct the SFC-aware SF with the given SFP, the control plane MAY instruct the SFC-aware SF with the
order to consume these Context Headers. If no instructions are order to consume these Context Headers. If no instructions are
provided, the SFC-aware SF MUST process these Context Headers in the provided and the SFC-aware SF will make use of or modify the specific
order they appear in an NSH packet. context header, then the SFC-aware SF MUST process these Context
Headers in the order they appear in an NSH packet.
If multiple instances of the same metadata are included in an NSH If multiple instances of the same metadata are included in an NSH
packet, but the definition of that context header does not allow for packet, but the definition of that context header does not allow for
it, the SFC-aware SF MUST process the first instance and ignore it, the SFC-aware SF MUST process the first instance and ignore
subsequent instances. subsequent instances.
3. NSH Actions 3. NSH Actions
NSH-aware nodes are the only nodes that may alter the content of NSH NSH-aware nodes, which include service classifiers, SFFs, SFs and SFC
headers. NSH-aware nodes include: service classifiers, SFFs, SFs and proxies, may alter the contents of the NSH headers. These nodes have
SFC proxies. These nodes have several possible NSH-related actions: several possible NSH-related actions:
1. Insert or remove NSH: These actions can occur respectively at the 1. Insert or remove the NSH: These actions can occur respectively at
start and end of a service path. Packets are classified, and if the start and end of a service path. Packets are classified, and
determined to require servicing, NSH will be imposed. A service if determined to require servicing, an NSH will be imposed. A
classifier MUST insert NSH at the start of an SFP. An imposed service classifier MUST insert an NSH at the start of an SFP. An
NSH MUST contain both a valid Base Header and Service Path imposed NSH MUST contain both a valid Base Header and Service
Header. At the end of a service function path, an SFF, MUST be Path Header. At the end of a service function path, an SFF MUST
the last node operating on the service header and MUST remove NSH remove the NSH before forwarding or delivering the un-
before forwarding or delivering the un-encapsulated packet. encapsulated packet. It is therefore the last node operating on
the service header.
Multiple logical classifiers may exist within a given service Multiple logical classifiers may exist within a given service
path. Non-initial classifiers may re-classify data and that re- path. Non-initial classifiers may re-classify data and that re-
classification MAY result in the selection of a different Service classification MAY result in the selection of a different Service
Function Path. When the logical classifier performs re- Function Path. When the logical classifier performs re-
classification that results in a change of service path, it MUST classification that results in a change of service path, it MUST
remove the existing NSH and MUST impose a new NSH with the Base replace the existing NSH with a new NSH with the Base Header and
Header and Service Path Header reflecting the new service path Service Path Header reflecting the new service path information
information and MUST set the initial SI. Metadata MAY be and MUST set the initial SI. Metadata MAY be preserved in the
preserved in the new NSH. new NSH.
2. Select service path: The Service Path Header provides service 2. Select service path: The Service Path Header provides service
path information and is used by SFFs to determine correct service path information and is used by SFFs to determine correct service
path selection. SFFs MUST use the Service Path Header for path selection. SFFs MUST use the Service Path Header for
selecting the next SF or SFF in the service path. selecting the next SF or SFF in the service path.
3. Update NSH: SFs MUST decrement the service index by one. If an 3. Update the NSH: SFs MUST decrement the service index by one. If
SFF receives a packet with an SPI and SI that do not correspond an SFF receives a packet with an SPI and SI that do not
to a valid next hop in a valid Service Function Path, that packet correspond to a valid next hop in a valid Service Function Path,
MUST be dropped by the SFF. that packet MUST be dropped by the SFF.
Classifiers MAY update Context Headers if new/updated context is Classifiers MAY update Context Headers if new/updated context is
available. available.
If an SFC proxy is in use (acting on behalf of a NSH unaware If an SFC proxy is in use (acting on behalf of an NSH-unaware
service function for NSH actions), then the proxy MUST update service function for NSH actions), then the proxy MUST update
Service Index and MAY update contexts. When an SFC proxy Service Index and MAY update contexts. When an SFC proxy
receives an NSH-encapsulated packet, it MUST remove NSH before receives an NSH-encapsulated packet, it MUST remove the NSH
forwarding it to an NSH unaware SF. When the SFC Proxy receives before forwarding it to an NSH-unaware SF. When the SFC Proxy
a packet back from an NSH unaware SF, it MUST re-encapsulate it receives a packet back from an NSH-unaware SF, it MUST re-
with the correct NSH, and MUST decrement the Service Index by encapsulate it with the correct NSH, and MUST decrement the
one. Service Index by one.
4. Service policy selection: Service Functions derive policy (i.e., 4. Service policy selection: Service Functions derive policy (i.e.,
service actions such as permit or deny) selection and enforcement service actions such as permit or deny) selection and enforcement
from NSH. Metadata shared in NSH can provide a range of service- from the NSH. Metadata shared in the NSH can provide a range of
relevant information such as traffic classification. service-relevant information such as traffic classification.
Figure 7 maps each of the four actions above to the components in the Figure 8 maps each of the four actions above to the components in the
SFC architecture that can perform it. SFC architecture that can perform it.
+----------------+---------------+-------+----------------+---------+ +-----------+-----------------------+-------+---------------+-------+
| | Insert |Forward| Update |Service | | | Insert, remove, or |Forward| Update |Service|
| | or remove NSH |NSH | NSH |policy | | | replace the NSH |the NSH| the NSH |policy |
| | |Packets| |selection| | | |Packets| |sel. |
| Component +-------+-------+ +----------------+ | |Component +-------+-------+-------+ +-------+-------+ |
| | | | | Dec. |Update | | | | | | | |Dec. |Update | |
| |Insert |Remove | |Service |Context| | | |Insert |Remove |Replace| |Service|Context| |
| | | | | Index |Header | | | | | | | |Index |Header | |
+----------------+-------+-------+-------+--------+-------+---------+ +-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | + | | | + | | | | + | | + | | | + | |
|Classifier | | | | | | | |Classifier | | | | | | | |
+----------------+-------+-------+-------+--------+-------+---------+ +-----------+-------+-------+-------+-------+-------+-------+-------+
|Service Function| | + | + | | | | |Service | | + | | + | | | |
|Forwarder(SFF) | | | | | | | |Function | | | | | | | |
+----------------+-------+-------+-------+--------+-------+---------+ |Forwarder | | | | | | | |
|Service | | | | + | + | + | |(SFF) | | | | | | | |
|Function (SF) | | | | | | | +-----------+-------+-------+-------+-------+-------+-------+-------+
+----------------+-------+-------+-------+--------+-------+---------+ |Service | | | | | + | + | + |
|SFC Proxy | + | + | | + | + | | |Function | | | | | | | |
+----------------+-------+-------+-------+--------+-------+---------+ |(SF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | + | | | + | + | |
|SFC Proxy | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
Figure 7: NSH Action and Role Mapping Figure 8: NSH Action and Role Mapping
4. NSH Transport Encapsulation 4. NSH Transport Encapsulation
Once NSH is added to a packet, an outer encapsulation is used to Once the NSH is added to a packet, an outer encapsulation is used to
forward the original packet and the associated metadata to the start forward the original packet and the associated metadata to the start
of a service chain. The encapsulation serves two purposes: of a service chain. The encapsulation serves two purposes:
1. Creates a topologically independent services plane. Packets are 1. Creates a topologically independent services plane. Packets are
forwarded to the required services without changing the forwarded to the required services without changing the
underlying network topology. underlying network topology.
2. Transit network nodes simply forward the encapsulated packets 2. Transit network nodes simply forward the encapsulated packets
without modification. without modification.
The service header is independent of the encapsulation used and is The service header is independent of the encapsulation used and is
encapsulated in existing transports. The presence of NSH is encapsulated in existing transports. The presence of an NSH is
indicated via protocol type or other indicator in the outer indicated via protocol type or other indicator in the outer
encapsulation. encapsulation.
5. Fragmentation Considerations 5. Fragmentation Considerations
NSH and the associated transport header are "added" to the The NSH and the associated transport header are "added" to the
encapsulated packet/frame. This additional information increases the encapsulated packet/frame. This additional information increases the
size of the packet. size of the packet.
As discussed in [I-D.ietf-rtgwg-dt-encap], within an administrative Within a managed administrative domain, an operator can ensure that
domain, an operator can ensure that the underlay MTU is sufficient to the underlay MTU is sufficient to carry SFC traffic without requiring
carry SFC traffic without requiring fragmentation. fragmentation. Given that the intended scope of the NSH is within a
single provider's operational domain, that approach is sufficient.
However, there will be cases where the underlay MTU is not large However, although explicitly outside the scope of this specification,
enough to carry the NSH traffic. Since NSH does not provide there might be cases where the underlay MTU is not large enough to
fragmentation support at the service plane, the transport/overlay carry the NSH traffic. Since the NSH does not provide fragmentation
layer MUST provide the requisite fragmentation handling. Section 9 support at the service plane, the overlay layer ought to provide the
of [I-D.ietf-rtgwg-dt-encap] provides guidance for those scenarios. requisite fragmentation handling. For instance, Section 9 of
[I-D.ietf-rtgwg-dt-encap] provides exemplary approaches and guidance
for those scenarios.
For example, when NSH is encapsulated in IP, IP-level fragmentation For example, when the NSH is encapsulated in IP, IP-level
coupled with Path MTU Discovery (PMTUD) is used. When, on the other fragmentation coupled with Path MTU Discovery (PMTUD) is used. When,
hand, the underlay does not support fragmentation procedures, an on the other hand, the underlay does not support fragmentation
error message SHOULD be logged when dropping a packet too big. procedures, an error message SHOULD be logged when dropping a packet
Lastly, NSH-specific fragmentation and reassembly methods may be too big. Lastly, NSH-specific fragmentation and reassembly methods
defined as well, but these methods are outside the scope of this may be defined as well, but these methods are outside the scope of
document. this document, and subject for future work.
6. Service Path Forwarding with NSH 6. Service Path Forwarding with NSH
6.1. SFFs and Overlay Selection 6.1. SFFs and Overlay Selection
As described above, NSH contains a Service Path Identifier (SPI) and As described above, the NSH contains a Service Path Identifier (SPI)
a Service Index (SI). The SPI is, as per its name, an identifier. and a Service Index (SI). The SPI is, as per its name, an
The SPI alone cannot be used to forward packets along a service path. identifier. The SPI alone cannot be used to forward packets along a
Rather the SPI provides a level of indirection between the service service path. Rather the SPI provides a level of indirection between
path/topology and the network transport. Furthermore, there is no the service path/topology and the network transport. Furthermore,
requirement, or expectation of an SPI being bound to a pre-determined there is no requirement, or expectation of an SPI being bound to a
or static network path. pre-determined or static network path.
The Service Index provides an indication of location within a service The Service Index provides an indication of location within a service
path. The combination of SPI and SI provides the identification of a path. The combination of SPI and SI provides the identification of a
logical SF and its order within the service plane, and is used to logical SF and its order within the service plane, and is used to
select the appropriate network locator(s) for overlay forwarding. select the appropriate network locator(s) for overlay forwarding.
The logical SF may be a single SF, or a set of eligible SFs that are The logical SF may be a single SF, or a set of eligible SFs that are
equivalent. In the latter case, the SFF provides load distribution equivalent. In the latter case, the SFF provides load distribution
amongst the collection of SFs as needed. amongst the collection of SFs as needed.
SI serves as a mechanism for detecting invalid service function SI serves as a mechanism for detecting invalid service function
skipping to change at page 17, line 6 skipping to change at page 18, line 17
is incorrect and the packet must be discarded. is incorrect and the packet must be discarded.
This indirection -- SPI to overlay -- creates a true service plane. This indirection -- SPI to overlay -- creates a true service plane.
That is, the SFF/SF topology is constructed without impacting the That is, the SFF/SF topology is constructed without impacting the
network topology but more importantly, service plane only network topology but more importantly, service plane only
participants (i.e., most SFs) need not be part of the network overlay participants (i.e., most SFs) need not be part of the network overlay
topology and its associated infrastructure (e.g., control plane, topology and its associated infrastructure (e.g., control plane,
routing tables, etc.) SFs need to be able to return a packet to an routing tables, etc.) SFs need to be able to return a packet to an
appropriate SFF (i.e., has the requisite NSH information) when appropriate SFF (i.e., has the requisite NSH information) when
service processing is complete. This can be via the overlay or service processing is complete. This can be via the overlay or
underlay and in some case require additional configuration on the SF. underlay and in some cases require additional configuration on the
As mentioned above, an existing overlay topology may be used provided SF. As mentioned above, an existing overlay topology may be used
it offers the requisite connectivity. provided it offers the requisite connectivity.
The mapping of SPI to transport occurs on an SFF (as discussed above, The mapping of SPI to transport occurs on an SFF (as discussed above,
the first SFF in the path gets an NSH encapsulated packet from the the first SFF in the path gets an NSH encapsulated packet from the
Classifier). The SFF consults the SPI/ID values to determine the Classifier). The SFF consults the SPI/ID values to determine the
appropriate overlay transport protocol (several may be used within a appropriate overlay transport protocol (several may be used within a
given network) and next hop for the requisite SF. Table 1 below given network) and next hop for the requisite SF. Table 1 below
depicts an example of a single next-hop SPI/SI to network overlay depicts an example of a single next-hop SPI/SI to network overlay
network locator mapping. network locator mapping.
+------+------+---------------------+-------------------+ +------+------+---------------------+-------------------+
skipping to change at page 19, line 24 skipping to change at page 20, line 24
| | | | | | | | | |
| 30 | 7 | 192.0.2.10 | 10 | | 30 | 7 | 192.0.2.10 | 10 |
| | | | | | | | | |
| | | 198.51.100.1 | 5 | | | | 198.51.100.1 | 5 |
+------+-----+--------------+---------+ +------+-----+--------------+---------+
(encapsulation type omitted for formatting) (encapsulation type omitted for formatting)
Table 4: NSH Weighted Service Path Table 4: NSH Weighted Service Path
6.2. Mapping NSH to Network Transport 6.2. Mapping the NSH to Network Transport
As described above, the mapping of SPI to network topology may result As described above, the mapping of SPI to network topology may result
in a single path, or it might result in a more complex topology. in a single path, or it might result in a more complex topology.
Furthermore, the SPI to overlay mapping occurs at each SFF Furthermore, the SPI to overlay mapping occurs at each SFF
independently. Any combination of topology selection is possible. independently. Any combination of topology selection is possible.
Please note, there is no requirement to create a new overlay topology Please note, there is no requirement to create a new overlay topology
if a suitable one already exists. NSH packets can use any (new or if a suitable one already exists. NSH packets can use any (new or
existing) overlay provided the requisite connectivity requirements existing) overlay provided the requisite connectivity requirements
are satisfied. are satisfied.
skipping to change at page 20, line 33 skipping to change at page 21, line 33
6.4. Service Graphs 6.4. Service Graphs
While a given realized service function path is a specific sequence While a given realized service function path is a specific sequence
of service functions, the service as seen by a user can actually be a of service functions, the service as seen by a user can actually be a
collection of service function paths, with the interconnection collection of service function paths, with the interconnection
provided by classifiers (in-service path, non-initial provided by classifiers (in-service path, non-initial
reclassification). These internal reclassifiers examine the packet reclassification). These internal reclassifiers examine the packet
at relevant points in the network, and, if needed, SPI and SI are at relevant points in the network, and, if needed, SPI and SI are
updated (whether this update is a re-write, or the imposition of a updated (whether this update is a re-write, or the imposition of a
new NSH with new values is implementation specific) to reflect the new NSH with new values is implementation specific) to reflect the
"result" of the classification. These classifiers may also of course "result" of the classification. These classifiers may, of course,
modify the metadata associated with the packet. also modify the metadata associated with the packet.
[RFC7665], Section 2.1 describes Service Graphs in detail. [RFC7665], Section 2.1 describes Service Graphs in detail.
7. Policy Enforcement with NSH 7. Policy Enforcement with NSH
7.1. NSH Metadata and Policy Enforcement 7.1. NSH Metadata and Policy Enforcement
As described in Section 2, NSH provides the ability to carry metadata As described in Section 2, NSH provides the ability to carry metadata
along a service path. This metadata may be derived from several along a service path. This metadata may be derived from several
sources, common examples include: sources. Common examples include:
Network nodes/devices: Information provided by network nodes can Network nodes/devices: Information provided by network nodes can
indicate network-centric information (such as VRF or tenant) that indicate network-centric information (such as VRF or tenant) that
may be used by service functions, or conveyed to another network may be used by service functions or conveyed to another network
node post service path egress. node post service path egress.
External (to the network) systems: External systems, such as External (to the network) systems: External systems, such as
orchestration systems, often contain information that is valuable orchestration systems, often contain information that is valuable
for service function policy decisions. In most cases, this for service function policy decisions. In most cases, this
information cannot be deduced by network nodes. For example, a information cannot be deduced by network nodes. For example, a
cloud orchestration platform placing workloads "knows" what cloud orchestration platform placing workloads "knows" what
application is being instantiated and can communicate this application is being instantiated and can communicate this
information to all NSH nodes via metadata carried in the context information to all NSH nodes via metadata carried in the context
header(s). header(s).
Service Functions: A classifier co-resident with Service Functions Service Functions: A classifier co-resident with Service Functions
often perform very detailed and valuable classification. often perform very detailed and valuable classification.
Regardless of the source, metadata reflects the "result" of Regardless of the source, metadata reflects the "result" of
classification. The granularity of classification may vary. For classification. The granularity of classification may vary. For
example, a network switch, acting as a classifier, might only be able example, a network switch, acting as a classifier, might only be able
to classify based on a 5-tuple, whereas, a service function may be to classify based on a 5-tuple, while a service function may be able
able to inspect application information. Regardless of granularity, to inspect application information. Regardless of granularity, the
the classification information can be represented in NSH. classification information can be represented in the NSH.
Once the data is added to NSH, it is carried along the service path, Once the data is added to the NSH, it is carried along the service
NSH-aware SFs receive the metadata, and can use that metadata for path, NSH-aware SFs receive the metadata, and can use that metadata
local decisions and policy enforcement. Figure 8 and Figure 9 for local decisions and policy enforcement. Figure 9 and Figure 10
highlight the relationship between metadata and policy: highlight the relationship between metadata and policy:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| SFF )------->( SFF |------->| SFF | | SFF )------->( SFF |------->| SFF |
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+
^ | | ^ | |
,-|-. ,-|-. ,-|-. ,-|-. ,-|-. ,-|-.
/ \ / \ / \ / \ / \ / \
( Class ) ( SF1 ) ( SF2 ) ( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ / \ ify / \ / \ /
`---' `---' `---' `---' `---' `---'
5-tuple: Permit Inspect 5-tuple: Permit Inspect
Tenant A Tenant A AppY Tenant A Tenant A AppY
AppY AppY
Figure 8: Metadata and Policy Figure 9: Metadata and Policy
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF | | SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
^ | | ^ | |
,-+-. ,-+-. ,-+-. ,-+-. ,-+-. ,-+-.
/ \ / \ / \ / \ / \ / \
( Class ) ( SF1 ) ( SF2 ) ( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ / \ ify / \ / \ /
`-+-' `---' `---' `-+-' `---' `---'
| Permit Deny AppZ | Permit Deny AppZ
+---+---+ employees +---+---+ employees
| | | |
+-------+ +-------+
External External
system: system:
Employee Employee
AppZ AppZ
Figure 9: External Metadata and Policy Figure 10: External Metadata and Policy
In both of the examples above, the service functions perform policy In both of the examples above, the service functions perform policy
decisions based on the result of the initial classification: the SFs decisions based on the result of the initial classification: the SFs
did not need to perform re-classification, rather they rely on a did not need to perform re-classification; instead, they rely on a
antecedent classification for local policy enforcement. antecedent classification for local policy enforcement.
Depending on the information carried in the metadata, data privacy Depending on the information carried in the metadata, data privacy
considerations may need to be considered. For example, if the considerations may need to be considered. For example, if the
metadata conveys tenant information, that information may need to be metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only) . NSH intended recipients (which may include intended SFs only). The NSH
itself does not provide privacy functions, rather it relies on the itself does not provide privacy functions, rather it relies on the
transport/overlay layer. An operator can select the appropriate transport/overlay layer. An operator can select the appropriate
transport to ensure confidentially (and other security) transport to ensure confidentiality (and other security)
considerations are met. Metadata privacy and security considerations considerations are met. Metadata privacy and security considerations
are a matter for the documents that define metadata format. are a matter for the documents that define metadata format.
7.2. Updating/Augmenting Metadata 7.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically performed during initial Post-initial metadata imposition (typically performed during initial
service path determination), the metadata may be augmented or service path determination), the metadata may be augmented or
updated: updated:
1. Metadata Augmentation: Information may be added to NSH's existing 1. Metadata Augmentation: Information may be added to the NSH's
metadata, as depicted in Figure 10. For example, if the initial existing metadata, as depicted in Figure 11. For example, if the
classification returns the tenant information, a secondary initial classification returns the tenant information, a
classification (perhaps co-resident with DPI or SLB) may augment secondary classification (perhaps co-resident with DPI or SLB)
the tenant classification with application information, and may augment the tenant classification with application
impose that new information in NSH metadata. The tenant information, and impose that new information in NSH metadata.
classification is still valid and present, but additional
information has been added to it. The tenant classification is still valid and present, but
additional information has been added to it.
2. Metadata Update: Subsequent classifiers may update the initial 2. Metadata Update: Subsequent classifiers may update the initial
classification if it is determined to be incorrect or not classification if it is determined to be incorrect or not
descriptive enough. For example, the initial classifier adds descriptive enough. For example, the initial classifier adds
metadata that describes the traffic as "Internet" but a security metadata that describes the traffic as "Internet" but a security
service function determines that the traffic is really "attack". service function determines that the traffic is really "attack".
Figure 11 illustrates an example of updating metadata. Figure 12 illustrates an example of updating metadata.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF | | SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
^ | | ^ | |
,---. ,---. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \ / \
( Class ) ( SF1 ) ( SF2 ) ( Class ) ( SF1 ) ( SF2 )
\ / \ / \ / \ / \ / \ /
`-+-' `---' `---' `-+-' `---' `---'
| Inspect Deny | Inspect Deny
+---+---+ employees employee+ +---+---+ employees employee+
| | Class=AppZ appZ | | Class=AppZ appZ
+-------+ +-------+
External External
system: system:
Employee Employee
Figure 10: Metadata Augmentation Figure 11: Metadata Augmentation
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF | | SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
^ | | ^ | |
,---. ,---. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \ / \
( Class ) ( SF1 ) ( SF2 ) ( Class ) ( SF1 ) ( SF2 )
\ / \ / \ / \ / \ / \ /
`---' `---' `---' `---' `---' `---'
5-tuple: Inspect Deny 5-tuple: Inspect Deny
Tenant A Tenant A attack Tenant A Tenant A attack
--> attack --> attack
Figure 11: Metadata Update Figure 12: Metadata Update
7.3. Service Path Identifier and Metadata 7.3. Service Path Identifier and Metadata
Metadata information may influence the service path selection since Metadata information may influence the service path selection since
the Service Path Identifier values can represent the result of the Service Path Identifier values can represent the result of
classification. A given SPI can be defined based on classification classification. A given SPI can be defined based on classification
results (including metadata classification). The imposition of the results (including metadata classification). The imposition of the
SPI and SI results in the packet being placed on the newly specified SPI and SI results in the packet being placed on the newly specified
SFP at the position indicated by the imposed SPI and SI. SFP at the position indicated by the imposed SPI and SI.
This relationship provides the ability to create a dynamic service This relationship provides the ability to create a dynamic service
plane based on complex classification without requiring each node to plane based on complex classification without requiring each node to
be capable of such classification, or requiring a coupling to the be capable of such classification, or requiring a coupling to the
network topology. This yields service graph functionality as network topology. This yields service graph functionality as
described in Section 6.4. Figure 12 illustrates an example of this described in Section 6.4. Figure 13 illustrates an example of this
behavior. behavior.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |------+---> | SFF | | SFF |---------> | SFF |------+---> | SFF |
+--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ | +--+--+
| | | | | | | |
,---. ,---. | ,---. ,---. ,---. | ,---.
/ \ / SF1 \ | / \ / \ / SF1 \ | / \
( SCL ) ( + ) | ( SF2 ) ( SCL ) ( + ) | ( SF2 )
\ / \SCL2 / | \ / \ / \SCL2 / | \ /
skipping to change at page 24, line 42 skipping to change at page 25, line 42
--> DoS | --> DoS |
V V
,-+-. ,-+-.
/ \ / \
( SF10 ) ( SF10 )
\ / \ /
`---' `---'
DoS DoS
"Scrubber" "Scrubber"
Figure 12: Path ID and Metadata Figure 13: Path ID and Metadata
Specific algorithms for mapping metadata to an SPI are outside the Specific algorithms for mapping metadata to an SPI are outside the
scope of this document. scope of this document.
8. Security Considerations 8. Security Considerations
As with many other protocols, the NSH encapsulation could be spoofed As with many other protocols, the NSH encapsulation could be spoofed
or otherwise modified in transit. However, the deployment scope (as or otherwise modified in transit. However, the deployment scope (as
defined in [RFC7665]) of the NSH encapsulation is limited to a single defined in [RFC7665]) of the NSH encapsulation is limited to a single
network administrative domain as a controlled environment, with network administrative domain as a controlled environment, with
trusted devices (e.g., a data center) thus mitigating the risk of trusted devices (e.g., a data center) hence mitigating the risk of
unauthorized manipulation of the encapsulation headers or metadata. unauthorized manipulation of the encapsulation headers or metadata.
NSH is always encapsulated in a transport protocol (as detailed in NSH is always encapsulated in a transport protocol (as detailed in
Section 4 of this specification) and therefore, when required, Section 4 of this specification); and, therefore, when required,
existing security protocols that provide authenticity (e.g., existing security protocols that provide authenticity (e.g.,
[RFC6071]) can be used. Similarly, if confidentiality is required, [RFC6071]) can be used. Similarly, if confidentiality is required,
existing encryption protocols can be used in conjunction with the NSH existing encryption protocols can be used in conjunction with the NSH
encapsulation. encapsulation.
Further, existing best practices, such as [BCP38] SHOULD be deployed Further, existing best practices, such as [BCP38] SHOULD be deployed
at the network layer to ensure that traffic entering the service path at the network layer to ensure that traffic entering the service path
is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional
transport encapsulation considerations. transport encapsulation considerations.
Even though much of the metadata carried within the NSH encapsulation Even though much of the metadata carried within the NSH encapsulation
is derived from the packet contents, and thus is not privacy or is derived from the packet contents, and thus is not privacy or
security sensitive, NSH metadata authenticity and confidentiality security sensitive, The NSH metadata authenticity and confidentiality
must be considered as well. In order to protect the metadata, an must be considered as well. In order to protect the metadata, an
operator can leverage the aforementioned mechanisms provided by the operator can utilize the aforementioned mechanisms provided by the
transport layer including authenticity and/or confidentiality. An transport layer including authenticity and/or confidentiality. An
operator MUST carefully select the transport/underlay services to operator MUST carefully select the transport/underlay services to
ensure end-to-end security services, when those are sought. For ensure end-to-end security services, when those are desired. For
example, if [RFC6071] is used, the operator MUST ensure it can be example, if [RFC6071] is used, the operator MUST ensure it can be
supported by the transport/underlay of all relevant network segments supported by the transport/underlay of all relevant network segments
as well as SFFs and SFs in the service path. Further, as described as well as SFFs, SFs and SFC proxies in the service path. Further,
under the "SFC Encapsulation" area of the Security Considerations of as described under the "SFC Encapsulation" area of the Security
[RFC7665], operators can and should use indirect identification for Considerations of [RFC7665], operators can and should use indirect
metadata deemed to be sensitive (such as personally identifying identification for metadata deemed to be sensitive (such as
information), thus significantly mitigating the risk of privacy personally identifying information) significantly mitigating the risk
violation. In particular, subscriber identifying information should of privacy violation. In particular, subscriber identifying
be handled carefully, and in general should be obfuscated. This is information should be handled carefully, and in general should be
covered in the Security Considerations of [RFC7665]. For those obfuscated. This is covered in the Security Considerations of
situations where obfuscation is either inapplicable or judged to be [RFC7665]. For those situations where obfuscation is either
insufficient, one can also encrypt the metadata. An approach to an inapplicable or judged to be insufficient, an operator can also
optional capability to do this was explored encrypt the metadata. An approach to an optional capability to do
[I-D.reddy-sfc-nsh-encrypt]. Means to prevent leaking privacy- this was explored in [I-D.reddy-sfc-nsh-encrypt]. Means to prevent
related information outside an administrative domain are natively leaking privacy-related information outside an administrative domain
supported by NSH given that the last SFF of a servicepath will are natively supported by the NSH given that the last SFF of a
systematically remove the NSH encapsulation before forwarding a service path will systematically remove the NSH encapsulation before
packet exiting the service path. forwarding a packet exiting the service path.
Lastly, SF security, although out of scope of this document, should Lastly, SF security, although out of scope of this document, should
be considered, particularly if an SF needs to access, authenticate, be considered, particularly if an SF needs to access, authenticate,
or update the NSH encapsulation or metadata. However, again the or update the NSH encapsulation or metadata. However, again, the
placement of SFs is assumed to be bounded within the scope of a placement of SFs is assumed to be bounded within the scope of a
single administrative domain and therefore under direct control of single administrative domain and therefore under direct control of
the operator. the operator.
9. Contributors 9. Contributors
This WG document originated as draft-quinn-sfc-nsh and had the This WG document originated as draft-quinn-sfc-nsh; the following are
following co-authors and contributors. The editors of this document its co-authors and contributors along with their respective
would like to thank and recognize them and their contributions. affiliations at the time of WG adoption. The editors of this
These co-authors and contributors provided invaluable concepts and document would like to thank and recognize them and their
content for this document's creation. contributions. These co-authors and contributors provided invaluable
concepts and content for this document's creation.
Surendra Kumar
Cisco Systems
smkumar@cisco.com
Michael Smith o Jim Guichard, Cisco Systems, Inc.
Cisco Systems
michsmit@cisco.com
Jim Guichard o Surendra Kumar, Cisco Systems, Inc.
Huawei
james.n.guichard@huawei.com
Rex Fernando o Michael Smith, Cisco Systems, Inc.
Cisco Systems
Email: rex@cisco.com
Navindra Yadav o Wim Henderickx, Alcatel-Lucent
Cisco Systems
Email: nyadav@cisco.com
Wim Henderickx o Tom Nadeau, Brocade
Alcatel-Lucent
wim.henderickx@alcatel-lucent.com
Andrew Dolganow o Puneet Agarwal
Alcaltel-Lucent
Email: andrew.dolganow@alcatel-lucent.com
Praveen Muley o Rajeev Manur, Broadcom
Alcaltel-Lucent
Email: praveen.muley@alcatel-lucent.com
Tom Nadeau o Abhishek Chauhan, Citrix
Brocade
tnadeau@lucidvision.com
Puneet Agarwal o Joel Halpern, Ericsson
puneet@acm.org
Rajeev Manur o Sumandra Majee, F5
Broadcom
rmanur@broadcom.com
Abhishek Chauhan o David Melman, Marvell
Citrix
Abhishek.Chauhan@citrix.com
Joel Halpern o Pankaj Garg, Microsoft
Ericsson
joel.halpern@ericsson.com
Sumandra Majee o Brad McConnell, Rackspace
F5
S.Majee@f5.com
David Melman o Chris Wright, Red Hat, Inc.
Marvell
davidme@marvell.com
Pankaj Garg o Kevin Glavin, Riverbed
Microsoft
pankajg@microsoft.com
Brad McConnell o Hong (Cathy) Zhang, Huawei US R&D
Rackspace
bmcconne@rackspace.com
Chris Wright o Louis Fourie, Huawei US R&D
Red Hat Inc.
chrisw@redhat.com
Kevin Glavin o Ron Parker, Affirmed Networks
Riverbed
kevin.glavin@riverbed.com
Hong (Cathy) Zhang o Myo Zarny, Goldman Sachs
Huawei US R&D
cathy.h.zhang@huawei.com
Louis Fourie o Andrew Dolganow, Alcatel-Lucent
Huawei US R&D o Rex Fernando, Cisco Systems, Inc.
louis.fourie@huawei.com
Ron Parker o Praveen Muley, Alcatel-Lucent
Affirmed Networks
ron_parker@affirmednetworks.com
Myo Zarny o Navindra Yadav, Cisco Systems, Inc.
Goldman Sachs
myo.zarny@gs.com
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli,
Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal
Mizrahi and Ken Gray for their detailed review, comments and Mizrahi and Ken Gray for their detailed review, comments and
contributions. contributions.
A special thank you goes to David Ward and Tom Edsall for their A special thank you goes to David Ward and Tom Edsall for their
guidance and feedback. guidance and feedback.
skipping to change at page 29, line 20 skipping to change at page 29, line 20
Bit 2 - O (OAM) bit Bit 2 - O (OAM) bit
Bit 3 - Unassigned Bit 3 - Unassigned
Bits 16-19 - Unassigned Bits 16-19 - Unassigned
11.2.2. NSH Version 11.2.2. NSH Version
IANA is requested to setup a registry of "NSH Version". New values IANA is requested to setup a registry of "NSH Version". New values
are assigned via Standards Action [RFC8126]. are assigned via Standards Action [RFC8126].
Version 00b: This protocol version. This document. Version 00b: Protocol as defined by this document.
Version 01b: Reserved. This document. Version 01b: Reserved. This document.
Version 10b: Unassigned. Version 10b: Unassigned.
Version 11b: Unassigned. Version 11b: Unassigned.
11.2.3. MD Type Registry 11.2.3. MD Type Registry
IANA is requested to set up a registry of "MD Types". These are IANA is requested to set up a registry of "MD Types". These are
4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in
this document, see Table 5. Registry entries are assigned by using this document, see Table 5. Registry entries are assigned by using
the "IETF Review" policy defined in RFC 8126 [RFC8126]. the "IETF Review" policy defined in RFC 8126 [RFC8126].
skipping to change at page 31, line 47 skipping to change at page 31, line 47
The type values are assigned via Standards Action [RFC8126]. The type values are assigned via Standards Action [RFC8126].
No initial values are assigned at the creation of the registry. No initial values are assigned at the creation of the registry.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7665>. editor.org/info/rfc7665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 12.2. Informative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[I-D.guichard-sfc-nsh-dc-allocation] [I-D.guichard-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal, Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
P., Glavin, K., and Y. Laribi, "Network Service Header P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network
(NSH) Context Header Allocation (Data Center)", draft- Service Header (NSH) MD Type 1: Context Header Allocation
guichard-sfc-nsh-dc-allocation-05 (work in progress), (Data Center)", draft-guichard-sfc-nsh-dc-allocation-07
August 2016. (work in progress), August 2017.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work
in progress), April 2017. in progress), April 2017.
[I-D.ietf-rtgwg-dt-encap] [I-D.ietf-rtgwg-dt-encap]
Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
Considerations", draft-ietf-rtgwg-dt-encap-02 (work in Considerations", draft-ietf-rtgwg-dt-encap-02 (work in
skipping to change at page 33, line 18 skipping to change at page 33, line 18
draft-napper-sfc-nsh-broadband-allocation-03 (work in draft-napper-sfc-nsh-broadband-allocation-03 (work in
progress), July 2017. progress), July 2017.
[I-D.reddy-sfc-nsh-encrypt] [I-D.reddy-sfc-nsh-encrypt]
Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, Reddy, T., Patil, P., Fluhrer, S., and P. Quinn,
"Authenticated and encrypted NSH service chains", draft- "Authenticated and encrypted NSH service chains", draft-
reddy-sfc-nsh-encrypt-00 (work in progress), April 2015. reddy-sfc-nsh-encrypt-00 (work in progress), April 2015.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2784>. editor.org/info/rfc2784>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3692>. editor.org/info/rfc3692>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6071>. editor.org/info/rfc6071>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>. August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7498>. editor.org/info/rfc7498>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7676>. editor.org/info/rfc7676>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: paulq@cisco.com Email: paulq@cisco.com
Uri Elzur (editor) Uri Elzur (editor)
Intel Intel
 End of changes. 134 change blocks. 
345 lines changed or deleted 345 lines changed or added

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