< draft-ietf-detnet-data-plane-framework-03.txt   draft-ietf-detnet-data-plane-framework-04.txt >
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: April 29, 2020 L. Berger Expires: August 6, 2020 L. Berger
D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Independent Independent
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen February 3, 2020
October 27, 2019
DetNet Data Plane Framework DetNet Data Plane Framework
draft-ietf-detnet-data-plane-framework-03 draft-ietf-detnet-data-plane-framework-04
Abstract Abstract
This document provides an overall framework for the DetNet data This document provides an overall framework for the DetNet data
plane. It covers concepts and considerations that are generally plane. It covers concepts and considerations that are generally
common to any Deterministic Networking data plane specification. common to any Deterministic Networking data plane specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 40 skipping to change at page 1, line 38
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 April 29, 2020. This Internet-Draft will expire on August 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 5 3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 4
3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6 3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6
3.1.1. Data Plane Technology . . . . . . . . . . . . . . . . 6 3.1.1. Data Plane Technology . . . . . . . . . . . . . . . . 6
3.1.2. Data Plane Format . . . . . . . . . . . . . . . . . . 6 3.1.2. Data Plane Format . . . . . . . . . . . . . . . . . . 6
3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7 3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7
3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8 3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8
3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 9 3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 9
3.6. Further DetNet Data Plane Considerations . . . . . . . . 9 3.6. Further DetNet Data Plane Considerations . . . . . . . . 9
3.6.1. Per Flow Related Functions . . . . . . . . . . . . . 9 3.6.1. Per Flow Related Functions . . . . . . . . . . . . . 9
3.6.2. Service Protection . . . . . . . . . . . . . . . . . 11 3.6.2. Service Protection . . . . . . . . . . . . . . . . . 11
skipping to change at page 2, line 43 skipping to change at page 2, line 41
4.1. DetNet Controller Plane Requirements . . . . . . . . . . 16 4.1. DetNet Controller Plane Requirements . . . . . . . . . . 16
4.2. Generic Controller Plane Considerations . . . . . . . . . 17 4.2. Generic Controller Plane Considerations . . . . . . . . . 17
4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 18 4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 18
4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 19 4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 19
4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19 4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19
4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 20 4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 20
4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 21 4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
DetNet (Deterministic Networking) provides a capability to carry DetNet (Deterministic Networking) 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 packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [I-D.ietf-detnet-architecture]. concepts of DetNet can be found in [RFC8655].
This document describes the concepts needed by any DetNet data plane This document describes the concepts needed by any DetNet data plane
specification and provides considerations for any corresponding specification and provides considerations for any corresponding
implementation. It covers the building blocks that provide the implementation. It covers the building blocks that provide the
DetNet service, the DetNet service sub-layer and the DetNet DetNet service, the DetNet service sub-layer and the DetNet
forwarding sub-layer functions as described in the DetNet forwarding sub-layer functions as described in the DetNet
Architecture. Architecture.
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service protection and reordering. The forwarding sub-layer DetNet service protection and reordering. The forwarding sub-layer
leverages Traffic Engineering mechanisms and provides congestion leverages Traffic Engineering mechanisms and provides congestion
protection (low loss, assured latency, and limited out-of-order protection (low loss, assured latency, and limited out-of-order
delivery). delivery). A particular forwarding sub-layer may have capabilities
that are not available on other forwarding-sub layers. DetNet makes
use of the existing forwarding sub-layers with their respective
capabilities and does not require 1:1 equivalence between different
forwarding sub-layer capabilities.
As part of the service sub-layer functions, this document describes As part of the service sub-layer functions, this document describes
typical DetNet node data plane operation. It describes the function typical DetNet node data plane operation. It describes the function
and operation of the Packet Replication (PRF) Packet Elimination and operation of the Packet Replication (PRF) Packet Elimination
(PEF) and the Packet Ordering (POF) functions within the service sub- (PEF) and the Packet Ordering (POF) functions within the service sub-
layer. Furthermore, it also describes the forwarding sub-layer. layer. Furthermore, it also describes the forwarding sub-layer.
DetNet flows may be carried over network technologies that can DetNet flows may be carried over network technologies that can
provide the DetNet required service characteristics. For example, provide the DetNet required service characteristics. For example,
DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive
Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN
support is not required and some of the DetNet benefits can be gained support is not required in DetNet. TSN frame preemption is an
by running over a data link layer that has not been specifically example of a forwarding layer capability that is typically not
enhanced to support TSN. replicated in other forwarding technologies. Most of DetNet benefits
can be gained by running over a data link layer that has not been
specifically enhanced to support all TSN capabilities but for certain
networks and traffic mixes delay and jitter performance may vary due
to the forwarding sub-layer intrinsic properties.
Different application flows (e.g., Ethernet, IP, etc.), can be mapped Different application flows (e.g., Ethernet, IP, etc.), can be mapped
on top of DetNet. DetNet can optionally reuse header information on top of DetNet. DetNet can optionally reuse header information
provided by, or shared with, applications. An example of shared provided by, or shared with, applications. An example of shared
header fields can be found in [I-D.ietf-detnet-ip]. header fields can be found in [I-D.ietf-detnet-ip].
This document also covers basic concepts related to the controller This document also covers basic concepts related to the controller
plane and Operations, Administration, and Maintenance (OAM). Data plane and Operations, Administration, and Maintenance (OAM). Data
plane OAM specifics are out of scope for this docuement. plane OAM specifics are out of scope for this document.
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [I-D.ietf-detnet-architecture], and the reader is architecture [RFC8655], and the reader is assumed to be familiar with
assumed to be familiar with that document and its terminology. that document and its terminology.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
BGP Border Gateway Protocol.
CW Control Word. CW Control Word.
d-CW DetNet Control Word. d-CW DetNet Control Word.
DetNet Deterministic Networking. DetNet Deterministic Networking.
DN DetNet. DN DetNet.
GMPLS Generalized Multiprotocol Label Switching.
GRE Generic Routing Encapsulation. GRE Generic Routing Encapsulation.
IPSec IP Security. IPSec IP Security.
L2 Layer 2. L2 Layer 2.
LSP Label Switched Path.
LSR Label Switching Router. LSR Label Switching Router.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
MPLS-TE Multiprotocol Label Switching - Traffic Engineering. MPLS-TE Multiprotocol Label Switching - Traffic Engineering.
OAM Operations, Administration, and Maintenance. OAM Operations, Administration, and Maintenance.
PCEP Path Computation Element Communication Protocol.
PEF Packet Elimination Function. PEF Packet Elimination Function.
PRF Packet Replication Function. PRF Packet Replication Function.
PREOF Packet Replication, Elimination and Ordering Functions. PREOF Packet Replication, Elimination and Ordering Functions.
POF Packet Ordering Function. POF Packet Ordering Function.
PSN Packet Switched Network. PSN Packet Switched Network.
PW PseudoWire. PW PseudoWire.
QoS Quality of Service. QoS Quality of Service.
S-Label DetNet "service" label. S-Label DetNet "service" label.
TDM Time-Division Multiplexing. TDM Time-Division Multiplexing.
TSN Time-Sensitive Network. TSN Time-Sensitive Network.
YANG Yet Another Next Generation.
3. DetNet Data Plane Overview 3. DetNet Data Plane Overview
This document describes how application flows, or app-flows, are This document describes how application flows, or app-flows, are
carried over DetNet networks. The DetNet Architecture, carried over DetNet networks. The DetNet Architecture, [RFC8655],
[I-D.ietf-detnet-architecture], models the DetNet related data plane models the DetNet related data plane functions as decomposed into two
functions as decomposed into two sub-layers: a service sub-layer and sub-layers: a service sub-layer and a forwarding sub-layer.
a forwarding sub-layer.
Figure 1 reproduced from the [I-D.ietf-detnet-architecture],shows a Figure 1 reproduced from the [RFC8655],shows a logical DetNet service
logical DetNet service with the two sub-layers. with the two sub-layers.
| packets going | ^ packets coming ^ | packets going | ^ packets coming ^
v down the stack v | up the stack | v down the stack v | up the stack |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Source | | Destination | | Source | | Destination |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Service sub-layer: | | Service sub-layer: | | Service sub-layer: | | Service sub-layer: |
| Packet sequencing | | Duplicate elimination | | Packet sequencing | | Duplicate elimination |
| Flow replication | | Flow merging | | Flow replication | | Flow merging |
| Packet encoding | | Packet decoding | | Packet encoding | | Packet decoding |
skipping to change at page 6, line 6 skipping to change at page 5, line 38
Alternatively, an overlay approach may be used in which the packet is Alternatively, an overlay approach may be used in which the packet is
natively carried between key nodes within the DetNet network (say natively carried between key nodes within the DetNet network (say
between PREOF nodes) and a sub-layer is used to provide the between PREOF nodes) and a sub-layer is used to provide the
information needed to reach the next hop in the overlay. information needed to reach the next hop in the overlay.
The forwarding sub-layer provides the QoS related functions needed by The forwarding sub-layer provides the QoS related functions needed by
the DetNet flow. It may do this directly through the use of queuing the DetNet flow. It may do this directly through the use of queuing
techniques and traffic engineering methods, or it may do this through techniques and traffic engineering methods, or it may do this through
the assistance of its underlying connectivity. For example it may the assistance of its underlying connectivity. For example it may
call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
[IEEE802.1TSNTG]. [IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for
packet queuing, as well as reservation and allocation of bandwidth
capacity resources.
The service sub-layer provides additional support beyond the The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer. An example of connectivity function of the forwarding sub-layer. An example of
this is Packet Replication, Elimination, and Ordering functions see this is Packet Replication, Elimination, and Ordering functions see
Section 4.3. Section 4.3. The ordering (POF) uses sequence numbers added to
packets enabling a range of packet order protection from simple
ordering and dropping out-of-order packets to more complex reordering
of a fixed number of out-of-order, minimally delayed packets.
Reordering requires buffer resources and has impact on the delay and
jitter of packets in the DetNet flow.
The method of instantiating each of the layers is specific to the The method of instantiating each of the layers is specific to the
particular DetNet data plane method, and more than one approach may particular DetNet data plane method, and more than one approach may
be applicable to a given bearer network type. be applicable to a given bearer network type.
3.1. Data Plane Characteristics 3.1. Data Plane Characteristics
There are two major characteristics to the data plane: the technology There are two major characteristics to the data plane: the technology
and the encapsulation, as discussed below. and the encapsulation, as discussed below.
skipping to change at page 6, line 40 skipping to change at page 6, line 32
it may be achieved by other technologies (e.g., Figure 2). DetNet is it may be achieved by other technologies (e.g., Figure 2). DetNet is
currently defined for operation over packet switched (IP) networks or currently defined for operation over packet switched (IP) networks or
label switched (MPLS) networks. label switched (MPLS) networks.
3.1.2. Data Plane Format 3.1.2. Data Plane Format
DetNet encodes specific flow attributes (flow identity and sequence DetNet encodes specific flow attributes (flow identity and sequence
number) in packets. For example, in DetNet IP, zero encapsulation is number) in packets. For example, in DetNet IP, zero encapsulation is
used and no sequence number is available, and in DetNet MPLS, DetNet used and no sequence number is available, and in DetNet MPLS, DetNet
specific information may be added explicitly to the packets in the specific information may be added explicitly to the packets in the
format of S-label and d-CW. format of S-label and d-CW [I-D.ietf-detnet-mpls] .
3.2. Encapsulation 3.2. Encapsulation
The encapsulation of a DetNet flow allows it to be sent over a data The encapsulation of a DetNet flow allows it to be sent over a data
plane technology other than its native type. DetNet uses header plane technology other than its native type. DetNet uses header
information to perform traffic classification, i.e., identify DetNet information to perform traffic classification, i.e., identify DetNet
flows, and provide DetNet service and forwarding functions. As flows, and provide DetNet service and forwarding functions. As
mentioned above, DetNet may add headers, as is the case for DN MPLS, mentioned above, DetNet may add headers, as is the case for DN MPLS,
or may use headers that are already present, as is the case in DN IP. or may use headers that are already present, as is the case in DN IP.
Figure 2 illustrates some relationships between the components. Figure 2 illustrates some relationships between the components.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
detail in [I-D.ietf-detnet-ip]. detail in [I-D.ietf-detnet-ip].
The DetNet forwarding plane may use explicit route capabilities and The DetNet forwarding plane may use explicit route capabilities and
traffic engineering capabilities to provide a forwarding sub-layer traffic engineering capabilities to provide a forwarding sub-layer
that is responsible for providing resource allocation and explicit that is responsible for providing resource allocation and explicit
routes. It is possible to include such information in a native IP routes. It is possible to include such information in a native IP
packet explicitly, or implicitly. packet explicitly, or implicitly.
3.5. DetNet MPLS Data Plane 3.5. DetNet MPLS Data Plane
MPLS provides the ability to forward traffic over implicit and MPLS provides a forwarding sub-layer for traffic over implicit and
explicit paths to the point in the network where the next DetNet explicit paths to the point in the network where the next DetNet
service sub-layer action needs to take place. It does this through service sub-layer action needs to take place. It does this through
the use of a stack of one or more labels with various forwarding the use of a stack of one or more labels with various forwarding
semantics. semantics.
MPLS also provides the ability to identify a service instance that is MPLS also provides the ability to identify a service instance that is
used to process the packet through the use of a label that maps the used to process the packet through the use of a label that maps the
packet to a service instance. packet to a service instance.
In cases where metadata is needed to process an MPLS encapsulated In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, a shim layer called a control word packet at the service sub-layer, the d-CW [I-D.ietf-detnet-mpls],
(CW) [RFC4385] can be used. Although such CWs are frequently 32 bits [RFC4385],can be used. Although such d-CWs are frequently 32 bits
long, there is no architectural constraint on its size of this long, there is no architectural constraint on its size of this
structure, only the requirement that it is fully understood by all structure, only the requirement that it is fully understood by all
parties operating on it in the DetNet service sub-layer. The parties operating on it in the DetNet service sub-layer. The
operation of this method is described in detail in operation of this method is described in detail in
[I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls].
3.6. Further DetNet Data Plane Considerations 3.6. Further DetNet Data Plane Considerations
This section provides informative considerations related to providing This section provides informative considerations related to providing
DetNet service to flows which are identified based on their header DetNet service to flows which are identified based on their header
skipping to change at page 9, line 45 skipping to change at page 9, line 45
basis. basis.
3.6.1.1. Reservation and Allocation of resources 3.6.1.1. Reservation and Allocation of resources
Reservation of resources can allocate resources to specific DetNet Reservation of resources can allocate resources to specific DetNet
flows. This can eliminate packet contention and packet loss for flows. This can eliminate packet contention and packet loss for
DetNet traffic. This also can reduce jitter for DetNet traffic. DetNet traffic. This also can reduce jitter for DetNet traffic.
Resources allocated to a DetNet flow protect it from other traffic Resources allocated to a DetNet flow protect it from other traffic
flows. On the other hand, DetNet flows are assumed to behave with flows. On the other hand, DetNet flows are assumed to behave with
respect to the reserved traffic profile. Misbehaving DetNet flows respect to the reserved traffic profile. Misbehaving DetNet flows
must be detected and it have to be ensured that they do not must be able to be detected and ensure that they do not compromise
compromise QoS of other flows. The use of (queuing, policing, QoS of other flows. Queuing, policing, and shaping policies can be
shaping) policies can be used to ensure that the allocation of used to ensure that the allocation of resources reserved for DetNet
resources reserved for DetNet is met. is met.
3.6.1.2. Explicit routes 3.6.1.2. Explicit routes
Use of a specific path for a flow. This allows control of the Use of a specific path for a flow. This allows control of the
network delay by steering the packet with the ability to influence network delay by steering the packet with the ability to influence
the physical path. Explicit routes complement reservation by the physical path. Explicit routes complement reservation by
ensuring that a consistent path can be associated with its resources ensuring that a consistent path can be associated with its resources
for the duration of that path. Coupled with the traffic mechanism, for the duration of that path. Coupled with the traffic mechanism,
this limits misordering and bounds latency. Explicit route this limits misordering and bounds latency. Explicit route
computation can encompass a wide set of constraints and optimize the computation can encompass a wide set of constraints and optimize the
skipping to change at page 10, line 36 skipping to change at page 10, line 36
number of protection schemes. MPLS hitless protection can be used to number of protection schemes. MPLS hitless protection can be used to
switch traffic to an already established path in order to restore switch traffic to an already established path in order to restore
delivery rapidly after a failure. Path changes, even in the case of delivery rapidly after a failure. Path changes, even in the case of
failure recovery, can lead to the out of order delivery of data failure recovery, can lead to the out of order delivery of data
requiring packet ordering functions either within the DetNet service requiring packet ordering functions either within the DetNet service
or at a high layer in the application traffic. Establishment of new or at a high layer in the application traffic. Establishment of new
paths after a failure is out of scope for DetNet services. paths after a failure is out of scope for DetNet services.
3.6.1.4. Network Coding 3.6.1.4. Network Coding
Network Coding, not to be confused with network programming, Network Coding, [nwcrg] not to be confused with network programming,
comprises several techniques where multiple data flows are encoded. comprises several techniques where multiple data flows are encoded.
These resulting flows can then be sent on different paths. The These resulting flows can then be sent on different paths. The
encoding operation can combine flows and error recovery information. encoding operation can combine flows and error recovery information.
When the encoded flows are decoded and recombined the original flows When the encoded flows are decoded and recombined the original flows
can be recovered. Note that Network coding uses an alternative to can be recovered. Note that Network coding uses an alternative to
packet by packet PREOF. Therefore, for certain network topologies packet by packet PREOF. Therefore, for certain network topologies
and traffic loads, Network Coding can be used to improve a network's and traffic loads, Network Coding can be used to improve a network's
throughput, efficiency, latency, and scalability, as well as throughput, efficiency, latency, and scalability, as well as
resilience to partition, attacks, and eavesdropping, as compared to resilience to partition, attacks, and eavesdropping, as compared to
traditional methods. DetNet could utilized Network coding as an traditional methods. DetNet could utilized Network coding as an
skipping to change at page 13, line 17 skipping to change at page 13, line 17
nodes determine which packets are eliminated and which packets are nodes determine which packets are eliminated and which packets are
forwarded. A 1+1 scheme where only one path is used for traffic at a forwarded. A 1+1 scheme where only one path is used for traffic at a
time, could use the same topology. In this case there is no PRF time, could use the same topology. In this case there is no PRF
function and traffic is switched upon detection of failure. An OAM function and traffic is switched upon detection of failure. An OAM
scheme that monitors the paths detects the loss of path or traffic is scheme that monitors the paths detects the loss of path or traffic is
required to initiate the switch. A POF may still be used in this required to initiate the switch. A POF may still be used in this
case to prevent misordering of packets. In both cases the protection case to prevent misordering of packets. In both cases the protection
paths are established and maintained for the duration of the DetNet paths are established and maintained for the duration of the DetNet
service. service.
3.6.2.2. Ring Service Protection 3.6.2.2. Path Differential Delay
In the preceding example, proper working of duplicate elimination and
reordering of packets are dependent on the number of out-of-order
packets that can be buffered and the delay difference of arriving
packets. DetNet uses flow specific requirements (e.g., maximum
number of out-of-order packets, maximum latency of the flow, etc.)
for configuration of POF related buffers. If the differential delay
between paths is excessively large or there is excessive mis-ordering
of the packets, then packets may be dropped instead of being
reordered. Likewise, PEF uses the sequence number to identify
duplicate packets, and large differential delays combined with high
numbers of packets may exceed the ability of the PEF to work
properly.
3.6.2.3. Ring Service Protection
Ring protection may also be supported if the underlying technology Ring protection may also be supported if the underlying technology
supports it. Many of the same concepts apply however rings are supports it. Many of the same concepts apply however rings are
normally 1+1 protection for data efficiency reasons. [RFC8227] is an normally 1+1 protection for data efficiency reasons. [RFC8227] is an
example of MPLS-TP data plane that supports Ring protection. example of MPLS-TP data plane that supports Ring protection.
3.6.3. Aggregation Considerations 3.6.3. Aggregation Considerations
The DetNet data plane also allows for the aggregation of DetNet The DetNet data plane also allows for the aggregation of DetNet
flows, which can improve scalability by reducing the per-hop state. flows, which can improve scalability by reducing the per-hop state.
skipping to change at page 16, line 25 skipping to change at page 16, line 25
+------+ +------+
| L2 | | L2 |
+------+ +------+
Figure 5: Example DetNet MPLS Sub-Network Formats Figure 5: Example DetNet MPLS Sub-Network Formats
4. Controller Plane (Management and Control) Considerations 4. Controller Plane (Management and Control) Considerations
4.1. DetNet Controller Plane Requirements 4.1. DetNet Controller Plane Requirements
While the definition of controller plane for DetNet is out of the The Controller Plane corresponds to the aggregation of the Control
scope of this document, there are particular considerations and and Management Planes discussed in [RFC7426] and [RFC8655]. While
requirements for such that result from the unique characteristics of more details of any DetNet controller plane are out of the scope of
the DetNet architecture [I-D.ietf-detnet-architecture] and data plane this document, there are particular considerations and requirements
as defined herein. for such that result from the unique characteristics of the DetNet
architecture [RFC8655] and data plane as defined herein.
The primary requirements of the DetNet controller plane are that it The primary requirements of the DetNet controller plane are that it
must be able to: must be able to:
o Instantiate DetNet flows in a DetNet domain (which may include o Instantiate DetNet flows in a DetNet domain (which may include
some or all of explicit path determination, link bandwidth some or all of explicit path determination, link bandwidth
reservations, restricting flows to IEEE 802.1 TSN links, node reservations, restricting flows to IEEE 802.1 TSN links, node
buffer and other resource reservations, specification of required buffer and other resource reservations, specification of required
queuing disciplines along the path, ability to manage queuing disciplines along the path, ability to manage
bidirectional flows, etc.) as needed for a flow. bidirectional flows, etc.) as needed for a flow.
skipping to change at page 17, line 44 skipping to change at page 17, line 44
used as the basis of a later analysis of the alternatives. used as the basis of a later analysis of the alternatives.
4.2. Generic Controller Plane Considerations 4.2. Generic Controller Plane Considerations
This section covers control plane considerations that are independent This section covers control plane considerations that are independent
of the data plane technology used for DetNet service delivery. of the data plane technology used for DetNet service delivery.
While management plane and control planes are traditionally While management plane and control planes are traditionally
considered separately, from the Data Plane perspective there is no considered separately, from the Data Plane perspective there is no
practical difference based on the origin of flow provisioning practical difference based on the origin of flow provisioning
information, and the DetNet architecture information, and the DetNet architecture [RFC8655] refers to these
[I-D.ietf-detnet-architecture] refers to these collectively as the collectively as the 'Controller Plane'. This document therefore does
'Controller Plane'. This document therefore does not distinguish not distinguish between information provided by distributed control
between information provided by distributed control plane protocols, plane protocols, e.g., RSVP-TE [RFC3209] and [RFC3473], or by
e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network centralized network management mechanisms, e.g., RestConf [RFC8040],
management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and YANG [RFC7950], and the Path Computation Element Communication
the Path Computation Element Communication Protocol (PCEP) Protocol (PCEP) [I-D.ietf-pce-pcep-extension-for-pce-controller] or
[I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination any combination thereof. Specific considerations and requirements
thereof. Specific considerations and requirements for the DetNet for the DetNet Controller Plane are discussed in Section 4.1.
Controller Plane are discussed in Section 4.1.
Each respective data plane document also covers the control plane Each respective data plane document also covers the control plane
considerations for that technology. For example [I-D.ietf-detnet-ip] considerations for that technology. For example [I-D.ietf-detnet-ip]
covers IP control plane normative considerations and covers IP control plane normative considerations and
[I-D.ietf-detnet-mpls] covers MPLS control plane normative [I-D.ietf-detnet-mpls] covers MPLS control plane normative
considerations. considerations.
4.2.1. Flow Aggregation Control 4.2.1. Flow Aggregation Control
Flow aggregation means that multiple App-flows are served by a single Flow aggregation means that multiple App-flows are served by a single
skipping to change at page 20, line 6 skipping to change at page 20, line 6
4.2.3. Contention Loss and Jitter Reduction 4.2.3. Contention Loss and Jitter Reduction
As discussed in Section 1, this document does not specify the As discussed in Section 1, this document does not specify the
mechanisms needed to eliminate packet contention, packet loss or mechanisms needed to eliminate packet contention, packet loss or
reduce jitter for DetNet flows at the DetNet forwarding sub-layer. reduce jitter for DetNet flows at the DetNet forwarding sub-layer.
The ability to manage node and link resources to be able to provide The ability to manage node and link resources to be able to provide
these functions is a necessary part of the DetNet controller plane. these functions is a necessary part of the DetNet controller plane.
It is also necessary to be able to control the required queuing It is also necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path mechanisms used to provide these functions along a flow's path
through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for
further discussion of these requirements. further discussion of these requirements. Some forms of protection
may minimize packet loss or change jitter characteristics in the
cases where packets are reordered when out-of-order packets are
received at the service sub-layer.
4.2.4. Bidirectional Traffic 4.2.4. Bidirectional Traffic
DetNet applications typically generate bidirectional traffic. IP and In many cases DetNet flows can be considered unidirectional and
MPLS typically treat each direction separately and do not force independent. However, there are cases where the DetNet service
interdependence of each direction. MPLS has considered bidirectional requires bidirectional traffic from a DetNet application service
traffic requirements and the MPLS definitions from [RFC5654] are perspective. IP and MPLS typically treat each direction separately
useful to illustrate terms such as associated bidirectional flows and and do not force interdependence of each direction. MPLS has
co-routed bidirectional flows. MPLS defines a point-to-point considered bidirectional traffic requirements and the MPLS
associated bidirectional LSP as consisting of two unidirectional definitions from [RFC5654] are useful to illustrate terms such as
point-to-point LSPs, one from A to B and the other from B to A, which associated bidirectional flows and co-routed bidirectional flows.
are regarded as providing a single logical bidirectional forwarding MPLS defines a point-to-point associated bidirectional LSP as
path. This is analogous to standard IP routing. MPLS defines a consisting of two unidirectional point-to-point LSPs, one from A to B
point-to-point co-routed bidirectional LSP as an associated and the other from B to A, which are regarded as providing a single
bidirectional LSP which satisfies the additional constraint that its logical bidirectional forwarding path. This is analogous to standard
two unidirectional component LSPs follow the same path (in terms of IP routing. MPLS defines a point-to-point co-routed bidirectional
both nodes and links) in both directions. An important property of LSP as an associated bidirectional LSP which satisfies the additional
co-routed bidirectional LSPs is that their unidirectional component constraint that its two unidirectional component LSPs follow the same
LSPs share fate. In both types of bidirectional LSPs, resource path (in terms of both nodes and links) in both directions. An
reservations may differ in each direction. The concepts of important property of co-routed bidirectional LSPs is that their
associated bidirectional flows and co-routed bidirectional flows can unidirectional component LSPs share fate. In both types of
also be applied to DetNet IP flows. bidirectional LSPs, resource reservations may differ in each
direction. The concepts of associated bidirectional flows and co-
routed bidirectional flows can also be applied to DetNet IP flows.
While the DetNet IP data plane must support bidirectional DetNet While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features with respect to flows, there are no special bidirectional features with respect to
the data plane other than the need for the two directions of a co- the data plane other than the need for the two directions of a co-
routed bidirectional flow to take the same path. That is to say that routed bidirectional flow to take the same path. That is to say that
bidirectional DetNet flows are solely represented at the management bidirectional DetNet flows are solely represented at the management
and control plane levels, without specific support or knowledge and control plane levels, without specific support or knowledge
within the DetNet data plane. Fate sharing and associated or co- within the DetNet data plane. Fate sharing and associated or co-
routed bidirectional flows, can be managed at the control level. routed bidirectional flows, can be managed at the control level.
skipping to change at page 21, line 25 skipping to change at page 21, line 28
it should be noted that the ability to determine, for a particular it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support. There may be capabilities that can domain requires explicit support. There may be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery [RFC4872] be used, or extended, for example GMPLS end-to-end recovery [RFC4872]
and GMPLS segment recovery [RFC4873]. and GMPLS segment recovery [RFC4873].
5. Security Considerations 5. Security Considerations
Security considerations for DetNet are described in detail in Security considerations for DetNet are described in detail in
[I-D.ietf-detnet-security]. General security considerations are [I-D.ietf-detnet-security]. General security considerations are
described in [I-D.ietf-detnet-architecture]. This section considers described in [RFC8655]. This section considers general security
general security considerations applicable to all data planes. considerations applicable to all data planes.
Security aspects which are unique to DetNet are those whose aim is to Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency. and bounded end-to-end delivery latency.
The primary considerations for the data plane is to maintain The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. For through whatever means is provided by the underlying technology. For
skipping to change at page 22, line 26 skipping to change at page 22, line 31
This document makes no IANA requests. This document makes no IANA requests.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
Bernardos for their various contributions to this work. Bernardos for their various contributions to this work.
8. References 8. Contributors
8.1. Normative References The following people contributed substantially to the content of this
document:
Don Fedyk
Jouni Korhonen
9. References
9.1. Normative References
[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>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
8.2. Informative References [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[I-D.ietf-detnet-architecture] 9.2. Informative References
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.
Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
flow-information-model-05 (work in progress), September flow-information-model-06 (work in progress), October
2019. 2019.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-01 (work in progress), July 2019. draft-ietf-detnet-ip-04 (work in progress), November 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 2019. draft-ietf-detnet-mpls-04 (work in progress), November
2019.
[I-D.ietf-detnet-mpls-over-tsn] [I-D.ietf-detnet-mpls-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking
Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over- (TSN)", draft-ietf-detnet-mpls-over-tsn-01 (work in
tsn-00 (work in progress), May 2019. progress), October 2019.
[I-D.ietf-detnet-mpls-over-udp-ip] [I-D.ietf-detnet-mpls-over-udp-ip]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP", and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP",
draft-ietf-detnet-mpls-over-udp-ip-02 (work in progress), draft-ietf-detnet-mpls-over-udp-ip-04 (work in progress),
October 2019. November 2019.
[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., and N. Finn, "Deterministic Networking
Networking (DetNet) Security Considerations", draft-ietf- (DetNet) Security Considerations", draft-ietf-detnet-
detnet-security-05 (work in progress), August 2019. security-07 (work in progress), January 2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-02 (work in progress), July extension-for-pce-controller-03 (work in progress),
2019. November 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Matsushima, S., and Z. Li, "SRv6 Network Programming",
Network Programming", draft-ietf-spring-srv6-network- draft-ietf-spring-srv6-network-programming-08 (work in
programming-05 (work in progress), October 2019. progress), January 2020.
[IEEE802.1AE-2018] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018, Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networking Task Group", <http://www.ieee802.org/1/tsn>. Networking Task Group", <http://www.ieee802.org/1/tsn>.
[nwcrg] IRTF, "Coding for efficient NetWork Communications
Research Group (nwcrg)",
<https://datatracker.ietf.org/rg/nwcrg/about>.
[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>.
[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A
Framework for QoS-based Routing in the Internet", Framework for QoS-based Routing in the Internet",
RFC 2386, DOI 10.17487/RFC2386, August 1998, RFC 2386, DOI 10.17487/RFC2386, August 1998,
<https://www.rfc-editor.org/info/rfc2386>. <https://www.rfc-editor.org/info/rfc2386>.
skipping to change at page 25, line 10 skipping to change at page 25, line 30
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387,
September 2011, <https://www.rfc-editor.org/info/rfc6387>. September 2011, <https://www.rfc-editor.org/info/rfc6387>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>. <https://www.rfc-editor.org/info/rfc7551>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
skipping to change at page 26, line 4 skipping to change at page 26, line 27
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Janos Farkas Janos Farkas
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Andrew G. Malis Andrew G. Malis
Independent Independent
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Futurewei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen
Email: jouni.nospam@gmail.com
 End of changes. 67 change blocks. 
126 lines changed or deleted 159 lines changed or added

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