idnits 2.17.1 draft-li-teas-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 -- The document date (April 14, 2021) is 1108 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 (-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 Summary: 3 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 Z. Li 3 Internet-Draft J. Dong 4 Intended status: Standards Track Huawei Technologies 5 Expires: October 16, 2021 April 14, 2021 7 Framework for End-to-End IETF Network Slicing 8 draft-li-teas-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 describes the framework of end-to-end IETF network 26 slicing, and introduces the identifiers for 5G end-to-end network 27 slice and the multi-domain IETF network slice in the data packet. 28 The roles of the different identifiers in packet forwarding is also 29 described. The network slice identifiers can be instantiated with 30 different data planes. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 16, 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Requirements on E2E IETF Network Slicing . . . . . . . . . . 5 75 3.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Management Plane/Control Plane . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 82 7.2. Informative References . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 The definition and the characteristics of IETF network slice are 88 introduced in [I-D.ietf-teas-ietf-network-slice-definition], and 89 [I-D.ietf-teas-ietf-network-slice-framework] describes a general 90 framework of IETF network slice. 92 [I-D.ietf-teas-enhanced-vpn] describes the framework and the 93 candidate component technologies for providing enhanced VPN services, 94 by utilizing an approach that is based on existing VPN and Traffic 95 Engineering (TE) technologies and adds characteristics that specific 96 services require above traditional VPNs. VPN+ can be built from a 97 VPN overlay and an underlying Virtual Transport Network (VTN) which 98 has a customized network topology and a set of dedicated or shared 99 resources in the underlay network. Enhanced VPN (VPN+) can be used 100 for the realization of IETF network slices. 102 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 103 scalability considerations in the control plane and data plane to 104 enable VPN+ services, and provide several suggestions to improve the 105 scalability of VTN. In the control plane, It proposes the approach 106 of decoupling the topology and resource attributes of VTN, so that 107 multiple VTNs may share the same topology and the result of topology 108 based path computation. In the data plane, it proposes to carry a 109 VTN-ID of a network domain in the data packet to determine the set of 110 resources reserved for the corresponding VTN. 112 An IETF network slice may span multiple network domains. Further in 113 the context of 5G, there can be end-to-end network slices which 114 consists of three major types of network segments: Radio Access 115 Network (RAN), Transport Network (TN) and Core Network (CN). In 116 order to facilitate the mapping between network slices in different 117 network segments and network domains, it may be beneficial to also 118 carry the identifiers of the 5G end-to-end network slice, the multi- 119 domain IETF network slice together with the intra-domain network 120 slice identifier in the data packet. 122 This document describes the scenarios of end-to-end network slicing, 123 and the framework of network slice mapping between different network 124 segments and network domains. Then multiple network slice related 125 identifiers are defined to covers different network scopes. These 126 network slice identifiers can be instantiated using different data 127 planes, such as MPLS and IPv6. 129 2. Framework 130 /----\ /----\ /----\ /----\ /----\ 131 / \ // \\ // \\ // \\ / \ 132 | RAN |---| TN-1 |---| TN-2 |----| TN-3 |----| Core | 133 \ / \\ // \\ // \\ // \ / 134 \----/ \----/ \----/ \----/ \----/ 136 S-NSSAI 137 o--------------------------------------------------------------------o 138 IETF Network Slice (VPN+) 139 o--------------------------------------------------o 140 Global VTN 141 o===========================================o 142 Local VTN-1 Local VTN-2 Local VTN-3 143 o************o o************o o***********o 145 Figure 1. 5G end-to-end network slicing scenario 147 One typical scenario of 5G end-to-end network slicing is shown in 148 figure 1. The 5G end-to-end network slice is identified by the 149 S-NSSAI (Single Network Slice Selection Assistance Information). In 150 the transport network segment, the 5G network slice is mapped to an 151 IETF network slice, which is realized with a multi-domain VPN+ 152 service. In the underlay network, the multi-domain VPN+ service is 153 supported by a multi-domain VTN (Virtual Transport Network), which is 154 comprised by multiple intra-domain VTNs in different domains. In 155 each domain, a local VTN-ID is carried in the packet to identify the 156 set of network resource reserved for the VTN in the corresponding 157 domain. 159 In order to concatenate multiple local VTNs into a multi-domain VTN, 160 the global VTN-ID can be carried in the packet, which is used by the 161 network domain border routers to map to the local VTN-IDs in each 162 domain. And in order to facilitate the network slice mapping between 163 RAN, Core network and transport network, the S-NSSAI may be carried 164 in the packet sent to the transport network, which can be used by the 165 transport network to map the 5G end-to-end network slice to the 166 corresponding IETF network slice. 168 According to the above end-to-end network slicing scenario, there can 169 be three network slice related identifiers: 171 o Local VTN-ID: This is the VTN-ID as defined in 172 [I-D.dong-teas-enhanced-vpn-vtn-scalability]. It is used by the 173 network nodes in a network domain to determine the set of local 174 network resources reserved for a VTN. It SHOULD be processed by 175 each hop along the path in the domain. 177 o Global VTN-ID: This is the identifier which uniquely identifies a 178 multi-domain VTN. In each network domain, the domain edge node 179 maps the global VTN-ID to a local VTN-ID for packet forwarding. 181 o 5G end-to-end network slice ID (S-NSSAI): This is the identifier 182 of the 5G end-to-end network slice. When required, it can be used 183 by the network nodes to provide traffic monitoring at the end-to- 184 end network slice granularity. 186 For the above network slice identifiers, the local VTN-ID is 187 mandatory, the Global VTN-ID and the 5G S-NSSAI are optional. The 188 existence of the Global VTN-ID depends on whether the VTN spans 189 multiple network domains in the transport network. The existence of 190 the 5G S-NSSAI depends on whether an IETF network slice is used as 191 part of the 5G end-to-end network slice. 193 3. Requirements on E2E IETF Network Slicing 195 This section lists the requirements on E2E IETF network slicing. 197 3.1. Data Plane 199 To facilitate the mapping between 5G end-to-end network slice and 200 IETF network slice, and the mapping between multi-domain IETF network 201 slice and the intra-domain IETF network slice, different network 202 slice related identifiers (e.g. S-NSSAI, Global VTN-ID, local VTN- 203 ID) needs to be carried in the data packet. 205 3.2. Management Plane/Control Plane 207 For multi-domain IETF network slice, a centralized IETF network slice 208 controller is responsible for the allocation of the Global VTN-ID and 209 the Local VTN-ID, and the provisioning mapping relationship of the 210 Global VTN-ID and the Local VTN-IDs to the network edge nodes in 211 different network domains. 213 For 5G end-to-end network slice, the edge node of transport network 214 can derive the S-NSSAI from the packet sent by the RAN or Core 215 network, and encapsulate it an outer packet header or tunnel 216 information when traversing the transport network. The controller 217 needs to be responsible for creating the mapping relationship and 218 provisioning it to the edge nodes of the transport network. 220 4. IANA Considerations 222 This document makes no request of IANA. 224 Note to RFC Editor: this section may be removed on publication as an 225 RFC. 227 5. Security Considerations 229 TBD 231 6. Acknowledgements 233 TBD 235 7. References 237 7.1. Normative References 239 [I-D.ietf-teas-enhanced-vpn] 240 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 241 Framework for Enhanced Virtual Private Networks (VPN+) 242 Service", draft-ietf-teas-enhanced-vpn-06 (work in 243 progress), July 2020. 245 [I-D.ietf-teas-ietf-network-slice-definition] 246 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 247 Tantsura, "Definition of IETF Network Slices", draft-ietf- 248 teas-ietf-network-slice-definition-00 (work in progress), 249 January 2021. 251 [I-D.ietf-teas-ietf-network-slice-framework] 252 Gray, E. and J. Drake, "Framework for IETF Network 253 Slices", March 2021, . 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 7.2. Informative References 263 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 264 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 265 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 266 enhanced-vpn-vtn-scalability-01 (work in progress), 267 November 2020. 269 Authors' Addresses 271 Zhenbin Li 272 Huawei Technologies 273 Huawei Campus, No. 156 Beiqing Road 274 Beijing 100095 275 China 277 Email: lizhenbin@huawei.com 279 Jie Dong 280 Huawei Technologies 281 Huawei Campus, No. 156 Beiqing Road 282 Beijing 100095 283 China 285 Email: jie.dong@huawei.com