DetNet Data Plane: IP over MPLSEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netIndependentagmalis@gmail.comFuturewei Technologiesstewart.bryant@gmail.comjouni.nospam@gmail.comDetNet
This document specifies the Deterministic Networking data plane
when operating in an IP over MPLS packet switched network.
Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.
DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end
delivery latency. General background and concepts of DetNet can
be found in the DetNet Architecture .
This document specifies use of the IP DetNet encapsulation over an
MPLS network. It maps the IP data plane encapsulation described in to the DetNet MPLS data plane defined in .
This document uses the terminology and concepts established in
the DetNet architecture
and , and the
reader is assumed to be familiar with these documents and their
terminology.
This document uses the abbreviations defined in the DetNet
architecture and
.
This document uses the following abbreviations:
Customer Edge equipment.Deterministic Networking.DetNet Flow.DetNet.Layer-2.Layer-3.Label-switched path.Multiprotocol Label Switching.Provider Edge.Packet Elimination Function.Packet Replication Function.Packet Replication, Elimination and Ordering Functions.Packet Ordering Function.Packet Switched Network.Pseudowire.Traffic Engineering.Time-Sensitive Networking, TSN is a Task Group of the IEEE
802.1 Working Group.
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.
illustrates an IP DetNet, with an MPLS based DetNet
network as a sub-network between the relay nodes. It shows a
more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs. The end systems
still originate IP encapsulated traffic that are identified as
DetNet flows. The relay nodes follow procedures defined in
to map each DetNet
flow to MPLS LSPs. While not shown, relay nodes can provide
service sub-layer functions such as PREOF using DetNet over MPLS,
and this is indicated by the solid line for the MPLS
facing portion of the Service component. Note that the Transit
node is MPLS (TE) LSP aware and performs switching based on MPLS
labels, and need not have any specific knowledge of the DetNet
service or the corresponding DetNet flow identification. See
for details on the mapping of IP
flows to MPLS, and
for general support of DetNet services using MPLS.
This section defines how IP encapsulated flows are carried over
a DetNet MPLS data plane as defined in . Since both Non-DetNet and
DetNet IP packet are identical on the wire, this section is
applicable to any node that supports IP over DetNet MPLS, and
this section refers to both cases as DetNet IP over DetNet MPLS.
An example use of DetNet IP over DetNet MPLS is presented here.
illustrated DetNet
enabled End Systems (hosts), connected to DetNet (DN) enabled
IP networks, operating over a DetNet aware MPLS network.
Using this figure we can have a case where the Relay nodes act as
T-PEs and sit at the boundary of the MPLS
domain since the non-MPLS domain is DetNet aware. This case
is very similar to the DetNet MPLS Network figure 2 in . However in figure 2 the T-PEs are located at the
end system and MPLS spans the whole DetNet service.
The primary difference in this document is that the Relay nodes are at the edges of the
MPLS domain and therefore function as T-PEs, and that MPLS service
sub-layer functions are not provided over the DetNet IP
network. The transit node functions show above are identical
to those described in .
illustrates how relay nodes
can provide service protection over an MPLS domain. In this
case, CE1 and CE2 are IP DetNet end systems which are
interconnected via a MPLS domain such as described in . Note that R1 and R3
sit at the edges of an MPLS domain and therefore are similar
to T-PEs, while R2 sits in the middle of the domain and is
therefore similar to an S-PE.
illustrates DetNet
enabled End Systems, connected to DetNet (DN) enabled
MPLS network. A similar situation occurs when
end systems are are not DetNet aware. In this case, edge nodes sit at
the boundary of the MPLS domain since it is also a DetNet domain
boundary. The edge nodes provide DetNet service proxies for the
end applications by initiating and terminating DetNet service
for the application's IP flows. While the node types differ,
there is essentially no difference in data plane processing
between relay and edges. There are likely to be differences
in controller plane operation, particularly when distributed
control plane protocols are used.
It is still possible to provided DetNet service protection for
non-DetNet aware end systems. This case is basically the
same as , with the exception
that CE1 and CE2 are non-DetNet aware end systems and R1 and R3
become edge nodes.
The basic encapsulation
approach is to treat a DetNet IP flow as an app-flow from the
DetNet MPLS perspective. The corresponding example DetNet
Sub-Network format is shown in .
In "App-Flow" indicates the payload carried by
the DetNet IP data plane. "IP" and "NProto" indicate the fields
described in Section 5.1.1. IP Header Information and Section 5.1.2.
Other Protocol Header Information in ,
respectively.
"App-Flow for MPLS" indicates
that an individual DetNet IP flow is the payload from the
perspective of the DetNet MPLS data plane defined in .
Per , the DetNet MPLS data plane
uses a single S-Label to support a single app flow. Section 5.1. DetNet
IP Flow Identification Procedures in states that a single DetNet flow
is identified based on IP, and next level protocol, header information.
Section 4.4. Aggregation Considerations in defines the ways in which aggregation is
supported through the use of prefixes, wildcards, lists, and port
ranges. Collectively, this results in the fairly straightforward
procedures defined in this section.
As shown in , DetNet relay nodes
are responsible for the mapping of a DetNet flow, at the service
sub-layer, from the IP to MPLS DetNet data planes and back
again. Their related DetNet IP over DetNet MPLS data plane
operation is comprised of two sets of procedures: the mapping of
flow identifiers, and ensuring proper traffic treatment.
Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows.
The six-tuple of IP is mapped to the S-Label in both cases.
The various fields may be mapped or ignored when going from IP to MPLS.
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a DetNet MPLS network
MUST map a DetNet IP flow, as identified in into a single MPLS DetNet flow and MUST
process it in accordance to the procedures defined in
. PRF MAY be
supported at the MPLS level for DetNet IP flows sent over an DetNet MPLS network.
Aggregation MAY be supported as defined in Section 4.4. Aggregation
considerations in MAY be used to
identify an individual DetNet IP flow. The provisioning of the
mapping of DetNet IP flows to DetNet MPLS flows MUST
be supported via configuration, e.g., via the controller plane.
A DetNet relay node (egress T-PE) MAY be provisioned to handle packets received via the
DetNet MPLS data plane as DetNet IP flows. A single incoming DetNet MPLS
flow MAY be treated as a single DetNet IP flow, without
examination of IP headers. Alternatively, packets received via the
DetNet MPLS data plane MAY follow the normal DetNet IP flow
identification procedures defined in Section 5.1.
An implementation MUST support the provisioning for handling any
received DetNet MPLS data plane as DetNet IP flows via configuration.
Note that such configuration MAY include support from PREOF on the
incoming DetNet MPLS flow.
The traffic treatment required for a particular DetNet IP flow is
provisioned via configuration or the controller plane. When a DetNet
IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure that the
provisioned DetNet IP traffic treatment is provided at the forwarding
sub-layer as described in
Section 5.2. Note that the PRF function MAY be utilized when sending
IP over MPLS.
Traffic treatment for DetNet IP flows received over the DetNet
MPLS data plane MUST follow Section 5.3 DetNet IP Traffic
Treatment Procedures in .
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS ingress node:
Each MPLS App-Flow is identified using the IP flow
identification information as defined in . The information is summarized
in Section 5.1 of that document, and includes all wildcards,
port ranges and the ability to ignore specific IP fields.
The DetNet MPLS service that is to be used to send the
matching IP traffic. This matching information is
provided in Section 5.1, and includes
both service and traffic delivery information.
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS egress node:
S-Label values that are carrying MPLS over IP encapsulated
traffic.
For each S-Label, how the received traffic is to be
handled. The traffic may be processed according as any other
DetNet IP traffic as defined in this document or in , or the traffic may be
directly treated as an MPLS App-flow for additional
processing according to .
It is the responsibility of the DetNet controller plane to
properly provision both flow identification information and
the flow specific resources needed to provided the traffic
treatment needed to meet each flow's service requirements.
This applies for aggregated and individual flows.
This draft does not have additional security considerations. Security
considerations for DetNet are described in detail in . General security
considerations are described in . MPLS and IP specific
considerations are described in
and .
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service traversing
the DetNet network.
Application flows can be protected through whatever means is
provided by the underlying technology. For example, encryption may be
used, such as that provided by IPSec for IP
flows and/or by an underlying sub-net using MACSec
for IP over Ethernet (Layer-2) flows.
From a data plane perspective this document does not add or modify any
header information.
At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane
attackers with additional information about the data flows (when
compared to controller planes that do not include per-flow identification).
This is an inherent property of DetNet which has security
implications that should be considered when determining if DetNet is
a suitable technology for any given use case.
To provide uninterrupted availability of the DetNet
service, provisions can be made against DOS attacks and delay
attacks. To protect against DOS attacks, excess traffic due to
malicious or malfunctioning devices can be prevented or mitigated,
for example through the use of existing mechanism such as policing and shaping applied at
the input of a DetNet domain. To prevent DetNet packets from
being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of
Man-In-The-Middle attacks, for example through use of
authentication and authorization of devices within the DetNet domain.
This document makes no IANA requests.
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black,
Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther,
George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their
various contributions to this work.
János Farkas contributed substantially to the content of this
document.
IEEE Std 802.1AE-2018 MAC Security (MACsec)IEEE Standards Association