< draft-geng-detnet-requirements-bounded-latency-02.txt   draft-geng-detnet-requirements-bounded-latency-03.txt >
Network Working Group L. Geng Network Working Group L. Geng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational P. Willis Intended status: Informational P. Willis
Expires: December 5, 2019 BT Expires: January 9, 2020 BT
S. Homma S. Homma
NTT NTT
L. Qiang L. Qiang
Huawei Huawei
June 3, 2019 July 8, 2019
Requirements of Layer 3 Deterministic Latency Service Requirements of Layer 3 Deterministic Latency Service
draft-geng-detnet-requirements-bounded-latency-02 draft-geng-detnet-requirements-bounded-latency-03
Abstract Abstract
This document specifies some technical, operational and management This document specifies some technical, operational and management
requirements of deploying deterministic latency service on layer 3 requirements of deploying deterministic latency service on layer 3
networks from the perspective of the service provider. networks from the perspective of the service provider.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 5, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
wander within a clock synchronous domain . . . . . . 4 wander within a clock synchronous domain . . . . . . 4
2.3. Requirement 3: Must support Inter-Continental propagation 2.3. Requirement 3: Must support Inter-Continental propagation
delay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 delay . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operational and Management Requirements . . . . . . . . . . . 6 3. Operational and Management Requirements . . . . . . . . . . . 6
3.1. Requirement 4: Should have self-monitoring capability . . 6 3.1. Requirement 4: Should have self-monitoring capability . . 6
3.2. Requirement 5: Should be robust against denial of service 3.2. Requirement 5: Should be robust against denial of service
attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Requirement 6: Must tolerate failures of links or nodes 3.3. Requirement 6: Must tolerate failures of links or nodes
and topology changes . . . . . . . . . . . . . . . . . . 7 and topology changes . . . . . . . . . . . . . . . . . . 7
3.4. Requirement 7: Must be scalable . . . . . . . . . . . . . 7 3.4. Requirement 7: Must be scalable . . . . . . . . . . . . . 7
3.4.1. Sub-requirement 7.1: Must be scalable to numerous
network devices . . . . . . . . . . . . . . . . . . . 7
3.4.2. Sub-requirement 7.2: Must be scalable to massive
traffic flows . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DetNet is chartered to provide bounds on latency, jitter (delay DetNet is chartered to provide bounds on latency, jitter (delay
variation) and packet loss [draft-ietf-detnet-problem-statement]. variation) and packet loss [draft-ietf-detnet-problem-statement].
Where latency and jitter are two closely related performance Where latency and jitter are two closely related performance
characteristics, this document refers to bounded latency and bounded characteristics, this document refers to bounded latency and bounded
jitter collectively as deterministic latency. jitter collectively as deterministic latency.
This document does not intend to define any specific mechanism, but This document does not intend to define any specific mechanism, but
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Domain II = = Domain II = =
=<==D==>= =<==D==>=
= = = =
Figure 1: TSN islands interconnecting Figure 1: TSN islands interconnecting
2.2.2. Sub-requirement 2.2: Should tolerate clock jitter & wander 2.2.2. Sub-requirement 2.2: Should tolerate clock jitter & wander
within a clock synchronous domain within a clock synchronous domain
DetNet domain itself can be time synchronous or asynchronous, DetNet domain itself can be time synchronous or asynchronous,
depending on the technology selection of different operators. Even depending on actual deployment, application, use cases, etc. Even
within a time synchronous domain, the synchronized clocks may also within a time synchronous domain, the synchronized clocks may also
experience jitter & wander, the mechanisms adopted by DetNet should experience jitter & wander. Different areas have different clock
be able to tolerate a certain degree of clock jitter & wander. accuracy, for example the crystal oscillator in Ethernet is specified
at 100 ppm [Fast-Ethernet-MII-clock], SyncE can achieve 50 ppb
[G.8262], and more precise time synchronization [G.8273] is expected
in 5G mobile backhaul. Hence the mechanisms adopted by DetNet should
be able to tolerate a certain degree of clock jitter & wander
accordingly.
2.3. Requirement 3: Must support Inter-Continental propagation delay 2.3. Requirement 3: Must support Inter-Continental propagation delay
In contrast to Layer 2 TSN that is deployed on a LAN [IEEE-TSN], In contrast to Layer 2 TSN that is deployed on a LAN [IEEE-TSN],
DetNet is expected to be deployed in a larger scale carrier networks DetNet is expected to be deployed in a larger scale carrier networks
that have long link propagation delay which means that DetNet must that have long link propagation delay which means that DetNet must
work on network links that have inter-continental propagation delays. work on network links that have inter-continental propagation delays.
Long link propagation delay can cause some troubles to cyclic Long link propagation delay can cause some troubles to cyclic
forwarding type mechanisms. In order to guarantee deterministic forwarding type mechanisms. In order to guarantee deterministic
latency, cyclic forwarding type mechanisms usually require a packet latency, cyclic forwarding type mechanisms usually require a packet
skipping to change at page 7, line 24 skipping to change at page 7, line 24
inevitable. However if the topology keeps changing many times, then inevitable. However if the topology keeps changing many times, then
DetNet may not deliver on its SLA. The topology changes alone may DetNet may not deliver on its SLA. The topology changes alone may
not be sufficient on a traditional IP network to raise any alarms, not be sufficient on a traditional IP network to raise any alarms,
but the mechanism's self-monitoring should detect this, and keep but the mechanism's self-monitoring should detect this, and keep
working in flapping network topologies. working in flapping network topologies.
3.4. Requirement 7: Must be scalable 3.4. Requirement 7: Must be scalable
Further to the requirement to work on inter-continental links, the Further to the requirement to work on inter-continental links, the
deterministic latency forwarding mechanisms must scale to networks of deterministic latency forwarding mechanisms must scale to networks of
significant size. The number of DetNet devices and flows in a significant size with numerous network devices and massive traffic
network will be very dependent on the use case. A simple use case to flows.
understand is ultra-low-latency (public) 5G transport networks, which
would require DetNet extend to every 5G base station. For some
network operators, their network may need to connect to ~100 K base
stations (serving multiple MNOs'), and this number will only increase
with 5G. If each ultra-low-latency slice or MNO is treated as a
separate deterministic latency traffic flow (or tunnel), then even if
each base station has a limited number of ultra-low latency slices or
MNOs (e.g. ~10), there will still be a lot of, ~1M, deterministic
latency traffic flows on one network simultaneously.
[Authors note: Req. 1 and Req. 3 also have some discussions relevant 3.4.1. Sub-requirement 7.1: Must be scalable to numerous network
to scalability. Need more comments and suggestions to help devices
reorganize the contents.]
A simple use case to understand is ultra-low-latency (public) 5G
transport networks, which would require DetNet extend to every 5G
base station. For some network operators, their network may need to
connect to ~100 K base stations (serving multiple MNOs'), and this
number will only increase with 5G.
3.4.2. Sub-requirement 7.2: Must be scalable to massive traffic flows
If each ultra-low-latency slice or MNO is treated as a separate
deterministic latency traffic flow (or tunnel), then even if each
base station has a limited number of ultra-low latency slices or MNOs
(e.g. ~10), there will still be a lot of, ~1M, deterministic latency
traffic flows on one network simultaneously.
4. IANA Considerations 4. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
5. Security Considerations 5. Security Considerations
This document will not introduce new security problems. This document will not introduce new security problems.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 8, line 17 skipping to change at page 8, line 21
The Authors would like to thank David Black, Stewart Bryant for their The Authors would like to thank David Black, Stewart Bryant for their
review, suggestion and comments to this document. review, suggestion and comments to this document.
7. Normative References 7. Normative References
[draft-ietf-detnet-architecture] [draft-ietf-detnet-architecture]
"DetNet Architecture", <https://datatracker.ietf.org/doc/ "DetNet Architecture", <https://datatracker.ietf.org/doc/
draft-ietf-detnet-architecture/>. draft-ietf-detnet-architecture/>.
[draft-ietf-detnet-problem-statement] [draft-ietf-detnet-problem-statement]
"DetNet Problem Statement", G.8262 : Timing characteristics of a synchronous Ethernet
<https://datatracker.ietf.org/doc/ equipment slave clockG.8262 : Timing characteristics of a
synchronous Ethernet equipment slave clock, "DetNet
Problem Statement", <https://datatracker.ietf.org/doc/
draft-ietf-detnet-problem-statement/>. draft-ietf-detnet-problem-statement/>.
[Fast-Ethernet-MII-clock]
"Fast Ethernet MII clock",
<http://www.ti.com/lit/ds/symlink/dp83865.pdf>.
[G.8262] "G.8262 : Timing characteristics of a synchronous Ethernet
equipment slave clock",
<https://www.itu.int/rec/T-REC-G.8262>.
[G.8273] "G.8273: Framework of phase and time clocks",
<https://www.itu.int/rec/T-REC-G.8273/en>.
[IEEE-TSN] [IEEE-TSN]
"IEEE TSN Task Group", "IEEE TSN Task Group",
<http://www.ieee802.org/1/pages/tsn.html>. <http://www.ieee802.org/1/pages/tsn.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
 End of changes. 13 change blocks. 
25 lines changed or deleted 51 lines changed or added

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