Technical Requirements of Bounded Latency Forwarding
draft-geng-detnet-requirements-bounded-latency-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Liang Geng , Li Qiang , Toerless Eckert | ||
| Last updated | 2019-03-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-detnet-requirements-bounded-latency-01
Network Working Group L. Geng
Internet-Draft China Mobile
Intended status: Informational L. Qiang
Expires: September 9, 2019 Huawei Technologies
T. Eckert
Huawei
March 8, 2019
Technical Requirements of Bounded Latency Forwarding
draft-geng-detnet-requirements-bounded-latency-01
Abstract
This document analyses the technical requirements that Layer 3
bounded latency forwarding scheme should satisfy.
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 September 9, 2019.
Copyright Notice
Copyright (c) 2019 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 September 9, 2019 [Page 1]
Internet-Draft Requirements of Bounded Latency March 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3
2. Tolerance of Time Deviation . . . . . . . . . . . . . . . . . 3
3. Long Link Propagation Delay . . . . . . . . . . . . . . . . . 3
4. Massive Dynamic Flows . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
DetNet is chartered to provide deterministic forwarding over Layer 3.
Deterministic forwarding means packet forwarding with bounded
latency, loss and delay variation
[draft-ietf-detnet-problem-statement]. In current DetNet's
discussion, low packet loss is mainly achieved through PREOF (Packet
Replication, Elimination, and Ordering
Functions)[draft-ietf-detnet-architecture]. This document focuses on
bounded latency.
Common IP/MPLS forwarding has long tail effect that couldn't
guarantee bounded latency. DetNet has to have an approach to
identify DetNet flows, and divert them into a DetNet forwarding plane
in which some schemes are adapted to guarantee bounded latency.
There are several schemes are proposed for bounded latency forwarding
such as dedicated tunnel, light load with per-flow per-hop shaping,
Time Aware Shaping[IEEE802.1Qbv], Cyclic Queuing and
Forwarding[IEEE802.1Qch], Scalable Deterministic
Forwarding[draft-qiang-detnet-large-scale-detnet], and SR based
bounded latency[draft-chen-detnet-sr-based-bounded-latency]. This
document is not going to compare and analyze these schemes, but to
propose some factors (Layer 3 specific) worth to be considered when
selecting Layer 3 bounded latency forwarding scheme.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Geng, et al. Expires September 9, 2019 [Page 2]
Internet-Draft Requirements of Bounded Latency March 2019
1.2. Terminology & Abbreviations
This document uses the terminology defined in
[draft-ietf-detnet-architecture].
TSN: Time Sensitive Network
2. Tolerance of Time Deviation
One of DetNet's objectives is to stitch TSN domains together as shown
in Figure 1. We know that devices inside a TSN domain are time-
synchronized, and most of TSN forwarding schemes rely on precise time
synchronization. However two TSN domains have a high probability of
being asynchronous, while DetNet needs to connect them together and
provide end-to-end deterministic forwarding. Therefore, it is worthy
of have a DetNet forwarding plane which can keep the bounded latency
even under an unsynchronized situation. Otherwise, buffer is needed
to absorb the time deviation, and end-users have to bear the latency
and cost increase introduced by buffer.
Moreover, there are
+--------------+ +--------------+
| | DetNet Forwarding | |
| TSN Domain I +-----------------------------+ TSN Domain II|
| | | |
+--------------+ +--------------+
Figure 1: DetNet Scenario
3. Long Link Propagation Delay
In contrast to Layer 2 TSN that deployed in LAN, Layer 3 DetNet is
expected to be deployed in larger scale network that has longer link
propagation delay. Long link propagation delay can cause some
troubles to simple cyclic forwarding schemes, like[IEEE802.1Qch].
IEEE 802.1 Qch works on the basis of time synchronization, and one
hop forwarding (include packet sending, packet transmission on link,
and packet receiving three operations) is required to be finished
within one cycle as shown in Figure 2. Long links whose latency
exceed the cycle time will make IEEE 802.1 Qch doesn't work. One
possible solution is to set cycle time to be a bigger value, in order
to absorb long link propagation delay. However, this solution will
lead to larger jitter. The reason is that cyclic forwarding schemes
only try to ensure the packet arrives at a node within a certain
cycle, and packet's arrival time may vary within that cycle.
Geng, et al. Expires September 9, 2019 [Page 3]
Internet-Draft Requirements of Bounded Latency March 2019
/--\ " "
| | " Send "
\--/ " * "
Upstream Node " \ "
" \ "
" Short "
" Link\ "
" \ "
/--\ " v "
| | " * "
\--/ " Receive"
Downstream Node " "
" "
| | |
Time Line ----+-----------+-----------+---->
0 1 2
Figure 2: One Hop Forwarding in Qch
[Jitter on link is TBD]
4. Massive Dynamic Flows
Considering the features of TSN applications we can speculate that
the number of TSN flows will not dramatically change with time.
While DetNet targets at larger-scale deployment. There are more
time-sensitive applications such as VR communication, they may
require establishment or tear-down of the DetNet connections
frequently. Meanwhile, layer 3 device may serve millions of traffic
flows simultaneously. Hence those schemes that need complex
calculations may not be applicable in DetNet. More importantly,
forwarding schemes need to avoid impact on those in-transit flows
when new flows are added (or old flows are removed).
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
This document will not introduce new security problems.
7. Acknowledgements
The Authors would like to thank David Black for his review,
suggestion and comments to this document.
Geng, et al. Expires September 9, 2019 [Page 4]
Internet-Draft Requirements of Bounded Latency March 2019
8. Normative References
[draft-chen-detnet-sr-based-bounded-latency]
"SR based Bounded Latency",
<https://datatracker.ietf.org/doc/
draft-chen-detnet-sr-based-bounded-latency/>.
[draft-ietf-detnet-architecture]
"DetNet Architecture", <https://datatracker.ietf.org/doc/
draft-ietf-detnet-architecture/>.
[draft-ietf-detnet-problem-statement]
"DetNet Problem Statement",
<https://datatracker.ietf.org/doc/
draft-ietf-detnet-problem-statement/>.
[draft-qiang-detnet-large-scale-detnet]
"Large-Scale Deterministic Network",
<https://datatracker.ietf.org/doc/
draft-qiang-detnet-large-scale-detnet/>.
[IEEE802.1Qbv]
"Enhancements for Scheduled Traffic", 2016.
[IEEE802.1Qch]
"Cyclic Queuing and Forwarding", 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Liang Geng
China Mobile
Beijing
China
Email: gengliang@chinamobile.com
Geng, et al. Expires September 9, 2019 [Page 5]
Internet-Draft Requirements of Bounded Latency March 2019
Li Qiang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qiangli3@huawei.com
Toerless Eckert
Huawei USA - Futurewei Technologies Inc.
2330 Central Expy
Santa Clara 95050
USA
Email: tte+ietf@cs.fau.de
Geng, et al. Expires September 9, 2019 [Page 6]