| DetNet | B. Varga, Ed. |
| Internet-Draft | J. Farkas |
| Intended status: Standards Track | Ericsson |
| Expires: December 10, 2020 | A. Malis |
| Malis Consulting | |
| S. Bryant | |
| Futurewei Technologies | |
| D. Fedyk | |
| LabN Consulting, L.L.C. | |
| June 8, 2020 |
DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
draft-ietf-detnet-tsn-vpn-over-mpls-03
This document specifies the Deterministic Networking data plane when TSN networks are interconnected over a DetNet MPLS Network.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2020.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 Working Group deals with deterministic services through IEEE 802 networks. Deterministic Networking (DetNet) defined by IETF is a service that can be offered by a L3 network to DetNet flows. General background and concepts of DetNet can be found in [RFC8655].
This document specifies the use of a DetNet MPLS network to interconnect TSN nodes/network segments. DetNet MPLS data plane is defined in [I-D.ietf-detnet-mpls].
This document uses the terminology and concepts established in the DetNet architecture [RFC8655] and [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 terminology.
The following abbreviations are used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
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 at the boundary of a DetNet domain. They are responsible for mapping non-DetNet aware L2 traffic to DetNet services. They also support the imposition and disposition of the required DetNet encapsulation. These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example TSN Streams are simple applications over DetNet flows. The specific of this operation are discussed later in this document.
TSN Edge Transit Edge TSN
End System Node Node Node End System
(T-PE) (LSR) (T-PE)
+----------+ +----------+
| TSN | <---------End to End TSN Service----------> | TSN |
| Applic. | | Applic. |
+----------+ +.........+ +.........+ +----------+
| | | \S-Proxy: :S-Proxy/ | | |
| TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN |
| | |TSN| |Svc| |Svc| |TSN| | |
+----------+ +---+ +---+ +----------+ +---+ +---+ +----------+
| L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 |
+------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+
[Network] [Network]
`-----' `-----'
|<------ DetNet MPLS ------>|
|<---------------------- TSN --------------------->|
Figure 1: A TSN over DetNet MPLS Enabled Network
In this example, edge nodes provide a service proxy function that "associates" the DetNet flows and native flows (i.e., TSN Streams) at the edge of the DetNet domain. TSN streams are treated as App-flows for DetNet. The whole DetNet domain behaves as a TSN relay node for the TSN streams. The service proxy behaves as a port of that TSN relay node.
Figure 2 illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network. Edge nodes, E1 and E2, insert and remove required DetNet data plane encapsulation. The 'X' in the edge nodes and relay node, R1, represent a potential DetNet compound flow packet replication and elimination point. This conceptually parallels L2VPN services, and could leverage existing related solutions as discussed below.
TSN |<------- End to End DetNet Service ------>| TSN
Service | Transit Transit | Service
TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN
End | V V 1 V V 2 V V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | E1 |=======| R1 |=======| E2 | | +---+
| |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| |
|CE1| | | \ | | X | | / | | |CE2|
| | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Edge Node Relay Node Edge Node |
| (T-PE) (S-PE) (T-PE) |
| |
|<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|
| |
|<-------- Time Sensitive Networking (TSN) Service ------->|
X = Service protection
DFx = DetNet member flow x over a TE LSP
Figure 2: IEEE 802.1TSN Over DetNet
The basic approach defined in [I-D.ietf-detnet-mpls] supports the DetNet service sub-layer based on existing pseudowire (PW) encapsulations and mechanisms, and supports the DetNet forwarding sub-layer based on existing MPLS Traffic Engineering encapsulations and mechanisms.
A node operating on a DetNet flow in the Detnet service sub-layer, i.e. a node processing a DetNet packet which has the S-Label as top of stack uses the local context associated with that S-Label, for example a received F-Label, to determine what local DetNet operation(s) are applied to that packet. An S-Label may be unique when taken from the platform label space [RFC3031], which would enable correct DetNet flow identification regardless of which input interface or LSP the packet arrives on. The service sub-layer functions (i.e., PREOF) use a DetNet control word (d-CW).
The DetNet MPLS data plane builds on MPLS Traffic Engineering encapsulations and mechanisms to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes. The forwarding sub-layer is supported by one or more forwarding labels (F-Labels).
DetNet edge/relay nodes are DetNet service sub-layer aware, understand the particular needs of DetNet flows and provide both DetNet service and forwarding sub-layer functions. They add, remove and process d-CWs, S-Labels and F-labels as needed. MPLS enabled DetNet nodes can enhance the reliability of delivery by enabling the 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 allocation to eliminate (or reduce) congestion loss and jitter.
DetNet transit nodes reside wholly within a DetNet domain, and also 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.
The basic encapsulation approach is to treat a TSN Stream as an App-flow from the DetNet MPLS perspective. The corresponding example shown in Figure 3.
/-> +------+ +------+ +------+ TSN ^ ^
| | X | | X | | X |<- Appli : :
App-Flow <-+ +------+ +------+ +------+ cation : :(1)
for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v
\-> +---+======+--+======+--+======+-----+ :
| d-CW | | d-CW | | d-CW | :
DetNet-MPLS +------+ +------+ +------+ :(2)
|Labels| |Labels| |Labels| v
+---+======+--+======+--+======+-----+
Link/Sub-Network | L2 | | TSN | | UDP |
+------+ +------+ +------+
| IP |
+------+
| L2 |
+------+
(1) TSN Stream
(2) DetNet MPLS Flow
Figure 3: Example TSN over MPLS Encapsulation Formats
In the figure, "Application" indicates the application payload carried by the TSN network. "MPLS App-Flow" indicates that the TSN Stream is the payload from the perspective of the DetNet MPLS data plane defined in [I-D.ietf-detnet-mpls]. A single DetNet MPLS flow can aggregate multiple TSN Streams.
Description of Edge Nodes procedures and functions for TSN over DetNet MPLS scenario follows the concept of [RFC3985] and covers the Edge Nodes components shown on Figure 1. In this section the following procedures of DetNet Edge Nodes are described:
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.
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 Working Group have defined (and are defining) a number of amendments to IEEE 802.1Q that provide zero congestion loss and bounded latency in bridged networks. IEEE 802.1CB defines packet replication and elimination functions for a TSN 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 DetNet Edge Node from the connected CE before forwarded to connected CE(s) or presentation to the DetNet Service Proxy function for 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 packet processing function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) [RFC3985] block. This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, 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 are supported.
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. of IEEE 802.1CB and IEEE P802.1CBdb) 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 (see Clause 6. of IEEE 802.1CB and IEEE P802.1CBdb) 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 information to ensure TSN specific functions of the Edge Node according to the expectations of the connected TSN network.
The Service Proxy function maps between App-flows and DetNet flows. The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined in Clause 6. and Clause 9. of IEEE 802.1CB and IEEE P802.1CBdb to recognize the App-flow related packets. 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 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 information to map a TSN Stream to a DetNet flow. N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) SHALL be supported. The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows.
Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions service protection function interworking is possible between the TSN and the DetNet domains. Such service protection interworking scenarios MAY require to copy sequence number fields from TSN (L2) to PW (MPLS) encapsulation. However, such interworking is out-of-scope in this document and left for further study.
A MPLS DetNet flow is configured to carry any number of TSN flows. The DetNet flow specific bandwidth profile SHOULD match the required bandwidth of the App-flow aggregate.
In the design of [I-D.ietf-detnet-mpls] an MPLS service label (the S-Label), similar to a pseudowire (PW) label [RFC3985], is used to identify both the DetNet flow identity and the payload MPLS payload type. The DetNet sequence number is carried in the DetNet Control word (d-CW) which carries the Data/OAM discriminator as well. In [I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16 bit sequence number and a 28 bit sequence number.
PREOF functions and the provided service recovery is available only within the DetNet domain as the DetNet flow-ID and the DetNet sequence number are not valid outside the DetNet network. MPLS (DetNet) Edge node terminates all related information elements encoded in the MPLS labels.
The LSP used to forward the DetNet packet may be of any type (MPLS-LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]). The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.
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].
TSN Stream(s) to DetNet flow mapping related information are required only for the service proxy function of MPLS (DetNet) Edge nodes. From the Data Plane perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane).
The following summarizes the set of information that is needed to configure TSN over DetNet MPLS:
This information MUST be provisioned per DetNet flow.
MPLS DetNet Edge nodes are member of both the DetNet domain and the connected TSN network. From the TSN network perspective the MPLS (DetNet) Edge node has a "TSN relay node" role, so TSN specific management and control plane functionalities must be implemented. There are many similarities in the management plane techniques used in DetNet and TSN, but that is not the case for the control plane protocols. For example, RSVP-TE and MSRP behaves differently. Therefore management and control plane design is an important aspect of scenarios, where mapping between DetNet and TSN is required.
Note that, as the DetNet network is just a portion of the end to end TSN path (i.e., single hop from Ethernet perspective), some parameters (e.g., delay) may differ significantly. Since there is no interworking function the bandwidth of DetNet network is assumed to be set large enough to handle all TSN Flows it will support. At the egress of the Detnet Domain the MPLS headers are stripped and the TSN flow continues on as a normal TSN flow.
In order to use a DetNet network to interconnect TSN segments, TSN specific information must be converted to DetNet domain specific ones. TSN Stream ID(s) and stream(s) related parameters/requirements must be converted to a DetNet flow-ID and flow related parameters/requirements.
In some case it may be challenging to determine some egress node related information. For example, it may be not trivial to locate the egress point/interface of a TSN Streams with a multicast destination MAC address. Such scenarios may require interaction between control and management plane functions and between DetNet and TSN domains.
Mapping between DetNet flow identifiers and TSN Stream identifiers, if not provided explicitly, can be done by the service proxy function of an MPLS (DetNet) Edge node locally based on information provided for configuration of the TSN Stream identification functions (e.g., Mask-and-Match Stream identification).
Triggering the setup/modification of a DetNet flow in the DetNet network is an example where management and/or control plane interactions are required between the DetNet and the TSN network.
Configuration of TSN specific functions (e.g., FRER) inside the TSN network is a TSN domain specific decision and may not be visible in the DetNet domain. Service protection interworking scenarios are left for further study.
Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. General security considerations are described in [RFC8655].
DetNet MPLS data plane specific considerations are summarized and described in [I-D.ietf-detnet-mpls] including any application flow types. This document focuses on the scenario where TSN Streams are the application flows for DetNet and it is already covered by those DetNet MPLS data plane security considerations.
This document makes no IANA requests.
The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, Christophe Mangin and Jouni Korhonen for their various contributions to this work.
| [I-D.ietf-detnet-mpls] | Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane: MPLS", Internet-Draft draft-ietf-detnet-mpls-06, April 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3031] | Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |