idnits 2.17.1 draft-homma-rtgwg-slice-gateway-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 : ---------------------------------------------------------------------------- ** 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 481: '... edge of E2E-NSs MUST have the capabil...' RFC 2119 keyword, line 485: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 491: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 497: '...en NSSI: An SLG MUST identify and cla...' RFC 2119 keyword, line 506: '... 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 92 has weird spacing: '...ructure of SL...' -- The document date (March 8, 2020) is 1503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.rokui-teas-transport-slice-definition' is mentioned on line 195, but not defined == Missing Reference: 'I-D.ejj-teas-ns-framework' is mentioned on line 391, but not defined == Outdated reference: A later version (-04) exists of draft-defoy-coms-subnet-interconnection-01 == Outdated reference: A later version (-04) exists of draft-henry-tsvwg-diffserv-to-qci-03 == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-00 == 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 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg S. Homma 3 Internet-Draft T. Nakamura 4 Intended status: Informational NTT 5 Expires: September 9, 2020 X. de Foy 6 InterDigital Inc. 7 A. Galis 8 University College London 9 LM. Contreras 10 Telefonica 11 R. Rokui 12 Nokia 13 P. Martinez-Julia 14 NICT 15 March 8, 2020 17 Gateway Function for Network Slicing 18 draft-homma-rtgwg-slice-gateway-02 20 Abstract 22 This document describes the roles and requirements for a slice 23 gateway that is a function or function group for handling data plane 24 traffic, such as connecting/disconnecting and compose/decompose 25 network slice subnet instances and providing network slices from end 26 to end. The interworking between management and control elements at 27 the management and control planes with the gateway function for 28 controlling and orchestrating end-to-end network slices are also 29 presented in this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 9, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 67 3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 7 68 4. Architecture of Network Slicing System . . . . . . . . . . . 9 69 4.1. Network Slice Management System Architecture . . . . . . 9 70 5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 11 71 5.1. Management of NS as Infrastructure . . . . . . . . . . . 11 72 5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 11 73 5.1.1.1. Identification/Classification . . . . . . . . . . 11 74 5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 12 75 5.1.1.3. Isolation among NSs . . . . . . . . . . . . . . . 13 76 5.1.1.4. Service Chaining as Infrastructural 77 Mechanism(*Optional) . . . . . . . . . . . . . . 14 78 5.1.2. Control/Management Planes Aspects . . . . . . . . . . 14 79 5.1.2.1. Interfaces to Controllers or Operation Systems . 14 80 5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 14 81 5.1.2.3. Authentication Authorization Accounting (AAA) . . 14 82 5.1.2.4. Operation Administration and Maintenance(OAM) . . 14 83 5.1.2.5. Traffic Monitoring . . . . . . . . . . . . . . . 15 84 5.2. Management of Services on NS (*Optional) . . . . . . . . 15 85 5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 15 86 5.2.1.1. Identification/Classification . . . . . . . . . . 15 87 5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 15 88 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 15 89 5.2.2. Control/Management Planes Aspects . . . . . . . . . . 16 90 5.2.2.1. Interfaces to Service Management Systems . . . . 16 91 5.2.2.2. Collection of Telemetry information . . . . . . . 16 92 6. Structure of SLG . . . . . . . . . . . . . . . . . . . . . . 16 93 7. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 17 94 7.1. Examples of Components Required to Maintain SLG Functions 17 95 7.2. SLG Types Depending on Locations on NS . . . . . . . . . 18 96 7.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 18 97 7.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 18 98 7.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 18 99 7.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 18 100 7.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 21 101 8. Interconnection between NSSIs . . . . . . . . . . . . . . . . 22 102 8.1. Pre-arrangement of transport protocols . . . . . . . . . 22 103 8.2. Quality Assurance between SLGs . . . . . . . . . . . . . 22 104 8.3. Secure Interconnection . . . . . . . . . . . . . . . . . 22 105 9. Interfaces of SLG Controller . . . . . . . . . . . . . . . . 23 106 9.1. Southbound Interface . . . . . . . . . . . . . . . . . . 23 107 9.2. Northbound Interface for Higher Operation Systems . . . . 23 108 9.3. Northbound Interface for Customers/Tenants . . . . . . . 23 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 111 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 112 13. Informative References . . . . . . . . . . . . . . . . . . . 23 113 Appendix A. Requirements for each SLG Type . . . . . . . . . . . 26 114 Appendix B. Example of Data Model for Service Management . . . . 27 115 Appendix C. Complementation of Network Slicing in 3GPP . . . . . 29 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 118 1. Introduction 120 Network slicing is an approach to create separate virtual networks in 121 support of service depending on several requirements on the same 122 physical resources, and it enables networks to adapt to requirements, 123 which is diverse more, inexpensively and flexibly. The overview is 124 introduced in [Slicing_Tutrial] and [NECOS]. 126 It's also expected to enhance usability of infrastructural networks 127 for tenants and create new business opportunities. For example, by 128 using network slices lent from infrastructure operators, other 129 industrial companies can provide communication services including 130 ensurance of network transport without having physical 131 infrastructure. 133 From a business point of view, a slice includes a combination of all 134 the relevant network resources, functions, and assets required to 135 fulfill a specific business case or service, including OSS, BSS and 136 DevOps processes. 138 From the network infrastructure point of view, network slice requires 139 the partitioning and assignment of a set of resources that can be 140 used in an isolated, disjunctive or non- disjunctive manner for that 141 slice. 143 From the tenant point of view, network slice provides different 144 capabilities, specifically in terms of their management and control 145 capabilities, and how much of them the network service provider hands 146 over to the slice tenant. As such there are two kinds of slices: (A) 147 Inner slices, understood as the partitions used for internal services 148 of the provider, retaining full control and management of them. (B) 149 Outer slices, being those partitions hosting customer services, 150 appearing to the customer as dedicated networks. 152 Network slices are established with combination of various 153 technologies, such as software defined network (SDN), network 154 function virtualization (NFV), or traffic engineering, and managed/ 155 operated with automation technologies such as orchestrator. 157 Assumed use cases of network slices include establishment of virtual 158 networks whose qualities are guaranteed from end to end under the 159 supervision of multi-domain orchestrators. In such cases, a network 160 slice subnet is created on each domain, such as access network and 161 core network, and an end-to-end network slices is composed of 162 connected subnets. 164 Network slice subnets are built based on specifications of the 165 underlay network, and thus the used technologies might vary. 166 Therefore, a gateway function, which enables to connect subnets while 167 adapting the differentiations and forward data packets to/from the 168 appropriate next subnet, is required. 170 This document describes the gateway function for network slicing, 171 called slice gateway or SLG, and its role and requirements. Note 172 that defining a new data plane technology is not a goal of this 173 draft. In addition, this draft aims to specify management-related 174 requirements for an SLG, which may be implemented using existing data 175 plane technologies. 177 2. Definition of Terms 179 This section describes definitions and terminologies related to 180 network slicing, especially gateway function and interconnection 181 network slices established in each domain. Other complementary 182 definitions are described in [I-D.homma-slice-provision-models]. 184 Network Slicing: Network slicing is a methodology to create separate 185 logical networks in support of services, depending on several 186 requirements, on the same physical resources. This is possible by 187 combinations of several network technologies. 189 Network Slice (NS): An NS is a logical separate network that 190 provides specific network capabilities and characteristics. It is 191 composed of set of resources including virtual/physical forwarding 192 functions, links, and network functions. There are several types 193 of NS depending on network types where the NS is deployed. 194 Transport slice is one of them and the detailed definition is 195 provided in [I-D.rokui-teas-transport-slice-definition]. (Note 196 that 3GPP and other SDOs use definitions "Network Slice Instance/ 197 NSI" and "Network Slice Subnet Instance/NSSI", but they are 198 expressed as NS in this document.) 200 Network Slice Instance (NSI): An NSI is a logical network instance 201 composed with required infrastructure resources, including 202 networking (WAN), computing (NFVI) resources, and some include 203 additional network service functions such as firewall or load- 204 balancer. It is composed of one or more Network Slice Subnet 205 Instances. Note that, the word "instance" is not used in the 206 definition of transport slice discussed in the NS-DT (Network 207 Slice Design Team). 209 Network Slice Subnet: An NS subnet is a representation of a set of 210 resources structuring a part of NSI within a single domain. 211 Network slice subnet concept is proposed in [TS.28.530-3GPP]. 212 Note that, in the definition of transport slice discussed in the 213 NS-DT, Network Slice and Network Slice Subnet are not 214 distinguished, and all types of network slices in transport 215 network are called transport slice. 217 Network Slice Subnet Instance (NSSI): An NSSI is a partial logical 218 network instance represented as a network slice instance. It is a 219 minimal unit managed or provided as a network slice. One or more 220 NSSI structure an NSI or an E2E-NSI. 222 End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is an NS 223 providing connectivity among end points. An E2E-NS is used for 224 emphasizing end to end connectivity provided by an NS. 226 Network Slice as a Service (NSaaS): An NSaaS is a service delivery 227 model in which a third-party provider (e.g., vertical customer) 228 hosts NSs and makes them available to customers. In this model, 229 there are mainly two roles: NS provider and NS tenant. 231 Network Slice Provider (NS Provider): An NS provider is a person or 232 group that designs and instantiates one or more NSIs/NSSIs, and 233 provides them to NS tenants. In some cases, an NS provider is an 234 infrastructure operator simultaneously. This includes NSI, NSSI, 235 and E2E-NSI providers. 237 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 238 that rents and occupies NSs from NS providers. 240 Domain: A domain is a group of a network and devices administrated 241 as a unit with common rules and procedures. 243 Administrative Domain: An administrative domain is a group of 244 networks and devices managed by an administrator. 246 Resource: A resource is element used to create virtual networks. 247 There are several types of resources, i.e., connectivity, 248 computing and storage. 250 Network Function Virtualization (NFV): NFV is the concept or 251 technologies to provide dedicated network appliances as software. 253 Software Defined Network (SDN): SDN is the concept or technologies 254 to separate network control plane from data plane, and control 255 network devices dynamically and flexibly. 257 Virtual Network: A virtual network is a network running a number of 258 virtual network functions. The detailed definition is provided in 259 [RFC8453]. 261 Virtual Network Function (VNF): A virtual network function (VNF) is 262 a network function whose functional software is decoupled from 263 hardware. One or more virtual machines running different software 264 and processes on top of industry-standard high-volume servers, 265 switches and storage, or cloud computing infrastructure, and 266 capable of implementing network functions traditionally 267 implemented via custom hardware appliances and middleboxes (e.g., 268 router, NAT, firewall, load balancer, etc.) 270 Slice Gateway Function (SLG): An SLG is a function or a group of 271 functions to connect/disconnect NSSIs. The roles are described in 272 the following sections. 274 Business Support System and Operation Support System (BSS/OSS): BSS/ 275 OSS are systems to support service providing and operation of 276 network devices. 278 Orchestrator: Orchestrator is an entity to operate network 279 components automatically. There are several types of 280 orchestrators including NFV Orchestrator (NFVO) or service 281 orchestrator defined by ETSI NFV and Open Source MANO (OSM) 282 ([NFV-Architectural-Framework] and [OSM-White-Paper]). 284 SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls 285 SLGs. An SLG-Ctrl is controlled by upper-level operation systems 286 such as OSS/BSS or orchestrator. 288 3. Motivations and Roles of SLG 290 One of the main roles of SLG is the enablement of interworkings 291 between data plane with management and control elements for 292 controlling and orchestrating end-to-end slices. 294 Use cases of network slices are discussed in several Standard 295 Developing Organizations (SDOs). Some examples are described in use 296 cases document ([I-D.netslices-usecases]). 298 In some proposed use cases, an NS is structured across multiple 299 network domains. The capability of NSSIs might be different because 300 the components are domain-specific. In particular, the 301 differentiation in capability between different administrative 302 domains is large. 304 Moreover, several variations can be considered on NS provisioning in 305 NSaaS (ref. [I-D.homma-slice-provision-models]), and some cases need 306 abstraction of underlay infrastructure to NS tenants. SLG solution 307 provides controllability of network functions for manipulation of NSs 308 intensively, and it can be expected to emphasize the manageability of 309 NSIs in such cases. 311 For connecting some different NSSIs and providing a NS that 312 guarantees the prescribed quality from end to end, SLGs are required 313 to connect such NSSIs. SLGs enable to provide E2E-NSIs independently 314 of specifications of underlay networks by hiding the differentiations 315 and connecting between NSSIs. An overview of this concept is shown 316 in Figure 1. SLGs glue NSSIs established on each domain and provide 317 an E2E-NSI. 319 E2E-NSI 320 ________________________A_________________________ 321 / \ 322 _____________ ____________ _________________ 323 / // / / / 324 end +---+ +---+ +---+ +---+ ,---. 325 host==>|SLG| NSSI#1 |SLG| NSSI#2 |SLG+-+SLG| NSSI#3 ( APL ) 326 +---+ +---+ +---+ +---+ `-----` 327 /____________//___________/ /________________/ 328 /____________//___________/ /________________/ 329 : : : 330 : : : 331 .--. .--. .--. 332 ( )-. ( )-. ( )-. 333 .' Access ' .' Core ' .' Data ' 334 ( Network ) ( Network ) ( Center ) 335 ( -' ( -' ( /Cloud -' 336 '-( ) '-( ) '-( ) 337 '---' '---' '---' 339 \______ ______/ \_____ _____/ \________ ________/ 340 V V V 341 Domain#1 Domain#2 Domain#3 343 \_____________ _____________/ \________ ________/ 344 V V 345 Domain of Administrator#A Domain of Administrator#B 347 * Legend 348 APL: Application 350 Figure 1: E2E-NSI composed of multiple NSSIs 352 Moreover, identification of user service traffic and their 353 allocation/disallocation to the appropriate NSSI are required at the 354 edges of E2E-NSIs, as shown in Figure 2, and SLGs might take on these 355 roles. 357 +-----+ _______________ 358 end | |-->/_______________ 359 host ====>| SLG | NSSI#1 360 |@Edge| _______________ 361 | |-->/______________ 362 | | NSSI#2 363 | | : : 364 +-----+ 366 Figure 2: NSSI selection of SLG 368 Note that, this model has the assumption that transitions of data 369 packets from one NSSI to another are executed at only SLGs. Also, an 370 SLG is not necessarily implemented as a single device or virtual 371 machine (VM). 373 4. Architecture of Network Slicing System 375 NSs are composed of several (virtual) network functions and links, 376 and the characteristics of each NS are based on the assumed service. 377 Also, some of NSs are deployed across multiple administrative 378 domains. For deploying the appropriate NSs based on each service 379 requirements, a management system, which enables to control network 380 resources totally within a domain, and interaction between such 381 management systems are required. 383 An SLG is a network function, and SLGs are installed at edge of 384 NSSIs. NSs are dynamically created, deleted, and moved depending on 385 requests from network operator or NS tenants. Therefore, some SLGs 386 would be required to be VNF for flexible deployment. 388 This section describes overview of NS management system architecture 389 (Section 4.1) . It refers [NFV-Architectural-Framework] and 390 [OSM-White-Paper] for management of whole of NS and VNFs, and 391 [RFC8453] and [I-D.ejj-teas-ns-framework] for transport network/slice 392 manipulation. 394 4.1. Network Slice Management System Architecture 396 The architecture overview of NS management system is shown in 397 Figure 3. 399 NS Tenant 400 | 401 | +------------+ 402 . .|. . . . . . . . . . . . . . . . . .| . . . . .|. . . . . . . 403 . +-v-----+ | . . +-v-----+ . 404 . |BSS/OSS| | . . |BSS/OSS| . 405 . +-+-----+ | . . +-+-----+ . 406 . | | . . | . 407 . +-v--------------------------------+ | . . +-v----------+ . 408 . | Network Service-Orchestrator +--+ . . |E2E-O/NS-O +- . 409 . +-+--------------------+-----------+ . . +-+--------+-+ . 410 . | | . . | | . 411 . +-v----------------+ +-v----------------+ . . : . 412 . | Resource Orch.#1 | | Resource Orch.#2 |.. . . . . . . . . . . 413 . +-+---------+------+ +-+---------+------+ . Administrative 414 . | | | | . Domain#2 415 . +-v------++-v------+ +-v------++-v------+ . 416 . |Network ||NFV | |Network ||NFV | . 417 . |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | . 418 . +-+------++-+------+ +-+------++-+------+ . 419 . | | | | . 420 . +-v------++-v------+ +-v------++-v------+ . 421 . |Network ||Compute | |Network ||Compute | . 422 . |Elements||Resource| |Elements||Resource|.. . 423 . |in ||in | |in ||in | . 424 . |Domain#1||Domain#1| |Domain#2||Domain#2| . 425 . +--------++--------+ +--------++--------+ . 426 . . . . . . . . . . . . . . . . . . . . . . . 427 Administrative Domain#1 429 Figure 3: Overview of NS Management Architecture 431 Orchestrators manage whole resources including network elements and 432 compute resources (i.e., routing, bandwidth, network functions). In 433 this figure, the resources are managed by resource orchestrators 434 installed in each domain, and the network service orchestrator 435 operates resource orchestrators. A resource orchestrator includes 436 modules for handling each resource type, such as NFVO (ref. 437 [OSM-White-Paper]) and Transport Slice Controller/TSC (ref. [I- 438 D.ejj-teas-ns-framework]). These orchestrators have recursive 439 structure, and a network service orchestrator sometimes control other 440 network service orchestrators in other administrative domains. 442 NSs are requested from NS tenants via BSS/OSS and the order to create 443 an NS is given to orchestrators. Orchestrators manipulate network 444 elements and compute resouces via controllers. When an NS across 445 multiple administrative domains are requested, the network service 446 orchestrator request orchestrators in other administrative domains to 447 create NSSIs. 449 SLGs are also controlled via orchestrators. An SLG can be 450 implemented in a network element, or may be hosted on a compute 451 resource if it runs as a VNF. 453 5. Requirements for SLG 455 An SLG is basically a component in the data plane and has the roles 456 of data packet processing. Moreover, it is required to have 457 functions for control/management processes such as connecting to 458 underlay networks or managing NSs. 460 Furthermore, an SLG might be required to support handling services 461 provided on NSs in addition to controlling of NS because an SLG is an 462 edge node on an E2E-NSI. 464 In this section, we describe the requirements for an SLG in terms of 465 the following aspects and their interworkings. 467 1. Data plane for NSs as infrastructure 469 2. Control/management plane for NSs as infrastructure 471 3. Data plane for services on NSs 473 4. Control/management plane for services on NSs 475 5.1. Management of NS as Infrastructure 477 5.1.1. Data Plane Aspect 479 5.1.1.1. Identification/Classification 481 SLGs at the edge of E2E-NSs MUST have the capability to identify and 482 classify data packets, and assign them to the appropriate E2E-NS. 483 This requirement varies depending on the location. 485 Fixed Access: An SLG MUST identify and classify data packet with 486 access point, including CPE or WiFi-AP, or subscriber ID such as 487 VLAN-ID. Moreover, in some services, an SLG should identify and 488 classify data packets based on user device or application used in 489 the communication. 491 Mobile Access: An SLG MUST identify and classify data packet with 492 subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of 493 tunnels. Moreover, in some services, an SLG should identify and 494 classify data packets based on application used in the 495 communication or location of the user equipment (UE). 497 Connection Point between NSSI: An SLG MUST identify and classify 498 data packet based on the tunnel-ID or virtual routing and 499 forwarding (VRF) that received the packets. If specific slice 500 identifier such as a value mapped in the metadata field of the IP 501 header is used; an SLG should identify and classify data packets 502 with the ID. 504 5.1.1.2. Transporting/Forwarding 506 SLGs MUST provide functions for transport data packets depending on 507 the specifications of the underlay networks. 509 Encapsulation/Decapsulation/Tagging: In network slicing, duplication 510 of IP addresses of user packets between NSs MUST be accepted, 511 thus, using techniques that enable separation of a network 512 logically is preferred. In short, some tunnel protocols or 513 tagging approaches should be used as transport of NSs. For this 514 reason, SLG MUST support encapsulation or tagging of data packets 515 based on the specification of the underlay network. Also, SLG 516 MUST support the packets' decapsulation or untagging. Examples of 517 tunnel protocols and tags that can be used for creating NSs on L2/ 518 L3 segments are described below. 520 L2 Segment: VLAN, MPLS, Segment Routing MPLS (SR-MPLS), PPPoE, 521 etc. 523 L3 Segment: GRE, L2TP, GTP-U, VxLAN, IPv6 Segment Routing (SRv6), 524 etc. 526 VxLAN, SR-MPLS, and SRv6 are described in their specification 527 documents ([RFC7348], [I-D.ietf-spring-segment-routing-mpls], and 528 [I-D.ietf-6man-segment-routing-header]). 530 Translation of Encapsulation/Tagging Form: SLG MUST support to 531 translate tunnel header or tag of received packets to the 532 appropriate tunnel header or tag when it forwards data packets to 533 the next NSSI that has different transport capability. 535 Distribution of Traffic: Some NSs have multiple route between the 536 same end points within the same NSSI because of traffic 537 engineering, switching to a redundant path, or other reasons, and 538 SLG MAY forward data packets with the appropriate route based on 539 some trigger information. An example of the overview of this 540 requirement is shown in Figure 4. In this figure, there are two 541 routes, main and sub, between SLGs, and an SLG switches forwarding 542 route depending on the network situation such as congestion 543 occurrence on the current route. 545 ____________________________ 546 / . . . . . / 547 +-----+ . . +-----+ 548 | |. . . .| | 549 | SLG | | SLG | 550 | |* * * *| | 551 +-----+ * * +-----+ 552 / * * * * * / 553 /___________________________/ 554 NSSI 555 *** : Main-route 556 ... : Sub-route 558 Figure 4: An example of traffic distribution by SLG 560 5.1.1.3. Isolation among NSs 562 In NSaaS, isolation control is required for avoiding an NS being 563 affect by other NSs. Traffic engineering or QoS control is ones of 564 the most fundamental approaches to prevent disturbances among NSs. 566 Traffic Shaping/Policing: An SLG MUST execute traffic shaping and 567 policing at its egress and ingress ports to avoid an NS using 568 excessive traffic bandwidth. 570 Quality of service (QoS) Control: If there is an order of priority 571 between NSs on the same underlay infrastructure, an SLG should 572 remark the appropriate QoS parameter of the outer-most header of 573 each packet following the preconfigured setting and provide packet 574 scheduling based on the QoS parameter for providing priority 575 control. The field that SLG refers may vary depending on the 576 specification of the underlay network. For example, COS value is 577 remarked in L2 segments; on the other hand, DSCP value is remarked 578 in L3 segments. In mobility networks standardized by 3GPP, QoS 579 class is managed by using QoS Class Identifier (QCI) or 5G QoS 580 Identifier (5QI) conveyed in extention header of user plane 581 protocol, and they mapped to DSCP 582 ([I-D.henry-tsvwg-diffserv-to-qci]). 584 5.1.1.4. Service Chaining as Infrastructural Mechanism(*Optional) 586 If an SLG is composed of a combination of several components, a 587 service chaining mechanism is required to make them work together and 588 achieve SLG functionality. 590 Moreover, some NSs may traverse NFVs such as firewalls or cache 591 servers for providing value-added services to their users. In such 592 cases, SLG might be required to support service chaining mechanisms, 593 such as handling of network service header (NSH) defined in 594 [RFC8300]. If an NS includes the service chaining architecture 595 defined in [RFC7665], some SLG would be required to support following 596 functions; classifier(CF), service function forwarder (SFF), and 597 inter boundary node(IBN). (Details of CF, SFF and IBN are described 598 in SFC documents; [RFC7665], [RFC8459].) 600 5.1.2. Control/Management Planes Aspects 602 5.1.2.1. Interfaces to Controllers or Operation Systems 604 SLG MUST have interface to its controller or operation systems for 605 set parameters related to the data plane functions described in 606 Section 5.1.1. In addition, an SLG at the edges of E2E-NSs MUST have 607 interfaces to authentication servers. 609 5.1.2.2. Address Resolution/Routing 611 An SLG MUST support address resolution or routing mechanisms to 612 connect to underlay network elements including routers or L2 613 switches. 615 5.1.2.3. Authentication Authorization Accounting (AAA) 617 For preventing entry of irregular traffic to NSs, an SLG at the edge 618 of E2E-NS MUST support AAA mechanism for incoming traffic. Also, 619 when an SLG connects to another SLG in other administrative domain, 620 SLGs should have a mechanism to confirm that the connection is 621 established with the regular processes. For example, an SLG is 622 required to support authentication of the opponent SLG with key 623 information indicated from higher-level operation systems. 625 5.1.2.4. Operation Administration and Maintenance(OAM) 627 In management of NSs, OAM mechanisms for both underlay and overlay 628 networks is required for SLGs. For an underlay network, an SLG MUST 629 have OAM functions to confirm connectivity to interconnect equipment. 630 For an overlay network as an NS, an SLG MUST have OAM functions to 631 confirm connectivity to the nodes on the same NS. 633 5.1.2.5. Traffic Monitoring 635 An SLG shall support monitoring of traffic amount and latency as a 636 mechanism for checking whether each of the accomodated NSs is 637 satisfying its SLO. When an NS can't fulfill its SLO, the SLG MUST 638 send a notification to any listening system. A use case where the 639 traffic monitoring of SLGs is used for such closed loop schem is 640 introduced in [I-D.pedro-nmrg-intelligent-reasoning] 642 5.2. Management of Services on NS (*Optional) 644 5.2.1. Data Plane Aspect 646 5.2.1.1. Identification/Classification 648 In NSaaS, some NS tenants may need delivery of an individual service 649 to each user, device, or application on the same NS. For such 650 service deliveries, an SLG might be required to identify and classify 651 user traffic based on some information such as subscriber ID or 652 payload of data packets. Also, an SLG should be controllable from 653 the NS tenant. 655 5.2.1.2. QoS Control 657 An NS accommodates several communication devices and SLGs might be 658 required to have fair queueing mechanisms for maintaining service 659 quality of each user. Also, different types of service traffic that 660 have different priorities might coexist on an NS. For example, some 661 NS providers might provide telephone and internet access services to 662 their users with an NS. In such cases, SLG might be required to 663 provide QoS control mechanisms for enforcing priority control based 664 on service priorities. 666 These QoS controls are executed depending on the information of inner 667 packets and are independent of isolation mechanisms as 668 infrastructure. An SLG might be required to have a hierarchical QoS 669 control mechanism in case that both QoS controls for services over 670 NSs and isolation between NSs are required. 672 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 674 SLG might be required to support steering or service chaining 675 function for conveying data packets to the appropriate network 676 functions deployed on an NS based on the classification result and 677 user's contract information. 679 5.2.2. Control/Management Planes Aspects 681 5.2.2.1. Interfaces to Service Management Systems 683 An SLG might have interfaces to controllers for managing user 684 policies on each NS. Some controllers might be deployed on the same 685 NS. If some controllers are located at external networks, they might 686 require SLGs to have APIs. 688 5.2.2.2. Collection of Telemetry information 690 In an NSaaS, collection of telemetry information of each NS might be 691 required for understanding traffic usage. Thus, an SLG might be 692 required to support to collect and report telemetry information of 693 connected NSs. 695 6. Structure of SLG 697 SLG is composed of data plan entities and controller. SLG Data plane 698 entity (SLG-D) has functions to manipulate NSSIs and to handle 699 traffic on slices. In some cases, an SLG-D is composed of several 700 physical devices and/or virtual instances. Function types supported 701 by SLG-D are listed Section 5. SLG controller (SLG-C) accomodates 702 multiple SLG Data plane entities via its southbound interface, and 703 sets configurations into each SLG-D. SLG-C also has a northbound 704 interface(NBI) and it provides accesses to two endpoints: higher 705 operation systems such as orchestrator, and to external customers and 706 tenants which own their NSSIs. Then, functionality and 707 controllability exposed to customers/tenants ashould be limited, and 708 the access must be secure (i.e., authentication and admission control 709 should be supported). The overview of SLG structure is shown in 710 Figure 5. 712 Customers/ Operation System 713 tenants (i.e.,Orchestrator) 715 | | 716 | | 717 +-------+---------+ 718 | 719 | 720 +---------+--------+ 721 | SLG Controller | 722 +---------+--------+ 723 | 724 +-----+------------------------------------+ 725 | | 726 | | 727 | | 728 | | 729 +-----+----------------------------+ | 730 | SLG D-plane Entity_1 | | 731 |.-----. .-----. .----------. | +-------+-------+ 732 || FIB | | OAM | |Monitoring| .. | | | 733 |`-----' `-----' `----------' | ... | SLG D-plan | 734 |.-----. .-----. .-----. .-----. | | Entity_n | 735 ||decap| | QoS | | Fwd | |encap| ..| | | 736 |`-----' `-----' `-----' `-----' | +---------------+ 737 +----------------------------------+ 739 Figure 5: Overview of SLG Structure 741 An example of data model for customers/tenants is shown in Appendix B 743 7. Deployment of SLG 745 This section describes considerations related with deployment of 746 SLGs. 748 7.1. Examples of Components Required to Maintain SLG Functions 750 For providing E2E-NSIs on existing network infrastructures, some 751 components located at boundaries of domains are required to have the 752 same set of functionality as an SLG. Examples of such components in 753 each domain type are described below. 755 Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc. 757 Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW 758 ([TS.36.300-3GPP]), etc. 760 Data Center: Gateway Router, L2 switch, ToR switch, Server, etc. 762 7.2. SLG Types Depending on Locations on NS 764 There are mainly three types of SLG for creating E2E-NSI across 765 multiple administrative domains. The requirements of each SLG type 766 are listed in Appendix A. 768 7.2.1. Edge SLG(E-SLG) 770 E-SLG is located at an edge of an E2E-NSI, and supports 771 identification, classification and authentication of user traffic in 772 addition to fundamental SLG functions, such as transport and 773 isolation. Also, it might be required to have capabilities for 774 services delivered on an NS. 776 7.2.2. Inter-Subnet SLG(IS-SLG) 778 IS-SLG is located between NSSIs within a single administrative domain 779 and has only fundamental functions such as QoS control or tranlation 780 of headers. 782 This type of SLG enables to separate an NSI into some NSSIs. It will 783 provide modularities of NSSIs, and simplify the management of NSIs. 784 However, it is not necessarily required if a common transport 785 mechanism in all domains is used. 787 7.2.3. Inter-Domain SLG(ID-SLG) 789 ID-SLG is located between NSSIs established on different domains. It 790 supports authentication for connecting to the opponent SLG in 791 addition to fundamental functions. 793 7.3. Horizontal Connection 795 The connection form of an SLG varies depending on which type it is. 796 Examples of horizontal connection forms of each SLG type are 797 described below. 799 E-SLG: An E-SLG accommodates several hosts and NSSIs. This has a 800 forwarding table of end hosts and insert their packets to the 801 appropriate NSSI. An overview of this connection is shown in 802 Figure 6. 804 *Virtual Layer* 806 +-----+ 807 host#1 ====>| | _______________ 808 | |-->/_______________ 809 host#2 ====>|E-SLG| NSSI#1 810 | | _______________ 811 host#3 ====>| |-->/_______________ 812 | | NSSI#2 813 : : | | : : 814 +-----+ 816 //////////////////////////////////////// 817 *Physical Layer* 819 ,-------------------- 820 [UE#1] -----\ / 821 [UE#2] -----[Edge] Domain#1 822 [UE#3] -----/ \ 823 : : `------------------- 825 Edge: Edge Node 827 Figure 6: Overview of horizontal connection of E-SLG 829 IS-SLG: An IS-SLG has the role of mediator between NSSIs and passes 830 packets received from an NSSI to the next one. If transport 831 methods used in each domain are different, the IS-SLG translate 832 packet form to the appropriate one. An overview of this 833 connection is shown in Figure 7. 835 *Virtual Layer* 837 +------+ 838 _________ | | ___________ 839 _________/-->|IS-SLG|--> /__________ 840 NSSI#1 | | NSSI#2 841 +------+ 843 /////////////////////////////////////// 844 *Physical Layer* 846 --------------. ,-------------- 847 \ / 848 Domain#1 [ GW ] Domain#2 849 / \ 850 --------------' `-------------- 852 GW: Gateway Node 854 Figure 7: Overview of horizontal connection of IS-SLG 856 ID-SLG: An ID-SLG passes data packets to another ID-SLG located on a 857 different administrative domain. Some tunnel established between 858 them in advance may be used for the passing of packets. An 859 overview of this connection is shown in Figure 8. 861 *Virtual Layer* 863 +------+ +------+ 864 _________ | | ______ | | ___________ 865 _________/-->|ID-SLG|O______)|ID-SLG|-->/__________ 866 NSSI#1 | | Tunnel | | NSSI#2 867 +------+ +------+ 869 /////////////////////////////////////////////////////// 870 *Physical Layer* 872 --------------------. ,------------------- 873 Administrative \ / Administrative 874 Domain#1 [ GW ]---[ GW ] Domain#2 875 / \ 876 --------------------' `------------------- 878 GW: Gateway Node 880 Figure 8: Overview of horizontal connection of ID-SLG 882 7.4. Vertical Connection 884 There are two patterns of vertical connection of SLGs in the middle 885 of E2E-NSs. The first pattern is that the SLGs accommodate only a 886 set of NSSIs, which are composition of the same E2E-NS. In this 887 pattern, such SLGs are not required to support NSSI selection, 888 however, establishment of a new SLG is required when a new E2E-NS is 889 created. This might causes extra overheads because of deploying many 890 SLGs. 892 The other pattern is that such SLGs are acceptable to accommodate 893 multiple NSSIs from each domain. In this pattern, SLGs support NSSI 894 selection. On the other hand, this pattern can restrain the number 895 of SLGs. Also, it is easy to provide transit of data packets from an 896 NSSI to another NSSI on the same domain. 898 The overviews of these patterns are shown in Figure 9 and Figure 10. 900 +-----+ 901 _________ | | ___________ 902 _________/-->|SLG#1|-->/__________ 903 NSSI#1 | | NSSI#2 904 +-----+ 905 +-----+ 906 _________ | | ___________ 907 _________/-->|SLG#2|-->/__________ 908 NSSI#3 | | NSSI#4 909 +-----+ 910 : : : 912 Figure 9: Overview of vertical connection of SLG: Separated Pattern 914 +-----+ 915 _________ | | ___________ 916 _________/-->| |-->/__________ 917 NSSI#1 |SLG#1| NSSI#2 918 _________ | | ___________ 919 _________/-->| |-->/__________ 920 NSSI#3 | | NSSI#4 921 | | 922 : | | : 923 +-----+ 925 Figure 10: Overview of vertical connection of SLG: Shared Pattern 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 SLG-C can provide some capabilities, such as NS allocation and 986 obtaining of NS status, for customers/tenants to handle their own 987 NSs. An example of data models for this interface is shown in 988 Appendix B. 990 10. Security Considerations 992 Requirements and considerations for SLG related to security are 993 described in Section 5 and Section 8. 995 11. IANA Considerations 997 This memo includes no request to IANA. 999 12. Acknowledgement 1001 The authors would like to thank Li Qiang for her kind review and 1002 valuable feedback. 1004 13. Informative References 1006 [I-D.defoy-coms-subnet-interconnection] 1007 Foy, X., Rahman, A., Galis, A., 1008 kiran.makhijani@huawei.com, k., and L. Qiang, 1009 "Interconnecting (or Stitching) Network Slice Subnets", 1010 draft-defoy-coms-subnet-interconnection-01 (work in 1011 progress), October 2017. 1013 [I-D.henry-tsvwg-diffserv-to-qci] 1014 Henry, J., Szigeti, T., and L. Contreras, "Diffserv to QCI 1015 Mapping", draft-henry-tsvwg-diffserv-to-qci-03 (work in 1016 progress), February 2020. 1018 [I-D.homma-slice-provision-models] 1019 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 1020 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 1021 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 1022 Foy, "Network Slice Provision Models", draft-homma-slice- 1023 provision-models-00 (work in progress), February 2019. 1025 [I-D.ietf-6man-segment-routing-header] 1026 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 1027 Field, B., daniel.voyer@bell.ca, d., 1028 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 1029 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 1030 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 1031 Header (SRH)", draft-ietf-6man-segment-routing-header-08 1032 (work in progress), January 2018. 1034 [I-D.ietf-spring-segment-routing-mpls] 1035 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1036 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1037 data plane", draft-ietf-spring-segment-routing-mpls-11 1038 (work in progress), October 2017. 1040 [I-D.netslices-usecases] 1041 kiran.makhijani@huawei.com, k., Qin, J., Ravindran, R., 1042 Geng, L., Qiang, L., Peng, S., Foy, X., Rahman, A., Galis, 1043 A., and G. Fioccola, "Network Slicing Use Cases: Network 1044 Customization and Differentiated Services", draft- 1045 netslices-usecases-02 (work in progress), October 2017. 1047 [I-D.pedro-nmrg-intelligent-reasoning] 1048 Martinez-Julia, P. and S. Homma, "Intelligent Reasoning on 1049 External Events for Network Management", draft-pedro-nmrg- 1050 intelligent-reasoning-01 (work in progress), March 2020. 1052 [I-D.rokui-5g-transport-slice] 1053 Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., 1054 Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., 1055 Eardley, P., Makhijani, K., and H. Flinck, "5G Transport 1056 Slice Connectivity Interface", draft-rokui-5g-transport- 1057 slice-00 (work in progress), July 2019. 1059 [NECOS] NECOS, "Novel Enablers for Cloud Slicing", 1060 . 1062 [NFV-Architectural-Framework] 1063 Network Functions Virtualisation (NFV) ETSI Industry 1064 Specification Group (ISG), "Network Functions 1065 Virtualisation (NFV); Architectural Framework", December 1066 2014, . 1069 [OSM-White-Paper] 1070 ETSI, "OSM White Paper", October 2016, 1071 . 1074 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1075 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1076 eXtensible Local Area Network (VXLAN): A Framework for 1077 Overlaying Virtualized Layer 2 Networks over Layer 3 1078 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1079 . 1081 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1082 Chaining (SFC) Architecture", RFC 7665, 1083 DOI 10.17487/RFC7665, October 2015, 1084 . 1086 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1087 "Network Service Header (NSH)", RFC 8300, 1088 DOI 10.17487/RFC8300, January 2018, 1089 . 1091 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1092 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1093 DOI 10.17487/RFC8453, August 2018, 1094 . 1096 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1097 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1098 DOI 10.17487/RFC8459, September 2018, 1099 . 1101 [Slicing_Tutrial] 1102 IEEE NetSoft2018, "Network Slicing Landscape Tutorial", 1103 June 2018, 1104 . 1107 [TS.23.501-3GPP] 1108 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1109 (V16.0.0): System Architecture for 5G System; Stage 2", 1110 September 2018, . 1113 [TS.28.530-3GPP] 1114 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1115 (V1.0.0): Management and orchestration of networks and 1116 network slicing; Concepts, use cases and requirements 1117 (work in progress)", June 2018, 1118 . 1121 [TS.36.300-3GPP] 1122 3rd Generation Partnership Project (3GPP), "Evolved 1123 Universal Terrestrial Radio Access (E-UTRA) and Evolved 1124 Universal Terrestrial Radio Access Network (E-UTRAN); 1125 Overall description; Stage 2", December 2007, 1126 . 1128 Appendix A. Requirements for each SLG Type 1130 The requirements for each SLG type are listed in Figure 11. 1132 +---------------++-------+-------+-------+----------------+ 1133 | || E-SLG |IS-SLG |ID-SLG | Reference | 1134 +=========================================================+ 1135 |*Data-Plane of NS as Infrastructure | 1136 +=========================================================+ 1137 |Identification/|| M | O | O |Section 5.1.1.1.| 1138 |Classification || | | | | 1139 +---------------++-------+-------+-------+----------------+ 1140 |Transport/ || M | O | M |Section 5.1.1.2.| 1141 |Forwarding || | | | | 1142 +---------------++-------+-------+-------+----------------+ 1143 |Isolation || M | M | M |Section 5.1.1.3.| 1144 +---------------++-------+-------+-------+----------------+ 1145 |Service Chain || O | O | O |Section 5.1.1.4.| 1146 +=========================================================+ 1147 |*Control/Management-Plane of NS as Infrastructure | 1148 +=========================================================+ 1149 |IF to Ctrl/OpS || M | M | M |Section 5.1.2.1.| 1150 +---------------++-------+-------+-------+----------------+ 1151 |Addr Resolution|| M | M | M |Section 5.1.2.2.| 1152 |/Routing || | | | | 1153 +---------------++-------+-------+-------+----------------+ 1154 |AAA || M | - | M |Section 5.1.2.3.| 1155 +---------------++-------+-------+-------+----------------+ 1156 |OAM || M | M | M |Section 5.1.2.4.| 1157 +---------------++-------+-------+-------+----------------+ 1158 |Monitoring || M | M | M |Section 5.1.2.5.| 1159 +=========================================================+ 1160 |*Data-Plane for Service on NS | 1161 +=========================================================+ 1162 |Identification/|| O | - | O |Section 5.2.1.1.| 1163 |Classification || | | | | 1164 +---------------++-------+-------+-------+----------------+ 1165 |QoS Control || O | O | O |Section 5.2.1.2.| 1166 +---------------++-------+-------+-------+----------------+ 1167 |Steering/ || O | - | O |Section 5.2.1.3.| 1168 |Service Chain || | | | | 1169 +=========================================================+ 1170 |*Control/Management-Plane for Service on NS | 1171 +=========================================================+ 1172 |IF to Service || O | O | O |Section 5.2.2.1.| 1173 |Manager || | | | | 1174 +---------------++-------+-------+-------+----------------+ 1175 |Telemetry || O | O | O |Section 5.2.2.2.| 1176 +---------------++-------+-------+-------+----------------+ 1177 M: Mandatry, O: Optional, - : Not Required 1179 Figure 11: List of Requirements for each SLG 1181 Appendix B. Example of Data Model for Service Management 1183 An SLG provides customers/tenants some capabilities: NS allocation, 1184 change of forwarding policy for user traffic on the target NS, 1185 reporting telemetry information of the target NS, etc. Examples of 1186 tree diagram of data model for service management is shown in 1187 Figure 12. 1189 module: slg-svc-man 1190 +--rw ns-allocation 1191 +--rw current-ns-id? 1192 | +--rw ns-id? string 1193 | +--rw nssi-id* string 1194 +--rw flow-id 1195 | +--rw ipv4? boolean 1196 | | +--rw src-ipv4-address? inet:ipv4-address 1197 | | +--rw dst-ipv4-address? inet:ipv4-address 1198 | +--rw ipv6? boolean 1199 | | +--rw src-ipv6-prefix? inet:ipv6-prefix 1200 | | +--rw dst-ipv6-prefix? inet:ipv6-prefix 1201 | +--rw src-port? inet:port-number 1202 | +--rw dst-port? inet:port-number 1203 | +--rw protocol? uint8 1204 | +--rw option-tag? 1205 | +--rw tag-id* string 1206 +--rw new-ns-id? string 1207 +--rw ns-id? 1208 +--rw nssi-id* string 1210 +--rw uflow-policy 1211 +--rw ns-id? string 1212 | +--nssi-id* string 1213 +--rw flow-id? 1214 | +--rw ipv4? boolean 1215 | | +--rw src-ipv4-address? inet:ipv4-address 1216 | | +--rw dst-ipv4-address? inet:ipv4-address 1217 | +--rw ipv6? boolean 1218 | | +--rw src-ipv6-prefix? inet:ipv6-prefix 1219 | | +--rw dst-ipv6-prefix? inet:ipv6-prefix 1220 | +--rw src-port? inet:port-number 1221 | +--rw dst-port? inet:port-number 1222 | +--rw protocol? uint8 1223 | +--rw option-tag? 1224 | +--rw tag-id* string 1225 +--rw forwarding-policy 1226 +--rw traffic-class inet8 1227 +--rw guaranteed-rate-value? uint64 1228 +--rw permissible-jitter-value? uint64 1229 +--rw service-function-path-id? inet24 1231 +--ro telemery-report 1232 +--ro ns-id? string 1233 +--ro nssi-id* string 1234 +--ro flow-id* 1235 +--ro packet-received? uint64 1236 +--ro packet-sent? uint64 1237 +--ro bytes-received? uint64 1238 +--ro bytes-sent? uint64 1239 +--ro latency? 1240 +--ro endpoint-id* string 1242 Figure 12: Tree Diagram of Data Model for Service Management 1244 Appendix C. Complementation of Network Slicing in 3GPP 1246 The 3GPP 5GS is natively support network slicing (ref. 1247 [TS.23.501-3GPP], and UPF provides some functions as SLG, such as NS 1248 selection, QoS control, traffic steering, etc. 3GPP is responsible 1249 for standardizing user plane manipulation for mobility management, 1250 and interworking with transport on underlay network and external 1251 networks of 5GS such as DNs is out of scope in 3GPP. 1253 SLG concept will provide complemental definitions of functions and 1254 interfaces for providing E2E-NSI including 5GS. A way of 1255 interworking between transport slice and RAN/UPF is described in 1256 [I-D.rokui-5g-transport-slice]. In this case, RAN/UPF and transport 1257 slice endpoints connected to them behave as ID-SLGs. 1259 Another way for interworking is RAN/UPF support functionalities of 1260 SLG for transport slice. However, this is not supported in 3GPP 1261 standards, and may inhibit multi-vendor implementation. 1263 Authors' Addresses 1265 Shunsuke Homma 1266 NTT 1267 Japan 1269 Email: shunsuke.homma.fp@hco.ntt.co.jp 1271 Takayuki Nakamura 1272 NTT 1273 Japan 1275 Email: takayuki.nakamura.gy@hco.ntt.co.jp 1277 Xavier de Foy 1278 InterDigital Inc. 1279 Canada 1281 Email: Xavier.Defoy@InterDigital.com 1283 Alex Galis 1284 University College London 1285 United Kingdom 1287 Email: a.galis@ucl.ac.uk 1288 Luis M. Contreras 1289 Telefonica 1290 Ronda de la Comunicacion, s/n 1291 Sur-3 building, 3rd floor 1292 Madrid 28050 1293 Spain 1295 Email: luismiguel.contrerasmurillo@telefonica.com 1296 URI: http://lmcontreras.com/ 1298 Reza Rokui 1299 Nokia 1300 Canada 1302 Email: reza.rokui@nokia.com 1304 Pedro Martinez-Julia 1305 NICT 1306 Japan 1308 Email: pedro@nict.go.jp