]> University of Science and Technology of China

100 Fuxing Road Hefei Anhui 230093 China xfyan@mail.ustc.edu.cn

University of Science and Technology of China

100 Fuxing Road Hefei Anhui 230093 China xlichen@ieee.org

University of Science and Technology of China

100 Fuxing Road Hefei Anhui 230093 China zqzhu@ieee.org

Routing Spring SRv6 INT Closed-Loop Resource Control This document defines SRv6-INT, a protocol extension that integrates In-band Network Telemetry (INT) with Segment Routing over IPv6 (SRv6) packet processing. The extension reuses the Segment List entry associated with each SRv6-INT endpoint to carry an equal-length telemetry record, thereby preventing telemetry collection along the path from further increasing the packet header length. A collector obtains the resulting telemetry and provides it to local and global controllers for closed-loop resource control.

Introduction Segment Routing over IPv6 (SRv6) uses the Segment Routing Header (SRH) to carry an ordered list of Segment Identifiers (SIDs) in IPv6 packets . Packets are forwarded according to the Segment List in the SRH, and each segment endpoint executes the behavior bound to the active SID . Telemetry data can be recorded in data packets as they traverse a network. In-band Network Telemetry (INT) and In Situ Operations, Administration, and Maintenance (IOAM) are related but independent telemetry frameworks that use this measurement approach. This document defines SRv6-INT, a protocol extension that integrates INT telemetry collection with SRv6 packet processing. When a packet reaches the endpoint associated with the active SID, the endpoint replaces the Segment List entry containing that SID with equal-length node telemetry data, referred to as INT Metadata. Reusing this header space prevents the packet header from growing as telemetry data is collected at successive segment endpoints . INT Metadata can contain a device identifier, timestamps, processing latency, queue occupancy, and traffic counters. The collected metadata can be used to monitor application traffic and provide feedback for closed-loop resource control . defines the scope and non-goals of this document.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terminology defined in and , including SRH, Segment List, Segment Identifier, SR Policy, Segments Left, Last Entry, FIB, and SRv6 Endpoint behavior. It also defines the following terms:

• SRv6-INT: The protocol extension that integrates INT telemetry collection with SRv6 packet processing. Its packet format and processing behaviors are specified in and , respectively.
• INT Metadata: A 128-bit per-node telemetry record carried in a reused Segment List entry.
• SRv6-INT-capable node: An SRv6 node that supports one or more SRv6-INT processing behaviors.
• SRv6-INT ingress (or headend): An SRv6-INT-capable node that constructs SRv6-INT packets for selected traffic according to an SR Policy.
• SRv6-INT endpoint: An SRv6-INT-capable node that instantiates one or more local SIDs bound to SRv6-INT endpoint behaviors.
• Service node: A node that hosts an application or service.
• Collector: A deployed entity that obtains telemetry data provided by SRv6-INT endpoints. It reads local telemetry data from packets delivered to a service node or obtains complete telemetry data after SRv6-INT processing at the final endpoint.
• Local controller: A deployed entity that consumes local telemetry data and makes local resource-control decisions.
• Global controller: A deployed entity that consumes complete telemetry data, forms a network-wide performance view, and makes resource-control decisions.

This document does not mandate any specific implementation of the collector, local controller, or global controller.

Problem Statement and Scope

Problem Statement An SRv6 packet already carries a Segment List in its SRH. If a separate telemetry header is inserted and each endpoint appends a telemetry record, the packet length increases as the packet traverses the path. This growth increases the risk of exceeding the maximum transmission unit (MTU) and adds data-plane processing overhead. To avoid this growth, each SRv6-INT endpoint replaces its corresponding Segment List entry with the telemetry data it collects. The collector then obtains the resulting telemetry data, which the local and global controllers use as feedback for closed-loop resource control.

Scope and Non-Goals This document defines:

• The SRv6-INT protocol extension and associated control information;
• The reuse of Segment List entries to carry INT Metadata;
• The SRv6-INT processing behaviors defined in ; and
• How the collector obtains telemetry data and how the local controller and global controller consume the data for closed-loop resource control.

This document does not define resource-control algorithms used by the local and global controllers, APIs used for resource control, or encapsulation formats and transport protocols for delivering telemetry data to the collector.

