draft-ietf-detnet-architecture-02.txt   draft-ietf-detnet-architecture-03.txt 
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Technologies Co. Ltd Internet-Draft Huawei Technologies Co. Ltd
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: December 31, 2017 Cisco Expires: February 9, 2018 Cisco
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
June 29, 2017 August 8, 2017
Deterministic Networking Architecture Deterministic Networking Architecture
draft-ietf-detnet-architecture-02 draft-ietf-detnet-architecture-03
Abstract Abstract
Deterministic Networking (DetNet) provides a capability to carry Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency. Techniques with extremely low data loss rates and bounded latency. Techniques
used include: 1) reserving data plane resources for individual (or used include: 1) reserving data plane resources for individual (or
aggregated) DetNet flows in some or all of the intermediate nodes aggregated) DetNet flows in some or all of the intermediate nodes
(e.g. bridges or routers) along the path of the flow; 2) providing (e.g. bridges or routers) along the path of the flow; 2) providing
explicit routes for DetNet flows that do not rapidly change with the explicit routes for DetNet flows that do not rapidly change with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 31, 2017. This Internet-Draft will expire on February 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 16 skipping to change at page 3, line 16
4.7.1. Exporting flow identification . . . . . . . . . . . . 27 4.7.1. Exporting flow identification . . . . . . . . . . . . 27
4.7.2. Flow attribute mapping between layers . . . . . . . . 29 4.7.2. Flow attribute mapping between layers . . . . . . . . 29
4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 30 4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 30
4.8. Advertising resources, capabilities and adjacencies . . . 32 4.8. Advertising resources, capabilities and adjacencies . . . 32
4.9. Provisioning model . . . . . . . . . . . . . . . . . . . 32 4.9. Provisioning model . . . . . . . . . . . . . . . . . . . 32
4.9.1. Centralized Path Computation and Installation . . . . 32 4.9.1. Centralized Path Computation and Installation . . . . 32
4.9.2. Distributed Path Setup . . . . . . . . . . . . . . . 32 4.9.2. Distributed Path Setup . . . . . . . . . . . . . . . 32
4.10. Scaling to larger networks . . . . . . . . . . . . . . . 33 4.10. Scaling to larger networks . . . . . . . . . . . . . . . 33
4.11. Connected islands vs. networks . . . . . . . . . . . . . 33 4.11. Connected islands vs. networks . . . . . . . . . . . . . 33
4.12. Compatibility with Layer-2 . . . . . . . . . . . . . . . 33 4.12. Compatibility with Layer-2 . . . . . . . . . . . . . . . 33
5. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 34 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5.1. Flat vs. hierarchical control . . . . . . . . . . . . . . 34 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
5.2. Peer-to-peer reservation protocol . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
5.3. Wireless media interactions . . . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
5.4. Packet encoding for service protection . . . . . . . . . 35 9. Access to IEEE 802.1 documents . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. Informative References . . . . . . . . . . . . . . . . . . . 35
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
10. Access to IEEE 802.1 documents . . . . . . . . . . . . . . . 37
11. Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows extremely low a network to DetNet flows. DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
This is accomplished by dedicating network resources such as link This is accomplished by dedicating network resources such as link
bandwidth and buffer space to DetNet flows and/or classes of DetNet bandwidth and buffer space to DetNet flows and/or classes of DetNet
flows, and by replicating packets along multiple paths. Unused flows, and by replicating packets along multiple paths. Unused
reserved resources are available to non-DetNet packets. reserved resources are available to non-DetNet packets.
skipping to change at page 4, line 23 skipping to change at page 4, line 18
Many applications of interest to Deterministic Networking require the Many applications of interest to Deterministic Networking require the
ability to synchronize the clocks in end systems to a sub-microsecond ability to synchronize the clocks in end systems to a sub-microsecond
accuracy. Some of the queue control techniques defined in accuracy. Some of the queue control techniques defined in
Section 4.5 also require time synchronization among relay and transit Section 4.5 also require time synchronization among relay and transit
nodes. The means used to achieve time synchronization are not nodes. The means used to achieve time synchronization are not
addressed in this document. DetNet should accommodate various addressed in this document. DetNet should accommodate various
synchronization techniques and profiles that are defined elsewhere to synchronization techniques and profiles that are defined elsewhere to
solve exchange time in different market segments. solve exchange time in different market segments.
The present document is an individual contribution, but it is Wired and wireless media differ greatly in a number of ways,
intended by the authors for adoption by the DetNet working group. including connectivity possibilities and the reliability of packet
transmission. While some of the techniques described in this
document may be applicable to wireless media, the DetNet architecture
assumes the use of links with characteristics typical of wired, and
not wireless, media.
2. Terminology 2. Terminology
2.1. Terms used in this document 2.1. Terms used in this document
The following special terms are used in this document in order to The following special terms are used in this document in order to
avoid the assumption that a given element in the architecture does or avoid the assumption that a given element in the architecture does or
does not have Internet Protocol stack, functions as a router, bridge, does not have Internet Protocol stack, functions as a router, bridge,
firewall, or otherwise plays a particular role at Layer-2 or higher. firewall, or otherwise plays a particular role at Layer-2 or higher.
skipping to change at page 6, line 11 skipping to change at page 6, line 9
participates in the DetNet service layer. It typically participates in the DetNet service layer. It typically
incorporates DetNet transport layer functions as well, in incorporates DetNet transport layer functions as well, in
which case it is collocated with a transit node. which case it is collocated with a transit node.
reservation reservation
A trail of configuration between source to destination(s) A trail of configuration between source to destination(s)
through transit nodes and subnets associated with a DetNet through transit nodes and subnets associated with a DetNet
flow, to provide congestion protection. flow, to provide congestion protection.
DetNet service layer DetNet service layer
The layer at which service protection is provided, either The layer at which service protection is provided, packet
packet sequencing, replication, and elimination sequencing, replication, and elimination (Section 3.2.4) or
(Section 3.2.4) or network coding (Section 5.4). packet encoding.
source source
An end system capable of sourcing a DetNet flow. An end system capable of sourcing a DetNet flow.
DetNet transit node DetNet transit node
A node operating at the DetNet transport layer, that utilizes A node operating at the DetNet transport layer, that utilizes
link layer and/or network layer switching across multiple link layer and/or network layer switching across multiple
links and/or sub-networks to provide paths for DetNet service links and/or sub-networks to provide paths for DetNet service
layer functions. Optionally provides congestion protection layer functions. Optionally provides congestion protection
over those paths. An MPLS LSR is an example of a DetNet over those paths. An MPLS LSR is an example of a DetNet
skipping to change at page 8, line 6 skipping to change at page 8, line 6
(latency and packet loss). Given that DetNet nodes have a finite (latency and packet loss). Given that DetNet nodes have a finite
amount of buffer space, congestion protection necessarily results in amount of buffer space, congestion protection necessarily results in
a maximum end-to-end latency. It also addresses the largest a maximum end-to-end latency. It also addresses the largest
contribution to packet loss, which is buffer congestion. contribution to packet loss, which is buffer congestion.
After congestion, the most important contributions to packet loss are After congestion, the most important contributions to packet loss are
typically from random media errors and equipment failures. Service typically from random media errors and equipment failures. Service
protection is the name for the mechanisms used by DetNet to address protection is the name for the mechanisms used by DetNet to address
these losses. The mechanisms employed are constrained by the these losses. The mechanisms employed are constrained by the
requirement to meet the users' latency requirements. Packet requirement to meet the users' latency requirements. Packet
replication and elimination (Section 3.2.4) packet encoding replication and elimination (Section 3.2.4) is described in this
Section 5.4 are described in this document to provide service document to provide service protection; others may be found. This
protection; others may be found. Both mechanisms distribute the mechanism distributes the contents of DetNet flows over multiple
contents of DetNet flows over multiple paths in time and/or space, so paths in time and/or space, so that the loss of some of the paths
that the loss of some of the paths does need not cause the loss of does need not cause the loss of any packets. The paths are typically
any packets. The paths are typically (but not necessarily) explicit (but not necessarily) explicit routes, so that they cannot suffer
routes, so that they cannot suffer temporary interruptions caused by temporary interruptions caused by the reconvergence of routing or
the reconvergence of routing or bridging protocols. bridging protocols.
These three techniques can be applied independently, giving eight These three techniques can be applied independently, giving eight
possible combinations, including none (no DetNet), although some possible combinations, including none (no DetNet), although some
combinations are of wider utility than others. This separation keeps combinations are of wider utility than others. This separation keeps
the protocol stack coherent and maximizes interoperability with the protocol stack coherent and maximizes interoperability with
existing and developing standards in this (IETF) and other Standards existing and developing standards in this (IETF) and other Standards
Development Organizations. Some examples of typical expected Development Organizations. Some examples of typical expected
combinations: combinations:
o Explicit routes plus service protection are exactly the techniques o Explicit routes plus service protection are exactly the techniques
skipping to change at page 10, line 11 skipping to change at page 10, line 11
wiring. As an additional benefit, ring topologies can often utilize wiring. As an additional benefit, ring topologies can often utilize
different topology management protocols than those used for a mesh different topology management protocols than those used for a mesh
network, with a consequent reduction in the response time to topology network, with a consequent reduction in the response time to topology
changes. Of course, this comes at some cost in terms of increased changes. Of course, this comes at some cost in terms of increased
hop count, and thus latency, for the typical path. hop count, and thus latency, for the typical path.
In order to get the advantages of low hop count and still ensure In order to get the advantages of low hop count and still ensure
against even very brief losses of connectivity, DetNet employs against even very brief losses of connectivity, DetNet employs
explicit routes, where the path taken by a given DetNet flow does not explicit routes, where the path taken by a given DetNet flow does not
change, at least immediately, and likely not at all, in response to change, at least immediately, and likely not at all, in response to
network topology events. Service protection (Section 3.2.4 or network topology events. Service protection (Section 3.2.4) over
Section 5.4) over explicit routes provides a high likelihood of explicit routes provides a high likelihood of continuous
continuous connectivity. Explicit routes are commonly used in MPLS connectivity. Explicit routes are commonly used in MPLS TE LSPs.
TE LSPs.
3.2.3. Jitter Reduction 3.2.3. Jitter Reduction
A core objective of DetNet is to enable the convergence of Non-IP A core objective of DetNet is to enable the convergence of Non-IP
networks onto a common network infrastructure. This requires the networks onto a common network infrastructure. This requires the
accurate emulation of currently deployed mission-specific networks, accurate emulation of currently deployed mission-specific networks,
which typically rely on point-to-point analog (e.g. 4-20mA which typically rely on point-to-point analog (e.g. 4-20mA
modulation) and serial-digital cables (or buses) for highly reliable, modulation) and serial-digital cables (or buses) for highly reliable,
synchronized and jitter-free communications. While the latency of synchronized and jitter-free communications. While the latency of
analog transmissions is basically the speed of light, legacy serial analog transmissions is basically the speed of light, legacy serial
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Jitter reduction is provided by the mechanisms described in Jitter reduction is provided by the mechanisms described in
Section 4.5 that also provide congestion protection. Section 4.5 that also provide congestion protection.
3.2.4. Packet Replication and Elimination 3.2.4. Packet Replication and Elimination
After congestion loss has been eliminated, the most important causes After congestion loss has been eliminated, the most important causes
of packet loss are random media and/or memory faults, and equipment of packet loss are random media and/or memory faults, and equipment
failures. Both causes of packet loss can be greatly reduced by failures. Both causes of packet loss can be greatly reduced by
spreading the data in a packet over multiple transmissions. One such spreading the data in a packet over multiple transmissions. One such
method for service protection is described in this section, which method for service protection is described in this section, which
sends the same packets over multiple paths. See also Section 5.4. sends the same packets over multiple paths.
Packet replication and elimination, also known as seamless redundancy Packet replication and elimination, also known as seamless redundancy
[HSR-PRP], or 1+1 hitless protection, is a function of the DetNet [HSR-PRP], or 1+1 hitless protection, is a function of the DetNet
service layer. It involves three capabilities: service layer. It involves three capabilities:
o Providing sequencing information, once, at or near the source, to o Providing sequencing information, once, at or near the source, to
the packets of a DetNet compound flow. This may be done by adding the packets of a DetNet compound flow. This may be done by adding
a sequence number or time stamp as part of DetNet, or may be a sequence number or time stamp as part of DetNet, or may be
inherent in the packet, e.g. in a transport protocol, or inherent in the packet, e.g. in a transport protocol, or
associated to other physical properties such as the precise time associated to other physical properties such as the precise time
skipping to change at page 13, line 5 skipping to change at page 13, line 5
including coesistence with other QoS mechanisms Section 3.3.1 and including coesistence with other QoS mechanisms Section 3.3.1 and
protection against misbehaving transmitters Section 3.3.2. protection against misbehaving transmitters Section 3.3.2.
3.3.1. Coexistence with normal traffic 3.3.1. Coexistence with normal traffic
A DetNet network supports the dedication of a high proportion (e.g. A DetNet network supports the dedication of a high proportion (e.g.
75%) of the network bandwidth to DetNet flows. But, no matter how 75%) of the network bandwidth to DetNet flows. But, no matter how
much is dedicated for DetNet flows, it is a goal of DetNet to coexist much is dedicated for DetNet flows, it is a goal of DetNet to coexist
with existing Class of Service schemes (e.g., DiffServ). It is also with existing Class of Service schemes (e.g., DiffServ). It is also
important that non-DetNet traffic not disrupt the DetNet flow, of important that non-DetNet traffic not disrupt the DetNet flow, of
course (see Section 3.3.2 and Section 6). For these reasons: course (see Section 3.3.2 and Section 5). For these reasons:
o Bandwidth (transmission opportunities) not utilized by a DetNet o Bandwidth (transmission opportunities) not utilized by a DetNet
flow are available to non-DetNet packets (though not to other flow are available to non-DetNet packets (though not to other
DetNet flows). DetNet flows).
o DetNet flows can be shaped or scheduled, in order to ensure that o DetNet flows can be shaped or scheduled, in order to ensure that
the highest-priority non-DetNet packet also is ensured a worst- the highest-priority non-DetNet packet also is ensured a worst-
case latency (at any given hop). case latency (at any given hop).
o When transmission opportunities for DetNet flows are scheduled in o When transmission opportunities for DetNet flows are scheduled in
skipping to change at page 34, line 17 skipping to change at page 34, line 17
maximize the compatibility of their outputs. maximize the compatibility of their outputs.
DetNet enabled end systems and intermediate nodes can be DetNet enabled end systems and intermediate nodes can be
interconnected by sub-networks, i.e., Layer-2 technologies. These interconnected by sub-networks, i.e., Layer-2 technologies. These
sub-networks will provide DetNet compatible service for support of sub-networks will provide DetNet compatible service for support of
DetNet traffic. Examples of sub-networks include 802.1TSN and a DetNet traffic. Examples of sub-networks include 802.1TSN and a
point-to-point OTN link. Of course, multi-layer DetNet systems may point-to-point OTN link. Of course, multi-layer DetNet systems may
be possible too, where one DetNet appears as a sub-network, and be possible too, where one DetNet appears as a sub-network, and
provides service to, a higher layer DetNet system. provides service to, a higher layer DetNet system.
5. Open Questions 5. Security Considerations
There are a number of architectural questions that will have to be
resolved before this document can be submitted for publication.
Aside from the obvious fact that this present draft is subject to
change, there are specific questions to which the authors wish to
direct the readers' attention.
5.1. Flat vs. hierarchical control
Boxes that are solely routers or solely bridges are rare in today's
market. In a multi-tenant data center, multiple users' virtual
Layer-2/Layer-3 topologies exist simultaneously, implemented on a
network whose physical topology bears only accidental resemblance to
the virtual topologies.
While the forwarding topology (the bridges and routers) are an
important consideration for a DetNet Flow Management Entity
(Section 4.4.1), so is the purely physical topology. Ultimately, the
model used by the management entities is based on boxes, queues, and
links. The authors hope that the work of the TEAS WG will help to
clarify exactly what model parameters need to be traded between the
intermediate nodes and the controller(s).
5.2. Peer-to-peer reservation protocol
As described in Section 4.9.2, the DetNet WG needs to decide whether
to support a peer-to-peer protocol for a source and a destination to
reserve resources for a DetNet stream. Assuming that enabling the
involvement of the source and/or destination is desirable (see
Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases]), it
remains to decide whether the DetNet WG will make it possible to
deploy at least some DetNet capabilities in a network using only a
peer-to-peer protocol, without a central controller.
(Note that a UNI (see Section 4.4.3) between an end system and a
DetNet edge node, for sources and/or listeners to request DetNet
services, can be either the first hop of a per-to-peer reservation
protocol, or can be deflected by the DetNet edge node to a central
controller for resolution. Similarly, a decision by a central
controller can be effected by the controller instructing the end
system or DetNet edge node to initiate a per-to-peer protocol
activity.)
5.3. Wireless media interactions
Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases]
illustrates cases where wireless media are needed in a DetNet
network. Some wireless media in general use, such as IEEE 802.11
[IEEE802.1Q-2014], have significantly higher packet loss rates than
typical wired media, such as Ethernet [IEEE802.3-2012]. IEEE 802.11
includes support for such features as MAC-layer acknowledgements and
retransmissions.
The techniques described in Section 3 are likely to improve the
ability of a mixed wired/wireless network to offer the DetNet QoS
features. The interaction of these techniques with the features of
specific wireless media, although they may be significant, cannot be
addressed in this document. It remains to be decided to what extent
the DetNet WG will address them, and to what extent other WGs, e.g.
6TiSCH, will do so.
5.4. Packet encoding for service protection
There are methods for using multiple paths to provide service
protection that involve encoding the information in a packet
belonging to a DetNet flow into multiple transmission units,
typically combining information from multiple packets into any given
transmission unit. Such techniques may be applicable for use as a
DetNet service protection technique, assuming that the DetNet users'
needs for timeliness of delivery and freedom from interference with
misbehaving DetNet flows can be met.
No specific mechanisms are defined here, at this time. This section
will either be enhanced or removed. Contributions are invited.
6. Security Considerations
Security in the context of Deterministic Networking has an added Security in the context of Deterministic Networking has an added
dimension; the time of delivery of a packet can be just as important dimension; the time of delivery of a packet can be just as important
as the contents of the packet, itself. A man-in-the-middle attack, as the contents of the packet, itself. A man-in-the-middle attack,
for example, can impose, and then systematically adjust, additional for example, can impose, and then systematically adjust, additional
delays into a link, and thus disrupt or subvert a real-time delays into a link, and thus disrupt or subvert a real-time
application without having to crack any encryption methods employed. application without having to crack any encryption methods employed.
See [RFC7384] for an exploration of this issue in a related context. See [RFC7384] for an exploration of this issue in a related context.
Furthermore, in a control system where millions of dollars of Furthermore, in a control system where millions of dollars of
skipping to change at page 36, line 25 skipping to change at page 34, line 45
accidental or intentional. See also Section 3.3.2. accidental or intentional. See also Section 3.3.2.
Security must cover: Security must cover:
o the protection of the signaling protocol o the protection of the signaling protocol
o the authentication and authorization of the controlling systems o the authentication and authorization of the controlling systems
o the identification and shaping of the DetNet flows o the identification and shaping of the DetNet flows
7. Privacy Considerations 6. Privacy Considerations
DetNet is provides a Quality of Service (QoS), and as such, does not DetNet is provides a Quality of Service (QoS), and as such, does not
directly raise any new privacy considerations. directly raise any new privacy considerations.
However, the requirement for every (or almost every) node along the However, the requirement for every (or almost every) node along the
path of a DetNet flow to identify DetNet flows may present an path of a DetNet flow to identify DetNet flows may present an
additional attack surface for privacy, should the DetNet paradigm be additional attack surface for privacy, should the DetNet paradigm be
found useful in broader environments. found useful in broader environments.
8. IANA Considerations 7. IANA Considerations
This document does not require an action from IANA. This document does not require an action from IANA.
9. Acknowledgements 8. Acknowledgements
The authors wish to thank Jouni Korhonen, Erik Nordmark, George The authors wish to thank Jouni Korhonen, Erik Nordmark, George
Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne, Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne,
Shitanshu Shah, Craig Gunther, Rodney Cummings, Balazs Varga, Shitanshu Shah, Craig Gunther, Rodney Cummings, Balazs Varga,
Wilfried Steiner, Marcel Kiessling, Karl Weber, Janos Farkas, Ethan Wilfried Steiner, Marcel Kiessling, Karl Weber, Janos Farkas, Ethan
Grossman, Pat Thaler, Lou Berger, and especially Michael Johas Grossman, Pat Thaler, Lou Berger, and especially Michael Johas
Teener, for their various contribution with this work. Teener, for their various contribution with this work.
10. Access to IEEE 802.1 documents 9. Access to IEEE 802.1 documents
To access password protected IEEE 802.1 drafts, see the IETF IEEE To access password protected IEEE 802.1 drafts, see the IETF IEEE
802.1 information page at https://www.ietf.org/proceedings/52/slides/ 802.1 information page at https://www.ietf.org/proceedings/52/slides/
bridge-0/tsld003.htm. bridge-0/tsld003.htm.
11. Informative References 10. Informative References
[AVnu] http://www.avnu.org/, "The AVnu Alliance tests and [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and
certifies devices for interoperability, providing a simple certifies devices for interoperability, providing a simple
and reliable networking solution for AV network and reliable networking solution for AV network
implementation based on the Audio Video Bridging (AVB) implementation based on the Audio Video Bridging (AVB)
standards.". standards.".
[CCAMP] IETF, "Common Control and Measurement Plane", [CCAMP] IETF, "Common Control and Measurement Plane",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>. <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[HART] www.hartcomm.org, "Highway Addressable Remote Transducer,
a group of specifications for industrial process and
control devices administered by the HART Foundation".
[HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a
further development of the PRP approach, although HSR further development of the PRP approach, although HSR
functions primarily as a protocol for creating media functions primarily as a protocol for creating media
redundancy while PRP, as described in the previous redundancy while PRP, as described in the previous
section, creates network redundancy. PRP and HSR are both section, creates network redundancy. PRP and HSR are both
described in the IEC 62439 3 standard.", described in the IEC 62439 3 standard.",
<http://webstore.iec.ch/webstore/webstore.nsf/ <http://webstore.iec.ch/webstore/webstore.nsf/
artnum/046615!opendocument>. artnum/046615!opendocument>.
[I-D.dt-detnet-dp-alt] [I-D.dt-detnet-dp-alt]
skipping to change at page 38, line 34 skipping to change at page 36, line 45
[I-D.svshah-tsvwg-deterministic-forwarding] [I-D.svshah-tsvwg-deterministic-forwarding]
Shah, S. and P. Thubert, "Deterministic Forwarding PHB", Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
draft-svshah-tsvwg-deterministic-forwarding-04 (work in draft-svshah-tsvwg-deterministic-forwarding-04 (work in
progress), August 2015. progress), August 2015.
[I-D.varga-detnet-service-model] [I-D.varga-detnet-service-model]
Varga, B. and J. Farkas, "DetNet Service Model", draft- Varga, B. and J. Farkas, "DetNet Service Model", draft-
varga-detnet-service-model-02 (work in progress), May varga-detnet-service-model-02 (work in progress), May
2017. 2017.
[IEEE802.11-2012]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", 2012,
<http://standards.ieee.org/getieee802/
download/802.11-2012.pdf>.
[IEEE802.1AS-2011] [IEEE802.1AS-2011]
IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", IEEE, "IEEE Std 802.1AS Timing and Synchronization for
2011, <http://standards.ieee.org/getIEEE802/ Time-Sensitive Applications in Bridged Local Area
download/802.1AS-2011.pdf>. Networks", 2011,
<http://ieeexplore.ieee.org/document/5741898/>.
[IEEE802.1BA-2011] [IEEE802.1BA-2011]
IEEE, "AVB (Audio Video Bridging) Systems (IEEE 802.1BA- IEEE, "IEEE Std 802.1BA Audio Video Bridging (AVB)
2011)", 2011, <http://standards.ieee.org/getIEEE802/ Systems", 2011,
download/802.1BA-2011.pdf>. <http://ieeexplore.ieee.org/document/6032690/>.
[IEEE802.1CB] [IEEE802.1CB]
IEEE, "Frame Replication and Elimination for Reliability IEEE, "Frame Replication and Elimination for Reliability
(IEEE Draft P802.1CB)", 2016, (IEEE Draft P802.1CB)", 2017,
<http://www.ieee802.org/1/files/private/cb-drafts/>. <http://www.ieee802.org/1/files/private/cb-drafts/>.
[IEEE802.1Q-2014] [IEEE802.1Q-2014]
IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2014", 2014, IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks",
<http://standards.ieee.org/getieee802/ 2014, <http://ieeexplore.ieee.org/document/6991462/>.
download/802-1Q-2014.pdf>.
[IEEE802.1Qbu] [IEEE802.1Qbu]
IEEE, "Frame Preemption", 2016, IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks -
<http://www.ieee802.org/1/files/private/bu-drafts/>. Amendment 26: Frame Preemption", 2016,
<http://ieeexplore.ieee.org/document/7553415/>.
[IEEE802.1Qbv] [IEEE802.1Qbv]
IEEE, "Enhancements for Scheduled Traffic", 2016, IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks -
<http://www.ieee802.org/1/files/private/bv-drafts/>. Amendment 25: Enhancements for Scheduled Traffic", 2015,
<http://ieeexplore.ieee.org/document/7572858/>.
[IEEE802.1Qca] [IEEE802.1Qca]
IEEE 802.1, "IEEE 802.1Qca Bridges and Bridged Networks - IEEE, "IEEE Std 802.1Qca Bridges and Bridged Networks -
Amendment 24: Path Control and Reservation", IEEE Amendment 24: Path Control and Reservation", June 2015,
P802.1Qca/D2.1 P802.1Qca, June 2015, <http://ieeexplore.ieee.org/document/7565435/>.
<https://standards.ieee.org/findstds/standard/802.1Qca-
2015.html>.
[IEEE802.1Qcc] [IEEE802.1Qcc]
IEEE, "Stream Reservation Protocol (SRP) Enhancements and IEEE, "Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", 2016, Performance Improvements (IEEE Draft P802.1Qcc)", 2017,
<http://www.ieee802.org/1/files/private/cc-drafts/>. <http://www.ieee802.org/1/files/private/cc-drafts/>.
[IEEE802.1Qch] [IEEE802.1Qch]
IEEE, "Cyclic Queuing and Forwarding", 2016, IEEE, "Cyclic Queuing and Forwarding (IEEE Draft
P802.1Qch)", 2017,
<http://www.ieee802.org/1/files/private/ch-drafts/>. <http://www.ieee802.org/1/files/private/ch-drafts/>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networks Task Group", 2013, Networks Task Group", 2013,
<http://www.IEEE802.org/1/pages/avbridges.html>. <http://www.IEEE802.org/1/pages/avbridges.html>.
[IEEE802.3-2012] [IEEE802.3-2015]
IEEE, "IEEE Standard for Ethernet", 2012, IEEE, "IEEE Std 802.3 Standard for Ethernet", 2015,
<http://standards.ieee.org/getieee802/ <http://ieeexplore.ieee.org/document/7428776/>.
download/802.3-2012.pdf>.
[IEEE802.3br] [IEEE802.3br]
IEEE, "Interspersed Express Traffic", 2016, IEEE, "IEEE Std 802.3br Standard for Ethernet Amendment 5:
<http://www.ieee802.org/3/br/>. Specification and Management Parameters for Interspersing
Express Traffic", 2016,
[IEEE802154] <http://ieeexplore.ieee.org/document/7900321/>.
IEEE Standard for Information Technology, "IEEE 802.15.4,
Part. 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless
Personal Area Networks", June 2011.
[IEEE802154e]
IEEE Standard for Information Technology, "IEEE 802.15.4e,
Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 1: MAC sublayer", April 2012.
[ISA100.11a]
ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
also IEC 62734", 2011, < http://www.isa100wci.org/en-
US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
WEB-ETSI.aspx>.
[ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1: [ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1:
Models and Terminology", 2000, <https://www.isa.org/ Models and Terminology", 2000, <https://www.isa.org/
isa95/>. isa95/>.
[ODVA] http://www.odva.org/, "The organization that supports [ODVA] http://www.odva.org/, "The organization that supports
network technologies built on the Common Industrial network technologies built on the Common Industrial
Protocol (CIP) including EtherNet/IP.". Protocol (CIP) including EtherNet/IP.".
[PCE] IETF, "Path Computation Element", [PCE] IETF, "Path Computation Element",
skipping to change at page 42, line 28 skipping to change at page 40, line 14
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <http://www.rfc-editor.org/info/rfc7426>. 2015, <http://www.rfc-editor.org/info/rfc7426>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling", [TEAS] IETF, "Traffic Engineering Architecture and Signaling",
<https://datatracker.ietf.org/doc/charter-ietf-teas/>. <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[WirelessHART]
www.hartcomm.org, "Industrial Communication Networks -
Wireless Communication Network and Communication Profiles
- WirelessHART - IEC 62591", 2010.
Authors' Addresses Authors' Addresses
Norman Finn Norman Finn
Huawei Technologies Co. Ltd Huawei Technologies Co. Ltd
3755 Avocado Blvd. 3755 Avocado Blvd.
PMB 436 PMB 436
La Mesa, California 91941 La Mesa, California 91941
US US
Phone: +1 925 980 6430 Phone: +1 925 980 6430
 End of changes. 31 change blocks. 
176 lines changed or deleted 68 lines changed or added

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