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