idnits 2.17.1 draft-li-mpls-enhanced-vpn-vtn-id-00.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 261 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 (February 22, 2021) is 1151 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) == 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 (~~), 5 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: August 26, 2021 February 22, 2021 7 Carrying Virtual Transport Network Identifier in MPLS Packet 8 draft-li-mpls-enhanced-vpn-vtn-id-00 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 and the 22 associated information in an MPLS packet to identify the VTN the 23 packet belongs to. The procedure for processing the VTN ID is also 24 specified. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 26, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . 6 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. 98 For network scenraios where a large number of VTNs need to be created 99 and maintained, [I-D.dong-teas-enhanced-vpn-vtn-scalability] 100 describes the scalability considerations for VTN. One approach to 101 improve the data plane scalability is introducing a dedicated VTN 102 Identifier (VTN-ID) in data packets to identify the VTN the packets 103 belong to, so that VTN-specific packet processing can be performed by 104 network nodes. 106 This document proposes a mechanism to carry the VTN Identifier (VTN- 107 ID) and the related information in MPLS [RFC3031] data packets, so 108 that the packet will be processed by network nodes using the set of 109 network resources allocated to the corresponding VTN. The procedure 110 for processing the VTN-ID is also specified. The forwarding path of 111 the MPLS LSP is determined using the MPLS label stack in the packet, 112 and the set of local network resources used for processing the packet 113 is determined by the VTN-ID. The mechanism introduced in this 114 document is applicable to both MPLS networks with RSVP-TE [RFC3209] 115 or LDP [RFC5036] based LSPs, and MPLS networks with Segment Routing 116 (SR) [RFC8402] [RFC8660]. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 124 appear in all capitals, as shown here. 126 3. Carrying VTN Information in MPLS Packet 128 This document defines a new VTN header which is used to carry the 129 VTN-ID and other VTN related information. In an MPLS packet, The VTN 130 header follows the MPLS label stack, and precedes the header and 131 payloads in the upper layer. The format of VTN header is shown as 132 below: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |Nibble | Length| Flags | Reserved | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | VTN Identifier | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ~ Service Differentiator (Optional) ~ 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1. The format of MPLS VTN Header 145 Where: 147 o Nibble: The first 4-bit field is set to the binary value 0010. 148 This is to ensure that the VTN header will not be interpreted as 149 an IP header or the ACH of pseudowire packet. 151 o Length: Indicate the length of the MPLS VTN header in 32-bit 152 words. 154 o Flags: 8-bit Flags field. All the flags are reversed for future 155 use. This field SHOULD be set to zero on transmission and MUST be 156 ignored on receipt. 158 o Reserved: 16-bit field reserved for future use. 160 o VTN Identifier (VTN-ID): A 4-octet global significant identifier 161 which uniquely identifies a VTN. 163 o Service Differentiator: A variable length field to identify a 164 service instance which is carried by the VTN. In the context of 165 5G network slicing, this may be the Single Network Slice Selection 166 Assistance Information (S-NSSAI) associated with the packet. 168 Editor's note: The length of the VTN-ID is defined as 4-octet for the 169 potential matching or mapping with the 4-octet S-NSSAI defined in 170 3GPP [TS23501] for 5G network slicing. One or multiple S-NSSAIs may 171 be mapped to one VTN. 173 8-bit 24-bit 174 +------------+-------------------------+ 175 | SST | Slice Differentiator | 176 +------------+-------------------------+ 177 Figure 2. The format of S-NSSAI 179 A new MPLS special-purpose label or extended special-purpose label 180 [RFC7274] is defined as the VTN Header Indicator (VHI), its value is 181 to be assigned by IANA. The VHI label is used to indicate the 182 existence of the VTN Header after the MPLS label stack in the packet. 183 The position of the VHI label in the MPLS label stack is not limited. 185 The benefit of introducing the MPLS VTN header to carry the VTN-ID 186 and the related information is that it provides the flexibility to 187 encode information which cannot be accommodated in an MPLS label 188 (20-bit), and the length of the header can be variable. 190 4. Procedures 192 4.1. VTN Header Insertion 194 When the ingress node of an LSP receives a packet, according to 195 traffic classification or mapping policy, the packet is steered into 196 one of the VTNs in the network, then a VTN header SHOULD be inserted 197 into the packet, and the VTN-ID which the packet is mapped to SHOULD 198 be carried in the VTN header. The ingress node may also insert a 199 Service Differentiator into the VTN header to further identify the 200 service instance the packet belongs to.The ingress node SHOULD also 201 encapsulates the packet with an MPLS label stack which are used to 202 determine the path traversed by the LSP. The VHI label SHOULD be 203 inserted in the label stack to identify the existence of the VTH 204 header. 206 4.2. VTN based Packet Forwarding 208 On receipt of a MPLS packet which carries the VHL and the VTN header, 209 network nodes which support the mechanism defined in this document 210 SHOULD scan the label stack to figure out the existence of the VHL. 211 If there is a VHL in the label stack, then the network node SHOULD 212 parse the VTN header and use the VTN-ID to identify the VTN the 213 packet belongs to, and use the local resources allocated to the VTN 214 to process and forward the packet. The forwarding behavior is based 215 on both the top MPLS label and the VTN ID. The top MPLS label is 216 used for the lookup of the next-hop, and the VTN-ID can be used to 217 determine the set of network resources allocated by the network nodes 218 for processing and sending the packet to the next-hop. The network 219 node may further use the Service Differentiator information to 220 provide some fine-grained differentiation and processing based on the 221 local network resources allocated to the VTN. 223 There can be different approaches used for allocating network 224 resources on each network node to the VTNs. For example, on one 225 interface, a subset of forwarding plane resource (e.g. bandwidth and 226 the associated buffer/queuing/scheduling resources) allocated to a 227 particular VTN can be considered as a virtual layer-2 sub-interface 228 with dedicated bandwidth and the associated resources. In packet 229 forwarding, the top MPLS label of the received packet is used to 230 identify the next-hop and the outgoing Layer 3 interface, and the 231 VTN-ID is used to further identify the virtual sub-interface which is 232 associated with the VTN on the outgoing interface. 234 Network nodes which do not support the mechanism in this document 235 SHOULD ignore the VHL and the VTN header, and forward the packet only 236 based on the top MPLS label. 238 The egress node of the MPLS LSP SHOULD pop the VHL together with 239 other LSP labels, and decapsulate the VTN header. 241 5. Capability Advertisement and Negotiation 243 Before inserting the VTN header into an MPLS packet, the ingress node 244 MAY need to know whether the nodes along the LSP can process the VTN 245 header properly according to the mechanisms defined in this document. 246 This can be achieved by introducing the capability advertisement and 247 negotiation mechanism for the VTN header. The ingress node also need 248 to know whether the egress node of the LSP can remove the VTN header 249 properly before parsing the upper layer and send the packet to the 250 next hop. The capability advertisement and negotiation mechanism 251 will be described in a future version of this document. 253 6. IANA Considerations 255 This document requests IANA to assign a new special-purpose label 256 from the "Special-Purpose MPLS Label Values" or the "Extended 257 Special-Purpose MPLS Label Values" registry. 259 Value Description Reference 260 ------------------------------------------------- 261 TBD VTN Header Indicator this document 263 7. Security Considerations 265 TBD 267 8. Contributors 269 Zhibo Hu 270 Email: huzhibo@huawei.com 272 9. Acknowledgements 274 TBD. 276 10. References 278 10.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 286 Label Switching Architecture", RFC 3031, 287 DOI 10.17487/RFC3031, January 2001, 288 . 290 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 291 and Retiring Special-Purpose MPLS Labels", RFC 7274, 292 DOI 10.17487/RFC7274, June 2014, 293 . 295 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 297 May 2017, . 299 10.2. Informative References 301 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 302 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 303 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 304 enhanced-vpn-vtn-scalability-01 (work in progress), 305 November 2020. 307 [I-D.ietf-teas-enhanced-vpn] 308 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 309 Framework for Enhanced Virtual Private Networks (VPN+) 310 Service", draft-ietf-teas-enhanced-vpn-06 (work in 311 progress), July 2020. 313 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 314 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 315 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 316 . 318 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 319 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 320 October 2007, . 322 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 323 Decraene, B., Litkowski, S., and R. Shakir, "Segment 324 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 325 July 2018, . 327 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 328 Decraene, B., Litkowski, S., and R. Shakir, "Segment 329 Routing with the MPLS Data Plane", RFC 8660, 330 DOI 10.17487/RFC8660, December 2019, 331 . 333 [TS23501] "3GPP TS23.501", 2016, 334 . 337 Authors' Addresses 339 Zhenbin Li 340 Huawei Technologies 341 Huawei Campus, No. 156 Beiqing Road 342 Beijing 100095 343 China 345 Email: lizhenbin@huawei.com 347 Jie Dong 348 Huawei Technologies 349 Huawei Campus, No. 156 Beiqing Road 350 Beijing 100095 351 China 353 Email: jie.dong@huawei.com