]> Advertising Network Resource Partition (NRP) Policy in BGP Huawei Technologies
No. 156 Beiqing Road Beijing China jie.dong@huawei.com
Huawei Technologies
No. 156 Beiqing Road Beijing China zhangka@huawei.com
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District Beijing China gongliyan@chinamobile.com
Routing IDR Internet-Draft A Network Resource Partition (NRP) is a subset of the network resources and the 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 or RFC 9543 network slice services. For the instantiation of an NRP, NRP-specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy. This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality.
Introduction discusses the general framework, the components, and interfaces for requesting and operating network slices using IETF technologies. also introduces the concept of the Network Resource Partition (NRP), which is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network. An NRP can be to support one or a group of RFC 9543 network slice services. specifies the framework of NRP-based enhanced VPNs and describes the candidate component technologies in different network planes and network layers. Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. RFC 9543 Network Slice is considered as one target use case of enhanced VPNs. An NRP could be used as the underlay of one or a group of enhanced VPN services. To meet the requirement of network slice or enhanced VPN services, a number of NRPs can be created, each with a subset of network resources allocated on network nodes and links in a customized topology of the physical network. The NRP-specific resource and policy information need to be advertised to the set of network nodes involved in the NRP, so that the NRP-specific state can be created, and NRP-specific behavior can be enabled. Such information may be advertised by a network controller, a BGP route reflector, or a BGP speaker which is responsible for the NRP instantiation. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy . This document specifies the BGP extensions for advertising NRP Policy to the set of network nodes and links. The NRP information is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of BGP Link-State (BGP-LS) Address Family, this allows to reuse the TLVs defined for BGP-LS without impacting the base BGP and BGP-LS functionality.
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 Extensions for NRP Policy Advertisement According to , each NRP consists of a subset of network resources and the associated policies on a set of links in the underlay network. BGP-LS defines the mechanisms for the advertisement of Node, Link, and Prefix NLRI types and their associated attributes via BGP. The NRP-specific resource and policy information can be described as NRP-specific node and link attributes. This document introduces a BGP subsequent address family (SAFI) called "NRP Policy" for the BGP-LS address family. The SAFI value is TBD1. The encoding of the NRP Policy NLRI and the associated attributes are described in the following sub-sections.
BGP NRP Policy NLRI The format of the BGP-LS NLRI is reused for the NRP Policy NLRI. And the encoding of BGP-LS NLRI type "NRP-link" as defined in is reused for the NRP Policy Link NLRI. The definition of other NRLI Types for NRP Policy NLRI is for further study. The format of NRP Policy Link NLRI is shown as below:
Encoding of NRP-Policy NLRI
Encoding of NRP-Policy Link NLRI
The encoding and semantics of Protocol-ID, Identifier, Local Node Descriptors, Remote Node Descriptors and the Link Descriptors are the same as defined in . The NRP Descriptors TLV as defined in is reused in the NRP Policy NLRI. It contains descriptors of the NRP which the link participates in. This is a mandatory TLV for NRP-Policy Link NLRI. The length of this TLV is variable. The value contains one or more NRP Descriptor sub-TLVs defined in . Among the NRP Descriptors Sub-TLVs, the NRP ID sub-TLV is mandatory in the NRP Descriptors. There MUST be only one instance of NRP ID Sub-TLV present in the NRP Descriptors.
NRP Policy Attribute The BGP-LS Attribute, when associated with an NRP Policy NLRI, is used for the advertisement of the information of the NRP Policy. The NRP Attribute TLVs as defined in are reused for the advertisement of NRP Policy information. Specifically, the following NRP Attribute TLVs can be carried in BGP-LS Attribute which is associated with an NRP Policy NLRI. BGP-LS Attribute TLVs used for NRP Policy
TLV Code Point Description Length
1089 Maximum Link Bandwidth 4
TBD NRP Hierarchy 4
The Maximum Link Bandwidth TLV as defined in is used as an NRP Policy Attribute TLV to indicate the set of link bandwidth to be allocated to an NRP. It is mandatory in the BGP-LS Attribute which is associated with an NRP-Policy NLRI. The NRP Hierarchy Attribute TLV as defined in is used to indicate the Hierarchy of the NRP. When an NRP is derived from another NRP (called parent NRP), the Parent NRP ID TLV as defined in is used to carry the identifier of the parent NRP. Other link attributes MAY also be used as NRP Policy Link Attribute TLVs. The details are for further study.
NRP Policy Operations This section describes the operation of BGP based NRP Policy. BGP is used for the origination and propagation of the NRP Policy information, while the installation and use of NRP Policy are out of the scope of BGP.
Advertisement of NRP Policy The NRP Policy information used for NRP instantiation can be computed by a network controller, or derived from the NRP Policy information received from a network slice controller, and originated by a BGP speaker. The NRP Policy information for each network node involved in the NRP could be different. In order to control the target nodes to receive a specific NRP Policy NLRI, one or more Node Target extended communities SHOULD be attached to the NRP Policy NLRI, where each node target identifies the intended nodes for the advertised NRP Policy information. If the originator has direct BGP peer relationship with an target node of the NRP Policy, the NRP Policy NLRI can be advertised directly to the node, in such a case, the node target extended community MAY not be attached, and the NO_ADVERTISE community MUST be attached.
Reception of NRP Policy On reception of an NRP Policy NLRI, a BGP speaker first determines if the NRP Policy is valid and eligible. An NRP Policy is considered valid and eligible if the following checks are passed. a. The NRP Policy NLRI and the associated BGP-LS Attribute pass the syntactic validation as described in Section 8.2.2 of }. b. The BGP Update message of NRP Policy NLRI contains either a node target extended community which identifies the local node, or a NO_ADVERTISE community. c. The NRP Policy Link NLRI identifies a local interface of the network node. d. The bandwidth value of the Maximum link bandwidth TLV in the BGP-LS Attribute is smaller than the unreserved bandwidth of the interface. If the NRP Policy Link NLRI is considered valid and eligible, the BGP speaker performs the decision process for selection of the best route. The selected best route of NRP Policy Link NLRI is used to instantiate the NRP-specific state and behavior on the selected interface of the network node. If one or more node targets are present and none of them matches the local BGP identifier, then the NRP Policy NLRI is not usable on the receiver node.
Propagation of NRP Policy NRP Policy NLRIs that have the NO_ADVERTISE community attached to them MUST NOT be propagated further. The propagation of NRP Policy NLRIs which are attached with one or more node target extended communities SHOULD follow the rules as specified in .
Security Considerations The security considerations in and apply to this document.
IANA Considerations IANA is requested to assign a new code point for SAFI "NRP Policy" under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. BGP SAFI Code Point
Value Description Reference
TBD1 NRP Policy This document
Acknowledgements The authors would like to thank XXX for the review and discussion of this document.
References Normative References 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. A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks Huawei University of Surrey China Mobile KDDI Corporation Samsung This document describes the framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). An NRP represents a subset of network resources and associated policies in the underlay network. NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work. 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. Distribution of Link-State and Traffic Engineering Information Using BGP In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. BGP Link State Extensions for Scalable Network Resource Partition Huawei Technologies China Telecom China Telecom Huawei Technologies Huawei Technologies Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. 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. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. BGP Extended Community for Identifying the Target Nodes Huawei Technologies Huawei Technologies Nokia Nvidia BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose. A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Informative References Realizing Network Slices in IP/MPLS Networks Cisco Systems Inc. Juniper Networks Huawei Technologies Comcast Cisco Systems Inc. Ericsson ZTE Corporation ZTE Corporation IBM Corporation Telefonica Ciena Verizon Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. 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 relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets.