The Correspondence between Packets and SRv6 Tunnels

Introduction In SRv6 networks, the Software-Defined Networking (SDN) controller is responsible for centralized management and dynamic configuration of network resources, which is essential for achieving network flexibility and intelligence. However, the controller’s awareness of SRv6 packet paths currently relies on theoretical derivation, which lacks timeliness and accuracy. Delays in state updates and failures in acquiring real-time path information pose challenges in dynamic network environments. For instance: * In multi-path tunnel configurations, the controller should adjust traffic routing based on the active/standby status and priority of pre-configured tunnels. Latency in state awareness can prevent prompt response to network changes, resulting in inaccurate path decisions. * In load-balancing scenarios with multiple parallel sub-paths, traffic distribution strategies (e.g., hashing or random selection) improve bandwidth utilization but complicate operations due to the difficulty of tracking packet routes in real time. To address these issues, this document defines a new Segment Routing Header (SRH) extension: the SRv6 Policy Key, which serves as a unique tunnel identifier. ## 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.

SRv6 Policy KEY This document defines a new SRH extension header, the SRv6 Policy Key, which is used to identify an SRv6 policy tunnel. This identifier is carried within the packet header and reported by network nodes to the controller. Using this identifier, the controller can accurately determine the actual path taken by packets within the Segment Routing domain. This significantly enhances the controller’s state awareness, allowing it to obtain a more timely and accurate view of network status, thereby improving operational maintenance and decision-making processes.

Format of an SRv6 Policy KEY The SRv6 Policy Key is appended to the end of the standard SRH (as defined in RFC9386) and has the following format:

SRv6 Policy KEY Field: Carries the core identifier information of the SRv6 tunnel, implemented in TLV format (see Section 3.2 for details).
Other fields (Next Header, Hdr Ext Len, etc.): Comply with the standard SRH definition in RFC9386 to ensure compatibility with existing SRv6 devices.

SRv6 Policy KEY TLV The SRv6 Policy Key is encapsulated in a TLV structure, which contains all parameters required to identify the SRv6 tunnel and its candidate paths. The TLV format is as follows:

Type: 8-bit code point
Length: Variable-length field size
Flags: 8-bit flag field
Preference: 32-bit priority value for candidate paths
Policy Color: 32-bit color identifier
Headend: 128-bit IPv6 address of the tunnel start point
Endpoint: 128-bit IPv6 address of the tunnel endpoint
SID List: Segment Identifier list for candidate paths under the policy.

Key Technologies and Implementation

Overall Interaction Architecture The solution adopts a collaborative "controller–network node" architecture as its core: the controller assumes centralized analysis and decision-making responsibilities, while network nodes (including source nodes, destination nodes, and intermediate forwarding nodes) are responsible for packet processing and information reporting. Through the interaction mechanism of configuration distribution and information reporting, precise identification of service transmission tunnels is achieved.

Detailed Steps

Pre-configuration (Controller-Driven) The controller configures the source node to embed a "SRv6 Policy Key" containing key tunnel information in the Segment Routing Header (SRH) of SRv6 packets when sending them. Simultaneously, it configures relevant network nodes, such as source nodes, destination nodes, or intermediate forwarding nodes, to detect SRv6 packets carrying specific service data, extract the service information and SRv6 Policy Key from them, and report these to the controller. If dynamic adjustment is not required, these configurations can also be pre-configured on the nodes.

Packet Processing (Executed by Network Nodes) When generating SRv6 packets carrying specific service data, the source node attaches the SRv6 Policy Key in the SRH of the packets as per the pre-configuration and sends them. During the process of forwarding or receiving packets, network nodes such as source nodes, destination nodes, or intermediate forwarding nodes automatically extract the service information (e.g., service type, traffic characteristics) and SRv6 Policy Key from detected SRv6 packets carrying service data, preparing them for subsequent reporting.

Information Reporting and Tunnel Identification (Collaborative Completion) Network nodes report the extracted service information and SRv6 Policy Key to the controller, supporting batch reporting of multiple sets of associated information over a specific time period. After receiving the information, the controller parses the corresponding SRv6 tunnel authentic specific service path using the SRv6 Policy Key, ultimately establishing a clear association that "a specific service is transmitted through a specific SRv6 tunnel."

Functional Description

Function1: Path Consistency Verification The controller uses the SRv6 Policy Key to compare actual packet paths against intended paths. This ensures congruence between data transmission routes and pre-configured paths, enhancing reliability and operational efficiency.

Function2: Service flow analysis function Network nodes record and perform statistics on service flows based on the SRv6 Policy Key, candidate paths, and segment lists. This enables service impact analysis during node upgrades or relocations.

Function3: Controller path visualization The controller collects and analyzes packet headers from network nodes, improving path visibility and manageability. The SRv6 Policy Key enables the controller to query candidate paths and reconstruct real-time service trajectories. -------------- | controller |---------------<-------------| | +-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | |Telementry |Telementry |Telementry | | | | | | | | | | | | | SRv6 Policy +-+-+-+-+-+-+-+-+-+-+-+ SRv6 Policy | |------------->-------------- | P1 |--------------->-------------| | +-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | CE1 |----------------- | PE1 |----------------- | P2 |----------------- | PE2 |----------------- | CE2 | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+ | |-----------------------------| P3 |------------------------------ +-+-+-+-+-+-+-+-+-+-+-| Figure 3: Example Network Topology with SRv6 Policy Key ]]>

Use Case

Enhancing Real-Time Path Recognition In practical SRv6 deployments, the controller often lacks real-time awareness of actual packet paths due to state update latency and acquisition malfunctions. The SRv6 Policy Key provides a unique identifier that enhances real-time path recognition. As shown in Figure 3, when a packet enters the headend node PE1, the SRv6 Policy Key is added to the packet header. This key carries essential tunnel identification information that enables precise path recognition throughout the transmission path. This enhancement is particularly valuable in:

Triple-Redundant Tunnels (P1, P2, P3): Achieving seamless switch-over between primary and backup tunnels requires precise awareness of each path's state. The SRv6 Policy Key enables each node (P1, P2, P3) to accurately identify and report the path being used, allowing informed switching decisions.
Single-Tunnel Multipath Policy: Traffic is dynamically distributed among multiple paths (P1, P2, P3) according to link conditions and priority levels. The SRv6 Policy Key provides accurate path awareness at each transit node, enabling efficient traffic handling and network optimization.

Improving Path Visibility In the network topology shown in Figure 3, intricate load-balancing scenarios present significant challenges for path visibility. A single logical path from PE1 to PE2 may be distributed across three concurrent sub-paths (via P1, P2, P3) following hash rules. Through the SRv6 Policy Key mechanism, each node along the path (P1, P2, P3, and PE2) can detect and report the actual path usage to the controller. This enables the controller to:

Identify exactly which sub-path (P1, P2, or P3) is carrying specific traffic flows
Monitor load distribution patterns in real-time across all available paths
Correlate service performance metrics with specific paths through the network
Make data-driven decisions for traffic engineering and optimization

This enhanced visibility is crucial for maintaining service level agreements and troubleshooting performance issues.

Security Considerations TBD.

IANA Considerations TBD.