idnits 2.17.1 draft-homma-nmrg-slice-gateway-00.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 431: '... edge of E2E-NSs MUST have the capabil...' RFC 2119 keyword, line 435: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 441: '... Access: An SLG MUST identify and cla...' RFC 2119 keyword, line 447: '...subnets: An SLG MUST identify and cla...' RFC 2119 keyword, line 455: '... SLGs MUST provide functions for tra...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2012 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 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-05 == 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nmrg S. Homma 3 Internet-Draft NTT 4 Intended status: Informational X. de Foy 5 Expires: April 25, 2019 InterDigital Inc. 6 A. Galis 7 University College London 8 October 22, 2018 10 Gateway Function for Network Slicing 11 draft-homma-nmrg-slice-gateway-00 13 Abstract 15 This document describes the roles and requirements for a slice 16 gateway that is a function or function group for handling data plane 17 traffic, such as connecting/disconnecting and compose/decompose 18 network slice subnets and providing network slices from end to end. 19 The interworkings between management and control elements at the 20 management and control planes with the gateway function for 21 controlling and orchestrating end-to-end network slices are also 22 presented in this document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 60 3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 6 61 4. Architecture of Network Slicing System . . . . . . . . . . . 8 62 4.1. Network Slice Management System Architecture . . . . . . 8 63 5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 10 64 5.1. Management of NS as Infrastructure . . . . . . . . . . . 10 65 5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 10 66 5.1.1.1. Identification/Classification . . . . . . . . . . 11 67 5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 11 68 5.1.1.3. Isolation between NSs . . . . . . . . . . . . . . 12 69 5.1.1.4. Service Chaining as Infrastructural 70 Mechanism(*Optional) . . . . . . . . . . . . . . 13 71 5.1.2. Control/Management Planes Aspects . . . . . . . . . . 13 72 5.1.2.1. Interfaces to Controllers or Operation Systems . 13 73 5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 13 74 5.1.2.3. Authentication Authorization Accounting (AAA) . . 13 75 5.1.2.4. Operation Administration and Maintenance(OAM) . . 14 76 5.2. Management of Services on NS (*Optional) . . . . . . . . 14 77 5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 14 78 5.2.1.1. Identification/Classification . . . . . . . . . . 14 79 5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 14 80 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 14 81 5.2.2. Control/Management Planes Aspects . . . . . . . . . . 15 82 5.2.2.1. Interfaces to Service Management Systems . . . . 15 83 5.2.2.2. Collection of Telemetry information . . . . . . . 15 84 6. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. Examples of Components Required to Maintain SLG Functions 15 86 6.2. SLG Types Depending on Locations on NS . . . . . . . . . 15 87 6.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 15 88 6.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 16 89 6.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 16 90 6.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 16 91 6.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 19 92 6.5. Software vs. Hardware . . . . . . . . . . . . . . . . . . 20 93 7. Interconnection between NS subnets . . . . . . . . . . . . . 20 94 7.1. Pre-arrangement of transport protocols . . . . . . . . . 20 95 7.2. Quality Assurance between SLGs . . . . . . . . . . . . . 20 96 7.3. Secure Interconnection . . . . . . . . . . . . . . . . . 21 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 101 11. Informative References . . . . . . . . . . . . . . . . . . . 21 102 Appendix A. Requirements for each SLG Type . . . . . . . . . . . 23 103 Appendix B. Position of SLG on ETSI NFV MANO . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 Network slicing is an approach to create separate virtual networks in 109 support of service depending on several requirements on the same 110 physical resources, and it enables networks to adapt to requirements, 111 which is diverse more, inexpensively and flexibly. The overview is 112 introduced in [Slicing_Tutrial] and [NECOS]. 114 It's also expected to enhance usability of infrastructural networks 115 for tenants and create new business opportunities. For example, by 116 using network slices lent from infrastructure operators, other 117 industrial companies can provide communication services including 118 ensurance of network transport without having physical 119 infrastructure. 121 From a business point of view, a slice includes a combination of all 122 the relevant network resources, functions, and assets required to 123 fulfill a specific business case or service, including OSS, BSS and 124 DevOps processes. 126 From the network infrastructure point of view, network slice requires 127 the partitioning and assignment of a set of resources that can be 128 used in an isolated, disjunctive or non- disjunctive manner for that 129 slice. 131 From the tenant point of view, network slice provides different 132 capabilities, specifically in terms of their management and control 133 capabilities, and how much of them the network service provider hands 134 over to the slice tenant. As such there are two kinds of slices: (A) 135 Inner slices, understood as the partitions used for internal services 136 of the provider, retaining full control and management of them. (B) 137 Outer slices, being those partitions hosting customer services, 138 appearing to the customer as dedicated networks. 140 Network slices are established with combination of various 141 technologies, such as software defined network (SDN), network 142 function virtualization (NFV), or traffic engineering, and managed/ 143 operated with automation technologies such as orchestrator. 145 Assumed use cases of network slices include establishment of virtual 146 networks whose qualities are guaranteed from end to end under the 147 supervision of multi-domain orchstrators. In such cases, a network 148 slice subnet is created on each domain, such as access network and 149 core network, and an end-to-end network slices is composed of 150 connected subnets. 152 Network slice subnets are built based on specifications of the 153 underlay network, and thus the used technologies might vary. 154 Therefore, a gateway function, which enables to connect subnets while 155 adapting the differentiations and forward data packets to/from the 156 appropriate next subnet, is required. 158 This document describes the gateway function for network slicing, 159 called slice gateway or SLG, and the role and requirements are 160 described. Note that defining a new data plane technology is not a 161 goal of this draft. In addition, this draft aims to specify 162 management-related requirements for an SLG, which may be implemented 163 using existing data plane technologies. 165 2. Definition of Terms 167 Network Slicing: Network slicing is a technology or an approach to 168 create separate virtual networks in support of services, depending 169 on several requirements, on the same physical resources. This is 170 possible by combinations of several network technologies. 172 Network Slice (NS): An NS is a virtual network established on 173 network infrastructure. Some include additional network functions 174 such as firewall or load-balancer in addition to basically 175 forwarding functions such as switches or routers. It has an 176 overlay architecture and is independent from the underlay 177 network's topology. 179 NS Subnet: An NS subnet is partially virtual network established 180 within a single domain. 182 End-to-End Network Slice (E2E-NS): An E2E-NS is a virtual network 183 connecting between end points. E2E slices are composed of a 184 single NS subnet or multiple NS subnets. 186 Network Slice as a Service (NSaaS): An NSaaS is a NS distribution 187 model in which a third-party provider hosts NSs and makes them 188 available to customers. 190 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 191 that rents and occupies NSs from NS providers. 193 Domain: A domain is a group of a network and devices administrated 194 as a unit with common rules and procedures. 196 Administrative Domain: An administrative domain is a group of 197 networks and devices managed by an administrator. 199 Resource: A resource is element used to create virtual networks. 200 There are several types of resources, i.e., connectivity, 201 computing and storage. 203 Network Function Virtualization (NFV): NFV is the concept or 204 technologies to provide dedicated network appliances as software. 206 Software Defined Network (SDN): SDN is the concept or technologies 207 to separate network control plane from data plane, and control 208 network devices dynamically and flexibly. 210 Virtual Network: A virtual network is a network running a number of 211 virtual network functions. 213 Virtual Network Function (VNF): A virtual network function (VNF) is 214 a network function whose functional software is decoupled from 215 hardware. One or more virtual machines running different software 216 and processes on top of industry-standard high-volume servers, 217 switches and storage, or cloud computing infrastructure, and 218 capable of implementing network functions traditionally 219 implemented via custom hardware appliances and middleboxes (e.g., 220 router, NAT, firewall, load balancer, etc.) 222 Slice Gateway Function (SLG): An SLG is a function or a group of 223 functions to connect/disconnect NS subnets. The roles are 224 described in the following sections. 226 Business Support System and Operation Support System (BSS/OSS): BSS/ 227 OSS are systems to support service providing and operation of 228 network devices. 230 Orchestrator: Orchestrator is an entity to operate network 231 components automatically. There are several types of 232 orchestrators including NFV Orchestrator (NFVO) or service 233 orchestrator defined by ETSI NFV and Open Source MANO (OSM) 234 ([NFV-Architectural-Framework] and [OSM-White-Paper]). 236 SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls 237 SLGs. An SLG-Ctrl is controlled by upper-level operation systems 238 such as OSS/BSS or orchestrator. 240 3. Motivations and Roles of SLG 242 One of the main roles of SLG is the enablement of interworkings 243 between data plane with management and control elements for 244 controlling and orchestrating end-to-end slices. 246 Use cases of network slices are discussed in several Standard 247 Developing Organizations (SDOs). Some examples are described in use 248 cases document ([I-D.netslices-usecases]). 250 In some proposed use cases, an NS is structured across multiple 251 network domains. The capability of NS subnets might be different 252 because the components are domain-specific. In particular, the 253 differentiation in capability between different administrative 254 domains is large. 256 For connecting some different NS subnets and providing a NS that 257 guarantees the prescribed quality from end to end, SLGs are required 258 to connect such NS subnets. SLGs enable to provide E2E-NSs 259 independently of specifications of underlay networks by hiding the 260 differentiations and connecting between NS subnets. An overview of 261 this concept is shown in Figure 1. SLGs glue NS subnets established 262 on each domain and provide an E2E-NS. 264 E2E-NS 265 ________________________A_________________________ 266 / \ 267 _____________ ____________ _________________ 268 / // / / / 269 end +---+ NS +---+ NS +---+ +---+ NS ,------. 270 host==>|SLG| Subnet |SLG| Subnet |SLG+-+SLG| Subnet( Server ) 271 +---+ #1 +---+ #2 +---+ +---+ #3 `------' 272 /____________//___________/ /________________/ 273 /____________//___________/ /________________/ 274 : : : 275 : : : 276 .--. .--. .--. 277 ( )-. ( )-. ( )-. 278 .' Access ' .' Core ' .' Data ' 279 ( Network ) ( Network ) ( Center ) 280 ( -' ( -' ( /Cloud -' 281 '-( ) '-( ) '-( ) 282 '---' '---' '---' 284 \______ ______/ \_____ _____/ \________ ________/ 285 V V V 286 Domain#1 Domain#2 Domain#3 288 \_____________ _____________/ \________ ________/ 289 V V 290 Domain of Administrator#A Domain of Administrator#B 292 Figure 1: E2E-NS composed of multiple NS subnets 294 Moreover, identification of user service traffic and their 295 allocation/disallocation to the appropriate NS subnet are required at 296 the edges of E2E-NSs, as shown in Figure 2, and SLGs might take on 297 these roles. 299 +-----+ _______________ 300 end | |-->/_______________ 301 host ====>| SLG | NS Subnet#1 302 |@Edge| _______________ 303 | |-->/______________ 304 | | NS Subnet#2 305 | | : : 306 +-----+ 308 Figure 2: NS subnet selection of SLG 310 Note that, this model has the assumption that transitions of data 311 packets from one NS subnet to another are executed at only SLGs. 312 Also, an SLG is not necessarily implemented as a single device or 313 virtual machine (VM). 315 4. Architecture of Network Slicing System 317 NSs are composed of several (virtual) network functions and links, 318 and the charactaristics of each NS are based on the assumed service. 319 Also, some of NSs are deployed accross multiple administrative 320 domains. For deploying the appropriate NSs based on each service 321 requirements, a management system, which enables to control network 322 resources totally within a domain, and interaction between such 323 management systems are required. 325 An SLG is a network function, and SLGs are installed at edge of NS 326 subnets. NSs are dynamically created, deleted, and moved depending 327 on requests from network opertor orNS tenants. Therefore, some SLGs 328 would be required to be VNF for flexible deployment. 330 This section describes overview of NS management system architecture 331 (Section 4.1) . 333 4.1. Network Slice Management System Architecture 335 The architecture overview of NS management system is shown in 336 Figure 3. 338 NS Tenant 339 | 340 . .|. . . . . . . . . . . . . . . . . . . . . 341 . +-v---------+ . 342 . |Portal/GUI +--+ . 343 . +-+---------+ | . . . . . . . . . . 344 . | +-v-----------------------+ . . +------------+ . 345 . | |CSS-Mngr./TNS-Orch. |<------->|CSS-M/TNS-O | . 346 . | +-+-------+---------------+ . . +-+--------+-+ . 347 . | | | . . | | . 348 . +-v-----+ | | . . +-v-----+ | . 349 . |BSS/OSS|<-----+ | . . |BSS/OSS| | . 350 . +-+-----+ | . . +-+-----+ | . 351 . | | . . | | . 352 . +-v--------------------v-----------+ . . +-v--------v-+ . 353 . | E2E-Orch./Network Service-Orch. | . . |E2E-O/NS-O | . 354 . +-+--------------------+-----------+ . . +-+--------+-+ . 355 . | | . . | | . 356 . +-v----------------+ +-v----------------+ . . : . 357 . | Resource Orch.#1 | | Resource Orch.#2 |.. . . . . . . . . . . 358 . +-+---------+------+ +-+---------+------+ . Administrative 359 . | | | | . Domain#2 360 . +-v------++-v------+ +-v------++-v------+ . 361 . |Network ||NFV | |Network ||NFV | . 362 . |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | . 363 . +-+------++-+------+ +-+------++-+------+ . 364 . | | | | . 365 . +-v------++-v------+ +-v------++-v------+ . 366 . |Network ||Server | |Network ||Server | . 367 . |Elements||Resource| |Elements||Resource|.. . 368 . |in ||in | |in ||in | . 369 . |Domain#1||Domain#1| |Domain#2||Domain#2| . 370 . +--------++--------+ +--------++--------+ . 371 . . . . . . . . . . . . . . . . . . . . . . . 372 Administrative Domain#1 374 CSS-Mngr./CSS-M:Cross-Segment Slice Manager 375 TNS-Orch./TNS-O:Transport Network Slice Orchestrator 377 Figure 3: Overview of NS Management Architecture 379 Orchestrators manage whole resources including network elements and 380 server resources (i.e., routing, bandwidth, compute or storage). In 381 this figure, the resources including network elements and server 382 resources are managed by resource orchestrators installed in each 383 domain, and the E2E-orchestrator and network service orchestrator 384 handle resource orchestrators. 386 NSs are requested from NS tenants via the portal system and the order 387 of creations of an NS is given to the E2E orchestrator from the 388 portal system via BSS/OSS. When an NS across multiple administrative 389 domains are requested, the portal system that received the request 390 forwards the order to create NS subnets to the other infrastructure 391 providers' systems via Cross-Segment Slice Manager. The details of 392 COMS architecture are described in the architecture document ([I- 393 D.qiang-coms-architecture]). 395 SLGs are also controlled via orchestrators. An SLG basically belongs 396 to a network element, and it might also belong to server resource if 397 it runs as a VNF. (The position of SLG deployed as a VNF is shown in 398 Appendix B.) 400 The information model used in this architecture is described in 401 information model document 402 ([I-D.qiang-coms-netslicing-information-model]). 404 5. Requirements for SLG 406 An SLG is basically a component in the data plane and has the roles 407 of data packet processing. Moreover, it is required to have 408 functions for control/management processes such as connecting to 409 underlay networks or managing NSs. 411 Furthermore, an SLG might be required to support handling services 412 provided on NSs in addition to controlling of NS because an SLG is an 413 edge node on an E2E-NS. 415 In this section, we describe the requirements for an SLG in terms of 416 the following aspects and their interworkings. 418 1. Data plane for NSs as infrastructure 420 2. Control/management plane for NSs as infrastructure 422 3. Data plane for services on NSs 424 4. Control/management plane for services on NSs 426 5.1. Management of NS as Infrastructure 428 5.1.1. Data Plane Aspect 429 5.1.1.1. Identification/Classification 431 SLGs at the edge of E2E-NSs MUST have the capability to identify and 432 classify data packets, and assign them to the appropriate E2E-NS. 433 This requirement varies depending on the location. 435 Fixed Access: An SLG MUST identify and classify data packet with 436 access point, including CPE or WiFi-AP, or subscriber ID such as 437 VLAN-ID. Moreover, in some services, an SLG should identify and 438 classify data packets based on user device or application used in 439 the communication. 441 Mobile Access: An SLG MUST identify and classify data packet with 442 subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of 443 tunnels. Moreover, in some services, an SLG should identify and 444 classify data packets based on application used in the 445 communication or location of the user equipment (UE). 447 Between NS subnets: An SLG MUST identify and classify data packet 448 based on the tunnel-ID or virtual routing and forwarding (VRF) 449 that received the packets. If specific slice identifier such as a 450 value mapped in the metadata field of the IP header is used; an 451 SLG should identify and classify data packets with the ID. 453 5.1.1.2. Transporting/Forwarding 455 SLGs MUST provide functions for transport data packets depending on 456 the specifications of the underlay networks. 458 Encapsulation/Decapsulation/Tagging: In network slicing, duplication 459 of IP addresses of user packets between NSs MUST be accepted, 460 thus, using techniques that enable separation of a network 461 logically is preferred. In short, some tunnel protocols or 462 tagging approaches should be used as transport of NSs. For this 463 reason, SLG MUST support encapsulation or tagging of data packets 464 based on the specification of the underlay network. Also, SLG 465 MUST support the packets' decapsulation or untagging. Examples of 466 tunnel protocols and tags that can be used for creating NSs on L2/ 467 L3 segments are described below. 469 L2 Segment: VLAN, MPLS, Segment Routing MPLS (SR-MPLS), PPPoE, 470 etc. 472 L3 Segment: GRE, L2TP, GTP-U, VxLAN, IPv6 Segment Routing (SRv6), 473 etc. 475 VxLAN, SR-MPLS, and SRv6 are described in their specification 476 documents ([RFC7348], [I-D.ietf-spring-segment-routing-mpls], and 477 [I-D.ietf-6man-segment-routing-header]). 479 Translation of Encapsulation/Tagging Form: SLG MUST support to 480 translate tunnel header or tag of received packets to the 481 appropriate tunnel header or tag when it forwards data packets to 482 the next NS subnet that has different transport capability. 484 Distribution of Traffic: Some NSs have multiple route between the 485 same end points within the same NS subnet because of traffic 486 engineering, switching to a redundant path, or other reasons, and 487 SLG MAY forward data packets with the appropriate route based on 488 some trigger information. An example of the overview of this 489 requirement is shown in Figure 4. In this figure, there are two 490 routes, main and sub, between SLGs, and an SLG switches forwarding 491 route depending on the network situation such as congestion 492 occurrence on the current route. 494 ____________________________ 495 / . . . . . / 496 +-----+ . . +-----+ 497 | |. . . .| | 498 | SLG | | SLG | 499 | |* * * *| | 500 +-----+ * * +-----+ 501 / * * * * * / 502 /___________________________/ 503 NS Subnet 504 *** : Main-route 505 ... : Sub-route 507 Figure 4: An example of traffic distribution by SLG 509 5.1.1.3. Isolation between NSs 511 In NSaaS, isolation control is required for avoiding an NS being 512 affect by other NSs. Traffic engineering or QoS control is ones of 513 the most fundamental approaches to prevent disturbances between NSs. 515 Traffic Shaping/Policing: An SLG MUST execute traffic shaping and 516 policing at its egress and ingress ports to avoid an NS using 517 excessive traffic bandwidth. 519 Quality of service (QoS) Control: If there is an order of priority 520 between NSs on the same underlay infrastructure, an SLG should 521 remark the appropriate QoS parameter of the outer-most header of 522 each packet following the preconfigured setting and provide packet 523 scheduling based on the QoS parameter for providing priority 524 control. The field that SLG refers may vary depending on the 525 specification of the underlay network. For example, COS value is 526 remarked in L2 segments; on the other hand, DSCP value is remarked 527 in L3 segments. 529 5.1.1.4. Service Chaining as Infrastructural Mechanism(*Optional) 531 If an SLG is composed of a combination of several components, a 532 service chaining mechanism is required to make them work together and 533 achieve SLG functionality. 535 Moreover, some NSs may traverse NFVs such as firewalls or cache 536 servers for providing value-added services to their users. In such 537 cases, SLG might be required to support service chaining mechanisms, 538 such as handling of network service header (NSH) defined in 539 [RFC8300]. If an NS includes the service chaining architecture 540 defined in [RFC7665], some SLG would be required to support following 541 functions; classifier(CF), service function forwarder (SFF), and 542 inter boundary node(IBN). (Details of CF, SFF and IBN are described 543 in SFC documents; [RFC7665], [I-D.ietf-sfc-hierarchical].) 545 5.1.2. Control/Management Planes Aspects 547 5.1.2.1. Interfaces to Controllers or Operation Systems 549 SLG MUST have interface to its controller or operation systems for 550 set parameters related to the data plane functions described in 551 Section 5.1.1. In addition, an SLG at the edges of E2E-NSs MUST have 552 interfaces to authentication servers. 554 5.1.2.2. Address Resolution/Routing 556 An SLG MUST support address resolution or routing mechanisms to 557 connect to underlay network elements including routers or L2 558 switches. 560 5.1.2.3. Authentication Authorization Accounting (AAA) 562 For preventing entry of irregular traffic to NSs, an SLG at the edge 563 of E2E-NS MUST support AAA mechanism for incoming traffic. Also, 564 when an SLG connects to another SLG in other administrative domain, 565 SLGs should have a mechanism to confirm that the connection is 566 established with the regular processes. For example, an SLG is 567 required to support authentication of the opponent SLG with key 568 information indicated from higher-level operation systems. 570 5.1.2.4. Operation Administration and Maintenance(OAM) 572 In management of NSs, OAM or monitoring mechanisms for both underlay 573 and overlay networks is required for SLGs. For an underlay network, 574 an SLG MUST have OAM functions to confirm connectivity to 575 interconnect equipment. For an overlay network, an SLG MUST have OAM 576 functions to confirm connectivity to the some node on the same NS, 577 and measure the traffic amount of flowing packets on each NS. 579 5.2. Management of Services on NS (*Optional) 581 5.2.1. Data Plane Aspect 583 5.2.1.1. Identification/Classification 585 In NSaaS, some NS tenants may need delivery of an individual service 586 to each user, device, or application on the same NS. For such 587 service deliveries, an SLG might be required to identify and classify 588 user traffic based on some information such as subscriber ID or 589 payload of data packets. Also, an SLG should be controllable from 590 the NS tenant. 592 5.2.1.2. QoS Control 594 An NS accommodates several communication devices and SLGs might be 595 required to have fair queueing mechanisms for maintaining service 596 quality of each user. Also, different types of service traffic that 597 have different priorities might coexist on an NS. For example, some 598 NS providers might provide telephone and internet access services to 599 their users with an NS. In such cases, SLG might be required to 600 provide QoS control mechanisms for enforcing priority control based 601 on service priorities. 603 These QoS controls are executed depending on the information of inner 604 packets and are independent of isolation mechanisms as 605 infrastructure. An SLG might be required to have a hierarchical QoS 606 control mechanism in case that both QoS controls for services over 607 NSs and isolation between NSs are required. 609 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 611 SLG might be required to support steering or service chaining 612 function for conveying data packets to the appropriate network 613 functions deployed on an NS based on the classification result and 614 user's contract information. 616 5.2.2. Control/Management Planes Aspects 618 5.2.2.1. Interfaces to Service Management Systems 620 An SLG might have interfaces to controllers for managing user 621 policies on each NS. Some controllers might be deployed on the same 622 NS. If some controllers are located at external networks, they might 623 require SLGs to have APIs. 625 5.2.2.2. Collection of Telemetry information 627 In an NSaaS, collection of telemetry information of each NS might be 628 required for understanding traffic usage. Thus, an SLG might be 629 required to support to collect and report telemetry information of 630 connected NSs. 632 6. Deployment of SLG 634 This section describes considerations related with deployment of 635 SLGs. 637 6.1. Examples of Components Required to Maintain SLG Functions 639 For providing E2E-NSs on existing network infrastructures, some 640 components located at boundaries of domains are required to have the 641 same set of functionality as an SLG. Examples of such components in 642 each domain type are described below. 644 Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc. 646 Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW 647 ([TS.36.300-3GPP]), etc. 649 Data Center: Gateway Router, L2 switch, ToR switch, Server, etc. 651 6.2. SLG Types Depending on Locations on NS 653 There are mainly three types of SLG for creating E2E-NS across 654 multiple administrative domains. The requirements of each SLG type 655 are listed in Appendix A. 657 6.2.1. Edge SLG(E-SLG) 659 This is located at an edge of an E2E-NS, and supports identification, 660 classification and authentication of user traffic in addition to 661 fundamental SLG functions, such as transport and isolation. Also, it 662 might be required to have capabilities for services delivered on an 663 NS. 665 6.2.2. Inter-Subnet SLG(IS-SLG) 667 This is located between NS subnets within a single administrative 668 domain and has only fundamental functions. It is not necessarily 669 required if a common transport mechanism in all domains is used. 671 6.2.3. Inter-Domain SLG(ID-SLG) 673 This is located between NS subnets established on different domains. 674 It supports authentication for connecting to the opponent SLG in 675 addition to fundamental functions. 677 6.3. Horizontal Connection 679 The connection form of an SLG varies depending on which type it is. 680 Examples of horizontal connection forms of each SLG type are 681 described below. 683 E-SLG: An E-SLG accommodates several hosts and NS subnets. This has 684 a forwarding table of end hosts and insert their packets to the 685 appropriate NS subnet. An overview of this connection is shown in 686 Figure 5. 688 *Virtual Layer* 690 +-----+ 691 host#1 ====>| | _______________ 692 | |-->/_______________ 693 host#2 ====>|E-SLG| NS Subnet#1 694 | | _______________ 695 host#3 ====>| |-->/_______________ 696 | | NS Subnet#2 697 : : | | : : 698 +-----+ 700 //////////////////////////////////////// 701 *Physical Layer* 703 ,-------------------- 704 [UE#1] -----\ / 705 [UE#2] -----[Edge] Domain#1 706 [UE#3] -----/ \ 707 : : `------------------- 709 Edge: Edge Node 711 Figure 5: Overview of horizontal connection of E-SLG 713 IS-SLG: An IS-SLG has the role of mediator between NS subnets and 714 passes packets received from an NS subnet to the next one. If 715 transport methods used in each domain are different, the IS-SLG 716 translate packet form to the appropriate one. An overview of this 717 connection is shown in Figure 6. 719 *Virtual Layer* 721 +------+ 722 _________ | | ___________ 723 _________/-->|IS-SLG|--> /__________ 724 NS Subnet#1 | | NS Subnet#2 725 +------+ 727 /////////////////////////////////////// 728 *Physical Layer* 730 --------------. ,-------------- 731 \ / 732 Domain#1 [ GW ] Domain#2 733 / \ 734 --------------' `-------------- 736 GW: Gateway Node 738 Figure 6: Overview of horizontal connection of IS-SLG 740 ID-SLG: An ID-SLG passes data packets to another ID-SLG located on a 741 different administrative domain. Some tunnel established between 742 them in advance may be used for the passing of packets. An 743 overview of this connection is shown in Figure 7. 745 *Virtual Layer* 747 +------+ +------+ 748 _________ | | ______ | | ___________ 749 _________/-->|ID-SLG|O______)|ID-SLG|-->/__________ 750 NS Subnet#1 | | Tunnel | | NS Subnet#2 751 +------+ +------+ 753 /////////////////////////////////////////////////////// 754 *Physical Layer* 756 --------------------. ,------------------- 757 Administrative \ / Administrative 758 Domain#1 [ GW ]---[ GW ] Domain#2 759 / \ 760 --------------------' `------------------- 762 GW: Gateway Node 764 Figure 7: Overview of horizontal connection of ID-SLG 766 6.4. Vertical Connection 768 There are two patterns of vertical connection of SLGs in the middle 769 of E2E-NSs. The first pattern is that the SLGs accommodate only a 770 set of NS subnets, which are composition of the same E2E-NS. In this 771 pattern, such SLGs are not required to support NS subnet selection, 772 however, establishment of a new SLG is required when a new E2E-NS is 773 created. This might causes extra overheads because of deploying many 774 SLGs. 776 The other pattern is that such SLGs are acceptable to accommodate 777 multiple NS subnets from each domain. In this pattern, SLGs are 778 support NS subnet selection. On the other hand, this pattern can 779 restrain the number of SLGs. Also, it is easy to provide transit of 780 data packets from an NS subnet to other subnet on the same domain. 782 The overviews of these patterns are shown in Figure 8 and Figure 9. 784 +-----+ 785 _________ | | ___________ 786 _________/-->|SLG#1|-->/__________ 787 NS Subnet#1 | | NS Subnet#2 788 +-----+ 789 +-----+ 790 _________ | | ___________ 791 _________/-->|SLG#2|-->/__________ 792 NS Subnet#3 | | NS Subnet#4 793 +-----+ 794 : : : 796 Figure 8: Overview of vertical connection of SLG: Separated Pattern 798 +-----+ 799 _________ | | ___________ 800 _________/-->| |-->/__________ 801 NS Subnet#1 |SLG#1| NS Subnet#2 802 _________ | | ___________ 803 _________/-->| |-->/__________ 804 NS Subnet#3 | | NS Subnet#4 805 | | 806 : | | : 807 +-----+ 809 Figure 9: Overview of vertical connection of SLG: Shared Pattern 811 6.5. Software vs. Hardware 813 An SLG can be created as either a software or hardware function. NSs 814 are virtual networks created depending on requests from external NS 815 tenants, and thus software would be more compatible with usage for 816 NSs in terms of flexibility or manageability. Moreover, it enables 817 to increase or decrease for each function if SLG is composed of 818 combination of several components. However, it is difficult to 819 provide high performance or sufficient throughput for carrier-grade 820 networks with software function. In addition, it would be difficult 821 to implement sufficient QoS control mechanisms with general servers, 822 because they requires special hardware structures. An example of 823 position of SLG in NFV environment is described in Appendix B. 825 On the other hand, hardware appliances are able to provide high 826 throughput compared with software. However, they are inflexible in 827 terms of provisioning. 829 From the above considerations, operators should prepare SLG in 830 appropriate ways depending on their usages or locations. 832 7. Interconnection between NS subnets 834 SLG provides interconnectivity between NS subnets. The concept and 835 fundamental framework including the related NS information model are 836 described in subnets interconnection document 837 ([I-D.defoy-coms-subnet-interconnection]). 839 This section is focused on interconnection between NS subnets 840 established on different administrative domains, and describes 841 considerations related to this condition. 843 7.1. Pre-arrangement of transport protocols 845 For interconnection between different administrative NS subnets, pre- 846 arrangement of the transport protocol, which is used to connect 847 between SLGs is required. Orchestration systems indicate the 848 protocol and configuration to each SLG. 850 7.2. Quality Assurance between SLGs 852 In addition to establishing connection, quality control of 853 communication is important. SLGs of egress side should execute 854 traffic shaping to prevent some NSs from excessively occupying the 855 link between SLGs. Moreover, some SLGs are connected to several 856 other SLGs that are deployed on the different locations. Therefore 857 SLGs of the ingress side should execute traffic policing to avoid 858 excessive inflow of traffic into some NSs. The parameters for these 859 controls are pre-configured by orchestration systems. 861 The above approaches are ones of the simplest ways to provide quality 862 assurance of inter-administrative subnets. If there is stricter 863 isolation request, more considerations would be required. 865 7.3. Secure Interconnection 867 For connecting networks of different administrators, secure 868 interconnection schemes are required. Especially, in an NSaaS, 869 networks might be connected to several networks, and schemes for 870 ensuring secure connectivity would be more important. 872 SLGs confirm whether the opponent SLG is regular when it requests to 873 connect, and reject the request if the SLG is not regular. In some 874 cases, SLGs might be confirm whether the inner packets received from 875 the other SLGs are sent from regular users. 877 8. Security Considerations 879 Requirements and considerations for SLG related to security are 880 described in Section 5 and Section 7. 882 9. IANA Considerations 884 This memo includes no request to IANA. 886 10. Acknowledgement 888 The authors would like to thank Li Qiang for her kind review and 889 valuable feedback. 891 11. Informative References 893 [I-D.defoy-coms-subnet-interconnection] 894 Foy, X., Rahman, A., Galis, A., 895 kiran.makhijani@huawei.com, k., and L. Qiang, 896 "Interconnecting (or Stitching) Network Slice Subnets", 897 draft-defoy-coms-subnet-interconnection-01 (work in 898 progress), October 2017. 900 [I-D.ietf-6man-segment-routing-header] 901 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 902 Field, B., daniel.voyer@bell.ca, d., 903 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 904 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 905 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 906 Header (SRH)", draft-ietf-6man-segment-routing-header-08 907 (work in progress), January 2018. 909 [I-D.ietf-sfc-hierarchical] 910 Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 911 "Hierarchical Service Function Chaining (hSFC)", draft- 912 ietf-sfc-hierarchical-05 (work in progress), November 913 2017. 915 [I-D.ietf-spring-segment-routing-mpls] 916 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 917 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 918 data plane", draft-ietf-spring-segment-routing-mpls-11 919 (work in progress), October 2017. 921 [I-D.netslices-usecases] 922 kiran.makhijani@huawei.com, k., Qin, J., Ravindran, R., 923 Geng, L., Qiang, L., Peng, S., Foy, X., Rahman, A., Galis, 924 A., and G. Fioccola, "Network Slicing Use Cases: Network 925 Customization and Differentiated Services", draft- 926 netslices-usecases-02 (work in progress), October 2017. 928 [I-D.qiang-coms-netslicing-information-model] 929 Qiang, L., Galis, A., 67, 4., kiran.makhijani@huawei.com, 930 k., Martinez-Julia, P., Flinck, H., and X. Foy, 931 "Technology Independent Information Model for Network 932 Slicing", draft-qiang-coms-netslicing-information-model-01 933 (work in progress), October 2017. 935 [NECOS] NECOS, "Novel Enablers for Cloud Slicing", 936 . 938 [NFV-Architectural-Framework] 939 Network Functions Virtualisation (NFV) ETSI Industry 940 Specification Group (ISG), "Network Functions 941 Virtualisation (NFV); Architectural Framework", December 942 2014, . 945 [OSM-White-Paper] 946 ETSI, "OSM White Paper", October 2016, 947 . 950 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 951 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 952 eXtensible Local Area Network (VXLAN): A Framework for 953 Overlaying Virtualized Layer 2 Networks over Layer 3 954 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 955 . 957 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 958 Chaining (SFC) Architecture", RFC 7665, 959 DOI 10.17487/RFC7665, October 2015, 960 . 962 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 963 "Network Service Header (NSH)", RFC 8300, 964 DOI 10.17487/RFC8300, January 2018, 965 . 967 [Slicing_Tutrial] 968 IEEE NetSoft2018, "Network Slicing Landscape- Tutorial", 969 June 2018, 970 . 973 [TS.36.300-3GPP] 974 3rd Generation Partnership Project (3GPP), "3GPP TS 975 36.300", December 2007, 976 . 978 Appendix A. Requirements for each SLG Type 980 The requirements for each SLG type are listed in Figure 10. 982 +---------------++-------+-------+-------+----------------+ 983 | || E-SLG |IS-SLG |ID-SLG | Reference | 984 +=========================================================+ 985 |*Data-Plane of NS as Infrastructure | 986 +=========================================================+ 987 |Identification/|| M | O | O |Section 5.1.1.1.| 988 |Classification || | | | | 989 +---------------++-------+-------+-------+----------------+ 990 |Transport/ || M | O | M |Section 5.1.1.2.| 991 |Forwarding || | | | | 992 +---------------++-------+-------+-------+----------------+ 993 |Isolation || M | M | M |Section 5.1.1.3.| 994 +---------------++-------+-------+-------+----------------+ 995 |Service Chain || O | O | O |Section 5.1.1.4.| 996 +=========================================================+ 997 |*Control/Management-Plane of NS as Infrastructure | 998 +=========================================================+ 999 |IF to Ctrl/OpS || M | M | M |Section 5.1.2.1.| 1000 +---------------++-------+-------+-------+----------------+ 1001 |Addr Resolution|| M | M | M |Section 5.1.2.2.| 1002 |/Routing || | | | | 1003 +---------------++-------+-------+-------+----------------+ 1004 |AAA || M | - | M |Section 5.1.2.3.| 1005 +---------------++-------+-------+-------+----------------+ 1006 |OAM || M | M | M |Section 5.1.2.4.| 1007 +=========================================================+ 1008 |*Data-Plane for Service on NS | 1009 +=========================================================+ 1010 |Identification/|| O | - | O |Section 5.2.1.1.| 1011 |Classification || | | | | 1012 +---------------++-------+-------+-------+----------------+ 1013 |QoS Control || O | O | O |Section 5.2.1.2.| 1014 +---------------++-------+-------+-------+----------------+ 1015 |Steering/ || O | - | O |Section 5.2.1.3.| 1016 |Service Chain || | | | | 1017 +=========================================================+ 1018 |*Control/Management-Plane for Service on NS | 1019 +=========================================================+ 1020 |IF to Service || O | O | O |Section 5.2.2.1.| 1021 |Manager || | | | | 1022 +---------------++-------+-------+-------+----------------+ 1023 |Telemetory || O | O | O |Section 5.2.2.2.| 1024 +---------------++-------+-------+-------+----------------+ 1025 M: Mandatry, O: Optional, - : Not Required 1027 Figure 10: List of Requirements for each SLG 1029 Appendix B. Position of SLG on ETSI NFV MANO 1031 Some SLGs and the controllers are deployed and run on NSs as VNFs. 1032 An arechitecture for managing lifecycle of VNFs is under 1033 standardization in ETS NFV MANO. 1035 The mapping of SLG as a VM into ETSI NFV MANO architecture is 1036 described in Figure 11. In some cases, SLGs are deployed with 1037 containor. VNFs are parts of NS compositions and NFV orchestrator 1038 would be controlled by upper control entities such as resource 1039 orchestrator. 1041 OSS/BSS, Service-Orch, Resource-Orch 1042 | | 1043 | | 1044 +-v-------+ +-v----------+ 1045 |SLG-Ctrl |<-----+ NFV Orch. | 1046 +-+-------+ +-+----------+ 1047 | | 1048 ,-v-------. | 1049 | SLG | | 1050 :=========: +-v----------+ 1051 |VM(GstOS)|<-----+VNF Manager | 1052 `---------' +-+----------+ 1053 +---------+ | 1054 | HostOS/ | +-v----------+ 1055 | Server |<-----| VIM | 1056 +---------+ +------------+ 1058 Figure 11: Position of SLG as a VM on ETSI NFV MANO 1060 Authors' Addresses 1062 Shunsuke Homma 1063 NTT, Corp. 1064 3-9-11, Midori-cho 1065 Musashino-shi, Tokyo 180-8585 1066 Japan 1068 Email: homma.shunsuke@lab.ntt.co.jp 1069 Xavier de Foy 1070 InterDigital Inc. 1071 1000 Sherbrooke West 1072 Montreal 1073 Canada 1075 Email: Xavier.Defoy@InterDigital.com 1077 Alex Galis 1078 University College London 1079 Torrington Place 1080 London WC1E 7JE 1081 United Kingdom 1083 Email: a.galis@ucl.ac.uk