Carrying NRP Identifier and related information in MPLS Packet
draft-li-mpls-enhanced-vpn-vtn-id-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhenbin Li , Jie Dong | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-mpls-enhanced-vpn-vtn-id-04
Network Working Group Z. Li
Internet-Draft J. Dong
Intended status: Standards Track Huawei Technologies
Expires: 24 April 2025 21 October 2024
Carrying NRP Identifier and related information in MPLS Packet
draft-li-mpls-enhanced-vpn-vtn-id-04
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li & Dong Expires 24 April 2025 [Page 1]
Internet-Draft NRP ID in MPLS October 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Carrying NRP Information in MPLS Packet . . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NRP Extension Header Insertion . . . . . . . . . . . . . 5
3.2. NRP based Packet Forwarding . . . . . . . . . . . . . . . 5
4. Capability Advertisement and Negotiation . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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.
Li & Dong Expires 24 April 2025 [Page 2]
Internet-Draft NRP ID in MPLS October 2024
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].
1.1. 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
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Carrying NRP Information in MPLS Packet
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:
Li & Dong Expires 24 April 2025 [Page 3]
Internet-Draft NRP ID in MPLS October 2024
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.
Li & Dong Expires 24 April 2025 [Page 4]
Internet-Draft NRP ID in MPLS October 2024
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.
3. Procedures
3.1. NRP Extension Header Insertion
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.
3.2. NRP based Packet Forwarding
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.
Li & Dong Expires 24 April 2025 [Page 5]
Internet-Draft NRP ID in MPLS October 2024
The egress node of the MPLS LSP SHOULD pop the NRP extension header,
together with other post-stack extension headers if there is any.
4. Capability Advertisement and Negotiation
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.
5. IANA Considerations
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
6. Security Considerations
TBD
7. Contributors
Zhibo Hu
Email: huzhibo@huawei.com
8. Acknowledgements
The authors would like to thank Loa Andersson for the review and
comments.
9. References
9.1. Normative References
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Network Resource Partition (NRP) based
Enhanced Virtual Private Networks", Work in Progress,
Li & Dong Expires 24 April 2025 [Page 6]
Internet-Draft NRP ID in MPLS October 2024
Internet-Draft, draft-ietf-teas-enhanced-vpn-20, 14 June
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-enhanced-vpn-20>.
[I-D.song-mpls-extension-header]
Song, H., Zhou, T., Andersson, L., Zhang, Z. J., and R.
Gandhi, "MPLS Network Actions using Post-Stack Extension
Headers", Work in Progress, Internet-Draft, draft-song-
mpls-extension-header-13, 11 October 2023,
<https://datatracker.ietf.org/doc/html/draft-song-mpls-
extension-header-13>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
9.2. Informative References
[I-D.ietf-teas-nrp-scalability]
Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra,
"Scalability Considerations for Network Resource
Partition", Work in Progress, Internet-Draft, draft-ietf-
teas-nrp-scalability-05, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
nrp-scalability-05>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
Li & Dong Expires 24 April 2025 [Page 7]
Internet-Draft NRP ID in MPLS October 2024
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Email: lizhenbin@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Email: jie.dong@huawei.com
Li & Dong Expires 24 April 2025 [Page 8]