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 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.¶

[I-D.ietf-idr-sr-policy-nrp] binds NRPs to Segment Routing (SR) Policies [RFC9256]. [I-D.ietf-idr-sr-policy-nrp] extends the BGP SR Policy protocol [RFC9830] to distribute the NRP Identifier (NRP ID) associated with a SR Policy when the SR Policy is created. Per this approach, each SR Policy is associated with exactly one NRP. This model works well for small-scale deployments with a limited number of NRPs, but it prevents multiple network slices from sharing a single SR Policy path and thus suffers from poor scalability. As the number of network slices increases, the required number of SR Policies grows linearly, resulting in significant operational and maintenance overhead. Scalability issues for NRP and network slicing deployments are prominent and further discussed in [I-D.ietf-teas-nrp-scalability].¶

This document proposes a mechanism to decouple SR Policies from NRPs, allowing multiple NRPs to 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 Update messages between headend and endpoint nodes. A new NRP ID Extended Communities Attribute is defined, which enables network nodes to exchange network slice information during conventional BGP route propagation, facilitating automatic traffic steering into the corresponding network slices. Furthermore, this design supports the sharing of a common SR Policy path by multiple network slices. When network slice scale expands, the number of SR Policies no longer needs to increase proportionally, effectively reducing overall network operational complexity.¶

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.¶

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. 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, 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 a new packet header, and the NRP ID is placed in either the source IP field or an extension header of this new 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