Applicability SRv6-INT applies within an SRv6-INT domain. An SRv6-INT domain is a portion of an SRv6 network in which SRv6-INT is enabled. Only configured SRv6-INT ingress nodes and SRv6-INT endpoints perform SRv6-INT processing. Ordinary IPv6 transit nodes may forward packets between these nodes without examining or modifying SRv6-INT fields. SRv6-INT can be applied to all application traffic or only to traffic selected according to a local policy. This document does not define the selection criteria. The amount of traffic subject to SRv6-INT can be limited according to device capacity, packet overhead, and operational constraints.

SRv6-INT Protocol Extension This document applies only to SRHs that contain a complete Segment List. SRv6-INT processing of a Reduced SRH is outside the scope of this document.

SRv6-INT Packet Format This section specifies the SRv6-INT packet format and the additional semantics assigned to SRH fields. Except as specified in this document, SRH fields are used as defined in . IPv6 packet processing follows . The format and semantics of the SRv6-INT fields are the same whether the SRH is added during encapsulation or included when an IPv6 packet is originated . presents the encapsulation context and the SRH format. The encapsulation in (a) is schematic and is not drawn to scale. (b) shows a Segment List entry after it has been reused for INT Metadata as specified in .

SRv6-INT Packet Format

where: Next Header: Defined in Section 4.4 of . Hdr Ext Len: Defined in Section 4.4 of . Routing Type: 4. Segments Left: Defined in Section 4.4 of . Last Entry: In a complete Segment List, identifies the entry containing the first segment of the SR Policy, as specified in Section 2 of . Flags: An 8-bit field defined in . defines the use of one bit for SRv6-INT. Tag: A 16-bit field defined in . Its use for SRv6-INT is defined in . Segment List[0..n]: A list of 128-bit IPv6 addresses encoded in reverse SR Policy order, as specified in Section 2 of . In a complete Segment List, Segment List[0] contains the last segment of the SR Policy. SRv6-INT TLV: An SRH TLV defined in . It follows the Segment List and MUST be fully contained within the SRH, as determined by Hdr Ext Len, in accordance with Section 2.1 of .

SRv6-INT Control and Feedback Fields SRv6-INT uses one bit in the SRH Flags field, the SRH Tag field, and an SRv6-INT TLV to carry control and feedback information. SRv6-INT Flag: A one-bit flag in the SRH Flags field that identifies an SRv6-INT packet. The SRv6-INT ingress sets this flag when constructing the packet, and it remains unchanged within the SRv6-INT domain. A packet without this flag set MUST NOT undergo SRv6-INT processing. Its bit position is TBD1; the existing implementation uses 0x80 for testing. Tag: Indicates the SRv6-INT processing mode associated with the local SID. Plain mode applies when the SID has no associated service node. Service mode applies when the SID is associated with a service node. This mode includes packet delivery to and return from that node. In Service mode, Tag also distinguishes the endpoint-processing state from the service-processing state. The existing implementation uses the following values:

Tag Value	Processing Mode and State
0x0000	Plain mode.
0x4000	Service mode (endpoint-processing state), used at the SRv6-INT endpoint before delivery to the associated service node and after the packet returns.
0x8000	Service mode (service-processing state), used after delivery to the associated service node and before the packet returns to the SRv6-INT endpoint.

The Tag values for these modes and states are TBD. specifies how Tag is initialized and updated. SRv6-INT TLV: A packet with the SRv6-INT Flag set MUST carry an SRv6-INT TLV after the Segment List. Following the alignment convention in Section 2.1 of , the SRv6-INT TLV has no alignment requirement. The TLV has the following format: where: Type: 8 bits. The value TBD2 identifies the SRv6-INT TLV. The IANA request is specified in . Length: 8 bits. The length of the Value in octets, excluding the Type and Length fields. Its value is 6; the total TLV length is 8 octets. MapInfo: A 16-bit bitmap in which each set bit selects a telemetry data category to be collected by SRv6-INT endpoints. The bits are assigned as follows: PF (Performance Feedback): A 32-bit field carrying performance feedback in Service mode. In this document, PF carries the result of the most recently completed Service_Delay measurement for the local SID, as defined in . The endpoint stores this result locally and sets PF to the stored value before delivering a subsequent packet to the associated service node. Future specifications may extend PF to carry other performance metrics. Any such extension MUST define how each metric is identified and specify its semantics, units, and encoding. PF is the only field in the SRv6-INT TLV that may change along the path. Type, Length, and MapInfo MUST remain unchanged.

