< draft-homma-coms-slice-gateway-00.txt   draft-homma-coms-slice-gateway-01.txt >
none S. Homma none S. Homma
Internet-Draft NTT Internet-Draft NTT
Intended status: Informational X. de Foy Intended status: Informational X. de Foy
Expires: August 4, 2018 InterDigital Inc. Expires: September 6, 2018 InterDigital Inc.
January 31, 2018 A. Galis
University College London
March 5, 2018
Gateway Function for Network Slicing Gateway Function for Network Slicing
draft-homma-coms-slice-gateway-00 draft-homma-coms-slice-gateway-01
Abstract Abstract
This document describes the roles and requirements for a slice This document describes the roles and requirements for a slice
gateway which is a function or function group on the data plane for gateway that is a data plane function or function group for
connecting network slice subnets and providing network slices from connecting/disconnecting and compose/decompose network slice subnets
end to end. and providing network slices from end to end. The interworkings
between management and control elements at the management and control
planes with the gateway function for controlling and orchestrating
end-to-end network slices are also presented in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 4 3. Motivations and Roles of SLG . . . . . . . . . . . . . . . . 5
4. Architecture Overview of NS Management . . . . . . . . . . . 6 4. Architecture Overview of NS Management . . . . . . . . . . . 8
5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 8 5. Requirements for SLG . . . . . . . . . . . . . . . . . . . . 9
5.1. Management of NS as Infrastructure . . . . . . . . . . . 8 5.1. Management of NS as Infrastructure . . . . . . . . . . . 10
5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 8 5.1.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 10
5.1.1.1. Identification/Classification . . . . . . . . . . 8 5.1.1.1. Identification/Classification . . . . . . . . . . 10
5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 9 5.1.1.2. Transporting/Forwarding . . . . . . . . . . . . . 10
5.1.1.3. Isolation between NSs . . . . . . . . . . . . . . 10 5.1.1.3. Isolation between NSs . . . . . . . . . . . . . . 12
5.1.1.4. Service Chaining as Infrastructural 5.1.1.4. Service Chaining as Infrastructural
Mechanism(*Optional) . . . . . . . . . . . . . . 10 Mechanism(*Optional) . . . . . . . . . . . . . . 12
5.1.2. Control/Management Planes Aspects . . . . . . . . . . 11 5.1.2. Control/Management Planes Aspects . . . . . . . . . . 13
5.1.2.1. Interfaces to Controllers or Operation Systems . 11 5.1.2.1. Interfaces to Controllers or Operation Systems . 13
5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 11 5.1.2.2. Address Resolution/Routing . . . . . . . . . . . 13
5.1.2.3. Authentication Authorization Accounting (AAA) . . 11 5.1.2.3. Authentication Authorization Accounting (AAA) . . 13
5.1.2.4. Operation Administration and Maintenance(OAM) . . 11 5.1.2.4. Operation Administration and Maintenance(OAM) . . 13
5.2. Management of Services on NS (*Optional) . . . . . . . . 11 5.2. Management of Services on NS (*Optional) . . . . . . . . 13
5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 11 5.2.1. Data Plane Aspect . . . . . . . . . . . . . . . . . . 13
5.2.1.1. Identification/Classification . . . . . . . . . . 11 5.2.1.1. Identification/Classification . . . . . . . . . . 13
5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 12 5.2.1.2. QoS Control . . . . . . . . . . . . . . . . . . . 14
5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 12 5.2.1.3. Steering/Service Chaining(Cooperation with VNFs) 14
5.2.2. Control/Management Planes Aspects . . . . . . . . . . 12 5.2.2. Control/Management Planes Aspects . . . . . . . . . . 14
5.2.2.1. Interfaces to Service Management Systems . . . . 12 5.2.2.1. Interfaces to Service Management Systems . . . . 14
5.2.2.2. Collection of Telemetry information . . . . . . . 12 5.2.2.2. Collection of Telemetry information . . . . . . . 14
6. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 12 6. Deployment of SLG . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Examples of Components Required to Have SLG Functions . . 13 6.1. Examples of Components Required to Maintain SLG Functions 15
6.2. SLG Types Depending on Locations on NS . . . . . . . . . 13 6.2. SLG Types Depending on Locations on NS . . . . . . . . . 15
6.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 13 6.2.1. Edge SLG(E-SLG) . . . . . . . . . . . . . . . . . . . 15
6.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 13 6.2.2. Inter-Subnet SLG(IS-SLG) . . . . . . . . . . . . . . 15
6.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 13 6.2.3. Inter-Domain SLG(ID-SLG) . . . . . . . . . . . . . . 15
6.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 13 6.3. Horizontal Connection . . . . . . . . . . . . . . . . . . 15
6.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 16 6.4. Vertical Connection . . . . . . . . . . . . . . . . . . . 18
6.5. Software vs. Hardware . . . . . . . . . . . . . . . . . . 17 6.5. Software vs. Hardware . . . . . . . . . . . . . . . . . . 19
7. Interconnection between NS subnets . . . . . . . . . . . . . 17 7. Interconnection between NS subnets . . . . . . . . . . . . . 19
7.1. Pre-arrangement of transport protocols . . . . . . . . . 17 7.1. Pre-arrangement of transport protocols . . . . . . . . . 19
7.2. Quality Assurance between SLGs . . . . . . . . . . . . . 17 7.2. Quality Assurance between SLGs . . . . . . . . . . . . . 19
7.3. Secure Interconnection . . . . . . . . . . . . . . . . . 18 7.3. Secure Interconnection . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
11. Informative References . . . . . . . . . . . . . . . . . . . 18 11. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Position of SLG on ETSI NFV MANO . . . . . . . . . . 20 Appendix A. Position of SLG on ETSI NFV MANO . . . . . . . . . . 22
Appendix B. Requirements for each SLG Type . . . . . . . . . . . 20 Appendix B. Requirements for each SLG Type . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Network slicing is an approach to create virtual networks depending Network slicing is an approach to create separate virtual networks in
on several requirements on the same physical resources, and it support of service depending on several requirements on the same
enables networks to adapt to requirements, which is diverse more, physical resources, and it enables networks to adapt to requirements,
inexpensively and flexibly. which is diverse more, inexpensively and flexibly. It's also
expected to enhance usability of infrastructural networks for tenants
and create new business opportunities. For example, by using network
slices lent from infrastructure operators, other industrial companies
can provide communication services including ensurance of network
transport without having physical infrastructure.
From a business point of view, a slice includes a combination of all
the relevant network resources, functions, and assets required to
fulfill a specific business case or service, including OSS, BSS and
DevOps processes.
From the network infrastructure point of view, network slice requires
the partitioning and assignment of a set of resources that can be
used in an isolated, disjunctive or non- disjunctive manner for that
slice.
From the tenant point of view, network slice provides different
capabilities, specifically in terms of their management and control
capabilities, and how much of them the network service provider hands
over to the slice tenant. As such there are two kinds of slices: (A)
Inner slices, understood as the partitions used for internal services
of the provider, retaining full control and management of them. (B)
Outer slices, being those partitions hosting customer services,
appearing to the customer as dedicated networks.
Network slices are established with combination of various Network slices are established with combination of various
technologies, such as software defined network (SDN), network technologies, such as software defined network (SDN), network
function virtualization (NFV), or traffic engineering, and managed function virtualization (NFV), or traffic engineering, and managed/
with automation technologies such as orchestrator. operated with automation technologies such as orchestrator.
Assumed use cases of network slices include establishment of virtual Assumed use cases of network slices include establishment of virtual
networks whose qualities are guaranteed from end to end. In such networks whose qualities are guaranteed from end to end under the
cases, a network slice subnet is created on each domain, such as supervision of multi-domain orchstrators. In such cases, a network
access network and core network, and such network slices are composed slice subnet is created on each domain, such as access network and
of connected subnets. core network, and such network slices are composed of connected
subnets.
Network slice subnets are built based on specification of the Network slice subnets are built based on specification of the
underlay network, and thus the used technologies might be varied. underlay network, and thus the used technologies might vary.
For example, transporting methods used in access networks and core Therefore, a gateway function, which enables to connect subnets while
networks are different. Therefore, a gateway function, which enables adapting the differentiations and forward data packets to/from the
to connect subnets with absorbing the differentiations and forward appropriate next subnet, is required. Defining a new data plane
data packets the appropriate next subnet, is required. technology is not a goal of this draft. This draft aims to specify
management-related requirements for an SLG, which may be implemented
using existing data plane technologies.
In this document, the gateway function is called slice gateway or In this document, the gateway function is called slice gateway or
SLG, and the role and requirements are described. SLG, and the role and requirements are described.
2. Definition of Terms 2. Definition of Terms
Network Slicing: Network slicing is a technology or an approach to Network Slicing: Network slicing is a technology or an approach to
create virtual networks, depending on several requirements, on the create separate virtual networks in support of services, depending
same physical resources. This is possible by combinations of on several requirements, on the same physical resources. This is
several network technologies. possible by combinations of several network technologies.
Network Slice (NS): An NS is a virtual network established on Network Slice (NS): An NS is a virtual network established on
network infrastructure. Some include additional network functions network infrastructure. Some include additional network functions
such as firewall or load-balancer in addition to basically such as firewall or load-balancer in addition to basically
forwarding functions such as switches or routers. It has an forwarding functions such as switches or routers. It has an
overlay architecture and is independent from the underlay overlay architecture and is independent from the underlay
network's topology. network's topology.
NS Subnet: An NS subnet is partially virtual network established NS Subnet: An NS subnet is partially virtual network established
within a single domain. within a single domain.
skipping to change at page 4, line 29 skipping to change at page 5, line 16
There are several types of resources, i.e., connectivity, There are several types of resources, i.e., connectivity,
computing and storage. computing and storage.
Network Function Virtualization (NFV): NFV is the concept or Network Function Virtualization (NFV): NFV is the concept or
technologies to provide dedicated network appliances as software. technologies to provide dedicated network appliances as software.
Software Defined Network (SDN): SDN is the concept or technologies Software Defined Network (SDN): SDN is the concept or technologies
to separate network control plane from data plane, and control to separate network control plane from data plane, and control
network devices dynamically and flexibly. network devices dynamically and flexibly.
Virtual Network: A virtual network is a network running a number of
virtual network functions.
Virtual Network Function (VNF): A virtual network function (VNF) is
a network function whose functional software is decoupled from
hardware. One or more virtual machines running different software
and processes on top of industry-standard high-volume servers,
switches and storage, or cloud computing infrastructure, and
capable of implementing network functions traditionally
implemented via custom hardware appliances and middleboxes (e.g.,
router, NAT, firewall, load balancer, etc.)
Slice Gateway Function (SLG): An SLG is a function or a group of Slice Gateway Function (SLG): An SLG is a function or a group of
functions to connect NS subnets. The role is described in the functions to connect/disconnect NS subnets. The role is described
following sections. in the following sections.
Business Support System and Operation Support System (BSS/OSS): BSS/ Business Support System and Operation Support System (BSS/OSS): BSS/
OSS are systems to support service providing and operation of OSS are systems to support service providing and operation of
network devices. network devices.
Orchestrator: Orchestrator is an entity to operate network Orchestrator: Orchestrator is an entity to operate network
components automatically. There are several types of components automatically. There are several types of
orchestrators including NFV Orchestrator (NFVO) or Network Service orchestrators including NFV Orchestrator (NFVO) or service
Orchestrator defined by ETSI NFV and Open Source MANO (OSM) orchestrator defined by ETSI NFV and Open Source MANO (OSM)
([NFV-Architectural-Framework] and [OSM-White-Paper]). ([NFV-Architectural-Framework] and [OSM-White-Paper]).
SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls SLG Controller (SLG-Ctrl): An SLG-Ctrl is an entity that controls
SLGs. An SLG-Ctrl is controlled by upper-level operation systems SLGs. An SLG-Ctrl is controlled by upper-level operation systems
such as OSS/BSS or orchestrator. such as OSS/BSS or orchestrator.
3. Motivations and Roles of SLG 3. Motivations and Roles of SLG
SLG main role is the enablement of interworkings between data plane
with management and control elements for controlling and
orchestrating end-to-end slices.
Use cases of network slices are discussed in several Standard Use cases of network slices are discussed in several Standard
Developing Organizations (SDOs). Some examples are described in use Developing Organizations (SDOs). Some examples are described in use
cases document ([I-D.netslices-usecases]). cases document ([I-D.netslices-usecases]).
In some proposed use cases, an NS is structured across multiple In some proposed use cases, an NS is structured across multiple
network domains. The capability of NS subnets might be different network domains. The capability of NS subnets might be different
because the components are domain-specific. In particular, the because the components are domain-specific. In particular, the
differentiation in capability between different administrative differentiation in capability between different administrative
domains is large. domains is large.
skipping to change at page 5, line 35 skipping to change at page 7, line 21
host==>|SLG| Subnet |SLG| Subnet |SLG+-+SLG| Subnet( Server ) host==>|SLG| Subnet |SLG| Subnet |SLG+-+SLG| Subnet( Server )
+---+ #1 +---+ #2 +---+ +---+ #3 `------' +---+ #1 +---+ #2 +---+ +---+ #3 `------'
/____________//___________/ /________________/ /____________//___________/ /________________/
/____________//___________/ /________________/ /____________//___________/ /________________/
: : : : : :
: : : : : :
.--. .--. .--. .--. .--. .--.
( )-. ( )-. ( )-. ( )-. ( )-. ( )-.
.' Access ' .' Core ' .' Data ' .' Access ' .' Core ' .' Data '
( Network ) ( Network ) ( Center ) ( Network ) ( Network ) ( Center )
( -' ( -' ( -' ( -' ( -' ( /Cloud -'
'-( ) '-( ) '-( ) '-( ) '-( ) '-( )
'---' '---' '---' '---' '---' '---'
\______ ______/ \_____ _____/ \________ ________/ \______ ______/ \_____ _____/ \________ ________/
V V V V V V
Domain#1 Domain#2 Domain#3 Domain#1 Domain#2 Domain#3
\_____________ _____________/ \________ ________/ \_____________ _____________/ \________ ________/
V V V V
Domain of Administrator#A Domain of Administrator#B Domain of Administrator#A Domain of Administrator#B
Figure 1: E2E-NS composed of multiple NS subnets Figure 1: E2E-NS composed of multiple NS subnets
Moreover, identification of user traffic and their assignment to the Moreover, identification of user service traffic and their
appropriate NS subnet are required at the edges of E2E-NSs, as shown allocation/disallocation to the appropriate NS subnet are required at
in Figure 2, and SLGs might take on these roles. the edges of E2E-NSs, as shown in Figure 2, and SLGs might take on
these roles.
+-----+ _______________ +-----+ _______________
end | |-->/_______________ end | |-->/_______________
host ====>| SLG | NS Subnet#1 host ====>| SLG | NS Subnet#1
|@Edge| _______________ |@Edge| _______________
| |-->/______________ | |-->/______________
| | NS Subnet#2 | | NS Subnet#2
| | : : | | : :
+-----+ +-----+
skipping to change at page 6, line 30 skipping to change at page 8, line 15
Note that, this model has the assumption that transitions of data Note that, this model has the assumption that transitions of data
packets from one NS subnet to another are executed at only SLGs. packets from one NS subnet to another are executed at only SLGs.
Also, an SLG is not necessarily implemented as a single device or Also, an SLG is not necessarily implemented as a single device or
virtual machine (VM). virtual machine (VM).
4. Architecture Overview of NS Management 4. Architecture Overview of NS Management
The architecture overview of NS management system is shown in The architecture overview of NS management system is shown in
Figure 3. Orchestrators manage whole resources including network Figure 3. Orchestrators manage whole resources including network
elements and server resources (i.e., routing, bandwidth, compute or elements and server resources (i.e., routing, bandwidth, compute or
storage). In this figure the resources of each domain are managed by storage). In this figure, the resources including network elements
domain orchestrators and the E2E-orchestrator and network service and server resources are managed by resource orchestrators installed
orchestrator handle domain orchestrators. in each domain, and the E2E-orchestrator and network service
orchestrator handle resource orchestrators.
NSs are requested from NS tenants via the portal system and the order 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 of creations of an NS is given to the E2E orchestrator from the
portal system via BSS/OSS. When an NS across multiple administrative portal system via BSS/OSS. When an NS across multiple administrative
domains are requested, the portal system that received the request domains are requested, the portal system that received the request
forwards the order to create NS subnets to the other infrastructure forwards the order to create NS subnets to the other infrastructure
providers' systems via Cross-Segment Slice Manager. The details of providers' systems via Cross-Segment Slice Manager. The details of
COMS architecture are described in the architecture document ([I- COMS architecture are described in the architecture document ([I-
D.qiang-coms-architecture]). D.qiang-coms-architecture]).
SLGs are also controlled via orchestrators. An SLG basically belongs SLGs are also controlled via orchestrators. An SLG basically belongs
to a network element, and it might also belong to server resource if 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 it runs as a VNF. (An example of position of SLG deployed as a VNF
shown in Appendix A.) is shown in Appendix A.)
SLGs are located at the edges of each NS subnet. They translate data 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 packets into the appropriate form and send them to the next NS
subnet. SLGs located at the end of E2E-NSs additionally provide subnet. SLGs located at the end of E2E-NSs additionally provide
identification of data packets and select the assigned NS subnet identification of data packets and select the assigned NS subnet
based on the identification result. based on the identification result.
The information model used in this architecture is described in The information model used in this architecture is described in
information model document information model document
([I-D.qiang-coms-netslicing-information-model]). ([I-D.qiang-coms-netslicing-information-model]).
NS Tenant NS Tenant
| |
. .|. . . . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . . . . . . . . .
. +-v---------+ . . +-v---------+ .
. |Portal/GUI +--+ . . |Portal/GUI +--+ .
. +-+---------+ | . . . . . . . . . . . +-+---------+ | . . . . . . . . . .
. | +-v-------------------+ . . +------------+ . . | +-v-----------------------+ . . +------------+ .
. | |CSS-Mngr./TNS-Orch. |4----------->|CSS-M/TNS-O | . . | |CSS-Mngr./TNS-Orch. |<------->|CSS-M/TNS-O | .
. | +-+-------+-----------+ . . +-+--------+-+ . . | +-+-------+---------------+ . . +-+--------+-+ .
. | | | . . | | . . | | | . . | | .
. +-v-----+ | | . . +-v-----+ | . . +-v-----+ | | . . +-v-----+ | .
. |BSS/OSS|4-----+ | . . |BSS/OSS| | . . |BSS/OSS|<-----+ | . . |BSS/OSS| | .
. +-+-----+ | . . +-+-----+ | . . +-+-----+ | . . +-+-----+ | .
. | | . . | | . . | | . . | | .
. +-v--------------------v-----------+ . . +-v--------v-+ . . +-v--------------------v-----------+ . . +-v--------v-+ .
. | E2E-Orch./Network Service-Orch. | . . |E2E-O/NS-O | . . | E2E-Orch./Network Service-Orch. | . . |E2E-O/NS-O | .
. +-+--------------------+-----------+ . . +-+--------+-+ . . +-+--------------------+-----------+ . . +-+--------+-+ .
. | | . . | | . . | | . . | | .
. +-v----------------+ +-v----------------+ . . : . . +-v----------------+ +-v----------------+ . . : .
. | Domain Orch.#1 | | Domain Orch.#2 |.. . . . . . . . . . . . | Resource Orch.#1 | | Resource Orch.#2 |.. . . . . . . . . . .
. +-+---------+------+ +-+---------+------+ . Administrative . +-+---------+------+ +-+---------+------+ . Administrative
. | | | | . Domain#2 . | | | | . Domain#2
. +-v------++-v------+ +-v------++-v------+ . . +-v------++-v------+ +-v------++-v------+ .
. |Network ||NFV | |Network ||NFV | . . |Network ||NFV | |Network ||NFV | .
. |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | . . |Ctrl. ||Ctrl. | |Ctrl. ||Ctrl. | .
. +-+------++-+------+ +-+------++-+------+ . . +-+------++-+------+ +-+------++-+------+ .
. | | | | . . | | | | .
. +-v------++-v------+ +-v------++-v------+ . . +-v------++-v------+ +-v------++-v------+ .
. |Network ||Server | |Network ||Server | . . |Network ||Server | |Network ||Server | .
. |Elements||Resource| |Elements||Resource|.. . . |Elements||Resource| |Elements||Resource|.. .
skipping to change at page 8, line 17 skipping to change at page 10, line 10
An SLG is basically a component in the data plane and has the roles An SLG is basically a component in the data plane and has the roles
of data packet processing. Moreover, it is required to have of data packet processing. Moreover, it is required to have
functions for control/management processes such as connecting to functions for control/management processes such as connecting to
underlay networks or managing NSs. underlay networks or managing NSs.
Furthermore, an SLG might be required to support handling services Furthermore, an SLG might be required to support handling services
provided on NSs in addition to controlling of NS because an SLG is an provided on NSs in addition to controlling of NS because an SLG is an
edge node on an E2E-NS. edge node on an E2E-NS.
In this section, we describe the requirements for an SLG in terms of In this section, we describe the requirements for an SLG in terms of
the following aspects. the following aspects and their interworkings.
1. Data plane for NSs as infrastructure 1. Data plane for NSs as infrastructure
2. Control/management plane for NSs as infrastructure 2. Control/management plane for NSs as infrastructure
3. Data plane for services on NSs 3. Data plane for services on NSs
4. Control/management plane for services on NSs 4. Control/management plane for services on NSs
5.1. Management of NS as Infrastructure 5.1. Management of NS as Infrastructure
skipping to change at page 9, line 4 skipping to change at page 10, line 45
Mobile Access: An SLG MUST identify and classify data packet with Mobile Access: An SLG MUST identify and classify data packet with
subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of subscriber-ID such as IMSI, radio-wave bandwidth, or identifier of
tunnels. Moreover, in some services, an SLG should identify and tunnels. Moreover, in some services, an SLG should identify and
classify data packets based on application used in the classify data packets based on application used in the
communication or location of the user equipment (UE). communication or location of the user equipment (UE).
Between NS subnets: An SLG MUST identify and classify data packet Between NS subnets: An SLG MUST identify and classify data packet
based on the tunnel-ID or virtual routing and forwarding (VRF) based on the tunnel-ID or virtual routing and forwarding (VRF)
that received the packets. If specific slice identifier such as a that received the packets. If specific slice identifier such as a
value mapped in the metadata field of the IP header is used, an value mapped in the metadata field of the IP header is used; an
SLG should identify and classify data packets with the ID. SLG should identify and classify data packets with the ID.
5.1.1.2. Transporting/Forwarding 5.1.1.2. Transporting/Forwarding
SLGs MUST provide functions for transport data packets depending on SLGs MUST provide functions for transport data packets depending on
the specifications of the underlay networks. the specifications of the underlay networks.
Encapsulation/Decapsulation/Tagging: In network slicing, duplication Encapsulation/Decapsulation/Tagging: In network slicing, duplication
of IP addresses of user packets between NSs MUST be accepted, of IP addresses of user packets between NSs MUST be accepted,
thus, using techniques that enable separation of a network thus, using techniques that enable separation of a network
skipping to change at page 12, line 44 skipping to change at page 14, line 44
An SLG might have interfaces to controllers for managing user An SLG might have interfaces to controllers for managing user
policies on each NS. Some controllers might be deployed on the same policies on each NS. Some controllers might be deployed on the same
NS. If some controllers are located at external networks, they might NS. If some controllers are located at external networks, they might
require SLGs to have APIs. require SLGs to have APIs.
5.2.2.2. Collection of Telemetry information 5.2.2.2. Collection of Telemetry information
In an NSaaS, collection of telemetry information of each NS might be In an NSaaS, collection of telemetry information of each NS might be
required for understanding traffic usage. Thus, an SLG might be required for understanding traffic usage. Thus, an SLG might be
required to support to collect and repoet telemetry information of required to support to collect and report telemetry information of
connected NSs. connected NSs.
6. Deployment of SLG 6. Deployment of SLG
This section describes considerations related with deployment of This section describes considerations related with deployment of
SLGs. SLGs.
6.1. Examples of Components Required to Have SLG Functions 6.1. Examples of Components Required to Maintain SLG Functions
For providing E2E-NSs on existing network infrastructures, some For providing E2E-NSs on existing network infrastructures, some
components located at boundaries of domains are required to have the components located at boundaries of domains are required to have the
same set of functionality as an SLG. Examples of such components in same set of functionality as an SLG. Examples of such components in
each domain type are described below. each domain type are described below.
Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc. Fixed Network: CPE/HGW, Service Edge, Gateway Router, etc.
Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW Mobile Network: User Equipment, Radio-AP, eNodeB, S/P-GW
([LTE-Specs]), etc. ([LTE-Specs]), etc.
skipping to change at page 16, line 9 skipping to change at page 18, line 9
--------------------' `------------------- --------------------' `-------------------
GW: Gateway Node GW: Gateway Node
Figure 7: Overview of horizontal connection of ID-SLG Figure 7: Overview of horizontal connection of ID-SLG
6.4. Vertical Connection 6.4. Vertical Connection
There are two patterns of vertical connection of SLGs in the middle 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 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 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, 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 however, establishment of a new SLG is required when a new E2E-NS is
created. This might causes extra overheads because of deploying many created. This might causes extra overheads because of deploying many
SLGs. SLGs.
The other pattern is that such SLGs are acceptable to accommodate The other pattern is that such SLGs are acceptable to accommodate
multiple NS subnets from each domain. In this pattern, SLGs are multiple NS subnets from each domain. In this pattern, SLGs are
support NS subnet selection. On the other hand, this pattern can support NS subnet selection. On the other hand, this pattern can
restrain the number of SLGs. Also, it is easy to provide transit of 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. data packets from an NS subnet to other subnet on the same domain.
skipping to change at page 17, line 39 skipping to change at page 19, line 39
described in subnets interconnection document described in subnets interconnection document
([I-D.defoy-coms-subnet-interconnection]). ([I-D.defoy-coms-subnet-interconnection]).
This section is focused on interconnection between NS subnets This section is focused on interconnection between NS subnets
established on different administrative domains, and describes established on different administrative domains, and describes
considerations related to this condition. considerations related to this condition.
7.1. Pre-arrangement of transport protocols 7.1. Pre-arrangement of transport protocols
For interconnection between different administrative NS subnets, pre- For interconnection between different administrative NS subnets, pre-
arrangement of the transport protocol which is used to connect arrangement of the transport protocol, which is used to connect
between SLGs is required. Orchestration systems indicate the between SLGs is required. Orchestration systems indicate the
protocol and configuration to each SLG. protocol and configuration to each SLG.
7.2. Quality Assurance between SLGs 7.2. Quality Assurance between SLGs
In addition to establishing connection, quality control of In addition to establishing connection, quality control of
communication is important. SLGs of egress side should execute communication is important. SLGs of egress side should execute
traffic shaping to prevent some NSs from excessively occupying the traffic shaping to prevent some NSs from excessively occupying the
link between SLGs. Moreover, some SLGs are connected to several link between SLGs. Moreover, some SLGs are connected to several
other SLGs that are deployed on the different locations. Therefore other SLGs that are deployed on the different locations. Therefore
skipping to change at page 18, line 12 skipping to change at page 20, line 12
excessive inflow of traffic into some NSs. The parameters for these excessive inflow of traffic into some NSs. The parameters for these
controls are pre-configured by orchestration systems. controls are pre-configured by orchestration systems.
The above approaches are ones of the simplest ways to provide quality The above approaches are ones of the simplest ways to provide quality
assurance of inter-administrative subnets. If there is stricter assurance of inter-administrative subnets. If there is stricter
isolation request, more considerations would be required. isolation request, more considerations would be required.
7.3. Secure Interconnection 7.3. Secure Interconnection
For connecting networks of different administrators, secure For connecting networks of different administrators, secure
interconnection schemes are required. In particular, in an NSaaS, interconnection schemes are required. Especially, in an NSaaS,
networks might be connected to several networks and schemes for networks might be connected to several networks, and schemes for
ensuring secure connectivity. ensuring secure connectivity would be more important.
SLGs confirm whether the opponent SLG is regular when it requests to 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 connect, and reject the request if the SLG is not regular. In some
cases, SLGs might be confirm whether the inner packets received from cases, SLGs might be confirm whether the inner packets received from
the other SLGs are sent from regular users. the other SLGs are sent from regular users.
8. Security Considerations 8. Security Considerations
Requirements and considerations for SLG related to security are Requirements and considerations for SLG related to security are
described in Section 5 and Section 7. described in Section 5 and Section 7.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgement 10. Acknowledgement
The authors would like to thank Li Qiang for her reviews and The authors would like to thank Li Qiang for her kind review and
comments. valuable feedback.
11. Informative References 11. Informative References
[I-D.defoy-coms-subnet-interconnection] [I-D.defoy-coms-subnet-interconnection]
Foy, X., Rahman, A., Galis, A., Foy, X., Rahman, A., Galis, A.,
kiran.makhijani@huawei.com, k., and L. Qiang, kiran.makhijani@huawei.com, k., and L. Qiang,
"Interconnecting (or Stitching) Network Slice Subnets", "Interconnecting (or Stitching) Network Slice Subnets",
draft-defoy-coms-subnet-interconnection-01 (work in draft-defoy-coms-subnet-interconnection-01 (work in
progress), October 2017. progress), October 2017.
skipping to change at page 19, line 39 skipping to change at page 21, line 39
(work in progress), October 2017. (work in progress), October 2017.
[LTE-Specs] [LTE-Specs]
3rd Generation Partnership Project (3GPP), "3GPP TS 3rd Generation Partnership Project (3GPP), "3GPP TS
36.300", December 2007, 36.300", December 2007,
<http://www.qtc.jp/3GPP/Specs/36300-830.pdf>. <http://www.qtc.jp/3GPP/Specs/36300-830.pdf>.
[NFV-Architectural-Framework] [NFV-Architectural-Framework]
Network Functions Virtualisation (NFV) ETSI Industry Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG), "Network Functions Specification Group (ISG), "Network Functions
Virtualisation (NFV); Architectural Framework", Decenber Virtualisation (NFV); Architectural Framework", December
2014, <http://www.etsi.org/deliver/etsi_gs/ 2014, <http://www.etsi.org/deliver/etsi_gs/
NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf>. NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf>.
[OSM-White-Paper] [OSM-White-Paper]
ETSI, "OSM White Paper", October 2016, ETSI, "OSM White Paper", October 2016,
<https://osm.etsi.org/images/ <https://osm.etsi.org/images/
OSM-Whitepaper-TechContent-ReleaseONE-FINAL.pdf>. OSM-Whitepaper-TechContent-ReleaseONE-FINAL.pdf>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
skipping to change at page 20, line 38 skipping to change at page 22, line 38
| BSS/OSS, Orchestrator | | BSS/OSS, Orchestrator |
+-+---------------+---------+ +-+---------------+---------+
| | | |
+-v------+ +-v---------+ +-v------+ +-v---------+
|SLG-Ctrl| | NFV Orch. | |SLG-Ctrl| | NFV Orch. |
+-+------+ +-+---------+ +-+------+ +-+---------+
| | | |
,-v------. | ,-v------. |
| SLG | | | SLG | |
:========: +-v---------+ :========: +-v---------+
| VM |4-----+ VNF Mngr. | | VM |<-----+ VNF Mngr. |
`--------' +-+---------+ `--------' +-+---------+
+--------+ | +--------+ |
|HostOS/ | +-v---------+ |HostOS/ | +-v---------+
|Server |4-----+ VIM | |Server |<-----| VIM |
+--------+ +-----------+ +--------+ +-----------+
Figure 10: Position of SLG as a VM on ETSI NFV MANO Figure 10: Position of SLG as a VM on ETSI NFV MANO
Appendix B. Requirements for each SLG Type Appendix B. Requirements for each SLG Type
The requirements for each SLG type are listed in Figure 11. The requirements for each SLG type are listed in Figure 11.
+---------------++-------+-------+-------+----------------+ +---------------++-------+-------+-------+----------------+
| || E-SLG |IS-SLG |ID-SLG | Reference | | || E-SLG |IS-SLG |ID-SLG | Reference |
skipping to change at line 991 skipping to change at page 24, line 22
Email: homma.shunsuke@lab.ntt.co.jp Email: homma.shunsuke@lab.ntt.co.jp
Xavier de Foy Xavier de Foy
InterDigital Inc. InterDigital Inc.
1000 Sherbrooke West 1000 Sherbrooke West
Montreal Montreal
Canada Canada
Email: Xavier.Defoy@InterDigital.com Email: Xavier.Defoy@InterDigital.com
Alex Galis
University College London
Torrington Place
London WC1E 7JE
United Kingdom
Email: a.galis@ucl.ac.uk
 End of changes. 34 change blocks. 
100 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/