Network Working Group L. Geng
Internet-Draft L. Wang
Intended status: Informational China Mobile
Expires: January 3, 2019 L. Qiang
Huawei Technologies
July 2, 2018
Technical Requirements of Bounded Latency in Large-scale DetNet
Deployment
draft-geng-detnet-requirements-bounded-latency-00
Abstract
This document summarizes the technical requirements of bounded
latency of DetNet system in large-scale deployment.
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 January 3, 2019.
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.
Geng, et al. Expires January 3, 2019 [Page 1]
Internet-DraTechnical Requirements of DetNet Deployment in La July 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3
2. End-to-end bounded latency requirements . . . . . . . . . . . 3
3. Tolerance of time deviation . . . . . . . . . . . . . . . . . 4
4. Massive number of deterministic flows . . . . . . . . . . . . 4
5. Stable jitter with long transmission delay . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Deterministic Networking (DetNet) enables the transmission of
specific data flows in large scale networks with extremely low data
loss rates and bounded latency. [draft-ietf-detnet-problem-statement]
outlines the problems that need to be resolved in DetNet, and
[draft-ietf-detnet-use-cases] presents the use cases in which DetNet
deployment is found beneficial and useful.
In DetNet WG, many of the technical requirements and solution have
been discussed In order to achieve deterministic networking
performance in large-scale network. This mainly include the
following aspect.
o DetNet Definition and architecture are discussed in
[draft-ietf-detnet-architecture]
o Encapsulation methods are discussed in[draft-ietf-detnet-dp-sol]
with specific mechanisms for identification of DetNet services and
approaches for reliable transmission (i.e. Replication of
packets).
o Security requirements are specially discussed in
[draft-ietf-detnet-security].
To some extend, TSN is assumed to be used for Layer 2 underlay for
DetNet services to guarantee the bounded latency performance.
However, TSN is originally designed for LAN scenario which suffers
from scalability problems (i.e. end-to-end time synchronization,
sensitive jitter performance subject to transmission latency).
Meanwhile, it is also considered challenging to using MPLS/IP
encapsulation for DetNet service in which the forwarding plane is
purely based on Layer 2 TSN technology. There is yet a document
Geng, et al. Expires January 3, 2019 [Page 2]
Internet-DraTechnical Requirements of DetNet Deployment in La July 2018
which specifically discusses the requirements of bounded latency with
an assumption that DetNet runs as an standalone underlay technology
rather than an overlay of TSN.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.2. Terminology & Abbreviations
This document uses the terminology defined in
[draft-ietf-detnet-architecture].
TSN: Time Sensitive Network
2. End-to-end bounded latency requirements
As [draft-ietf-detnet-dp-sol] declares, there are two types of
scenarios considered in DetNet as shown in Figure 1: (i) inter-
connect TSN domains scenario, and (ii) native connectivity between
DetNet-aware end systems.
+--------------+ +--------------+
| | | |
| TSN Domain I +-----------------------------+ TSN Domain II|
| | | |
+--------------+ +--------------+
(i) Inter-connect TSN Domains
+--------------+ +--------------+
|DetNet Device +---------------------------+DetNet Device |
+--------------+ +--------------+
(ii) Native Connectivity between DetNet-aware End Systems
Figure 1: Two Types of DetNet Scenarios
Req 1: Stitching TSN domains with bounded latency.
In scenario (i) TSN islands are bridged through DetNet connections,
and time synchronization is required inside each TSN domain. Note
that different TSN domains may be misaligned in time and it may not
be feasible to achieve end-to-end time synchronization in large
scale. It is the DetNet domain who has to maintain the bounded
latency performance between the separated TSN domains.
Geng, et al. Expires January 3, 2019 [Page 3]
Internet-DraTechnical Requirements of DetNet Deployment in La July 2018
Req 2: Flexible and fast convergence mechanism as new DetNet flow is
created.
Considering the features of TSN applications we can speculate that
the applications in scenario (i) are usually in a simple manner,
which means the number of deterministic flows will not dramatically
change with time. At the same time, the traffic patterns are
relative regular. While in scenario (ii) there are more bandwidth-
greddy applications such as VR communication. They may require
establishment or tear-down of the DetNet connections frequently.
Mechanisms like IEEE 802.1 Qch, and IEEE 802.1 Qbv which need re-
computation whenever new flow are added may be not suitable for this
case. In order to deploy DetNet services in scenario (ii).
3. Tolerance of time deviation
Req 3: Tolerance of a certain level of end-to-end time deviation.
Different from the TSN services which are deployed in small-scale
local area network, DetNet service targets at large scale
implementation. There are a great amount of heterogeneous devices in
large scale network. It will be difficult and costly to keep precise
synchronization among all devices. It is worthy of have a DetNet
system which can keep the bounded latency performance even under an
unsynchronized situation..
4. Massive number of deterministic flows
Req 4: Fine-grained and scalable resource reservation method.
Resource reservation for individual DetNet flows are required in
order to maintain per-flow state in the devices along the path.
Given a large number of DetNet flows, aggregation of such resource
reservation may be necessary at least at the core routers. However,
aggregating massive DetNet flows into a tunnel will sacrifice some
network resources or accuracy, just like change from DiffServ to
IntServ. Certain trade-off needs to be studied carefully to achieve
optimal performance.
5. Stable jitter with long transmission delay
Req 5: Tolerance of transmission latency
Large transmission latency is expected in large scale network which
may further lead to larger jitter in some mechanisms such as IEEE
802.1 Qch. It would be preferred to have a mechanism where the jitter
performance does not scale up with the transmission latency. Thus
Geng, et al. Expires January 3, 2019 [Page 4]
Internet-DraTechnical Requirements of DetNet Deployment in La July 2018
end user can have same bounded latency performance in a P2MP
deployment.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
This document will not introduce new security problems.
8. Acknowledgements
TBD.
9. Normative References
[draft-ietf-detnet-architecture]
"DetNet Architecture", .
[draft-ietf-detnet-dp-sol]
"DetNet Data Plane Encapsulation",
.
[draft-ietf-detnet-problem-statement]
"DetNet Problem Statement",
.
[draft-ietf-detnet-security]
"DetNet Security Considerations",
.
[draft-ietf-detnet-use-cases]
"DetNet Use Cases", .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
Geng, et al. Expires January 3, 2019 [Page 5]
Internet-DraTechnical Requirements of DetNet Deployment in La July 2018
Authors' Addresses
Liang Geng
China Mobile
Beijing
China
Email: gengliang@chinamobile.com
Lei Wang
China Mobile
Beijing
China
Email: wangleiyjy@chinamobile.com
Li Qiang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qiangli3@huawei.com
Geng, et al. Expires January 3, 2019 [Page 6]