]> Encoding Network Slice Identification for SRv6 China Mobile
Beijing China chengweiqiang@chinamobile.com
China Telecom
Guangzhou China mapeiy@chinatelecom.cn
China Unicom
Beijing China renfh3@chinaunicom.cn
New H3C Technologies
Beijing China linchangwang.04414@h3c.com
China Mobile
Beijing China gongliyan@chinamobile.com
Broadcom
Israel shay.zadok@broadcom.com
CentecNetworks
China wumy@centec.com
Ruijie Networks Co., Ltd.
Beijing China wangxuewei1@ruijie.com.cn
General SPRING A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. At the data plane, use the NRP Selector ID to map and differentiate between different NRPs. How to map to NRP via Selector ID is not within the scope of this document. This document describes a novel method to encode NRP Selector ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP.
Introduction SRv6 Network Programming enables the creation of overlays with underlay optimization to be deployed in an SR domain . As defined in , all inter-domain packets are encapsulated for the part of the packet journey that is within the SR domain. The outer IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain. In a network that provides NRP services, the NRP Selector ID can be carried in the packet. In the process of packet forwarding, the routers on the forwarding path can extract NRP Selector ID from the packet, determine the NRP to which the packet belongs, and then forward the packet using the resources associated with the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP.
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 (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997) and (Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017).
Terminology The key terms used in this document are defined below. Network Resource Partition (NRP): a subset of the network resources and associated policies on each of a connected set of links in the underlay network. This term is defined in . NRP Identifier (NRP-ID): an identifier that is globally unique within an NRP domain and that can be used in the control or management plane to identify the resources associated with the NRP. . NRP Selector: one or more fields (markings) in a packet's network layer header that are used to map the packet to an NRP. NRP Selector Identifier (NRP Selector ID): a dedicated identifier that acts as an NRP Selector.
NRP Selector Identifier Assignment One approach to improve the data plane scalability of NRPs is to introduce a dedicated NRP Selector ID in data packets, which is used to identify the set of network resources allocated to an NRP. This way, packets mapped to an NRP can be processed and forwarded using the NRP-specific network resources, which could help to provide guaranteed performance for the packets. An NRP Selector ID can be used to identify a subset of the resources (e.g., bandwidth, buffer, and queuing resources) allocated on the set of links and nodes involved in the NRP. When an SR domain enables network slicing, a local policy MUST be defined and uniformly applied within the domain to govern the encoding of the NRP Presence Indicator (NPI) and the NRP Selector Identifier. This policy includes the method to encode the NPI and the number of bits reserved for the NRP Selector Identifier. When a packet enters the SR domain, the ingress PE encapsulates the packet with an outer IPv6 header and optional Segment Routing Header (SRH) as defined in . The ingress PE MAY classify the packet into a NRP and set the NRP identifier as follows: o Allocate a source IPv6 address for the outer header from a configured address block designated for NRP. o Encode the NRP Selector Identifier in the least significant bits of this source address. o Set the NRP Presence Indicator (NPI) in the outer IPv6 header to inform transit nodes that a valid NRP Selector Identifier is present. The NPI is a local designation within the SR domain. There are two proposed options for encoding the NPI, chosen by domain-wide policy: o NPI Option A - Using a Bit in the Traffic Class Field: A specific, agreed-upon bit within the Traffic Class field of the IPv6 header is used as the NPI. If this option is used, all nodes within the SR domain participating in NRP-aware forwarding MUST be upgraded to interpret this bit correctly. Packets with the NPI bit set may not be forwarded correctly by legacy nodes that are unaware of this new semantic for the Traffic Class field.
NPI Option A
o NPI Option B - Using a Designated Address Prefix in the Source Address: A specific IPv6 address prefix is configured and uniformly recognized within the SR domain as the "NPI Prefix". This prefix is allocated from the operator's existing address space and is used exclusively as the network prefix for source addresses carrying NRP Selector Identifiers. The NPI is effectively indicated by the source address falling within this pre-defined prefix. The NRP Selector Identifier is encoded in the least significant bits of the interface identifier portion of the address. This method does not alter the structure of the IPv6 address field itself; it simply designates a subset of the operator's address space for NRP-enabled traffic. This option can provide better backward compatibility (see Section 6).
NPI Option B
The format for the NRP Selector Identifier and NPI options in the IPv6 header is shown in Figure 3.
Encoding of NRP Selector Identifier and NPI Option
Per-NRP Forwarding Any router within the SR domain that forwards a packet with NPI set uses the NRP Selector Identifier to select a NRP and apply per-NRP policies. The most significant bit of NRP Selector Identifier may be used to carry an S-flag, which is used to indicate whether the packet MUST be forwarded strictly using the network resource associated with the NRP Selector Identifier. When the network resource associated with the NRP Selector Identifier does not exist or is not available, if the S-flag is set to 1, the packet MUST be discarded, otherwise the packet SHOULD be forwarded using the default network resource or ignoring the NRP Selector Identifier.
The NRP Selector Identifier with S bit
Example Figure 5 shows an example of network NRP packet forwarding using the proposed encoding method. Assume the NPI is encoded using option B as the NPI prefix in Source Address.
Packet Forwarding for Network NRP | Payload | --> | Payload | --> |Payload| +-------+ PE1 +------------+ P1 +------------+ PE2 +-------+ ]]>
The PE and P routers are configured to use the prefix AA::/64 as NPI. The IPv6 address AA::1:0:0 is assigned to PE1 as the source address used for network slicing. And the lowest 32 bits of the address is reserved for NRP Selector Identifier. PE1 encapsulates the network NRP packet with an outer IPv6 header along with an SRH. The Source Address in the outer header is AA::1:0:5, in which the lowest 32 bits carries the NRP Selector Identifier 5. P1 checks the Source Address and finds it matching the NPI prefix AA::/64. So, P1 parses NRP Selector Identifier 5 from the Source Address, and uses the network resources associated with NRP Selector Identifier 5 to forward the packet. PE2 decapsulates the outer IPv6 header and SRH.
Backward Compatibility Backward compatibility differs based on the chosen NPI encoding method: o For NPI Option A (Traffic Class bit): This method is not backward compatible. Legacy routers that do not recognize the new semantic of the designated Traffic Class bit will forward packets based on the standard interpretation of the header fields. They will not perform NRP-specific processing. Successful end-to-end NRP forwarding requires all routers along the path to be upgraded and configured to interpret the NPI bit correctly. o For NPI Option B (Source Address Prefix): This method offers better backward compatibility. Legacy routers forward packets based on the destination address and standard routing rules. They treat the source address as a regular IPv6 address and ignore any NRP semantics. Therefore, packets can traverse legacy nodes without issue, provided the path is otherwise valid. Only nodes that are explicitly configured to recognize the designated NPI prefix will inspect the source address, extract the NRP Selector Identifier from its lower bits, and apply NRP-specific forwarding policies. This allows for incremental deployment within an SR domain. In both cases, ingress PEs that are not NRP-aware will not set the NPI or encode a NRP Selector Identifier. NRP-aware transit routers will not attempt to classify such packets into a NRP and will forward them using default resources.
Security Considerations The encoding mechanism defined in this document does not introduce new vulnerabilities or attack vectors to the SRv6 architecture. The security considerations discussed herein are inherent to the operation of network slicing and the use of source routing within a trusted domain, and they map to existing security paradigms for IPv6 and Segment Routing. o Interaction with Legacy Nodes (NPI Option A): If NPI Option A (Traffic Class bit) is deployed, the risk of misforwarding by legacy nodes stems from reusing an existing field in a new way. This is a well-understood interoperability and incremental deployment consideration. Networks requiring end-to-end NRP consistency must ensure path continuity, which may involve upgrading legacy nodes or selecting paths that exclude them. o Address Space Management (NPI Option B): The need to carefully manage the address block used as the NPI Prefix to avoid overlap is a standard network planning requirement for any IPv6 deployment. It does not represent a new security flaw but emphasizes operational best practices.
IANA Considerations TBD
References Normative References Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Informative References IPv6 Segment Routing Header (SRH) 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. Segment Routing over IPv6 (SRv6) Network Programming 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. A Framework for Network Slices in Networks Built from IETF Technologies This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Realizing Network Slices in IP/MPLS Networks This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers.