draft-ietf-detnet-ip-00.txt   draft-ietf-detnet-ip-01.txt 
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 6, 2019 L. Berger Expires: January 2, 2020 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
S. Bryant S. Bryant
Huawei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
May 5, 2019 July 1, 2019
DetNet Data Plane: IP DetNet Data Plane: IP
draft-ietf-detnet-ip-00 draft-ietf-detnet-ip-01
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating in an IP packet switched network. operating in an IP packet switched network.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 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 November 6, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6
4.1. End-System Specific Considerations . . . . . . . . . . . 7 4.1. End-System Specific Considerations . . . . . . . . . . . 7
4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7
4.2.1. DetNet Routers . . . . . . . . . . . . . . . . . . . 8 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9
4.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9
4.4. Class of Service . . . . . . . . . . . . . . . . . . . . 10 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10
4.5. Quality of Service . . . . . . . . . . . . . . . . . . . 10 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 10
4.6. Cross-DetNet Flow Resource Aggregation . . . . . . . . . 10 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 11
4.7. Flow Identification and Aggregation . . . . . . . . . . . 11 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 11
4.8. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 11 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12
4.9. Aggregation Considerations . . . . . . . . . . . . . . . 12 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 12
5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 5.1.2. Other Protocol Header Information . . . . . . . . . . 13
5.1. DetNet IP Flow Identification Procedures . . . . . . . . 13 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 14
5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15
5.1.2. Other Protocol Header Information . . . . . . . . . . 14 6. Management and Control Information Summary . . . . . . . . . 15
5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 16
6. Flow Identification Management and Control Information . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative references . . . . . . . . . . . . . . . . . . 17
11.1. Normative references . . . . . . . . . . . . . . . . . . 19 10.2. Informative references . . . . . . . . . . . . . . . . . 19
11.2. Informative references . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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.
General background and concepts of DetNet can be found in the DetNet General background and concepts of DetNet can be found in the DetNet
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane operation for IP hosts This document specifies the DetNet data plane operation for IP hosts
and routers that provide DetNet service to IP encapsulated data. No and routers that provide DetNet service to IP encapsulated data. No
DetNet specific encapsulation is defined to support IP flows, instead DetNet specific encapsulation is defined to support IP flows, instead
the existing IP and higher layer protocol header information is used the existing IP and higher layer protocol header information is used
to support flow identification and DetNet service delivery. Common to support flow identification and DetNet service delivery. Common
data plane procedures and control information for all DetNet data data plane procedures and control information for all DetNet data
planes can be found in the [I-D.ietf-detnet-framework]. planes can be found in the [I-D.ietf-detnet-data-plane-framework].
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: functions into two sub- functions decomposed into two sub-layers: functions into two sub-
layers: a service sub-layer and a forwarding sub-layer. The service layers: a service sub-layer and a forwarding sub-layer. The service
sub-layer is used to provide DetNet service protection and sub-layer is used to provide DetNet service protection and
reordering. The forwarding sub-layer is used to provides congestion reordering. The forwarding sub-layer is used to provides congestion
protection (low loss, assured latency, and limited reordering). protection (low loss, assured latency, and limited out-of-order
Since no DetNet specific headers are added to support DetNet IP delivery). Since no DetNet specific headers are added to support
flows, only the forwarding sub-layer functions are supported using DetNet IP flows, only the forwarding sub-layer functions are
the DetNet IP defined by this document. Service protection can be supported using the DetNet IP defined by this document. Service
provided on a per sub-net basis using technologies such as MPLS protection can be provided on a per sub-net basis using technologies
[I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified in the IEEE such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified
802.1 TSN task group(referred to in this document simply as IEEE802.1 in the IEEE 802.1 TSN task group(referred to in this document simply
TSN). as IEEE802.1 TSN).
This document provides an overview of the DetNet IP data plane in This document provides an overview of the DetNet IP data plane in
Section 3, considerations that apply to providing DetNet services via Section 3, considerations that apply to providing DetNet services via
the DetNet IP data plane in Section 4. Section 5 provides the the DetNet IP data plane in Section 4. Section 5 provides the
procedures for hosts and routers that support IP-based DetNet procedures for hosts and routers that support IP-based DetNet
services. services. Section 6 summarizes the set of information that is needed
to identify an individual DetNet flow.
2. Terminology 2. Terminology
2.1. Terms Used In This Document 2.1. Terms Used In This Document
This document uses the terminology and concepts established in the This document uses the terminology and concepts established in the
DetNet architecture [I-D.ietf-detnet-architecture], and the reader is DetNet architecture [I-D.ietf-detnet-architecture], and the reader is
assumed to be familiar with that document and its terminology. assumed to be familiar with that document and its terminology.
2.2. Abbreviations 2.2. Abbreviations
skipping to change at page 4, line 14 skipping to change at page 4, line 11
DSCP Differentiated Services Code Point DSCP Differentiated Services Code Point
L2 Layer-2. L2 Layer-2.
L3 Layer-3. L3 Layer-3.
LSP Label-switched path. LSP Label-switched path.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
OAM Operations, Administration, and Maintenance.
PE Provider Edge.
PREOF Packet Replication, Ordering and Elimination Function. PREOF Packet Replication, Ordering and Elimination Function.
PSN Packet Switched Network.
PW Pseudowire.
QoS Quality of Service. QoS Quality of Service.
TE Traffic Engineering.
TSN Time-Sensitive Networking, TSN is a Task Group of the TSN Time-Sensitive Networking, TSN is a Task Group of the
IEEE 802.1 Working Group. IEEE 802.1 Working Group.
2.3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DetNet IP Data Plane Overview 3. DetNet IP Data Plane Overview
This document describes how IP is used by DetNet nodes, i.e., hosts This document describes how IP is used by DetNet nodes, i.e., hosts
and routers, identify DetNet flows and provide a DetNet service using and routers, identify DetNet flows and provide a DetNet service using
an IP data plane. From a data plane perspective, an end-to-end IP an IP data plane. From a data plane perspective, an end-to-end IP
model is followed. As mentioned above, existing IP and higher layer model is followed. As mentioned above, existing IP and higher layer
protocol header information is used to support flow identification protocol header information is used to support flow identification
and DetNet service delivery. Common data plane procedures and and DetNet service delivery. Common data plane procedures and
control information for all DetNet data planes can be found in the control information for all DetNet data planes can be found in the
[I-D.ietf-detnet-framework]. [I-D.ietf-detnet-data-plane-framework].
The DetNet IP data plane uses "6-tuple" based flow identification, The DetNet IP data plane uses "6-tuple" based flow identification,
where 6-tuple refers to information carried in IP and higher layer where 6-tuple refers to information carried in IP and higher layer
protocol headers. The 6-tuple referred to in this document is the protocol headers. The 6-tuple referred to in this document is the
same as that defined in [RFC3290]. Specifically 6-tuple is same as that defined in [RFC3290]. Specifically 6-tuple is
(destination address, source address, IP protocol, source port, (destination address, source address, IP protocol, source port,
destination port, and differentiated services (DiffServ) code point destination port, and differentiated services (DiffServ) code point
(DSCP). General background on the use of IP headers, and 5-tuples, (DSCP). General background on the use of IP headers, and 5-tuples,
to identify flows and support Quality of Service (QoS) can be found to identify flows and support Quality of Service (QoS) can be found
in [RFC3670]. [RFC7657] also provides useful background on the in [RFC3670]. [RFC7657] also provides useful background on the
skipping to change at page 6, line 32 skipping to change at page 6, line 29
|<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|
Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain
Figure 2 illustrates a variant of Figure 1 where the end systems are Figure 2 illustrates a variant of Figure 1 where the end systems are
not DetNet aware. In this case, edge nodes sit at the boundary of not DetNet aware. In this case, edge nodes sit at the boundary of
the DetNet domain and provide DetNet service proxies for the end the DetNet domain and provide DetNet service proxies for the end
applications by initiating and terminating DetNet service for the applications by initiating and terminating DetNet service for the
application's IP flows. The existing header information or an application's IP flows. The existing header information or an
approach such as described in Section 4.6 can be used to support approach such as described in Section 4.4 can be used to support
DetNet flow identification. DetNet flow identification.
Note, that Figure 1 and Figure 2 can be combined, so IP DetNet End
Systems can communicate over DetNet IP network with IP End System.
Non-DetNet and DetNet IP packets are identical on the wire. From Non-DetNet and DetNet IP packets are identical on the wire. From
data plane perspective, the only difference is that there is flow- data plane perspective, the only difference is that there is flow-
associated DetNet information on each DetNet node that defines the associated DetNet information on each DetNet node that defines the
flow related characteristics and required forwarding behavior. As flow related characteristics and required forwarding behavior. As
shown above, edge nodes provide a Service Proxy function that shown above, edge nodes provide a Service Proxy function that
"associates" one or more IP flows with the appropriate DetNet flow- "associates" one or more IP flows with the appropriate DetNet flow-
specific information and ensures that the receives the proper traffic specific information and ensures that the receives the proper traffic
treatment within the domain. treatment within the domain.
Note: The operation of IEEE802.1 TSN end systems over DetNet enabled Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
IP networks is not described in this document. TSN over MPLS is IP networks is not described in this document. TSN over MPLS is
discribed in [I-D.ietf-detnet-tsn-over-mpls]. discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls].
4. DetNet IP Data Plane Considerations 4. DetNet IP 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
information. information.
4.1. End-System Specific Considerations 4.1. End-System Specific Considerations
Data-flows requiring DetNet service are generated and terminated on Data-flows requiring DetNet service are generated and terminated on
skipping to change at page 7, line 25 skipping to change at page 7, line 25
When IP end systems are DetNet aware, no application-level or When IP end systems are DetNet aware, no application-level or
service-level proxy functions are needed inside the DetNet domain. service-level proxy functions are needed inside the DetNet domain.
For DetNet unaware IP end systems service-level proxy functions are For DetNet unaware IP end systems service-level proxy functions are
needed inside the DetNet domain. needed inside the DetNet domain.
End systems need to ensure that DetNet service requirements are met End systems need to ensure that DetNet service requirements are met
when processing packets associated with a DetNet flow. When when processing packets associated with a DetNet flow. When
forwarding packets, this means that packets are appropriately shaped forwarding packets, this means that packets are appropriately shaped
on transmission and received appropriate traffic treatment on the on transmission and received appropriate traffic treatment on the
connected sub-network, see Section 4.5 and Section 4.2.1 for more connected sub-network, see Section 4.3.2 and Section 4.2 for more
details. When receiving packets, this means that there are details. When receiving packets, this means that there are
appropriate local node resources, e.g., buffers, to receive and appropriate local node resources, e.g., buffers, to receive and
process a DetNet flow packets. process a DetNet flow packets.
4.2. DetNet Domain-Specific Considerations 4.2. DetNet Domain-Specific Considerations
As a general rule, DetNet IP domains need to be able to forward any As a general rule, DetNet IP domains need to be able to forward any
DetNet flow identified by the IP 6-tuple. Doing otherwise would DetNet flow identified by the IP 6-tuple. Doing otherwise would
limit end system encapsulation format. From a practical standpoint limit end system encapsulation format. From a practical standpoint
this means that all nodes along the end-to-end path of DetNet flows this means that all nodes along the end-to-end path of DetNet flows
skipping to change at page 8, line 19 skipping to change at page 8, line 19
| ES1|____ / \__/ +----+___ | ES1|____ / \__/ +----+___
+----+ \ / \ +----+ \ / \
+ | + |
____ \ _/ ____ \ _/
+----+ __/ \ +__ DetNet IP domain / +----+ __/ \ +__ DetNet IP domain /
| ES2|____/ L2/L3 |___/ \ __ __/ | ES2|____/ L2/L3 |___/ \ __ __/
+----+ \_______/ \_______/ \___/ +----+ \_______/ \_______/ \___/
Figure 3: Connection types of L3 end systems Figure 3: Connection types of L3 end systems
4.2.1. DetNet Routers Within a DetNet domain, the DetNet enabled IP Routers are
interconnected by links and sub-networks to support end-to-end
Within a DetNet domain, the DetNet enabled IP Routers interconnect delivery of DetNet flows. From a DetNet architecture perspective,
links and sub-networks to support end-to-end delivery of DetNet these routers are DetNet relays, as they must be DetNet service
flows. From a DetNet architecture perspective, these routers are aware. Such routers identify DetNet flows based on the IP 6-tuple,
DetNet relays, as they must be DetNet service aware. Such routers and ensure that the DetNet service required traffic treatment is
identify DetNet flows based on the IP 6-tuple, and ensure that the provided both on the node and on any attached sub-network.
DetNet service required traffic treatment is provided both on the
node and on any attached sub-network.
This solution provides DetNet functions end to end, but does so on a This solution provides DetNet functions end to end, but does so on a
per link and sub-network basis. Congestion protection and latency per link and sub-network basis. Congestion protection and latency
control and the resource allocation (queuing, policing, shaping) are control and the resource allocation (queuing, policing, shaping) are
supported using the underlying link / sub net specific mechanisms. supported using the underlying link / sub net specific mechanisms.
However, service protections (packet replication and packet However, service protections (packet replication and packet
elimination functions) are not provided at the DetNet layer end to elimination functions) are not provided at the DetNet layer end to
end. Instead service protection can be provided on a per underlying end. Instead service protection can be provided on a per underlying
L2 link and sub-network basis. L2 link and sub-network basis.
+------+ +------+
| X | | X |
+======+ +------+
End-system | IP | | IP |
-----+------+-------+======+--- --+======+--
DetNet |L2/SbN| |L2/SbN|
+------+ +------+
Figure 4: Encapsulation of DetNet Routing in simplified IP service L3
end-systems
The DetNet Service Flow is mapped to the link / sub-network specific The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means. This implies resources using an underlying system specific means. This implies
each DetNet aware node on path looks into the forwarded DetNet each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out Service Flow packet and utilize e.g., a 6-tuple to find out the
the required mapping within a node. required mapping within a node.
As noted earlier, the Service Protection is done within each link / As noted earlier, the Service Protection is done within each link /
sub-network independently using the domain specific mechanisms (due sub-network independently using the domain specific mechanisms (due
the lack of a unified end to end sequencing information that would be the lack of a unified end to end sequencing information that would be
available for intermediate nodes). Therefore, service protection (if available for intermediate nodes). Therefore, service protection (if
enabled) cannot be provided end-to-end, only within sub-networks. enabled) cannot be provided end-to-end, only within sub-networks.
This is shown for a three sub-network scenario in Figure 5, where This is shown for a three sub-network scenario in Figure 4, where
each sub-network can provide service protection between its borders. each sub-network can provide service protection between its borders.
______ "R" and "E" denotes replication and elimination points within the
sub-network.
<-------------------- DenNet IP ------------------------>
______
____ / \__ ____ / \__
____ / \__/ \___ ______ ____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+ +----+ __/ +====+ +==+ \ +----+
|src |__/ SubN1 ) | | \ SubN3 \____| dst| |src |__/ SubN1 ) | | \ SubN3 \____| dst|
+----+ \_______/ \ Sub-Network2 | \______/ +----+ +----+ \_______/ \ Sub-Network2 | \______/ +----+
\_ _/ \_ _/
\ __ __/ \ __ __/
\_______/ \___/ \_______/ \___/
+---+ +---------E--------+ +-----+ +---+ +---------E--------+ +-----+
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
|src |----R E--------R +---+ E------R E------+ dst| |src |----R E--------R +---+ E------R E------+ dst|
+----+ | | | | | | | +----+ +----+ | | | | | | | +----+
+---+ +-----R------------+ +-----+ +---+ +-----R------------+ +-----+
Figure 5: Replication and elimination in sub-networks for DetNet IP Figure 4: Replication and elimination in sub-networks for DetNet IP
networks networks
If end to end service protection is desired, it can be implemented, If end to end service protection is desired, it can be implemented,
for example, by the DetNet end systems using Layer-4 (L4) transport for example, by the DetNet end systems using Layer-4 (L4) transport
protocols or application protocols. However, these protocols are out protocols or application protocols. However, these protocols are out
of scope of this document. of scope of this document.
4.3. OAM 4.3. Forwarding Sub-Layer Considerations
[Editor's note: This section is TBD. OAM may be dropped from this
document and left for future study.]
4.4. Class of Service 4.3.1. Class of Service
Class of Service (CoS) for DetNet flows carried in IPv6 is provided Class of Service (CoS) for DetNet flows carried in IPv6 is provided
using the standard differentiated services code point (DSCP) field using the standard differentiated services code point (DSCP) field
[RFC2474] and related mechanisms. The 2-bit explicit congestion [RFC2474] and related mechanisms. The 2-bit explicit congestion
notification (ECN) [RFC3168] field MAY also be used. notification (ECN) [RFC3168] field MAY also be used.
One additional consideration for DetNet nodes which support CoS One additional consideration for DetNet nodes which support CoS
services is that they MUST ensure that the CoS service classes do not services is that they MUST ensure that the CoS service classes do not
impact the congestion protection and latency control mechanisms used impact the congestion protection and latency control mechanisms used
to provide DetNet QoS. This requirement is similar to requirement to provide DetNet QoS. This requirement is similar to requirement
for MPLS LSRs to that CoS LSPs do not impact the resources allocated for MPLS LSRs to that CoS LSPs do not impact the resources allocated
to TE LSPs via [RFC3473]. to TE LSPs via [RFC3473].
4.5. Quality of Service 4.3.2. Quality of Service
Quality of Service (QoS) for DetNet service flows carried in IP MUST Quality of Service (QoS) for DetNet service flows carried in IP MUST
be provided locally by the DetNet-aware hosts and routers supporting be provided locally by the DetNet-aware hosts and routers supporting
DetNet flows. Such support leverages the underlying network layer DetNet flows. Such support leverages the underlying network layer
such as 802.1 TSN. The traffic control mechanisms used to deliver such as 802.1 TSN. The traffic control mechanisms used to deliver
QoS for IP encapsulated DetNet flows are expected to be defined in a QoS for IP encapsulated DetNet flows are expected to be defined in a
future document. From an encapsulation perspective, the combination future document. From an encapsulation perspective, the combination
of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code, of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code,
uniquely identifies a DetNet service flow. uniquely identifies a DetNet service flow.
skipping to change at page 10, line 44 skipping to change at page 10, line 30
nodes of a DetNet network must: nodes of a DetNet network must:
o Defend the DetNet QoS by discarding or remarking (to a non-DetNet o Defend the DetNet QoS by discarding or remarking (to a non-DetNet
CoS) packets received that are not the subject of a completed CoS) packets received that are not the subject of a completed
reservation. reservation.
o Not use a DetNet reserved resource, e.g. a queue or shaper o Not use a DetNet reserved resource, e.g. a queue or shaper
reserved for DetNet flows, for any packet that does not carry a reserved for DetNet flows, for any packet that does not carry a
DetNet Class of Service marker. DetNet Class of Service marker.
4.6. Cross-DetNet Flow Resource Aggregation 4.4. DetNet Flow Aggregation
The ability to aggregate individual flows, and their associated
resource control, into a larger aggregate is an important technique
for improving scaling of messaging in the data, management and
control planes. This document identifies the traffic identification
related aspects of aggregation of DetNet flows. The resource control
and management aspects of aggregation (including the queuing/shaping/
policing implications) will be covered in other documents. The data
plane implications of aggregation are independent for PW/MPLS and IP
encapsulated DetNet flows.
DetNet flows forwarded via IP have more limited aggregation options,
due to the available traffic flow identification fields of the IP
solution. One available approach is to manage the resources
associated with a DSCP identified traffic class and to map (remark)
individually controlled DetNet flows onto that traffic class. This
approach also requires that nodes support aggregation ensure that
traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
a fashion that ensures the required DetNet service is preserved.
In both the MPLS and IP cases, additional details of the traffic
control capabilities needed at a DetNet-aware node may be covered in
the new service descriptions mentioned above or in separate future
documents. Management and control plane mechanisms will also need to
ensure that the service required on the aggregate flow (H-LSP or
DSCP) are provided, which may include the discarding or remarking
mentioned in the previous sections.
4.7. Flow Identification and Aggregation As described in [I-D.ietf-detnet-data-plane-framework], the ability
to aggregate individual flows, and their associated resource control,
into a larger aggregate is an important technique for improving
scaling by reducing the state per hop. DetNet IP data plane
aggregation can take place within a single node, when that node
maintains state about both the aggregated and individual flows. It
can also take place between nodes, where one node maintains state
about only flow aggregates while the other node maintains state on
all or a portion of the component flows. In either case, the
management or control function that provisions the aggregate flows
must ensure that adequate resources are allocated and configured to
provide combined service requirements of the individual flows. As
DetNet is concerned about latency and jitter, more than just
bandwidth needs to be considered.
Section 3 introduces the use of the IP "6-tuple" for flow From a single node perspective, the aggregation of IP flows impacts
identification, and Section 4.5 goes on to discuss how identified DetNet IP data plane flow identification and resource allocation. As
flows use specific QoS mechanisms for flow-specific traffic discussed above, IP flow identification uses the IP "6-tuple" for
treatment, including path control and resource allocation. flow identification. DetNet IP flows can be aggregated using any of
Section 5.1 contains detailed DetNet IP flow identification the 6-tuple fields defined in Section 5.1. The use of prefixes,
procedures. Flow identification plays an important role for the wildcards, bitmasks, and value ranges allows a DetNet node to
DetNet controller plane. identify aggregate DetNet flows. From a resource allocation
perspective, DetNet nodes must provide service to a aggregate and not
on a component flow basis.
Section 4.6 and Section 4.9 discuss the use of flow aggregation in It is the responsibility of the DetNet controller plane to properly
DetNet. Flow aggregation can be accomplished using any of the provision the use of these aggregation mechanisms. This includes
6-tuple fields defined in Section 5.1, using a DSCP identified ensuring that aggregated flows have compatible e.g., the same or very
traffic class or other field. It will be the responsibility of the similar QoS and/or CoS characteristics, see Section 4.3.2. It also
DetNet controller plane to be able to properly provision the use of includes ensuring that per component-flow service requirements are
these aggregation mechanisms. satisfied by the aggregate, see Section 5.3.
4.8. Bidirectional Traffic 4.5. Bidirectional Traffic
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.
Control and management mechanisms need to support bidirectional Control and management mechanisms need to support bidirectional
flows, but the specification of such mechanisms are out of scope of flows, but the specification of such mechanisms are out of scope of
this document. An example control plane solution for MPLS can be this document. An example control plane solution for MPLS can be
found in [RFC7551]. found in [RFC7551].
4.9. Aggregation Considerations
The use of prefixes, wildcards, bitmasks, and port ranges allows a
DetNet node to aggregate DetNet flows. This aggregation can take
place within a single node, when that node maintains state about both
the aggregated and component flows. It can also take place between
nodes, where one node maintains state about only flow aggregates
while the other node maintains state on all or a portion of the
component flows. In either case, the management or control function
that provisions the aggregate flows must ensure that adequate
resources are allocated and configured to provide combined service
requirements of the component flows. As DetNet is concerned about
latency and jitter, more than just bandwidth needs to be considered.
5. DetNet IP Data Plane Procedures 5. DetNet IP Data Plane Procedures
This section provides DetNet IP data plane procedures. These This section provides DetNet IP data plane procedures. These
procedures have been divided into the following areas: flow procedures have been divided into the following areas: flow
identification, forwarding and traffic treatment. Flow identification, forwarding and traffic treatment. Flow
identification includes those procedures related to matching IP and identification includes those procedures related to matching IP and
higher layer protocol header information to DetNet flow (state) higher layer protocol header information to DetNet flow (state)
information and service requirements. Flow identification is also information and service requirements. Flow identification is also
sometimes called Traffic classification, for example see [RFC5777]. sometimes called Traffic classification, for example see [RFC5777].
Forwarding includes those procedures related to next hop selection Forwarding includes those procedures related to next hop selection
and delivery. Traffic treatment includes those procedures related to and delivery. Traffic treatment includes those procedures related to
providing an identified flow with the required DetNet service. providing an identified flow with the required DetNet service.
DetNet IP data plane establishment and operational procedures also DetNet IP data plane establishment and operational procedures also
have requirements on the control and management systems for DetNet have requirements on the control and management systems for DetNet
flows and these are covered in this section. Specifically this flows and these are referred in this section. Specifically this
section identifies a number of information elements that require section identifies a number of information elements that require
support via the management and control interfaces supported by a support via the management and control interfaces supported by a
DetNet node. The specific mechanism used for such support is out of DetNet node. The specific mechanism used for such support is out of
the scope of this document. A summary of the requirements for the scope of this document. A summary of the requirements for
management and control related information is included. Conformance management and control related information is included. Conformance
language is not used in the summary since applies to future language is not used in the summary since applies to future
mechanisms such as those that may be provided in YANG models [YANG- mechanisms such as those that may be provided in YANG models
REF-TBD]. [I-D.ietf-detnet-yang].
5.1. DetNet IP Flow Identification Procedures 5.1. DetNet IP Flow Identification Procedures
IP and higher layer protocol header information is used to identify IP and higher layer protocol header information is used to identify
DetNet flows. All DetNet implementations that support this document DetNet flows. All DetNet implementations that support this document
MUST identify individual DetNet flows based on the set of information MUST identify individual DetNet flows based on the set of information
identified in this section. Note, that additional flow identified in this section. Note, that additional flow
identification requirements, e.g., to support other higher layer identification requirements, e.g., to support other higher layer
protocols, may be defined in future. protocols, may be defined in future.
skipping to change at page 15, line 48 skipping to change at page 14, line 48
next-hop selection process is impacted by DetNet. Specifically, next-hop selection process is impacted by DetNet. Specifically,
implementations of this document SHALL use management and control implementations of this document SHALL use management and control
information to select the one or more outgoing interfaces and next information to select the one or more outgoing interfaces and next
hops to be used for a packet belonging to a DetNet flow. hops to be used for a packet belonging to a DetNet flow.
The use of multiple paths or links, e.g., ECMP, to support a single The use of multiple paths or links, e.g., ECMP, to support a single
DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet
flows within a DetNet domain. flows within a DetNet domain.
The above implies that management and control functions will be The above implies that management and control functions will be
defined to support this requirement, e.g., see [YANG-REF-TBD]. defined to support this requirement, e.g., see
[I-D.ietf-detnet-yang].
5.3. DetNet IP Traffic Treatment Procedures 5.3. DetNet IP Traffic Treatment Procedures
Implementations if this document MUST ensure that a DetNet flow Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via [YANG-REF-TBD]. configuration or the controller plane, e.g., via
General information on DetNet service can be found in [I-D.ietf-detnet-yang]. General information on DetNet service can be
[I-D.ietf-detnet-flow-information-model]. Typical mechanisms used to found in [I-D.ietf-detnet-flow-information-model]. Typical
provide different treatment to different flows includes the mechanisms used to provide different treatment to different flows
allocation of system resources (such as queues and buffers) and includes the allocation of system resources (such as queues and
provisioning or related parameters (such as shaping, and policing). buffers) and provisioning or related parameters (such as shaping, and
Support can also be provided via an underlying network technology policing). Support can also be provided via an underlying network
such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and IEEE802.1 TSN technology such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and
[I-D.ietf-ip-over-tsn]. Other than in the TSN case, the specific IEEE802.1 TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN
mechanisms used by a DetNet node to ensure DetNet service delivery case, the specific mechanisms used by a DetNet node to ensure DetNet
requirements are met for supported DetNet flows is outside the scope service delivery requirements are met for supported DetNet flows is
of this document. outside the scope of this document.
6. Flow Identification Management and Control Information 6. Management and Control Information Summary
The following summarizes the set of information that is needed to The following summarizes the set of information that is needed to
identify an individual DetNet flow: identify individual and aggregated DetNet flows:
o IPv4 and IPv6 source address field. o IPv4 and IPv6 source address field.
o IPv4 and IPv6 source address prefix length, where a zero (0) value o IPv4 and IPv6 source address prefix length, where a zero (0) value
effectively means that the address field is ignored. effectively means that the address field is ignored.
o IPv4 and IPv6 destination address field. o IPv4 and IPv6 destination address field.
o IPv4 and IPv6 destination address prefix length, where a zero (0) o IPv4 and IPv6 destination address prefix length, where a zero (0)
effectively means that the address field is ignored. effectively means that the address field is ignored.
skipping to change at page 17, line 11 skipping to change at page 16, line 11
o IPv6 flow label field. This field can be optionally used for o IPv6 flow label field. This field can be optionally used for
matching. When used, can be exclusive of matching against the matching. When used, can be exclusive of matching against the
next header field. next header field.
o TCP and UDP Source Port. Exact and wildcard matching is required. o TCP and UDP Source Port. Exact and wildcard matching is required.
Port ranges can optionally be used. Port ranges can optionally be used.
o TCP and UDP Destination Port. Exact and wildcard matching is o TCP and UDP Destination Port. Exact and wildcard matching is
required. Port ranges can optionally be used. required. Port ranges can optionally be used.
o IPsec Header SPI field. Exact matching is required.
This information MUST be provisioned per DetNet flow via This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller or management plane. configuration, e.g., via the controller or management plane.
Information identifying a DetNet flow is ordered and implementations Information identifying a DetNet flow is ordered and implementations
use the first match. This can, for example, be used to provide a use the first match. This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service Destination Port field values, while providing a different service
for all other flows with that same UDP Destination Port value. for the aggregate of all other flows with that same UDP Destination
Port value.
7. Security Considerations
The security considerations of DetNet in general are discussed in
[I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other
security considerations will be added in a future version of this
draft.
8. IANA Considerations
TBD.
9. Contributors
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5, far fewer than the 20 individuals below who
made important contributions to this draft. The editor wishes to
thank and acknowledge each of the following authors for contributing
text to this draft. See also Section 10.
Loa Andersson
Huawei
Email: loa@pi.nu
Yuanlong Jiang
Huawei
Email: jiangyuanlong@huawei.com
Norman Finn
Huawei
3101 Rio Way
Spring Valley, CA 91977
USA
Email: norman.finn@mail01.huawei.com
Janos Farkas
Ericsson
Magyar Tudosok krt. 11
Budapest 1117
Hungary
Email: janos.farkas@ericsson.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Tal Mizrahi
Marvell
6 Hamada st.
Yokneam
Israel
Email: talmi@marvell.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Andrew G. Malis
Huawei Technologies
Email: agmalis@gmail.com
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
10. Acknowledgements
The author(s) ACK and NACK.
The following people were part of the DetNet Data Plane Solution
Design Team:
Jouni Korhonen
Janos Farkas
Norman Finn It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and
individual flows.
Balazs Varga 7. Security Considerations
Loa Andersson Security considerations for DetNet are described in detail in
[I-D.ietf-detnet-security]. General security considerations are
described in [I-D.ietf-detnet-architecture]. This section considers
exclusively security considerations which are specific to the DetNet
IP data plane.
Tal Mizrahi Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
David Mozes The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. For
example, encryption may be used, such as that provided by IPSec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
Yuanlong Jiang From a data plane perspective this document does not add or modify
any header information.
Andrew Malis At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable
technology for any given use case.
Carlos J. Bernardos To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks. To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain. To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of Man-In-The-
Middle attacks, for example through use of authentication and
authorization of devices within the DetNet domain.
The DetNet chairs serving during the DetNet Data Plane Solution 8. IANA Considerations
Design Team:
Lou Berger This document does not require an action from IANA.
Pat Thaler 9. Acknowledgements
Thanks for Stewart Bryant for his extensive review of the previous The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
versions of the document. David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
Bernardos for their various contributions to this work.
11. References 10. References
11.1. Normative references 10.1. Normative references
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
skipping to change at page 20, line 35 skipping to change at page 18, line 31
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>.
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608, Length Recommendation for Forwarding", BCP 198, RFC 7608,
skipping to change at page 21, line 10 skipping to change at page 19, line 10
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative references 10.2. Informative references
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-12 (work in progress), March 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-00
(work in progress), May 2019.
[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-02 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
Flow Information Model", draft-ietf-detnet-flow- Flow Information Model", draft-ietf-detnet-flow-
information-model-03 (work in progress), March 2019. information-model-03 (work in progress), March 2019.
[I-D.ietf-detnet-framework]
Korhonen, J., Varga, B., "DetNet Data Plane Framework",
2019.
[I-D.ietf-detnet-ip-over-mpls] [I-D.ietf-detnet-ip-over-mpls]
Korhonen, J., Varga, B., "DetNet IP over DetNet MPLS Data Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
Plane", 2019. and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-
ietf-detnet-ip-over-mpls-00 (work in progress), May 2019.
[I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time
Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-
tsn-00 (work in progress), May 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., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-04 (work in progress), March 2019. detnet-security-04 (work in progress), March 2019.
[I-D.ietf-detnet-tsn-over-mpls] [I-D.ietf-detnet-tsn-vpn-over-mpls]
Varga, B., "DetNet Data Plane: IEEE 802.1 Time Sensitive Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Networking over MPLS", 2019. Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive
Networking over MPLS", draft-ietf-detnet-tsn-vpn-over-
mpls-00 (work in progress), May 2019.
[I-D.ietf-ip-over-tsn] [I-D.ietf-detnet-yang]
Korhonen, J., Varga, B., "DetNet Data Plane: IP over IEEE Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic
802.1 Time Sensitive Networking (TSN)", 2019. Networking (DetNet) Configuration YANG Model", draft-ietf-
detnet-yang-02 (work in progress), March 2019.
[IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002, DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>. <https://www.rfc-editor.org/info/rfc3290>.
skipping to change at page 23, line 15 skipping to change at page 21, line 39
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
Andrew G. Malis Andrew G. Malis
Huawei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Huawei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 65 change blocks. 
269 lines changed or deleted 201 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/