idnits 2.17.00 (12 Aug 2021) /tmp/idnits28525/draft-li-mpls-enhanced-vpn-vtn-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 268 has weird spacing: '...dicator thi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7274' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'TS23501' is defined on line 360, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-08 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft J. Dong 4 Intended status: Standards Track Huawei Technologies 5 Expires: 8 September 2022 7 March 2022 7 Carrying Virtual Transport Network Identifier in MPLS Packet 8 draft-li-mpls-enhanced-vpn-vtn-id-02 10 Abstract 12 A Virtual Transport Network (VTN) is a virtual network which has a 13 customized network topology and a set of dedicated or shared network 14 resources allocated from the underlying network infrastructure. 15 Multiple VTNs can be created by network operator for using as the 16 underlay for one or a group of VPNs services to provide enhanced VPN 17 (VPN+) services. In packet forwarding, some fields in the data 18 packet needs to be used to identify the VTN the packet belongs to, so 19 that the VTN-specific processing can be executed. In the context of 20 network slicing, a VTN can be instantiated as a Network Resource 21 Partition (NRP). 23 This document proposes a mechanism to carry the VTN-ID in an MPLS 24 packet to identify the VTN the packet belongs to. The procedure for 25 processing the VTN ID is also specified. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Carrying VTN Information in MPLS Packet . . . . . . . . . . . 3 63 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. VTN Header Insertion . . . . . . . . . . . . . . . . . . 5 65 4.2. VTN based Packet Forwarding . . . . . . . . . . . . . . . 5 66 5. Capability Advertisement and Negotiation . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 10.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Virtual Private Networks (VPNs) provide different groups of users 79 with logically isolated connectivity over a common shared network 80 infrastructure. With the introduction of 5G, new service types may 81 require connectivity services with advanced characteristics comparing 82 to traditional VPNs, such as strict isolation from other services or 83 guaranteed performance. These services are refered to as "enhanced 84 VPNs" (VPN+). [I-D.ietf-teas-enhanced-vpn] describes a framework and 85 candidate component technologies for providing VPN+ services. 87 The enhanced properties of VPN+ require integration between the 88 overlay connectivity and the characteristics provided by the underlay 89 network. To meet the requirement of enhanced VPN services, a number 90 of Virtual Transport Networks (VTNs) need to be created, each 91 consists of a subset of the underlay network topology and a set of 92 network resources allocated from the underlay network to meet the 93 requirement of one or a group of VPN+ services. In the network, 94 traffic of different VPN+ services may to be processed separately 95 based on the topology and the network resources associated with the 96 corresponding VTN. [I-D.ietf-teas-ietf-network-slices] introduces 97 the concept Network Resource Partition (NRP) as a set of network 98 resources that are available to carry traffic and meet the SLOs and 99 SLEs. In the context of network slicing, a VTN can be instantiated 100 as a Network Resource Partition (NRP). 102 For network scenarios where a large number of VTNs need to be created 103 and maintained, [I-D.dong-teas-nrp-scalability] describes the 104 scalability considerations for VTN. One approach to improve the data 105 plane scalability is introducing a dedicated VTN Identifier (VTN-ID) 106 in data packets to identify the VTN the packets belong to, so that 107 VTN-specific packet processing can be performed by network nodes. 109 This document proposes a mechanism to carry the VTN Identifier (VTN- 110 ID) and the related information in MPLS [RFC3031] data packets, so 111 that the packet will be processed by network nodes using the set of 112 network resources allocated to the corresponding VTN. The procedure 113 for processing the VTN-ID is also specified. The forwarding path of 114 the MPLS LSP is determined using the MPLS label stack in the packet, 115 and the set of local network resources used for processing the packet 116 is determined by the VTN-ID. The mechanism introduced in this 117 document is applicable to both MPLS networks with RSVP-TE [RFC3209] 118 or LDP [RFC5036] LSPs, and MPLS networks with Segment Routing (SR) 119 [RFC8402] [RFC8660]. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 127 appear in all capitals, as shown here. 129 3. Carrying VTN Information in MPLS Packet 131 This document defines a new VTN extension header which is used to 132 carry the VTN-ID and other VTN related information. In an MPLS 133 packet, The VTN extension header follows the MPLS label stack, and 134 precedes the header and payloads in the upper layer. The format of 135 VTN extension header is shown as below: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |Nibble | Length| Flags | Reserved | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 ~ Options ~ 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1. The format of MPLS VTN Extension Header 146 Where: 148 * Nibble: The first 4-bit field is set to the binary value 0010. 149 This is to ensure that the VTN extension header will not be 150 interpreted as an IP header or the ACH of pseudowire packet. 152 * Length: Indicate the length of the VTN extension header in 32-bit 153 words. 155 * Flags: 8-bit Flags field. All the flags are reversed for future 156 use. This field SHOULD be set to zero on transmission and MUST be 157 ignored on receipt. 159 * Reserved: 16-bit field reserved for future use. 161 A new VTN-ID Option is defined in this document, other option types 162 may be defined in future documents. The format of the VTN-ID Option 163 is shown as below: 165 Option Option Option 166 Type Data Len Data 167 +--------+--------+--------+--------+--------+--------+ 168 |BBCTTTTT|00000100| VTN-ID | 169 +--------+--------+--------+--------+--------+--------+ 170 Figure 2. The format of VTN-ID Option 172 Option Type: 8-bit identifier of the type of option. The type of 173 VTN-ID option is to be assigned by IANA. The highest-order bits of 174 the type field are defined as below: 176 * BB 00 The highest-order 2 bits are set to 00 to indicate that a 177 node which does not recognize this type will skip over it and 178 continue processing the header. 180 * C 1 The third highest-order bit are set to 1 to indicate this 181 option may change en route. 183 Opt Data Len: 8-bit unsigned integer indicates the length of the 184 option Data field of this option, in octets. The value of Opt Data 185 Len of the VTN-ID option SHOULD be set to 4. 187 Option Data: 4-octet identifier which uniquely identifies a VTN 188 within a network domain. 190 A new MPLS special-purpose label or extended special-purpose label is 191 defined as the VTN Extension Header Indicator (VEHI), its value is to 192 be assigned by IANA. The VEHI label is used to indicate the 193 existence of the VTN Extension Header after the MPLS label stack in 194 the packet. The position of the VEHI label in the MPLS label stack 195 is not limited. 197 The benefit of introducing the MPLS VTN Extension Header to carry the 198 VTN-ID and the related information is that it provides the 199 flexibility to encode information which cannot be accomodated in an 200 MPLS label (20-bit), and the length of the header can be variable. 202 4. Procedures 204 4.1. VTN Header Insertion 206 When the ingress node of an LSP receives a packet, according to 207 traffic classification or mapping policy, the packet is steered into 208 one of the VTNs in the network, then a VTN header SHOULD be inserted 209 into the packet, and the VTN-ID which the packet is mapped to SHOULD 210 be carried in the VTN header. The ingress node SHOULD also 211 encapsulates the packet with an MPLS label stack which are used to 212 determine the path traversed by the LSP. The VHI label SHOULD be 213 inserted in the label stack to identify the existence of the VTH 214 header. 216 4.2. VTN based Packet Forwarding 218 On receipt of a MPLS packet which carries the VHL and the VTN header, 219 network nodes which support the mechanism defined in this document 220 SHOULD scan the label stack to figure out the existence of the VHL. 221 If there is a VHL in the label stack, then the network node SHOULD 222 parse the VTN header and use the VTN-ID to identify the VTN the 223 packet belongs to, and use the local resources allocated to the VTN 224 to process and forward the packet. The forwarding behavior is based 225 on both the top MPLS label and the VTN-ID. The top MPLS label is 226 used for the lookup of the next-hop, and the VTN-ID can be used to 227 determine the set of network resources allocated by the network nodes 228 for processing and sending the packet to the next-hop. 230 There can be different approaches used for allocating network 231 resources on each network node to the VTNs. For example, on one 232 interface, a subset of forwarding plane resource (e.g. bandwidth and 233 the associated buffer/queuing/scheduling resources) allocated to a 234 particular VTN can be considered as a virtual layer-2 sub-interface 235 with dedicated bandwidth and the associated resources. In packet 236 forwarding, the top MPLS label of the received packet is used to 237 identify the next-hop and the outgoing Layer 3 interface, and the 238 VTN-ID is used to further identify the virtual sub-interface which is 239 associated with the VTN on the outgoing interface. 241 Network nodes which do not support the mechanism in this document 242 SHOULD ignore the VHL and the VTN header, and forward the packet only 243 based on the top MPLS label. 245 The egress node of the MPLS LSP SHOULD pop the VEHL together with 246 other LSP labels, and decapsulate the VTN header. 248 5. Capability Advertisement and Negotiation 250 Before inserting the VTN header into an MPLS packet, the ingress node 251 MAY need to know whether the nodes along the LSP can process the VTN 252 header properly according to the mechanisms defined in this document. 253 This can be achieved by introducing the capability advertisement and 254 negotiation mechanism for the VTN header. The ingress node also need 255 to know whether the egress node of the LSP can remove the VTN header 256 properly before parsing the upper layer and send the packet to the 257 next hop. The capability advertisement and negotiation mechanism 258 will be described in a future version of this document. 260 6. IANA Considerations 262 IANA is requested to assign a new special-purpose label from the 263 "Special-Purpose MPLS Label Values" or "Extended Special-Purpose MPLS 264 Label Values" registry. 266 Value Description Reference 267 ------------------------------------------------------- 268 TBD VTN Extension Header Indicator this document 270 IANA is requested to assign a new option type of the MPLS VTN 271 extension header: 273 Value Description Reference 274 ------------------------------------------------- 275 TBD VTN-ID this document 277 7. Security Considerations 279 TBD 281 8. Contributors 283 Zhibo Hu 284 Email: huzhibo@huawei.com 286 9. Acknowledgements 288 TBD. 290 10. References 292 10.1. Normative References 294 [I-D.ietf-teas-enhanced-vpn] 295 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 296 Framework for Enhanced Virtual Private Network (VPN+) 297 Services", Work in Progress, Internet-Draft, draft-ietf- 298 teas-enhanced-vpn-09, 25 October 2021, 299 . 302 [I-D.ietf-teas-ietf-network-slices] 303 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 304 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 305 Network Slices", Work in Progress, Internet-Draft, draft- 306 ietf-teas-ietf-network-slices-08, 6 March 2022, 307 . 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 316 Label Switching Architecture", RFC 3031, 317 DOI 10.17487/RFC3031, January 2001, 318 . 320 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 321 and Retiring Special-Purpose MPLS Labels", RFC 7274, 322 DOI 10.17487/RFC7274, June 2014, 323 . 325 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 326 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 327 May 2017, . 329 10.2. Informative References 331 [I-D.dong-teas-nrp-scalability] 332 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 333 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 334 "Scalability Considerations for Network Resource 335 Partition", Work in Progress, Internet-Draft, draft-dong- 336 teas-nrp-scalability-01, 7 February 2022, 337 . 340 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 341 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 342 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 343 . 345 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 346 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 347 October 2007, . 349 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 350 Decraene, B., Litkowski, S., and R. Shakir, "Segment 351 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 352 July 2018, . 354 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 355 Decraene, B., Litkowski, S., and R. Shakir, "Segment 356 Routing with the MPLS Data Plane", RFC 8660, 357 DOI 10.17487/RFC8660, December 2019, 358 . 360 [TS23501] "3GPP TS23.501", 2016, 361 . 364 Authors' Addresses 366 Zhenbin Li 367 Huawei Technologies 368 Huawei Campus, No. 156 Beiqing Road 369 Beijing 370 100095 371 China 372 Email: lizhenbin@huawei.com 374 Jie Dong 375 Huawei Technologies 376 Huawei Campus, No. 156 Beiqing Road 377 Beijing 378 100095 379 China 380 Email: jie.dong@huawei.com