draft-ietf-detnet-tsn-vpn-over-mpls-01.txt   draft-ietf-detnet-tsn-vpn-over-mpls-02.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: April 29, 2020 A. Malis Expires: September 7, 2020 A. Malis
Independent Independent
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
October 27, 2019 March 6, 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-01 draft-ietf-detnet-tsn-vpn-over-mpls-02
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 April 29, 2020. This Internet-Draft will expire on September 7, 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . 9
5.3. Edge Node DetNet Service and Forwarding Sub-Layer 5.3. Edge Node DetNet Service and Forwarding Sub-Layer
Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
6. Controller Plane (Management and Control) Considerations . . 10 6. Controller Plane (Management and Control) Considerations . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 background and concepts of DetNet can be found in [RFC8655].
[I-D.ietf-detnet-architecture].
This document specifies the use of a DetNet MPLS network to This document specifies the use of a DetNet MPLS network to
interconnect TSN nodes/network segments. DetNet MPLS data plane is interconnect TSN nodes/network segments. DetNet MPLS data plane is
defined in [I-D.ietf-detnet-mpls]. defined in [I-D.ietf-detnet-mpls].
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 DetNet architecture [RFC8655] and
[I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls].
The reader is assumed to be familiar with these documents and their The reader is assumed to be familiar with these documents and their
terminology. terminology.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
AC Attachment Circuit. AC Attachment Circuit.
CE Customer Edge equipment. CE Customer Edge equipment.
CoS Class of Service.
CW Control Word. CW Control Word.
DetNet Deterministic Networking. DetNet Deterministic Networking.
DF DetNet Flow. DF DetNet Flow.
FRER Frame Replication and Elimination for Redundancy (TSN FRER Frame Replication and Elimination for Redundancy (TSN
function). function).
L2 Layer 2. L2 Layer 2.
skipping to change at page 3, line 48 skipping to change at page 3, line 46
L3 Layer 3. L3 Layer 3.
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.
MPLS-TP Multiprotocol Label Switching - Transport Profile. MPLS-TP Multiprotocol Label Switching - Transport Profile.
MS-PW Multi-Segment PseudoWire (MS-PW).
NSP Native Service Processing. NSP Native Service Processing.
OAM Operations, Administration, and Maintenance. OAM Operations, Administration, and Maintenance.
PE Provider Edge. PE Provider Edge.
PEF Packet Elimination Function.
PRF Packet Replication Function.
PREOF Packet Replication, Elimination and Ordering Functions. PREOF Packet Replication, Elimination and Ordering Functions.
POF Packet Ordering Function.
PSN Packet Switched Network.
PW PseudoWire. PW PseudoWire.
QoS Quality of Service.
S-PE Switching Provider Edge. S-PE Switching Provider Edge.
T-PE Terminating Provider Edge. T-PE Terminating Provider Edge.
TSN Time-Sensitive Network. TSN Time-Sensitive Network.
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
skipping to change at page 8, line 24 skipping to change at page 8, line 24
DetNet MPLS scenario follows the concept of [RFC3985] and covers the DetNet MPLS scenario follows the concept of [RFC3985] and covers the
Edge Nodes components shown on Figure 1. In this section the Edge Nodes components shown on Figure 1. In this section the
following procedures of DetNet Edge Nodes are described: following procedures of DetNet Edge Nodes are described:
o TSN related (Section 5.1) o TSN related (Section 5.1)
o DetNet Service Proxy (Section 5.2) o DetNet Service Proxy (Section 5.2)
o DetNet service and forwarding sub-layer (Section 5.3) o DetNet service and forwarding sub-layer (Section 5.3)
The sub-sections describe procedures for forwarding packets by DetNet
Edge nodes, where such packets are received from either directly
connected CEs (TSN nodes) or some other DetNet Edge nodes.
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.
TSN specific functions are executed on the data received by the PE TSN specific functions are executed on the data received by the
from the CE before presentation to the DetNet PW for transmission DetNet Edge Node from the connected CE before forwarded to connected
across the DetNet domain, or on the data received from a DetNet PW by CE(s) or presentation to the DetNet Service Proxy function for
a PE before it is output on the Attachment Circuit (AC). 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)
(AC).
TSN specific function(s) of Edge Nodes (T-PE) are belonging to the TSN specific function(s) of Edge Nodes (T-PE) are belonging to the
native service processing (NSP) [RFC3985] block. This is similar to native service processing (NSP) [RFC3985] block. This is similar to
other functionalities being defined by standard bodies other than the other functionalities being defined by standard bodies other than the
IETF (for example in case of Ethernet: stripping, overwriting or IETF (for example in case of Ethernet: stripping, overwriting or
adding VLAN tags, etc.). Depending on the TSN role of the Edge Node adding VLAN tags, etc.). Depending on the TSN role of the Edge Node
in the end-to-end TSN service selected TSN functions must be in the end-to-end TSN service selected TSN functions must be
supported. supported.
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
packet belongs to a configured TSN Stream (i.e., App-flow from DetNet
perspective). If no Stream ID is matched and no other (VPN) service
is configured for the AC then packet MUST be dropped. If there is a
matching TSN Stream then the Stream-ID specific TSN functions MUST be
executed (e.g., ingress policing, header field 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
according to the TSN Stream specific configuration to connected CE(s)
(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
Stream specific forwarding configurations the PE MUST flood the
packet to other locally attached CE(s) and to the DetNet Service
Proxy. If the administrative policy on the PE does not allow
flooding the PE MUST drop the packet.
When a TSN entity of the PE receives a packet from the DetNet Service
Proxy, it MUST first check via Stream Identification whether the
packet belongs to a configured TSN Stream. If no Stream 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
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
according to the TSN Stream specific configuration to connected
CE(s). If there are no TSN Stream specific forwarding configurations
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
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 function 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 IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to
recognize the App-flow related packets. The Service Proxy presents recognize the App-flow related packets. The Service Proxy presents
TSN Streams as an App-flow to a DetNet Flow. TSN Streams as an App-flow to a DetNet Flow.
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.
If present it associates the internal DetNet flow-ID to the packet
and MUST forward it to the DetNet Service and Forwarding sub-layers.
If no matching statement is present it MUST drop the packet.
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
Entity.
Implementations of this document SHALL use management and control Implementations of this document SHALL use management and control
information to map a TSN Stream to a DetNet flow. N:1 mapping information to map a TSN Stream to a DetNet flow. N:1 mapping
(aggregating multiple TSN Streams in a single DetNet flow) SHALL be (aggregating multiple TSN Streams in a single DetNet flow) SHALL be
supported. The management or control function that provisions flow supported. The management or control function that provisions flow
mapping SHALL ensure that adequate resources are allocated and mapping SHALL ensure that adequate resources are allocated and
configured to provide proper service requirements of the mapped configured to provide proper service requirements of the mapped
flows. flows.
Due to the (intentional) similarities of the DetNet PREOF and TSN Due to the (intentional) similarities of the DetNet PREOF and TSN
FRER functions service protection function interworking is possible FRER functions service protection function interworking is possible
skipping to change at page 9, line 50 skipping to change at page 10, line 51
[I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16 [I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16
bit sequence number and a 28 bit sequence number. bit sequence number and a 28 bit sequence number.
PREOF functions and the provided service recovery is available only PREOF functions and the provided service recovery is available only
within the DetNet domain as the DetNet flow-ID and the DetNet within the DetNet domain as the DetNet flow-ID and the DetNet
sequence number are not valid outside the DetNet network. MPLS sequence number are not valid outside the DetNet network. MPLS
(DetNet) Edge node terminates all related information elements (DetNet) Edge node terminates all related information elements
encoded in the MPLS labels. encoded in the MPLS labels.
The LSP used to forward the DetNet packet may be of any type (MPLS- The LSP used to forward the DetNet packet may be of any type (MPLS-
LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]). The LSP
[I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label (F-Label) label and/or the S-Label may be used to indicate the queue
and/or the S-Label may be used to indicate the queue processing as processing as well as the forwarding parameters.
well as the forwarding parameters.
For further details see [I-D.ietf-detnet-mpls]. When a PE receives a packet from the Service Proxy function it MUST
add to the packet the DetNet flow-ID specific S-label and create a
d-CW. The PE MUST forward the packet according to the configured
DetNet Service and Forwarding sub-layer rules to other PE nodes.
When a PE receives an MPLS packet from a remote PE, then, after
processing the MPLS label stack, if the top MPLS label ends up being
a DetNet S-label that was advertised by this node, then the PE MUST
forward the packet according to the configured DetNet Service and
Forwarding sub-layer rules to other PE nodes or via the Detnet
Service Proxy function towards locally connected CE(s).
For further details on DetNet Service and Forwarding sub-layers see
[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).
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
skipping to change at page 11, line 20 skipping to change at page 12, line 33
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 [I-D.ietf-detnet-architecture]. DetNet MPLS data plane described in [RFC8655]. DetNet MPLS data plane specific
specific considerations are summarized in [I-D.ietf-detnet-mpls]. considerations are summarized in [I-D.ietf-detnet-mpls]. The primary
The primary considerations for the data plane is to maintain considerations for the data plane is to maintain integrity of data
integrity of data and delivery of the associated DetNet service and delivery of the associated DetNet service traversing the DetNet
traversing the DetNet network. Application flows can be protected network. Application flows can be protected through whatever means
through whatever means is provided by the underlying technology. For is provided by the underlying technology. For example, encryption
example, encryption may be used, such as that provided by IPSec may be used, such as that provided by IPSec [RFC4301] for IP flows
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 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]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-05 (work in progress), February
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-architecture]
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-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
Framework", draft-ietf-detnet-data-plane-framework-02 data-plane-framework-04 (work in progress), February 2020.
(work in progress), September 2019.
[I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 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-08 (work in progress), February 2020.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019.
[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 13, line 37 skipping to change at page 14, line 30
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
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
 End of changes. 26 change blocks. 
73 lines changed or deleted 121 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/