draft-ietf-sfc-nsh-15.txt   draft-ietf-sfc-nsh-16.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: January 19, 2018 Intel Expires: January 20, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
July 18, 2017 July 19, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-15 draft-ietf-sfc-nsh-16
Abstract Abstract
This document describes a Network Service Header (NSH) inserted onto This document describes a Network Service Header (NSH) inserted onto
packets or frames to realize service function paths. NSH also packets or frames to realize service function paths. 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. NSH is the SFC encapsulation required to support the
Service Function Chaining (SFC) architecture (defined in RFC7665). Service Function Chaining (SFC) architecture (defined in RFC7665).
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 19, 2018. This Internet-Draft will expire on January 20, 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 40 skipping to change at page 2, line 40
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 19 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 19
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 19 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 19
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 21 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 21
7.3. Service Path Identifier and Metadata . . . . . . . . . . 23 7.3. Service Path Identifier and Metadata . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 27 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 27
11.2. Network Service Header (NSH) Parameters . . . . . . . . 27 11.2. Network Service Header (NSH) Parameters . . . . . . . . 27
11.2.1. NSH Base Header Reserved Bits . . . . . . . . . . . 27 11.2.1. NSH Base Header Unassigned Bits . . . . . . . . . . 27
11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 27 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 27
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 28 11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 28
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 28 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 28
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 29 11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 29
11.2.6. New IETF assigned MD Type Registry . . . . . . . . . 29 11.2.6. New IETF assigned MD Type Registry . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 6, line 43 skipping to change at page 6, line 43
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 2 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|R| TTL | Length |R|R|R|R|MD Type| Next Protocol | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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 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 ECMP decision processing, this
document reserves version 01 and this value MUST NOT be used in document reserves version 01b and this value MUST NOT be used in
future versions of the protocol. Please see [RFC7325] for further future versions of the protocol. Please see [RFC7325] for further
discussion of MPLS-related forwarding requirements. 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.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
TTL: Indicates the maximum SFF hops for an SFP. The initial TTL TTL: Indicates the maximum SFF hops for an SFP. The initial TTL
value SHOULD be configurable via the control plane; the configured value SHOULD be configurable via the control plane; the configured
initial value can be specific to one or more SFPs. If no initial initial value can be specific to one or more SFPs. If no initial
value is explicitly provided, the default initial TTL value 63 MUST value is explicitly provided, the default initial TTL value 63 MUST
be used. Each SFF involved in forwarding an NSH packet MUST be used. Each SFF involved in forwarding an NSH packet MUST
decrement the TTL value by 1 prior to NSH forwarding lookup. decrement the TTL value by 1 prior to NSH forwarding lookup.
Decrementing by 1 from an incoming value of 0 shall result in a TTL Decrementing by 1 from an incoming value of 0 shall result in a TTL
value of 63. The packet MUST NOT be forwarded if TTL is, after value of 63. The packet MUST NOT be forwarded if TTL is, after
decrement, 0. decrement, 0.
All other flag fields are reserved for future use. Reserved bits All other flag fields are unassigned and available for future use,
MUST be set to zero upon origination and MUST be preserved unmodified see Section 11.2.1. Unassigned bits MUST be set to zero upon
by other NSH supporting elements. Elements which do not understand origination and MUST be preserved unmodified by other NSH supporting
the meaning of any of these bits MUST NOT modify their actions based elements. Elements which do not understand the meaning of any of
on those unknown bits. these bits MUST NOT modify their actions based on those unknown bits.
Length: The total length, in 4-byte words, of NSH including the Base Length: The total length, in 4-byte words, of NSH including the Base
Header, the Service Path Header, the Fixed Length Context Header or Header, the Service Path Header, the Fixed Length Context Header or
Variable Length Context Header(s). The length MUST be of value 0x6 Variable Length Context Header(s). The length MUST be of value 0x6
for MD Type equal to 0x1, and MUST be of value 0x2 or greater for MD for MD Type equal to 0x1, and MUST be of value 0x2 or greater for MD
Type equal to 0x2. The length of the NSH header MUST be an integer Type equal to 0x2. The length of the NSH header MUST be an integer
multiple of 4 bytes, thus variable length metadata is always padded multiple of 4 bytes, thus variable length metadata is always padded
out to a multiple of 4 bytes. out to a multiple of 4 bytes.
MD Type: indicates the format of NSH beyond the mandatory Base Header MD Type: indicates the format of NSH beyond the mandatory Base Header
skipping to change at page 8, line 28 skipping to change at page 8, line 28
length Context Header (see Figure 4 below). length Context Header (see Figure 4 below).
0x2 - which does not mandate any headers beyond the Base Header and 0x2 - which 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 0x15. 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 implementations MUST support MD type = 0x1 and MD Type = 0x2 NSH implementations MUST support MD type = 0x1 and MD Type = 0x2
(where the length is of value 0x2). NSH implementations SHOULD (where the length is of value 0x2). NSH implementations SHOULD
support MD Type 0x2 with length > 0x2. There exists, however, a support MD Type 0x2 with length > 0x2. There exists, however, a
middle ground, wherein a device will support MD Type 0x1 (as per the middle ground, wherein a device will support MD Type 0x1 (as per the
MUST) metadata, yet be deployed in a network with MD Type 0x2 MUST) metadata, yet be deployed in a network with MD Type 0x2
metadata packets. In that case, the MD Type 0x1 node, MUST utilize metadata packets. In that case, the MD Type 0x1 node, MUST utilize
the base header length field to determine the original payload offset the base header length field to determine the original payload offset
if it requires access to the original packet/frame. This if it requires access to the original packet/frame. This
specification does not disallow the MD Type value from changing along specification does not disallow the MD Type value from changing along
an SFP; however, the specification of the necessary mechanism to an SFP; however, the specification of the necessary mechanism to
allow the MD Type to change along an SFP are outside the scope of 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. be available. Packets with MD Type values not supported by an
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 NSH does not alter the inner payload, and the semantics on the inner
protocol remain unchanged due to NSH service function chaining. 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:
0x0: Unassigned 0x0: Unassigned
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
0xFF: Experiment 2 0xFF: Experiment 2
Packets with Next Protocol values not supported by an implementation Packets with Next Protocol values not supported SHOULD be silently
SHOULD be silently dropped. Additionally, an implementation not dropped by default, although an implementation MAY provide a
explicitly configured for a specific experiment [RFC3692] SHOULD configuration parameter to forward them. Additionally, an
silently drop packets with Next Protocol values 0xFE and 0xFF. implementation not explicitly configured for a specific experiment
[RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE
and 0xFF.
2.3. Service Path Header 2.3. Service Path Header
Figure 3 shows the format of the Service Path Header: Figure 3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 24 skipping to change at page 10, line 26
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. A Fixed Length Context Header that Path Header, as per Figure 4. A Fixed Length Context Header that
carries no metadata MUST be set to zero. 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|R| TTL | Length |R|R|R|R|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 4: NSH MD Type=0x1
skipping to change at page 11, line 24 skipping to change at page 11, line 26
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|R| TTL | Length |R|R|R|R|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 5: 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 6.
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 |R| Len | | Metadata Class | Type |U| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata | | Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variable Context Headers Figure 6: 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 and is Type: indicates the explicit type of metadata being carried and is
the responsibility of the MD Class owner. the responsibility of the MD Class owner.
Reserved bit: one reserved bit is present for future use. The Unassigned bit: one unassigned bit is available for future use. This
reserved bits MUST be set to 0x0. bit MUST be set to 0b.
Length: indicates the length of the variable metadata, in single byte Length: indicates the length of the variable metadata, in single byte
words. In case the metadata length is not an integer number of words. In case the metadata length is not an integer number of
4-byte words, the sender MUST add pad bytes immediately following the 4-byte words, the sender MUST add pad bytes immediately following the
last metadata byte to extend the metadata to an integer number of 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 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 nearest 4-byte word boundary, to locate and process the next field in
the packet. The receiver MUST access only those bytes in the the packet. The receiver MUST access only those bytes in the
metadata indicated by the length field (i.e., actual number of single metadata indicated by the length field (i.e., actual number of single
byte words) and MUST ignore the remaining bytes up to the nearest byte words) and MUST ignore the remaining bytes up to the nearest
4-byte word boundary. The Length may be 0 or greater. 4-byte word boundary. The Length may be 0 or greater.
A value of 0x0 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 their scoping (see structure of context header together with their scoping (see
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 belong to a given SFP, if a mandatory- Upon receipt of a packet that belong to a given SFP, if a mandatory-
skipping to change at page 27, line 32 skipping to change at page 27, line 32
An IEEE EtherType, 0x894F, has been allocated for NSH. An IEEE EtherType, 0x894F, has been allocated for NSH.
11.2. Network Service Header (NSH) Parameters 11.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.
11.2.1. NSH Base Header Reserved Bits 11.2.1. NSH Base Header Unassigned Bits
There are five reserved bits in the NSH Base Header. New bits are There are five unassigned bits in the NSH Base Header. New bits are
assigned via Standards Action [RFC8126]. assigned via Standards Action [RFC8126].
Bit 3 - Reserved Bit 3 - Unassigned
Bits 16-19 - Reserved 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 00: This protocol version. This document. Version 00b: This protocol version. This document.
Version 01: Reserved. This document. Version 01b: Reserved. This document.
Version 10: Unassigned. Version 10b: Unassigned.
Version 11: 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 0, 1, 2, and 15 are specified in this 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in
document, see Table 5. Registry entries are assigned by using the this document, see Table 5. Registry entries are assigned by using
"IETF Review" policy defined in RFC 8126 [RFC8126]. the "IETF Review" policy defined in RFC 8126 [RFC8126].
+---------+-----------------+---------------+ +----------+-----------------+---------------+
| MD Type | Description | Reference | | MD Type | Description | Reference |
+---------+-----------------+---------------+ +----------+-----------------+---------------+
| 0 | Reserved | This document | | 0x0 | Reserved | This document |
| | | | | | | |
| 1 | NSH MD Type 1 | This document | | 0x1 | NSH MD Type 1 | This document |
| | | | | | | |
| 2 | NSH MD Type 2 | This document | | 0x2 | NSH MD Type 2 | This document |
| | | | | | | |
| 3..14 | Unassigned | | | 0x3..0xE | Unassigned | |
| | | | | | | |
| 15 | Experimentation | This document | | 0xF | Experimentation | This document |
+---------+-----------------+---------------+ +----------+-----------------+---------------+
Table 5: MD Type Values Table 5: MD Type Values
11.2.4. MD Class Registry 11.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. New allocations are to be made according to the bit values. New allocations are to be made according to the
following policies: following policies:
0x0000 to 0x01ff: IETF Review 0x0000 to 0x01ff: IETF Review
skipping to change at page 29, line 17 skipping to change at page 29, line 17
11.2.5. NSH Base Header Next Protocol 11.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 document (see Table 7. New values are assigned via "Expert in this document (see Table 7. New values are assigned via "Expert
Reviews" as per [RFC8126]. Reviews" as per [RFC8126].
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| 0x0 | Unassigned | This document | | 0x0 | Unassigned | |
| | | | | | | |
| 0x1 | IPv4 | This document | | 0x1 | IPv4 | This document |
| | | | | | | |
| 0x2 | IPv6 | This document | | 0x2 | IPv6 | This document |
| | | | | | | |
| 0x3 | Ethernet | This document | | 0x3 | Ethernet | This document |
| | | | | | | |
| 0x4 | NSH | This document | | 0x4 | NSH | This document |
| | | | | | | |
| 0x5 | MPLS | This document | | 0x5 | MPLS | This document |
 End of changes. 23 change blocks. 
49 lines changed or deleted 52 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/