draft-ietf-sfc-nsh-07.txt   draft-ietf-sfc-nsh-08.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: February 24, 2017 Intel Expires: March 19, 2017 Intel
August 23, 2016 September 15, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-07.txt draft-ietf-sfc-nsh-08.txt
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 path. NSH is the SFC encapsulation required to support the service path. 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).
1. Requirements Language 1. Requirements Language
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 February 24, 2017. This Internet-Draft will expire on March 19, 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 16 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11 3.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1. Optional Variable Length Metadata . . . . . . . . . . 12 3.5.1. Optional Variable Length Metadata . . . . . . . . . . 12
4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16 5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16
6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 17 6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 17
7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 18 7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 18
7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 18 7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 18
7.2. Mapping NSH to Network Transport . . . . . . . . . . . . . 20 7.2. Mapping NSH to Network Transport . . . . . . . . . . . . . 20
7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 21 7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 21
7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 21
8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22 8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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 3. NSH provides a mechanism to carry shared metadata between
participating entities and service functions. The semantics of participating entities and service functions. The semantics of
the shared metadata is communicated via a control plane, which is the shared metadata is communicated via a control plane, which is
outside the scope of this document, to participating nodes. outside the scope of this document, to participating nodes.
Examples of metadata include classification information used for [SFC-CP] provides an example of such in section 3.3. Examples of
policy enforcement and network context for forwarding post metadata include classification information used for policy
service delivery. 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. An appropriate
carried via a network transport protocol, over existing (for a given deployment) network transport protocol can be used
underlays. This transport may form an overlay network and if an to transport NSH-encapsulated traffic. This transport may form
existing overlay topology provides the required service path an overlay network and if an existing overlay topology provides
connectivity, that existing overlay may be used. the required service path 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. An outer transport header is imposed, on NSH create a service plane. An outer transport header is imposed, on NSH
and the original packet/frame, for network forwarding. 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 (all references to bytes in this draft
refer to 8-bit bytes, or octets) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header | | Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Header | | Service Path Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Context Headers ~ ~ Context Headers ~
skipping to change at page 9, line 23 skipping to change at page 9, line 23
0x1 - which indicates that the format of the header includes fixed 0x1 - which indicates that the format of the header includes fixed
length context headers (see Figure 4 below). length context headers (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
information. information.
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 SHOULD support NSH implementations MUST support MD Type = 0x1, and SHOULD support MD
MD- Type = 0x2. There exists, however, a middle ground, wherein a Type = 0x2. There exists, however, a middle ground, wherein a device
device will support MD-Type 0x1 (as per the MUST) metadata, yet be will support MD Type 0x1 (as per the MUST) metadata, yet be deployed
deployed in a network with MD-Type 0x2 metadata packets. In that in a network with MD Type 0x2 metadata packets. In that case, the MD
case, the MD-Type 0x1 node, MUST utilize the base header length field Type 0x1 node, MUST utilize the base header length field to determine
to determine the original payload offset if it requires access to the the original payload offset if it requires access to the original
original packet/frame. packet/frame.
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 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
skipping to change at page 10, line 19 skipping to change at page 10, line 19
| Service Path Identifier (SPI) | Service Index | | Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path Identifier (SPI): 24 bits Service Path Identifier (SPI): 24 bits
Service Index (SI): 8 bits Service Index (SI): 8 bits
Figure 3: NSH Service Path Header Figure 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. The initial classifier MUST set the appropriate SPI
for a given classification result.
Service Index (SI): provides location within the SFP. The initial Service Index (SI): provides location within the SFP. The initial
classifier for a given SFP SHOULD set the SI to 255, however the classifier MUST set the appropriate SI value for a given
control plane MAY configure the initial value of SI as appropriate classification result. The initial SI value SHOULD default to 255.
(i.e. taking into account the length of the service function path). However, the classifier MUST allow configuration of other SI values.
Service Index MUST be decremented by Service Functions or by SFC Service Index MUST be decremented by Service Functions or by SFC
Proxy nodes after performing required services and the new Proxy nodes after performing required services and the new
decremented SI value MUST be used in the egress NSH packet. The decremented SI value MUST be used in the egress NSH packet. The
initial Classifier MUST send the packet to the first SFF in the initial Classifier MUST send the packet to the first SFF in the
identified SFP for forwarding along an SFP. If re-classification identified SFP for forwarding along an SFP. If re-classification
occurs, and that re-classification results in a new SPI, the occurs, and that re-classification results in a new SPI, the
(re)classifier is, in effect, the initial classifier for the (re)classifier is, in effect, the initial classifier for the
resultant SPI. resultant SPI.
SI SHOULD be used in conjunction with SPI for SFP selection and for SI SHOULD be used in conjunction with SPI for SFP selection and,
determining the next SFF/SF in the path. Service Index (SI) is also consequently, determining the next SFF/SF in the path. Service Index
valuable when troubleshooting/ reporting service paths. When an SPI (SI) is also valuable when troubleshooting/ reporting service paths.
and SI do not correspond to a valid next Service Function path, it is When an SPI and SI do not correspond to a valid next hop in a SFP, it
an error and the SFF SHOULD generate an error/log message. The value is an error and the SFF SHOULD generate an error/log message. The
zero for SI is not valid and indicates a broken SFC or malfunctioning value zero for SI is not valid and indicates a broken SFC or
SF. In addition to indicating the location within a Service Function malfunctioning SF. In addition to indicating the location within a
Path, SI can be used for service plane loop detection. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | |Ver|O|C|R|R|R|R|R|R| Length | MD type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifer | Service Index | | Service Path Identifer | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header | | Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header | | Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header | | Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header | | Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSH MD-type=0x1 Figure 4: NSH MD Type=0x1
[dcalloc] and [broadalloc] provide specific examples of how metadata [dcalloc] and [broadalloc] provide specific examples of how metadata
can be allocated. can be allocated.
3.5. NSH MD-type 2 3.5. NSH MD Type 2
When the base header specifies MD Type= 0x2, zero or more Variable When the base header specifies MD Type= 0x2, zero or more Variable
Length Context Headers MAY be added, immediately following the Length Context Headers MAY be added, immediately following the
Service Path Header. Therefore, Length = 0x2, indicates that only Service Path Header. Therefore, Length = 0x2, indicates that only
the Base Header followed by the Service Path Header are present. The the Base Header followed by the Service Path Header are present. The
optional Variable Length Context Headers MUST be of an integer number optional Variable Length Context Headers MUST be of an integer number
of 4-bytes. The base header length field MUST be used to determine of 4-bytes. The base header length field MUST be used to determine
the offset to locate the original packet or frame for SFC nodes that the offset to locate the original packet or frame for SFC nodes that
require access to that information. require access to that information.
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|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | |Ver|O|C|R|R|R|R|R|R| Length | MD Type=0x2 | 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
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| Len | | Metadata Class |C| Type |R| Len |
skipping to change at page 14, 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 an SPI and SI that do not correspond to a valid next Service with an SPI and SI that do not correspond to a valid next hop in
Function Path, that packet MUST be dropped by the SFF. a valid 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 20, line 46 skipping to change at page 20, line 46
Furthermore, the SPI to overlay mapping occurs at each SFF Furthermore, the SPI to overlay mapping occurs at each SFF
independently. Any combination of topology selection is possible. independently. Any combination of topology selection is possible.
Please note, there is no requirement to create a new overlay topology Please note, there is no requirement to create a new overlay topology
if a suitable one already existing. NSH packets can use any (new or if a suitable one already existing. NSH packets can use any (new or
existing) overlay provided the requisite connectivity requirements existing) overlay provided the requisite connectivity requirements
are satisfied. are satisfied.
Examples of mapping for a topology: Examples of mapping for a topology:
1. Next SF is located at SFFb with locator 192.0.2.1 1. Next SF is located at SFFb with locator 192.0.2.1
SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 192.0.2.1 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1
2. Next SF is located at SFFc with multiple network locators for 2. Next SF is located at SFFc with multiple network locators for
load distribution purposes: load distribution purposes:
SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1,
203.0.113.2, 203.0.113.3, equal cost 203.0.113.2, 203.0.113.3, equal cost
3. Next SF is located at SFFd with two paths from SFFc, one for 3. Next SF is located at SFFd with two paths from SFFc, one for
redundancy: redundancy:
SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10,
203.0.113.10, cost=20 203.0.113.10, cost=20
skipping to change at page 24, line 6 skipping to change at page 24, line 6
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 Depending on the information carried in the metadata, data privacy
considerations may need to be considered. For example, if the considerations may need to be considered. For example, if the
metadata conveys tenant information, that information may need to be metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only) . NSH intended recipients (which may include intended SFs only) . NSH
itself does not provide privacy functions, rather it relies on the itself does not provide privacy functions, rather it relies on the
transport/overlay layer. An operator can select the appropriate transport/overlay layer. An operator can select the appropriate
transport to ensure the confidentially (and other security) transport to ensure the confidentiality (and other security)
considerations are met. 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
skipping to change at page 27, line 26 skipping to change at page 27, line 26
when required, existing security protocols that provide authenticity when required, existing security protocols that provide authenticity
(e.g. [ [RFC6071]) can be used between SFF or even to SF. Similarly (e.g. [ [RFC6071]) can be used between SFF or even to SF. Similarly
if confidentiality is required, existing encryption protocols can be if confidentiality is required, existing encryption protocols can be
used in conjunction with encapsulated NSH. used in conjunction with encapsulated NSH.
Further, existing best practices, such as [BCP38] should be deployed Further, existing best practices, such as [BCP38] should be deployed
at the network layer to ensure that traffic entering the service path at the network layer to ensure that traffic entering the service path
is indeed "valid". [draft-ietf-rtgwg-dt-encap-01.txt] provides is indeed "valid". [draft-ietf-rtgwg-dt-encap-01.txt] provides
additional transport encapsulation considerations. additional transport encapsulation considerations.
NSH metadata authenticity and confidentially must be considered as NSH metadata authenticity and confidentiality must be considered as
well. In order to protect the metadata, an operator can leverage the well. In order to protect the metadata, an operator can leverage the
aforementioned mechanisms provided the transport layer, authenticity aforementioned mechanisms provided the transport layer, authenticity
and/or confidentiality. An operator MUST carefully select the and/or confidentiality. An operator MUST carefully select the
transport/underlay services to ensure end to end security services, transport/underlay services to ensure end to end security services,
when those are sought after. For example, if RFC6071 is used, the when those are sought after. For example, if RFC6071 is used, the
operator MUST ensure it can be supported by the transport/underlay of operator MUST ensure it can be supported by the transport/underlay of
all relevant network segments as well as SFF and SFs. Further, as all relevant network segments as well as SFF and SFs. Further, as
describe in [section 8.1], operators can and should use indirect described in [section 8.1], operators can and should use indirect
identification for personally identifying information, thus identification for personally identifying information, thus
significantly mitigating the risk of privacy violation. significantly mitigating the risk of privacy violation.
Further, the extensibility of MD-2 to add information to packets, and Further, the extensibility of MD Type 2 to add information to
where needed to mark that data as critical, allows for attaching packets, and where needed to mark that data as critical, allows for
signatures or even encryption keying information to the NSH header in attaching signatures or even encryption keying information to the NSH
the future. Based on the learnings from the work on [nsh-sec], it header in the future. Based on the learnings from the work on [nsh-
appears likely that this can provide any needed NSH-specific security sec], it appears likely that this can provide any needed NSH-specific
mechanisms in the future. security mechanisms in the future.
Lastly, SF security, although out of scope of this document, should Lastly, SF security, although out of scope of this document, should
be considered, particularly if an SF needs to access, authenticate or be considered, particularly if an SF needs to access, authenticate or
update NSH metadata. update NSH metadata.
Further security considerations are discussed in [nsh-sec]. Further security considerations are discussed in [nsh-sec].
10. 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
skipping to change at page 36, line 10 skipping to change at page 36, line 10
[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., [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>. August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[SFC-CP] Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", 2016, <https://
datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/>.
[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. 24 change blocks. 
52 lines changed or deleted 64 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/