Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLSEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comMalis Consultingagmalis@gmail.comFuturewei Technologiessb@stewartbryant.comLabN Consulting, L.L.C.dfedyk@labn.netDetNetinterconnecting TSN networks
This document specifies the Deterministic Networking data plane
when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network.
Introduction
The Time-Sensitive Networking Task Group (TSN TG) within the IEEE 802.1 Working
Group deals with deterministic services through IEEE 802 networks.
Deterministic Networking (DetNet) defined by the IETF is a service that can be
offered by an L3 network to DetNet flows. General background and concepts
of DetNet can be found in .
This document specifies the use of a DetNet MPLS network to interconnect TSN
nodes/network segments. The DetNet MPLS data plane is defined in
.
TerminologyTerms Used in This Document
This document uses the terminology and concepts established in the DetNet
architecture . TSN-specific terms are defined in the TSN TG
of the IEEE 802.1 Working Group. The reader is assumed
to be familiar with these documents and their terminology.
Abbreviations
The following abbreviations are used in this document:
AC
Attachment Circuit
CE
Customer Edge equipment
d-CW
DetNet Control Word
DetNet
Deterministic Networking
DF
DetNet Flow
FRER
Frame Replication and Elimination for Redundancy
(TSN function)
Packet Replication, Elimination and Ordering Functions
PW
Pseudowire
S-PE
Switching Provider Edge
T-PE
Terminating Provider Edge
TSN
Time-Sensitive Network
Requirements Language
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
when, and only when, they appear in all capitals, as shown here.
IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario 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 PW
T-PE nodes, which use MPLS-TE LSPs. In this
example, TSN Streams are simple applications over DetNet flows. The specifics
of this operation are discussed later in this document.
A TSN over DetNet MPLS-Enabled Network | 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 --------------------->|
]]>
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.
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 the 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.
IEEE 802.1TSN over DetNet| 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
AC = Attachment Circuit
Tnl = Tunnel
]]>DetNet MPLS Data PlaneOverview
The basic approach defined in
supports the DetNet service sub-layer based on existing 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 that has the S-Label as top of stack,
uses the local context associated with that S-Label. For example, a received
F-Label can be used to determine what local DetNet operation(s) is applied to that
packet. An S-Label may be unique when taken from the platform
label space , 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 DetNet nodes and transit nodes include
DetNet forwarding sub-layer functions -- notably, support for
explicit routes and resource allocation to eliminate (or
reduce) congestion loss and jitter. Unlike other DetNet node types,
transit nodes provide no service sub-layer processing.
TSN over DetNet MPLS Encapsulation
The basic encapsulation approach is to treat a TSN Stream as an App-flow
from the DetNet MPLS perspective. The corresponding example is shown in
. Note that three example flows are
shown in the figure.
Examples of TSN over MPLS Encapsulation Formats +------+ +------+ +------+ TSN ^ ^
MPLS | | X | | X | | X |<- Appli : :
App-Flow <-+ +------+ +------+ +------+ cation : :(1)
| |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
]]>
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
. A single DetNet MPLS flow
can aggregate multiple TSN Streams.
TSN over MPLS Data Plane Procedures
The description of edge node procedures and functions for TSN over DetNet MPLS
scenarios follows the concepts from and covers the
edge node components shown in . In
this section, the following procedures of DetNet edge nodes are described:
TSN related ()
DetNet Service Proxy ()
DetNet service and forwarding sub-layer ()
The subsections 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.
Edge Node TSN Procedures
The TSN TG of the IEEE 802.1
Working Group has defined (and is defining) a number of amendments
to that provide zero
congestion loss and bounded latency in bridged networks.
defines packet
replication and elimination functions for a TSN network.
The implementation of a 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 being forwarded to
connected CE(s) or presented to the DetNet service proxy function for
transmission across the DetNet domain. TSN-specific functions
are also executed on the data received from a DetNet PW by a PE
before the data is output on the AC(s).
The TSN packet processing function(s) of edge nodes (T-PE) belongs to the
NSP
block. This is similar to other functionalities being defined by standards
bodies other than the IETF (for example, in the 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 first checks via Stream identification
(see Clause 6 of and
)
whether the packet belongs
to a configured TSN Stream (i.e., App-flow from the DetNet perspective).
If no Stream ID is matched and no other (VPN) service is configured
for the AC, then the packet MUST be dropped. If there is a matching TSN
Stream, then the Stream-ID-specific TSN functions are executed
(e.g., ingress policing, header field manipulation in the case
of active Stream identification, FRER, etc.). Source Media Access Control (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)). 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 first checks via Stream identification
(see Clause 6 of and
) whether
the packet belongs to a configured TSN Stream. If no Stream ID is
matched, then the packet is dropped. If there is a matching TSN
Stream, then the Stream-ID-specific TSN functions are 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 is forwarded
according to the TSN-Stream-specific configuration to connected CE(s).
If there are no TSN-Stream-specific forwarding configurations, the
PE floods the packet to locally attached CE(s). If the
administrative policy on the PE does not allow flooding, the PE
drops 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.
Edge Node DetNet Service Proxy Procedures
The service proxy
function maps between App-flows and DetNet flows.
The DetNet edge node TSN entity MUST support the TSN Stream
identification functions (as defined in Clause 6 of and ) and the related managed objects (as
defined in Clause 9 of and ) to
recognize the packets related to App-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 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 match is found, 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
fulfill the 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 might require copying of sequence
number fields from TSN (L2) to PW (MPLS) encapsulation.
However, such interworking is out of scope in this document and
is left for further study.
Edge Node DetNet Service and Forwarding Sub-Layer Procedures
In the design presented in , an MPLS service
label (the S-Label), similar to a PW label
, is used to identify both the DetNet flow
identity and the MPLS payload type. The DetNet sequence
number is carried in the d-CW, which carries the
Data/OAM discriminator as well. In
, two sequence number sizes
are supported: a 16-bit sequence number and a 28-bit sequence number.
PREOF functions and the provided service recovery are 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 nodes terminate all related information elements
encoded in the MPLS labels.
When a PE receives a packet from the service proxy function, it MUST
handle the packet as defined in .
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 .
Controller Plane (Management and Control) Considerations
Information related to TSN Stream(s) to DetNet flow mapping is
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:
TSN-related configuration information according to the
TSN role of the DetNet MPLS node, as per
, , and
.
DetNet MPLS-related configuration information according to the
DetNet role of the DetNet MPLS node, as per
.
App-flow identification information to map received TSN
Stream(s) to the DetNet flow. Parameters of TSN Stream
identification are defined in and
.
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 challenges are
highlighted below.
MPLS DetNet edge nodes are a 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 behave 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 the Ethernet perspective), some parameters
(e.g., delay) may differ significantly. Since there is no interworking
function, the bandwidth of the 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 information. TSN Stream ID(s) and stream-related
parameters/requirements must be converted to a DetNet flow ID and
flow-related parameters/requirements.
In some cases, it may be challenging to determine some information related to the egress-node. For example, it may be not trivial to
locate the egress point/interface of a TSN Stream 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 the 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
Security considerations for DetNet are described in detail in . General security
considerations are described in .
Considerations specific to the DetNet MPLS data plane are summarized and
described in , including any
application flow types. This document focuses on a scenario where TSN Streams are the application flows for DetNet, which is already covered
by those DetNet MPLS data plane security considerations.
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesStandard for Local and metropolitan area networks -- Frame Replication and Elimination for ReliabilityIEEEDraft Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability - Amendment: Extended Stream Identification FunctionsIEEEInformative ReferencesDeterministic Networking (DetNet) Security ConsiderationsStandard for Local and Metropolitan Area Networks--Bridges
and Bridged NetworksIEEEAcknowledgements
The authors wish to thank , , ,
, and for their various contributions
to this work.