draft-ietf-sfc-nsh-02.txt   draft-ietf-sfc-nsh-03.txt 
Network Working Group P. Quinn, Ed. Network Working Group 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: July 22, 2016 Intel Expires: September 22, 2016 Intel
January 19, 2016 March 21, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-02.txt draft-ietf-sfc-nsh-03.txt
Abstract Abstract
This draft describes a Network Service Header (NSH) inserted onto This draft describes a Network Service Header (NSH) inserted onto
encapsulated packets or frames to realize service function paths. encapsulated packets or frames to realize service function paths.
NSH also provides a mechanism for metadata exchange along the NSH also provides a mechanism for metadata exchange along the
instantiated service path. NSH is the SFC encapsulation as per SFC instantiated service path. NSH is the SFC encapsulation as per SFC
Architecture [SFC-arch] Architecture [SFC-arch]
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 July 22, 2016. This Internet-Draft will expire on September 22, 2016.
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 11, line 34 skipping to change at page 11, line 34
to 0x0 when MD Type= 0x1 and MAY be used with MD Type = 0x2 and MUST to 0x0 when MD Type= 0x1 and MAY be used with MD Type = 0x2 and MUST
be set to 0x1 if one or more critical TLVs are present. be set to 0x1 if one or more critical TLVs are present.
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 and MUST be ignored upon receipt. MUST be set to zero and MUST be ignored upon receipt.
Length: total length, in 4-byte words, of NSH including the Base Length: total length, in 4-byte words, of NSH including the Base
Header, the Service Path Header and the optional variable TLVs. The Header, the Service Path Header and the optional variable TLVs. The
Length MUST be of value 0x6 for MD Type = 0x1 and MUST be of value Length MUST be of value 0x6 for MD Type = 0x1 and MUST be of value
0x2 or higher for MD Type = 0x2. The NSH header length MUST be an 0x2 or higher for MD Type = 0x2. The NSH header length MUST be an
integer number of 4 bytes. integer number of 4 bytes. The length field MUST be used to
determine the "end" of NSH and where the original packet/frame
begins.
MD Type: indicates the format of NSH beyond the mandatory Base Header MD Type: indicates the format of NSH beyond the mandatory Base Header
and the Service Path Header. MD Type defines the format of the and the Service Path Header. MD Type defines the format of the
metadata being carried. A new registry will be requested from IANA metadata being carried. A new registry will be requested from IANA
for the MD Type. for the MD Type.
NSH defines two MD types: NSH defines two MD types:
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).
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Draft-dc [dcalloc] and draft-mobility [moballoc] provide specific Draft-dc [dcalloc] and draft-mobility [moballoc] provide specific
examples of how metadata can be allocated. examples of how metadata 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. 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
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 ID | Service Index | | Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Variable Length Context Headers (opt.) ~ ~ Variable Length Context Headers (opt.) ~
| | | |
skipping to change at page 19, line 7 skipping to change at page 19, line 7
The service header is independent of the encapsulation used and is The service header is independent of the encapsulation used and is
encapsulated in existing transports. The presence of NSH is encapsulated in existing transports. The presence of 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
Work in progress: discussion of jumbo frames and PMTUD implications. NSH and the associated transport header are "added" to the
encapsulated packet/frame. This additional information increases the
size of the packet. In order the ensure proper forwarding of NSH
data, several options for handling fragmentation and re-assembly
exist:
1. Jumbo Frames, when supported, enable the transport of NSH and
associated transport packets without requiring fragmentation.
2. Path MTU Discovery [RFC1191]"describes a technique for
dynamically discovering the maximum transmission unit (MTU) of an
arbitrary internet path" and can be utilized to ensure the the
required packet size is used.
3. [RFC6830] describes two schemes for fragmentation and re-assembly
in section 5.4.
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
requirement, or expectation of an SPI being bound to a pre-determined requirement, or expectation of an SPI being bound to a pre-determined
or static network path. or static network path.
The Service Index provides an indication of location within a service The Service Index provides an indication of location within a service
path. The combination of SPI and SI provides the identification of a path. The combination of SPI and SI provides the identification of a
logical SF and its order within the service plane, and is used to logical SF and its order within the service plane, and is used to
select the appropriate network locator(s) for overlay forwarding. select the appropriate network locator(s) for overlay forwarding.
The logical SF may be a single SF, or a set of eligible SFs that are The logical SF may be a single SF, or a set of eligible SFs that are
equivalent. In the latter case, the SFF provides load distribution equivalent. In the latter case, the SFF provides load distribution
amongst the collection of SFs as needed. SI may also serve as a amongst the collection of SFs as needed.
mechanism for loop detection within a service path since each SF in
the path decrements the index; an Service Index of 0 indicates that a SI may also serve as a mechanism for loop detection within a service
loop occurred and packet must be discarded. path since each SF in the path decrements the index; an Service Index
of 0 indicates that a loop occurred and packet must be discarded.
This indirection -- path ID to overlay -- creates a true service This indirection -- path ID to overlay -- creates a true service
plane. That is the SFF/SF topology is constructed without impacting plane. That is the SFF/SF topology is constructed without impacting
the network topology but more importantly service plane only the network topology but more importantly service plane only
participants (i.e. most SFs) need not be part of the network overlay participants (i.e. most SFs) need not be part of the network overlay
topology and its associated infrastructure (e.g. control plane, topology and its associated infrastructure (e.g. control plane,
routing tables, etc.). As mentioned above, an existing overlay routing tables, etc.). As mentioned above, an existing overlay
topology may be used provided it offers the requisite connectivity. topology may be used provided it offers the requisite connectivity.
The mapping of SPI to transport occurs on an SFF (as discussed above, The mapping of SPI to transport occurs on an SFF (as discussed above,
skipping to change at page 34, line 5 skipping to change at page 33, line 19
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.
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. RFC 2119 [RFC6071]) can be used.
Similarly if confidentiality is required, existing encryption Similarly if confidentiality is required, existing encryption
protocols can be used in conjunction with encapsulated NSH. protocols can be used in conjunction with encapsulated NSH.
Further security considerations are discussed in [nsh-sec].
11. Open Items for WG Discussion 11. Open Items for WG Discussion
1. MD type 1 metadata semantics specifics 1. MD type 1 metadata semantics specifics
2. Bypass bit in NSH. 2. Bypass bit in NSH.
3. Rendered Service Path ID (RSPID). 3. Rendered Service Path ID (RSPID).
12. Contributors 12. Contributors
skipping to change at page 41, line 20 skipping to change at page 41, line 20
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[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>.
15.2. Informative References 15.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <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
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[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>.
[SFC-arch] [SFC-arch]
Quinn, P., Ed. and J. Halpern, Ed., "Service Function Quinn, P., Ed. and J. Halpern, Ed., "Service Function
Chaining (SFC) Architecture", 2014, Chaining (SFC) Architecture", 2014,
<http://datatracker.ietf.org/doc/draft-quinn-sfc-arch>. <http://datatracker.ietf.org/doc/draft-quinn-sfc-arch>.
skipping to change at page 43, line 5 skipping to change at page 42, line 22
[dcalloc] Guichard, J., Smith, M., and S. Kumar, "Network Service [dcalloc] Guichard, J., Smith, M., and S. Kumar, "Network Service
Header (NSH) Context Header Allocation (Data Center)", Header (NSH) Context Header Allocation (Data Center)",
2014, <https://datatracker.ietf.org/doc/ 2014, <https://datatracker.ietf.org/doc/
draft-guichard-sfc-nsh-dc-allocation/>. draft-guichard-sfc-nsh-dc-allocation/>.
[moballoc] [moballoc]
Napper, J. and S. Kumar, "NSH Context Header Allocation -- Napper, J. and S. Kumar, "NSH Context Header Allocation --
Mobility", 2014, <https://datatracker.ietf.org/doc/ Mobility", 2014, <https://datatracker.ietf.org/doc/
draft-napper-sfc-nsh-mobility-allocation/>. draft-napper-sfc-nsh-mobility-allocation/>.
[nsh-sec] Reddy, T., Migault, D., Pignataro, C., Quinn, P., and C.
Inacio, "NSH Security and Privacy requirements", 2016, <ht
tps://datatracker.ietf.org/doc/
draft-reddy-sfc-nsh-security-req/>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: paulq@cisco.com Email: paulq@cisco.com
Uri Elzur (editor) Uri Elzur (editor)
Intel Intel
 End of changes. 11 change blocks. 
11 lines changed or deleted 47 lines changed or added

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