< draft-ietf-sfc-nsh-11.txt		draft-ietf-sfc-nsh-12.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: August 16, 2017 Intel		Expires: August 27, 2017 Intel
	February 12, 2017		February 23, 2017
	Network Service Header		Network Service Header
	draft-ietf-sfc-nsh-11.txt		draft-ietf-sfc-nsh-12.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 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 August 16, 2017.		This Internet-Draft will expire on August 27, 2017.
	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 14, line 5 ¶		skipping to change at page 13, line 34 ¶
	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
	MUST ignore the remaining bytes up to the nearest 4-byte word		MUST ignore the remaining bytes up to the nearest 4-byte word
	boundary. The Length may be 0 or greater.		boundary. The Length may be 0 or greater.
	A value of 0x0 denotes a TLV header without a Variable Metadata		A value of 0x0 denotes a TLV header without a Variable Metadata
	field.		field.
			This specification does not make any assumption about TLVs that are
			mandatory-to-implement or those that are mandatory-to-process. These
			considerations are deployment-specific. However, the control plane
			is entitled to instruct SFC-aware SFs with the data structure of TLVs
			together with their scoping (see Section 3.3.3 of [SFC-CP]).
			If multiple mandatory-to-process TLVs are required for a given SFP,
			the control plane MAY instruct the SFC-aware SF with the order to
			consume these TLVs. If no instructions are provided, the SFC-aware
			SF MUST process these TLVs in the order their appear in the NSH
			packet.
			If multiple instances of the same TLV are included in an NSH packet,
			but the definition of that TLV does not allow for it, the SFC-aware
			SF MUST NOT process the packet and MUST log at least once per the SPI
			for which multiple instances of that TLV is supplied.
	4. NSH Actions		4. NSH Actions
	NSH-aware nodes are the only nodes that MAY alter the content of the		NSH-aware nodes are the only nodes that MAY alter the content of the
	NSH headers. NSH-aware nodes include: service classifiers, SFF, SF		NSH headers. NSH-aware nodes include: service classifiers, SFF, SF
	and SFC proxies. These nodes have several possible header related		and SFC proxies. These nodes have several possible header related
	actions:		actions:
	1. Insert or remove NSH: These actions can occur at the start and		1. Insert or remove NSH: These actions can occur at the start and
	end respectively of a service path. Packets are classified, and		end respectively of a service path. Packets are classified, and
	if determined to require servicing, NSH will be imposed. A		if determined to require servicing, NSH will be imposed. A
End of changes. 4 change blocks.
	4 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/