INT Metadata Format Each INT Metadata record is 128 bits, equal in length to a Segment List entry. Plain mode and Service mode share the following format. Only the interpretation of the time fields differs between the two modes. ~ marks continuation across rows; the two parts bearing the same time-field name form a single 32-bit field. where: Device ID: 8 bits. Identifies the SRv6-INT endpoint that writes the record. Time Field 1 and Time Field 2: Two 32-bit time fields. Their interpretation is shown below:

Processing Mode and State	Time Field 1	Time Field 2
Plain mode	In_Time	Out_Time
Service mode (service-processing state)	In_Time	Out_Time
Service mode (endpoint-processing state after service return)	Service_Delay	Hop_Delay

The table uses the following field definitions:

• In_Time: The time of the packet's first arrival at the SRv6-INT endpoint.
• Out_Time: The time at which the packet leaves the SRv6-INT endpoint in Plain mode or is transmitted to the associated service node in Service mode.
• Service_Delay: The interval from transmission to the service node until the packet returns to the same SRv6-INT endpoint.
• Hop_Delay: The interval from the packet's first arrival at the SRv6-INT endpoint until it is forwarded toward the next segment after returning from the service node.

Queue ID: 5 bits. Identifies the queue. Queue Length: 19 bits. The queue length. Port Counter: 32 bits. The traffic count.

Segment List Entry Reuse The endpoint associated with the SID in Segment List[0] uses Plain mode. When an SRv6-INT endpoint receives a packet destined to a local SID, it reuses only the Segment List entry corresponding to that SID. defines the INT Metadata format and field semantics. In Plain mode, the endpoint writes INT Metadata into that entry once. In Service mode, the endpoint writes INT Metadata into the entry for transmission to the associated service node and updates the same entry after the packet returns. specifies the write sequence. The endpoint MUST NOT modify any other Segment List entry. Once it has completed SRv6-INT processing, the INT Metadata in the corresponding entry MUST NOT be modified or interpreted as a SID. Entry reuse MUST NOT change the number of entries in the Segment List, the 128-bit length of each entry, Last Entry, Hdr Ext Len, or the order or value of any SID that remains to be processed.

SRv6-INT Processing Model This section defines SRv6-INT processing behaviors and their operation within an SRv6-INT domain.

SRv6-INT Processing Behaviors

SRv6-INT Packet Validation A packet processed by End.T.INT or End.DT.INT MUST meet the following requirements:

• The SRv6-INT Flag is set.
• Each SRv6-INT TLV in the packet conforms to the format specified in .
• The Tag field indicates one of the processing modes and states defined in .
• The packet does not contain the HMAC TLV (Type 5) defined in . explains this restriction.

H.Encaps.INT Behavior H.Encaps.INT extends the H.Encaps behavior defined in Section 5.1 of . An SRv6-INT ingress/headend applies it to selected traffic. For each selected packet, the SRv6-INT ingress/headend performs the following operations:

End.T.INT Behavior End.T.INT extends the End.T behavior defined in Section 4.3 of . Each instance is associated with an IPv6 FIB table T and may also be associated with a service node. In the procedure below, M holds the 128-bit INT Metadata constructed or updated for the local SID. Time Field 1 and Time Field 2 refer to fields in M. When a packet's IPv6 Destination Address matches a local End.T.INT SID, the SRv6-INT endpoint performs the following operations: The service node MUST return the packet to the same SRv6-INT endpoint without modifying the SRH. The packet's IPv6 Destination Address MUST continue to identify the same locally instantiated End.T.INT SID.

End.DT.INT Behavior A locally instantiated SID bound to the End.DT.INT behavior MUST be the last segment of the SR Policy. Each such SID is associated with a local decapsulation and delivery context. When a packet's IPv6 Destination Address matches a local End.DT.INT SID, the SRv6-INT endpoint performs the following operations:

