| Internet-Draft | NRP ID in MPLS | October 2024 |
| Li & Dong | Expires 24 April 2025 | [Page] |
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. Multiple NRPs can be created by network operator to meet the diverse requirements of enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet.¶
This document proposes a mechanism to carry the data plane NRP ID in an MPLS packet to identify the NRP the packet belongs to. The procedure for processing the data plane NRP ID is also specified.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Virtual Private Networks (VPNs) [RFC4206] provide different customers with logically isolated connectivity over a common network infrastructure. With the introduction and evolvement of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPNs, such as resource isolation from other services or guaranteed performance. Such kind of network service is called enhanced VPN [I-D.ietf-teas-enhanced-vpn]. Enhanced VPN service requires the coordination and integration between the overlay VPNs and the capability and resources of the underlay network. Enhanced VPN can be used, for example, to deliver network slice services as described in [RFC9543].¶
[RFC9543] 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.¶
In packet forwarding, traffic of different Enhanced VPN services needs to be processed separately based on the network resources and the logical topology associated with the corresponding NRP. [I-D.ietf-teas-nrp-scalability] describes the scalability considerations and the possible optimizations for providing a relatively large number of NRPs. The approach to improve the data plane scalability of NRP is to introduce a dedicated data plane NRP ID in the data packets to identify the set of network resources allocated to an NRP, so that the packets mapped to an NRP can be processed and forwarded using the NRP-specific network resources, which could avoid possible resource competition with services in other NRPs.¶
This document proposes a mechanism to carry the NRP Identifier (called data plane NRP ID) and the related information in MPLS [RFC3031] data packets, so that the packet will be processed by network nodes using the set of network resources allocated to the corresponding NRP. The procedure for processing the data plane NRP ID is also specified. The destination and forwarding path of the MPLS LSP is determined using the MPLS label stack in the packet, and the set of network resources used for processing the packet is determined by the NRP ID. The mechanism introduced in this document is applicable to both MPLS networks with RSVP-TE [RFC3209] or LDP [RFC5036] LSPs, and MPLS networks with Segment Routing (SR) [RFC8402] [RFC8660].¶
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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document makes use of the post stack extension header mechanism as defined in [I-D.song-mpls-extension-header]. A new type of MPLS extension header called "NRP extension header" is defined to carry the data plane NRP ID and other NRP related information. The type of NRP extension header is to be assigned by IANA. The format of NRP extension header is shown as below:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH | HLEN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data Plane NRP ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The format of MPLS VTN Extension Header¶
Where:¶
NH: 8-bit indicator for the Next Header type.¶
HLEN: 8-bit unsigned integer for the Extension Header Length in 4-octet units, not including the first 4 octets.¶
Flags: 8-bit flag field. The most significant bit is defined in this document.¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|U U U U U U U|
+-+-+-+-+-+-+-+-+¶
S (Strict Match): The S flag is used to indicate whether the NRP ID MUST be strictly matched for the processing of the packet. When the S flag in the NR option of a received packet is set to 1, if the NRP ID in the packet does not match with any of the network resources provisioned on the network node, the packet MUST be dropped. When the S flag in the NRP option of a received packet is set to 0, if the NRP ID in the packet does not match with any of the network resources provisioned on the network node, the packet MUST be forwarded using the default set of resource and behavior as if the NRP option does not exist.¶
U (Unused): These flags are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.¶
Reserved: 8-bit field reserved for future use.¶
Data Plane NRP ID: Network-wide identifier which uniquely identifies the set of network resources allocated to an NRP. The size of the NRP ID is determined by the value of HLEN.¶
The NRP extension header SHOULD be processed hop-by-hop (HBH). Thus it is suggested the NRP extension header be positioned in precedence over the end-to-end (E2E) extension headers.¶
The benefit of introducing the post-stack NRP Extension Header to carry the Data Plane NRP ID and related information is that it provides the flexibility to encode information which cannot be accommodated in an MPLS label stack, and the length of the extension header can be variable.¶
When the ingress node of an LSP receives a packet intended for NRP based forwarding, according to traffic classification or mapping policy, the packet is steered into one of the NRPs in the network, then an MPLS NRP extension header SHOULD be inserted into the Post-Stack extension headers of the packet, and the NRP ID which the packet is mapped to SHOULD be carried in the NRP header. The ingress node SHOULD also encapsulates the packet with an MPLS label stack which are used to determine the destination and path of the LSP.¶
On receipt of a MPLS packet which carries the NRP extension header, network nodes which support the mechanism defined in this document parse the NRP header and use the NRP ID to identify the NRP the packet belongs to, and use the local resources allocated to the NRP to process and forward the packet. The forwarding behavior is based on both the MPLS label stack and the NRP extension header. The top MPLS label is used for the lookup of the next-hop, and the NRP ID can be used to determine the set of network resources allocated by the network nodes for processing and sending the packet to the next-hop.¶
There can be different approaches used for allocating network resources on each network node to the NRPs. For example, on one interface, a subset of forwarding plane resource (e.g., bandwidth and the associated buffer/queuing/scheduling resources) allocated to a particular NRP can be considered as a virtual layer-2 sub-interface with dedicated bandwidth and the associated resources. In packet forwarding, the top MPLS label of the received packet is used to identify the next-hop and the outgoing Layer 3 interface, and the data plane NRP-ID is used to further identify the virtual sub-interface which is associated with the NRP on the outgoing interface.¶
Network nodes which do not support the mechanism in this document SHOULD ignore the NRP extension header, and forward the packet only based on the top MPLS label.¶
The egress node of the MPLS LSP SHOULD pop the NRP extension header, together with other post-stack extension headers if there is any.¶
Before inserting the NRP extension header into an MPLS packet, the ingress node MAY want to know whether the nodes along the LSP can process the NRP extension header properly based on the mechanisms defined in this document. This can be achieved by introducing the capability advertisement and negotiation mechanism for the NRP extension header. The ingress node also need to know whether the egress node of the LSP can remove the NRP extension header as part of the post-stack action header properly before parsing the upper layer and send the packet to the next hop. The capability advertisement and negotiation mechanism will be described in a future version of this document.¶
IANA is requested to assign the code point for a new type of MPLS extension header in the "MPLS extension headers registry" as below:¶
Value Description Reference ------------------------------------------------- TBD Data Plane NRP ID this document¶
Zhibo Hu Email: huzhibo@huawei.com¶
The authors would like to thank Loa Andersson for the review and comments.¶