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.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 1.2. Terminology & Abbreviations
• 2. End-to-end bounded latency requirements
• 3. Tolerance of time deviation
• 4. Massive number of deterministic flows
• 5. Stable jitter with long transmission delay
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. Normative References
• Authors' Addresses

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.

• DetNet Definition and architecture are discussed in [draft-ietf-detnet-architecture]
• 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).
• 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 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.

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 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

Authors' Addresses