idnits 2.17.1 draft-li-6man-e2e-ietf-network-slicing-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 241 has weird spacing: '... Option this ...' -- The document date (April 14, 2021) is 1098 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 (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-02 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-definition (ref. 'I-D.ietf-teas-ietf-network-slice-definition') ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-framework (ref. 'I-D.ietf-teas-ietf-network-slice-framework') == 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-6man-ipv6-alt-mark-02 Summary: 3 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 Encapsulation of End-to-End IETF Network Slice Information in IPv6 8 draft-li-6man-e2e-ietf-network-slicing-00 10 Abstract 12 Network slicing can be used to meet the connectivity and performance 13 requirement of different services or customers in a shared network. 14 An IETF network slice may span multiple network domains. In the 15 context of 5G, the 5G end-to-end network slices consist of three 16 major types of network segments: Radio Access Network (RAN), 17 Transport Network (TN) and Core Network (CN). 19 In order to facilitate the mapping between network slices in 20 different network segments and network domains, it is beneficial to 21 carry the identifiers of the 5G end-to-end network slice, the multi- 22 domain IETF network slice together with the intra-domain network 23 slice identifier in the data packet. 25 This document defines the mechanism of encapsulating the end-to-end 26 network slice related information in IPv6 data plane. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 16, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. End-to-End Network Slice Identifiers in IPv6 . . . . . . . . 3 69 2.1. IPv6 Global VTN-ID Option . . . . . . . . . . . . . . . . 4 70 2.2. IPv6 5G Network Slice ID Option . . . . . . . . . . . . . 4 71 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The definition and the characteristics of IETF are introduced in 83 [I-D.ietf-teas-ietf-network-slice-definition], and 84 [I-D.ietf-teas-ietf-network-slice-framework] describes a general 85 framework of IETF network slice. 87 [I-D.ietf-teas-enhanced-vpn] describes the framework and the 88 candidate component technologies for providing enhanced VPN services. 89 VPN+ can be built from a VPN overlay and an underlying Virtual 90 Transport Network (VTN) which has a customized network topology and a 91 set of dedicated or shared resources in the underlay network. 92 Enhanced VPN (VPN+) can be used for the realization of IETF network 93 slices. 95 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 96 scalability considerations in the control plane and data plane to 97 enable VPN+ services, and provides several suggestions to improve the 98 scalability of VTN. In the control plane, It proposes the approach 99 of decoupling the topology and resource attributes of VTN, so that 100 multiple VTNs may share the same topology and the result of topology 101 based path computation. In the data plane, it proposes to carry a 102 VTN-ID in the data packet to determine the set of resources reserved 103 for the corresponding VTN. 105 An IETF network slice may span multiple network domains. Further in 106 the context of 5G, there can be end-to-end network slices which 107 consists of three major types of network segments: Radio Access 108 Network (RAN), Transport Network (TN) and Core Network (CN). In 109 order to facilitate the mapping between network slices in different 110 network segments and network domains, it may be beneficial to carry 111 the identifiers of the 5G end-to-end network slice and the multi- 112 domain IETF network slice together with the intra-domain network 113 slice identifier in the data packet. 115 [I-D.li-teas-e2e-ietf-network-slicing] describes the framework of 116 carrying end-to-end network slice related identifiers in the data 117 plane, each of the identifiers may span a different network scope. 119 With IPv6 data plane, [I-D.dong-6man-enhanced-vpn-vtn-id] specifies 120 the extensions and mechanisms to carry the VTN-ID of a single network 121 domain in IPv6 extension header, so as to improve the scalability of 122 VTN [I-D.dong-teas-enhanced-vpn-vtn-scalability]. This document 123 further specifies the extensions and mechanisms of encapsulating the 124 identifiers of the 5G end-to-end network slice and the multi-domain 125 IETF network slice in IPv6 data plane to support the end-to-end 126 network slicing. 128 2. End-to-End Network Slice Identifiers in IPv6 130 This section describes the approach of encapsulating the end-to-end 131 network slice identifiers in IPv6 data plane. Two new IPv6 options 132 are defined for the global VTN-ID and the 5G end-to-end network slice 133 ID (i.e. S-NSSAI) respectively. This way, the network slice 134 identifiers with different network scopes are carried in separate 135 IPv6 options. 137 The Global VTN-ID and the 5G network slice ID are optional in the 138 data packet, depending on whether a IETF network slice spans multiple 139 domains and whether it is used as part of the 5G end-to-end network 140 slice. 142 Editor's note: Another option is to define a new network slice option 143 to carry all the network slicing related information, each network 144 slice related identifier can be defined as a separate TLV in the new 145 option. Since the end-to-end network slice related identifiers are 146 optional information, it is more practical to define them as separate 147 options of IPv6 extension header for better incremental evolution. 149 2.1. IPv6 Global VTN-ID Option 151 The format of the Global VTN-ID option is shown as below: 153 Option Option Option 154 Type Data Len Data 155 +--------+--------+--------+--------+--------+--------+ 156 |BBCTTTTT|00000100| Global VTN-ID | 157 +--------+--------+--------+--------+--------+--------+ 158 Figure 1. The format of Global VTN-ID Option 160 Option Type: 8-bit identifier of the type of option. The type of 161 Global VTN-ID option is to be assigned by IANA. The highest-order 162 bits of the type field are defined as below: 164 o BB 00 The highest-order 2 bits are set to 00 to indicate that a 165 node which does not recognize this type will skip over it and 166 continue processing the header. 168 o C 0 The third highest-order bit are set to 0 to indicate this 169 option does not change en route. 171 Opt Data Len: 8-bit unsigned integer indicates the length of the 172 option Data field of this option, in octets. The value of Opt Data 173 Len of the Global VTN-ID option SHOULD be set to 4. 175 Option Data: 4-octet identifier which uniquely identifies a global 176 VTN. 178 2.2. IPv6 5G Network Slice ID Option 180 The format of the 5G network slice ID option is shown as below: 182 Option Option Option 183 Type Data Len Data 184 +--------+--------+--------+--------+--------+--------+ 185 |BBCTTTTT|00000100| S-NSSAI | 186 +--------+--------+--------+--------+--------+--------+ 187 Figure 2. The format of 5G network slice ID Option 189 Option Type: 8-bit identifier of the type of option. The type of 5G 190 network slice ID option is to be assigned by IANA. The highest-order 191 bits of the type field are defined as below: 193 o BB 00 The highest-order 2 bits are set to 00 to indicate that a 194 node which does not recognize this type will skip over it and 195 continue processing the header. 197 o C 0 The third highest-order bit are set to 0 to indicate this 198 option does not change en route. 200 Opt Data Len: 8-bit unsigned integer indicates the length of the 201 option Data field of this option, in octets. The value of Opt Data 202 Len of the 5G network slice ID option SHOULD be set to 4. This 203 aligns with the length of the S-NSSAI defined in 3GPP. 205 Option Data: 4-octet identifier which uniquely identifies a 5G end- 206 to-end network slice. 208 3. Procedures 210 The ingress node of a multi-domain IETF network slice SHOULD 211 encapsulate the received packet in an outer IPv6 header, the Global 212 VTN-ID the packet mapped to MAY be carried in the IPv6 HBH options 213 header of the outer IPv6 header. 215 The edge nodes of each domain MAY parse the Global VTN-ID in the IPv6 216 HBH options header and maps it to a local VTN. When the mechanism as 217 defined in [I-D.dong-6man-enhanced-vpn-vtn-id] is used in the local 218 domain, the Local VTN-ID is obtained from the mapping relationship 219 between the Global VTN-ID and Local VTN-ID maintained on the edge 220 node, and the Local VTN-ID SHOULD be encapsulated in the HBH header 221 of the outer IPv6 header. The Local VTN-ID is used to identify the 222 local network resources reserved for the VTN in the local domain. 223 The local VTN-ID in the packet MAY be updated on the edge nodes of 224 each domain. 226 When the multi-domain IETF network slice is part of a 5G end-to-end 227 network slice, the 5G Network Slice ID option MAY be carried in the 228 IPv6 HBH options header of the outer IPv6 header. The S-NSSAI MAY be 229 used for the collection and report of the performance information of 230 the 5G end-to-end network slice based on the mechanism defined in 231 [I-D.ietf-6man-ipv6-alt-mark]. 233 4. IANA Considerations 235 IANA is requested to allocate two new option types from "Destination 236 Options and Hop-by-Hop Options" registry. 238 Value Description Reference 239 ------------------------------------------------- 240 TBD1 Global VTN-ID Option this document 241 TBD2 5G Network Slice ID Option this document 243 5. Security Considerations 245 TBD 247 6. Acknowledgements 249 TBD 251 7. References 253 7.1. Normative References 255 [I-D.dong-6man-enhanced-vpn-vtn-id] 256 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 257 Transport Network Identifier in IPv6 Extension Header", 258 draft-dong-6man-enhanced-vpn-vtn-id-02 (work in progress), 259 November 2020. 261 [I-D.ietf-teas-enhanced-vpn] 262 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 263 Framework for Enhanced Virtual Private Networks (VPN+) 264 Service", draft-ietf-teas-enhanced-vpn-06 (work in 265 progress), July 2020. 267 [I-D.ietf-teas-ietf-network-slice-definition] 268 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 269 Tantsura, "Definition of IETF Network Slices", draft-ietf- 270 teas-ietf-network-slice-definition-00 (work in progress), 271 January 2021. 273 [I-D.ietf-teas-ietf-network-slice-framework] 274 Gray, E. and J. Drake, "Framework for IETF Network 275 Slices", March 2021, . 278 [I-D.li-teas-e2e-ietf-network-slicing] 279 Li, Z. and J. Dong, "Framework for End-to-End IETF Network 280 Slicing", April 2021, . 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 7.2. Informative References 290 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 291 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 292 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 293 enhanced-vpn-vtn-scalability-01 (work in progress), 294 November 2020. 296 [I-D.ietf-6man-ipv6-alt-mark] 297 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 298 Pang, "IPv6 Application of the Alternate Marking Method", 299 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 300 October 2020. 302 Authors' Addresses 304 Zhenbin Li 305 Huawei Technologies 306 Huawei Campus, No. 156 Beiqing Road 307 Beijing 100095 308 China 310 Email: lizhenbin@huawei.com 312 Jie Dong 313 Huawei Technologies 314 Huawei Campus, No. 156 Beiqing Road 315 Beijing 100095 316 China 318 Email: jie.dong@huawei.com