idnits 2.17.1 draft-dong-6man-enhanced-vpn-vtn-id-03.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 == 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 1158 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 26, 2021 C. Xie 6 C. Ma 7 China Telecom 8 February 22, 2021 10 Carrying Virtual Transport Network Identifier in IPv6 Extension Header 11 draft-dong-6man-enhanced-vpn-vtn-id-03 13 Abstract 15 A Virtual Transport Network (VTN) is a virtual network which has a 16 customized network topology and a set of dedicated or shared network 17 resources allocated from the network infrastructure. A VTN can be 18 used as the underlay for one or a group of VPNs to provide enhanced 19 VPN (VPN+) services. In packet forwarding, some fields in data 20 packet needs to be used to identify the VTN the packet belongs to, so 21 that the VTN-specific processing can be performed. 23 This document proposes a new option type to carry VTN ID in an IPv6 24 extension header to identify the Virtual Transport Network (VTN) the 25 packet belongs to. The procedure for processing of the VTN option is 26 also specified. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. New IPv6 Extension Header Option for VTN . . . . . . . . . . 3 65 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. VTN Option Insertion . . . . . . . . . . . . . . . . . . 4 67 3.2. VTN based Packet Forwarding . . . . . . . . . . . . . . . 4 68 4. Operational Considerations . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 9.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Virtual Private Networks (VPNs) provide different groups of users 81 with logically isolated connectivity over a common shared network 82 infrastructure. With the introduction of 5G, new service types may 83 require connectivity services with advanced characteristics comparing 84 to traditional VPNs, such as strict isolation from other services or 85 guaranteed performance. These services are refered to as "enhanced 86 VPNs" (VPN+). [I-D.ietf-teas-enhanced-vpn] describes a framework and 87 candidate component technologies for providing VPN+ services. 89 The enhanced properties of VPN+ require tighter coordination and 90 integration between the underlay network resources and the overlay 91 network. VPN+ service can be built on a Virtual Transport Network 92 (VTN) which has a customized network topology and a set of dedicated 93 or shared network resources allocated from the physical network. The 94 overlay VPN together with the corresponding VTN in the underlay 95 constitute the VPN+ service. In the network, traffic of different 96 VPN+ services need to be processed separately based on the topology 97 and the network resources associated with the corresponding VTN. 99 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 100 scalability considerations for VPN+, one approach to improve the data 101 plane scalability is by introducing a dedicated VTN Identifier (VTN 102 ID) in data packets to identify the VTN the packets belong to, so 103 that VTN-specific packet processing can be performed. This is called 104 Resource Independent (RI) VTN. 106 This document proposes a mechanism to carry the VTN ID in an IPv6 107 extension header [RFC8200] of a packet, so that the packet will be 108 processed by network nodes using the network resources allocated to 109 the corresponding VTN. The procedure for processing the VTN ID is 110 also specified. This provides a scalable solution for enhanced VPN 111 data plane, so that it may be used to support a large number of VTNs 112 in an IPv6 network. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 120 appear in all capitals, as shown here. 122 2. New IPv6 Extension Header Option for VTN 124 A new option type "VTN" is defined to carry the Virtual Transport 125 Network Identifier (VTN ID) in an IPv6 packet header. Its format is 126 shown as below: 128 Option Option Option 129 Type Data Len Data 130 +--------+--------+--------+--------+ 131 |BBCTTTTT|00000100| 4-octet VTN ID | 132 +--------+--------+--------+--------+ 133 Figure 1. The format of VTN Option 135 Option Type: 8-bit identifier of the type of option. The type of VTN 136 option is to be assigned by IANA. The highest-order bits of the type 137 field are defined as below: 139 o BB 00 The highest-order 2 bits are set to 00 to indicate that a 140 node which does not recognize this type will skip over it and 141 continue processing the header. 143 o C 0 The third highest-order bit are set to 0 to indicate this 144 option does not change en route. 146 Opt Data Len: 8-bit unsigned integer indicates the length of the 147 option Data field of this option, in octets. The value of Opt Data 148 Len of VTN option SHOULD be set to 4. 150 Option Data: 4-octet identifier which uniquely identifies a VTN. 152 Editor's note: The length of the VTN ID is defined as 4-octet for the 153 matching with the 4-octet Single Network Slice Selection Assistance 154 Information (S-NSSAI) defined in 3GPP [TS23501]. 156 8-bit 24-bit 157 +------------+-------------------------+ 158 | SST | Slice Differentiator | 159 +------------+-------------------------+ 160 Figure 2. The format of S-NSSAI 162 3. Procedures 164 As the VTN option needs to be processed by each node along the path 165 for VTN-specific forwarding, it SHOULD be carried in IPv6 Hop-by-Hop 166 options header when the Hop-by-Hop options header can be processed in 167 forwarding plane by all the nodes along the path. 169 3.1. VTN Option Insertion 171 When an ingress node of an IPv6 domain receives a packet, according 172 to traffic classification or mapping policy, the packet is steered 173 into one of the VTNs in the network, then the packet SHOULD be 174 encapsulated in an outer IPv6 header, and the VTN-ID of the VTN which 175 the packet is mapped to SHOULD be carried in the Hop-by-Hop options 176 header associated with the outer IPv6 header. 178 3.2. VTN based Packet Forwarding 180 On receipt of a packet with the VTN option, each network node which 181 can parse the VTN option SHOULD use the VTN ID to identify the VTN 182 the packet belongs to, so that the set of local resources allocated 183 to the VTN could be determined. The packet forwarding behavior is 184 based on both the destination IP address and the VTN option. The 185 destination IP address is used for the lookup of the next-hop and the 186 outgoing interface, and VTN-ID is used to determine the set of 187 network resources reserved for processing and sending the packet to 188 the next-hop node via the outgoing interface. The egress node of the 189 IPv6 domain SHOULD decapsulate the outer IPv6 header which includes 190 the VTN option. 192 In the forwarding plane, there can be different instantiations of 193 local network resources allocated to the VTNs. For example, on one 194 interface, a subset of forwarding plane resources (e.g. the bandwidth 195 and the associated buffer/queuing/scheduling resources) allocated to 196 a particular VTN can be considered as a virtual sub-interface with 197 dedicated resources. In packet forwarding, the IPv6 destination 198 address of the received packet is used to identify the next-hop and 199 the outgoing interface, and the VTN ID is used to further identify 200 the virtual sub-interface which is associated with the VTN on the 201 outgoing interface. 203 Routers which do not support Hop-by-Hop options header SHOULD ignore 204 the Hop-by-Hop options header and forward the packet only based on 205 the destination IP address. Routers which support Hop-by-Hop Options 206 header, but do not support the VTN option SHOULD ignore the Hop-by- 207 Hop option and continue to forward the packet only based on the 208 destination IP address. 210 4. Operational Considerations 212 As described in [RFC8200], nodes may be configured to ignore the Hop- 213 by-Hop Options header, and in some implementations a packet 214 containing a Hop-by-Hop Options header may be dropped or assigned to 215 a slow processing path. This needs to be taken into consideration 216 when VTN option is introduced to a network. The operator needs to 217 make sure that all the network nodes in a VTN can either process Hop- 218 by-Hop Options header in packet forwarding, or ignore the Hop-by-Hop 219 Option header. In other word, packets steered into a VTN MUST NOT be 220 dropped due to the existence of the Hop-by-Hop Options header. It is 221 RECOMMENDED to configure all the nodes in a VTN to process the Hop- 222 by-Hop Options header if there is a nob for this. 224 5. IANA Considerations 226 This document requests IANA to assign a new option type from 227 "Destination Options and Hop-by-Hop Options" registry. 229 Value Description Reference 230 -------------------------------------- 231 TBD VTN Option this document 233 6. Security Considerations 235 TBD 237 7. Contributors 239 Zhibo Hu 240 Email: huzhibo@huawei.com 242 Lei Bao 243 Email: baolei7@huawei.com 245 8. Acknowledgements 247 The authors would like to thank Juhua Xu and James Guichard for their 248 review and valuable comments. 250 9. References 252 9.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 260 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 261 May 2017, . 263 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 264 (IPv6) Specification", STD 86, RFC 8200, 265 DOI 10.17487/RFC8200, July 2017, 266 . 268 9.2. Informative References 270 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 271 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 272 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 273 enhanced-vpn-vtn-scalability-01 (work in progress), 274 November 2020. 276 [I-D.ietf-teas-enhanced-vpn] 277 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 278 Framework for Enhanced Virtual Private Networks (VPN+) 279 Service", draft-ietf-teas-enhanced-vpn-06 (work in 280 progress), July 2020. 282 [TS23501] "3GPP TS23.501", 2016, 283 . 286 Authors' Addresses 288 Jie Dong 289 Huawei Technologies 290 Huawei Campus, No. 156 Beiqing Road 291 Beijing 100095 292 China 294 Email: jie.dong@huawei.com 296 Zhenbin Li 297 Huawei Technologies 298 Huawei Campus, No. 156 Beiqing Road 299 Beijing 100095 300 China 302 Email: lizhenbin@huawei.com 304 Chongfeng Xie 305 China Telecom 306 China Telecom Beijing Information Science & Technology, Beiqijia 307 Beijing 102209 308 China 310 Email: xiechf@chinatelecom.cn 312 Chenhao Ma 313 China Telecom 314 China Telecom Beijing Information Science & Technology, Beiqijia 315 Beijing 102209 316 China 318 Email: machh@chinatelecom.cn