Error Handling Failures of checks inherited from , , or are handled as specified for those checks in the cited document. A failure of an SRv6-INT check specified in or in the applicable End.T.INT or End.DT.INT procedure is an SRv6-INT processing error. The same applies in either of the following cases:

• Telemetry data selected by MapInfo cannot be obtained or represented in the corresponding field defined in .
• INT Metadata replacement violates .

On an SRv6-INT processing error, the node MUST stop SRv6-INT processing and discard the packet. It MUST NOT modify any further Segment List entries.

SRv6-INT Domain and Node Roles shows an SRv6-INT domain. Packets steered by the SR Policy <S1, S2, S3> are processed by N1, N2, and N3 in that order. The nodes have the following roles:

• H is the SRv6-INT ingress/headend executing H.Encaps.INT.
• N1 executes End.T.INT for SID S1. No service node is associated with S1, so N1 uses Plain mode.
• N2 executes End.T.INT for SID S2. S2 is associated with the service node shown, so N2 uses Service mode.
• R is an ordinary IPv6 transit node between N2 and N3.
• N3 executes End.DT.INT for the final SID S3.

Node Roles and Closed-Loop Resource Control in an SRv6-INT Domain [H]-->[N1]-->[N2]---->[R]--------->[N3]--------------> | ^ :^ | | | :: | | v :: | | +--------------+ :: | | | Service Node | :: | | +--------------+ :: | | :^ :: | | Local :: Complete :: | | Telemetry :: Telemetry :: | | v: Config v: Config | | +-------------------+ +-------------------+ | | | Collector / | | Collector / | | | | Local Controller | | Global Controller | | | +-------------------+ +-------------------+ | | | +------------------------------------------------+ ]]>

Solid arrows show packet forwarding, including delivery from N2 to the service node and return to N2. Dotted arrows show telemetry data provided by N2 and N3 to the corresponding collectors. Arrows labeled Config show resource configuration. A slash indicates that the collector and controller roles may be co-located. The following requirements apply within an SRv6-INT domain:

• Each non-final SID in an SR Policy used for SRv6-INT MUST be instantiated at an SRv6-INT endpoint and bound to the End.T.INT behavior. The final SID MUST be instantiated at an SRv6-INT endpoint and bound to the End.DT.INT behavior. For each non-final SID, the deployment configuration MUST identify any associated service node.
• The collector MUST interpret the INT Metadata using information associated with the deployed SR Policy.
• SRv6-INT endpoints whose In_Time or Out_Time values are compared MUST use clocks synchronized to a common time reference. Service_Delay and Hop_Delay MAY be computed using the local clock of the endpoint that writes them.

In the following example, H sets MapInfo to select telemetry data categories. N2 has stored a Service_Delay measurement obtained from an earlier packet. A_H denotes the Source Address in the outer IPv6 header constructed by H. M1 and M3 denote the INT Metadata written by N1 and N3, respectively. T2 denotes the INT Metadata written by N2 before delivery to the service node; M2 denotes that INT Metadata after N2 updates its time fields when the packet returns. The notation follows Section 6.1 of . (A_H,S1) lists the outer IPv6 Source and Destination Addresses. (S3,S2,S1;SL=2) lists the Segment List in encoding order. Other header fields and the inner packet are omitted. When H receives a selected packet, it executes H.Encaps.INT as specified in , sets Tag to indicate Plain mode, and forwards the packet: N1 executes End.T.INT in Plain mode. It sets Tag to indicate Plain mode, writes M1 to Segment List[2], and forwards the packet to N2: N2 executes End.T.INT in Service mode. Before delivering the packet to the service node, N2 sets Tag to indicate the endpoint-processing state, writes the stored Service_Delay into PF, and writes T2 to Segment List[1]. It then sets Tag to indicate the service-processing state. The IPv6 Destination Address and SL remain unchanged: When the packet is delivered to the service node, the collector reads the INT Metadata denoted by T2 as local telemetry data and obtains the Service_Delay measured for the earlier packet from PF. The service node returns the packet to N2 without modifying the SRH. As specified in , N2 replaces Time Field 1 and Time Field 2 in T2 with Service_Delay and Hop_Delay, respectively, producing M2. N2 stores Service_Delay locally for S2, restores Tag to indicate the endpoint-processing state, and sets PF to 0. It then writes M2 to Segment List[1], sets SL to 0 and the IPv6 Destination Address to S3, and forwards the packet: R forwards the packet to N3 using ordinary IPv6 forwarding, leaving the fields shown above unchanged. N3 executes End.DT.INT as specified in . It sets Tag to indicate Plain mode and writes M3 to Segment List[0]. Before decapsulation, the packet is: N3 provides the collector with a packet containing the complete SRH, then removes the outer IPv6 header and its extension headers and forwards the inner packet. The collector obtains the INT Metadata sequence M1, M2, M3.

