idnits 2.17.1 draft-li-teas-e2e-ietf-network-slicing-02.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 (7 March 2022) is 780 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-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') == Outdated reference: A later version (-02) exists of draft-dong-teas-nrp-scalability-01 Summary: 2 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: 8 September 2022 R. Pang 6 China Unicom 7 Y. Zhu 8 China Telecom 9 7 March 2022 11 Framework for End-to-End IETF Network Slicing 12 draft-li-teas-e2e-ietf-network-slicing-02 14 Abstract 16 Network slicing can be used to meet the connectivity and performance 17 requirement of different services or customers in a shared network. 18 An IETF network slice may be used for 5G or other network scenarios. 19 In the context of 5G, the 5G end-to-end network slices consist of 20 three major types of network technology domains: Radio Access Network 21 (RAN), Transport Network (TN) and Core Network (CN). The transport 22 network slice can be realized as IETF network slices. In the 23 transport network, the IETF network slice may span multiple network 24 administrative domains. 26 In order to facilitate the mapping between network slices in 27 different network technology domains and administrative domains, it 28 is beneficial to carry the identifiers related to the 5G end-to-end 29 network slice, the multi-domain IETF network slice together with the 30 intra-domain network slice related identifier in the data packet. 32 This document describes the framework of end-to-end IETF network 33 slicing, and introduces the identifiers related to 5G end-to-end 34 network slice and the multi-domain IETF network slice. These 35 identifiers can be carried in the data packet. The roles of the 36 different identifiers in packet forwarding is also described. The 37 network slice identifiers may be instantiated with different data 38 planes. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on 8 September 2022. 63 Copyright Notice 65 Copyright (c) 2022 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 70 license-info) in effect on the date of publication of this document. 71 Please review these documents carefully, as they describe your rights 72 and restrictions with respect to this document. Code Components 73 extracted from this document must include Revised BSD License text as 74 described in Section 4.e of the Trust Legal Provisions and are 75 provided without warranty as described in the Revised BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Requirements on E2E IETF Network Slicing . . . . . . . . . . 5 82 3.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 83 3.2. Management Plane/Control Plane . . . . . . . . . . . . . 6 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 89 7.2. Informative References . . . . . . . . . . . . . . . . . 7 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 92 1. Introduction 94 [I-D.ietf-teas-ietf-network-slices] defines the terminologies and the 95 characteristics of IETF network slices. It also discusses the 96 general framework, the components and interfaces for requesting and 97 operating IETF network slices. A Network Resource Partition (NRP) is 98 a collection of network resources in the underlay network that are 99 available to carry traffic and meet the SLOs and SLEs. 101 [I-D.ietf-teas-enhanced-vpn] describes the framework and the 102 candidate component technologies for providing enhanced VPN (VPN+) 103 services based on existing VPN and Traffic Engineering (TE) 104 technologies with enhanced characteristics that specific services 105 require above traditional VPNs. It also introduces the concept of 106 Virtual Transport Network (VTN), which is a virtual underlay network 107 consisting of a set of dedicated or shared network resources 108 allocated from the physical underlay network, and is associated with 109 a customized network topology. VPN+ services can be delivered by 110 mapping one or a group of overlay VPNs to the appropriate VTNs as the 111 underlay, so as to provide the network characteristics required by 112 the customers. Enhanced VPN (VPN+) and VTN can be used for the 113 realization of IETF network slices. In the context of IETF network 114 slicing, NRP can be seen as an instantiation of VTN. 116 [I-D.dong-teas-nrp-scalability] describes the scalability 117 considerations in the control plane and data plane of NRP, and 118 proposed several suggestions to improve the scalability. In the 119 control plane, It proposes the approach of decoupling the topology 120 and resource attributes of NRP, so that multiple NRPs may share the 121 same topology attributes and the result of topology based path 122 computation. In the data plane, it proposes to carry a global NRP-ID 123 of a network domain in the data packet to determine the set of 124 resources reserved for the corresponding NRP. 126 An IETF network slice may span multiple network administrative 127 domains. Further in the context of 5G, there are end-to-end network 128 slices which consists of three major types of network technology 129 domains: Radio Access Network (RAN), Transport Network (TN) and Core 130 Network (CN). In order to facilitate the mapping between network 131 slices in different network technology domains and administrative 132 domains, it may be beneficial to carry the identifiers related to the 133 5G end-to-end network slice, the identifiers of the multi-domain IETF 134 network slices together with the intra-domain network slices related 135 identifiers in the data packet. 137 This document describes the typical scenarios of end-to-end network 138 slicing, and the framework of concatenating network slices in 139 different network technology domains and administrative domains. 141 Multiple network slice related identifiers are defined for network 142 slices with different network scopes. These network slice related 143 identifiers can be instantiated using different data planes, such as 144 IPv6 and MPLS. 146 2. Framework 148 /----\ /----\ /----\ /----\ /----\ 149 / \ // \\ // \\ // \\ / \ 150 | RAN |---| TN-1 |---| TN-2 |----| TN-3 |----| Core | 151 \ / \\ // \\ // \\ // \ / 152 \----/ \----/ \----/ \----/ \----/ 154 5G Network Slice 155 o--------------------------------------------------------------------o 156 IETF Network Slice (VPN+) 157 o--------------------------------------------------o 158 Global NRP (VTN) 159 o===========================================o 160 Local NRP-1 Local NRP-2 Local NRP-3 161 o************o o************o o***********o 163 Figure 1. 5G end-to-end network slicing scenario 165 One typical scenario of 5G end-to-end network slicing is shown in 166 figure 1. The 5G end-to-end network slice is identified by the 167 S-NSSAI (Single Network Slice Selection Assistance Information). In 168 the transport network, the 5G network slice is mapped to an IETF 169 network slice. In a multi-domain transport network, an IETF network 170 slice can be realized with a multi-domain VPN+ service. In the 171 underlay network, the multi-domain VPN+ service can be supported by a 172 multi-domain VTN, which is the concatenation of multiple intra-domain 173 NRPs in different domains. In each domain, a domain-significant NRP- 174 ID can be carried in the packet to identify the set of network 175 resource reserved for the NRP in the corresponding domain. Note this 176 is similar to the Option C mode of inter-domain VPN service 177 [RFC4364]. Using Option A or Option B mode of inter-domain VPN for 178 5G end-to-end network slicing is also possible, which is out of the 179 scope of the current version of this document. 181 In order to concatenate multiple domain-wide NRPs into a multi-domain 182 NRP, the global NRP-ID can be carried in the packet, which is used by 183 the domain border nodes to map to the local NRP-IDs in each domain. 184 And in order to facilitate the network slice mapping between RAN, 185 Core network and transport network, the S-NSSAI may be carried in the 186 packet sent to the transport network, which can be used by the 187 transport network to map the 5G end-to-end network slice to the 188 corresponding IETF network slice. 190 According to the above end-to-end network slicing scenario, there can 191 be three network slice related identifiers in the data packet: 193 * Domain NRP-ID: This is the NRP-ID as defined in 194 [I-D.dong-teas-nrp-scalability]. It is used by the network nodes 195 in a network domain to determine the set of local network 196 resources reserved for an NRP. It SHOULD be processed by each hop 197 along the path in the domain. 199 * End-to-end NRP-ID: This is the identifier which uniquely 200 identifies a multi-domain NRP. In each network domain, the domain 201 border nodes map the global NRP-ID to the domain NRP-ID for packet 202 forwarding. 204 * 5G end-to-end network slice ID (S-NSSAI): This is the identifier 205 of the 5G end-to-end network slice. When required, it may be used 206 by the network nodes to provide traffic monitoring at the end-to- 207 end network slice granularity. 209 For the above network slice identifiers, the domain NRP-ID is 210 mandatory, the global NRP-ID and the 5G S-NSSAI are optional. The 211 existence of the Global NRP-ID depends on whether the NRP spans 212 multiple network domains in the transport network, and how the domain 213 NRP-IDs are managed. In some network scenarios, different network 214 domains can have consistent NRP ID allocation, then the domain NRP-ID 215 can has the same value as a global NRP-ID. The existence of the 5G 216 S-NSSAI depends on whether an IETF network slice is used as part of 217 the 5G end-to-end network slice. 219 3. Requirements on E2E IETF Network Slicing 221 This section lists the requirements on E2E IETF network slicing. 223 3.1. Data Plane 225 To facilitate the mapping between 5G end-to-end network slice and 226 IETF network slice, and the mapping between multi-domain IETF network 227 slice and the intra-domain IETF network slice, different network 228 slice related identifiers, including the S-NSSAI, the Global NRP-ID, 229 domain NRP-ID need to be carried in the data packet. 231 In a multi-domain IETF network slice, the domain border nodes should 232 support to map the Global NRP-ID to the domain NRP-ID of the local 233 domain. In a 5G end-to-end network slicing scenario, the edge nodes 234 of IETF network slice should support to map the S-NSSAI to the global 235 NRP-ID and the domain NRP-ID. When the correlation between S-NSSAI 236 and the NRP-ID needs to be maintained, the edge nodes of IETF network 237 slices should be able to derive the S-NSSAI from the data packet 238 received from RAN and CN, and encapsulate both the S-NSSAI and the 239 NRP-ID into an outer packet header when traversing the transport 240 network domains. 242 3.2. Management Plane/Control Plane 244 For multi-domain IETF network slice, a centralized IETF network slice 245 controller is responsible for the allocation of the Global NRP-ID and 246 the domain NRP-IDs, and the provisioning of the mapping relationship 247 between the Global NRP-ID and the domain NRP-IDs to the border nodes 248 in different network domains. 250 For 5G end-to-end network slice, when S-NSSAI is used for the mapping 251 from RAN or CN network slices to IETF network slices, the IETF 252 network slice controller is responsible for the provisioning of the 253 mapping relationship between S-NSSAI and the Global and local NRP-IDs 254 at the edge nodes of IETF network slices. 256 4. IANA Considerations 258 This document makes no request of IANA. 260 Note to RFC Editor: this section may be removed on publication as an 261 RFC. 263 5. Security Considerations 265 TBD 267 6. Acknowledgements 269 TBD 271 7. References 273 7.1. Normative References 275 [I-D.ietf-teas-enhanced-vpn] 276 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 277 Framework for Enhanced Virtual Private Network (VPN+) 278 Services", Work in Progress, Internet-Draft, draft-ietf- 279 teas-enhanced-vpn-09, 25 October 2021, 280 . 283 [I-D.ietf-teas-ietf-network-slices] 284 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 285 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 286 Network Slices", Work in Progress, Internet-Draft, draft- 287 ietf-teas-ietf-network-slices-08, 6 March 2022, 288 . 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 7.2. Informative References 298 [I-D.dong-teas-nrp-scalability] 299 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 300 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 301 "Scalability Considerations for Network Resource 302 Partition", Work in Progress, Internet-Draft, draft-dong- 303 teas-nrp-scalability-01, 7 February 2022, 304 . 307 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 308 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 309 2006, . 311 Authors' Addresses 313 Zhenbin Li 314 Huawei Technologies 315 Huawei Campus, No. 156 Beiqing Road 316 Beijing 317 100095 318 China 319 Email: lizhenbin@huawei.com 321 Jie Dong 322 Huawei Technologies 323 Huawei Campus, No. 156 Beiqing Road 324 Beijing 325 100095 326 China 327 Email: jie.dong@huawei.com 329 Ran Pang 330 China Unicom 331 Email: pangran@chinaunicom.cn 333 Yongqing Zhu 334 China Telecom 335 Email: zhuyq8@chinatelecom.cn