< draft-li-6man-ipv6-sfc-ifit-00.txt   draft-li-6man-ipv6-sfc-ifit-01.txt >
Network Working Group Z. Li Network Working Group Z. Li
Internet-Draft S. Peng Internet-Draft S. Peng
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 12, 2019 March 11, 2019 Expires: January 9, 2020 July 8, 2019
Consideration of IPv6 Encapsulation for SFC and IFIT IPv6 Encapsulation for SFC and IFIT
draft-li-6man-ipv6-sfc-ifit-00 draft-li-6man-ipv6-sfc-ifit-01
Abstract Abstract
Service Function Chaining (SFC) and In-situ Flow Information Service Function Chaining (SFC) and In-situ Flow Information
Telemetry (IFIT) are important path services along with the packets. Telemetry (IFIT) are important path services along with the packets.
In order to support these services, several encapsulations have been In order to support these services, several encapsulations have been
defined. The document analyzes the problems of these encapsulations defined. The document analyzes the problems of these encapsulations
in the IPv6 scenario and proposes the possible optimized in the IPv6 scenario and proposes the possible optimized
encapsulation for IPv6. encapsulation for IPv6.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Consideration . . . . . . . . . . . . . . . . . . . . 3 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 3
4.1. Service Options . . . . . . . . . . . . . . . . . . . . . 4 4.1. Service Options . . . . . . . . . . . . . . . . . . . . . 4
4.2. IPv6 Metadata Header . . . . . . . . . . . . . . . . . . 6 4.2. IPv6 Service Metadata Options . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. SFC Service Metadata Option . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.2.2. IOAM Service Metadata Option . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.3. IFA Service Metadata Option . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Service Function Chaining (SFC) [RFC7665] and In-situ Flow Service Function Chaining (SFC) [RFC7665] and In-situ Flow
Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are
important path services along with the packets. In order to support important path services along with the packets. In order to support
these services, several encapsulations have been defined. Network these services, several encapsulations have been defined. Network
Service Header (NSH) is defined in [RFC8300] as the encapsulation for Service Header (NSH) is defined in [RFC8300] as the encapsulation for
SFC. For IFIT encapsulations, In-situ OAM (iOAM) Header is defined SFC. For IFIT encapsulations, In-situ OAM (iOAM) Header is defined
in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT) in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT)
skipping to change at page 3, line 17 skipping to change at page 3, line 19
SRH: Segment Routing Header SRH: Segment Routing Header
3. Problem Statement 3. Problem Statement
The problems posed by the current encapsulations for SFC and IFIT in The problems posed by the current encapsulations for SFC and IFIT in
the application scenarios of IPv6 and SRv6 include: the application scenarios of IPv6 and SRv6 include:
1. According to the encapsulation order recommended in [RFC8200], if 1. According to the encapsulation order recommended in [RFC8200], if
the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in
the trace mode of IOAM as the number of nodes traversed by the IPv6 the incremental trace mode of IOAM as the number of nodes traversed
packets increases, the recorded IOAM information will increase by the IPv6 packets increases, the recorded IOAM information will
accordingly. This will increase the length of the Hop-by-Hop options increase accordingly. This will increase the length of the Hop-by-
header and cause increasing difficulties in reading the following Hop options header and cause increasing difficulties in reading the
Segment Routing Extension Header (SRH) following Segment Routing Extension Header (SRH)
[I-D.ietf-6man-segment-routing-header] and thereby reduce the [I-D.ietf-6man-segment-routing-header] and thereby reduce the
forwarding performance of the data plane greatly. forwarding performance of the data plane greatly.
2. With the introduction of SRv6 network programming 2. With the introduction of SRv6 network programming
[I-D.filsfils-spring-srv6-network-programming], the path services [I-D.ietf-spring-srv6-network-programming], the path services along
along with the IPv6 packets can be processed at all the IPv6 network with the IPv6 packets can be processed at all the IPv6 network nodes
nodes or only at the SRv6 enabled network nodes along the path. It or only at the SRv6 enabled network nodes along the path. It is
is necessary to distinguish the encapsulations for the specific path necessary to distinguish the encapsulations for the specific path
service which should be processed by the IPv6 path or the SRv6 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 3. Both NSH and IOAM need the Metadata field to record metadata
information. However currently these metadata has to be recorded information. However currently these metadata has to be recorded
separately which may generate redundant metadata information or separately which may generate redundant metadata information or
increase the cost of process. increase the cost of process.
4. There is unnecessary inconsistency in the current encapsulations 4. There is unnecessary inconsistency in the current encapsulations
for IOAM, IFA and PBT in the IPv6 scenario. Especially it seems 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 unnecessary to define a new specific IPv6 header for IFA, i.e. IFA
header. header.
5. [I-D.guichard-spring-nsh-sr] is proposed for the solution to
encapsulate NSH in SRv6 to support SFC. But the encapsulation is not
defined yet.
4. Design Consideration 4. Design Consideration
To solve the problems stated above, in the application scenarios of To solve the problems stated above, in the application scenarios of
IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized
with the following design considerations: with the following design considerations:
o To separate the SFC/IFIT path service into two parts, i.e. o To separate the SFC/IFIT path service into two parts, i.e.
instruction and recording parts. The instruction part (normally instruction and recording parts. The instruction part (normally
with fixed length) can be placed in the front IPv6 extension with fixed length) can be placed in the front IPv6 extension
headers including Hop-by-Hop options header, Destination options headers including Hop-by-Hop options header, Destination options
skipping to change at page 4, line 40 skipping to change at page 4, line 37
According to the above design optimization consideration, in the According to the above design optimization consideration, in the
application scenarios of IPv6 and SRv6 the encapsulations for SFC and application scenarios of IPv6 and SRv6 the encapsulations for SFC and
IFIT can be defined as below. IFIT can be defined as below.
4.1. Service Options 4.1. Service Options
1. NSH Service Option 1. NSH Service Option
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index | | Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv6 Options with NSH instructions Figure 1. IPv6 Options with NSH instructions
Option Type: TBD Option Type: TBD_0
Opt Data Len: 8 octets. Opt Data Len: 8 octets.
Other fields: refer to [RFC8300]. Other fields: refer to [RFC8300].
2. IOAM Service Option 2. IOAM Service Option
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID |NodeLen | Flags | RemainingLen| | Namespace-ID |NodeLen | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved | | IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 Options with IOAM instructions Figure 2. IPv6 Options with IOAM instructions
Option Type: TBD Option Type: TBD_1
Opt Data Len: 8 octets. Opt Data Len: 8 octets.
Other fields: refer to [I-D.ietf-ippm-ioam-data]. Other fields: refer to [I-D.ietf-ippm-ioam-data].
3. PBT Service Option 3. PBT Service Option
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | TIH Length | Reserved | Hop Count | | Next Header | TIH Length | Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID | | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID | | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Set ID | | Data Set ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IPv6 Options with PBT instructions Figure 3. IPv6 Options with PBT instructions
Option Type: TBD Option Type: TBD_2
Opt Data Len: 20 octets. Opt Data Len: 20 octets.
Other fields: refer to [I-D.song-ippm-postcard-based-telemetry]. Other fields: refer to [I-D.song-ippm-postcard-based-telemetry].
4. IFA Service Option 4. IFA Service Option
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=2.0| GNS |NextHdr = IP_xx|R|R|R|M|T|I|T|C| Max Length | |Ver=2.0| GNS |NextHdr = IP_xx|R|R|R|M|T|I|T|C| Max Length |
| | | | | | |F|S| |A| | | | | | | | | |F|S| |A| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IPv6 Options with IFA instructions Figure 4. IPv6 Options with IFA instructions
Option Type: TBD Option Type: TBD_3
Opt Data Len: 4 octets. Opt Data Len: 4 octets.
Other fields: refer to [I-D.kumar-ippm-ifa]. Other fields: refer to [I-D.kumar-ippm-ifa].
These options can be put in the IPv6 Hop-by-Hop Options Header or SRH These options can be put in the IPv6 Hop-by-Hop Options Header or SRH
TLV. TLV.
4.2. IPv6 Metadata Header 4.2. IPv6 Service Metadata Options
IPv6 Metadata Header is defined as a new type of IPv6 extension As introduced in [I-D.li-6man-enhanced-extension-header], IPv6
header shown in Figure 5. The metadata is the information recorded Metadata Header is defined as a new type of IPv6 extension header.
by each hop for specific path services, The length of the metadata is The metadata is the information recorded by each hop for specific
variable. path services, and carried in corresponding service metadata options.
The length of the metadata is variable.
4.2.1. SFC Service Metadata Option
For the SFC service, the corresponding SFC service metadata option is
defined as shown in Figure 5.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | | | SFC Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | SFC Metadata Class | Type |U| Length |
. . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Metadata Stack (Variable) . | Variable-Length Metadata |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Metadata Header
Next Header 8-bit selector. Identifies the type of header Figure 5. SFC Service Metadata
immediately following the IPv6 metadata
header.
Hdr Ext Len 8-bit unsigned integer. Length of the SFC Type 8-bit identifier of the service type, i.e. SFC.
IPv6 metadata header in 8-octet units, The value is TBD-4.
not including the first 8 octets.
Metadata Stack Variable-length field, of length such that the Length 8-bit unsigned integer. Length of the
complete IPv6 metadata header is an Service Metadata field, in octets.
integer multiple of 8 octets long. Contains
one or more type of path service metadata.
For specific path service, i.e. SFC/IOAM, the corresponding metadata Metadata Class Defines the scope of the Type field to
is defined as follows: provide a hierarchical namespace. IANA has
set up the "NSH MD Class" registry, which
contains 16-bit values [RFC8300].
Type Indicates the explicit type of metadata
being carried. The definition of the Type is
the responsibility of the MD Class owner.
Unassigned bit One unassigned bit is available for future use.
This bit MUST NOT be set, and it MUST be
ignored on receipt.
Length Indicates the length of the variable-length
metadata, in bytes. Detailed specification
in [RFC8300].
4.2.2. IOAM Service Metadata Option
For the IOAM service, the corresponding IOAM service metadata option
is defined as shown in Figure 6.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type | Length | | IOAM Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Metadata (variable) | | IOAM Service Metadata Options (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Service Metadata
Service Type 8-bit selector. Identifies the type of Figure 6. IOAM Service Metadata
Service Metadata.
Length 16-bit unsigned integer. Length of the IOAM Type 8-bit identifier of the IOAM Service Metadata
Service metadata in 8-octet units, type. The value is TBD-5.
not including the first 8 octets.
Metadata Variable-length field, of length such that the Length 8-bit unsigned integer. Length of the
complete IPv6 metadata header is an IOAM Service Metadata field, in octets.
integer multiple of 8 octets long.
RESERVED 8-bit reserved field MUST be set to zero upon
transmission and ignored upon receipt.
IOAM Service IOAM option data is present as specified by the
Metadata Options IOAM Type field, and is defined in Section 4 of
[I-D.ietf-ippm-ioam-data].
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.
4.2.3. IFA Service Metadata Option
For the IOAM service, the corresponding IOAM service metadata option
is defined as shown in Figure 6.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IFA Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| IFA Service Metadata Options (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. IFA Service Metadata
IFA Type 8-bit identifier of the IFA Service Metadata
type. The value is TBD-6.
Length 8-bit unsigned integer. Length of the
IOAM Service Metadata field, in octets.
RESERVED 8-bit reserved field MUST be set to zero upon
transmission and ignored upon receipt.
IFA Service IFA option data is present as specified by the
Metadata Options IFA Type field.
5. IANA Considerations 5. IANA Considerations
TBD. Value Description Reference
---------------------------------------------------------------------
TBD_0 NSH Service Option [This draft]
TBD_1 IOAM Service Option [This draft]
TBD_2 PBT Service Option [This draft]
TBD_3 IFA Service Option [This draft]
TBD_4 SFC Service Metadata Type [This draft]
TBD_5 IOAM Service Metadata Type [This draft]
TBD_6 IFA Service Metadata Type [This draft]
6. Security Considerations 6. Security Considerations
TBD. TBD.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.guichard-spring-nsh-sr] [I-D.guichard-spring-nsh-sr]
Guichard, J., Song, H., Tantsura, J., Halpern, J., Guichard, J., Song, H., Tantsura, J., Halpern, J.,
Henderickx, W., and M. Boucadair, "NSH and Segment Routing Henderickx, W., Boucadair, M., and S. Hassan, "NSH and
Integration for Service Function Chaining (SFC)", draft- Segment Routing Integration for Service Function Chaining
guichard-spring-nsh-sr-00 (work in progress), September (SFC)", draft-guichard-spring-nsh-sr-01 (work in
2018. progress), March 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), February 2019. header-21 (work in progress), June 2019.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-05 (work in progress), March 2019. data-06 (work in progress), July 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network-
programming-01 (work in progress), July 2019.
[I-D.kumar-ippm-ifa] [I-D.kumar-ippm-ifa]
Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook,
H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband
Flow Analyzer", draft-kumar-ippm-ifa-01 (work in Flow Analyzer", draft-kumar-ippm-ifa-01 (work in
progress), February 2019. progress), February 2019.
[I-D.song-ippm-postcard-based-telemetry] [I-D.song-ippm-postcard-based-telemetry]
Song, H., Zhou, T., Li, Z., and J. Shin, "Postcard-based Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
In-band Flow Data Telemetry", draft-song-ippm-postcard- "Postcard-based On-Path Flow Data Telemetry", draft-song-
based-telemetry-02 (work in progress), March 2019. ippm-postcard-based-telemetry-04 (work in progress), June
2019.
[I-D.song-opsawg-ifit-framework] [I-D.song-opsawg-ifit-framework]
Song, H., Li, Z., Zhou, T., Li, Z., and J. Shin, "In-situ Song, H., Li, Z., Zhou, T., Qin, F., Shin, J., and J. Jin,
Flow Information Telemetry Framework", draft-song-opsawg- "In-situ Flow Information Telemetry Framework", draft-
ifit-framework-01 (work in progress), March 2019. song-opsawg-ifit-framework-02 (work in progress), June
2019.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Chaining (SFC) Architecture", RFC 7665, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
7.2. Informative References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 44 change blocks. 
109 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/