draft-ietf-sfc-nsh-14.txt   draft-ietf-sfc-nsh-15.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 17, 2018 Intel Expires: January 19, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
July 16, 2017 July 18, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-14 draft-ietf-sfc-nsh-15
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 17, 2018. This Internet-Draft will expire on January 19, 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 22 skipping to change at page 2, line 22
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 4
1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5 1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5
2. Network Service Header . . . . . . . . . . . . . . . . . . . 5 2. Network Service Header . . . . . . . . . . . . . . . . . . . 5
2.1. Network Service Header Format . . . . . . . . . . . . . . 6 2.1. Network Service Header Format . . . . . . . . . . . . . . 6
2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 6 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 6
2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9
2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 10 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 10
2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 11 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1. Optional Variable Length Metadata . . . . . . . . . . 11 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 11
3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 14 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 14
5. Fragmentation Considerations . . . . . . . . . . . . . . . . 15 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 15
6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 15 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 15
6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 15 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 15
6.2. Mapping NSH to Network Transport . . . . . . . . . . . . 18 6.2. Mapping NSH to Network Transport . . . . . . . . . . . . 18
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 19 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 19
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 19 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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. if it requires access to the original packet/frame. This
specification does not disallow the MD Type value from changing along
an SFP; however, the specification of the necessary mechanism to
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
be available.
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: Reserved 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
An implementation not explicitly configured for a specific experiment Packets with Next Protocol values not supported by an implementation
[RFC3692] SHOULD NOT attempt to process Next Protocol values 0xFE and SHOULD be silently dropped. Additionally, an implementation not
0xFF. 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 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 |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| 0 | Reserved | This document | | 0x0 | Unassigned | This document |
| | | | | | | |
| 1 | IPv4 | This document | | 0x1 | IPv4 | This document |
| | | | | | | |
| 2 | IPv6 | This document | | 0x2 | IPv6 | This document |
| | | | | | | |
| 3 | Ethernet | This document | | 0x3 | Ethernet | This document |
| | | | | | | |
| 4 | NSH | This document | | 0x4 | NSH | This document |
| | | | | | | |
| 5 | MPLS | This document | | 0x5 | MPLS | This document |
| | | | | | | |
| 6..253 | Unassigned | | | 0x6..0xFD | Unassigned | |
| | | | | | | |
| 254 | Experiment 1 | This document | | 0xFE | Experiment 1 | This document |
| | | | | | | |
| 255 | Experiment 2 | This document | | 0xFF | Experiment 2 | This document |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
Table 7: NSH Base Header Next Protocol Values Table 7: NSH Base Header Next Protocol Values
11.2.6. New IETF assigned MD Type Registry 11.2.6. New IETF assigned MD Type Registry
This document requests IANA to create a registry for the type values This document requests IANA to create a registry for the type values
owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF
Assigned MD Type Registry." Assigned MD Type Registry."
 End of changes. 17 change blocks. 
19 lines changed or deleted 25 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/