draft-ietf-sfc-nsh-05.txt   draft-ietf-sfc-nsh-06.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: November 27, 2016 Intel Expires: February 24, 2017 Intel
May 26, 2016 August 23, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-05.txt draft-ietf-sfc-nsh-06.txt
Abstract Abstract
This document describes a Network Service Header (NSH) inserted onto This document describes a Network Service Header (NSH) inserted onto
encapsulated packets or frames to realize service function paths. packets or frames to realize service function paths. NSH also
NSH also provides a mechanism for metadata exchange along the provides a mechanism for metadata exchange along the instantiated
instantiated service path. NSH is the SFC encapsulation required to service path. NSH is the SFC encapsulation required to support the
support the Service Function Chaining (SFC) Architecture (defined in Service Function Chaining (SFC) Architecture (defined in RFC7665).
RFC7665).
1. Requirements Language 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].
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 November 27, 2016. This Internet-Draft will expire on February 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5
2.3. NSH-based Service Chaining . . . . . . . . . . . . . . . . 5 2.3. NSH-based Service Chaining . . . . . . . . . . . . . . . . 5
3. Network Service Header . . . . . . . . . . . . . . . . . . . . 7 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 7
3.1. Network Service Header Format . . . . . . . . . . . . . . 7 3.1. Network Service Header Format . . . . . . . . . . . . . . 7
3.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 3.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7
3.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9 3.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10
3.4. NSH MD-type 1 . . . . . . . . . . . . . . . . . . . . . . 10 3.4. NSH MD-type 1 . . . . . . . . . . . . . . . . . . . . . . 10
3.5. NSH MD-type 2 . . . . . . . . . . . . . . . . . . . . . . 10 3.5. NSH MD-type 2 . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1. Optional Variable Length Metadata . . . . . . . . . . 11 3.5.1. Optional Variable Length Metadata . . . . . . . . . . 12
4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 15 5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16
6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 16 6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 17
7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 17 7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 18
7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 17 7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 18
7.2. Mapping NSH to Network Transport . . . . . . . . . . . . . 19 7.2. Mapping NSH to Network Transport . . . . . . . . . . . . . 20
7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 20 7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 21
7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 21
8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21 8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22
8.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21 8.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22
8.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . . 22 8.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . . 24
8.3. Service Path Identifier and Metadata . . . . . . . . . . . 24 8.3. Service Path Identifier and Metadata . . . . . . . . . . . 25
9. NSH Encapsulation Examples . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. GRE + NSH . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. VXLAN-gpe + NSH . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9.3. Ethernet + NSH . . . . . . . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Network Service Header (NSH) Parameters . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12.2.1. NSH Base Header Reserved Bits . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . . 32
13.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . . 33 12.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . . 32
13.2. Network Service Header (NSH) Parameters . . . . . . . . . 33 12.2.4. MD Class Registry . . . . . . . . . . . . . . . . . . 33
13.2.1. NSH Base Header Reserved Bits . . . . . . . . . . . . 33 12.2.5. NSH Base Header Next Protocol . . . . . . . . . . . . 33
13.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13.2.4. MD Class Registry . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 35
13.2.5. NSH Base Header Next Protocol . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
2. Introduction 2. 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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
type-length-value (TLV) metadata. type-length-value (TLV) metadata.
NSH is designed to be easy to implement across a range of devices, NSH is designed to be easy to implement across a range of devices,
both physical and virtual, including hardware platforms. both physical and virtual, including hardware platforms.
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. NSH is the SFC
encapsulation referenced in RFC7665 document. encapsulation referenced in RFC7665.
2.1. Definition of Terms 2.1. Definition of Terms
Classification: Defined in [RFC7665]. Classification: Defined in [RFC7665].
Classifier: Defined in [RFC7665]. Classifier: Defined in [RFC7665].
Metadata: Defined in [RFC7665]. Metadata: Defined in [RFC7665].
Network Locator: dataplane address, typically IPv4 or IPv6, used to Network Locator: dataplane address, typically IPv4 or IPv6, used to
send and receive network traffic. send and receive network traffic.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
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].
SFC Proxy: Defined in [RFC7665]. SFC Proxy: Defined in [RFC7665].
2.2. Problem Space 2.2. Problem Space
Network Service Header (NSH) addresses several limitations associated Network Service Header (NSH) addresses several limitations associated
with service function deployments. RFC 7498 [RFC7498] provides a with service function deployments. [RFC7498] provides a
comprehensive review of those issues. comprehensive review of those issues.
2.3. NSH-based Service Chaining 2.3. NSH-based Service Chaining
The NSH creates a dedicated service plane, more specifically, NSH The NSH creates a dedicated service plane, more specifically, 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, the underlying network topology does not require
modification. NSH provides an identifier used to select the modification. NSH provides an identifier used to select the
network overlay for network forwarding. network overlay for network forwarding.
2. Service Chaining: NSH enables Service Chaining per [RFC7665]. 2. Service Chaining: NSH enables service chaining per [RFC7665].
NSH contains path identification information needed to realize a NSH contains path identification information needed to realize a
service path. Furthermore, NSH provides the ability to monitor service path. Furthermore, NSH provides the ability to monitor
and troubleshoot a service chain, end-to-end via service-specific and troubleshoot a service chain, end-to-end via service-specific
OAM messages. The NSH fields can be used by administrators (via, OAM messages. The NSH fields can be used by administrators (via,
for example a traffic analyser) to verify (account, ensure for example a traffic analyser) to verify (account, ensure
correct chaining, provide reports, etc.) the path specifics of correct chaining, provide reports, etc.) the path specifics of
packets being forwarded along a service path. packets being forwarded along a service path.
3. NSH provides a mechanism to carry shared metadata between network 3. NSH provides a mechanism to carry shared metadata between
devices and service function, and between service functions. The participating entities and service functions. The semantics of
semantics of the shared metadata is communicated via a control the shared metadata is communicated via a control plane, which is
plane to participating nodes. Examples of metadata include outside the scope of this document, to participating nodes.
classification information used for policy enforcement and Examples of metadata include classification information used for
network context for forwarding post service delivery. policy enforcement and network context for forwarding post
service delivery.
4. Classification and re-classification: sharing the metadata allows 4. Classification and re-classification: 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.
5. NSH offers a common and standards-based header for service 5. NSH offers a common and standards-based header for service
chaining to all network and service nodes. chaining to all network and service nodes.
6. Transport Agnostic: NSH is transport independent and is often 6. Transport Agnostic: NSH is transport independent and is often
carried via a network transport protocol, over existing carried via a network transport protocol, over existing
underlays. This transport may form an overlay network and if an underlays. This transport may form an overlay network and if an
existing overlay topology provides the required service path existing overlay topology provides the required service path
connectivity, that existing overlay may be used. connectivity, that existing overlay may be used.
3. Network Service Header 3. Network Service Header
A Network Service Header (NSH) contains service path information and A Network Service Header (NSH) contains service path information and
optionally metadata that are added to a packet or frame and used to optionally metadata that are added to a packet or frame and used to
create a service plane. The original packets preceded by NSH, are create a service plane. An outer transport header is imposed, on NSH
then encapsulated in an outer header for transport. and the original packet/frame, for network forwarding.
A Service Classifier adds the NSH. The NSH is removed by the last A Service Classifier adds the NSH. The NSH is removed by the last
SFF in the service chain or by a SF that consumes the packet. SFF in the service chain or by a SF that consumes the packet.
3.1. Network Service Header Format 3.1. Network Service Header Format
An NSH is composed of a 4-byte Base Header, a 4-byte Service Path An NSH is composed of a 4-byte Base Header, a 4-byte Service Path
Header and Context Headers, as shown in Figure 1 below. Header and Context Headers, as shown in Figure 1 below.
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
skipping to change at page 8, line 14 skipping to change at page 8, line 14
Figure 2: NSH Base Header Figure 2: 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 updates. It MUST be set to 0x0 by the going forward with future NSH updates. It MUST be set to 0x0 by the
sender, in this first revision of NSH. Given the widespread sender, in this first revision of NSH. Given the widespread
implementation of existing hardware that uses the first nibble after implementation of existing hardware that uses the first nibble after
an MPLS label stack for ECMP decision processing, this document an MPLS label stack for ECMP decision processing, this document
reserves version 01 and this value MUST NOT be used in future reserves version 01 and this value MUST NOT be used in future
versions of the protocol. versions of the protocol. Please see [RFC7325] for further
discussion of MPLS-related forwarding requirements.
O bit: when set to 0x1 indicates that this packet is an Operations, O bit: Setting this bit indicates an Operations, Administration, and
Administration and Maintenance (OAM) message. The receiving SFF and Maintenance (OAM) packet. The actual packet format and processing of
SFs nodes MUST examine the payload and take appropriate action (e.g. SFC OAM messages is outside the scope of this specification (see [I-
return status information). OAM message specifics and handling D.ietf-sfc-oam-framework]).
details are outside the scope of this document.
SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
OAM procedures, SHALL discard packets with O-bit set.
SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
parameter to enable forwarding received SFC OAM packets unmodified to
the next element in the chain. Such behavior may be acceptable for a
subset of OAM functions, but can result in unexpected outcomes for
others, thus it is recommended to analyze the impact of forwarding an
OAM packet for all OAM functions prior to enabling this behavior.
The configurable parameter MUST be disabled by default.
For non OAM packets, the O-bit MUST be cleared and MUST NOT be
modified along the SFP.
C bit: Indicates that a critical metadata TLV is present. This bit C bit: Indicates that a critical metadata TLV is present. This bit
acts as an indication for hardware implementers to decide how to acts as an indication for hardware implementers to decide how to
handle the presence of a critical TLV without necessarily needing to handle the presence of a critical TLV without necessarily needing to
parse all TLVs present. For an MD Type of 0x1 (i.e. no variable parse all TLVs present. For an MD Type of 0x1 (i.e. no variable
length metadata is present), the C bit MUST be set to 0x0. length metadata is present), the C bit MUST be set to 0x0.
All other flag fields are reserved for future use. Reserved bits All other flag fields are reserved for future use. Reserved bits
MUST be set to zero when sent and MUST be ignored upon receipt. MUST be set to zero when sent and MUST be ignored upon receipt.
skipping to change at page 9, line 16 skipping to change at page 9, line 31
invariant, and not affected by MD Type. invariant, and not affected by MD Type.
NSH implementations MUST support MD-Type = 0x1, and SHOULD support NSH implementations MUST support MD-Type = 0x1, and SHOULD support
MD- Type = 0x2. There exists, however, a middle ground, wherein a MD- Type = 0x2. There exists, however, a middle ground, wherein a
device will support MD-Type 0x1 (as per the MUST) metadata, yet be device will support MD-Type 0x1 (as per the MUST) metadata, yet be
deployed in a network with MD-Type 0x2 metadata packets. In that deployed in a network with MD-Type 0x2 metadata packets. In that
case, the MD-Type 0x1 node, MUST utilize the base header length field case, the MD-Type 0x1 node, MUST utilize the base header length field
to determine the original payload offset if it requires access to the to determine the original payload offset if it requires access to the
original packet/frame. original packet/frame.
Next Protocol: indicates the protocol type of the original packet. Next Protocol: indicates the protocol type of the encapsulated data.
NSH does not alter the inner payload, and the semantics on the inner
protocol remain unchanged due to NSH service function chaining.
Please see IANA Considerations section below. Please see IANA Considerations section below.
This draft defines the following Next Protocol values: This draft 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
0x6-0xFD: Unassigned 0x6-0xFD: Unassigned
skipping to change at page 9, line 45 skipping to change at page 10, line 21
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 3: NSH Service Path Header
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. Path selection.
Service Index (SI): provides location within the SFP. The first Service Index (SI): provides location within the SFP. The initial
classifier (i.e. at the boundary of the NSH domain) in the NSH classifier for a given SFP SHOULD set the SI to 255, however the
Service Function Path, SHOULD set the SI to 255, however the control control plane MAY configure the initial value of SI as appropriate
plane MAY configure the initial value of SI as appropriate (i.e. (i.e. taking into account the length of the service function path).
taking into account the length of the service function path). A Service Index MUST be decremented by Service Functions or by SFC
Classifier MUST send the packet to the first SFF in the chain. Proxy nodes after performing required services and the new
Service index MUST be decremented by service functions or proxy nodes decremented SI value MUST be used in the egress NSH packet. The
after performing required services and the new decremented SI value initial Classifier MUST send the packet to the first SFF in the
MUST be used in the egress NSH packet. SI SHOULD be used in identified SFP for forwarding along an SFP. If re-classification
conjunction with Service Path Identifier for Service Function Path occurs, and that re-classification results in a new SPI, the
selection. Service Index (SI) is also valuable when troubleshooting/ (re)classifier is, in effect, the initial classifier for the
reporting service paths. In addition to indicating the location resultant SPI.
within a Service Function Path, SI can be used for service plane loop
detection. SI SHOULD be used in conjunction with SPI for SFP selection and for
determining the next SFF/SF in the path. Service Index (SI) is also
valuable when troubleshooting/ reporting service paths. When an SPI
and SI do not correspond to a valid next Service Function path, it is
an error and the SFF SHOULD generate an error/log message. The value
zero for SI is not valid and indicates a broken SFC or malfunctioning
SF. In addition to indicating the location within a Service Function
Path, SI can be used for service plane loop detection.
3.4. NSH MD-type 1 3.4. NSH MD-type 1
When the Base Header specifies MD Type = 0x1, four Context Headers, When the Base Header specifies MD Type = 0x1, four Context Headers,
4-byte each, MUST be added immediately following the Service Path 4-byte each, MUST be added immediately following the Service Path
Header, as per Figure 4. Context Headers that carry no metadata MUST Header, as per Figure 4. Context Headers that carry no metadata MUST
be set to zero. be set to zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 29 skipping to change at page 12, line 14
Figure 5: NSH MD-type=0x2 Figure 5: NSH MD-type=0x2
3.5.1. Optional Variable Length Metadata 3.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
described below. described 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class |C| Type |R|R|R| Len | | Metadata Class |C| Type |R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata | | Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variable Context Headers Figure 6: Variable Context Headers
Metadata Class (MD Class): describes the scope of the "Type" field. Metadata Class (MD Class): The MD Class defines the scope of the
In some cases, the MD Class will identify a specific vendor, in 'Type' field to provide a hierarchical namespace. The IANA
others, the MD Class will identify specific standards body allocated Considerations section defines how the MD Class values can be
types. Please see IANA Considerations section below. allocated to standards bodies, vendors, and others.
Type: the specific type of information being carried, within the Type: the Type field is split into two ranges - 0 to 127 for non-
scope of a given MD Class. Value allocation is the responsibility of critical options and 128-255 for critical options. While the value
the MD Class owner. allocation is the responsibility of the MD Class owner, critical
options MUST NOT be allocated from the 0 to 127 range and non-
critical options MUST NOT be allocated from the 128-255 range.
Encoding the criticality of the TLV within the Type field is Figure 7 below illustrates the placement of the Critical bit within
consistent with IPv6 option types: the most significant bit of the the Type field.
Type field indicates whether the TLV is mandatory for the receiver to
understand/process. This effectively allocates Type values 0 to 127
for non-critical options and Type values 128 to 255 for critical
options. Figure 7 below illustrates the placement of the Critical
bit within the Type field.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|C| Type | |C| Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 7: Critical Bit Placement Within the TLV Type Field Figure 7: Critical Bit Placement Within the TLV Type Field
If an NSH-aware node receives an encapsulated packet containing a TLV If an NSH-aware node receives an encapsulated packet containing a TLV
with the Critical bit set to 0x1 in the Type field and it does not with the Critical bit set to 0x1 in the Type field and it does not
understand how to process the Type, it MUST drop the packet. Transit understand how to process the Type, it MUST drop the packet. Transit
devices (i.e. network nodes that do not participate in the service devices (i.e. network nodes that do not participate in the service
plane) MUST NOT drop packets based on the setting of this bit. plane) MUST NOT drop packets based on the setting of this bit.
Reserved bits: three reserved bit are present for future use. The Reserved bits: three reserved bit are present for future use. The
reserved bits MUST be set to 0x0. reserved bits MUST be set to 0x0.
Length: Length of the variable metadata, in 4-byte words. A value of Length: Length of the variable metadata, in single byte words. In
0x0 or higher can be used. A value of 0x0 denotes a TLV header case the metadata length is not an integer number of 4-byte words,
without a Variable Metadata field. the sender MUST add pad bytes immediately following the last metadata
byte to extend the metadata to an integer number of 4-byte words.
The receiver MUST round up the length field to the nearest 4-byte
word boundary, to locate and process the next field in the packet.
The receiver MUST access only those bytes in the metadata indicated
by the length field (i.e. actual number of single byte words) and
MUST ignore the remaining bytes up to the nearest 4-byte word
boundary. A value of 0x0 or higher can be used.
A value of 0x0 denotes a TLV header without a Variable Metadata
field.
4. NSH Actions 4. NSH Actions
NSH-aware nodes are the only nodes that MAY alter the content of the NSH-aware nodes are the only nodes that MAY alter the content of the
NSH headers. NSH-aware nodes include: service classifiers, SFF, SF NSH headers. NSH-aware nodes include: service classifiers, SFF, SF
and SFC proxies. These nodes have several possible header related and SFC proxies. These nodes have several possible header related
actions: actions:
1. Insert or remove NSH: These actions can occur at the start and 1. Insert or remove NSH: These actions can occur at the start and
end respectively of a service path. Packets are classified, and end respectively of a service path. Packets are classified, and
skipping to change at page 13, line 36 skipping to change at page 14, line 36
Header reflecting the new service path information and set the Header reflecting the new service path information and set the
initial SI. Metadata MAY be preserved in the new NSH. initial SI. Metadata MAY be preserved in the new NSH.
2. Select service path: The Service Path Header provides service 2. Select service path: The Service Path Header provides service
chain information and is used by SFFs to determine correct chain information and is used by SFFs to determine correct
service path selection. SFFs MUST use the Service Path Header service path selection. SFFs MUST use the Service Path Header
for selecting the next SF or SFF in the service path. for selecting the next SF or SFF in the service path.
3. Update a Service Path Header: NSH-aware service functions (SF) 3. Update a Service Path Header: NSH-aware service functions (SF)
MUST decrement the service index. If an SFF receives a packet MUST decrement the service index. If an SFF receives a packet
with SI equal to 0x0, that packet MUST be dropped by the SFF. with an SPI and SI that do not correspond to a valid next Service
Function Path, that packet MUST be dropped by the SFF.
Classifier(s) MAY update Context Headers if new/updated context Classifier(s) MAY update Context Headers if new/updated context
is available. is available.
If an SFC proxy is in use (acting on behalf of a non-NSH-aware If an SFC proxy is in use (acting on behalf of a non-NSH-aware
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 the NSH receives an NSH-encapsulated packet, it MUST remove the NSH
headers before forwarding it to an NSH unaware SF. When the SFC headers before forwarding it to an NSH unaware SF. When the SFC
Proxy receives a packet back from an NSH unaware SF, it MUST re- Proxy receives a packet back from an NSH unaware SF, it MUST re-
skipping to change at page 16, line 9 skipping to change at page 17, line 9
encapsulated in existing transports. The presence of NSH is encapsulated in existing transports. The presence of NSH is
indicated via protocol type or other indicator in the outer indicated via protocol type or other indicator in the outer
encapsulation. encapsulation.
See Section 9 for NSH encapsulation examples. See Section 9 for NSH encapsulation examples.
6. Fragmentation Considerations 6. Fragmentation Considerations
NSH and the associated transport header are "added" to 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. In order the ensure proper forwarding of NSH size of the packet. In order to ensure proper forwarding of NSH
packets, several options for handling fragmentation and re-assembly packets, several options for handling fragmentation and re-assembly
exist: exist:
1. Jumbo Frames, when supported, enable the transport of NSH and As discussed in [draft-ietf-rtgwg-dt-encap-01], within an
associated transport packets without requiring fragmentation. administrative domain, an operator can ensure that the underlay MTU
is sufficient to carry SFC traffic without requiring fragmentation.
2. and [RFC1191][RFC1981] describe a technique for dynamically
discovering the maximum transmission unit (MTU) of an arbitrary
internet path" and can be utilized to ensure the required packet
size is used.
3. Use the fragmentation provided by the network transport/overlay. However, there will be cases where the underlay MTU is not large
One example can be found in [RFC6830], section 5.4. enough to carry the NSH traffic. Since NSH does not provide
fragmentation support at the service plane, the transport/overlay
layer MUST provide the requisite fragmentation handling. Section 6
of [draft-ietf-rtgwg-dt-encap-01] provides guidance for those
scenarios.
7. Service Path Forwarding with NSH 7. Service Path Forwarding with NSH
7.1. SFFs and Overlay Selection 7.1. SFFs and Overlay Selection
As described above, NSH contains a Service Path Identifier (SPI) and As described above, NSH contains a Service Path Identifier (SPI) and
a Service Index (SI). The SPI is, as per its name, an identifier. a Service Index (SI). The SPI is, as per its name, an identifier.
The SPI alone cannot be used to forward packets along a service path. The SPI alone cannot be used to forward packets along a service path.
Rather the SPI provide a level of indirection between the service Rather the SPI provide a level of indirection between the service
path/topology and the network transport. Furthermore, there is no path/topology and the network transport. Furthermore, there is no
skipping to change at page 18, line 6 skipping to change at page 19, line 6
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 a NSH encapsulated packet from the the first SFF in the path gets a 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. Figure 9 below given network) and next hop for the requisite SF. Figure 9 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.
+-------------------------------------------------------+ +-------------------------------------------------------+
| SPI | SI | NH | Transport | | SPI | SI | Next hop(s) | Transport |
+-------------------------------------------------------+ +-------------------------------------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe | | 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| 10 | 254 | 198.51.100.10 | GRE | | 10 | 254 | 198.51.100.10 | GRE |
| 10 | 251 | 198.51.100.15 | GRE | | 10 | 251 | 198.51.100.15 | GRE |
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+-------------------------------------------------------+ +-------------------------------------------------------+
Figure 9: SFF NSH Mapping Example Figure 9: SFF NSH Mapping Example
Additionally, further indirection is possible: the resolution of the Additionally, further indirection is possible: the resolution of the
required SF network locator may be a localized resolution on an SFF, required SF network locator may be a localized resolution on an SFF,
rather than a service function chain control plane responsibility, as rather than a service function chain control plane responsibility, as
per figures 10 and 11 below. per figures 10 and 11 below.
Please note: VXLAN-gpe and GRE in the above table refer to Please note: VXLAN-gpe and GRE in the above table refer to
[VXLAN-gpe] and [RFC2784], respectively. [VXLAN-gpe] and [RFC2784], respectively.
+-------------------+ +----------------------------+
| SPI | SI | NH | | SPI | SI | Next hop(s) |
+-------------------+ +----------------------------+
| 10 | 3 | SF2 | | 10 | 3 | SF2 |
| 245 | 12 | SF34 | | 245 | 12 | SF34 |
| 40 | 9 | SF9 | | 40 | 9 | SF9 |
+-------------------+ +----------------------------+
Figure 10: NSH to SF Mapping Example Figure 10: NSH to SF Mapping Example
+----------------------------------------+ +----------------------------------------+
| SF | NH | Transport | | SF | Next hop(s) | Transport |
+----------------------------------------| +----------------------------------------|
| SF2 | 192.0.2.2 | VXLAN-gpe | | SF2 | 192.0.2.2 | VXLAN-gpe |
| SF34| 198.51.100.34 | UDP | | SF34| 198.51.100.34 | UDP |
| SF9 | 2001:db8::1 | GRE | | SF9 | 2001:db8::1 | GRE |
+--------------------------+------------- +--------------------------+-------------
= =
Figure 11: SF Locator Mapping Example Figure 11: SF Locator Mapping Example
Since the SPI is a representation of the service path, the lookup may Since the SPI is a representation of the service path, the lookup may
return more than one possible next-hop within a service path for a return more than one possible next-hop within a service path for a
skipping to change at page 20, line 41 skipping to change at page 21, line 41
packet is "on", and its location within that path simply by viewing packet is "on", and its location within that path simply by viewing
the NSH information (packet capture, IPFIX, etc.). The information the NSH information (packet capture, IPFIX, etc.). The information
can be used for service scheduling and placement decisions, can be used for service scheduling and placement decisions,
troubleshooting and compliance verification. troubleshooting and compliance verification.
7.4. Service Graphs 7.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 re-
reclassification). These internal reclassifiers examine the packet classification). These internal re-classifiers examine the packet at
at relevant points in the network, and rewrite the SPI and SI to relevant points in the network, and, if needed, SPI and SI are
reflect the results of the reclassification. (These classifiers may updated (whether this update is a re-write, or the imposition of a
also of course modify the metadata associated with the packet.) new NSH with new values is implementation specific) to reflect the
"result" of the classification. These classifiers may also of course
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.
8. Policy Enforcement with NSH 8. Policy Enforcement with NSH
8.1. NSH Metadata and Policy Enforcement 8.1. NSH Metadata and Policy Enforcement
As described in Section 3, NSH provides the ability to carry metadata As described in Section 3, 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:
skipping to change at page 22, line 44 skipping to change at page 23, line 44
Employee Employee
AppZ AppZ
Figure 14: External Metadata and Policy Figure 14: 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, rather 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
considerations may need to be considered. For example, if the
metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only) . NSH
itself does not provide privacy functions, rather it relies on the
transport/overlay layer. An operator can select the appropriate
transport to ensure the confidentially (and other security)
considerations are met.
8.2. Updating/Augmenting Metadata 8.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically performed during initial Post-initial metadata imposition (typically performed during initial
service path determination), metadata may be augmented or updated: service path determination), metadata may be augmented or updated:
1. Metadata Augmentation: Information may be added to NSH's existing 1. Metadata Augmentation: Information may be added to NSH's existing
metadata, as depicted in Figure 17. For example, if the initial metadata, as depicted in Figure 17. For example, if the initial
classification returns the tenant information, a secondary classification returns the tenant information, a secondary
classification (perhaps co-resident with DPI or SLB) may augment classification (perhaps co-resident with DPI or SLB) may augment
the tenant classification with application information, and the tenant classification with application information, and
impose that new information in the NSH metadata. The tenant impose that new information in the NSH metadata. The tenant
classification is still valid and present, but additional classification is still valid and present, but additional
information has been added to it. 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 18 illustrates an example of updating metadata. Figure 16 illustrates an example of updating metadata.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF | | SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
^ | | ^ | |
,---. ,---. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \ / \
( Class ) ( SF1 ) ( SF2 ) ( Class ) ( SF1 ) ( SF2 )
\ / \ / \ / \ / \ / \ /
`-+-' `---' `---' `-+-' `---' `---'
skipping to change at page 24, line 23 skipping to change at page 25, line 23
`---' `---' `---' `---' `---' `---'
5-tuple: Inspect Deny 5-tuple: Inspect Deny
Tenant A Tenant A attack Tenant A Tenant A attack
--> attack --> attack
Figure 16: Metadata Update Figure 16: Metadata Update
8.3. Service Path Identifier and Metadata 8.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 can represent the result of the Service Path Identifier and Service Index values can represent
classification. A given SPI can represent all or some of the the result of classification. A given SPI and SI can be defined
metadata, and be updated based on metadata classification results. based on classification results (including metadata classification).
The imposition of the SPI/SI (new or an change of existing) reflect,
as previously described, the new SFP.
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 7.4. Figure 19 illustrates an example of this described in Section 7.4. Figure 17 illustrates an example of this
behavior. behavior.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| SFF |---------> | SFF |------+---> | SFF | | SFF |---------> | SFF |------+---> | SFF |
+--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ | +--+--+
| | | | | | | |
,---. ,---. | ,---. ,---. ,---. | ,---.
/ \ / \ | / \ / \ / \ | / \
( SCL ) ( SF1 ) | ( SF2 ) ( SCL ) ( SF1 ) | ( SF2 )
\ / \ / | \ / \ / \ / | \ /
skipping to change at page 26, line 5 skipping to change at page 27, line 5
\ / \ /
`---' `---'
DoS DoS
"Scrubber" "Scrubber"
Figure 17: Path ID and Metadata Figure 17: 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.
9. NSH Encapsulation Examples 9. Security Considerations
9.1. GRE + NSH
IPv4 Packet:
+----------+--------------------+--------------------+
|L2 header | L3 header, proto=47|GRE header,PT=0x894F|
+----------+--------------------+--------------------+
--------------+----------------+
NSH, NP=0x1 |original packet |
--------------+----------------+
L2 Frame:
+----------+--------------------+--------------------+
|L2 header | L3 header, proto=47|GRE header,PT=0x894F|
+----------+--------------------+--------------------+
---------------+---------------+
NSH, NP=0x3 |original frame |
---------------+---------------+
Figure 18: GRE + NSH
9.2. VXLAN-gpe + NSH
IPv4 Packet:
+----------+------------------------+---------------------+
|L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|
+----------+------------------------+---------------------+
--------------+----------------+
NSH, NP=0x1 |original packet |
--------------+----------------+
L2 Frame:
+----------+------------------------+---------------------+
|L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|
+----------+------------------------+---------------------+
---------------+---------------+
NSH,NP=0x3 |original frame |
---------------+---------------+
Figure 19: VXLAN-gpe + NSH
9.3. Ethernet + NSH
IPv4 Packet:
+-------------------------------+---------------+--------------------+
|Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet |
+-------------------------------+---------------+--------------------+
L2 Frame:
+-------------------------------+---------------+----------------+
|Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame |
+-------------------------------+---------------+----------------+
Figure 20: Ethernet + NSH
10. Security Considerations
As with many other protocols, NSH data can be spoofed or otherwise As with many other protocols, NSH data can be spoofed or otherwise
modified. In many deployments, NSH will be used in a controlled modified. As noted in the descriptive text in [sfc-security-
requirements], in many deployments, NSH will be used in a controlled
environment, with trusted devices (e.g. a data center) thus environment, with trusted devices (e.g. a data center) thus
mitigating the risk of unauthorized header manipulation. mitigating the risk of unauthorized header manipulation. As noted
there, far fewer protection mechanisms are needed in these
environments, which are the primary design target of NSH.
NSH is always encapsulated in a transport protocol and therefore, NSH is always encapsulated in a transport protocol and therefore,
when required, existing security protocols that provide authenticity when required, existing security protocols that provide authenticity
(e.g. RFC 2119 [RFC6071]) can be used. (e.g. [ [RFC6071]) can be used between SFF or even to SF. Similarly
if confidentiality is required, existing encryption protocols can be
used in conjunction with encapsulated NSH.
Similarly if confidentiality is required, existing encryption Further, existing best practices, such as [BCP38] should be deployed
protocols can be used in conjunction with encapsulated NSH. at the network layer to ensure that traffic entering the service path
is indeed "valid". [draft-ietf-rtgwg-dt-encap-01.txt] provides
additional transport encapsulation considerations.
NSH metadata authenticity and confidentially must be considered as
well. In order to protect the metadata, an operator can leverage the
aforementioned mechanisms provided the transport layer, authenticity
and/or confidentiality. An operator MUST carefully select the
transport/underlay services to ensure end to end security services,
when those are sought after. For example, if RFC6071 is used, the
operator MUST ensure it can be supported by the transport/underlay of
all relevant network segments as well as SFF and SFs. Further, as
describe in [section 8.1], operators can and should use indirect
identification for personally identifying information, thus
significantly mitigating the risk of privacy violation.
Further, the extensibility of MD-2 to add information to packets, and
where needed to mark that data as critical, allows for attaching
signatures or even encryption keying information to the NSH header in
the future. Based on the learnings from the work on [nsh-sec], it
appears likely that this can provide any needed NSH-specific security
mechanisms in the future.
Lastly, SF security, although out of scope of this document, should
be considered, particularly if an SF needs to access, authenticate or
update NSH metadata.
Further security considerations are discussed in [nsh-sec]. Further security considerations are discussed in [nsh-sec].
11. Contributors 10. Contributors
This WG document originated as draft-quinn-sfc-nsh and had the This WG document originated as draft-quinn-sfc-nsh and had the
following co-authors and contributors. The editors of this document following co-authors and contributors. The editors of this document
would like to thank and recognize them and their contributions. would like to thank and recognize them and their contributions.
These co-authors and contributors provided invaluable concepts and These co-authors and contributors provided invaluable concepts and
content for this document's creation. content for this document's creation.
Surendra Kumar Surendra Kumar
Cisco Systems Cisco Systems
smkumar@cisco.com smkumar@cisco.com
skipping to change at page 32, line 5 skipping to change at page 31, line 5
louis.fourie@huawei.com louis.fourie@huawei.com
Ron Parker Ron Parker
Affirmed Networks Affirmed Networks
ron_parker@affirmednetworks.com ron_parker@affirmednetworks.com
Myo Zarny Myo Zarny
Goldman Sachs Goldman Sachs
myo.zarny@gs.com myo.zarny@gs.com
12. Acknowledgments 11. Acknowledgments
The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli,
Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi and Ken Gray Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal
for their detailed review, comments and contributions. Mizrahi and Ken Gray for their detailed review, comments and
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.
Additionally the authors would like to thank Carlos Pignataro and Additionally the authors would like to thank Carlos Pignataro and
Larry Kreeger for their invaluable ideas and contributions which are Larry Kreeger for their invaluable ideas and contributions which are
reflected throughout this document. reflected throughout this document.
Loa Andersson provided a thorough review and valuable comments, we Loa Andersson provided a thorough review and valuable comments, we
thank him for that. thank him for that.
Lastly, Reinaldo Penno deserves a particular thank you for his Lastly, Reinaldo Penno deserves a particular thank you for his
architecture and implementation work that helped guide the protocol architecture and implementation work that helped guide the protocol
concepts and design. concepts and design.
13. IANA Considerations 12. IANA Considerations
13.1. NSH EtherType 12.1. NSH EtherType
An IEEE EtherType, 0x894F, has been allocated for NSH. An IEEE EtherType, 0x894F, has been allocated for NSH.
13.2. Network Service Header (NSH) Parameters 12.2. Network Service Header (NSH) Parameters
IANA is requested to create a new "Network Service Header (NSH) IANA is requested to create a new "Network Service Header (NSH)
Parameters" registry. The following sub-sections request new Parameters" registry. The following sub-sections request new
registries within the "Network Service Header (NSH) Parameters " registries within the "Network Service Header (NSH) Parameters "
registry. registry.
13.2.1. NSH Base Header Reserved Bits 12.2.1. NSH Base Header Reserved Bits
There are ten bits at the beginning of the NSH Base Header. New bits There are ten bits at the beginning of the NSH Base Header. New bits
are assigned via Standards Action [RFC5226]. are assigned via Standards Action [RFC5226].
Bits 0-1 - Version Bits 0-1 - Version
Bit 2 - OAM (O bit) Bit 2 - OAM (O bit)
Bit 3 - Critical TLV (C bit) Bit 3 - Critical TLV (C bit)
Bits 4-9 - Reserved Bits 4-9 - Reserved
13.2.2. NSH Version 12.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 [RFC5226]. are assigned via Standards Action [RFC5226].
Version 00: This protocol version. This document. Version 00: This protocol version. This document.
Version 01: Reserved. This document. Version 01: Reserved. This document.
Version 10: Unassigned. Version 10: Unassigned.
Version 11: Unassigned. Version 11: Unassigned.
13.2.3. MD Type Registry 12.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
8-bit values. MD Type values 0, 1, 2, 254, and 255 are specified in 8-bit values. MD Type values 0, 1, 2, 254, and 255 are specified in
this document. Registry entries are assigned by using the "IETF this document. Registry entries are assigned by using the "IETF
Review" policy defined in RFC 5226 [RFC5226]. Review" policy defined in RFC 5226 [RFC5226].
+---------+--------------+---------------+ +---------+--------------+---------------+
| MD Type | Description | Reference | | MD Type | Description | Reference |
+---------+--------------+---------------+ +---------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
skipping to change at page 34, line 23 skipping to change at page 33, line 23
| | | | | | | |
| 3..253 | Unassigned | | | 3..253 | Unassigned | |
| | | | | | | |
| 254 | Experiment 1 | This document | | 254 | Experiment 1 | This document |
| | | | | | | |
| 255 | Experiment 2 | This document | | 255 | Experiment 2 | This document |
+---------+--------------+---------------+ +---------+--------------+---------------+
Table 1 Table 1
13.2.4. MD Class Registry 12.2.4. MD Class Registry
IANA is requested to set up a registry of "MD Class". These are 16- IANA is requested to set up a registry of "MD Class". These are 16-
bit values. Registry entries are assigned by using the "IETF Review" bit values. MD Classes defined by this document are assigned as
policy defined in RFC 5226 [RFC5226]. TLV Classes defined by this follows:
document are listed below. New values are assigned via Standards 0x0000 to 0x01ff: IETF Review
Action [RFC5226].
0x0000 to 0x01ff: IETF Consensus
0x0200 to 0x7fff: Expert Review 0x0200 to 0x7fff: Expert Review
0xfff6 to 0xfffe: Experimental 0xfff6 to 0xfffe: Experimental
0xffff: Reserved 0xffff: Reserved
13.2.5. NSH Base Header Next Protocol 12.2.5. NSH Base Header Next Protocol
IANA is requested to set up a registry of "Next Protocol". These are IANA is requested to set up a registry of "Next Protocol". These are
8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined
in this draft. New values are assigned via Standards Action in this draft. New values are assigned via Standards Action
[RFC5226]. [RFC5226].
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
skipping to change at page 36, line 5 skipping to change at page 35, line 5
| | | | | | | |
| 6..253 | Unassigned | | | 6..253 | Unassigned | |
| | | | | | | |
| 254 | Experiment 1 | This document | | 254 | Experiment 1 | This document |
| | | | | | | |
| 255 | Experiment 2 | This document | | 255 | Experiment 2 | This document |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
Table 2 Table 2
14. References 13. References
14.1. Normative References 13.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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, DOI 10.17487/ Service Function Chaining", RFC 7498, DOI 10.17487/
RFC7498, April 2015, RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>. <http://www.rfc-editor.org/info/rfc7498>.
[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, DOI 10.17487/ Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
RFC7665, October 2015, RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>. <http://www.rfc-editor.org/info/rfc7665>.
14.2. Informative References 13.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, for IP version 6", RFC 1981, DOI 10.17487/RFC1981,
August 1996, <http://www.rfc-editor.org/info/rfc1981>. August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[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,
<http://www.rfc-editor.org/info/rfc2784>. <http://www.rfc-editor.org/info/rfc2784>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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,
<http://www.rfc-editor.org/info/rfc6071>. <http://www.rfc-editor.org/info/rfc6071>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[VXLAN-gpe] [VXLAN-gpe]
Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D., Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D.,
Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg, Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-nvo3-vxlan-gpe/>. draft-ietf-nvo3-vxlan-gpe/>.
[broadalloc] [broadalloc]
Napper, J., Kumar, S., Muley, P., and W. Hendericks, "NSH Napper, J., Kumar, S., Muley, P., and W. Hendericks, "NSH
Context Header Allocation -- Mobility", 2016, <https:// Context Header Allocation -- Mobility", 2016, <https://
 End of changes. 55 change blocks. 
211 lines changed or deleted 231 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/