Internet DRAFT - draft-suzuki-netslices-latency-management
draft-suzuki-netslices-latency-management
Network Working Group T. Suzuki
Internet-Draft Hitachi, Ltd.
Intended status: Informational March 2, 2018
Expires: September 3, 2018
Use case and Requirements for Latency Management in Network Slices
draft-suzuki-netslices-latency-management-00
Abstract
This draft provides a use case that addresses the need for latency
management for end-to-end data transmissions through multiple
domains. Specifically, examples of latency management schemes are
described. In addition, the necessity of a common latency management
framework and of interfaces to gather latency information between
edges in each domain and to determine data transmission paths is
addressed.
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 http://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 September 3, 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
(http://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
Suzuki Expires September 3, 2018 [Page 1]
Internet-Draft Latency Management in Network Slices March 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case Requiring Low Latency . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Types of Latency Control . . . . . . . . . . . . . . . . . . . 6
4.1. Centralized Management Type . . . . . . . . . . . . . . . 6
4.2. Distributed management type . . . . . . . . . . . . . . . 7
5. Requirements for End-to-End Latency Management . . . . . . . . 9
5.1. Latency Management Framework . . . . . . . . . . . . . . . 9
5.2. Interface for Gathering Latency Information . . . . . . . 9
5.3. Interface for configuring a Data Transmission Path . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Suzuki Expires September 3, 2018 [Page 2]
Internet-Draft Latency Management in Network Slices March 2018
1. Introduction
This draft provides a use case that needs low latency and the
requirements for a framework to guarantee a service-level agreement
(SLA) on latency for end-to-end data transmissions in a network
slice. Currently, several use cases have been discussed for network
slices in the document [NetSlices-Usecase]. In addition, the
architecture of network slices has been discussed in the document
[NetSlices-Architecture]. In a network slice, specific resources
such as a network, computing power, and storage are assigned
exclusively to each user or service. Therefore, it is natural for
each user of a network slice to expect an SLA for the data
transmission performance.
Network slice schemes will be able to provide networks with low-
latency data transmission. With regard to low latency, deterministic
networks have also been discussed as a means of supporting
applications requiring extremely real-time data transmissions
[DetNet-Architecture]. In order to contribute to an SLA for network
slice schemes, a specific use case for DetNet is described in this
draft. In addition, requirements for controlling latency among
multiple network domains are addressed.
In Section 2, a use case requiring end-to-end latency management is
described. In Section 3, the problem of having to manage latency in
order to transmit data through multiple domains is discussed. In
Section 4, example methods for managing latency are shown. In
Section 5, requirements that the management system should satisfy are
described.
Suzuki Expires September 3, 2018 [Page 3]
Internet-Draft Latency Management in Network Slices March 2018
2. Use Case Requiring Low Latency
One use case requiring low-latency data transmission is the control
of a vehicle from a remote control center. In recent years,
autonomous cars are being actively researched and developed. Such
cars will be able to drive without being controlled by a driver at
almost all times. However, in some cases, these cars might stop
driving. For example, when some of the sensors or cameras that
detect the conditions of the car's surroundings are damaged, it will
be difficult for the car to drive autonomously. In such
circumstances, the damaged vehicle could be controlled by a driver at
a remote control center. The driver would have to drive the damaged
vehicle using the available sensors and monitors. In order to
control the vehicle safely, control data must be transmitted with low
latency between the remote control center and the car.
Suzuki Expires September 3, 2018 [Page 4]
Internet-Draft Latency Management in Network Slices March 2018
3. Problem Statement
Currently, deterministic network architecture is being actively
discussed. Specifically, schemes to control latency among multiple
network domains are being considered. With regard to end-to-end
latency control in network slicing, there will be two types of
service. One is the selection of a specific route that is able to
meet the requirements of end-to-end latency. The other is the
assignment of consumable latency in each domain. In the former case,
a specific route could be selected by a single network management
system. In the latter case, consumable latency for each domain could
be negotiated among multiple network-domain management systems.
Another scheme may also be possible. In order to manage end-to-end
latency through multiple network domains, a common scheme is needed.
Suzuki Expires September 3, 2018 [Page 5]
Internet-Draft Latency Management in Network Slices March 2018
4. Types of Latency Control
With regard to controlling end-to-end latency, there are at least two
types of scheme as described above. One is based on centralized
management and the other is based on distributed management. In this
section, those schemes are described in detail.
4.1. Centralized Management Type
An example system composed of a sender(Tx), receiver(Rx), multiple
domains, sub-management systems, and a main management system is
shown in Figure 1. In this system, each sub-management system
manages latency and specific routes in its respective domain. In
addition, each sub-management system measures the latency for
possible data transmission paths. In the figure, measured latency
for each path between edges in each domain and for each connection
between domains is shown. The measurement results are transmitted to
the main management system. The main management system selects a
specific route path between the sender and receiver to meet the
latency requirement of the sender, and the selection results are
transmitted to the sub-management systems. They configure a data
transmission path in their domain.
Suzuki Expires September 3, 2018 [Page 6]
Internet-Draft Latency Management in Network Slices March 2018
+-----+-----+
| Main mgmt |
+-----+-----+
__________________________|___________________________
_( )_
(_ Management network _)
(______________________________________________________)
| | | |
| | | |
+----+----+ +-----+---+ +--+------+ +---+-----+
|Sub-mgmt | |Sub-mgmt | |Sub-mgmt | |Sub-mgmt |
+----+----+ +-----+---+ +--+------+ +---+-----+
| | | |
| ___+_____ | |
| | 8 | | |
| +--+---------+---|------+ |
____+____ | |_________| | | ____+____
| | 5 | Domain-B | | 5 | |
| +------+---+ | +---+------+ |
+--+ 5 | | 7 | | | 13 | | 5 +--+
|Tx+---+--+ | | | +--+---|Rx|
+--+ | | 8 | | | 12 | | +--+
| +------+---+ | +---+------+ |
|_________| 5 | _____+___ | 5 |_________|
Domain-A | | 15 | | Domain-D
+----------+---------+--+
|_________|
Domain-C
Figure 1: Centralized latency management system
4.2. Distributed management type
An example system composed of a sender(Tx), receiver(Rx), multiple
domains, and sub-management systems is shown in Figure 2. In this
system, each sub-management system manages latency and specific
routes in its respective domain. The sub-management system that
receives a latency requirement for an end-to-end data transmission
requests the other sub-management systems to return possible
transmission latency between edges in the domain and between domains.
The sub-management system selects a specific domain path between the
sender and receiver to meet the latency requirement. After that, the
selection results are transmitted from the sub-management system to
the other sub-management systems. Specifically, the permitted
latency for each domain is transmitted to each sub-management system.
The selected sub-management system determines a specific route path
Suzuki Expires September 3, 2018 [Page 7]
Internet-Draft Latency Management in Network Slices March 2018
to transmit data in each domain.
______________________________________________________
_( )_
(_ Management network _)
(______________________________________________________)
| | | |
| | | |
+----+----+ +-----+---+ +--+------+ +---+-----+
|Sub-mgmt | |Sub-mgmt | |Sub-mgmt | |Sub-mgmt |
+----+----+ +-----+---+ +--+------+ +---+-----+
| | | |
| ___+_____ | |
| | | | |
| +--+ 10 +---|------+ |
____+____ 5 | |_________| | | 5 ____+____
+--- 5 | +---+ Domain-B | +---+ | 5 +--+
|Tx+---+ 10 | | | 10 +---|Rx|
+--+ |_________+---+ _____+___ +---+_________| +--+
Domain-A 5 | | | | 5 Domain-D
+----------+ 15 +--+
|_________|
Domain-C
Figure 2: Distributed latency management system
Suzuki Expires September 3, 2018 [Page 8]
Internet-Draft Latency Management in Network Slices March 2018
5. Requirements for End-to-End Latency Management
A framework for managing end-to-end data transmission latency must be
designed. In addition, the interfaces to gather latency information
and configure data transmission paths must be prepared to control
latency. Specific requirements are briefly described below.
5.1. Latency Management Framework
As shown in Figure 1 and Figure 2, there are at least two types of
latency management. One is to determine a specific data transmission
path using a centralized management system. The other is to
determine a specific data transmission path using a distributed
management system. In order to efficiently manage latency, a common
framework must be determined.
5.2. Interface for Gathering Latency Information
This interface is used to gather latency information for each domain.
In the case of the centralized management system, the main management
system uses the interface to gather latency information for each path
between edges in each domain and for each connection between domains
from all the sub-management systems. In the case of the distributed
management system, one sub-management system uses the interface to
gather possible transmission latency information between edges in the
domain and between domains from the other sub-management systems.
5.3. Interface for configuring a Data Transmission Path
This interface is used to configure an end-to-end data transmission
path. In the case of the centralized management system, the main
management system uses the interface to transmit a selected data-
transmission route path to the sub-management systems In the case of
the distributed management system, one sub-management system uses the
interface to transmit a selected data-transmission domain path to the
other sub-management systems that provided possible transmission
latency information between edges in each domain and between domains.
Suzuki Expires September 3, 2018 [Page 9]
Internet-Draft Latency Management in Network Slices March 2018
6. Security Considerations
This document describes a use case and requirements for latency
management among multiple network domains. A system to manage
latency for end-to-end data transmissions could be composed of
multiple sub-management systems for multiple domains. In this
system, latency information between edges in each domain is gathered
or exchanged to determine a data-transmission route path or domain
path. It is therefore necessary to use a secure communication
channel between the latency management systems.
Suzuki Expires September 3, 2018 [Page 10]
Internet-Draft Latency Management in Network Slices March 2018
7. IANA Considerations
This document includes no requests for IANA.
Suzuki Expires September 3, 2018 [Page 11]
Internet-Draft Latency Management in Network Slices March 2018
8. Informative References
[DetNet-Architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", October 2017.
<http://tools.ietf.org/html/
draft-ietf-detnet-architecture-04>
[NetSlices-Architecture]
Geng, L., Dong, J., Bryant, S., Makhijani, K., Galis, A.,
Foy, X., and S. Kuklinski, "Network Slicing Architecture",
July 2017.
<http://tools.ietf.org/html/
draft-geng-netslices-architecture-02>
[NetSlices-Usecase]
Makhijani, K., Qin, J., Ravindran, R., Geng, L., Qiang,
L., Peng, S., Foy, X., Rahman, A., Galis, A., and G.
Fioccola, "Network Slicing Use Cases: Network
Customization and Differentiated Services", October 2017.
<http://tools.ietf.org/html/draft-netslices-usecases-02>
Suzuki Expires September 3, 2018 [Page 12]
Internet-Draft Latency Management in Network Slices March 2018
Author's Address
Toshiaki Suzuki
Research & Development Group, Hitachi, Ltd.
1-280 Higashi-koigakubo
Kokubunji, Tokyo 185-8601
Japan
Phone: +81-42-323-1111
Email: toshiaki.suzuki.cs@hitachi.com
Suzuki Expires September 3, 2018 [Page 13]
