idnits 2.17.1 draft-homma-rtgwg-slice-gateway-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 469: '... edge of E2E-NSs MUST have the capabil...' RFC 2119 keyword, line 473: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 479: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 485: '...en NSSI: An SLG MUST identify and cla...' RFC 2119 keyword, line 494: '... SLGs MUST provide functions for tra...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 87 has weird spacing: '...ructure of SL...' -- The document date (November 3, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-defoy-coms-subnet-interconnection-01 -- No information found for draft-homma-slice-provision-models - is the name correct? == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-11 == Outdated reference: A later version (-02) exists of draft-qiang-coms-netslicing-information-model-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg S. Homma 3 Internet-Draft NTT 4 Intended status: Informational X. de Foy 5 Expires: May 6, 2020 InterDigital Inc. 6 A. Galis 7 University College London 8 LM. Contreras 9 Telefonica 10 November 3, 2019 12 Gateway Function for Network Slicing 13 draft-homma-rtgwg-slice-gateway-01 15 Abstract 17 This document describes the roles and requirements for a slice 18 gateway that is a function or function group for handling data plane 19 traffic, such as connecting/disconnecting and compose/decompose 20 network slice subnet instances and providing network slices from end 21 to end. The interworkings between management and control elements at 22 the management and control planes with the gateway function for 23 controlling and orchestrating end-to-end network slices are also 24 presented in this document. 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 May 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 62 3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 6 63 4. Architecture of Network Slicing System . . . . . . . . . . . 8 64 4.1. Network Slice Management System Architecture . . . . . . 8 65 5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Management of NS as Infrastructure . . . . . . . . . . . 10 67 5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 10 68 5.1.1.1. Identification/Classification . . . . . . . . . . 11 69 5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 11 70 5.1.1.3. Isolation among NSs . . . . . . . . . . . . . . . 12 71 5.1.1.4. Service Chaining as Infrastructural 72 Mechanism(*Optional) . . . . . . . . . . . . . . 13 73 5.1.2. Control/Management Planes Aspects . . . . . . . . . . 13 74 5.1.2.1. Interfaces to Controllers or Operation Systems . 13 75 5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 13 76 5.1.2.3. Authentication Authorization Accounting (AAA) . . 13 77 5.1.2.4. Operation Administration and Maintenance(OAM) . . 14 78 5.1.2.5. Traffic Monitoring . . . . . . . . . . . . . . . 14 79 5.2. Management of Services on NS (*Optional) . . . . . . . . 14 80 5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 14 81 5.2.1.1. Identification/Classification . . . . . . . . . . 14 82 5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 14 83 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 15 84 5.2.2. Control/Management Planes Aspects . . . . . . . . . . 15 85 5.2.2.1. Interfaces to Service Management Systems . . . . 15 86 5.2.2.2. Collection of Telemetry information . . . . . . . 15 87 6. Structure of SLG . . . . . . . . . . . . . . . . . . . . . . 15 88 7. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 16 89 7.1. Examples of Components Required to Maintain SLG Functions 16 90 7.2. SLG Types Depending on Locations on NS . . . . . . . . . 17 91 7.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 17 92 7.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 17 93 7.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 17 94 7.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 17 95 7.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 20 96 7.5. Software vs. Hardware . . . . . . . . . . . . . . . . . . 21 97 8. Interconnection between NSSIs . . . . . . . . . . . . . . . . 21 98 8.1. Pre-arrangement of transport protocols . . . . . . . . . 21 99 8.2. Quality Assurance between SLGs . . . . . . . . . . . . . 21 100 8.3. Secure Interconnection . . . . . . . . . . . . . . . . . 22 101 9. Interfaces of SLG Controller . . . . . . . . . . . . . . . . 22 102 9.1. Southbound Interface . . . . . . . . . . . . . . . . . . 22 103 9.2. Northbound Interface for Higher Operation Systems . . . . 22 104 9.3. Northbound Interface for Customers/Tenants . . . . . . . 22 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 107 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 108 13. Informative References . . . . . . . . . . . . . . . . . . . 23 109 Appendix A. Requirements for each SLG Type . . . . . . . . . . . 25 110 Appendix B. Position of SLG on ETSI NFV MANO . . . . . . . . . . 26 111 Appendix C. Complemention of Network Slicing in 3GPP . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 Network slicing is an approach to create separate virtual networks in 117 support of service depending on several requirements on the same 118 physical resources, and it enables networks to adapt to requirements, 119 which is diverse more, inexpensively and flexibly. The overview is 120 introduced in [Slicing_Tutrial] and [NECOS]. 122 It's also expected to enhance usability of infrastructural networks 123 for tenants and create new business opportunities. For example, by 124 using network slices lent from infrastructure operators, other 125 industrial companies can provide communication services including 126 ensurance of network transport without having physical 127 infrastructure. 129 From a business point of view, a slice includes a combination of all 130 the relevant network resources, functions, and assets required to 131 fulfill a specific business case or service, including OSS, BSS and 132 DevOps processes. 134 From the network infrastructure point of view, network slice requires 135 the partitioning and assignment of a set of resources that can be 136 used in an isolated, disjunctive or non- disjunctive manner for that 137 slice. 139 From the tenant point of view, network slice provides different 140 capabilities, specifically in terms of their management and control 141 capabilities, and how much of them the network service provider hands 142 over to the slice tenant. As such there are two kinds of slices: (A) 143 Inner slices, understood as the partitions used for internal services 144 of the provider, retaining full control and management of them. (B) 145 Outer slices, being those partitions hosting customer services, 146 appearing to the customer as dedicated networks. 148 Network slices are established with combination of various 149 technologies, such as software defined network (SDN), network 150 function virtualization (NFV), or traffic engineering, and managed/ 151 operated with automation technologies such as orchestrator. 153 Assumed use cases of network slices include establishment of virtual 154 networks whose qualities are guaranteed from end to end under the 155 supervision of multi-domain orchstrators. In such cases, a network 156 slice subnet is created on each domain, such as access network and 157 core network, and an end-to-end network slices is composed of 158 connected subnets. 160 Network slice subnets are built based on specifications of the 161 underlay network, and thus the used technologies might vary. 162 Therefore, a gateway function, which enables to connect subnets while 163 adapting the differentiations and forward data packets to/from the 164 appropriate next subnet, is required. 166 This document describes the gateway function for network slicing, 167 called slice gateway or SLG, and its role and requirements. Note 168 that defining a new data plane technology is not a goal of this 169 draft. In addition, this draft aims to specify management-related 170 requirements for an SLG, which may be implemented using existing data 171 plane technologies. 173 2. Definition of Terms 175 This section describes definitions and terminologies related to 176 network slicing, especially gateway function and interconnection 177 network slices established in each domain. Other complementary 178 definitions are described in [I-D.homma-slice-provision-models]. 180 Network Slicing: Network slicing is a technology or an approach to 181 create separate logical networks in support of services, depending 182 on several requirements, on the same physical resources. This is 183 possible by combinations of several network technologies. 185 Network Slice (NS): An NS is a logical separate network that 186 provides specific network capabilities and characteristics. 188 Network Slice Instance (NSI): An NSI is a logical network instance 189 composed with required infrastructure resources, including 190 networking (WAN), computing (NFVI) resources, and some include 191 additional network service functions such as firewall or load- 192 balancer. It is composed of one or more Network Slice Subnet 193 Instances. 195 Network Slice Subnet: An NS subnet is is a representation of a set 196 of resources structuring a part of NSI within a single domain. 198 Network Slice Subnet Instance (NSSI): An NSSI is a partial logical 199 network instance represented as a network slicce instance. It is 200 a minimul unit managed or provided as a network slice. One or 201 more NSSI structure an NSI or an E2E-NSI. 203 End-to-End Network Slice Instance (E2E-NSI): An E2E-NS is an NSI 204 providing connectivity among end points. An E2E-NSI is used for 205 enphasizing end to end connectivity provided by an NSI. 207 Network Slice as a Service (NSaaS): An NSaaS is a service delivery 208 model in which a third-party provider (e.g., vertical customer) 209 hosts NSs and makes them available to customers. In this model, 210 there are mainly two roles: NS provider and NS tenant. 212 Network Slice Provider (NS Provider): An NS provider is a person or 213 group that designs and instantiates one or more NSIs/NSSIs, and 214 provides them to NS tenants. In some cases, an NS provider is an 215 infrastructure operator simultaneously. This includes NSI, NSSI, 216 and E2E-NSI providers. 218 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 219 that rents and occupies NSs from NS providers. 221 Domain: A domain is a group of a network and devices administrated 222 as a unit with common rules and procedures. 224 Administrative Domain: An administrative domain is a group of 225 networks and devices managed by an administrator. 227 Resource: A resource is element used to create virtual networks. 228 There are several types of resources, i.e., connectivity, 229 computing and storage. 231 Network Function Virtualization (NFV): NFV is the concept or 232 technologies to provide dedicated network appliances as software. 234 Software Defined Network (SDN): SDN is the concept or technologies 235 to separate network control plane from data plane, and control 236 network devices dynamically and flexibly. 238 Virtual Network: A virtual network is a network running a number of 239 virtual network functions. 241 Virtual Network Function (VNF): A virtual network function (VNF) is 242 a network function whose functional software is decoupled from 243 hardware. One or more virtual machines running different software 244 and processes on top of industry-standard high-volume servers, 245 switches and storage, or cloud computing infrastructure, and 246 capable of implementing network functions traditionally 247 implemented via custom hardware appliances and middleboxes (e.g., 248 router, NAT, firewall, load balancer, etc.) 250 Slice Gateway Function (SLG): An SLG is a function or a group of 251 functions to connect/disconnect NSSIs. The roles are described in 252 the following sections. 254 Business Support System and Operation Support System (BSS/OSS): BSS/ 255 OSS are systems to support service providing and operation of 256 network devices. 258 Orchestrator: Orchestrator is an entity to operate network 259 components automatically. There are several types of 260 orchestrators including NFV Orchestrator (NFVO) or service 261 orchestrator defined by ETSI NFV and Open Source MANO (OSM) 262 ([NFV-Architectural-Framework] and [OSM-White-Paper]). 264 SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls 265 SLGs. An SLG-Ctrl is controlled by upper-level operation systems 266 such as OSS/BSS or orchestrator. 268 3. Motivations and Roles of SLG 270 One of the main roles of SLG is the enablement of interworkings 271 between data plane with management and control elements for 272 controlling and orchestrating end-to-end slices. 274 Use cases of network slices are discussed in several Standard 275 Developing Organizations (SDOs). Some examples are described in use 276 cases document ([I-D.netslices-usecases]). 278 In some proposed use cases, an NS is structured across multiple 279 network domains. The capability of NSSIs might be different because 280 the components are domain-specific. In particular, the 281 differentiation in capability between different administrative 282 domains is large. 284 Moreover, several variations can be considered on NS provisioning in 285 NSaaS (ref. [I-D.homma-slice-provision-models]), and some cases need 286 abstraction of underlay infrastructure to NS tenants. SLG solution 287 provides controllability of network functionss for manipulation of 288 NSs intensively, and it can be expected to emphasize the 289 manageability of NSIs in such cases. 291 For connecting some different NSSIs and providing a NS that 292 guarantees the prescribed quality from end to end, SLGs are required 293 to connect such NSSIs. SLGs enable to provide E2E-NSIs independently 294 of specifications of underlay networks by hiding the differentiations 295 and connecting between NSSIs. An overview of this concept is shown 296 in Figure 1. SLGs glue NSSIs established on each domain and provide 297 an E2E-NSI. 299 E2E-NSI 300 ________________________A_________________________ 301 / \ 302 _____________ ____________ _________________ 303 / // / / / 304 end +---+ +---+ +---+ +---+ ,---. 305 host==>|SLG| NSSI#1 |SLG| NSSI#2 |SLG+-+SLG| NSSI#3 ( APL ) 306 +---+ +---+ +---+ +---+ `-----` 307 /____________//___________/ /________________/ 308 /____________//___________/ /________________/ 309 : : : 310 : : : 311 .--. .--. .--. 312 ( )-. ( )-. ( )-. 313 .' Access ' .' Core ' .' Data ' 314 ( Network ) ( Network ) ( Center ) 315 ( -' ( -' ( /Cloud -' 316 '-( ) '-( ) '-( ) 317 '---' '---' '---' 319 \______ ______/ \_____ _____/ \________ ________/ 320 V V V 321 Domain#1 Domain#2 Domain#3 323 \_____________ _____________/ \________ ________/ 324 V V 325 Domain of Administrator#A Domain of Administrator#B 327 * Legend 328 APL: Application 330 Figure 1: E2E-NSI composed of multiple NSSIs 332 Moreover, identification of user service traffic and their 333 allocation/disallocation to the appropriate NSSI are required at the 334 edges of E2E-NSIs, as shown in Figure 2, and SLGs might take on these 335 roles. 337 +-----+ _______________ 338 end | |-->/_______________ 339 host ====>| SLG | NSSI#1 340 |@Edge| _______________ 341 | |-->/______________ 342 | | NSSI#2 343 | | : : 344 +-----+ 346 Figure 2: NSSI selection of SLG 348 Note that, this model has the assumption that transitions of data 349 packets from one NSSI to another are executed at only SLGs. Also, an 350 SLG is not necessarily implemented as a single device or virtual 351 machine (VM). 353 4. Architecture of Network Slicing System 355 NSs are composed of several (virtual) network functions and links, 356 and the charactaristics of each NS are based on the assumed service. 357 Also, some of NSs are deployed accross multiple administrative 358 domains. For deploying the appropriate NSs based on each service 359 requirements, a management system, which enables to control network 360 resources totally within a domain, and interaction between such 361 management systems are required. 363 An SLG is a network function, and SLGs are installed at edge of 364 NSSIs. NSs are dynamically created, deleted, and moved depending on 365 requests from network opertor orNS tenants. Therefore, some SLGs 366 would be required to be VNF for flexible deployment. 368 This section describes overview of NS management system architecture 369 (Section 4.1) . 371 4.1. Network Slice Management System Architecture 373 The architecture overview of NS management system is shown in 374 Figure 3. 376 NS Tenant 377 | 378 . .|. . . . . . . . . . . . . . . . . . . . . 379 . +-v---------+ . 380 . |Portal/GUI +--+ . 381 . +-+---------+ | . . . . . . . . . . 382 . | +-v-----------------------+ . . +------------+ . 383 . | |CSS-Mngr./TNS-Orch. |<------->|CSS-M/TNS-O | . 384 . | +-+-------+---------------+ . . +-+--------+-+ . 385 . | | | . . | | . 386 . +-v-----+ | | . . +-v-----+ | . 387 . |BSS/OSS|<-----+ | . . |BSS/OSS| | . 388 . +-+-----+ | . . +-+-----+ | . 389 . | | . . | | . 390 . +-v--------------------v-----------+ . . +-v--------v-+ . 391 . | E2E-Orch./Network Service-Orch. | . . |E2E-O/NS-O | . 392 . +-+--------------------+-----------+ . . +-+--------+-+ . 393 . | | . . | | . 394 . +-v----------------+ +-v----------------+ . . : . 395 . | Resource Orch.#1 | | Resource Orch.#2 |.. . . . . . . . . . . 396 . +-+---------+------+ +-+---------+------+ . Administrative 397 . | | | | . Domain#2 398 . +-v------++-v------+ +-v------++-v------+ . 399 . |Network ||NFV | |Network ||NFV | . 400 . |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | . 401 . +-+------++-+------+ +-+------++-+------+ . 402 . | | | | . 403 . +-v------++-v------+ +-v------++-v------+ . 404 . |Network ||Server | |Network ||Server | . 405 . |Elements||Resource| |Elements||Resource|.. . 406 . |in ||in | |in ||in | . 407 . |Domain#1||Domain#1| |Domain#2||Domain#2| . 408 . +--------++--------+ +--------++--------+ . 409 . . . . . . . . . . . . . . . . . . . . . . . 410 Administrative Domain#1 412 CSS-Mngr./CSS-M:Cross-Segment Slice Manager 413 TNS-Orch./TNS-O:Transport Network Slice Orchestrator 415 Figure 3: Overview of NS Management Architecture 417 Orchestrators manage whole resources including network elements and 418 server resources (i.e., routing, bandwidth, compute or storage). In 419 this figure, the resources including network elements and server 420 resources are managed by resource orchestrators installed in each 421 domain, and the E2E-orchestrator and network service orchestrator 422 handle resource orchestrators. 424 NSs are requested from NS tenants via the portal system and the order 425 of creations of an NS is given to the E2E orchestrator from the 426 portal system via BSS/OSS. When an NS across multiple administrative 427 domains are requested, the portal system that received the request 428 forwards the order to create NSSIs to the other infrastructure 429 providers' systems via Cross-Segment Slice Manager. The details of 430 COMS architecture are described in the architecture document ([I- 431 D.qiang-coms-architecture]). 433 SLGs are also controlled via orchestrators. An SLG basically belongs 434 to a network element, and it might also belong to server resource if 435 it runs as a VNF. (The position of SLG deployed as a VNF is shown in 436 Appendix B.) 438 The information model used in this architecture is described in 439 information model document 440 ([I-D.qiang-coms-netslicing-information-model]). 442 5. Requirements for SLG 444 An SLG is basically a component in the data plane and has the roles 445 of data packet processing. Moreover, it is required to have 446 functions for control/management processes such as connecting to 447 underlay networks or managing NSs. 449 Furthermore, an SLG might be required to support handling services 450 provided on NSs in addition to controlling of NS because an SLG is an 451 edge node on an E2E-NSI. 453 In this section, we describe the requirements for an SLG in terms of 454 the following aspects and their interworkings. 456 1. Data plane for NSs as infrastructure 458 2. Control/management plane for NSs as infrastructure 460 3. Data plane for services on NSs 462 4. Control/management plane for services on NSs 464 5.1. Management of NS as Infrastructure 466 5.1.1. Data Plane Aspect 467 5.1.1.1. Identification/Classification 469 SLGs at the edge of E2E-NSs MUST have the capability to identify and 470 classify data packets, and assign them to the appropriate E2E-NS. 471 This requirement varies depending on the location. 473 Fixed Access: An SLG MUST identify and classify data packet with 474 access point, including CPE or WiFi-AP, or subscriber ID such as 475 VLAN-ID. Moreover, in some services, an SLG should identify and 476 classify data packets based on user device or application used in 477 the communication. 479 Mobile Access: An SLG MUST identify and classify data packet with 480 subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of 481 tunnels. Moreover, in some services, an SLG should identify and 482 classify data packets based on application used in the 483 communication or location of the user equipment (UE). 485 Connection Point between NSSI: An SLG MUST identify and classify 486 data packet based on the tunnel-ID or virtual routing and 487 forwarding (VRF) that received the packets. If specific slice 488 identifier such as a value mapped in the metadata field of the IP 489 header is used; an SLG should identify and classify data packets 490 with the ID. 492 5.1.1.2. Transporting/Forwarding 494 SLGs MUST provide functions for transport data packets depending on 495 the specifications of the underlay networks. 497 Encapsulation/Decapsulation/Tagging: In network slicing, duplication 498 of IP addresses of user packets between NSs MUST be accepted, 499 thus, using techniques that enable separation of a network 500 logically is preferred. In short, some tunnel protocols or 501 tagging approaches should be used as transport of NSs. For this 502 reason, SLG MUST support encapsulation or tagging of data packets 503 based on the specification of the underlay network. Also, SLG 504 MUST support the packets' decapsulation or untagging. Examples of 505 tunnel protocols and tags that can be used for creating NSs on L2/ 506 L3 segments are described below. 508 L2 Segment: VLAN, MPLS, Segment Routing MPLS (SR-MPLS), PPPoE, 509 etc. 511 L3 Segment: GRE, L2TP, GTP-U, VxLAN, IPv6 Segment Routing (SRv6), 512 etc. 514 VxLAN, SR-MPLS, and SRv6 are described in their specification 515 documents ([RFC7348], [I-D.ietf-spring-segment-routing-mpls], and 516 [I-D.ietf-6man-segment-routing-header]). 518 Translation of Encapsulation/Tagging Form: SLG MUST support to 519 translate tunnel header or tag of received packets to the 520 appropriate tunnel header or tag when it forwards data packets to 521 the next NSSI that has different transport capability. 523 Distribution of Traffic: Some NSs have multiple route between the 524 same end points within the same NSSI because of traffic 525 engineering, switching to a redundant path, or other reasons, and 526 SLG MAY forward data packets with the appropriate route based on 527 some trigger information. An example of the overview of this 528 requirement is shown in Figure 4. In this figure, there are two 529 routes, main and sub, between SLGs, and an SLG switches forwarding 530 route depending on the network situation such as congestion 531 occurrence on the current route. 533 ____________________________ 534 / . . . . . / 535 +-----+ . . +-----+ 536 | |. . . .| | 537 | SLG | | SLG | 538 | |* * * *| | 539 +-----+ * * +-----+ 540 / * * * * * / 541 /___________________________/ 542 NSSI 543 *** : Main-route 544 ... : Sub-route 546 Figure 4: An example of traffic distribution by SLG 548 5.1.1.3. Isolation among NSs 550 In NSaaS, isolation control is required for avoiding an NS being 551 affect by other NSs. Traffic engineering or QoS control is ones of 552 the most fundamental approaches to prevent disturbances among NSs. 554 Traffic Shaping/Policing: An SLG MUST execute traffic shaping and 555 policing at its egress and ingress ports to avoid an NS using 556 excessive traffic bandwidth. 558 Quality of service (QoS) Control: If there is an order of priority 559 between NSs on the same underlay infrastructure, an SLG should 560 remark the appropriate QoS parameter of the outer-most header of 561 each packet following the preconfigured setting and provide packet 562 scheduling based on the QoS parameter for providing priority 563 control. The field that SLG refers may vary depending on the 564 specification of the underlay network. For example, COS value is 565 remarked in L2 segments; on the other hand, DSCP value is remarked 566 in L3 segments. 568 5.1.1.4. Service Chaining as Infrastructural Mechanism(*Optional) 570 If an SLG is composed of a combination of several components, a 571 service chaining mechanism is required to make them work together and 572 achieve SLG functionality. 574 Moreover, some NSs may traverse NFVs such as firewalls or cache 575 servers for providing value-added services to their users. In such 576 cases, SLG might be required to support service chaining mechanisms, 577 such as handling of network service header (NSH) defined in 578 [RFC8300]. If an NS includes the service chaining architecture 579 defined in [RFC7665], some SLG would be required to support following 580 functions; classifier(CF), service function forwarder (SFF), and 581 inter boundary node(IBN). (Details of CF, SFF and IBN are described 582 in SFC documents; [RFC7665], [RFC8459].) 584 5.1.2. Control/Management Planes Aspects 586 5.1.2.1. Interfaces to Controllers or Operation Systems 588 SLG MUST have interface to its controller or operation systems for 589 set parameters related to the data plane functions described in 590 Section 5.1.1. In addition, an SLG at the edges of E2E-NSs MUST have 591 interfaces to authentication servers. 593 5.1.2.2. Address Resolution/Routing 595 An SLG MUST support address resolution or routing mechanisms to 596 connect to underlay network elements including routers or L2 597 switches. 599 5.1.2.3. Authentication Authorization Accounting (AAA) 601 For preventing entry of irregular traffic to NSs, an SLG at the edge 602 of E2E-NS MUST support AAA mechanism for incoming traffic. Also, 603 when an SLG connects to another SLG in other administrative domain, 604 SLGs should have a mechanism to confirm that the connection is 605 established with the regular processes. For example, an SLG is 606 required to support authentication of the opponent SLG with key 607 information indicated from higher-level operation systems. 609 5.1.2.4. Operation Administration and Maintenance(OAM) 611 In management of NSs, OAM mechanisms for both underlay and overlay 612 networks is required for SLGs. For an underlay network, an SLG MUST 613 have OAM functions to confirm connectivity to interconnect equipment. 614 For an overlay network as an NS, an SLG MUST have OAM functions to 615 confirm connectivity to the nodes on the same NS. 617 5.1.2.5. Traffic Monitoring 619 An SLG shall support monitoring of traffic amount and latency as a 620 mechanism for checking whether each of the accomodated NSs is 621 satisfying its SLA. When an NS can't fulfill its SLA, the SLG MUST 622 send a notification to any listening system. 624 5.2. Management of Services on NS (*Optional) 626 5.2.1. Data Plane Aspect 628 5.2.1.1. Identification/Classification 630 In NSaaS, some NS tenants may need delivery of an individual service 631 to each user, device, or application on the same NS. For such 632 service deliveries, an SLG might be required to identify and classify 633 user traffic based on some information such as subscriber ID or 634 payload of data packets. Also, an SLG should be controllable from 635 the NS tenant. 637 5.2.1.2. QoS Control 639 An NS accommodates several communication devices and SLGs might be 640 required to have fair queueing mechanisms for maintaining service 641 quality of each user. Also, different types of service traffic that 642 have different priorities might coexist on an NS. For example, some 643 NS providers might provide telephone and internet access services to 644 their users with an NS. In such cases, SLG might be required to 645 provide QoS control mechanisms for enforcing priority control based 646 on service priorities. 648 These QoS controls are executed depending on the information of inner 649 packets and are independent of isolation mechanisms as 650 infrastructure. An SLG might be required to have a hierarchical QoS 651 control mechanism in case that both QoS controls for services over 652 NSs and isolation between NSs are required. 654 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 656 SLG might be required to support steering or service chaining 657 function for conveying data packets to the appropriate network 658 functions deployed on an NS based on the classification result and 659 user's contract information. 661 5.2.2. Control/Management Planes Aspects 663 5.2.2.1. Interfaces to Service Management Systems 665 An SLG might have interfaces to controllers for managing user 666 policies on each NS. Some controllers might be deployed on the same 667 NS. If some controllers are located at external networks, they might 668 require SLGs to have APIs. 670 5.2.2.2. Collection of Telemetry information 672 In an NSaaS, collection of telemetry information of each NS might be 673 required for understanding traffic usage. Thus, an SLG might be 674 required to support to collect and report telemetry information of 675 connected NSs. 677 6. Structure of SLG 679 SLG is composed of data plan entities and controller. SLG Data plane 680 entity (SLG-D) has functions to manipulate NSSIs and to handle 681 traffic on slices. In some cases, an SLG-D is composed of several 682 physical devices and/or virtual instances. Function types supported 683 by SLG-D are listed Section 5. SLG controller (SLG-C) accomodates 684 multiple SLG Data plane entities via its southbound interface, and 685 sets configurations into each SLG-D. SLG-C also has a northbound 686 interface and it provides accesses to two endpoints: higher operation 687 systems such as orchestrator, and to external customers and tenants 688 which own their NSSIs. Then, functionality and controllability 689 exposed to customers/tenants ashould be limited, and the access must 690 be secure (i.e., authentication and admission control should be 691 supported). The overview of SLG structure is shown in Figure 5. 693 Customers/ Operation System 694 tenants (i.e.,Orchestrator) 696 | | 697 | | 698 +-------+---------+ 699 | 700 | 701 +---------+--------+ 702 | SLG Controller | 703 +---------+--------+ 704 | 705 +-----+-----+ 706 | | 707 | +------------------------------+ 708 | | 709 | | 710 +-----+----------------------------+ | 711 | SLG D-plane Entity_1 | | 712 |.-----. .-----. .----------. | +-------+-------+ 713 || FIB | | OAM | |Monitoring| .. | | | 714 |`-----' `-----' `----------' | ... | SLG D-plan | 715 |.-----. .-----. .-----. .-----. | | Entity_n | 716 ||decap| | QoS | | Fwd | |encap| ..| | | 717 |`-----' `-----' `-----' `-----' | +---------------+ 718 +----------------------------------+ 720 Figure 5: Overview of SLG Structure 722 7. Deployment of SLG 724 This section describes considerations related with deployment of 725 SLGs. 727 7.1. Examples of Components Required to Maintain SLG Functions 729 For providing E2E-NSs on existing network infrastructures, some 730 components located at boundaries of domains are required to have the 731 same set of functionality as an SLG. Examples of such components in 732 each domain type are described below. 734 Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc. 736 Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW 737 ([TS.36.300-3GPP]), etc. 739 Data Center: Gateway Router, L2 switch, ToR switch, Server, etc. 741 7.2. SLG Types Depending on Locations on NS 743 There are mainly three types of SLG for creating E2E-NS across 744 multiple administrative domains. The requirements of each SLG type 745 are listed in Appendix A. 747 7.2.1. Edge SLG(E-SLG) 749 E-SLG is located at an edge of an E2E-NS, and supports 750 identification, classification and authentication of user traffic in 751 addition to fundamental SLG functions, such as transport and 752 isolation. Also, it might be required to have capabilities for 753 services delivered on an NS. 755 7.2.2. Inter-Subnet SLG(IS-SLG) 757 IS-SLG is located between NSSIs within a single administrative domain 758 and has only fundamental functions such as QoS control or tranlation 759 of headers. 761 This type of SLG enables to separate an NSI into some NSSIs. It will 762 provide modularities of NSSIs, and simplify the management of NSIs. 763 However, it is not necessarily required if a common transport 764 mechanism in all domains is used. 766 7.2.3. Inter-Domain SLG(ID-SLG) 768 ID-SLG is located between NSSIs established on different domains. It 769 supports authentication for connecting to the opponent SLG in 770 addition to fundamental functions. 772 7.3. Horizontal Connection 774 The connection form of an SLG varies depending on which type it is. 775 Examples of horizontal connection forms of each SLG type are 776 described below. 778 E-SLG: An E-SLG accommodates several hosts and NSSIs. This has a 779 forwarding table of end hosts and insert their packets to the 780 appropriate NSSI. An overview of this connection is shown in 781 Figure 6. 783 *Virtual Layer* 785 +-----+ 786 host#1 ====>| | _______________ 787 | |-->/_______________ 788 host#2 ====>|E-SLG| NSSI#1 789 | | _______________ 790 host#3 ====>| |-->/_______________ 791 | | NSSI#2 792 : : | | : : 793 +-----+ 795 //////////////////////////////////////// 796 *Physical Layer* 798 ,-------------------- 799 [UE#1] -----\ / 800 [UE#2] -----[Edge] Domain#1 801 [UE#3] -----/ \ 802 : : `------------------- 804 Edge: Edge Node 806 Figure 6: Overview of horizontal connection of E-SLG 808 IS-SLG: An IS-SLG has the role of mediator between NSSIs and passes 809 packets received from an NSSI to the next one. If transport 810 methods used in each domain are different, the IS-SLG translate 811 packet form to the appropriate one. An overview of this 812 connection is shown in Figure 7. 814 *Virtual Layer* 816 +------+ 817 _________ | | ___________ 818 _________/-->|IS-SLG|--> /__________ 819 NSSI#1 | | NSSI#2 820 +------+ 822 /////////////////////////////////////// 823 *Physical Layer* 825 --------------. ,-------------- 826 \ / 827 Domain#1 [ GW ] Domain#2 828 / \ 829 --------------' `-------------- 831 GW: Gateway Node 833 Figure 7: Overview of horizontal connection of IS-SLG 835 ID-SLG: An ID-SLG passes data packets to another ID-SLG located on a 836 different administrative domain. Some tunnel established between 837 them in advance may be used for the passing of packets. An 838 overview of this connection is shown in Figure 8. 840 *Virtual Layer* 842 +------+ +------+ 843 _________ | | ______ | | ___________ 844 _________/-->|ID-SLG|O______)|ID-SLG|-->/__________ 845 NSSI#1 | | Tunnel | | NSSI#2 846 +------+ +------+ 848 /////////////////////////////////////////////////////// 849 *Physical Layer* 851 --------------------. ,------------------- 852 Administrative \ / Administrative 853 Domain#1 [ GW ]---[ GW ] Domain#2 854 / \ 855 --------------------' `------------------- 857 GW: Gateway Node 859 Figure 8: Overview of horizontal connection of ID-SLG 861 7.4. Vertical Connection 863 There are two patterns of vertical connection of SLGs in the middle 864 of E2E-NSs. The first pattern is that the SLGs accommodate only a 865 set of NSSIs, which are composition of the same E2E-NS. In this 866 pattern, such SLGs are not required to support NSSI selection, 867 however, establishment of a new SLG is required when a new E2E-NS is 868 created. This might causes extra overheads because of deploying many 869 SLGs. 871 The other pattern is that such SLGs are acceptable to accommodate 872 multiple NSSIs from each domain. In this pattern, SLGs support NSSI 873 selection. On the other hand, this pattern can restrain the number 874 of SLGs. Also, it is easy to provide transit of data packets from an 875 NSSI to another NSSI on the same domain. 877 The overviews of these patterns are shown in Figure 9 and Figure 10. 879 +-----+ 880 _________ | | ___________ 881 _________/-->|SLG#1|-->/__________ 882 NSSI#1 | | NSSI#2 883 +-----+ 884 +-----+ 885 _________ | | ___________ 886 _________/-->|SLG#2|-->/__________ 887 NSSI#3 | | NSSI#4 888 +-----+ 889 : : : 891 Figure 9: Overview of vertical connection of SLG: Separated Pattern 893 +-----+ 894 _________ | | ___________ 895 _________/-->| |-->/__________ 896 NSSI#1 |SLG#1| NSSI#2 897 _________ | | ___________ 898 _________/-->| |-->/__________ 899 NSSI#3 | | NSSI#4 900 | | 901 : | | : 902 +-----+ 904 Figure 10: Overview of vertical connection of SLG: Shared Pattern 906 7.5. Software vs. Hardware 908 An SLG can be created as either a software or hardware function. NSs 909 are virtual networks created depending on requests from external NS 910 tenants, and thus software would be more compatible with usage for 911 NSs in terms of flexibility or manageability. Moreover, it enables 912 to increase or decrease for each function if SLG is composed of 913 combination of several components. However, it is difficult to 914 provide high performance or sufficient throughput for carrier-grade 915 networks with software function. In addition, it would be difficult 916 to implement sufficient QoS control mechanisms with general servers, 917 because they requires special hardware structures. An example of 918 position of SLG in NFV environment is described in Appendix B. 920 On the other hand, hardware appliances are able to provide high 921 throughput compared with software. However, they are inflexible in 922 terms of provisioning. 924 From the above considerations, operators should prepare SLG in 925 appropriate ways depending on their usages or locations. 927 8. Interconnection between NSSIs 929 SLG provides interconnectivity between NSSIs. The concept and 930 fundamental framework including the related NS information model are 931 described in NSSIs interconnection document 932 ([I-D.defoy-coms-subnet-interconnection]). 934 This section is focused on interconnection between NSSIs established 935 on different administrative domains, and describes considerations 936 related to this condition. 938 8.1. Pre-arrangement of transport protocols 940 For interconnection between different administrative NSSIs, pre- 941 arrangement of the transport protocol, which is used to connect 942 between SLGs is required. Orchestration systems indicate the 943 protocol and configuration to each SLG. 945 8.2. Quality Assurance between SLGs 947 In addition to establishing connection, quality control of 948 communication is important. SLGs of egress side should execute 949 traffic shaping to prevent some NSs from excessively occupying the 950 link between SLGs. Moreover, some SLGs are connected to several 951 other SLGs that are deployed on the different locations. Therefore 952 SLGs of the ingress side should execute traffic policing to avoid 953 excessive inflow of traffic into some NSs. The parameters for these 954 controls are pre-configured by orchestration systems. 956 The above approaches are ones of the simplest ways to provide quality 957 assurance of inter-administrative subnets. If there is stricter 958 isolation request, more considerations would be required. 960 8.3. Secure Interconnection 962 For connecting networks of different administrators, secure 963 interconnection schemes are required. Especially, in an NSaaS, 964 networks might be connected to several networks, and schemes for 965 ensuring secure connectivity would be more important. 967 SLGs confirm whether the opponent SLG is regular when it requests to 968 connect, and reject the request if the SLG is not regular. In some 969 cases, SLGs might be confirm whether the inner packets received from 970 the other SLGs are sent from regular users. 972 9. Interfaces of SLG Controller 974 9.1. Southbound Interface 976 SLG-C supports protocols to communicate with SLG-Ds. Information and 977 prameters exchanged between SLG-D and SLG-C are TBD. 979 9.2. Northbound Interface for Higher Operation Systems 981 TBD 983 9.3. Northbound Interface for Customers/Tenants 985 TBD 987 10. Security Considerations 989 Requirements and considerations for SLG related to security are 990 described in Section 5 and Section 8. 992 11. IANA Considerations 994 This memo includes no request to IANA. 996 12. Acknowledgement 998 The authors would like to thank Li Qiang for her kind review and 999 valuable feedback. 1001 13. Informative References 1003 [I-D.defoy-coms-subnet-interconnection] 1004 Foy, X., Rahman, A., Galis, A., 1005 kiran.makhijani@huawei.com, k., and L. Qiang, 1006 "Interconnecting (or Stitching) Network Slice Subnets", 1007 draft-defoy-coms-subnet-interconnection-01 (work in 1008 progress), October 2017. 1010 [I-D.homma-slice-provision-models] 1011 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 1012 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 1013 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 1014 Foy, "Network Slice Provision Models", draft-homma-slice- 1015 provision-models-00 (work in progress), February 2019. 1017 [I-D.ietf-6man-segment-routing-header] 1018 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 1019 Field, B., daniel.voyer@bell.ca, d., 1020 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 1021 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 1022 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 1023 Header (SRH)", draft-ietf-6man-segment-routing-header-08 1024 (work in progress), January 2018. 1026 [I-D.ietf-spring-segment-routing-mpls] 1027 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1028 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1029 data plane", draft-ietf-spring-segment-routing-mpls-11 1030 (work in progress), October 2017. 1032 [I-D.netslices-usecases] 1033 kiran.makhijani@huawei.com, k., Qin, J., Ravindran, R., 1034 Geng, L., Qiang, L., Peng, S., Foy, X., Rahman, A., Galis, 1035 A., and G. Fioccola, "Network Slicing Use Cases: Network 1036 Customization and Differentiated Services", draft- 1037 netslices-usecases-02 (work in progress), October 2017. 1039 [I-D.qiang-coms-netslicing-information-model] 1040 Qiang, L., Galis, A., 67, 4., kiran.makhijani@huawei.com, 1041 k., Martinez-Julia, P., Flinck, H., and X. Foy, 1042 "Technology Independent Information Model for Network 1043 Slicing", draft-qiang-coms-netslicing-information-model-01 1044 (work in progress), October 2017. 1046 [I-D.rokui-5g-transport-slice] 1047 Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., 1048 Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., 1049 Eardley, P., Makhijani, K., and H. Flinck, "5G Transport 1050 Slice Connectivity Interface", draft-rokui-5g-transport- 1051 slice-00 (work in progress), July 2019. 1053 [NECOS] NECOS, "Novel Enablers for Cloud Slicing", 1054 . 1056 [NFV-Architectural-Framework] 1057 Network Functions Virtualisation (NFV) ETSI Industry 1058 Specification Group (ISG), "Network Functions 1059 Virtualisation (NFV); Architectural Framework", December 1060 2014, . 1063 [OSM-White-Paper] 1064 ETSI, "OSM White Paper", October 2016, 1065 . 1068 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1069 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1070 eXtensible Local Area Network (VXLAN): A Framework for 1071 Overlaying Virtualized Layer 2 Networks over Layer 3 1072 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1073 . 1075 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1076 Chaining (SFC) Architecture", RFC 7665, 1077 DOI 10.17487/RFC7665, October 2015, 1078 . 1080 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1081 "Network Service Header (NSH)", RFC 8300, 1082 DOI 10.17487/RFC8300, January 2018, 1083 . 1085 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1086 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1087 DOI 10.17487/RFC8459, September 2018, 1088 . 1090 [Slicing_Tutrial] 1091 IEEE NetSoft2018, "Network Slicing Landscape Tutorial", 1092 June 2018, 1093 . 1096 [TS.23.501-3GPP] 1097 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1098 (V16.0.0): System Architecture for 5G System; Stage 2", 1099 September 2018, . 1102 [TS.36.300-3GPP] 1103 3rd Generation Partnership Project (3GPP), "Evolved 1104 Universal Terrestrial Radio Access (E-UTRA) and Evolved 1105 Universal Terrestrial Radio Access Network (E-UTRAN); 1106 Overall description; Stage 2", December 2007, 1107 . 1109 Appendix A. Requirements for each SLG Type 1111 The requirements for each SLG type are listed in Figure 11. 1113 +---------------++-------+-------+-------+----------------+ 1114 | || E-SLG |IS-SLG |ID-SLG | Reference | 1115 +=========================================================+ 1116 |*Data-Plane of NS as Infrastructure | 1117 +=========================================================+ 1118 |Identification/|| M | O | O |Section 5.1.1.1.| 1119 |Classification || | | | | 1120 +---------------++-------+-------+-------+----------------+ 1121 |Transport/ || M | O | M |Section 5.1.1.2.| 1122 |Forwarding || | | | | 1123 +---------------++-------+-------+-------+----------------+ 1124 |Isolation || M | M | M |Section 5.1.1.3.| 1125 +---------------++-------+-------+-------+----------------+ 1126 |Service Chain || O | O | O |Section 5.1.1.4.| 1127 +=========================================================+ 1128 |*Control/Management-Plane of NS as Infrastructure | 1129 +=========================================================+ 1130 |IF to Ctrl/OpS || M | M | M |Section 5.1.2.1.| 1131 +---------------++-------+-------+-------+----------------+ 1132 |Addr Resolution|| M | M | M |Section 5.1.2.2.| 1133 |/Routing || | | | | 1134 +---------------++-------+-------+-------+----------------+ 1135 |AAA || M | - | M |Section 5.1.2.3.| 1136 +---------------++-------+-------+-------+----------------+ 1137 |OAM || M | M | M |Section 5.1.2.4.| 1138 +---------------++-------+-------+-------+----------------+ 1139 |Monitoring || M | M | M |Section 5.1.2.5.| 1140 +=========================================================+ 1141 |*Data-Plane for Service on NS | 1142 +=========================================================+ 1143 |Identification/|| O | - | O |Section 5.2.1.1.| 1144 |Classification || | | | | 1145 +---------------++-------+-------+-------+----------------+ 1146 |QoS Control || O | O | O |Section 5.2.1.2.| 1147 +---------------++-------+-------+-------+----------------+ 1148 |Steering/ || O | - | O |Section 5.2.1.3.| 1149 |Service Chain || | | | | 1150 +=========================================================+ 1151 |*Control/Management-Plane for Service on NS | 1152 +=========================================================+ 1153 |IF to Service || O | O | O |Section 5.2.2.1.| 1154 |Manager || | | | | 1155 +---------------++-------+-------+-------+----------------+ 1156 |Telemetory || O | O | O |Section 5.2.2.2.| 1157 +---------------++-------+-------+-------+----------------+ 1158 M: Mandatry, O: Optional, - : Not Required 1160 Figure 11: List of Requirements for each SLG 1162 Appendix B. Position of SLG on ETSI NFV MANO 1164 Some SLGs and the controllers are deployed and run on NSs as VNFs. 1165 An arechitecture for managing lifecycle of VNFs is under 1166 standardization in ETS NFV MANO. 1168 The mapping of SLG as a VM into ETSI NFV MANO architecture is 1169 described in Figure 12. In some cases, SLGs are deployed with 1170 containor. VNFs are parts of NS compositions and NFV orchestrator 1171 would be controlled by upper control entities such as resource 1172 orchestrator. 1174 OSS/BSS, Service-Orch, Resource-Orch 1175 | | 1176 | | 1177 +-v-------+ +-v----------+ 1178 |SLG-Ctrl |<-----+ NFV Orch. | 1179 +-+-------+ +-+----------+ 1180 | | 1181 ,-v-------. | 1182 | SLG | | 1183 :=========: +-v----------+ 1184 |VM(GstOS)|<-----+VNF Manager | 1185 `---------' +-+----------+ 1186 +---------+ | 1187 | HostOS/ | +-v----------+ 1188 | Server |<-----| VIM | 1189 +---------+ +------------+ 1191 Figure 12: Position of SLG as a VM on ETSI NFV MANO 1193 Appendix C. Complemention of Network Slicing in 3GPP 1195 The 3GPP 5GS is natively support network slicing (ref. 1196 [TS.23.501-3GPP], and UPF provides some functions for manuplation of 1197 NSs, such as NS selection, QoS control, traffic steering, etc. 3GPP 1198 is responsible for standatdizing user plane manipulation for mobility 1199 management, and interworking with transport on underlay network and 1200 external networks of 5GS such as DNs is out of scope in 3GPP. 1202 SLG will provide complemental definitions of functions and interfaces 1203 for providing E2E-NSI including 5GS. A way of interworking between 1204 transport NS and RAN/UPF is described in 1205 [I-D.rokui-5g-transport-slice]. 1207 Further study is TBD. 1209 Authors' Addresses 1211 Shunsuke Homma 1212 NTT 1213 Japan 1215 Email: shunsuke.homma.fp@hco.ntt.co.jp 1216 Xavier de Foy 1217 InterDigital Inc. 1218 Canada 1220 Email: Xavier.Defoy@InterDigital.com 1222 Alex Galis 1223 University College London 1224 United Kingdom 1226 Email: a.galis@ucl.ac.uk 1228 Luis M. Contreras 1229 Telefonica 1230 Ronda de la Comunicacion, s/n 1231 Sur-3 building, 3rd floor 1232 Madrid 28050 1233 Spain 1235 Email: luismiguel.contrerasmurillo@telefonica.com 1236 URI: http://lmcontreras.com/