DetNet Data Plane: IP over MPLSEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comEricssonMagyar Tudosok krt. 11.BudapestHungary1117janos.farkas@ericsson.comLabN Consulting, L.L.C.lberger@labn.netHuawei Technologiesagmalis@gmail.comHuawei 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 the DetNet data plane operation for IP
hosts and routers that provide DetNet service to IP encapsulated
data. No DetNet specific encapsulation is defined to support IP
flows, rather existing IP and higher layer protocol header information is used to support
flow identification and DetNet service delivery.
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service
protection and reordering. The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering). Since no DetNet specific headers are added to
support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document. Service
protection can be provided on a per sub-net
basis using technologies such as MPLS and IEEE802.1 TSN.
This document provides an overview of the DetNet IP data plane
over MPLS.
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 Replication, Ordering and Elimination 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 is 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 IP over DetNet MPLS follows below.
illustrates DetNet
enabled End Systems (hosts), connected to DetNet (DN) enabled
IP networks, operating over a DetNet aware MPLS network. In
this figure, Relay nodes sit at the boundary of the MPLS
domain since the non-MPLS domain is DetNet aware. This figure
is very similar to the DetNet MPLS Network figure in . The primary
difference is that the Relay nodes are at the edges of the
MPLS domain and therefore function as T-PEs, and that 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 non-DetNet
enabled End Systems (hosts), connected to DetNet (DN) enabled
MPLS network. It differs from in that the hosts and edge IP
networks 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.
illustrates how it is still
possible to provided DetNet service protection for
non-DetNet aware end systems. This figures is basically the
same as , with the exception
that CE1 and CE2 are non-DetNet aware end systems and E1 and E3
are edge nodes that replace the relay nodes R1 and R3.
The basic encapsulation
approach is to treat a DetNet IP flow as an app-flow from the
DetNet MPLS app perspective. The corresponding example DetNet
Sub-Network format is shown in .
In the figure, "IP App-Flow" indicates the payload carried by
the DetNet IP data plane. "IP" and "NProto" indicate the fields
described in Section 7.1.1. IP Header Information and Section 7.1.2.
Other Protocol Header Information in ,
respectively.
"MPLS App-Flow" 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 7.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 7.4. Aggregation Considerations in defines that aggregation is
supported through the use of prefixes, wildcards, bitmasks, and port
ranges. Collectively, this results in the fairly straight forward
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.
A relay node that sends a DetNet IP flow over a DetNet MPLS network
MUST map that single DetNet IP flow into a single app-flow and MUST
process that app-flow in accordance to the procedures defined in
Section 6.1. PRF MAY be
supported for DetNet IP flows sent over an DetNet MPLS network.
Aggregation MAY be supported as defined in Section 5.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 app-flows MUST
be supported via configuration, e.g., via the controller plane.
A relay node MAY be provisioned to handle packets received via the
DetNet MPLS data plane as DetNet IP flows. A single incoming MPLS
app-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 7.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 PEOF 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 an DetNet
IP flow is sent over DetNet MPLS, a 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 7.3 DetNet IP Traffic
Treatment Procedures in .
The security considerations of DetNet in general are discussed in
and . Other security
considerations will be added in a future version of
this draft.
TBD.
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5, far fewer than the 20 individuals below who
made important contributions to this draft. The editor wishes to thank
and acknowledge each of the following authors for contributing text to
this draft. See also .
The author(s) ACK and NACK.
The following people were part of the DetNet Data Plane Solution Design Team:
Jouni KorhonenJános FarkasNorman FinnBalázs VargaLoa AnderssonTal MizrahiDavid MozesYuanlong JiangAndrew MalisCarlos J. Bernardos
The DetNet chairs serving during the DetNet Data Plane Solution Design Team:
Lou BergerPat Thaler
Thanks to Stewart Bryant for his extensive review of the previous
versions of the document.
DetNet MPLS
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J.DetNet Data Plane IP
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J.DetNet Data Plane Framework
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J.