draft-ietf-detnet-tsn-vpn-over-mpls-03.txt   draft-ietf-detnet-tsn-vpn-over-mpls-04.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: December 10, 2020 A. Malis Expires: May 6, 2021 A. Malis
Malis Consulting Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
June 8, 2020 November 2, 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-03 draft-ietf-detnet-tsn-vpn-over-mpls-04
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 December 10, 2020. This Internet-Draft will expire on May 6, 2021.
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 . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 10 Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
6. Controller Plane (Management and Control) Considerations . . 11 6. Controller Plane (Management and Control) Considerations . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 7, line 11 skipping to change at page 7, line 11
The DetNet MPLS data plane builds on MPLS Traffic Engineering The DetNet MPLS data plane builds on MPLS Traffic Engineering
encapsulations and mechanisms to provide a forwarding sub-layer that encapsulations and mechanisms to provide a forwarding sub-layer that
is responsible for providing resource allocation and explicit routes. is responsible for providing resource allocation and explicit routes.
The forwarding sub-layer is supported by one or more forwarding The forwarding sub-layer is supported by one or more forwarding
labels (F-Labels). labels (F-Labels).
DetNet edge/relay nodes are DetNet service sub-layer aware, DetNet edge/relay nodes are DetNet service sub-layer aware,
understand the particular needs of DetNet flows and provide both understand the particular needs of DetNet flows and provide both
DetNet service and forwarding sub-layer functions. They add, remove DetNet service and forwarding sub-layer functions. They add, remove
and process d-CWs, S-Labels and F-labels as needed. MPLS enabled and process d-CWs, S-Labels and F-labels as needed. MPLS DetNet
DetNet nodes can enhance the reliability of delivery by enabling the nodes and transit nodes include DetNet forwarding sub-layer
replication of packets where multiple copies, possibly over multiple
paths, are forwarded through the DetNet domain. They can also
eliminate surplus previously replicated copies of DetNet packets.
MPLS (DetNet) nodes also include DetNet forwarding sub-layer
functions, support for notably explicit routes, and resources functions, support for notably explicit routes, and resources
allocation to eliminate (or reduce) congestion loss and jitter. allocation to eliminate (or reduce) congestion loss and jitter.
Unlike other DetNet node types, transit nodes provide no service sub-
DetNet transit nodes reside wholly within a DetNet domain, and also layer processing.
provide DetNet forwarding sub-layer functions in accordance with the
performance required by a DetNet flow carried over an LSP. Unlike
other DetNet node types, transit nodes provide no service sub-layer
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)
skipping to change at page 8, line 38 skipping to change at page 8, line 32
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 The implementation of TSN entity (i.e., TSN packet processing
functions) MUST be compliant with the relevant IEEE 802.1 standards. 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 packet processing function(s) of Edge Nodes (T-PE) are belonging TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
to the native service processing (NSP) [RFC3985] block. This is to the native service processing (NSP) [RFC3985] block. This is
similar to other functionalities being defined by standard bodies similar to other functionalities being defined by standard bodies
other than the IETF (for example in case of Ethernet: stripping, other than the IETF (for example in case of Ethernet: stripping,
overwriting or adding VLAN tags, etc.). Depending on the TSN role of overwriting or adding VLAN tags, etc.). Depending on the TSN role of
the Edge Node in the end-to-end TSN service selected TSN functions the Edge Node in the end-to-end TSN service selected TSN functions
are 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 (see Clause 6. service, it first checks via Stream Identification (see Clause 6. of
of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
whether the packet belongs to a configured TSN Stream (i.e., App-flow 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 from DetNet perspective). If no Stream ID is matched and no other
(VPN) service is configured for the AC then packet MUST be dropped. (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 If there is a matching TSN Stream then the Stream-ID specific TSN
functions MUST be executed (e.g., ingress policing, header field functions are executed (e.g., ingress policing, header field
manipulation in case of active Stream Identification, FRER, etc.). manipulation in case of active Stream Identification, FRER, etc.).
Source MAC lookup MAY also be used for local MAC address learning. 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 (see Clause 6. Proxy, it first checks via Stream Identification (see Clause 6. of
of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
whether the packet belongs to a configured TSN Stream. If no Stream 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 ID is matched then packet is dropped. If there is a matching TSN
TSN Stream then the Stream ID specific TSN functions MUST be executed Stream then the Stream ID specific TSN functions are executed (e.g.,
(e.g., header field manipulation in case of active Stream header field manipulation in case of active Stream Identification,
Identification, FRER, etc.). Source MAC lookup MAY also be used for FRER, etc.). Source MAC lookup may also be used for local MAC
local MAC address learning. 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 is 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 floods 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 drops
drop the packet. 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
skipping to change at page 11, line 51 skipping to change at page 11, line 42
o TSN related configuration information according to the TSN role of o TSN related configuration information according to the TSN role of
the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
[IEEEP8021CBdb]. [IEEEP8021CBdb].
o DetNet MPLS related configuration information according to the o DetNet MPLS related configuration information according to the
DetNet role of the DetNet MPLS node, as per DetNet role of the DetNet MPLS node, as per
[I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls].
o App-Flow identification information to map received TSN Stream(s) o App-Flow identification information to map received TSN Stream(s)
to the DetNet flow. Parameters fo TSN stream identification are to the DetNet flow. Parameters of TSN stream identification are
defined in [IEEE8021CB] and [IEEEP8021CBdb]. defined in [IEEE8021CB] and [IEEEP8021CBdb].
This information MUST be provisioned per DetNet flow. This information MUST be provisioned per DetNet flow.
Mappings between DetNet and TSN management and control planes are out
of scope of the document. Some of the challanges are highligthed
below.
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 13, line 34 skipping to change at page 13, line 34
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., Malis, A., Bryant, S., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
detnet-mpls-06 (work in progress), April 2020. detnet-mpls-13 (work in progress), October 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>.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
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-06 (work in progress), May 2020. data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
(DetNet) Security Considerations", draft-ietf-detnet- Networking (DetNet) Security Considerations", draft-ietf-
security-10 (work in progress), May 2020. detnet-security-12 (work in progress), October 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 IEEE 802.1, "Standard for Local and metropolitan area
networks - Seamless Redundancy", IEEE P802.1CB networks - Frame Replication and Elimination for
/D2.1 P802.1CB, December 2015, Reliability (IEEE Std 802.1CB-2017)", 2017,
<http://www.ieee802.org/1/files/private/cb-drafts/d2/802- <http://standards.ieee.org/about/get/>.
1CB-d2-1.pdf>.
[IEEE8021Q] [IEEE8021Q]
IEEE 802.1, "Standard for Local and metropolitan area IEEE 802.1, "Standard for Local and metropolitan area
networks--Bridges and Bridged Networks (IEEE Std 802.1Q- networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
2014)", 2014, <http://standards.ieee.org/about/get/>. 2018)", 2018, <http://standards.ieee.org/about/get/>.
[IEEEP8021CBdb] [IEEEP8021CBdb]
Mangin, C., "Extended Stream identification functions", Mangin, C., "Extended Stream identification functions",
IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,
<http://www.ieee802.org/1/files/private/cb-drafts/d2/802- <http://www.ieee802.org/1/files/private/db-drafts/d1/802-
1CB-d2-1.pdf>. 1CBdb-d1-0.pdf>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[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>.
 End of changes. 22 change blocks. 
47 lines changed or deleted 42 lines changed or added

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