idnits 2.17.1 draft-geng-coms-architecture-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 : ---------------------------------------------------------------------------- ** There are 81 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.boucadair-connectivity-provisioning-protocol' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-15 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 none L. Geng 3 Internet-Draft China Mobile 4 Intended status: Informational L. Qiang 5 Expires: September 6, 2018 Huawei 6 J. Ordonez 7 O. Adamuz-Hinojosa 8 P. Ameigeiras 9 University of Granada 10 D. Lopez 11 Telefonica I+D 12 L. Contreras 13 Telefonica 14 March 5, 2018 16 COMS Architecture 17 draft-geng-coms-architecture-02 19 Abstract 21 This document defines the overall architecture of a COMS based 22 network slicing system. COMS works on the top level network slice 23 orchestrator which directly communicates with the network slice 24 provider and enables the technology-independent network slice 25 management. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 3 64 4. Advanced Architecture . . . . . . . . . . . . . . . . . . . . 4 65 5. Integration with NFV . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 9. Informative References . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Network slicing itself is a new concept triggered by vertical 75 industry, but that doesn't mean new forwarding technology is needed. 76 As an example given by [draft-arkko-arch-virtualization] shows, there 77 are multiple existing technologies could be used for network slicing 78 - VLAN tags are used in an ethernet segment, MPLS or VPNs across the 79 domain. If the storage and computing resources are considered, there 80 will be more available technologies (e.g., SFC). 82 Let's follow IETF's routine and image what will happen from the 83 bottom-up view. At first, existing technologies evolve toward 84 network slicing at forwarding plane in their own scopes. Then slice 85 management related functions will be patched at management/control 86 planes. When a network slice is going to be deployed inside a 87 domain, one of implementation technology will be selected, and the NS 88 provider directly operates on the management plane of this selected 89 technology. For example, If VPN is selected as the implementation 90 technology, then a network slice is a VPN for the NS provider in this 91 domain. While if SFC is selected in other domain, then a network 92 slice is a SFC for NS provider. What will happen if a network slice 93 across both VPN and SFC domains? There is no uniform management 94 manner in this case. 96 Then try to consider from the top-down view. There is no doubt that 97 slicing requirement is generated from NS tenant. When a NS tenant 98 request for NS service, normally he will not specify which 99 implementation technology should be used. Similarly, when the tenant 100 operates/manages his purchased slice, he doesn't want to care about 101 the technical details. 103 We can easily observe that bottom-up and top-down approaches will 104 eventually converge on a technology-independent common management 105 plane, that is exactly what COMS (Common Operation and Management on 106 network Slices) doing. 108 This document will explain how COMS works, and define the 109 architecture of COMS. Architecture discussed in this document is 110 assumed to be used only inside Transport Network region, and the end- 111 to-end network slice/slicing also just refers to the slice/slicing 112 across multiple TN domains in this document. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 Other network slicing related words used in this document are 121 interpreted as description in [COMS-PS]. 123 Notations used in this document are interpreted as follows: 125 T(x->y): end-to-end delay from x to y; 127 B(x->y): bandwidth from x to y; 129 S(x): storage space of x. 131 3. Overall Architecture 133 This section provides the overall architecture for a COMS based 134 network slicing system as shown in Figure 1. If multiple such kind 135 of systems deployed in different domains, these systems may stitches 136 together through the method discussed in [Stitching-Management] and 137 [Stitching-Data]. COMS works on the top network orchestrator inside 138 Transport Network region, which directly receives the network slice 139 service profile, operation and management requests for network 140 slices. Based on received information, the network orchestrator will 141 select the most appropriate implementation technologies, and map the 142 technology independent requests into the technology specific 143 configuration information that will be sent to the corresponding 144 network slice controller/orchestrator downwards. 146 | Network Slice 147 | Service Profile 148 | 149 +--------------------------v----------------------------+ 150 | | 151 | Top Level Network Orchestrator based on COMS | 152 | | 153 +--------------------------+----------------------------+ 154 | 155 +--------+------------------+-------+-----------+----------------+ 156 | | | | | 157 | +------v--------+ +------v--------+ +-------v-------+ +----v----+ 158 | | | | | | | | | 159 | | NS Ctrlr/Orch | | NS Ctrlr/Orch | | NS Ctrlr/Orch | | ... | 160 | | | | | | | | | 161 | +-------+-------+ +-------+-------+ +-------+-------+ +----+----+ 162 | | | | | 163 | | | | | 164 ==v=========v==================v==================v================v===== 165 = = 166 = +------------+ +------------+ +------------+ +------------+ +-------+ = 167 = |Connectivity| | Computing | | Storage | |Generalized | | ... | = 168 = | | | | | | |Functions | | | = 169 = +------------+ +------------+ +------------+ +------------+ +-------+ = 170 = = 171 ========================================================================= 173 Figure 1: Overall Architecture of COMS 175 4. Advanced Architecture 177 This section discusses the detailed architecture of a COMS based 178 network slicing system through an example shown in Figure 2. We do 179 not intend to design the inner framework of the top level network 180 slicing orchestrator but to explain how COMS works. Four components 181 insides the top level network orchestrator are logical components 182 that could be converged sometimes. 184 o Common Information Model: can be understood as the template, 185 according to which the received network slice service profile is 186 translated. 188 o Split Service Profile into Domains: the end-to-end service profile 189 is split into the service profiles inside different domains. 191 o Select Specific Implementation Technologies: there may be multiple 192 available implementation technologies inside a domain, select the 193 most appropriate one according to the service profile. As 194 Figure 2's example shows, since the end-to-end delay in Domain 1 195 is very small, the Flex-E will be selected. While in Domain 2 two 196 storage units are required, the NFV technology will be selected. 198 o Map to Selected Technologies: necessary mapping to the controller/ 199 orchestrator of selected technologies. 201 |Network Slice Service Profile 202 | 203 ************************************************************************** 204 *Top Level Network Orchestrator based on COMS * 205 * | * 206 * +-------------------------------v ---------------------------------+ * 207 * |Common Information Model | * 208 * | ................................................................ | * 209 * | . ~~~~~~~ T(A->B)<=10ms; B(A->B)>=10M ~~~~~~~ . | * 210 * | . ~ A ~---------------------------------------~ B ~ S(B)=1G. | * 211 * | . ~~~~~~~ ~~~~~~~ . | * 212 * | . | T(A->C)<=20ms; B(A->C)>=10M ~~~~~~~ . | * 213 * | . +-----------------------------------------~ C ~ S(C)=2G. | * 214 * | . ~~~~~~~ . | * 215 * | ................................................................ | * 216 * +--------------------------------+---------------------------------+ * 217 * | * 218 * +--------------------------------v---------------------------------+ * 219 * |Split Service Profile into Domains | * 220 * |................................. ................................| * 221 * |. Domain 1 . .Domain 2 .| * 222 * |. T(A->D)<=2ms . . T(D->B)<=8ms S(B)=1G .| * 223 * |. ~~~~~~~ B(A->D)>=10M ~~~~~~~ B(D->B)>=10M ~~~~~~~ .| * 224 * |. ~ A ~ --------------~ D ~-----------------~ B ~ .| * 225 * |. ~~~~~~~ ~~~~~~~ ~~~~~~~ .| * 226 * |. | T(A->E)<=2ms . . T(E->C)<=18ms S(C)=2G .| * 227 * |. | B(A->E)>=10M ~~~~~~~ B(E->C)>=10M ~~~~~~~ .| * 228 * |. +-----------------~ E ~-----------------~ C ~ .| * 229 * |. ~~~~~~~ ~~~~~~~ .| * 230 * |..................................................................| * 231 * +---------------------------------+--------------------------------+ * 232 * | * 233 * +---------------------------------v---------------------------------+ * 234 * |Select Specific Implementation Technologies | * 235 * | ............................. ............................ | * 236 * | .Domain 1 . .Domain 2 . | * 237 * | . Flex-E . . VPN+NFV . | * 238 * | ............................. ............................ | * 239 * +---------------+----------------------------------+----------------+ * 240 * | | * 241 * +---------------v----------------------------------v----------------+ * 242 * |Map to Selected Technologies | * 243 * +---------+------------------------+--------------------+-----------+ * 244 ************************************************************************** 245 | | | 246 *********v*********** *********v******** **********v********* 247 * Flex-E Controller * * VPN Controller * * NFV Orchestrator * 248 *********+*********** *********+******** **********+********* 249 | | | 250 *********v*********** *********v********************v********* 251 * Physical/Logical * * Physical/Logical * 252 * Resources inside * * Resources inside * 253 * Domain 1 * * Domain 2 * 254 ********************* **************************************** 256 Figure 2: Advanced Architecture of COMS 258 5. Integration with NFV 260 This section details the integration of the NFV framework [NFV-MANO] 261 in the COMS architecture. 263 Network slice providers aim to accommodate a myriad of use cases and 264 application scenarios from multiple tenants over a common network 265 infrastructure. To that end, network slice providers build up 266 multiple network slice instances (NSIs), each customized to serve the 267 specific service demands of a particular tenant. An NSI is a logical 268 self-contained network instance that network slice providers offer to 269 a tenant, and that a tenant can consume. Although NSIs may span 270 across multiple network segments (e.g., RAN, transport, and core 271 network), this document only considers the transport network domain. 273 NFV may play a key role in network slicing, enabling its realization 274 in a cost-efficient manner. Using the flexibility and virtualization 275 capabilities that the NFV framework brings, a network slice provider 276 can create and operate multiple NSIs over a common shared network 277 infrastructure with isolation guarantees in terms of performance, 278 management, security, and privacy [Ordonez-Network-Slicing]. To 279 provide the tenant with the required performance and functionality, 280 an NSI includes one or more network services, each consisting of a 281 chained set of compassable atomic units called virtualized network 282 functions (VNFs). These VNFs are software-based implementations of 283 network functions that rely on computing, storage, and connectivity 284 resources for their execution and communication. To simultaneously 285 serve the requirements of multiple NSIs, the network slice provider 286 makes use of the resources that are at its disposal, and efficiently 287 orchestrate them across NSIs. Although the network slice provider 288 can own these resources, we consider it rents them from one or more 289 infrastructure owners following the Infrastructure-as-a-Service 290 (IaaS) paradigm. In this case, the network slice provider takes the 291 role of a network infrastructure tenant. Note that each of the three 292 actors presented here (network infrastructure owner, network slice 293 provider, and network slice tenant) defines a different 294 administrative domain. 296 The NSIs shown in Figure 3 run parallel on a common shared transport 297 network infrastructure. The transport network infrastructure 298 consists of connectivity resources that may span across multiple 299 administrative domains (i.e., different network infrastructure 300 owners). These resources include WAN nodes and links providing 301 reachability across geographically remote data centers, where the 302 VNFs from different NSIs run. In particular, they connect together 303 the network connectivity endpoints (e.g., gateways) of those data 304 centers. 306 To simultaneously serve the connectivity needs of the NSIs using 307 resources within its administrative domain, each network 308 infrastructure owner has a WAN Infrastructure Manager (WIM). The WIM 309 is a NFV functional block that performs control-management actions 310 over the underlying connectivity resources to deploy and operate a 311 number of L2/L3 virtual topologies with different levels of 312 abstractions. To enforces the connectivity required by an NSI, the 313 WIM abstracts the resources under its management, and creates a 314 customized virtual topology that logically connects the data centers 315 hosting the NSI's VNFs. The resources of each data center are 316 managed with a Virtual Infrastructure Manager (VIM). This NFV 317 functional block play a similar role to the WIM, but extending their 318 management domain to computing and storage resources. 320 The transport network resources, managed by the underlying network 321 infrastructure owners using their WIMs/VIMs are delivered to the 322 network slice provider logically placed on top of them. The network 323 slice provider makes use of these resources to deploy and operate the 324 NSIs that are under its management. For this end, it may rely on the 325 NFV Orchestrator (NFVO) functionality. According to the NFV 326 framework, NFVO is a functional block with two well-defined 327 functionalities: resource orchestration and network service 328 orchestration. The former focuses on orchestrating network 329 infrastructure resources across multiple VIMs/WIMs, while the latter 330 performs lifecycle management operations (e.g., instantiation, 331 scaling, updating, termination, etc.) over the network service(s) 332 built using those resources. Due to the different scope of these two 333 set of functions, the NFVO may be logically split into two functional 334 blocks: Resource Orchestrator and Network Service Orchestrator. 336 ^ +---------------------------------------------------------+ 337 | | Cross-Segment Slice Manager | 338 | +-------------------------^-------------------------------+ 339 | | 340 | +-------------------v------------------------+ 341 | | Transport Network Slice Orchestrator <------+ 342 | +----------------------------------^-----^---+ | 343 | | | | 344 | +------------------------------------ | ----+------+ | 345 | | NSI M | | | 346 | +--------------------------------------- | --------+ | | 347 | | NSI 1 | | | | 348 | +---------------------------+ +---v---+ | | | 349 Network | | Tenant SDN Controller <------> OSS | | | | 350 Slice | +--^-------^--------^----+--+ +---^---+ | | | 351 Provider | | | | | | | | | 352 Domain | +--v--+ +--v--+ | +--v--+ +------v-------+ | | | 353 | | VNF | | VNF | .. | | VNF | | Network | | | | 354 | | +--^--+ +--^--+ | +--^--+ | Service | | | | 355 | | | | | | | Orchestrator | | | | 356 | | | +-----+--------v--+ | +------^-------+ | | | 357 | | +-> vSwitch/vRouter <-+ | |-++ | 358 | | +-----------------+ | | | | 359 | +--------------------------------------- | --------+ | | 360 | | | | 361 | +------------------------------------------v-----------v--+ | 362 + | Resource Orchestrator <-+ 363 +--------^-------------------^-------------------^--------+ 364 +-------+ | | | 365 +-----v-----+ +-----v-----+ +-----v-----+ 366 + | WIM | ... | VIM | ... | WIM | 367 | +-----+-----+ +-----+-----+ +-----+-----+ 368 | | | 369 Network +-------+------+ +-----------------+ +------+-------+ 370 Infrastructure | Connectivity | | +-------------+ | | Connectivity | 371 Owner | Resources | | | Computing/ | | | Resources | 372 Domain +--------------+ | | Storage/ | | +--------------+ 373 | |Connectivity | | 374 | | | Resources | | 375 | | +-------------+ | 376 | | Data Center | 377 v +-----------------+ 379 Figure 3: Integration of NFV framework in COMS architecture 381 To orchestrate the resources that are at its disposal (those provided 382 by the underlying network infrastructure owners), the network slice 383 provider has a single Resource Orchestrator. The main role of the 384 Resource Orchestrator is to dispatch this finite set of resources 385 across the operative NSIs in an optimal way, with the aim of 386 simultaneously satisfying their (potentially diverging) performance 387 requirements. To bring multiplexing gains and cost savings in this 388 task, the Resource Orchestrator may take advantage of resource 389 sharing. Resource sharing introduces flexibility and efficiency in 390 slice provisioning, as network slice provider's resources can be 391 dynamically allocated and released across NSIs according to the time- 392 varying resource requirements that their tenants impose. This 393 approach requires an adequate resource management framework for the 394 Resource Orchestrator that carefully finds an optimal solution, 395 enabling resource sharing among NSIs when necessary, while preserving 396 their performance isolation. 398 As shown in Figure 3, each of the operative NSIs serving a network 399 slice tenant comprises a tenant SDN controller, a Network Service 400 Orchestrator, and an Operation Support System (OSS). On the one 401 hand, the tenant SDN controller configures the VNFs at application 402 level, and chains them to dynamically build up the network service(s) 403 that are required in the NSI. For VNF configuration management, the 404 tenant SDN controller uses southbound configuration protocols such as 405 NETCONF. For VNF chaining management, it leverages the networking 406 capabilities provided by virtual switches/routers, sending them 407 appropriate forwarding instructions using southbound control 408 protocols such as OpenFlow. On the other hand, the Network Service 409 Orchestrator manages the lifecycle of the network service(s). 410 Finally, the OSS performs the intra-NSI management, bridging the gap 411 between the Network Service Orchestrator and the tenant SDN 412 controller, and coordinating their operations and management data. 413 The OSS is also the entry point of the NSI, providing management 414 capability exposure to external blocks. By way of example, the 415 network slice tenant can use the OSS to gain access to the NSI and 416 operate it at its convenience. 418 The description given above focuses on run-time phase, assuming the 419 NSIs are operative, and omitting the deployment steps referred in 420 Section 1. To trigger the deployment of a network slice, the network 421 slice provider needs other functional blocks. These functional 422 blocks include a Cross-Segment Slice Manager, and one or more Network 423 Slice Domain Orchestrators. The Cross-Segment Slice Manager receives 424 a network slice service profile from the tenant. This profile 425 contains the (end-to-end) slice requirements. The Cross-Segment 426 Slice Manager decompose these requirements into one or more network 427 slice domain slice requirements, and send them to the respective 428 Network Slice Domain Orchestrators (e.g., RAN Slice Orchestrator, 429 Transport Network Slice Orchestrator, Core Network Slice 430 Orchestrator). Since the architecture discussed in this document is 431 assumed to be inside the transport network domain, we only consider 432 the Network Slice Transport Orchestrator. The Network Slice 433 Transport Orchestrator uses the network slice transport requirements 434 to determine which VNFs and network service(s) are required, and what 435 are their resource requirements. Once checked the Resource 436 Orchestrator can provision them, the steps for deploying the slice 437 begin. First, the Resource Orchestrator creates the resource slice. 438 Then, the OSS takes over the resource slice and configures it, 439 resulting in a networking slice. Finally, the OSS (assisted by the 440 Network Service Orchestrator and the Tenant SDN controller), 441 instantiates one or more network services (and their constituent 442 VNFs) over this networking slice to realize a service slice, making 443 it usable for the network slice tenant. 445 6. Security Considerations 447 There is no security problems introduced by this document. 449 7. IANA Considerations 451 There is no IANA action required by this document. 453 8. Acknowledgements 455 TBD 457 9. Informative References 459 [COMS-PS] "Problem Statement of Supervised Heterogeneous Network 460 Slicing", . 463 [draft-arkko-arch-virtualization] 464 "Considerations on Network Virtualization and Slicing", 465 . 468 [I-D.boucadair-connectivity-provisioning-protocol] 469 Boucadair, M., Jacquenet, C., Zhang, D., and P. 470 Georgatsos, "Connectivity Provisioning Negotiation 471 Protocol (CPNP)", draft-boucadair-connectivity- 472 provisioning-protocol-15 (work in progress), December 473 2017. 475 [NFV-MANO] 476 ETSI GS NFV-MAN 001, "Network Functions Virtualisation 477 (NFV); Virtual Network Functions Architecture", V1.1.1, 478 December 2014. 480 [Ordonez-Network-Slicing] 481 Ordonez-Lucena, J., Ameigeiras, P., Lopez, D., Ramos- 482 Munoz, J., Lorca, J., and J. Folgueira, "Network Slicing 483 for 5G with SDN/NFV: Concepts, Architectures, and 484 Challenges", IEEE Communications Magazine, vol. 55, no. 5, 485 pp. 80-87, May 2017. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 493 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 494 DOI 10.17487/RFC5440, March 2009, 495 . 497 [Stitching-Data] 498 "Gateway Function for Network Slicing", 499 . 502 [Stitching-Management] 503 "Interconnecting (or Stitching) Network Slice Subnets", 504 . 507 Authors' Addresses 509 Liang Geng 510 China Mobile 512 Email: gengliang@chinamobile.com 514 Li Qiang 515 Huawei 517 Email: qiangli3@huawei.com 519 Jose Ordonez Lucena 520 University of Granada 522 Email: jordonez@ugr.es 523 Oscar Adamuz Hinojosa 524 University of Granada 526 Email: oadamuz@ugr.es 528 Pablo Ameigeiras 529 University of Granada 531 Email: pameigeiras@ugr.es 533 Diego Lopez 534 Telefonica I+D 536 Email: diego.r.lopez@telefonica.com 538 Luis Miguel Contreras Murillo 539 Telefonica 541 Email: luismiguel.contrerasmurillo@telefonica.com