BGP Link State Extensions for Scalable Network Resource Partition

Introduction 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. discusses the general framework, the components, and interfaces for requesting and operating network slices using IETF technologies. Network slice is considered as one target use case of enhanced VPNs. 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 associated with a logical network topology to select or specify the set of links and nodes involved. specifies the framework of NRP-based enhanced VPN and describes the candidate component technologies in different network planes and network layers. An NRP could be used as the underlay to meet the requirement of one or a group of enhanced VPN services. To meet the requirement of 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 information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. When an NRP spans multiple IGP areas or multiple Autonomous Systems (ASes), BGP-LS is needed to advertise the NRP information in each IGP area or AS to the network controller, so that the network controller could use the collected information to build the view of inter-area or inter-AS NRPs. This document specifies the 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.

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-LS Extensions for NRP Information Advertisement BGP-LS defines the mechanisms for advertisement of Node, Link, and Prefix Link-State NLRI types and their associated attributes via BGP. According to , each NRP consists of a set of dedicated or shared network resources on a connected set of links in the underlay network. Thus a NRP can be defined as the combination of a set of network attributes of network nodes and links, which include the topology attribute, resources attributes, etc. NRP is usually created based on the partitioning of network resources of network links, there are two possible ways for the advertisement of NRP-specific information. The first approach is to advertise the NRP information as link attributes of the layer-3 link using existing BGP-LS Link NLRI. However, this approach may have some scalability problem when the number of NRPs on a layer-3 link becomes large. First of all, the amount of NRP information associated with the link would increase in proportion to the number of NRPs the link participates in, and in some cases the NRP information may not be able to be accommodated in one BGP Update message. Secondly, for a specific link, when the information of only one NRP changes, the link NLRI and all the link attributes and all the associated NRP attributes need to be updated. This would result in unnecessary route advertisement. The second approach is to introduce dedicated BGP-LS NLRI type for the advertisement of NRP-specific information. This way, the information associated with each NRP can be advertised and updated separately. This can alleviate the burden of the problems with the first approach. Thus for better scalability, this document proposes the BGP-LS extensions and mechanisms of the second approach. The NRP information pertaining to a link is advertised via a new BGP-LS NLRI and the associated BGP-LS Attribute as follows:

The NRP Identification information and the identifiers of its associated link is carried using a new BGP-LS NRP Link NLRI.
The attributes of the NRP on the associated link are carried as TLVs of the associated BGP-LS Attribute.

This document focuses on the advertisement of NRP-specific information on the associated network links. The advertisement of NRP-specific information on the associated network nodes are for further study.

BGP-LS NRP Link NLRI A new BGP-LS NLRI type called "NRP-link" is defined for advertisement NRP-specific link information. The NLRI-Type is to be assigned by IANA (TBD1). Its format is shown as below:

Encoding of NRP-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 contains descriptors of the NRP which the link is associated with. This is a mandatory TLV for NRP-Link NLRIs. The type is to be assigned by IANA (TBD2). The length of this TLV is variable. The value contains one or more NRP Descriptor sub-TLVs defined in .

NRP Descriptors Sub-TLVs In this document, one NRP Descriptors sub-TLV is defined as below: NRP Descriptor Sub-TLVs

Sub-TLV Code Point	Description	Length
TBD3	NRP ID	4

NRP ID: A 32-bit network-wide unique identifier, which is used to identify an NRP the link is associated with. 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 Attribute TLVs The NRP Attribute TLVs are a set of TLVs that may be encoded in the BGP-LS Attribute associated with an NRP-Link NLRI. The following NRP Attribute TLVs can be carried as NRP attribute TLVs. NRP Attribute TLVs

TLV Code Point	Description	Length
1089	Maximum Link Bandwidth	4
TBD4	NRP Hierarchy	1
TBD5	Parent NRP ID	1

The Maximum Link Bandwidth TLV as defined in is used as an NRP Link Attribute TLV to indicate the amount of link bandwidth allocated to an NRP. It is mandatory in BGP-LS Attribute which is associated with an NRP-Link NLRI. Other link attributes MAY also be used as NRP Link Attribute TLVs. The details are for further study.

NRP-Hierarchy TLV A new NRP Attribute TLV is defined to carry the NRP Hierarchy information. The format of the NRP Hierarchy TLV is as below:

Encoding of NRP Hierarchy TLV Type (16 bits): TBD4. Length (16 bits): Length of the value field in octets. The value is 1. Hierarchy: Indicates the level to which the NRP belongs. When the value is 1, the NRP is a first-level NRP on the associated link. When the value is 2, the NRP is a second-level NRP on the associated link. By default, two levels of NRPs can be supported.

Parent NRP ID TLV When an NRP is derived from another NRP (called parent NRP), the Parent NRP ID TLV is used to carry the identifier of the parent NRP. The format of the Parent NRP ID TLV is as below:

Encoding of Parent NRP ID TLV Type (16 bits): TBD5. Length (16 bits): Length of the value field in octets. The value is 4. Parent NRP ID: The NRP ID of the parent NRP.

Security Considerations This document introduces no additional security vulnerabilities in addition to the ones as described in .

IANA Considerations IANA is requested to assign a new code point for "NRP-Link NLRI" under the "BGP-LS NLRI Types" Registry. NRP NLRI Type

Type	NLRI Type	Reference
TBD1	NRP Link NLRI	This document

IANA is requested to assign the following new code points for under the "BGP-LS NLRI and Attribute TLVs" Registry. NRP related TLV/Sub-TLVs

TLV Code Point	Description	Reference
TBD2	NRP Descriptors	This document
TBD3	NRP ID	This document
TBD4	NRP Hierarchy	This document
TBD5	Parent NRP ID	This document

Acknowledgements The authors would like to thank Mengkai Zhao and Tianle Zhang for the review and discussion of this document.