draft-ietf-detnet-use-cases-16.txt   draft-ietf-detnet-use-cases-17.txt 
Internet Engineering Task Force E. Grossman, Ed. Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY Internet-Draft DOLBY
Intended status: Informational May 15, 2018 Intended status: Informational June 26, 2018
Expires: November 16, 2018 Expires: December 28, 2018
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-16 draft-ietf-detnet-use-cases-17
Abstract Abstract
This draft documents requirements in several diverse industries to This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can properties. In this context deterministic implies that flows can be
be established which provide guaranteed bandwidth and latency which established which provide guaranteed bandwidth and latency which can
can be established from either a Layer 2 or Layer 3 (IP) interface, be established from either a Layer 2 or Layer 3 (IP) interface, and
and which can co-exist on an IP network with best-effort traffic. which can co-exist on an IP network with best-effort traffic.
Additional requirements include optional redundant paths, very high Additional requirements include optional redundant paths, very high
reliability paths, time synchronization, and clock distribution. reliability paths, time synchronization, and clock distribution.
Industries considered include professional audio, electrical Industries considered include professional audio, electrical
utilities, building automation systems, wireless for industrial, utilities, building automation systems, wireless for industrial,
cellular radio, industrial machine-to-machine, mining, private cellular radio, industrial machine-to-machine, mining, private
blockchain, and network slicing. blockchain, and network slicing.
For each case, this document will identify the application, identify For each case, this document will identify the application, identify
representative solutions used today, and the improvements IETF DetNet representative solutions used today, and the improvements IETF DetNet
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 November 16, 2018. This Internet-Draft will expire on December 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 5, line 32 skipping to change at page 5, line 32
12.2.4. Internet-Based Applications Asks . . . . . . . . . . 75 12.2.4. Internet-Based Applications Asks . . . . . . . . . . 75
12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75 12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75
12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 75 12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 75
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 77 14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 77
14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 78 14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 78
14.3. Building Automation Systems . . . . . . . . . . . . . . 78 14.3. Building Automation Systems . . . . . . . . . . . . . . 78
14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 78 14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 78
14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 78 14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 78
14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 78 14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 79
14.7. Internet Applications and CoMP . . . . . . . . . . . . . 79 14.7. Internet Applications and CoMP . . . . . . . . . . . . . 79
14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 79 14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 79
14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 79 14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 79
14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 79 14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 79
14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 79 14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 79
15. Informative References . . . . . . . . . . . . . . . . . . . 79 15. Informative References . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
This draft presents use cases from diverse industries which have in This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ common a need for deterministic flows, but which also differ notably
notably in their network topologies and specific desired behavior. in their network topologies and specific desired behavior. Together,
Together, they provide broad industry context for DetNet and a they provide broad industry context for DetNet and a yardstick
yardstick against which proposed DetNet designs can be measured (to against which proposed DetNet designs can be measured (to what extent
what extent does a proposed design satisfy these various use cases?) does a proposed design satisfy these various use cases?)
For DetNet, use cases explicitly do not define requirements; The For DetNet, use cases explicitly do not define requirements; The
DetNet WG will consider the use cases, decide which elements are in DetNet WG will consider the use cases, decide which elements are in
scope for DetNet, and the results will be incorporated into future scope for DetNet, and the results will be incorporated into future
drafts. Similarly, the DetNet use case draft explicitly does not drafts. Similarly, the DetNet use case draft explicitly does not
suggest any specific design, architecture or protocols, which will be suggest any specific design, architecture or protocols, which will be
topics of future drafts. topics of future drafts.
We present for each use case the answers to the following questions: We present for each use case the answers to the following questions:
skipping to change at page 6, line 50 skipping to change at page 6, line 50
These industries have already transitioned audio and video signals These industries have already transitioned audio and video signals
from analog to digital. However, the digital interconnect systems from analog to digital. However, the digital interconnect systems
remain primarily point-to-point with a single (or small number of) remain primarily point-to-point with a single (or small number of)
signals per link, interconnected with purpose-built hardware. signals per link, interconnected with purpose-built hardware.
These industries are now transitioning to packet-based infrastructure These industries are now transitioning to packet-based infrastructure
to reduce cost, increase routing flexibility, and integrate with to reduce cost, increase routing flexibility, and integrate with
existing IT infrastructure. existing IT infrastructure.
Today ProAV applications have no way to establish deterministic Today ProAV applications have no way to establish deterministic flows
streams from a standards-based Layer 3 (IP) interface, which is a from a standards-based Layer 3 (IP) interface, which is a fundamental
fundamental limitation to the use cases described here. Today limitation to the use cases described here. Today deterministic
deterministic streams can be created within standards-based layer 2 flows can be created within standards-based layer 2 LANs (e.g. using
LANs (e.g. using IEEE 802.1 AVB) however these are not routable via IEEE 802.1 AVB) however these are not routable via IP and thus are
IP and thus are not effective for distribution over wider areas (for not effective for distribution over wider areas (for example
example broadcast events that span wide geographical areas). broadcast events that span wide geographical areas).
It would be highly desirable if such streams could be routed over the It would be highly desirable if such flows could be routed over the
open Internet, however solutions with more limited scope (e.g. open Internet, however solutions with more limited scope (e.g.
enterprise networks) would still provide a substantial improvement. enterprise networks) would still provide a substantial improvement.
The following sections describe specific ProAV use cases. The following sections describe specific ProAV use cases.
2.1.1. Uninterrupted Stream Playback 2.1.1. Uninterrupted Stream Playback
Transmitting audio and video streams for live playback is unlike Transmitting audio and video streams for live playback is unlike
common file transfer because uninterrupted stream playback in the common file transfer because uninterrupted stream playback in the
presence of network errors cannot be achieved by re-trying the presence of network errors cannot be achieved by re-trying the
skipping to change at page 14, line 16 skipping to change at page 14, line 16
require particularly long time to operate and take up the majority of require particularly long time to operate and take up the majority of
the total clearance time, leaving only a 10ms window for the the total clearance time, leaving only a 10ms window for the
telecommunications part of the protection scheme, independent of the telecommunications part of the protection scheme, independent of the
distance to travel. Given the sensitivity of the issue, new networks distance to travel. Given the sensitivity of the issue, new networks
impose requirements that are even more stringent: IEC standard 61850 impose requirements that are even more stringent: IEC standard 61850
limits the transfer time for protection messages to 1/4 - 1/2 cycle limits the transfer time for protection messages to 1/4 - 1/2 cycle
or 4 - 8ms (for 60Hz lines) for the most critical messages. or 4 - 8ms (for 60Hz lines) for the most critical messages.
3.1.1.1.3. Symmetric Channel Delay 3.1.1.1.3. Symmetric Channel Delay
Note: It is currently under WG discussion whether symmetric path
delays are to be guaranteed by DetNet.
Teleprotection channels which are differential must be synchronous, Teleprotection channels which are differential must be synchronous,
which means that any delays on the transmit and receive paths must which means that any delays on the transmit and receive paths must
match each other. Teleprotection systems ideally support zero match each other. Teleprotection systems ideally support zero
asymmetric delay; typical legacy relays can tolerate delay asymmetric delay; typical legacy relays can tolerate delay
discrepancies of up to 750us. discrepancies of up to 750us.
Some tools available for lowering delay variation below this Some tools available for lowering delay variation below this
threshold are: threshold are:
o For legacy systems using Time Division Multiplexing (TDM), jitter o For legacy systems using Time Division Multiplexing (TDM), jitter
skipping to change at page 41, line 16 skipping to change at page 41, line 16
4.2.3.3. Feedback Control 4.2.3.3. Feedback Control
BAS systems utilize feedback control in various ways; the most time- BAS systems utilize feedback control in various ways; the most time-
critial is control of DC motors, which require a short feedback critial is control of DC motors, which require a short feedback
interval (1-5ms) with low communication delay (10ms) and jitter interval (1-5ms) with low communication delay (10ms) and jitter
(1ms). The feedback interval depends on the characteristics of the (1ms). The feedback interval depends on the characteristics of the
device and a target quality of control value. There are typically device and a target quality of control value. There are typically
~10s of such devices per LC. ~10s of such devices per LC.
Communication delay is expected to be less than 10 ms, jitter less Communication delay is expected to be less than 10ms, jitter less
than 1 sec while the availability must be 99.9999% . than 1ms while the availability must be 99.9999% .
4.2.4. Security Considerations 4.2.4. Security Considerations
When BAS field networks were developed it was assumed that the field When BAS field networks were developed it was assumed that the field
networks would always be physically isolated from external networks networks would always be physically isolated from external networks
and therefore security was not a concern. In today's world many BASs and therefore security was not a concern. In today's world many BASs
are managed remotely and are thus connected to shared IP networks and are managed remotely and are thus connected to shared IP networks and
so security is definitely a concern, yet security features are not so security is definitely a concern, yet security features are not
available in the majority of BAS field network deployments . available in the majority of BAS field network deployments .
skipping to change at page 44, line 20 skipping to change at page 44, line 20
able to store many packets waiting to be forwarded. It is able to store many packets waiting to be forwarded. It is
advantageous then for it to only be required to carry out the advantageous then for it to only be required to carry out the
specific behavior assigned to it by the PCE/NME (as opposed to specific behavior assigned to it by the PCE/NME (as opposed to
maintaining its own IP stack, for example). maintaining its own IP stack, for example).
Note: Current WG discussion indicates that some peer-to-peer Note: Current WG discussion indicates that some peer-to-peer
communication must be assumed, i.e. the PCE may communicate only communication must be assumed, i.e. the PCE may communicate only
indirectly with any given device, enabling hierarchical configuration indirectly with any given device, enabling hierarchical configuration
of the system. of the system.
6TiSCH depends on [PCE] and [I-D.finn-detnet-architecture]. 6TiSCH depends on [PCE] and [I-D.ietf-detnet-architecture].
6TiSCH also depends on the fact that DetNet will maintain consistency 6TiSCH also depends on the fact that DetNet will maintain consistency
with [IEEE802.1TSNTG]. with [IEEE802.1TSNTG].
5.2. Wireless Industrial Today 5.2. Wireless Industrial Today
Today industrial wireless is accomplished using multiple Today industrial wireless is accomplished using multiple
deterministic wireless networks which are incompatible with each deterministic wireless networks which are incompatible with each
other and with IP traffic. other and with IP traffic.
skipping to change at page 45, line 50 skipping to change at page 45, line 50
o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o
o o o LLN o o o o o o o LLN o o o o
o o o o o o o o o o o o o o o o o o o o o o o o
Figure 8: Extended 6TiSCH Network Figure 8: Extended 6TiSCH Network
The backbone router must ensure end-to-end deterministic behavior The backbone router must ensure end-to-end deterministic behavior
between the LLN and the backbone. We would like to see this between the LLN and the backbone. We would like to see this
accomplished in conformance with the work done in accomplished in conformance with the work done in
[I-D.finn-detnet-architecture] with respect to Layer-3 aspects of [I-D.ietf-detnet-architecture] with respect to Layer-3 aspects of
deterministic networks that span multiple Layer-2 domains. deterministic networks that span multiple Layer-2 domains.
The PCE must compute a deterministic path end-to-end across the TSCH The PCE must compute a deterministic path end-to-end across the TSCH
network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are
expected to enable end-to-end deterministic forwarding. expected to enable end-to-end deterministic forwarding.
+-----+ +-----+
| IoT | | IoT |
| G/W | | G/W |
+-----+ +-----+
skipping to change at page 48, line 10 skipping to change at page 48, line 10
shot with a full schedule, which incorporates the aggregation of its shot with a full schedule, which incorporates the aggregation of its
behavior for multiple paths. 6TiSCH expects that the programing of behavior for multiple paths. 6TiSCH expects that the programing of
the schedule will be done over COAP as discussed in the schedule will be done over COAP as discussed in
[I-D.ietf-6tisch-coap]. [I-D.ietf-6tisch-coap].
6TiSCH expects that the PCE commands will be mapped back and forth 6TiSCH expects that the PCE commands will be mapped back and forth
into CoAP by a gateway function at the edge of the 6TiSCH network. into CoAP by a gateway function at the edge of the 6TiSCH network.
For instance, it is possible that a mapping entity on the backbone For instance, it is possible that a mapping entity on the backbone
transforms a non-CoAP protocol such as PCEP into the RESTful transforms a non-CoAP protocol such as PCEP into the RESTful
interfaces that the 6TiSCH devices support. This architecture will interfaces that the 6TiSCH devices support. This architecture will
be refined to comply with DetNet [I-D.finn-detnet-architecture] when be refined to comply with DetNet [I-D.ietf-detnet-architecture] when
the work is formalized. Related information about 6TiSCH can be the work is formalized. Related information about 6TiSCH can be
found at [I-D.ietf-6tisch-6top-interface] and RPL [RFC6550]. found at [I-D.ietf-6tisch-6top-interface] and RPL [RFC6550].
A protocol may be used to update the state in the devices during A protocol may be used to update the state in the devices during
runtime, for example if it appears that a path through the network runtime, for example if it appears that a path through the network
has ceased to perform as expected, but in 6TiSCH that flow was not has ceased to perform as expected, but in 6TiSCH that flow was not
designed and no protocol was selected. We would like to see DetNet designed and no protocol was selected. We would like to see DetNet
define the appropriate end-to-end protocols to be used in that case. define the appropriate end-to-end protocols to be used in that case.
The implication is that these state updates take place once the The implication is that these state updates take place once the
system is configured and running, i.e. they are not limited to the system is configured and running, i.e. they are not limited to the
skipping to change at page 58, line 19 skipping to change at page 58, line 19
there is still no way to signal the time synchronization and time- there is still no way to signal the time synchronization and time-
sensitive stream requirements/reservations for Layer-3 flows in a way sensitive stream requirements/reservations for Layer-3 flows in a way
that addresses the entire transport stack, including the Ethernet that addresses the entire transport stack, including the Ethernet
layers that need to be configured. layers that need to be configured.
Furthermore, not all "user plane" traffic will be IP. Therefore, the Furthermore, not all "user plane" traffic will be IP. Therefore, the
same solution also must address the use cases where the user plane same solution also must address the use cases where the user plane
traffic is a different layer, for example Ethernet frames. traffic is a different layer, for example Ethernet frames.
There is existing work describing the problem statement There is existing work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture [I-D.ietf-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet) [I-D.ietf-detnet-architecture] for deterministic networking (DetNet)
that targets solutions for time-sensitive (IP/transport) streams with that targets solutions for time-sensitive (IP/transport) streams with
deterministic properties over Ethernet-based switched networks. deterministic properties over Ethernet-based switched networks.
6.4. Cellular Radio Networks Asks 6.4. Cellular Radio Networks Asks
A standard for data plane transport specification which is: A standard for data plane transport specification which is:
o Unified among all xHauls (meaning that different flows with o Unified among all xHauls (meaning that different flows with
diverse DetNet requirements can coexist in the same network and diverse DetNet requirements can coexist in the same network and
traverse the same nodes without interfering with each other) traverse the same nodes without interfering with each other)
skipping to change at page 70, line 40 skipping to change at page 70, line 40
explicitly based on IPv4 (as opposed to IPv6) and it is not explicitly based on IPv4 (as opposed to IPv6) and it is not
considered practical to expect them to migrate to IPv6 in order to considered practical to expect them to migrate to IPv6 in order to
use DetNet. Thus the expectation is that even if not every feature use DetNet. Thus the expectation is that even if not every feature
of DetNet is available in an IPv4 context, at least some of the of DetNet is available in an IPv4 context, at least some of the
significant benefits (such as guaranteed end-to-end delivery and low significant benefits (such as guaranteed end-to-end delivery and low
latency) are expected to be available. latency) are expected to be available.
11.1.6. Guaranteed End-to-End Delivery 11.1.6. Guaranteed End-to-End Delivery
Packets sent over DetNet are guaranteed not to be dropped by the Packets sent over DetNet are guaranteed not to be dropped by the
network due to congestion. (Packets may however be dropped for network due to congestion. However, the network may drop packets for
intended reasons, e.g. per security measures). intended reasons, e.g. per security measures. Also note that this
guarantee applies to the actions of DetNet protocol software, and
does not provide any guarantee against lower level errors such as
media errors or checksum errors.
11.1.7. Replacement for Multiple Proprietary Deterministic Networks 11.1.7. Replacement for Multiple Proprietary Deterministic Networks
There are many proprietary non-interoperable deterministic Ethernet- There are many proprietary non-interoperable deterministic Ethernet-
based networks currently available; DetNet is intended to provide an based networks currently available; DetNet is intended to provide an
open-standards-based alternative to such networks. open-standards-based alternative to such networks.
11.1.8. Mix of Deterministic and Best-Effort Traffic 11.1.8. Mix of Deterministic and Best-Effort Traffic
DetNet is intended to support coexistance of time-sensitive DetNet is intended to support coexistance of time-sensitive
skipping to change at page 74, line 7 skipping to change at page 74, line 7
as part of a whole system, however it is understood that such as part of a whole system, however it is understood that such
timing properties are not guaranteed by DetNet itself. It is timing properties are not guaranteed by DetNet itself. It is
currently an open question as to whether DetNet protocols will currently an open question as to whether DetNet protocols will
include a way for an application to communicate such timing include a way for an application to communicate such timing
expectations to the network, and if so whether they would be expectations to the network, and if so whether they would be
expected to materially affect the performance they would receive expected to materially affect the performance they would receive
from the network as a result. from the network as a result.
12.2. Internet-based Applications 12.2. Internet-based Applications
12.2.1. Use Case Description There are many applications that communicate over the open Internet
that could benefit from guaranteed delivery and bounded latency.
However as noted above, all such applications when run over the open
Internet are out of scope for DetNet. These same applications may be
in-scope when run in constrained environments, i.e. within a
centrally controlled DetNet network. The following are some examples
of such applications.
There are many applications that communicate across the open Internet 12.2.1. Use Case Description
that could benefit from guaranteed delivery and bounded latency. The
following are some representative examples.
12.2.1.1. Media Content Delivery 12.2.1.1. Media Content Delivery
Media content delivery continues to be an important use of the Media content delivery continues to be an important use of the
Internet, yet users often experience poor quality audio and video due Internet, yet users often experience poor quality audio and video due
to the delay and jitter inherent in today's Internet. to the delay and jitter inherent in today's Internet.
12.2.1.2. Online Gaming 12.2.1.2. Online Gaming
Online gaming is a significant part of the gaming market, however Online gaming is a significant part of the gaming market, however
latency can degrade the end user experience. For example "First latency can degrade the end user experience. For example "First
Person Shooter" (FPS) games are highly delay-sensitive. Person Shooter" games are highly delay-sensitive.
12.2.1.3. Virtual Reality 12.2.1.3. Virtual Reality
Virtual reality (VR) has many commercial applications including real Virtual reality has many commercial applications including real
estate presentations, remote medical procedures, and so on. Low estate presentations, remote medical procedures, and so on. Low
latency is critical to interacting with the virtual world because latency is critical to interacting with the virtual world because
perceptual delays can cause motion sickness. perceptual delays can cause motion sickness.
12.2.2. Internet-Based Applications Today 12.2.2. Internet-Based Applications Today
Internet service today is by definition "best effort", with no Internet service today is by definition "best effort", with no
guarantees on delivery or bandwidth. guarantees on delivery or bandwidth.
12.2.3. Internet-Based Applications Future 12.2.3. Internet-Based Applications Future
skipping to change at page 81, line 9 skipping to change at page 81, line 18
[Fronthaul] [Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul Chen, D. and T. Mustala, "Ethernet Fronthaul
Considerations", IEEE 1904.3, February 2015, Considerations", IEEE 1904.3, February 2015,
<http://www.ieee1904.org/3/meeting_archive/2015/02/ <http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_che n_1a.pdf>. tf3_1502_che n_1a.pdf>.
[HART] www.hartcomm.org, "Highway Addressable remote Transducer, [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.finn-detnet-architecture]
Finn, N. and P. Thubert, "Deterministic Networking
Architecture", draft-finn-detnet-architecture-08 (work in
progress), August 2016.
[I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-05 (work
in progress), March 2016.
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top) Interface", draft-ietf-6tisch-6top-interface-04 (6top) Interface", draft-ietf-6tisch-6top-interface-04
(work in progress), July 2015. (work in progress), July 2015.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work
in progress), April 2018. in progress), April 2018.
skipping to change at page 81, line 40 skipping to change at page 81, line 39
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015. in progress), March 2015.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 2018.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-05 (work in progress), May 2018.
[I-D.ietf-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-ietf-detnet-problem-statement-05 (work
in progress), June 2018.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.ietf-mpls-residence-time] [I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-15 (work in network", draft-ietf-mpls-residence-time-15 (work in
progress), March 2017. progress), March 2017.
 End of changes. 21 change blocks. 
50 lines changed or deleted 54 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/