draft-ietf-detnet-tsn-vpn-over-mpls-02.txt   draft-ietf-detnet-tsn-vpn-over-mpls-03.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: September 7, 2020 A. Malis Expires: December 10, 2020 A. Malis
Independent Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
March 6, 2020 June 8, 2020
DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
draft-ietf-detnet-tsn-vpn-over-mpls-02 draft-ietf-detnet-tsn-vpn-over-mpls-03
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
TSN networks are interconnected over a DetNet MPLS Network. TSN networks are interconnected over a DetNet MPLS 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 37 skipping to change at page 1, line 37
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 September 7, 2020. This Internet-Draft will expire on December 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4
4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6 4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7 4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7
5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8 5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8
5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8 5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8
5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9 5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 10
5.3. Edge Node DetNet Service and Forwarding Sub-Layer 5.3. Edge Node DetNet Service and Forwarding Sub-Layer
Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
6. Controller Plane (Management and Control) Considerations . . 11 6. Controller Plane (Management and Control) Considerations . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
Working Group deals with deterministic services through IEEE 802 Working Group deals with deterministic services through IEEE 802
networks. Deterministic Networking (DetNet) defined by IETF is a networks. Deterministic Networking (DetNet) defined by IETF is a
service that can be offered by a L3 network to DetNet flows. General service that can be offered by a L3 network to DetNet flows. General
background and concepts of DetNet can be found in [RFC8655]. background and concepts of DetNet can be found in [RFC8655].
This document specifies the use of a DetNet MPLS network to This document specifies the use of a DetNet MPLS network to
skipping to change at page 4, line 30 skipping to change at page 4, line 30
3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario
Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware
DetNet service running over an MPLS network. DetNet Edge Nodes sit DetNet service running over an MPLS network. DetNet Edge Nodes sit
at the boundary of a DetNet domain. They are responsible for mapping at the boundary of a DetNet domain. They are responsible for mapping
non-DetNet aware L2 traffic to DetNet services. They also support non-DetNet aware L2 traffic to DetNet services. They also support
the imposition and disposition of the required DetNet encapsulation. the imposition and disposition of the required DetNet encapsulation.
These are functionally similar to pseudowire (PW) Terminating These are functionally similar to pseudowire (PW) Terminating
Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example
TSN Streams are simple applicaions over DetNet flows. The specific TSN Streams are simple applications over DetNet flows. The specific
of this operation are discussed later in this document. of this operation are discussed later in this document.
TSN Edge Transit Edge TSN TSN Edge Transit Edge TSN
End System Node Node Node End System End System Node Node Node End System
(T-PE) (LSR) (T-PE) (T-PE) (LSR) (T-PE)
+----------+ +----------+ +----------+ +----------+
| TSN | <---------End to End TSN Service----------> | TSN | | TSN | <---------End to End TSN Service----------> | TSN |
| Applic. | | Applic. | | Applic. | | Applic. |
+----------+ +.........+ +.........+ +----------+ +----------+ +.........+ +.........+ +----------+
skipping to change at page 7, line 28 skipping to change at page 7, line 28
allocation to eliminate (or reduce) congestion loss and jitter. allocation to eliminate (or reduce) congestion loss and jitter.
DetNet transit nodes reside wholly within a DetNet domain, and also DetNet transit nodes reside wholly within a DetNet domain, and also
provide DetNet forwarding sub-layer functions in accordance with the provide DetNet forwarding sub-layer functions in accordance with the
performance required by a DetNet flow carried over an LSP. Unlike performance required by a DetNet flow carried over an LSP. Unlike
other DetNet node types, transit nodes provide no service sub-layer other DetNet node types, transit nodes provide no service sub-layer
processing. processing.
4.2. TSN over DetNet MPLS Encapsulation 4.2. TSN over DetNet MPLS Encapsulation
The basic encapsulation approach is to treat a TSN Stream as an app- The basic encapsulation approach is to treat a TSN Stream as an App-
flow from the DetNet MPLS perspective. The corresponding example flow from the DetNet MPLS perspective. The corresponding example
shown in Figure 3. shown in Figure 3.
/-> +------+ +------+ +------+ TSN ^ ^ /-> +------+ +------+ +------+ TSN ^ ^
| | X | | X | | X |<- Appli : : | | X | | X | | X |<- Appli : :
App-Flow <-+ +------+ +------+ +------+ cation : :(1) App-Flow <-+ +------+ +------+ +------+ cation : :(1)
for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v
\-> +---+======+--+======+--+======+-----+ : \-> +---+======+--+======+--+======+-----+ :
| d-CW | | d-CW | | d-CW | : | d-CW | | d-CW | | d-CW | :
DetNet-MPLS +------+ +------+ +------+ :(2) DetNet-MPLS +------+ +------+ +------+ :(2)
skipping to change at page 8, line 37 skipping to change at page 8, line 37
5.1. Edge Node TSN Procedures 5.1. Edge Node TSN Procedures
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments Working Group have defined (and are defining) a number of amendments
to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]
defines packet replication and elimination functions for a TSN defines packet replication and elimination functions for a TSN
network. network.
The implementation of TSN entity (i.e., TSN packet processing
functions) MUST be compliant with the relevant IEEE 802.1 standards.
TSN specific functions are executed on the data received by the TSN specific functions are executed on the data received by the
DetNet Edge Node from the connected CE before forwarded to connected DetNet Edge Node from the connected CE before forwarded to connected
CE(s) or presentation to the DetNet Service Proxy function for CE(s) or presentation to the DetNet Service Proxy function for
transmission across the DetNet domain, or on the data received from a transmission across the DetNet domain, or on the data received from a
DetNet PW by a PE before it is output on the Attachment Circuit(s) DetNet PW by a PE before it is output on the Attachment Circuit(s)
(AC). (AC).
TSN specific function(s) of Edge Nodes (T-PE) are belonging to the TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
native service processing (NSP) [RFC3985] block. This is similar to to the native service processing (NSP) [RFC3985] block. This is
other functionalities being defined by standard bodies other than the similar to other functionalities being defined by standard bodies
IETF (for example in case of Ethernet: stripping, overwriting or other than the IETF (for example in case of Ethernet: stripping,
adding VLAN tags, etc.). Depending on the TSN role of the Edge Node overwriting or adding VLAN tags, etc.). Depending on the TSN role of
in the end-to-end TSN service selected TSN functions must be the Edge Node in the end-to-end TSN service selected TSN functions
supported. are supported.
When a PE receives a packet from a CE, on a given AC with DetNet When a PE receives a packet from a CE, on a given AC with DetNet
service, it MUST first check via Stream Identification whether the service, it MUST first check via Stream Identification (see Clause 6.
packet belongs to a configured TSN Stream (i.e., App-flow from DetNet of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
perspective). If no Stream ID is matched and no other (VPN) service whether the packet belongs to a configured TSN Stream (i.e., App-flow
is configured for the AC then packet MUST be dropped. If there is a from DetNet perspective). If no Stream ID is matched and no other
matching TSN Stream then the Stream-ID specific TSN functions MUST be (VPN) service is configured for the AC then packet MUST be dropped.
executed (e.g., ingress policing, header field manipulation in case If there is a matching TSN Stream then the Stream-ID specific TSN
of active Stream Identification, FRER, etc.). Source MAC lookup MAY functions MUST be executed (e.g., ingress policing, header field
also be used for local MAC address learning. manipulation in case of active Stream Identification, FRER, etc.).
Source MAC lookup MAY also be used for local MAC address learning.
If the PE decides to forward the packet, the packet MUST be forwarded If the PE decides to forward the packet, the packet MUST be forwarded
according to the TSN Stream specific configuration to connected CE(s) according to the TSN Stream specific configuration to connected CE(s)
(in case of local bridging) and/or to the DetNet Service Proxy (in (in case of local bridging) and/or to the DetNet Service Proxy (in
case of forwarding to remote CE(s) required). If there are no TSN case of forwarding to remote CE(s) required). If there are no TSN
Stream specific forwarding configurations the PE MUST flood the Stream specific forwarding configurations the PE MUST flood the
packet to other locally attached CE(s) and to the DetNet Service packet to other locally attached CE(s) and to the DetNet Service
Proxy. If the administrative policy on the PE does not allow Proxy. If the administrative policy on the PE does not allow
flooding the PE MUST drop the packet. flooding the PE MUST drop the packet.
When a TSN entity of the PE receives a packet from the DetNet Service When a TSN entity of the PE receives a packet from the DetNet Service
Proxy, it MUST first check via Stream Identification whether the Proxy, it MUST first check via Stream Identification (see Clause 6.
packet belongs to a configured TSN Stream. If no Stream ID is of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
matched then packet MUST be dropped. If there is a matching TSN whether the packet belongs to a configured TSN Stream. If no Stream
Stream then the Stream ID specific TSN functions MUST be executed ID is matched then packet MUST be dropped. If there is a matching
TSN Stream then the Stream ID specific TSN functions MUST be executed
(e.g., header field manipulation in case of active Stream (e.g., header field manipulation in case of active Stream
Identification, FRER, etc.). Source MAC lookup MAY also be used for Identification, FRER, etc.). Source MAC lookup MAY also be used for
local MAC address learning. local MAC address learning.
If the PE decides to forward the packet, the packet MUST be forwarded If the PE decides to forward the packet, the packet MUST be forwarded
according to the TSN Stream specific configuration to connected according to the TSN Stream specific configuration to connected
CE(s). If there are no TSN Stream specific forwarding configurations CE(s). If there are no TSN Stream specific forwarding configurations
the PE MUST flood the packet to locally attached CE(s). If the the PE MUST flood the packet to locally attached CE(s). If the
administrative policy on the PE does not allow flooding the PE MUST administrative policy on the PE does not allow flooding the PE MUST
drop the packet. drop the packet.
Implementations of this document SHALL use management and control Implementations of this document SHALL use management and control
information to ensure TSN specific functions of the Edge Node information to ensure TSN specific functions of the Edge Node
according to the expectations of the connected TSN network. according to the expectations of the connected TSN network.
5.2. Edge Node DetNet Service Proxy Procedures 5.2. Edge Node DetNet Service Proxy Procedures
The Service Proxy function maps between App-flows and DetNet flows. The Service Proxy function maps between App-flows and DetNet flows.
The DetNet Edge Node TSN entity MUST support the TSN Stream The DetNet Edge Node TSN entity MUST support the TSN Stream
identification functions and the related managed objects as defined identification functions and the related managed objects as defined
in IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to in Clause 6. and Clause 9. of IEEE 802.1CB [IEEE8021CB] and IEEE
recognize the App-flow related packets. The Service Proxy presents P802.1CBdb [IEEEP8021CBdb] to recognize the App-flow related packets.
TSN Streams as an App-flow to a DetNet Flow. The Service Proxy presents TSN Streams as an App-flow to a DetNet
Flow.
When a DetNet Service Proxy receives a packet from the TSN Entity it When a DetNet Service Proxy receives a packet from the TSN Entity it
MUST check whether such an App-flow is present in its mapping table. MUST check whether such an App-flow is present in its mapping table.
If present it associates the internal DetNet flow-ID to the packet If present it associates the internal DetNet flow-ID to the packet
and MUST forward it to the DetNet Service and Forwarding sub-layers. and MUST forward it to the DetNet Service and Forwarding sub-layers.
If no matching statement is present it MUST drop the packet. If no matching statement is present it MUST drop the packet.
When a DetNet Service Proxy receives a packet from the DetNet Service When a DetNet Service Proxy receives a packet from the DetNet Service
and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN
Entity. Entity.
skipping to change at page 11, line 30 skipping to change at page 11, line 39
[I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls].
6. Controller Plane (Management and Control) Considerations 6. Controller Plane (Management and Control) Considerations
TSN Stream(s) to DetNet flow mapping related information are required TSN Stream(s) to DetNet flow mapping related information are required
only for the service proxy function of MPLS (DetNet) Edge nodes. only for the service proxy function of MPLS (DetNet) Edge nodes.
From the Data Plane perspective there is no practical difference From the Data Plane perspective there is no practical difference
based on the origin of flow mapping related information (management based on the origin of flow mapping related information (management
plane or control plane). plane or control plane).
The following summarizes the set of information that is needed to
configure TSN over DetNet MPLS:
o TSN related configuration information according to the TSN role of
the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
[IEEEP8021CBdb].
o DetNet MPLS related configuration information according to the
DetNet role of the DetNet MPLS node, as per
[I-D.ietf-detnet-mpls].
o App-Flow identification information to map received TSN Stream(s)
to the DetNet flow. Parameters fo TSN stream identification are
defined in [IEEE8021CB] and [IEEEP8021CBdb].
This information MUST be provisioned per DetNet flow.
MPLS DetNet Edge nodes are member of both the DetNet domain and the MPLS DetNet Edge nodes are member of both the DetNet domain and the
connected TSN network. From the TSN network perspective the MPLS connected TSN network. From the TSN network perspective the MPLS
(DetNet) Edge node has a "TSN relay node" role, so TSN specific (DetNet) Edge node has a "TSN relay node" role, so TSN specific
management and control plane functionalities must be implemented. management and control plane functionalities must be implemented.
There are many similarities in the management plane techniques used There are many similarities in the management plane techniques used
in DetNet and TSN, but that is not the case for the control plane in DetNet and TSN, but that is not the case for the control plane
protocols. For example, RSVP-TE and MSRP behaves differently. protocols. For example, RSVP-TE and MSRP behaves differently.
Therefore management and control plane design is an important aspect Therefore management and control plane design is an important aspect
of scenarios, where mapping between DetNet and TSN is required. of scenarios, where mapping between DetNet and TSN is required.
skipping to change at page 12, line 33 skipping to change at page 13, line 9
Configuration of TSN specific functions (e.g., FRER) inside the TSN Configuration of TSN specific functions (e.g., FRER) inside the TSN
network is a TSN domain specific decision and may not be visible in network is a TSN domain specific decision and may not be visible in
the DetNet domain. Service protection interworking scenarios are the DetNet domain. Service protection interworking scenarios are
left for further study. left for further study.
7. Security Considerations 7. 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 [RFC8655]. DetNet MPLS data plane specific described in [RFC8655].
considerations are summarized in [I-D.ietf-detnet-mpls]. The primary
considerations for the data plane is to maintain integrity of data DetNet MPLS data plane specific considerations are summarized and
and delivery of the associated DetNet service traversing the DetNet described in [I-D.ietf-detnet-mpls] including any application flow
network. Application flows can be protected through whatever means types. This document focuses on the scenario where TSN Streams are
is provided by the underlying technology. For example, encryption the application flows for DetNet and it is already covered by those
may be used, such as that provided by IPSec [RFC4301] for IP flows DetNet MPLS data plane security considerations.
and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for
IP over Ethernet (Layer-2) flows.
8. IANA Considerations 8. IANA Considerations
This document makes no IANA requests. This document makes no IANA requests.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
Christophe Mangin and Jouni Korhonen for their various contributions Christophe Mangin and Jouni Korhonen for their various contributions
to this work. to this work.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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., Malis, A., Bryant, S.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
draft-ietf-detnet-mpls-05 (work in progress), February detnet-mpls-06 (work in progress), April 2020.
2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[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>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S. Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-04 (work in progress), February 2020. data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T. and E. Grossman, "Deterministic Networking
J., Austad, H., and N. Finn, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-08 (work in progress), February 2020. security-10 (work in progress), May 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>.
[IEEE8021CB] [IEEE8021CB]
Finn, N., "Draft Standard for Local and metropolitan area Finn, N., "Draft Standard for Local and metropolitan area
networks - Seamless Redundancy", IEEE P802.1CB networks - Seamless Redundancy", IEEE P802.1CB
/D2.1 P802.1CB, December 2015, /D2.1 P802.1CB, December 2015,
skipping to change at page 15, line 4 skipping to change at page 15, line 25
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balazs Varga (editor)
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
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
Andrew G. Malis Andrew G. Malis
Independent Malis Consulting
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
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
 End of changes. 22 change blocks. 
53 lines changed or deleted 73 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/