draft-ietf-sfc-nsh-01.txt   draft-ietf-sfc-nsh-02.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: January 24, 2016 Intel Expires: July 22, 2016 Intel
July 23, 2015 January 19, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-01.txt draft-ietf-sfc-nsh-02.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 January 24, 2016. This Internet-Draft will expire on July 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 30 skipping to change at page 6, line 30
Network Overlay: Logical network built on top of existing network Network Overlay: Logical network built on top of existing network
(the underlay). Packets are encapsulated or tunneled to create (the underlay). Packets are encapsulated or tunneled to create
the overlay network topology. the overlay network topology.
Network Service Header: provides SFP identification, and is used by Network Service Header: provides SFP identification, and is used by
the NSH-aware functions, such as the Classifier, SFF and NSH-aware the NSH-aware functions, such as the Classifier, SFF and NSH-aware
SFs. In addition to SFP identification, the NSH may carry data SFs. In addition to SFP identification, the NSH may carry data
plane metadata. plane metadata.
Service Classifier: Logical function that performs classification Service Classifier: Logical entity providing classification
and imposes an NSH. The initial classifier imposes the initial function. Since they are logical, classifiers may be co-resident
NSH and sends the NSH packet to the first SFF in the path. Non- with SFC elements such as SFs or SFFs. Service classifiers
initial (i.e. subsequent) classification can occur as needed and perform classification and impose NSH. The initial classifier
can alter, or create a new service path. imposes the initial NSH and sends the NSH packet to the first SFF
in the path. Non-initial (i.e. subsequent) classification can
occur as needed and can alter, or create a new service path.
Network Locator: dataplane address, typically IPv4 or IPv6, used to Network Locator: dataplane address, typically IPv4 or IPv6, used to
send and receive network traffic. send and receive network traffic.
NSH Proxy: Removes and inserts NSH on behalf of an NSH-unaware NSH Proxy: Removes and inserts NSH on behalf of an NSH-unaware
service function. The proxy node removes the NSH header and service function. The proxy node removes the NSH header and
delivers the original packet/frame via a local attachment circuit delivers the original packet/frame via a local attachment circuit
to the service function. Examples of a local attachment circuit to the service function. Examples of a local attachment circuit
include, but are not limited to: VLANs, IP in IP, GRE, VXLAN. include, but are not limited to: VLANs, IP in IP, GRE, VXLAN.
When complete, the Service Function returns the packet to the NSH When complete, the Service Function returns the packet to the NSH
skipping to change at page 11, line 24 skipping to change at page 11, line 24
examine the payload and take appropriate action (e.g. return status examine the payload and take appropriate action (e.g. return status
information). information).
OAM message specifics and handling details are outside the scope of OAM message specifics and handling details are outside the scope of
this document. this document.
C bit: Indicates that a critical metadata TLV is present (see Section C bit: Indicates that a critical metadata TLV is present (see Section
3.4.2). This bit acts as an indication for hardware implementers to 3.4.2). This bit acts as an indication for hardware implementers to
decide how to handle the presence of a critical TLV without decide how to handle the presence of a critical TLV without
necessarily needing to parse all TLVs present. The C bit MUST be set necessarily needing to parse all TLVs present. The C bit MUST be set
to 0x0 when MD Type= 0x01 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. All other flag fields are reserved for future use. Reserved bits
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.
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
skipping to change at page 12, line 16 skipping to change at page 12, line 16
MD- Type = 0x2. MD- Type = 0x2.
Next Protocol: indicates the protocol type of the original packet. A Next Protocol: indicates the protocol type of the original packet. A
new IANA registry will be created for protocol type. new IANA registry will be created for protocol type.
This draft defines the following Next Protocol values: This draft defines the following Next Protocol values:
0x1 : IPv4 0x1 : IPv4
0x2 : IPv6 0x2 : IPv6
0x3 : Ethernet 0x3 : Ethernet
0x253: Experimental 0xFE-0xFF: Experimental
3.3. Service Path Header 3.3. Service Path Header
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 ID | Service Index | | Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service path ID (SPI): 24 bits Service path ID (SPI): 24 bits
Service index (SI): 8 bits Service index (SI): 8 bits
skipping to change at page 16, line 26 skipping to change at page 16, line 26
imposed NSH MUST contain valid Base Header and Service Path imposed NSH MUST contain valid Base Header and Service Path
Header. At the end of a service function path, a SFF, MUST be Header. At the end of a service function path, a SFF, MUST be
the last node operating on the service header and MUST remove it. the last node operating on the service header and MUST remove it.
Multiple logical classifiers may exist within a given service Multiple logical classifiers may exist within a given service
path. Non-initial classifiers may re-classify data and that re- path. Non-initial classifiers may re-classify data and that re-
classification MAY result in a new Service Function Path. When classification MAY result in a new Service Function Path. When
the logical classifier performs re-classification that results in the logical classifier performs re-classification that results in
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 SI Header reflecting the new service path information and set the
to 255. 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. A service index = 0x0 MUST decrement the service index. A service index = 0x0
indicates that a packet MUST be dropped by the SFF. indicates that a packet MUST be dropped by the SFF.
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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 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. SI may also serve as a
mechanism for loop detection within a service path since each SF in 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 the path decrements the index; an Service Index of 0 indicates that a
loop occurred and packet must be discarded. 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
skipping to change at page 22, line 33 skipping to change at page 22, line 33
| | | 10.3.3.3 | 5 | | | | 10.3.3.3 | 5 |
+----------------------------------+ +----------------------------------+
(encap type omitted for formatting) (encap type omitted for formatting)
Figure 12: NSH Weighted Service Path Figure 12: NSH Weighted Service Path
7.2. Mapping NSH to Network Overlay 7.2. Mapping NSH to Network Overlay
As described above, the mapping of SPI to network topology may result As described above, the mapping of SPI to network topology may result
in a single overlay path, or it might result in a more complex in a single overlay path, or it might result in a more complex
topology. Furthermore, the SPIx to overlay mapping occurs at each topology. Furthermore, the SPI to overlay mapping occurs at each SFF
SFF independently. Any combination of topology selection is independently. Any combination of topology selection is possible.
possible. Please note, there is no requirement to create a new Please note, there is no requirement to create a new overlay topology
overlay topology if a suitable one already existing. NSH packets can if a suitable one already existing. NSH packets can use any (new or
use any (new or existing) overlay provided the requisite connectivity existing) overlay provided the requisite connectivity requirements
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 10.1.1.1 1. Next SF is located at SFFb with locator 10.1.1.1
SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 10.1.1.1 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 10.1.1.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:10.2.2.1, 10.2.2.2, SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:10.2.2.1, 10.2.2.2,
10.2.2.3, equal cost 10.2.2.3, equal cost
skipping to change at page 40, line 17 skipping to change at page 40, line 17
IANA is requested to set up a registry of "TLV Types". These are 16- IANA is requested to set up a registry of "TLV Types". These are 16-
bit values. Registry entries are assigned by using the "IETF Review" bit values. Registry entries are assigned by using the "IETF Review"
policy defined in RFC 5226 [RFC5226]. policy defined in RFC 5226 [RFC5226].
14.2.4. NSH Base Header Next Protocol 14.2.4. 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 and 3 are defined in this 8-bit values. Next Protocol values 0, 1, 2 and 3 are defined in this
draft. New values are assigned via Standards Action [RFC5226]. draft. New values are assigned via Standards Action [RFC5226].
+---------------+-------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+-------------+---------------+ +---------------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| | | | | | | |
| 1 | IPv4 | This document | | 1 | IPv4 | This document |
| | | | | | | |
| 2 | IPv6 | This document | | 2 | IPv6 | This document |
| | | | | | | |
| 3 | Ethernet | This document | | 3 | Ethernet | This document |
| | | | | | | |
| 4..253 | Unassigned | | | 4..253 | Unassigned | |
+---------------+-------------+---------------+ | | | |
| 254 | Experiment 1 | This document |
| | | |
| 255 | Experiment 2 | This document |
+---------------+--------------+---------------+
Table 2 Table 2
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
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>.
 End of changes. 12 change blocks. 
35 lines changed or deleted 42 lines changed or added

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