idnits 2.17.1 draft-li-mpls-enhanced-vpn-vtn-id-01.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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 263 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 (April 14, 2021) is 1080 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 299, but no explicit reference was found in the text == Unused Reference: 'TS23501' is defined on line 342, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 0 errors (**), 0 flaws (~~), 7 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: October 16, 2021 April 14, 2021 7 Carrying Virtual Transport Network Identifier in MPLS Packet 8 draft-li-mpls-enhanced-vpn-vtn-id-01 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. 21 This document proposes a mechanism to carry the VTN-ID in an MPLS 22 packet to identify the VTN the packet belongs to. The procedure for 23 processing the VTN ID is also specified. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 16, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Carrying VTN Information in MPLS Packet . . . . . . . . . . . 3 62 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. VTN Header Insertion . . . . . . . . . . . . . . . . . . 5 64 4.2. VTN based Packet Forwarding . . . . . . . . . . . . . . . 5 65 5. Capability Advertisement and Negotiation . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Virtual Private Networks (VPNs) provide different groups of users 78 with logically isolated connectivity over a common shared network 79 infrastructure. With the introduction of 5G, new service types may 80 require connectivity services with advanced characteristics comparing 81 to traditional VPNs, such as strict isolation from other services or 82 guaranteed performance. These services are refered to as "enhanced 83 VPNs" (VPN+). [I-D.ietf-teas-enhanced-vpn] describes a framework and 84 candidate component technologies for providing VPN+ services. 86 The enhanced properties of VPN+ require integration between the 87 overlay connectivity and the characteristics provided by the underlay 88 network. To meet the requirement of enhanced VPN services, a number 89 of Virtual Transport Networks (VTNs) need to be created, each 90 consists of a subset of the underlay network topology and a set of 91 network resources allocated from the underlay network to meet the 92 requirement of one or a group of VPN+ services. In the network, 93 traffic of different VPN+ services may to be processed separately 94 based on the topology and the network resources associated with the 95 corresponding VTN. 97 For network scenraios where a large number of VTNs need to be created 98 and maintained, [I-D.dong-teas-enhanced-vpn-vtn-scalability] 99 describes the scalability considerations for VTN. One approach to 100 improve the data plane scalability is introducing a dedicated VTN 101 Identifier (VTN-ID) in data packets to identify the VTN the packets 102 belong to, so that VTN-specific packet processing can be performed by 103 network nodes. 105 This document proposes a mechanism to carry the VTN Identifier (VTN- 106 ID) and the related information in MPLS [RFC3031] data packets, so 107 that the packet will be processed by network nodes using the set of 108 network resources allocated to the corresponding VTN. The procedure 109 for processing the VTN-ID is also specified. The forwarding path of 110 the MPLS LSP is determined using the MPLS label stack in the packet, 111 and the set of local network resources used for processing the packet 112 is determined by the VTN-ID. The mechanism introduced in this 113 document is applicable to both MPLS networks with RSVP-TE [RFC3209] 114 or LDP [RFC5036] LSPs, and MPLS networks with Segment Routing (SR) 115 [RFC8402] [RFC8660]. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 123 appear in all capitals, as shown here. 125 3. Carrying VTN Information in MPLS Packet 127 This document defines a new VTN header which is used to carry the 128 VTN-ID and other VTN related information. In an MPLS packet, The VTN 129 header follows the MPLS label stack, and precedes the header and 130 payloads in the upper layer. The format of VTN header is shown as 131 below: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |Nibble | Length| Flags | Reserved | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 ~ Options ~ 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1. The format of MPLS VTN Header 142 Where: 144 o Nibble: The first 4-bit field is set to the binary value 0010. 145 This is to ensure that the VTN header will not be interpreted as 146 an IP header or the ACH of pseudowire packet. 148 o Length: Indicate the length of the MPLS VTN header in 32-bit 149 words. 151 o Flags: 8-bit Flags field. All the flags are reversed for future 152 use. This field SHOULD be set to zero on transmission and MUST be 153 ignored on receipt. 155 o Reserved: 16-bit field reserved for future use. 157 A new VTN-ID Option is defined in this document, other option types 158 may be defined in future documents. The format of the VTN-ID Option 159 is shown as below: 161 Option Option Option 162 Type Data Len Data 163 +--------+--------+--------+--------+--------+--------+ 164 |BBCTTTTT|00000100| VTN-ID | 165 +--------+--------+--------+--------+--------+--------+ 166 Figure 2. The format of VTN-ID Option 168 Option Type: 8-bit identifier of the type of option. The type of 169 VTN-ID option is to be assigned by IANA. The highest-order bits of 170 the type field are defined as below: 172 o BB 00 The highest-order 2 bits are set to 00 to indicate that a 173 node which does not recognize this type will skip over it and 174 continue processing the header. 176 o C 1 The third highest-order bit are set to 1 to indicate this 177 option may change en route. 179 Opt Data Len: 8-bit unsigned integer indicates the length of the 180 option Data field of this option, in octets. The value of Opt Data 181 Len of the VTN-ID option SHOULD be set to 4. 183 Option Data: 4-octet identifier which uniquely identifies a VTN 184 within a network domain. 186 A new MPLS special-purpose label or extended special-purpose label is 187 defined as the VTN Header Indicator (VHI), its value is to be 188 assigned by IANA. The VHI label is used to indicate the existence of 189 the VTN Header after the MPLS label stack in the packet. The 190 position of the VHI label in the MPLS label stack is not limited. 192 The benefit of introducing the MPLS VTN header to carry the VTN-ID 193 and the related information is that it provides the flexibility to 194 encode information which cannot be accomodated in an MPLS label 195 (20-bit), and the length of the header can be variable. 197 4. Procedures 199 4.1. VTN Header Insertion 201 When the ingress node of an LSP receives a packet, according to 202 traffic classification or mapping policy, the packet is steered into 203 one of the VTNs in the network, then a VTN header SHOULD be inserted 204 into the packet, and the VTN-ID which the packet is mapped to SHOULD 205 be carried in the VTN header. The ingress node SHOULD also 206 encapsulates the packet with an MPLS label stack which are used to 207 determine the path traversed by the LSP. The VHI label SHOULD be 208 inserted in the label stack to identify the existence of the VTH 209 header. 211 4.2. VTN based Packet Forwarding 213 On receipt of a MPLS packet which carries the VHL and the VTN header, 214 network nodes which support the mechanism defined in this document 215 SHOULD scan the label stack to figure out the existence of the VHL. 216 If there is a VHL in the label stack, then the network node SHOULD 217 parse the VTN header and use the VTN-ID to identify the VTN the 218 packet belongs to, and use the local resources allocated to the VTN 219 to process and forward the packet. The forwarding behavior is based 220 on both the top MPLS label and the VTN-ID. The top MPLS label is 221 used for the lookup of the next-hop, and the VTN-ID can be used to 222 determine the set of network resources allocated by the network nodes 223 for processing and sending the packet to the next-hop. 225 There can be different approaches used for allocating network 226 resources on each network node to the VTNs. For example, on one 227 interface, a subset of forwarding plane resource (e.g. bandwidth and 228 the associated buffer/queuing/scheduling resources) allocated to a 229 particular VTN can be considered as a virtual layer-2 sub-interface 230 with dedicated bandwidth and the associated resources. In packet 231 forwarding, the top MPLS label of the received packet is used to 232 identify the next-hop and the outgoing Layer 3 interface, and the 233 VTN-ID is used to further identify the virtual sub-interface which is 234 associated with the VTN on the outgoing interface. 236 Network nodes which do not support the mechanism in this document 237 SHOULD ignore the VHL and the VTN header, and forward the packet only 238 based on the top MPLS label. 240 The egress node of the MPLS LSP SHOULD pop the VHL together with 241 other LSP labels, and decapsulate the VTN header. 243 5. Capability Advertisement and Negotiation 245 Before inserting the VTN header into an MPLS packet, the ingress node 246 MAY need to know whether the nodes along the LSP can process the VTN 247 header properly according to the mechanisms defined in this document. 248 This can be achieved by introducing the capability advertisement and 249 negotiation mechanism for the VTN header. The ingress node also need 250 to know whether the egress node of the LSP can remove the VTN header 251 properly before parsing the upper layer and send the packet to the 252 next hop. The capability advertisement and negotiation mechanism 253 will be described in a future version of this document. 255 6. IANA Considerations 257 IANA is requested to assign a new special-purpose label from the 258 "Special-Purpose MPLS Label Values" or "Extended Special-Purpose MPLS 259 Label Values" registry. 261 Value Description Reference 262 ------------------------------------------------- 263 TBD VTN Header Indicator this document 265 IANA is requested to assign a new option type of the MPLS VTN 266 extension header: 268 Value Description Reference 269 ------------------------------------------------- 270 TBD VTN-ID this document 272 7. Security Considerations 274 TBD 276 8. Contributors 278 Zhibo Hu 279 Email: huzhibo@huawei.com 281 9. Acknowledgements 283 TBD. 285 10. References 287 10.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 295 Label Switching Architecture", RFC 3031, 296 DOI 10.17487/RFC3031, January 2001, 297 . 299 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 300 and Retiring Special-Purpose MPLS Labels", RFC 7274, 301 DOI 10.17487/RFC7274, June 2014, 302 . 304 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 305 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 306 May 2017, . 308 10.2. Informative References 310 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 311 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 312 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 313 enhanced-vpn-vtn-scalability-01 (work in progress), 314 November 2020. 316 [I-D.ietf-teas-enhanced-vpn] 317 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 318 Framework for Enhanced Virtual Private Networks (VPN+) 319 Service", draft-ietf-teas-enhanced-vpn-06 (work in 320 progress), July 2020. 322 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 323 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 324 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 325 . 327 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 328 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 329 October 2007, . 331 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 332 Decraene, B., Litkowski, S., and R. Shakir, "Segment 333 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 334 July 2018, . 336 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 337 Decraene, B., Litkowski, S., and R. Shakir, "Segment 338 Routing with the MPLS Data Plane", RFC 8660, 339 DOI 10.17487/RFC8660, December 2019, 340 . 342 [TS23501] "3GPP TS23.501", 2016, 343 . 346 Authors' Addresses 348 Zhenbin Li 349 Huawei Technologies 350 Huawei Campus, No. 156 Beiqing Road 351 Beijing 100095 352 China 354 Email: lizhenbin@huawei.com 356 Jie Dong 357 Huawei Technologies 358 Huawei Campus, No. 156 Beiqing Road 359 Beijing 100095 360 China 362 Email: jie.dong@huawei.com