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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/