IPv6 Encapsulation for SFC
and IFITHuawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinapengshuping@huawei.comLG U+71, Magokjungang 8-ro, Gangseo-guSeoulRepublic of Koreasoho8416@lguplus.co.krService Function Chaining (SFC) and In-situ Flow Information
Telemetry (IFIT) are important path services along with the packets. In
order to support these services, several encapsulations have been
defined. The document analyzes the problems of these encapsulations in
the IPv6 scenario and proposes the possible optimized encapsulation for
IPv6.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 RFC 2119.Service Function Chaining (SFC) and In-situ
Flow Information Telemetry (IFIT) are important path services
along with the packets. In order to support these services, several
encapsulations have been defined. Network Service Header (NSH) is
defined in as the encapsulation for SFC. For
IFIT encapsulations, In-situ OAM (iOAM) Header is defined in and Postcard-Based Telemetry (PBT)
Header is defined in . Inband Flow Analyzer
(IFA) is also defined in to record
flow specific information from an end station and/or switches across a
network. In the application scenario of IPv6, these encapsulations
propose challenges for the data plane. The document analyzes the
problems and proposes the possible optimized encapsulation for IPv6.SFC: Service Function ChainingIFIT: In-situ Flow Information TelemetryIOAM: In-situ OAMPBT: Postcard-Based TelemetryIFA: Inband Flow AnalyzerSRH: Segment Routing HeaderThe problems posed by the current encapsulations for SFC and IFIT in
the application scenarios of IPv6 and SRv6 include:1. According to the encapsulation order recommended in , if the IOAM is encapsulated in the IPv6 Hop-by-Hop
options header, in the incremental trace mode of IOAM as the number of
nodes traversed by the IPv6 packets increases, the recorded IOAM
information will increase accordingly. This will increase the length of
the Hop-by-Hop options header and cause increasing difficulties in
reading the subsequent Segment Routing Extension Header (SRH) and thereby reduce the
forwarding performance of the data plane greatly.2. With the introduction of SRv6 network programming , the path services
along with the IPv6 packets can be processed at all the IPv6 network
nodes or only at the SRv6 enabled network nodes along the path. It is
necessary to distinguish the encapsulations for the specific path
service which should be processed by the IPv6 path or the SRv6 path.3. Both NSH and IOAM need the Metadata field to record metadata
information. However currently these metadata has to be recorded
separately which may generate redundant metadata information or increase
the cost of process.4. There is unnecessary inconsistency in the current encapsulations
for IOAM, IFA and PBT in the IPv6 scenario. Especially it seems
unnecessary to define a new specific IPv6 header for IFA, i.e. IFA
header.To solve the problems stated above, in the application scenarios of
IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized with
the following design considerations:To separate the SFC/IFIT path service into two parts, i.e.
instruction and recording parts. The instruction part (normally with
fixed length) can be placed in the front IPv6 extension headers
including Hop-by-Hop options header, Destination options header,
Routing header, etc. while the recording part can be placed in the
back IPv6 extension headers such as being placed after IPv6 Routing
Header. In this way the path service instruction in the IPv6
extension headers can be fixed as much as possible to facilitate
hardware process to keep forwarding performance while the SFC/IFIT
metadata recording part is placed afterwards which enables to stop
recording when too much recording information has to be carried to
reach the limitation of hardware process.To define SFC/IFIT path service instructions as IPv6 options
uniformly whichs can be placed either in the Hop-by-hop options
which indicates the path service processed by all IPv6 enabled nodes
along the path or in the SRH option TLVs which indicates the path
service processed only by the SRv6 nodes along the SRv6 path
indicated by the Segment List in the SRH.To define a unified IPv6 metadata header which can be used as a
container to record the service metadata of SFC, IFIT and other
possible path services.According to the above design optimization consideration, in the
application scenarios of IPv6 and SRv6 the encapsulations for SFC and
IFIT can be defined as below.1. NSH Service OptionOption Type: TBD_0Opt Data Len: 8 octets.Other fields: refer to .2. IOAM Service OptionOption Type: TBD_1Opt Data Len: 8 octets.Other fields: refer to .3. PBT Service OptionOption Type: TBD_2Opt Data Len: 20 octets.Other fields: refer to .4. IFA Service OptionOption Type: TBD_3Opt Data Len: 4 octets.Other fields: refer to .These options can be put in the IPv6 Hop-by-Hop Options Header or
SRH TLV.As introduced in [I-D.li-6man-enhanced-extension-header], IPv6
Metadata Header is defined as a new type of IPv6 extension header. The
metadata is the information recorded by each hop for specific path
services, and carried in corresponding service metadata options. The
length of the metadata is variable.For the SFC service, the corresponding SFC service metadata
option is defined as shown in Figure 5.For the IOAM service, the corresponding IOAM service metadata
option is defined as shown in Figure 6.All the IOAM IPv6 options require 4n alignment. This ensures that
4 octet fields specified in [I-D.ietf-ippm-ioam-data] such as
transit delay are aligned at a multiple-of-4 offset from the start
of the IPv6 Metadata header.In addition, to maintain IPv6 extension header 8-octet alignment
and avoid the need to add or remove padding at every hop, the
Trace-Type for Incremental Tracing Option in IPv6 MUST be selected
such that the IOAM node data length is a multiple of 8-octets.For the IOAM service, the corresponding IOAM service metadata
option is defined as shown in Figure 6.TBD.