BGP Extensions for Network Resource Partition

Abstract

Existing approaches bind a Segment Routing (SR) Policy to a Network Resource Partition (NRP) on a one-to-one basis, which lacks flexibility and introduces significant operational overhead as the number of NRPs scales, especially when multiple NRPs share the same SR Policy path.¶

This document defines BGP extensions to advertise NRP Identifier (NRP ID) information within BGP Update messages between headend and endpoint nodes. It decouples SR Policies from NRPs, allowing multiple NRPs to share a common SR Policy path and avoiding linear growth of SR Policies.¶

The proposed design reduces operational complexity and also applies to SR Best Effort (SR BE) scenarios.¶

1. Introduction

In 5G and future heterogeneous network scenarios, network slicing is a core technology for delivering differentiated services. Network Resource Partition (NRP) [RFC9543] is a foundational underlay component for network slicing. NRP is logically partitions physical network resources to provide dedicated resource allocation and Quality of Service (QoS) isolation for diverse services, meeting performance requirements such as low latency and high reliability. Throughout this document, the terms NRP, network resource partition, network slicing, and network slice are conceptually equivalent. Accordingly, the Network Resource Partition Identifier (NRP ID) and Network Slice Identifier (NS ID) may be used interchangeably to refer to the unique identifier of a corresponding slice resource.¶

[I-D.ietf-teas-ns-ip-mpls] introduces the concepts of the NRP Selector ID and NRP ID. The NRP Selector ID is a dedicated identifier representing an NRP Selector, which consists of one or more fields in a packet's network-layer header used to map the packet to an NRP. The NRP ID is an identifier that is globally unique within an NRP domain and can be used in the control or management plane to identify resources associated with the NRP.¶

A dedicated NRP selector ID MUST be carried in data packets to identify the associated NRP, so that the packets are processed and forwarded over the network resources allocated to that NRP. A control plane mechanism is required to inform the ingress PE node of the NRP ID that it MUST encapsulate within data packets to serve as the NRP selector ID.¶

[I-D.ietf-idr-sr-policy-nrp] provides one such control plane mechanism. It binds NRPs to Segment Routing (SR) Policies [RFC9256] and extends BGP SR Policy [RFC9830] to distribute the NRP ID bound to a SR Policy at instantiation. This scheme enforces a one-to-one mapping between SR Policies and NRPs. While suitable for small deployments, it prohibits path sharing across network slices and scales poorly: SR Policy count grows linearly with slice count, driving high operational and maintenanceoverhead. NRP and slicing scalability challenges are analyzed in [I-D.ietf-teas-nrp-scalability].¶

To address these limitations, this document proposes an alternative control plane mechanism that decouples SR Policies from NRPs, so multiple NRPs can share one SR Policy path. This eliminates the linear scaling of SR Policy instances and substantially improves the scalability of SR-based network slice deployments. The core design principle is that it is the service—not the SR Policy—that requires NRP, i.e., NRPs are associated with services, not with SR Policies.¶

Instead of extending the BGP SR Policy protocol, this document defines BGP [RFC4760] extensions to advertise NRP ID information in BGP Updates between headend and endpoint nodes via a new NRP ID Extended Community attribute. Similar to the Color Extended Community, slice information is distributed along with BGP route updates for the service, enabling automated traffic steering into the corresponding slices. Multiple slices can reuse the same SR Policy path, so SR Policy instances no longer scale with the number of slices and operational complexity is reduced.¶

The decoupling mechanism also applies to SR Best Effort (BE) scenarios where SR Policies are not used. SR Policy is also referred to as SR TE (Traffic Engineering) mode or TE mode in this document.¶

This document does not change any existing data plane encapsulation and processing mechanisms. Existing data plane solutions remain applicable, including [I-D.ietf-6man-enhanced-vpn-vtn-id] and [I-D.cheng-spring-srv6-encoding-network-sliceid].¶

2. NRP ID Extended Communities Attribute

To indicate service traffic to be steered into the corresponding NRP for forwarding, and decouple NRPs from SR Policies, this document proposes to use BGP Extended Communities Attribute [RFC4360] to carry NRP ID. This enables the associative mapping between service 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:¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type high(0x03)|   Type low(*) |        Reserved(2 octets)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           NRP ID(4 octets)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 an NRP, indicating the matching service traffic to be steered into the corresponding NRP for forwarding.¶

3. 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. Either node acting as a BGP speaker MAY originate BGP Update messages carrying NRP ID for its locally advertised routes. Intermediate nodes transparently forward BGP update messages containing the NRP ID Extended Communities Attribute without performing any NRP-specific processing.¶

The endpoint node constructs BGP Update messages containing route information and NRP ID information per service requirements, and sends them to the headend node. For TE mode, these messages MUST additionally include Color information in the Color Extended Community defined in [RFC9012] to indicate that service traffic SHALL be forwarded over the corresponding SR Policy. For BE mode, only route information and NRP ID information need to be carried.¶

When the endpoint node generates BGP Update messages with network slice information, it MUST encode the NRP ID within the NRP ID Extended Communities Attribute in accordance with the encoding format specified in Chapter 2 of this document.¶

After receiving such BGP Update messages, the headend node 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. This association is used for subsequent traffic encapsulation and slice steering, ensuring the correct forwarding and management of routes. The specific data structure used to associate the routes and the NRPs is implementation-specific and thus out of the scope of this document.¶

4. Traffic Forwarding

The traffic forwarding process involves the headend node, intermediate nodes, and the endpoint node.¶

Headend Node: When the headend node receives a service packet, it performs a FIB lookup. If the matched route entry includes an NRP ID, the headend node MUST encapsulate the service packet appropriately. For instance, the packet may be encapsulated with an outer IP header, and the NRP ID is carried in either the source IP address field or an extension header of this outer header. The encapsulated packet is then forwarded to the network slice corresponding to the NRP ID (e.g., a bandwidth-guaranteed VLAN). In TE mode, the packet is further encapsulated in accordance with the matched SR Policy together with the NRP ID. The resulting encapsulated packet is forwarded per the SR Policy, with resource guarantees enforced based on the NRP ID.¶

Intermediate Node: Upon receiving a service packet carrying an NRP ID, the intermediate node processes the packet based on the destination IP address and the embedded NRP ID. First, the intermediate node extracts the destination IP address and performs a local FIB lookup to select the Layer 3 egress interface for basic IP forwarding. If the destination address is a Segment Identifier (SID), forwarding follows the defined SID behavior. Second, the intermediate node extracts the NRP ID from the packet and forwards the packet to the corresponding network slice 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. The packet is then forwarded to the next hop via the assigned slice resource, enforcing slice-specific resource guarantees.¶

Endpoint Node: When receiving a service packet with an NRP ID, the endpoint node performs network slice decapsulation on 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 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.¶

7. References