draft-ietf-sfc-nsh-08.txt   draft-ietf-sfc-nsh-09.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: March 19, 2017 Intel Expires: March 19, 2017 Intel
September 15, 2016 September 15, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-08.txt draft-ietf-sfc-nsh-09.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 13, line 17 skipping to change at page 13, line 17
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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 bit: one reserved bit is 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 single byte words. In Length: Length of the variable metadata, in single byte words. In
case the metadata length is not an integer number of 4-byte words, case the metadata length is not an integer number of 4-byte words,
the sender MUST add pad bytes immediately following the last metadata the sender MUST add pad bytes immediately following the last metadata
byte to extend the metadata to an integer number of 4-byte words. 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 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. word boundary, to locate and process the next field in the packet.
The receiver MUST access only those bytes in the metadata indicated The receiver MUST access only those bytes in the metadata indicated
by the length field (i.e. actual number of single byte words) and by the length field (i.e. actual number of single byte words) and
skipping to change at page 14, line 34 skipping to change at page 14, line 34
a change of service path, it MUST remove the existing NSH and a change of service path, it MUST remove the existing NSH and
MUST impose a new NSH with the Base Header and Service Path MUST impose a new NSH with the Base Header and Service Path
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 NSH: NSH-aware service functions (SF) MUST decrement the
MUST decrement the service index. If an SFF receives a packet service index. If an SFF receives a packet with an SPI and SI
with an SPI and SI that do not correspond to a valid next hop in that do not correspond to a valid next hop in a valid Service
a valid Service Function Path, that packet MUST be dropped by the Function Path, that packet MUST be dropped by the SFF.
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 17, line 13 skipping to change at page 17, line 13
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 to 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:
As discussed in [draft-ietf-rtgwg-dt-encap-01], within an As discussed in [encap-considerations], within an administrative
administrative domain, an operator can ensure that the underlay MTU domain, an operator can ensure that the underlay MTU is sufficient to
is sufficient to carry SFC traffic without requiring fragmentation. carry SFC traffic without requiring fragmentation.
However, there will be cases where the underlay MTU is not large However, there will be cases where the underlay MTU is not large
enough to carry the NSH traffic. Since NSH does not provide enough to carry the NSH traffic. Since NSH does not provide
fragmentation support at the service plane, the transport/overlay fragmentation support at the service plane, the transport/overlay
layer MUST provide the requisite fragmentation handling. Section 6 layer MUST provide the requisite fragmentation handling. Section 9
of [draft-ietf-rtgwg-dt-encap-01] provides guidance for those of [encap-considerations] provides guidance for those scenarios.
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 20, line 45 skipping to change at page 20, line 45
in a single path, or it might result in a more complex topology. in a single path, or it might result in a more complex topology.
Furthermore, the SPI to overlay mapping occurs at each SFF Furthermore, the SPI to overlay mapping occurs at each SFF
independently. Any combination of topology selection is possible. independently. Any combination of topology selection is possible.
Please note, there is no requirement to create a new overlay topology Please note, there is no requirement to create a new overlay topology
if a suitable one already 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 2001:db8::1
SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::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,
skipping to change at page 27, line 23 skipping to change at page 27, line 23
environments, which are the primary design target of NSH. 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. [ [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". [encap-considerations] provides additional
additional transport encapsulation considerations. transport encapsulation considerations.
NSH metadata authenticity and confidentiality 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
described in [section 8.1], operators can and should use indirect described in [section 8.1], operators can and should use indirect
skipping to change at page 36, line 32 skipping to change at page 36, line 32
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://
datatracker.ietf.org/doc/ datatracker.ietf.org/doc/
draft-napper-sfc-nsh-broadband-allocation/>. draft-napper-sfc-nsh-broadband-allocation/>.
[dcalloc] Guichard, J., Smith, M., and et al., "Network Service [dcalloc] Guichard, J., Smith, M., and et al., "Network Service
Header (NSH) Context Header Allocation (Data Center)", Header (NSH) Context Header Allocation (Data Center)",
2016, <https://datatracker.ietf.org/doc/ 2016, <https://datatracker.ietf.org/doc/
draft-guichard-sfc-nsh-dc-allocation/>. draft-guichard-sfc-nsh-dc-allocation/>.
[encap-considerations]
Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
Considerations", <https://datatracker.ietf.org/doc/
draft-ietf-rtgwg-dt-encap/>.
[nsh-sec] Reddy, T., Migault, D., Pignataro, C., Quinn, P., and C. [nsh-sec] Reddy, T., Migault, D., Pignataro, C., Quinn, P., and C.
Inacio, "NSH Security and Privacy requirements", 2016, <ht Inacio, "NSH Security and Privacy requirements", 2016, <ht
tps://datatracker.ietf.org/doc/ tps://datatracker.ietf.org/doc/
draft-reddy-sfc-nsh-security-req/>. draft-reddy-sfc-nsh-security-req/>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 8 change blocks. 
16 lines changed or deleted 20 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/