idnits 2.17.1 draft-dong-teas-hierarchical-ietf-network-slice-01.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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 == Outdated reference: A later version (-02) exists of draft-dong-teas-nrp-scalability-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: 8 September 2022 7 March 2022 7 Considerations about Hierarchical IETF Network Slices 8 draft-dong-teas-hierarchical-ietf-network-slice-01 10 Abstract 12 Network slicing is targeted at existing or emerging customers or 13 services which may request for network connectivity services with a 14 specific set of Service Level Objectives (SLOs) and Service Level 15 Expectations (SLEs). In some network scenarios, there can be 16 requirements for the deployment of hierarchical network slices.The 17 general framework of IETF network slice supports hierarchical network 18 slicing, while the technologies for realizing hierarchical IETF 19 network slice need to be considered. 21 This document describes the typical scenarios of hierarchical IETF 22 network slices, and provides the considerations and requirements on 23 the technologies in different network planes to realize hierarchical 24 IETF network slices. 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 8 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Scenarios of Hierarchical IETF Network Slices . . . . . . . . 3 61 2.1. Per-Customer Network Slices in an Industrial Network 62 Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Per-application Network Slices in a Customer Network 64 Slice . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Network Slice Services in a Wholesale Network Slice . . . 5 66 3. Considerations about Hierarchical Network Slice 67 Realization . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Forwarding Plane Network Resource Partitioning . . . . . 6 69 3.2. Data Plane Identifiers . . . . . . . . . . . . . . . . . 8 70 3.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9 71 3.4. Management Plane . . . . . . . . . . . . . . . . . . . . 10 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Network slicing is targeted at existing or emerging customers or 84 services which may request for network connectivity services with a 85 specific set of Service Level Objectives (SLOs) and Service Level 86 Expectations (SLEs). The concept and general framework of IETF 87 network slice are described in [I-D.ietf-teas-ietf-network-slices]. 88 [I-D.ietf-teas-enhanced-vpn] describes the framework and technologies 89 which can be used for IETF network slice realization by utilizing 90 Virtual Private Network (VPN) and Traffic Engineering (TE) mechanisms 91 with enhancements that specific services require over traditional 92 VPNs. 94 [I-D.ietf-teas-ietf-network-slices] mentions that IETF Network Slices 95 may be combined hierarchically, which means that a network slice may 96 itself be further sliced. The technologies for realizing 97 hierarchical IETF network slice need to be considered. 99 This document describes the typical scenarios in which the deployment 100 of hierarchical IETF network slices may be needed. This document 101 also provides the considerations and requirements on the technologies 102 in different network planes to realize hierarchical IETF network 103 slices. 105 2. Scenarios of Hierarchical IETF Network Slices 107 In this section, several possible network scenarios of hierarchical 108 IETF network slicing are introduced. 110 2.1. Per-Customer Network Slices in an Industrial Network Slice 112 One of the typical network slice deployment is in the multi- 113 industrial network case, in which a physical network is used to 114 deliver services of multiple vertical industries. Separate IETF 115 network slices are provided for different industries, such as health- 116 care, education, manufacturing, governmental affairs, etc. Then 117 within the network slice of a specific industry, there may be need to 118 create separate network slices for some or all of the customers 119 within this industry. 121 For example, within the education network slice, some of the 122 universities may require for a separate network slice to connect with 123 a set of the branch campuses. Another examples is within the health- 124 care network slice, some of the hospitals may require for a separate 125 network slice for the connectivity and services between a set of the 126 branch hospitals. 128 ---------------------------------/ 129 / Industry Slice 1 / 130 / ----------------------- / 131 / / Customer Slice 1 / / 132 / -----------------------/ / 133 / ----------------------- / 134 / / Customer Slice 2 / / 135 / -----------------------/ / 136 / ... / 137 ---------------------------------/ 138 ... 139 ---------------------------------/ 140 / Industry Slice 2 / 141 / ----------------------- / 142 / / Customer Slice 1 / / 143 / -----------------------/ / 144 / ----------------------- / 145 / / Customer Slice 2 / / 146 / -----------------------/ / 147 / ... / 148 ---------------------------------/ 149 Figure 1. Hierarchical Network Slices: Scenario 1 151 2.2. Per-application Network Slices in a Customer Network Slice 153 Another network slice deployment case is to provide dedicated IETF 154 network slices for some important customers as the first-level 155 network slices. While the customers may require to further split 156 their network slices into different sub-network slices for different 157 applications. 159 For example, a network slice for a hospital may be further divided to 160 carry different type of medical services, such as remote patient 161 monitoring, remote ultrasound diagnose, medical image transmission 162 etc. 164 ---------------------------------/ 165 / Customer Slice 1 / 166 / ----------------------- / 167 / / APP Slice 1 / / 168 / -----------------------/ / 169 / ----------------------- / 170 / / APP Slice 2 / / 171 / -----------------------/ / 172 / ... / 173 ---------------------------------/ 174 ... 175 ---------------------------------/ 176 / Customer Slice 2 / 177 / ----------------------- / 178 / / APP Slice 1 / / 179 / -----------------------/ / 180 / ----------------------- / 181 / / APP Slice 2 / / 182 / -----------------------/ / 183 / ... / 184 ---------------------------------/ 185 Figure 2. Hierarchical Network Slices: Scenario 2 187 2.3. Network Slice Services in a Wholesale Network Slice 189 IETF network slice can also be delivered as a wholesale service to 190 other network operators. In this case a network operator can be the 191 customer of a network slice, and it may also need to deliver IETF 192 network slice services to its customers. This is similar to the 193 Carrier's Carrier VPN service mode, while some additional 194 requirements on the SLOs and SLEs may be required by the second-level 195 network slice customer. 197 ---------------------------------/ 198 / Wholesale Slice 1 / 199 / ----------------------- / 200 / / Customer Slice 1 / / 201 / -----------------------/ / 202 / ----------------------- / 203 / / Customer Slice 2 / / 204 / -----------------------/ / 205 / ... / 206 ---------------------------------/ 207 ... 208 ---------------------------------/ 209 / Wholesale Slice 2 / 210 / ----------------------- / 211 / / Customer Slice 1 / / 212 / -----------------------/ / 213 / ----------------------- / 214 / / Customer Slice 2 / / 215 / -----------------------/ / 216 / ... / 217 ---------------------------------/ 218 Figure 3. Hierarchical Network Slices: Scenario 3 220 3. Considerations about Hierarchical Network Slice Realization 222 To support the realization of hierarchical network slices, there will 223 be specific requirements on the technologies used in each network 224 plane. In this section, the requirements of hierarchical network 225 slicing on the forwarding plane network resource partitioning, the 226 data plane encapsulations, the control plane protocols and the 227 management plane are analyzed. 229 3.1. Forwarding Plane Network Resource Partitioning 231 For the realization of IETF network slices, the network resources in 232 the underlying forwarding plane needs to be partitioned into 233 different network resource partitions (NRPs), each NRP is used as the 234 underlay network construct to support one or a group of IETF network 235 slice services. In order to support hierarchical network slices, the 236 forwarding plane network resources needs to be able to be partitioned 237 in a hierarchical manner. Taking a two-level hierarchical network 238 slice as an example, the bandwidth resource of a physical interface 239 needs to be partitioned in two levels. There can be different 240 options in modeling the interface resources of network resource 241 partition. 243 The first option is to treat the network resources in the first-level 244 NRPs as a set of layer-3 sub-interfaces, each with dedicated link 245 bandwidth, and the second-level NRPs are represented as virtual data 246 channels under the layer-3 sub-interfaces, as shown in the figure 247 below: 249 +----------------------+ 250 | +----------------+ | 251 | | +------------+ | | 252 | | |Data Channel| | | 253 | | +------------+ | | 254 | | ... | | 255 | | +------------+ | | 256 | | |Data Channel| | | 257 | | +------------+ | | 258 | +----------------+ | 259 | layer-3 subinterface | 260 | | 261 | . . . | 262 | +----------------+ | 263 | | +------------+ | | 264 | | |Data Channel| | | 265 | | +------------+ | | 266 | | ... | | 267 | | +------------+ | | 268 | | |Data Channel| | | 269 | | +------------+ | | 270 | +----------------+ | 271 | layer-3 subinterface | 272 +----------------------+ 273 Physical Interface 275 Figure 4. Modeling of Network Resource Partition on Interface: Option 1 277 The second option is to treat the first-level NRPs as layer-2 sub- 278 interface of the layer-3 interface, and the second-level NRPs are 279 represented as virtual data channels under the layer-2 sub-interface, 280 as shown in the figure below: 282 +----------------------+ 283 | +----------------+ | 284 | | +------------+ | | 285 | | |Data Channel| | | 286 | | +------------+ | | 287 | | ... | | 288 | | +------------+ | | 289 | | |Data Channel| | | 290 | | +------------+ | | 291 | +----------------+ | 292 | layer-2 subinterface | 293 | | 294 | . . . | 295 | +----------------+ | 296 | | +------------+ | | 297 | | |Data Channel| | | 298 | | +------------+ | | 299 | | ... | | 300 | | +------------+ | | 301 | | |Data Channel| | | 302 | | +------------+ | | 303 | +----------------+ | 304 | layer-2 subinterface | 305 +----------------------+ 306 Layer-3 Physical Interface 308 Figure 5. Modeling of Network Resource Partition on Interface, Option 2 310 The options of the network resource partition modeling may have 311 different impact to the control plane in terms of the number of 312 control protocol sessions to be maintained, and the amount and types 313 of information to be distributed in the control plane. Depends on 314 the network deployment requirements, different resource partition 315 modeling options may be used. 317 3.2. Data Plane Identifiers 319 Traffic of IETF network slices can be steered into the corresponding 320 underlay network construct based on one or multiple fields in the 321 data packet, so that the corresponding NRPs are used for processing 322 and forwarding the packet. On the edge nodes of an IETF network 323 slice, traffic flows can be classified and mapped to IETF network 324 slices using flexible matching rules based on operators' local 325 policy. While on the intermediate network nodes, a dedicated data 326 plane NRP Identifier [I-D.dong-teas-nrp-scalability] can facilitate 327 the identification of the NRP and the set of network resources 328 allocated on the network nodes for packet processing. 330 For hierarchical IETF network slices, such data plane identifiers may 331 need to be able to identify both the first-level NRP and the second- 332 level NRP. There are several options in the design of the data plane 333 NRP identifier for hierarchical network slices. 335 The first option is to use a unified data plane identifier for both 336 the first-level NRP and the second-level NRP. In this case, the 337 first-level NRPs and the second-level NRPs are identified using 338 distinct identifier values. 340 +-----------------------------------------+ 341 | Unified NRP ID for different levels | 342 +-----------------------------------------+ 344 Figure 6. Unified NRP ID 346 The second option is to use a hierarchical identifiers for the first- 347 level NRP and the second-level NRP. In this case, the first part of 348 the identifier is used to identify the first-level NRP, and the 349 second part of the identifier is used to identify the second-level 350 NRP. Depends on the data plane technologies used, the hierarchical 351 NRP may be encapsulated in a continuous field in the packet, or may 352 be positioned in separate fields. 354 +--------------------+--------------------+ 355 | Level-1 NRP ID | Level-2 NRP ID | 356 +--------------------+--------------------+ 358 Figure 7. Hierarchical NRP IDs 360 3.3. Control Plane 362 The control plane may be used for the distribution of the attributes 363 and states of the hierarchical NRPs and the associated data plane 364 identifiers among network nodes in the NRP and also to the network 365 controller. With different NRP modeling, the information may be 366 advertised as either layer-3 or layer-2 network information, which 367 may have different scalability implications to the control plane. 368 And as the number of hierarchical network slices increases, some 369 control plane optimization mechanisms may be needed to adopt to the 370 amount of information advertised. 372 3.4. Management Plane 374 For the management hierarchical network slices, the management system 375 of network operator needs to provide life-cycle management to both 376 the first-level network slices and the second-level network slices. 377 It should allow to manage the first-level and second-level network 378 slices separately, while the relationship between the first-level and 379 second-level network slices also need to be maintained in the 380 management system. The management system may need to support 381 additional functions and procedures for the management of 382 hierarchical network slices. Further analysis about the requirement 383 on the management plane is for further study. 385 4. Security Considerations 387 TBD 389 5. IANA Considerations 391 This document makes no request of IANA. 393 6. Contributors 395 Zhibo Hu 396 Email: huzhibo@huawei.com 398 7. Acknowledgments 400 The authors would like to thank Yawei Zhang for the review and 401 discussion of this document. 403 8. References 405 8.1. Normative References 407 [I-D.ietf-teas-ietf-network-slices] 408 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 409 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 410 Network Slices", Work in Progress, Internet-Draft, draft- 411 ietf-teas-ietf-network-slices-08, 6 March 2022, 412 . 415 8.2. Informative References 417 [I-D.dong-teas-nrp-scalability] 418 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 419 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 420 "Scalability Considerations for Network Resource 421 Partition", Work in Progress, Internet-Draft, draft-dong- 422 teas-nrp-scalability-01, 7 February 2022, 423 . 426 [I-D.ietf-teas-enhanced-vpn] 427 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 428 Framework for Enhanced Virtual Private Network (VPN+) 429 Services", Work in Progress, Internet-Draft, draft-ietf- 430 teas-enhanced-vpn-09, 25 October 2021, 431 . 434 Authors' Addresses 436 Jie Dong 437 Huawei Technologies 438 Huawei Campus, No. 156 Beiqing Road 439 Beijing 440 100095 441 China 442 Email: jie.dong@huawei.com 444 Zhenbin Li 445 Huawei Technologies 446 Huawei Campus, No. 156 Beiqing Road 447 Beijing 448 100095 449 China 450 Email: lizhenbin@huawei.com