Closed-Loop Resource-Control Framework SRv6-INT supports local and global control loops using telemetry data collected according to MapInfo. In the local loop, the collector obtains local telemetry data from packets delivered to a service node and provides the data to the local controller. The local controller uses these data to maintain a local performance view and produce configurations for the relevant service resources. In the global loop, an SRv6-INT endpoint executing End.DT.INT provides the complete INT Metadata sequence to the collector. The collector provides these data to the global controller, which uses them to generate configurations for the relevant network or service resources. Once applied, the resource configurations affect the processing of subsequent packets. SRv6-INT endpoints collect new telemetry data from those packets, and the controllers use these data to update their performance views and resource configurations, thereby closing the control loops. Invalid telemetry data MUST NOT be used to generate resource configurations. This document does not define the algorithms used to derive performance views or resource configurations.

Security Considerations Within an SRv6-INT domain, SRv6-INT-capable nodes are trusted to perform only those SRv6-INT processing operations authorized by their local configuration. The domain MUST apply the ingress filtering specified in Section 5.1 of . Unless explicitly permitted by local policy, domain boundary nodes MUST discard any packet with the SRv6-INT Flag set that would otherwise cross the domain boundary in either direction. The HMAC defined in is calculated over all Segment List entries. Because SRv6-INT replaces these entries with INT Metadata, the RFC 8754 HMAC TLV is incompatible with the Segment List entry replacement mechanism. Therefore, an SRv6-INT packet MUST NOT contain this TLV. SRv6-INT telemetry collection is subject to threats involving unauthorized modification of telemetry data, information disclosure, and denial of service, similar to those discussed for IOAM in Section 9 of . Within this closed-loop framework, unauthorized manipulation of INT Metadata or PF can distort performance assessments and lead to inappropriate resource configurations. If the trust assumptions within the domain no longer hold, boundary filtering alone is insufficient to address these threats. Deployments SHOULD enforce authorization controls on access to and transfer of telemetry data and on resource-configuration operations. They SHOULD also use mechanisms outside the scope of this document to protect the confidentiality and integrity of communications involving the Collector, Local Controller, and Global Controller.

IANA Considerations If this document is approved, IANA is requested to make the assignments specified below. Unassigned values are denoted by TBD1 through TBD4.

SRH Flag Assignment The requested assignment from the "Segment Routing Header Flags" registry is:

Bit	Description	Reference
TBD1	SRv6-INT Flag	This document

defines the flag semantics and identifies the value used for testing.

SRv6-INT TLV Type Assignment The requested assignment from the mutable range (128-251) of the "Segment Routing Header TLVs" registry is:

Type	Description	Reference
TBD2	SRv6-INT TLV	This document

defines the TLV format and field mutability.

SRv6 Endpoint Behavior Assignments The requested assignments from the "SRv6 Endpoint Behaviors" registry are:

Value	Endpoint Behavior	Reference
TBD3	End.T.INT	This document
TBD4	End.DT.INT	This document

No code point in this registry is requested for H.Encaps.INT. The values used in the SRH Tag field are not SRv6 Endpoint Behavior code points, and this document requests no IANA action for them. and specify their semantics and when the field is updated.

References Normative References This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References P4.org Applications Working Group In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. IEEE Institute of Electrical and Electronics Engineers (IEEE)

Contributors Xuefeng Yan, Xiaoliang Chen, and Zuqing Zhu contributed to the content of this document.