idnits 2.17.1 draft-defoy-coms-subnet-interconnection-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 (January 30, 2018) is 2276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-geng-coms-problem-statement-01 == Outdated reference: A later version (-01) exists of draft-homma-coms-slice-gateway-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 none X. de Foy 3 Internet-Draft A. Rahman 4 Intended status: Informational InterDigital Inc. 5 Expires: August 3, 2018 A. Galis 6 University College London 7 K. Makhijani 8 L. Qiang 9 Huawei Technologies 10 S. Homma 11 NTT 12 January 30, 2018 14 Interconnecting (or Stitching) Network Slice Subnets 15 draft-defoy-coms-subnet-interconnection-02 17 Abstract 19 This document aims to define the network slice subnet as a general 20 concept, and to augment a baseline network slice model with 21 attributes and operations related to interconnections between network 22 slice subnets. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 3, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Usage of NS Subnets . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Base Information Model . . . . . . . . . . . . . . . . . 5 63 2.2. Interconnection Anchors . . . . . . . . . . . . . . . . . 6 64 2.3. Interconnection Instances . . . . . . . . . . . . . . . . 8 65 2.4. Stitching Operation . . . . . . . . . . . . . . . . . . . 9 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 5. Informative References . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Network Slicing enables deployment and management of services with 74 diverse requirements on end-to-end partitioned virtual networks over 75 the same infrastructure, including networking, compute and storage 76 resources. [I-D.geng-coms-problem-statement] describes a problem 77 statement for supervised heterogeneous network slicing, enabling 78 users to deploy network slices including connectivity, computing and 79 storage components. 81 A resource-aware information model is currently being defined in 82 [I-D.qiang-coms-netslicing-information-model] to represent network 83 slices. Nevertheless, defining and managing a network slice (NS) 84 end-to-end does not always have to be done directly. It may be 85 convenient to define and manage separately subsets of an end-to-end 86 slice. The concept of network slice subnet is defined originally in 87 [NGMN_Network_Slicing] for 5G, though we only need to retain its 88 definition in the most universal form: network slice subnets are 89 similar to network slices in most ways but cannot be operated in 90 isolation as a complete network slice. They can however be 91 interconnected with other NS subnets to form a complete, end-to-end 92 network slice (i.e. interconnection and/or stitching of NS subnets). 93 To summarize: a NS subnet can be seen as a network slice with 94 unconnected links. The term "network slice segment" has also 95 occasionally been used to designate a similar concept. 97 This document aims to augment the base COMS model to help manage 98 interconnections between NS subnets. The base COMS model can be used 99 to represent an end-to-end network slice. The extensions described 100 in this document can be used to represent a slice subnet instead, and 101 can also be used to represent an interconnection inside an end-to-end 102 slice, i.e. they aim to represent interconnection points both 103 "before" and "after" the interconnection takes place. Operations 104 such as stitching subnets will also be described. The base model is 105 not technology specific, and therefore the description of 106 interconnections should not be either. Some interconnections may be 107 implemented using gateways in the data plane. 108 [I-D.homma-coms-slice-gateway] aims to describe the requirements on 109 such data plane network elements, and will provide input for the 110 management plane mechanisms described in the present document. 112 1.1. Usage of NS Subnets 114 Using NS subnets can help: 116 o Isolate management and maintenance of different portions of a 117 network slice, over multiple infrastructure domains, or even 118 within a single domain. For example, in Figure 1, NS orchestrator 119 (NSO) 2 manages subnet A, in isolation from subnets B and C 120 managed by NSO 3. NSO 1 can still manage the end-to-end slice as 121 a whole, but it does not need to deal in detail with each subnet. 123 o Isolate mapping towards different infrastructure technologies, 124 even within the same domain. This can simplify NS orchestrator 125 implementation, since each NSO can specialize in managing a 126 smaller set of technologies. 128 o Enable advanced functions such as sharing a slice subnet between 129 several slices, or substituting one slice subnet for another, e.g. 130 for coping with load. 132 +-----------+ 133 ******| NS Orch. 1|******** 134 * +-----------+ * 135 (COMS A) * * (COMS B+C) 136 * * 137 +-----------+ +-----------+ 138 | NS Orch. 2| | NS Orch. 3|***** 139 +-----------+ +-----------+ * 140 * * * 141 (COMS A) * (COMS B) * * (COMS C) 142 * A-B Inter- * B-C Inter- * 143 * connection * connection * 144 +-----------------+ . +-----------------+ . +-----------------+ 145 | +--+ | . | +--+ | . | +--+ | 146 | | +---------------------+ +--------------------+ | | 147 | ++-+ | . | ++-+ | . | ++-+ | 148 | | | . | | | . | | | 149 | +---+ | +---+ | . | +---+ | +---+ | . | +---+ | +---+ | 150 | | +-+--+ +-----------+ +-+--+ +----------+ +-+--+ | | 151 | +---+ +---+ | . | +---+ +---+ | . | +---+ +---+ | 152 +-----------------+ . +-----------------+ . +-----------------+ 154 <.. NS subnet A ..> <.. NS subnet B ..> <.. NS subnet C ..> 156 <....................... end-to-end slice .........................> 158 Figure 1: Overview of Network Slice Subnets Interconnection 160 Figure 1 illustrates how an end-to-end network slice may be composed 161 of multiple slice subnets, each managed independently by a same or 162 different NSO. In multi-administrative domain scenarios, using NS 163 subnets can help limiting the information that needs to be shared 164 between domains. At the infrastructure layer (i.e. in the data 165 plane), the interconnection between NS subnets may involve: 167 o a gateway, that performs protocol and/or identifier/label 168 translation as needed, 170 o two gateways, especially in cases where interconnected NS subnets 171 are in different administrative domains, 173 o nothing at all, in cases where the interconnection point can be 174 abstracted away, e.g. when the NS subnets share a common 175 infrastructure. In this case nodes from both NS subnets end up 176 being directly interconnected between each other. 178 1.2. Terminology 180 Network slicing related terminology used in this document should be 181 interpreted as described in [I-D.geng-coms-problem-statement]. 183 Network Slice Subnet (NS subnet): a network system comprised of 184 groups of connectivity, compute and storage resources, possibly 185 including network functions and network management entities, forming 186 a complete instantiated logical/physical network in support of 187 certain network and service characteristics. A network slice subnet 188 cannot be activated in isolation as an overall (end-to-end) network 189 slice, but must be interconnected with other slice subnets to form 190 one. 192 NS Stitching: a management operation consisting in creating an end- 193 to-end NS or a larger NS subnet, by interconnecting a set of NS 194 subnets together. 196 Interconnection Anchor: a management plane entity, part of a NS 197 subnet model, representing an end point for use in future stitching 198 operation. 200 Interconnection Instance (or Interconnect): a management plane 201 entity, part of a NS subnet model, representing an interconnection 202 realized by a stitching operation. It is distinct from a (data 203 plane) gateway: an interconnect may be realized with or without using 204 a gateway in the data plane. 206 2. Information Model 208 2.1. Base Information Model 210 The information model we use as base for network slicing is currently 211 being defined in [I-D.qiang-coms-netslicing-information-model]. It 212 is itself based on the network topology model ietf-network defined in 213 [I-D.ietf-i2rs-yang-network-topo], in which networks are composed of 214 nodes and links, and in which termination points (TP), defined in 215 nodes, are used to define source and destination of links. 217 A network slice data model instance, i.e. a "network" attribute of 218 the "ietf-network" model augmented using 219 [I-D.qiang-coms-netslicing-information-model]), represents a network 220 slice. When such a data model instance includes at least an 221 "interconnection anchor", as defined below, it represents a network 222 slice subnet instance. 224 At high level, the extensions defined in this document will augment 225 nodes and termination points: 227 module: ietf-network 228 +--rw networks 229 +--rw network* [network-id] 230 +--rw network-id 231 +--rw network-types 232 +--rw supporting-network* [network-ref] 233 | +--rw network-ref 234 +--rw node* [node-id] 235 | +--... (augmented with attributes for 236 | | anchor/interconnection nodes) 237 | +--rw nt:termination-point* [tp-id] 238 | | ... (augmented with attributes for 239 | | anchor/interconnection TP) 241 2.2. Interconnection Anchors 243 To represent an anchor point for future interconnections (i.e. an 244 unconnected end of a link), a simple solution is to use an 245 "interconnection anchor" termination point (or anchor TP). Within 246 the data model describing a subnet, any link not entirely contained 247 within the NS subnet must be terminated with such an anchor TP as 248 source or destination. An anchor TP belongs to a "node" attribute, 249 which we refer to as interconnection anchor node (or anchor node). 250 Anchor nodes should not include non-anchor TP or serve other non- 251 anchor related purposes (e.g. should not include any compute or 252 storage unit), in order to simplify the stitching operation. For 253 example, it will be easier to handle the case where the 254 interconnection anchors are abstracted away during a stitching 255 operation. Several anchor TPs can be grouped together in an anchor 256 node, and such grouping may be used as a hint during a stitching 257 operation (e.g. to place all interconnection points at a same 258 location). 260 As described in Figure 2, we represent a network slice subnet as a 261 network slice that also has one or more anchor nodes, which terminate 262 (at anchor TPs) links that need to be interconnected with external 263 nodes (cross-subnet links). 265 Slice Provider 266 | 267 +---------------------------------v---------------------------------+ 268 | Network Slice Orchestrator | 269 | | 270 | +---------------------------------------------------------------+ | 271 | | Data model: network slice composed of NS subnet 1 and 2 | | 272 | | | | 273 | | Network Slice Subnet 1 Network Slice Subnet 2 | | 274 | | +---------------------------+ +----------------------------+ | | 275 | | | cross-subnet link | | cross-subnet | | | 276 | | | +----------------+ | | link +------+ | | | 277 | | | | | | | +--------o node | | | | 278 | | | | |Interconnection| +---o--+ | | | 279 | | |+---o--+ +-------|-----+--+------|------+ | | | | 280 | | || node | | | | | | | | | | | 281 | | |+---o--+ | +-----|---+ | | +----|----+ | | | | | 282 | | | | | | | | | | | | | | | | | | 283 | | | | | | O - - - - - - - O | | | | | | 284 | | | | | | | | | | | | | | | | 285 | | | | | | anchor | | | | anchor | | | | | | 286 | | | | | | node | | | | node | | | | | | 287 | | | | | | | | | | | | +---+ | | | 288 | | | | | | O - - - - - - - O | | | | | | 289 | | | | | | | | | | | | | | | | | | 290 | | | | | +-----|---+ | | +----|----+ | +---o--+ | | | 291 | | | | | | | | | | | node | | | | 292 | | | | +-------|-----+--+------|------+ +---o--+ | | | 293 | | | | +------+ | | | | | | | | 294 | | | +-o node o-------+ | | +----------------+ | | | 295 | | | +------+ cross-subnet| | cross-subnet | | | 296 | | | link | | link | | | 297 | | +---------------------------+ +----------------------------+ | | 298 | +---------------------------------------------------------------+ | 299 +--------------------------------+----------------------------------+ 300 | 301 v 302 Network Infrastructure 304 Legend: o = termination point, O = anchor termination point 306 Figure 2: Network Slice Subnets Interconnection 308 Attributes of interconnection anchor nodes and termination points 309 include: 311 o Information enabling NS orchestrators to match anchor nodes and 312 TPs from both NS during a stitching operation. A label may be a 313 simple way to enable this. 315 o Information to help locate the interconnection. For example, it 316 could be a (sub-)domain name or geo-location information, that 317 indicates where the interconnection point should be located. This 318 can help for example in cases where the subnet is instantiated 319 before stitching. 321 o Information to help select the type of interconnection 322 establishment: for example, this can indicate a preference for 323 using interconnection over a gateway, or for abstracting away the 324 interconnection point in the infrastructure plane. 326 +--rw node* [node-id] 327 +-- (...) 328 +-- anchor_node_config 329 | +-- label (and/or other auto stitching help) 330 | +-- hint for location (domain, geolocation, etc.) 331 | +-- hint for type (1 gateway, 2 gateways, ...) 332 +--rw nt:termination-point* [tp-id] 333 +-- (...) 334 +-- anchor_tp_config 335 +-- label (and/or other auto stitching help) 336 +-- location (domain, geolocation, etc.) 337 +-- type (1 gateway, 2 gateways, ...) 339 2.3. Interconnection Instances 341 There are two options for representing post-stitching network slices 342 (or subnets). They are not mutually exclusive: 344 o Option 1: subnet data models are updated with information 345 describing the interconnection (e.g. anchor TPs and nodes are 346 updated with new attributes representing the existing connection, 347 if necessary). 349 o Option 2: a new data model is generated to represent the resulting 350 network slice (or subnet). In this merge data model, the 351 interconnection may or may not be represented, this can be a 352 choice made by the operator. 354 Option 1 and 2 can be used concurrently in a network. For example, a 355 parent NS orchestrator may manage stitched NS subnets through 356 underlying NS orchestrators, and at the same time expose to the NS 357 operator a merged data model representing the resulting end-to-end 358 slice. 360 To represent an existing interconnection in option 1, a simple 361 solution is to add attributes to existing anchor nodes and anchor 362 TPs. Those attributes will be described below. They aim to describe 363 state and configuration associated with an active interconnection. 365 To represent an existing interconnection in option 2, a simple 366 solution is to create new interconnection instance nodes and 367 termination point. The same attributes as in option 1 may be 368 associated with these nodes and TPs. 370 Attributes of interconnection instance nodes and termination points 371 include: 373 o State information (interconnection type, status, location...). 375 o Service assurance related information: besides measurements (on 376 throughput, loss rate, etc.), triggers depending on throughput, 377 latency, etc. can be linked with a management action or event. A 378 NS operator can use such events to take the decision to disable a 379 NS subnet, replace a NS subnet with another, etc. to maintain 380 overall service performance. 382 +--rw node* [node-id] 383 +-- (...) 384 +-- interconnection_instance_node_state 385 | +-- status 386 | +-- location (domain, geolocation, etc.) 387 | +-- type (1 gateway, 2 gateways, ...) 388 +-- interconnection_instance_node_service_assurance 389 | +-- events (including triggers and event IDs) 390 | +-- measurements 391 +--rw nt:termination-point* [tp-id] 392 +-- (...) 393 +-- interconnection_instance_tp_state 394 | +-- status 395 | +-- location (domain, geolocation, etc.) 396 | +-- type (1 gateway, 2 gateways, ...) 397 +-- interconnection_instance_node_service_assurance 398 +-- events (including triggers and event IDs) 399 +-- measurements 401 2.4. Stitching Operation 403 Stitching may occur when network slice subnets are initially 404 instantiated, or later after instantiation. This operation may 405 involve 2 or more NS subnets. 407 A first part of the operation is to identify which anchor TPs (i.e. 408 which links) to interconnect to each other. This matching should be 409 dictated by the design of each NS subnets. Attributes should be 410 present in anchor TPs to enable automatic matching without human 411 intervention at the time of stitching. Interconnected links need to 412 have compatible QoS attributes. 414 3. Security Considerations 416 Access control mechanisms for managing network slices can likely be 417 reused for network slice subnets, since their models should be 418 similar to each other. 420 Stitching 2 NS subnets together may be subject to some form of 421 authorization by a NS tenant. 423 4. IANA Considerations 425 This document has no actions for IANA. 427 5. Informative References 429 [I-D.geng-coms-problem-statement] 430 67, 4., Wang, L., Slawomir, S., Qiang, L., Matsushima, S., 431 Galis, A., and L. Contreras, "Problem Statement of 432 Supervised Heterogeneous Network Slicing", draft-geng- 433 coms-problem-statement-01 (work in progress), October 434 2017. 436 [I-D.homma-coms-slice-gateway] 437 Homma, S. and X. Foy, "Gateway Function for Network 438 Slicing", draft-homma-coms-slice-gateway-00 (work in 439 progress), January 2018. 441 [I-D.ietf-i2rs-yang-network-topo] 442 Clemm, A., Medved, J., Varga, R., Bahadur, N., 443 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 444 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 445 progress), December 2017. 447 [I-D.qiang-coms-netslicing-information-model] 448 Qiang, L., Galis, A., 67, 4., kiran.makhijani@huawei.com, 449 k., Martinez-Julia, P., Flinck, H., and X. Foy, 450 "Technology Independent Information Model for Network 451 Slicing", draft-qiang-coms-netslicing-information-model-02 452 (work in progress), January 2018. 454 [NGMN_Network_Slicing] 455 NGMN, "Description of Network Slicing Concept", 10 2016, 456 . 459 Authors' Addresses 461 Xavier de Foy 462 InterDigital Inc. 463 1000 Sherbrooke West 464 Montreal 465 Canada 467 Email: Xavier.Defoy@InterDigital.com 469 Akbar Rahman 470 InterDigital Inc. 471 1000 Sherbrooke West 472 Montreal 473 Canada 475 Email: Akbar.Rahman@InterDigital.com 477 Alex Galis 478 University College London 480 Email: a.galis@ucl.ac.uk 482 Kiran Makhijani 483 Huawei Technologies 484 2890 Central Expressway 485 Santa Clara CA 95050 486 USA 488 Email: kiran.makhijani@huawei.com 490 Li Qiang 491 Huawei Technologies 492 Huawei Campus, No. 156 Beiqing Rd. 493 Beijing 100095 495 Email: qiangli3@huawei.com 496 Shunsuke Homma 497 NTT, Corp. 498 3-9-11, Midori-cho 499 Musashino-shi, Tokyo 180-8585 500 Japan 502 Email: homma.shunsuke@lab.ntt.co.jp