BGP Extensions for Network Resource Partition

Introduction In 5G and future heterogeneous network scenarios, network slicing serves as the core technology for supporting differentiated services. Network Resource Partition (NRP), which underpins network slicing at the underlying layer, is officially defined in . explicitly delineates the core positioning and operational framework of NRP; through the logical partitioning of physical network resources, NRP achieves the guarantee and isolation of resource allocation and Quality of Service (QoS) for diverse services, and can thus meet differentiated service level objectives such as low latency and high reliability. NRP and network slicing are conceptually equivalent throughout this document. binds NRPs to Segment Routing (SR) Policies . In this approach, one SR Policy corresponds to one NRP, and the NRP identifier (NRP ID) associated with the SR Policy is distributed together when the SR Policy is created, via the extended BGP SR Policy protocol . Since the paths of SR Policies cannot be shared among multiple network slices, this solution lacks flexibility. As the number of network slices in the network increases, the number of SR Policies needs to be expanded accordingly, imposing heavy burdens on network maintenance. To address the aforementioned drawbacks, this document introduces NRP ID Extended Communities Attribute to the BGP protocol , which decouples SR Policies from NRPs. In this way, network elements can advertise network slice information to each other while exchanging routes through the BGP protocol, enabling automatic traffic steering to the corresponding network slices. Meanwhile, this document supports the sharing of a common SR Policy path by multiple network slices. When the number of network slices in the network grows, the number of SR Policies does not need to increase in a one-to-one ratio, thus reducing the complexity of network maintenance. Owing to the decoupling of SR Policies and network slices, the approach introduced in this document is also applicable to the SR Best Effort (BE) scenarios where SR Policies are not deployed.

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.

BGP Extended Communities Attribute for NRP ID To support automatic traffic steering to NRP, and decouple NRP from SR Policy, this document proposes to use BGP Extended Communities Attribute to carry NRP ID , thereby enabling the associative mapping between routes and NRPs. This BGP Extended Communities Attribute is a Transitive Opaque Extended Community, designated as NRP ID Extended Communities Attribute. Its detailed encoding structure is as follows:

NRP ID Extended Communities Attribute Where: Type high(1 octet): The value of this field is 0x03, which indicates it is transitive. Type low(1 octet): The value of this field is to be assigned by IANA, together with Type High, indicating that this Extended Communities Attribute is the NRP ID Extended Communities Attribute, which carries the NRP ID in the value field. Reserved(2 octets): reserved for future extension. This field SHOULD be set to zero on transmission and MUST be ignored on receipt. NRP ID (4 octets): carry the unique identifier of a NRP.

Route Advertisement The route advertisement process involves only the headend node and the endpoint node of NRP traffic. The two nodes complete the advertisement and association of NRP ID through the BGP protocol with NRP ID Extended Communities Attribute. As the initiator of BGP routes, the headend node or the the endpoint node constructs BGP messages that contain route information and NRP ID according to service requirements. For Traffic Engineering (TE) mode, Color information needs to be additionally carried in BGP messages (within Color Extended Community ), which is used to map to the corresponding SR Policy. For Best Effort (BE) mode, only route information and NRP ID need to be carried. When BGP speaker generates BGP update messages with network slice information, it needs to carry the NRP ID in the NRP ID Extended Communities Attribute in accordance with the format defined in Chapter 2 of this document. After receiving such BGP update messages, the BGP speaker recognizes the NRP ID Extended Communities Attribute by the values of Type high and Type low. It MUST ignore the value of the Reserved field and extract the network slice identifier (i.e., NRP ID) from the NRP ID field. The generated Routing Information Base (RIB) and Forwarding Information Base (FIB) MUST include the NRP ID to maintain the association between routes and corresponding NRPs, ensuring the correct forwarding and management of routes. The specific data structure used to associate the routes and the NRPs is is implementation-specific and thus out of the scope of this document.

Traffic Forwarding The traffic forwarding process involves the headend node, intermediate nodes, and the endpoint node. Headend Node: When the headend node receives a packet matching the BGP route corresponding to the target slice, it MUST extract the NRP ID associated with the route, and encapsulate the packet accordingly (for example, encapsulate the NRP ID into the source IP field of the packet or the IPv6 extension header). The encapsulated packet is then forwarded to the forwarding path corresponding to the NRP ID (such as a VLAN with bandwidth guarantee). In TE mode, the packet is encapsulated in accordance with the matching SR Policy together with the NRP ID, and the encapsulated packet is forwarded based on the SR Policy with resources guaranteed according to the NRP ID. Intermediate Node: After receiving a packet with NRP ID, the intermediate node needs to perform corresponding operations based on the destination IP address and NRP ID in the packet. First, it needs to determine the Layer 3 egress interface: extract the destination IP address of the packet, look up the local FIB table, and determine the Layer 3 egress interface of the packet according to the route matching result to complete basic route forwarding. If the destination IP address of the packet is a SID, the packet is forwarded based on the functional behavior of the SID. At the same time, the intermediate node extracts the NRP ID from the packet and forwards the packet to the corresponding network slice resources in the determined Layer 3 egress interface (such as slice sub-interfaces, slice queues, etc.) according to the locally configured mapping between NRP ID and network slice resources. Through these network slice resources, the packet reaches the next-hop node, thereby realizing resource guarantee and forwarding of slice traffic. Endpoint Node: After receiving a packet with NRP ID, the endpoint node decapsulates the packet, i.e., strips the outer packet header containing the NRP ID, and forwards the inner packet accordingly. In TE mode, the received packet is with SR Policy encapsulation, the endpoint node strips the outer packet header corresponding to the SR Policy encapsulation and processes the inner packet based on the functional behavior of the SID in the destination field of the stripped outer header.

IANA Considerations IANA is requested to assign the following code point from the subregistry of "BGP Transitive Extended Community Types" in the registry of "Border Gateway Protocol (BGP) Extended Communities" :

Code Point for the BGP message

Security Considerations The security considerations specified in 、 and apply to this document. This document introduces no new security considerations.