One document matched: draft-kumar-ipfix-sfc-extension-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category='std' ipr='trust200902' docName='draft-kumar-ipfix-sfc-extension-03'>
<front>
<title abbrev="">IPFIX Information Element extension for SFC</title>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="P." surname="Quinn" fullname="Paul Quinn">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city> <region>CA</region> <code></code>
<country>US</country>
</postal>
<email>paulq@cisco.com</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>Network Work group</workgroup>
<keyword>sfc</keyword>
<abstract><t>Service Function Chaining (SFC) is an architecture that enables
any operator to apply selective set of services by steering the
traffic through an ordered set of service functions without any
topology dependency.</t>
<t>This document defines the required Information Elements
to represent the details about service flows over any Service Function
Path.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC7665" /> introduces and explains
SFC architecture that enables any operator to apply selective set
of services by steering the traffic through an ordered set of service
functions without any topology dependency. Such ordered set of
service functions to be applied to a packet is defined as service
function chaining. As defined in <xref target="I-D.ietf-sfc-nsh" />,
a classifier will add Network Service Header (NSH) to a packet that
defines the corresponding service path to follow.
</t>
<t>This document defines the required Information
Elements to represent the details about traffic flows over any
Service Function Path and export to Collector. </t>
</section>
<section title="Requirements notation">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>This document uses the terminologies defined in
<xref target="RFC7665" /> and
<xref target="RFC7011" />
<xref target="RFC1112" />
<xref target="RFC2236" />
<xref target="RFC3376" />
<xref target="RFC4604" />
<xref target="RFC2710" />
<xref target="RFC3810" />
<xref target="RFC7063" />
<xref target="RFC5110" />
<xref target="RFC6388" />
<xref target="RFC4875" />
<xref target="RFC6513" />
<xref target="RFC7348" />
<xref target="RFC7637" />
<xref target="RFC7432" />
<xref target="I-D.ietf-bier-ospf-bier-extensions" />
<xref target="I-D.ietf-bier-isis-extensions" />
<xref target="I-D.ietf-bier-mpls-encapsulation" />
<xref target="I-D.ietf-bier-mvpn" />
<xref target="I-D.anish-bier-overlay-pim" />
<xref target="I-D.chen-bier-pce-bier" />
<xref target="I-D.ietf-sfc-nsh" />
<xref target="I-D.ietf-sfc-nsh" />
. In addition,
this document defines the below terminologies:
</t>
<t>Service Flow
<list><t>A Service Flow is defined as a set of packets
over a specific Service Function Path.</t>
</list>
</t>
</section>
<section title="Network Service Header">
<t>Section 3.1 of <xref target="I-D.ietf-sfc-nsh" /> defines the Network Service Header
format used by the classifier to encapsulate the traffic, carrying instruction about
the service functions to be applied to the packet. This header comprises a 4 byte base header
followed by a 4 byte service path header and a variable size context header.
</t>
<t>In order to accomodate different needs from different use cases, there are 2 types of
Network Service Header defined in <xref target="I-D.ietf-sfc-nsh" /> that
preserves same Base header and Service Path header while differs in Context header. NSH
MD-type 1 have a fixed size Mandatory Context header while NSH MD-type 2 have a variable
size TLV based context header. The details are below:
</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NSH MD-type 1
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional Variable Length Context Headers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH MD-type 2
]]></artwork>
</figure>
<t>The details about different header fields are detailed in Section 3.4 and 3.5 of
<xref target="I-D.ietf-sfc-nsh" />.
</t>
</section>
<section title="Flow measurement in SFC environment">
<t>SFC introduces the concept of steering user traffic over an ordered set of
service function by utilizing service overlay between service functions over
the existing network topology. The measurement of Service flow over Service
Function Chain are required for various application such as but not limited to
below:
<list style="symbols">
<t>Capacity Planning - To ensure distributing load between Service Functions.</t>
<t>OAM and troubleshooting - To measure the performance and troubleshooting failures.</t>
<t>Traffic Profiling - Determine the characteristics of traffic flow over SFP.</t>
<t>Security - To identify DoS attack or malicious intrusion.</t>
</list>
</t>
<t>In SFC environment, Classifier and Service Function Forwarder (SFF) are the
different nodes that handles SFC encapsulation and it is appropriate to collect
the Service Flow records in these nodes.
</t>
<section title="Observation Point">
<t>An Observation point in SFC environment is where Flow record for Service Flow will
be collected and exported to the Collector. In a Classifier or SFF, an Observation
point can be any physical or logical port that:
<list style="symbols">
<t>Forwards NSH encapsulated packets or frame from Classifier to SFF.</t>
<t>Receives NSH encapsulated packets or frame from Classifier or previous SFF.</t>
<t>Receives NSH encapsulated packets or frame from Service Function after packet treatment applied.</t>
<t>Forwards NSH encapsulated packets or frame to next Service Function Forwarder.</t>
<t>Forwards NSH encapsulated packets or frame to Service Function for packet treatment.</t>
</list>
</t>
</section>
<section title="Flow measurement">
<t>The ability to collect Flow record for different flows observed at the above range
of Observation point allows an Operator to measure flow properties before and after
the application of any service function within a service function path. An
implementation SHOULD support the use of Information Elements defined in section 6 to
measure and export the flow information. In addition, it also
MAY support the use of other Flow keys relevant to the underlay network to
collect any additional information from transport header encapsulating NSH header. </t>
</section>
</section>
<section title="Service Flow Information Elements">
<t>This document defines the below set of Information Elements that are
necessary for enabling IPFIX traffic measurement for Service Flow:
</t>
<figure>
<artwork><![CDATA[
+---------+------------------------------------------+
| ID | Name |
+---------+------------------------------------------+
| TBD1 | nshBaseVersion |
| TBD2 | nshBaseFlags |
| TBD3 | nshBaseHeaderLength |
| TBD4 | nshBaseMDType |
| TBD5 | nshBaseNextProtocol |
| TBD6 | nshSphServicePathID |
| TBD7 | nshSphServiceIndex |
| TBD8 | nshMetadataMch |
| TBD9 | nshMetadataVch |
| TBD10 | nshIPv4NextSFF |
| TBD11 | nshIPv6NextSFF |
| TBD12 | nshEtherNextSFF |
+---------+------------------------------------------+
]]></artwork>
</figure>
<section title="nshBaseVersion">
<t>Description:
<list><t>The Version field in NSH header.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD1
</t>
<t>Data Type Semantic: identifier
</t>
<t>Range: The valid range is 0-3.
</t>
<t>Reference:
<list><t>See Section 3.2 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshBaseFlags">
<t>Description:
<list><t>The flag bits from bit position 2 to 9 in NSH Base header.
This information is encoded as a bit field.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD2
</t>
<t>Data Type Semantic: flags
</t>
<t>Reference:
<list><t>See Section 3.2 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshBaseHeaderLength">
<t>Description:
<list><t>The length of the NSH header including any optional
variable TLVs.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD3
</t>
<t>Range: The valid range is 0-255.
</t>
<t>Reference:
<list><t>See Section 3.2 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshBaseMDType">
<t>Description:
<list><t>Defines the Metadata format beyond the NSH Base header.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD4
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 3.2 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshBaseNextProtocol">
<t>Description:
<list><t>This indicates the type of the payload packet encapsulated
within the NSH header.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD5
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 3.2 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshSphServicePathID">
<t>Description:
<list><t>Service Path ID uniquely identifies the Service Chain which is a
sequence of service function to be applied on the payload packet.
</t>
</list>
</t>
<t>Abstract Data Type: unsigned32
</t>
<t>Element ID: TBD6
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 3.3 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshSphServiceIndex">
<t>Description:
<list><t>Service Index identifies the next service function to be
applied in the service chain.
</t>
</list>
</t>
<t>Abstract Data Type: unsigned8
</t>
<t>Element ID: TBD7
</t>
<t>Range : The valid range is between 0-255.
</t>
<t>Reference:
<list><t>See Section 3.3 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshMetadataMch">
<t>Description:
<list><t>When MD Type is 1 on NSH header, Service Base header is followed
by fixed size Mandatory Context Header. The format of this header varies
depending on the implementation. This information element is of 16 bytes size.
</t>
</list>
</t>
<t>Abstract Data Type: OctetArray
</t>
<t>Element ID: TBD8
</t>
<t>Reference:
<list><t>See Section 3.4 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshMetadataVch">
<t>Description:
<list><t>When MD Type is 2 on NSH header, Service Base header is followed
by Variable size Context Header. The format of this header varies
depending on the implementation. This Informational element carries n octets
from the NSH Service Path header.
</t>
<t>A value of 64 reduced from nshBaseHeaderLength expresses how much Metadata
was observed, while the remainder is padding.
</t>
</list>
</t>
<t>Abstract Data Type: OctetArray
</t>
<t>Element ID: TBD9
</t>
<t>Reference:
<list><t>See Section 3.5 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshIPv4NextSFF">
<t>Description:
<list><t>This defines the IPv4 address of the next SFF in the Service Function
Path. This Information element is of size 4 bytes.
</t>
</list>
</t>
<t>Abstract Data Type: ipv4Address
</t>
<t>Element ID: TBD10
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 7.1 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshIPv6NextSFF">
<t>Description:
<list><t>This defines the IPv6 address of the next SFF in the Service Function
Path. This Information element is of size 16 bytes.
</t>
</list>
</t>
<t>Abstract Data Type: ipv6Address
</t>
<t>Element ID: TBD11
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 7.1 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
<section title="nshEtherNextSFF">
<t>Description:
<list><t>This defines the Ethernet Address of the next SFF in the Service Function
Path. This Information element is of size 16 bytes.
</t>
</list>
</t>
<t>Abstract Data Type: macAddress
</t>
<t>Element ID: TBD12
</t>
<t>Data Type Semantic: identifier
</t>
<t>Reference:
<list><t>See Section 7.1 of <xref target="I-D.ietf-sfc-nsh" /></t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations">
<t>To be Updated.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgement">
<t> The authors would like to thank Jim Guichard, Stewart Bryant, Benoit Claise,
Richard Furr and Joel M. Harpern for their contribution.
</t>
</section>
<section title="Contributing Authors">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.RFC.7011"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7665"?>
<?rfc include="reference.RFC.7012"?>
<?rfc include="reference.RFC.7013"?>
<?rfc include="reference.RFC.1112"?>
<?rfc include="reference.RFC.2236"?>
<?rfc include="reference.RFC.3376"?>
<?rfc include="reference.RFC.4604"?>
<?rfc include="reference.RFC.2710"?>
<?rfc include="reference.RFC.3810"?>
<?rfc include="reference.RFC.7063"?>
<?rfc include="reference.RFC.5110"?>
<?rfc include="reference.RFC.6388"?>
<?rfc include="reference.RFC.4875"?>
<?rfc include="reference.RFC.6513"?>
<?rfc include="reference.RFC.7348"?>
<?rfc include="reference.RFC.7637"?>
<?rfc include="reference.RFC.7432"?>
<?rfc include="reference.I-D.ietf-bier-ospf-bier-extensions"?>
<?rfc include="reference.I-D.ietf-bier-isis-extensions"?>
<?rfc include="reference.I-D.ietf-bier-mpls-encapsulation"?>
<?rfc include="reference.I-D.ietf-bier-mvpn"?>
<?rfc include="reference.I-D.anish-bier-overlay-pim"?>
<?rfc include="reference.I-D.chen-bier-pce-bier"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:29:44 |