draft-ietf-detnet-architecture-10.txt   draft-ietf-detnet-architecture-11.txt 
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: June 22, 2019 Cisco Expires: August 10, 2019 Cisco
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
December 19, 2018 February 6, 2019
Deterministic Networking Architecture Deterministic Networking Architecture
draft-ietf-detnet-architecture-10 draft-ietf-detnet-architecture-11
Abstract Abstract
This document provides the overall architecture for Deterministic This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability to carry specified Networking (DetNet), which provides a capability to carry specified
unicast or multicast data flows for real-time applications with unicast or multicast data flows for real-time applications with
extremely low data loss rates and bounded latency within a network extremely low data loss rates and bounded latency within a network
domain. Techniques used include: 1) reserving data plane resources domain. Techniques used include: 1) reserving data plane resources
for individual (or aggregated) DetNet flows in some or all of the for individual (or aggregated) DetNet flows in some or all of the
intermediate nodes along the path of the flow; 2) providing explicit intermediate nodes along the path of the flow; 2) providing explicit
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 June 22, 2019. This Internet-Draft will expire on August 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.2.1.1. Eliminate contention loss . . . . . . . . . . . . 10 3.2.1.1. Eliminate contention loss . . . . . . . . . . . . 10
3.2.1.2. Jitter Reduction . . . . . . . . . . . . . . . . 10 3.2.1.2. Jitter Reduction . . . . . . . . . . . . . . . . 10
3.2.2. Service Protection . . . . . . . . . . . . . . . . . 11 3.2.2. Service Protection . . . . . . . . . . . . . . . . . 11
3.2.2.1. In-Order Delivery . . . . . . . . . . . . . . . . 11 3.2.2.1. In-Order Delivery . . . . . . . . . . . . . . . . 11
3.2.2.2. Packet Replication and Elimination . . . . . . . 12 3.2.2.2. Packet Replication and Elimination . . . . . . . 12
3.2.2.3. Packet encoding for service protection . . . . . 14 3.2.2.3. Packet encoding for service protection . . . . . 14
3.2.3. Explicit routes . . . . . . . . . . . . . . . . . . . 14 3.2.3. Explicit routes . . . . . . . . . . . . . . . . . . . 14
3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 15 3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 15
3.3.1. Coexistence with normal traffic . . . . . . . . . . . 15 3.3.1. Coexistence with normal traffic . . . . . . . . . . . 15
3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 16 3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 16
4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 16 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 17
4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 16 4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 17
4.1.1. Representative Protocol Stack Model . . . . . . . . . 16 4.1.1. Representative Protocol Stack Model . . . . . . . . . 17
4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 19 4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 19
4.1.3. Network reference model . . . . . . . . . . . . . . . 21 4.1.3. Network reference model . . . . . . . . . . . . . . . 21
4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 22 4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 23
4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 23
4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 23 4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 24
4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 24 4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 24 4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 24
4.3.2. Source transmission behavior . . . . . . . . . . . . 24 4.3.2. Source transmission behavior . . . . . . . . . . . . 25
4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 26 4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 26
4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 26 4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 26
4.4.1. The Application Plane . . . . . . . . . . . . . . . . 27 4.4.1. The Application Plane . . . . . . . . . . . . . . . . 27
4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 27 4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 27
4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 28 4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 28
4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 29 4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 29
4.6. Service instance . . . . . . . . . . . . . . . . . . . . 30 4.6. Service instance . . . . . . . . . . . . . . . . . . . . 30
4.7. Flow identification at technology borders . . . . . . . . 31 4.7. Flow identification at technology borders . . . . . . . . 31
4.7.1. Exporting flow identification . . . . . . . . . . . . 31 4.7.1. Exporting flow identification . . . . . . . . . . . . 32
4.7.2. Flow attribute mapping between layers . . . . . . . . 33 4.7.2. Flow attribute mapping between layers . . . . . . . . 33
4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 34 4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 34
4.8. Advertising resources, capabilities and adjacencies . . . 35 4.8. Advertising resources, capabilities and adjacencies . . . 36
4.9. Scaling to larger networks . . . . . . . . . . . . . . . 36 4.9. Scaling to larger networks . . . . . . . . . . . . . . . 36
4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 36 4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
9. Informative References . . . . . . . . . . . . . . . . . . . 38 9. Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document provides the overall architecture for Deterministic This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability for the delivery of Networking (DetNet), which provides a capability for the delivery of
data flows with extremely low packet loss rates and bounded end-to- data flows with extremely low packet loss rates and bounded end-to-
end delivery latency. DetNet is for networks that are under a single end delivery latency. DetNet is for networks that are under a single
administrative control or within a closed group of administrative administrative control or within a closed group of administrative
skipping to change at page 8, line 34 skipping to change at page 8, line 34
o Service protection (Section 3.2.2). o Service protection (Section 3.2.2).
o Explicit routes (Section 3.2.3). o Explicit routes (Section 3.2.3).
Resource allocation operates by assigning resources, e.g., buffer Resource allocation operates by assigning resources, e.g., buffer
space or link bandwidth, to a DetNet flow (or flow aggregate) along space or link bandwidth, to a DetNet flow (or flow aggregate) along
its path. Resource allocation greatly reduces, or even eliminates its path. Resource allocation greatly reduces, or even eliminates
entirely, packet loss due to output packet contention within the entirely, packet loss due to output packet contention within the
network, but it can only be supplied to a DetNet flow that is limited network, but it can only be supplied to a DetNet flow that is limited
at the source to a maximum packet size and transmission rate. Note at the source to a maximum packet size and transmission rate. As
that congestion control provided via congestion detection and DetNet provides allocated resources (including provisioned capacity)
notification [RFC3168] is explicitly excluded from consideration in to DetNet flows the use of transport layer congestion control
DetNet, as it serves a different set of applications. [RFC2914] by App-flows is explicitly not required.
Resource allocation addresses two of the DetNet QoS requirements: Resource allocation addresses two of the DetNet QoS requirements:
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, resource allocation necessarily results in a amount of buffer space, resource allocation necessarily results in a
maximum end-to-end latency. It also addresses contention related maximum end-to-end latency. It also addresses contention related
packet loss. packet loss.
Other important contribution to packet loss are random media errors Other important contribution to packet loss are random media errors
and equipment failures. Service protection is the name for the and equipment failures. Service protection is the name for the
mechanisms used by DetNet to address these losses. The mechanisms mechanisms used by DetNet to address these losses. The mechanisms
skipping to change at page 10, line 23 skipping to change at page 10, line 23
3.2.1. Resource allocation 3.2.1. Resource allocation
3.2.1.1. Eliminate contention loss 3.2.1.1. Eliminate contention loss
The primary means by which DetNet achieves its QoS assurances is to The primary means by which DetNet achieves its QoS assurances is to
reduce, or even completely eliminate packet loss due to output packet reduce, or even completely eliminate packet loss due to output packet
contention within a DetNet node as a cause of packet loss. This can contention within a DetNet node as a cause of packet loss. This can
be achieved only by the provision of sufficient buffer storage at be achieved only by the provision of sufficient buffer storage at
each node through the network to ensure that no packets are dropped each node through the network to ensure that no packets are dropped
due to a lack of buffer storage. Note that a DetNet flow cannot be due to a lack of buffer storage. Note that App-flows are generally
throttled, i.e., its transmission rate cannot be reduced via explicit not expected to be responsive to implicit [RFC2914] or explicit
congestion notification [RFC3168]. congestion notification [RFC3168].
Ensuring adequate buffering requires, in turn, that the source, and Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow. particular DetNet flow.
skipping to change at page 16, line 18 skipping to change at page 16, line 18
failures. Filters and policers should be used in a DetNet network to failures. Filters and policers should be used in a DetNet network to
detect if DetNet packets are received on the wrong interface, or at detect if DetNet packets are received on the wrong interface, or at
the wrong time, or in too great a volume. Furthermore, filters and the wrong time, or in too great a volume. Furthermore, filters and
policers can take actions to discard the offending packets or flows, policers can take actions to discard the offending packets or flows,
or trigger shutting down the offending flow or the offending or trigger shutting down the offending flow or the offending
interface. interface.
It is also essential that filters and service remarking be employed It is also essential that filters and service remarking be employed
at the network edge to prevent non-DetNet packets from being mistaken at the network edge to prevent non-DetNet packets from being mistaken
for DetNet packets, and thus impinging on the resources allocated to for DetNet packets, and thus impinging on the resources allocated to
DetNet packets. DetNet packets. In particular, sending DetNet traffic into networks
that have not been provisioned in advance to handle that DetNet
traffic has to be treated as a fault. The use of egress traffic
filters, or equivalent mechanisms, to prevent this from happening are
strongly recommended at the edges of a DetNet networks and DetNet
supporting networks. In this context, the term 'provisioned' has a
broad meaning, e.g., provisioning could be performed via an
administrative decision that the downstream network has the available
capacity to carry the DetNet traffic that is being sent into it.
There exist techniques, at present and/or in various stages of Note that the sending of App-flows that do not use transport layer
standardization, that can perform these fault mitigation tasks that congestion control per [RFC2914] into a network that is not
provisioned to handle such DetNet traffic has to be treated as a
fault and prevented. PRF generated DetNet member flows also need to
be treated as not using transport layer congestion control even if
the original App-flow supports transport layer congestion control
because PREOF can remove congestion indications at the PEF and
thereby hide such indications (e.g., drops, ECN markings, increased
latency) from end systems.
The mechanisms to support these requirements are both data plane and
implementation specific. Data plane specific solutions will be
specified in the relevant data plane solution document. There also
exist techniques, at present and/or in various stages of
standardization, that can support these fault mitigation tasks that
deliver a high probability that misbehaving systems will have zero deliver a high probability that misbehaving systems will have zero
impact on well-behaved DetNet flows, except of course, for the impact on well-behaved DetNet flows, except of course, for the
receiving interface(s) immediately downstream of the misbehaving receiving interface(s) immediately downstream of the misbehaving
device. Examples of such techniques include traffic policing device. Examples of such techniques include traffic policing
functions (e.g., [RFC2475]) and separating flows into per-flow rate- functions (e.g., [RFC2475]) and separating flows into per-flow rate-
limited queues. limited queues.
4. DetNet Architecture 4. DetNet Architecture
4.1. DetNet stack model 4.1. DetNet stack model
skipping to change at page 25, line 34 skipping to change at page 26, line 5
The source is required not to exceed these limits in order to obtain The source is required not to exceed these limits in order to obtain
DetNet service. If the source transmits less data than this limit DetNet service. If the source transmits less data than this limit
allows, the unused resource such as link bandwidth can be made allows, the unused resource such as link bandwidth can be made
available by the DetNet system to non-DetNet packets as long as all available by the DetNet system to non-DetNet packets as long as all
guarantees are fulfilled. However, making those resources available guarantees are fulfilled. However, making those resources available
to DetNet packets in other DetNet flows would serve no purpose. to DetNet packets in other DetNet flows would serve no purpose.
Those other DetNet flows have their own dedicated resources, on the Those other DetNet flows have their own dedicated resources, on the
assumption that all DetNet flows can use all of their resources over assumption that all DetNet flows can use all of their resources over
a long period of time. a long period of time.
There is no provision in DetNet for throttling DetNet flows, i.e., There is no expectation in DetNet for App-flows to be responsive to
the transmission rate cannot be reduced via explicit congestion implicit [RFC2914] or explicit congestion notification [RFC3168].
notification [RFC3168]. The assumption is that a DetNet flow, to be The assumption is that a DetNet flow, to be useful, must be delivered
useful, must be delivered in its entirety. That is, while any useful in its entirety. That is, while any useful application is written to
application is written to expect a certain number of lost packets, expect a certain number of lost packets, the real-time applications
the real-time applications of interest to DetNet demand that the loss of interest to DetNet demand that the loss of data due to the network
of data due to the network is a rare event. is a rare event.
Although DetNet strives to minimize the changes required of an Although DetNet strives to minimize the changes required of an
application to allow it to shift from a special-purpose digital application to allow it to shift from a special-purpose digital
network to an Internet Protocol network, one fundamental shift in the network to an Internet Protocol network, one fundamental shift in the
behavior of network applications is impossible to avoid: the behavior of network applications is impossible to avoid: the
reservation of resources before the application starts. In the first reservation of resources before the application starts. In the first
place, a network cannot deliver finite latency and practically zero place, a network cannot deliver finite latency and practically zero
packet loss to an arbitrarily high offered load. Secondly, achieving packet loss to an arbitrarily high offered load. Secondly, achieving
practically zero packet loss for unthrottled (though bandwidth practically zero packet loss for DetNet flows means that DetNet nodes
limited) DetNet flows means that DetNet nodes have to dedicate buffer have to dedicate buffer resources to specific DetNet flows or to
resources to specific DetNet flows or to classes of DetNet flows. classes of DetNet flows. The requirements of each reservation have
to be translated into the parameters that control each DetNet
The requirements of each reservation have to be translated into the system's queuing, shaping, and scheduling functions and delivered to
parameters that control each DetNet system's queuing, shaping, and the DetNet nodes and end systems.
scheduling functions and delivered to the DetNet nodes and end
systems.
All nodes in a DetNet domain are expected to support the data All nodes in a DetNet domain are expected to support the data
behavior required to deliver a particular DetNet service. If a node behavior required to deliver a particular DetNet service. If a node
itself is not DetNet service aware, the DetNet nodes that are itself is not DetNet service aware, the DetNet nodes that are
adjacent to such non-DetNet aware nodes must ensure that the non- adjacent to such non-DetNet aware nodes must ensure that the non-
DetNet aware node is provisioned to appropriately support the DetNet DetNet aware node is provisioned to appropriately support the DetNet
service. For example, an IEEE 802.1 TSN node may be used to service. For example, an IEEE 802.1 TSN node may be used to
interconnect DetNet aware nodes, and these DetNet nodes can map interconnect DetNet aware nodes, and these DetNet nodes can map
DetNet flows to 802.1 TSN flows. Another example, an MPLS-TE or TP DetNet flows to 802.1 TSN flows. Another example, an MPLS-TE or TP
domain may be used to interconnect DetNet aware nodes, and these domain may be used to interconnect DetNet aware nodes, and these
skipping to change at page 38, line 28 skipping to change at page 38, line 37
Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-detnet-problem-statement] [I-D.ietf-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-ietf-detnet-problem-statement-08 (work Statement", draft-ietf-detnet-problem-statement-09 (work
in progress), December 2018. in progress), December 2018.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-03 (work in progress), October 2018. detnet-security-03 (work in progress), October 2018.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018. ietf-detnet-use-cases-20 (work in progress), December
2018.
[IEC62439-3-2016] [IEC62439-3-2016]
International Electrotechnical Commission (IEC) TC 65/SC International Electrotechnical Commission (IEC) TC 65/SC
65C - Industrial networks, "IEC 62439-3:2016 Industrial 65C - Industrial networks, "IEC 62439-3:2016 Industrial
communication networks - High availability automation communication networks - High availability automation
networks - Part 3: Parallel Redundancy Protocol (PRP) and networks - Part 3: Parallel Redundancy Protocol (PRP) and
High-availability Seamless Redundancy (HSR)", 2016, High-availability Seamless Redundancy (HSR)", 2016,
<https://webstore.iec.ch/publication/24447>. <https://webstore.iec.ch/publication/24447>.
[IEEE802.1BA] [IEEE802.1BA]
skipping to change at page 39, line 41 skipping to change at page 40, line 7
<https://ieeexplore.ieee.org/document/7572858/>. <https://ieeexplore.ieee.org/document/7572858/>.
[IEEE802.1Qch] [IEEE802.1Qch]
IEEE Standards Association, "IEEE Std 802.1Qch-2017 IEEE Standards Association, "IEEE Std 802.1Qch-2017
Bridges and Bridged Networks - Amendment 29: Cyclic Bridges and Bridged Networks - Amendment 29: Cyclic
Queuing and Forwarding", 2017, Queuing and Forwarding", 2017,
<https://ieeexplore.ieee.org/document/7961303/>. <https://ieeexplore.ieee.org/document/7961303/>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networking Task Group", 2013, Networking Task Group", <http://www.ieee802.org/1/tsn>.
<http://www.ieee802.org/1/tsn>.
[IEEE802.3-2018] [IEEE802.3-2018]
IEEE Standards Association, "IEEE Std 802.3-2018 Standard IEEE Standards Association, "IEEE Std 802.3-2018 Standard
for Ethernet", 2018, for Ethernet", 2018,
<https://ieeexplore.ieee.org/document/8457469>. <https://ieeexplore.ieee.org/document/8457469>.
[IEEE802.3br] [IEEE802.3br]
IEEE Standards Association, "IEEE Std 802.3br-2016 IEEE Standards Association, "IEEE Std 802.3br-2016
Standard for Ethernet Amendment 5: Specification and Standard for Ethernet Amendment 5: Specification and
Management Parameters for Interspersing Express Traffic", Management Parameters for Interspersing Express Traffic",
skipping to change at page 40, line 21 skipping to change at page 40, line 30
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
 End of changes. 22 change blocks. 
44 lines changed or deleted 67 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/