IPFIX Information Element extension for SFC

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 , a classifier will add Network Service Header (NSH) to a packet that defines the corresponding service path to follow. This document defines the required Information Elements to represent the details about traffic flows over any Service Function Path and export to Collector.

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 .

This document uses the terminologies defined in and . In addition, this document defines the below terminologies: Service Flow A Service Flow is defined as a set of packets over a specific Service Function Path.

Section 3.1 of 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. In order to accomodate different needs from different use cases, there are 2 types of Network Service Header defined in 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:

The details about different header fields are detailed in Section 3.4 and 3.5 of .

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: Capacity Planning - To ensure distributing load between Service Functions. OAM and troubleshooting - To measure the performance and troubleshooting failures. Traffic Profiling - Determine the characteristics of traffic flow over SFP. Security - To identify DoS attack or malicious intrusion. 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.

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: Forwards NSH encapsulated packets or frame from Classifier to SFF. Receives NSH encapsulated packets or frame from Classifier or previous SFF. Receives NSH encapsulated packets or frame from Service Function after packet treatment applied. Forwards NSH encapsulated packets or frame to next Service Function Forwarder. Forwards NSH encapsulated packets or frame to Service Function for packet treatment.

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.

This document defines the below set of Information Elements that are necessary for enabling IPFIX traffic measurement for Service Flow:

Description: The Version field in NSH header. Abstract Data Type: unsigned8 Element ID: TBD1 Data Type Semantic: identifier Range: The valid range is 0-3. Reference: See Section 3.2 of

Description: The flag bits from bit position 2 to 9 in NSH Base header. This information is encoded as a bit field. Abstract Data Type: unsigned8 Element ID: TBD2 Data Type Semantic: flags Reference: See Section 3.2 of

Description: The length of the NSH header including any optional variable TLVs. Abstract Data Type: unsigned8 Element ID: TBD3 Range: The valid range is 0-255. Reference: See Section 3.2 of

Description: Defines the Metadata format beyond the NSH Base header. Abstract Data Type: unsigned8 Element ID: TBD4 Data Type Semantic: identifier Reference: See Section 3.2 of

Description: This indicates the type of the payload packet encapsulated within the NSH header. Abstract Data Type: unsigned8 Element ID: TBD5 Data Type Semantic: identifier Reference: See Section 3.2 of

Description: Service Path ID uniquely identifies the Service Chain which is a sequence of service function to be applied on the payload packet. Abstract Data Type: unsigned32 Element ID: TBD6 Data Type Semantic: identifier Reference: See Section 3.3 of

Description: Service Index identifies the next service function to be applied in the service chain. Abstract Data Type: unsigned8 Element ID: TBD7 Range : The valid range is between 0-255. Reference: See Section 3.3 of

Description: 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. Abstract Data Type: OctetArray Element ID: TBD8 Reference: See Section 3.4 of

Description: 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. A value of 64 reduced from nshBaseHeaderLength expresses how much Metadata was observed, while the remainder is padding. Abstract Data Type: OctetArray Element ID: TBD9 Reference: See Section 3.5 of

Description: This defines the IPv4 address of the next SFF in the Service Function Path. This Information element is of size 4 bytes. Abstract Data Type: ipv4Address Element ID: TBD10 Data Type Semantic: identifier Reference: See Section 7.1 of

Description: This defines the IPv6 address of the next SFF in the Service Function Path. This Information element is of size 16 bytes. Abstract Data Type: ipv6Address Element ID: TBD11 Data Type Semantic: identifier Reference: See Section 7.1 of

Description: This defines the Ethernet Address of the next SFF in the Service Function Path. This Information element is of size 16 bytes. Abstract Data Type: macAddress Element ID: TBD12 Data Type Semantic: identifier Reference: See Section 7.1 of

To be Updated.

TBD

The authors would like to thank Jim Guichard, Stewart Bryant, Benoit Claise, Richard Furr and Joel M. Harpern for their contribution.

TBD