draft-ietf-sfc-nsh-03.txt   draft-ietf-sfc-nsh-04.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: September 22, 2016 Intel Expires: September 22, 2016 Intel
March 21, 2016 March 21, 2016
Network Service Header Network Service Header
draft-ietf-sfc-nsh-03.txt draft-ietf-sfc-nsh-04.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 12, line 9 skipping to change at page 12, line 9
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, and may contain optional variable length context Service Path Header, and 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- Type = 0x2. MD- Type = 0x2. There exists, however, a middle ground, wherein a
device will support MD-Type 1 (as per the MUST) metadata, yet
participate in the a network with MD-Type 2 metadata packets. In
that case, the type-1 node, MUST utilize the base header length field
to determine the original payload offset if it requires access to the
original packet/frame.
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
0xFE-0xFF: Experimental 0xFE-0xFF: Experimental
 End of changes. 2 change blocks. 
2 lines changed or deleted 7 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/