none S. Homma Internet-Draft NTT Intended status: Informational X. de Foy Expires: August 4, 2018 InterDigital Inc. January 31, 2018 Gateway Function for Network Slicing draft-homma-coms-slice-gateway-00 Abstract This document describes the roles and requirements for a slice gateway which is a function or function group on the data plane for connecting network slice subnets and providing network slices from end to end. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 4, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Homma & de Foy Expires August 4, 2018 [Page 1] Internet-Draft draft-homma-coms-slice-gateway January 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 4 4. Architecture Overview of NS Management . . . . . . . . . . . 6 5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 8 5.1. Management of NS as Infrastructure . . . . . . . . . . . 8 5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 8 5.1.1.1. Identification/Classification . . . . . . . . . . 8 5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 9 5.1.1.3. Isolation between NSs . . . . . . . . . . . . . . 10 5.1.1.4. Service Chaining as Infrastructural Mechanism(*Optional) . . . . . . . . . . . . . . 10 5.1.2. Control/Management Planes Aspects . . . . . . . . . . 11 5.1.2.1. Interfaces to Controllers or Operation Systems . 11 5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 11 5.1.2.3. Authentication Authorization Accounting (AAA) . . 11 5.1.2.4. Operation Administration and Maintenance(OAM) . . 11 5.2. Management of Services on NS (*Optional) . . . . . . . . 11 5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 11 5.2.1.1. Identification/Classification . . . . . . . . . . 11 5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 12 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 12 5.2.2. Control/Management Planes Aspects . . . . . . . . . . 12 5.2.2.1. Interfaces to Service Management Systems . . . . 12 5.2.2.2. Collection of Telemetry information . . . . . . . 12 6. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Examples of Components Required to Have SLG Functions . . 13 6.2. SLG Types Depending on Locations on NS . . . . . . . . . 13 6.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 13 6.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 13 6.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 13 6.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 13 6.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 16 6.5. Software vs. Hardware . . . . . . . . . . . . . . . . . . 17 7. Interconnection between NS subnets . . . . . . . . . . . . . 17 7.1. Pre-arrangement of transport protocols . . . . . . . . . 17 7.2. Quality Assurance between SLGs . . . . . . . . . . . . . 17 7.3. Secure Interconnection . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 11. Informative References . . . . . . . . . . . . . . . . . . . 18 Appendix A. Position of SLG on ETSI NFV MANO . . . . . . . . . . 20 Appendix B. Requirements for each SLG Type . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Homma & de Foy Expires August 4, 2018 [Page 2] Internet-Draft draft-homma-coms-slice-gateway January 2018 1. Introduction Network slicing is an approach to create virtual networks depending on several requirements on the same physical resources, and it enables networks to adapt to requirements, which is diverse more, inexpensively and flexibly. Network slices are established with combination of various technologies, such as software defined network (SDN), network function virtualization (NFV), or traffic engineering, and managed with automation technologies such as orchestrator. Assumed use cases of network slices include establishment of virtual networks whose qualities are guaranteed from end to end. In such cases, a network slice subnet is created on each domain, such as access network and core network, and such network slices are composed of connected subnets. Network slice subnets are built based on specification of the underlay network, and thus the used technologies might be varied. For example, transporting methods used in access networks and core networks are different. Therefore, a gateway function, which enables to connect subnets with absorbing the differentiations and forward data packets the appropriate next subnet, is required. In this document, the gateway function is called slice gateway or SLG, and the role and requirements are described. 2. Definition of Terms Network Slicing: Network slicing is a technology or an approach to create virtual networks, depending on several requirements, on the same physical resources. This is possible by combinations of several network technologies. Network Slice (NS): An NS is a virtual network established on network infrastructure. Some include additional network functions such as firewall or load-balancer in addition to basically forwarding functions such as switches or routers. It has an overlay architecture and is independent from the underlay network's topology. NS Subnet: An NS subnet is partially virtual network established within a single domain. End-to-End Network Slice (E2E-NS): An E2E-NS is a virtual network connecting between end points. E2E slices are composed of a single NS subnet or multiple NS subnets. Homma & de Foy Expires August 4, 2018 [Page 3] Internet-Draft draft-homma-coms-slice-gateway January 2018 Network Slice as a Service (NSaaS): An NSaaS is a NS distribution model in which a third-party provider hosts NSs and makes them available to customers. Network Slice Tenant (NS Tenant): An NS tenant is a person or group that rents and occupies NSs from NS providers. Domain: A domain is a group of a network and devices administrated as a unit with common rules and procedures. Administrative Domain: An administrative domain is a group of networks and devices managed by an administrator. Resource: A resource is element used to create virtual networks. There are several types of resources, i.e., connectivity, computing and storage. Network Function Virtualization (NFV): NFV is the concept or technologies to provide dedicated network appliances as software. Software Defined Network (SDN): SDN is the concept or technologies to separate network control plane from data plane, and control network devices dynamically and flexibly. Slice Gateway Function (SLG): An SLG is a function or a group of functions to connect NS subnets. The role is described in the following sections. Business Support System and Operation Support System (BSS/OSS): BSS/ OSS are systems to support service providing and operation of network devices. Orchestrator: Orchestrator is an entity to operate network components automatically. There are several types of orchestrators including NFV Orchestrator (NFVO) or Network Service Orchestrator defined by ETSI NFV and Open Source MANO (OSM) ([NFV-Architectural-Framework] and [OSM-White-Paper]). SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls SLGs. An SLG-Ctrl is controlled by upper-level operation systems such as OSS/BSS or orchestrator. 3. Motivations and Roles of SLG Use cases of network slices are discussed in several Standard Developing Organizations (SDOs). Some examples are described in use cases document ([I-D.netslices-usecases]). Homma & de Foy Expires August 4, 2018 [Page 4] Internet-Draft draft-homma-coms-slice-gateway January 2018 In some proposed use cases, an NS is structured across multiple network domains. The capability of NS subnets might be different because the components are domain-specific. In particular, the differentiation in capability between different administrative domains is large. For connecting some different NS subnets and providing a NS that guarantees the prescribed quality from end to end, SLGs are required to connect such NS subnets. SLGs enable to provide E2E-NSs independently of specifications of underlay networks by hiding the differentiations and connecting between NS subnets. An overview of this concept is shown in Figure 1. SLGs glue NS subnets established on each domain and provide an E2E-NS. E2E-NS ________________________A_________________________ / \ _____________ ____________ _________________ / // / / / end +---+ NS +---+ NS +---+ +---+ NS ,------. host==>|SLG| Subnet |SLG| Subnet |SLG+-+SLG| Subnet( Server ) +---+ #1 +---+ #2 +---+ +---+ #3 `------' /____________//___________/ /________________/ /____________//___________/ /________________/ : : : : : : .--. .--. .--. ( )-. ( )-. ( )-. .' Access ' .' Core ' .' Data ' ( Network ) ( Network ) ( Center ) ( -' ( -' ( -' '-( ) '-( ) '-( ) '---' '---' '---' \______ ______/ \_____ _____/ \________ ________/ V V V Domain#1 Domain#2 Domain#3 \_____________ _____________/ \________ ________/ V V Domain of Administrator#A Domain of Administrator#B Figure 1: E2E-NS composed of multiple NS subnets Homma & de Foy Expires August 4, 2018 [Page 5] Internet-Draft draft-homma-coms-slice-gateway January 2018 Moreover, identification of user traffic and their assignment to the appropriate NS subnet are required at the edges of E2E-NSs, as shown in Figure 2, and SLGs might take on these roles. +-----+ _______________ end | |-->/_______________ host ====>| SLG | NS Subnet#1 |@Edge| _______________ | |-->/______________ | | NS Subnet#2 | | : : +-----+ Figure 2: NS subnet selection of SLG Note that, this model has the assumption that transitions of data packets from one NS subnet to another are executed at only SLGs. Also, an SLG is not necessarily implemented as a single device or virtual machine (VM). 4. Architecture Overview of NS Management The architecture overview of NS management system is shown in Figure 3. Orchestrators manage whole resources including network elements and server resources (i.e., routing, bandwidth, compute or storage). In this figure the resources of each domain are managed by domain orchestrators and the E2E-orchestrator and network service orchestrator handle domain orchestrators. NSs are requested from NS tenants via the portal system and the order of creations of an NS is given to the E2E orchestrator from the portal system via BSS/OSS. When an NS across multiple administrative domains are requested, the portal system that received the request forwards the order to create NS subnets to the other infrastructure providers' systems via Cross-Segment Slice Manager. The details of COMS architecture are described in the architecture document ([I- D.qiang-coms-architecture]). SLGs are also controlled via orchestrators. An SLG basically belongs to a network element, and it might also belong to server resource if it runs as a VM. (An example of position of SLG deployed as a VM is shown in Appendix A.) SLGs are located at the edges of each NS subnet. They translate data packets into the appropriate form and send them to the next NS subnet. SLGs located at the end of E2E-NSs additionally provide Homma & de Foy Expires August 4, 2018 [Page 6] Internet-Draft draft-homma-coms-slice-gateway January 2018 identification of data packets and select the assigned NS subnet based on the identification result. The information model used in this architecture is described in information model document ([I-D.qiang-coms-netslicing-information-model]). NS Tenant | . .|. . . . . . . . . . . . . . . . . . . . . . +-v---------+ . . |Portal/GUI +--+ . . +-+---------+ | . . . . . . . . . . . | +-v-------------------+ . . +------------+ . . | |CSS-Mngr./TNS-Orch. |4----------->|CSS-M/TNS-O | . . | +-+-------+-----------+ . . +-+--------+-+ . . | | | . . | | . . +-v-----+ | | . . +-v-----+ | . . |BSS/OSS|4-----+ | . . |BSS/OSS| | . . +-+-----+ | . . +-+-----+ | . . | | . . | | . . +-v--------------------v-----------+ . . +-v--------v-+ . . | E2E-Orch./Network Service-Orch. | . . |E2E-O/NS-O | . . +-+--------------------+-----------+ . . +-+--------+-+ . . | | . . | | . . +-v----------------+ +-v----------------+ . . : . . | Domain Orch.#1 | | Domain Orch.#2 |.. . . . . . . . . . . . +-+---------+------+ +-+---------+------+ . Administrative . | | | | . Domain#2 . +-v------++-v------+ +-v------++-v------+ . . |Network ||NFV | |Network ||NFV | . . |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | . . +-+------++-+------+ +-+------++-+------+ . . | | | | . . +-v------++-v------+ +-v------++-v------+ . . |Network ||Server | |Network ||Server | . . |Elements||Resource| |Elements||Resource|.. . . |in ||in | |in ||in | . . |Domain#1||Domain#1| |Domain#2||Domain#2| . . +--------++--------+ +--------++--------+ . . . . . . . . . . . . . . . . . . . . . . . . Administrative Domain#1 CSS-Mngr./CSS-M:Cross-Segment Slice Manager TNS-Orch./TNS-O:Transport Network Slice Orchestrator Figure 3: Overview of NS Management Architecture Homma & de Foy Expires August 4, 2018 [Page 7] Internet-Draft draft-homma-coms-slice-gateway January 2018 5. Requirements for SLG An SLG is basically a component in the data plane and has the roles of data packet processing. Moreover, it is required to have functions for control/management processes such as connecting to underlay networks or managing NSs. Furthermore, an SLG might be required to support handling services provided on NSs in addition to controlling of NS because an SLG is an edge node on an E2E-NS. In this section, we describe the requirements for an SLG in terms of the following aspects. 1. Data plane for NSs as infrastructure 2. Control/management plane for NSs as infrastructure 3. Data plane for services on NSs 4. Control/management plane for services on NSs 5.1. Management of NS as Infrastructure 5.1.1. Data Plane Aspect 5.1.1.1. Identification/Classification SLGs at the edge of E2E-NSs MUST have the capability to identify and classify data packets, and assign them to the appropriate E2E-NS. This requirement varies depending on the location. Fixed Access: An SLG MUST identify and classify data packet with access point, including CPE or WiFi-AP, or subscriber ID such as VLAN-ID. Moreover, in some services, an SLG should identify and classify data packets based on user device or application used in the communication. Mobile Access: An SLG MUST identify and classify data packet with subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of tunnels. Moreover, in some services, an SLG should identify and classify data packets based on application used in the communication or location of the user equipment (UE). Between NS subnets: An SLG MUST identify and classify data packet based on the tunnel-ID or virtual routing and forwarding (VRF) that received the packets. If specific slice identifier such as a Homma & de Foy Expires August 4, 2018 [Page 8] Internet-Draft draft-homma-coms-slice-gateway January 2018 value mapped in the metadata field of the IP header is used, an SLG should identify and classify data packets with the ID. 5.1.1.2. Transporting/Forwarding SLGs MUST provide functions for transport data packets depending on the specifications of the underlay networks. Encapsulation/Decapsulation/Tagging: In network slicing, duplication of IP addresses of user packets between NSs MUST be accepted, thus, using techniques that enable separation of a network logically is preferred. In short, some tunnel protocols or tagging approaches should be used as transport of NSs. For this reason, SLG MUST support encapsulation or tagging of data packets based on the specification of the underlay network. Also, SLG MUST support the packets' decapsulation or untagging. Examples of tunnel protocols and tags that can be used for creating NSs on L2/ L3 segments are described below. L2 Segment: VLAN, MPLS, Segment Routing MPLS (SR-MPLS), PPPoE, etc. L3 Segment: GRE, L2TP, GTP-U, VxLAN, IPv6 Segment Routing (SRv6), etc. VxLAN, SR-MPLS, and SRv6 are described in their specification documents ([RFC7348], [I-D.ietf-spring-segment-routing-mpls], and [I-D.ietf-6man-segment-routing-header]). Translation of Encapsulation/Tagging Form: SLG MUST support to translate tunnel header or tag of received packets to the appropriate tunnel header or tag when it forwards data packets to the next NS subnet that has different transport capability. Distribution of Traffic: Some NSs have multiple route between the same end points within the same NS subnet because of traffic engineering, switching to a redundant path, or other reasons, and SLG MAY forward data packets with the appropriate route based on some trigger information. An example of the overview of this requirement is shown in Figure 4. In this figure, there are two routes, main and sub, between SLGs, and an SLG switches forwarding route depending on the network situation such as congestion occurrence on the current route. Homma & de Foy Expires August 4, 2018 [Page 9] Internet-Draft draft-homma-coms-slice-gateway January 2018 ____________________________ / . . . . . / +-----+ . . +-----+ | |. . . .| | | SLG | | SLG | | |* * * *| | +-----+ * * +-----+ / * * * * * / /___________________________/ NS Subnet *** : Main-route ... : Sub-route Figure 4: An example of traffic distribution by SLG 5.1.1.3. Isolation between NSs In NSaaS, isolation control is required for avoiding an NS being affect by other NSs. Traffic engineering or QoS control is ones of the most fundamental approaches to prevent disturbances between NSs. Traffic Shaping/Policing: An SLG MUST execute traffic shaping and policing at its egress and ingress ports to avoid an NS using excessive traffic bandwidth. Quality of service (QoS) Control: If there is an order of priority between NSs on the same underlay infrastructure, an SLG should remark the appropriate QoS parameter of the outer-most header of each packet following the preconfigured setting and provide packet scheduling based on the QoS parameter for providing priority control. The field that SLG refers may vary depending on the specification of the underlay network. For example, COS value is remarked in L2 segments; on the other hand, DSCP value is remarked in L3 segments. 5.1.1.4. Service Chaining as Infrastructural Mechanism(*Optional) If an SLG is composed of a combination of several components, a service chaining mechanism is required to make them work together and achieve SLG functionality. Moreover, some NSs may traverse NFVs such as firewalls or cache servers for providing value-added services to their users. In such cases, SLG might be required to support service chaining mechanisms, such as handling of network service header (NSH) defined in [RFC8300]. If an NS includes the service chaining architecture defined in [RFC7665], some SLG would be required to support following Homma & de Foy Expires August 4, 2018 [Page 10] Internet-Draft draft-homma-coms-slice-gateway January 2018 functions; classifier(CF), service function forwarder (SFF), and inter boundary node(IBN). (Details of CF, SFF and IBN are described in SFC documents; [RFC7665], [I-D.ietf-sfc-hierarchical].) 5.1.2. Control/Management Planes Aspects 5.1.2.1. Interfaces to Controllers or Operation Systems SLG MUST have interface to its controller or operation systems for set parameters related to the data plane functions described in Section 5.1.1. In addition, an SLG at the edges of E2E-NSs MUST have interfaces to authentication servers. 5.1.2.2. Address Resolution/Routing An SLG MUST support address resolution or routing mechanisms to connect to underlay network elements including routers or L2 switches. 5.1.2.3. Authentication Authorization Accounting (AAA) For preventing entry of irregular traffic to NSs, an SLG at the edge of E2E-NS MUST support AAA mechanism for incoming traffic. Also, when an SLG connects to another SLG in other administrative domain, SLGs should have a mechanism to confirm that the connection is established with the regular processes. For example, an SLG is required to support authentication of the opponent SLG with key information indicated from higher-level operation systems. 5.1.2.4. Operation Administration and Maintenance(OAM) In management of NSs, OAM or monitoring mechanisms for both underlay and overlay networks is required for SLGs. For an underlay network, an SLG MUST have OAM functions to confirm connectivity to interconnect equipment. For an overlay network, an SLG MUST have OAM functions to confirm connectivity to the some node on the same NS, and measure the traffic amount of flowing packets on each NS. 5.2. Management of Services on NS (*Optional) 5.2.1. Data Plane Aspect 5.2.1.1. Identification/Classification In NSaaS, some NS tenants may need delivery of an individual service to each user, device, or application on the same NS. For such service deliveries, an SLG might be required to identify and classify user traffic based on some information such as subscriber ID or Homma & de Foy Expires August 4, 2018 [Page 11] Internet-Draft draft-homma-coms-slice-gateway January 2018 payload of data packets. Also, an SLG should be controllable from the NS tenant. 5.2.1.2. QoS Control An NS accommodates several communication devices and SLGs might be required to have fair queueing mechanisms for maintaining service quality of each user. Also, different types of service traffic that have different priorities might coexist on an NS. For example, some NS providers might provide telephone and internet access services to their users with an NS. In such cases, SLG might be required to provide QoS control mechanisms for enforcing priority control based on service priorities. These QoS controls are executed depending on the information of inner packets and are independent of isolation mechanisms as infrastructure. An SLG might be required to have a hierarchical QoS control mechanism in case that both QoS controls for services over NSs and isolation between NSs are required. 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) SLG might be required to support steering or service chaining function for conveying data packets to the appropriate network functions deployed on an NS based on the classification result and user's contract information. 5.2.2. Control/Management Planes Aspects 5.2.2.1. Interfaces to Service Management Systems An SLG might have interfaces to controllers for managing user policies on each NS. Some controllers might be deployed on the same NS. If some controllers are located at external networks, they might require SLGs to have APIs. 5.2.2.2. Collection of Telemetry information In an NSaaS, collection of telemetry information of each NS might be required for understanding traffic usage. Thus, an SLG might be required to support to collect and repoet telemetry information of connected NSs. 6. Deployment of SLG This section describes considerations related with deployment of SLGs. Homma & de Foy Expires August 4, 2018 [Page 12] Internet-Draft draft-homma-coms-slice-gateway January 2018 6.1. Examples of Components Required to Have SLG Functions For providing E2E-NSs on existing network infrastructures, some components located at boundaries of domains are required to have the same set of functionality as an SLG. Examples of such components in each domain type are described below. Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc. Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW ([LTE-Specs]), etc. Data Center: Gateway Router, L2 switch, ToR switch, Server, etc. 6.2. SLG Types Depending on Locations on NS There are mainly three types of SLG for creating E2E-NS across multiple administrative domains. The requirements of each SLG type are listed in Appendix B. 6.2.1. Edge SLG(E-SLG) This is located at an edge of an E2E-NS, and supports identification, classification and authentication of user traffic in addition to fundamental SLG functions, such as transport and isolation. Also, it might be required to have capabilities for services delivered on an NS. 6.2.2. Inter-Subnet SLG(IS-SLG) This is located between NS subnets within a single administrative domain and has only fundamental functions. It is not necessarily required if a common transport mechanism in all domains is used. 6.2.3. Inter-Domain SLG(ID-SLG) This is located between NS subnets established on different domains. It supports authentication for connecting to the opponent SLG in addition to fundamental functions. 6.3. Horizontal Connection The connection form of an SLG varies depending on which type it is. Examples of horizontal connection forms of each SLG type are described below. E-SLG: An E-SLG accommodates several hosts and NS subnets. This has a forwarding table of end hosts and insert their packets to the Homma & de Foy Expires August 4, 2018 [Page 13] Internet-Draft draft-homma-coms-slice-gateway January 2018 appropriate NS subnet. An overview of this connection is shown in Figure 5. *Virtual Layer* +-----+ host#1 ====>| | _______________ | |-->/_______________ host#2 ====>|E-SLG| NS Subnet#1 | | _______________ host#3 ====>| |-->/_______________ | | NS Subnet#2 : : | | : : +-----+ //////////////////////////////////////// *Physical Layer* ,-------------------- [UE#1] -----\ / [UE#2] -----[Edge] Domain#1 [UE#3] -----/ \ : : `------------------- Edge: Edge Node Figure 5: Overview of horizontal connection of E-SLG IS-SLG: An IS-SLG has the role of mediator between NS subnets and passes packets received from an NS subnet to the next one. If transport methods used in each domain are different, the IS-SLG translate packet form to the appropriate one. An overview of this connection is shown in Figure 6. Homma & de Foy Expires August 4, 2018 [Page 14] Internet-Draft draft-homma-coms-slice-gateway January 2018 *Virtual Layer* +------+ _________ | | ___________ _________/-->|IS-SLG|--> /__________ NS Subnet#1 | | NS Subnet#2 +------+ /////////////////////////////////////// *Physical Layer* --------------. ,-------------- \ / Domain#1 [ GW ] Domain#2 / \ --------------' `-------------- GW: Gateway Node Figure 6: Overview of horizontal connection of IS-SLG ID-SLG: An ID-SLG passes data packets to another ID-SLG located on a different administrative domain. Some tunnel established between them in advance may be used for the passing of packets. An overview of this connection is shown in Figure 7. *Virtual Layer* +------+ +------+ _________ | | ______ | | ___________ _________/-->|ID-SLG|O______)|ID-SLG|-->/__________ NS Subnet#1 | | Tunnel | | NS Subnet#2 +------+ +------+ /////////////////////////////////////////////////////// *Physical Layer* --------------------. ,------------------- Administrative \ / Administrative Domain#1 [ GW ]---[ GW ] Domain#2 / \ --------------------' `------------------- GW: Gateway Node Figure 7: Overview of horizontal connection of ID-SLG Homma & de Foy Expires August 4, 2018 [Page 15] Internet-Draft draft-homma-coms-slice-gateway January 2018 6.4. Vertical Connection There are two patterns of vertical connection of SLGs in the middle of E2E-NSs. The first pattern is that the SLGs accommodate only a set of NS subnets which are composition of the same E2E-NS. In this pattern, such SLGs are not required to support NS subnet selection, however, establishment of a new SLG is required when a new E2E-NS is created. This might causes extra overheads because of deploying many SLGs. The other pattern is that such SLGs are acceptable to accommodate multiple NS subnets from each domain. In this pattern, SLGs are support NS subnet selection. On the other hand, this pattern can restrain the number of SLGs. Also, it is easy to provide transit of data packets from an NS subnet to other subnet on the same domain. The overviews of these patterns are shown in Figure 8 and Figure 9. +-----+ _________ | | ___________ _________/-->|SLG#1|-->/__________ NS Subnet#1 | | NS Subnet#2 +-----+ +-----+ _________ | | ___________ _________/-->|SLG#2|-->/__________ NS Subnet#3 | | NS Subnet#4 +-----+ : : : Figure 8: Overview of vertical connection of SLG: Separated Pattern +-----+ _________ | | ___________ _________/-->| |-->/__________ NS Subnet#1 |SLG#1| NS Subnet#2 _________ | | ___________ _________/-->| |-->/__________ NS Subnet#3 | | NS Subnet#4 | | : | | : +-----+ Figure 9: Overview of vertical connection of SLG: Shared Pattern Homma & de Foy Expires August 4, 2018 [Page 16] Internet-Draft draft-homma-coms-slice-gateway January 2018 6.5. Software vs. Hardware An SLG can be created as either a software or hardware function. NSs are virtual networks created depending on requests from external NS tenants, and thus software would be more compatible with usage for NSs in terms of flexibility or manageability. Moreover, it enables to increase or decrease for each function if SLG is composed of combination of several components. However, it is difficult to provide high performance or sufficient throughput for carrier-grade networks with software function. In addition, it would be difficult to implement sufficient QoS control mechanisms with general servers, because they requires special hardware structures. On the other hand, hardware appliances are able to provide high throughput compared with software. However, they are inflexible in terms of provisioning. From the above considerations, operators should prepare SLG in appropriate ways depending on their usages or locations. 7. Interconnection between NS subnets SLG provides interconnectivity between NS subnets. The concept and fundamental framework including the related NS information model are described in subnets interconnection document ([I-D.defoy-coms-subnet-interconnection]). This section is focused on interconnection between NS subnets established on different administrative domains, and describes considerations related to this condition. 7.1. Pre-arrangement of transport protocols For interconnection between different administrative NS subnets, pre- arrangement of the transport protocol which is used to connect between SLGs is required. Orchestration systems indicate the protocol and configuration to each SLG. 7.2. Quality Assurance between SLGs In addition to establishing connection, quality control of communication is important. SLGs of egress side should execute traffic shaping to prevent some NSs from excessively occupying the link between SLGs. Moreover, some SLGs are connected to several other SLGs that are deployed on the different locations. Therefore SLGs of the ingress side should execute traffic policing to avoid excessive inflow of traffic into some NSs. The parameters for these controls are pre-configured by orchestration systems. Homma & de Foy Expires August 4, 2018 [Page 17] Internet-Draft draft-homma-coms-slice-gateway January 2018 The above approaches are ones of the simplest ways to provide quality assurance of inter-administrative subnets. If there is stricter isolation request, more considerations would be required. 7.3. Secure Interconnection For connecting networks of different administrators, secure interconnection schemes are required. In particular, in an NSaaS, networks might be connected to several networks and schemes for ensuring secure connectivity. SLGs confirm whether the opponent SLG is regular when it requests to connect, and reject the request if the SLG is not regular. In some cases, SLGs might be confirm whether the inner packets received from the other SLGs are sent from regular users. 8. Security Considerations Requirements and considerations for SLG related to security are described in Section 5 and Section 7. 9. IANA Considerations This memo includes no request to IANA. 10. Acknowledgement The authors would like to thank Li Qiang for her reviews and comments. 11. Informative References [I-D.defoy-coms-subnet-interconnection] Foy, X., Rahman, A., Galis, A., kiran.makhijani@huawei.com, k., and L. Qiang, "Interconnecting (or Stitching) Network Slice Subnets", draft-defoy-coms-subnet-interconnection-01 (work in progress), October 2017. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-08 (work in progress), January 2018. Homma & de Foy Expires August 4, 2018 [Page 18] Internet-Draft draft-homma-coms-slice-gateway January 2018 [I-D.ietf-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", draft- ietf-sfc-hierarchical-05 (work in progress), November 2017. [I-D.ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-11 (work in progress), October 2017. [I-D.netslices-usecases] kiran.makhijani@huawei.com, k., Qin, J., Ravindran, R., 67, 4., Qiang, L., Peng, S., Foy, X., Rahman, A., Galis, A., and G. Fioccola, "Network Slicing Use Cases: Network Customization and Differentiated Services", draft- netslices-usecases-02 (work in progress), October 2017. [I-D.qiang-coms-netslicing-information-model] Qiang, L., Galis, A., 67, 4., kiran.makhijani@huawei.com, k., Martinez-Julia, P., Flinck, H., and X. Foy, "Technology Independent Information Model for Network Slicing", draft-qiang-coms-netslicing-information-model-01 (work in progress), October 2017. [LTE-Specs] 3rd Generation Partnership Project (3GPP), "3GPP TS 36.300", December 2007, . [NFV-Architectural-Framework] Network Functions Virtualisation (NFV) ETSI Industry Specification Group (ISG), "Network Functions Virtualisation (NFV); Architectural Framework", Decenber 2014, . [OSM-White-Paper] ETSI, "OSM White Paper", October 2016, . Homma & de Foy Expires August 4, 2018 [Page 19] Internet-Draft draft-homma-coms-slice-gateway January 2018 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . Appendix A. Position of SLG on ETSI NFV MANO The mapping of SLG as a VM into ETSI NFV MANO architecture is described in Figure 10. +---------------------------+ | BSS/OSS, Orchestrator | +-+---------------+---------+ | | +-v------+ +-v---------+ |SLG-Ctrl| | NFV Orch. | +-+------+ +-+---------+ | | ,-v------. | | SLG | | :========: +-v---------+ | VM |4-----+ VNF Mngr. | `--------' +-+---------+ +--------+ | |HostOS/ | +-v---------+ |Server |4-----+ VIM | +--------+ +-----------+ Figure 10: Position of SLG as a VM on ETSI NFV MANO Appendix B. Requirements for each SLG Type The requirements for each SLG type are listed in Figure 11. Homma & de Foy Expires August 4, 2018 [Page 20] Internet-Draft draft-homma-coms-slice-gateway January 2018 +---------------++-------+-------+-------+----------------+ | || E-SLG |IS-SLG |ID-SLG | Reference | +=========================================================+ |*Data-Plane of NS as Infrastructure | +=========================================================+ |Identification/|| M | O | O |Section 5.1.1.1.| |Classification || | | | | +---------------++-------+-------+-------+----------------+ |Transport/ || M | O | M |Section 5.1.1.2.| |Forwarding || | | | | +---------------++-------+-------+-------+----------------+ |Isolation || M | M | M |Section 5.1.1.3.| +---------------++-------+-------+-------+----------------+ |Service Chain || O | O | O |Section 5.1.1.4.| +=========================================================+ |*Control/Management-Plane of NS as Infrastructure | +=========================================================+ |IF to Ctrl/OpS || M | M | M |Section 5.1.2.1.| +---------------++-------+-------+-------+----------------+ |Addr Resolution|| M | M | M |Section 5.1.2.2.| |/Routing || | | | | +---------------++-------+-------+-------+----------------+ |AAA || M | - | M |Section 5.1.2.3.| +---------------++-------+-------+-------+----------------+ |OAM || M | M | M |Section 5.1.2.4.| +=========================================================+ |*Data-Plane for Service on NS | +=========================================================+ |Identification/|| O | - | O |Section 5.2.1.1.| |Classification || | | | | +---------------++-------+-------+-------+----------------+ |QoS Control || O | O | O |Section 5.2.1.2.| +---------------++-------+-------+-------+----------------+ |Steering/ || O | - | O |Section 5.2.1.3.| |Service Chain || | | | | +=========================================================+ |*Control/Management-Plane for Service on NS | +=========================================================+ |IF to Service || O | O | O |Section 5.2.2.1.| |Manager || | | | | +---------------++-------+-------+-------+----------------+ |Telemetory || O | O | O |Section 5.2.2.2.| +---------------++-------+-------+-------+----------------+ M: Mandatry, O: Optional, - : Not Required Figure 11: List of Requirements for each SLG Homma & de Foy Expires August 4, 2018 [Page 21] Internet-Draft draft-homma-coms-slice-gateway January 2018 Authors' Addresses Shunsuke Homma NTT, Corp. 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan Email: homma.shunsuke@lab.ntt.co.jp Xavier de Foy InterDigital Inc. 1000 Sherbrooke West Montreal Canada Email: Xavier.Defoy@InterDigital.com Homma & de Foy Expires August 4, 2018 [Page 22]