DetNet B. Varga, Ed.
Internet-Draft J. Farkas
Intended status: Standards Track Ericsson
Expires: November 7, 2019 L. Berger
LabN Consulting, L.L.C.
A. Malis
S. Bryant
Huawei Technologies
J. Korhonen
May 6, 2019

DetNet Data Plane: IP over MPLS


This document specifies the Deterministic Networking data plane when operating in an IP over MPLS packet switched network.

Status of This Memo

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

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 November 7, 2019.

Copyright Notice

Copyright (c) 2019 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 ( 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.

Table of Contents

1. Introduction

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 [I-D.ietf-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 [I-D.ietf-detnet-mpls] and IEEE802.1 TSN.

This document provides an overview of the DetNet IP data plane over MPLS.

2. Terminology

2.1. Terms Used In This Document

This document uses the terminology and concepts established in the DetNet architecture [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-data-plane-framework], and the reader is assumed to be familiar with these documents and their terminology.

2.2. Abbreviations

This document uses the abbreviations defined in the DetNet architecture [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-data-plane-framework]. This document uses the following abbreviations:

Customer Edge equipment.
Deterministic Networking.
DetNet Flow.
Label-switched path.
Multiprotocol Label Switching.
Provider Edge.
Packet Replication, Ordering and Elimination Function.
Packet Switched Network.
Traffic Engineering.
Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group.

2.3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. DetNet IP Data Plane Overview

Figure 1 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 Section 4 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 Section 4 for details on the mapping of IP flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of DetNet services using MPLS.

 DetNet IP       Relay         Transit         Relay      DetNet IP
 End System      Node           Node           Node       End System

+----------+                                              +---------+
|   Appl.  |<-------------- End to End Service ---------->|  Appl.  |
+----------+   .....-----+                  +-----.....   +---------+
| Service  |<--: Service |-- DetNet flow ---| Service :-->| Service |
|          |   :         |<- DN MPLS flow ->|         :   |         |
+----------+   +---------+   +----------+   +---------+   +---------+
|Forwarding|   |Fwd| |Fwd|   |Forwarding|   |Fwd| |Fwd|   |   Fwd   |
+--------.-+   +-.-+ +-.-+   +---.----.-+   +-.-+ +-.-+   +----.----+
         :  Link :    /  ,-----.  \   :  Link :    /  ,-----.  \
         +.......+    +-[  Sub  ]-+   +.......+   +--[  Sub  ]--+
                        [Network]                    [Network]
                         `-----'                      `-----'

                       |<---- DetNet MPLS --->|
         |<--------------------- DetNet IP ------------------->|

Figure 1: DetNet IP Over DetNet MPLS Network

4. IP over DetNet MPLS

This section defines how IP encapsulated flows are carried over a DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. 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.

4.1. IP Over DetNet MPLS Data Plane Scenarios

An example use of IP over DetNet MPLS follows below.

IP  DetNet        Relay       Transit         Relay       IP DetNet
End System        Node         Node           Node        End System
                  (T-PE)       (LSR)          (T-PE)
+----------+                                             +----------+
|   Appl.  |<------------ End to End Service ----------->|   Appl.  |
+----------+   .....-----+                 +-----.....   +----------+
| Service  |<--: Service |-- DetNet flow --| Service :-->| Service  |
+----------+   +---------+  +----------+   +---------+   +----------+
|Forwarding|   |Fwd| |Fwd|  |Forwarding|   |Fwd| |Fwd|   |Forwarding|
+-------.--+   +-.-+ +-.-+  +----.---.-+   +-.-+ +-.-+   +---.------+
        :  Link  :    /  ,-----.  \   : Link :    /  ,-----.  \
        +........+    +-[  Sub  ]-+   +......+    +-[  Sub  ]-+
                        [Network]                   [Network]
                         `-----'                     `-----'

        |<- DN IP->| |<---- DetNet MPLS ---->| |< -DN IP ->|

Figure 2: DetNet IP Over MPLS Network

Figure 2 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 [I-D.ietf-detnet-mpls]. 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 [I-D.ietf-detnet-mpls].

Figure 3 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 [I-D.ietf-detnet-mpls]. 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.

      DetNet                                         DetNet
IP    Service         Transit          Transit       Service  IP
DetNet               |<-Tnl->|        |<-Tnl->|               DetNet
End     |            V   1   V        V   2   V            |  End
System  |   +--------+       +--------+       +--------+   |  System
+---+   |   |   R1   |=======|   R2   |=======|   R3   |   |   +---+
|   |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------|   |
|CE1|   |   |    \   |       |   X    |       |   /    |   |   |CE2|
|   |   |   |     \_.|..DF2..|._/ \__.|..DF4..|._/     |   |   |   |
+---+       |        |=======|        |=======|        |       +---+
    ^       +--------+       +--------+       +--------+       ^
    |        Relay Node       Relay Node       Relay Node      |
    |          (T-PE)           (S-PE)          (T-PE)         |
    |                                                          |
    |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
    |                                                          |
    |<-------------- End to End DetNet Service --------------->|

   -------------------------- Data Flow ------------------------->

    X   = Service protection (PRF, PREOF, PEF/POF)
    DFx = DetNet member flow x over a TE LSP

Figure 3: DetNet IP Over DetNet MPLS Network

 IP               Edge                        Edge        IP
 End System       Node                        Node        End System
                 (T-PE)       (LSR)          (T-PE)
+----------+   +....-----+                 +-----....+   +----------+
|   Appl.  |<--:Svc Proxy|-- E2E Service --|Svc Proxy:-->|   Appl.  |
+----------+   +.....+---+                 +---+.....+   +----------+
|    IP    |<--:IP : |Svc|-- IP/DN Flow ---|Svc| :IP :-->|    IP    |
+----------+   +---+ +---+  +----------+   +---+ +---+   +----------+
|Forwarding|   |Fwd| |Fwd|  |Forwarding|   |Fwd| |Fwd|   |Forwarding|
+-------.--+   +-.-+ +-.-+  +----.---.-+   +-.-+ +-.-+   +---.------+
        :  Link  :    /  ,-----.  \   : Link :    /  ,-----.  \
        +........+    +-[  Sub  ]-+   +......+    +-[  Sub  ]-+
                        [Network]                   [Network]
                         `-----'                     `-----'

      |<--- IP --->| |<----- DetNet MPLS ----->| |<--- IP --->|

Figure 4: Non-DetNet Aware IP Over DetNet MPLS Network

Figure 4 illustrates non-DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled MPLS network. It differs from Figure 2 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.

Figure 5 illustrates how it is still possible to provided DetNet service protection for non-DetNet aware end systems. This figures is basically the same as Figure 3, 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.

      IP                                              IP
Non   Service          Transit          Transit       Service Non
DetNet                |<-Tnl->|        |<-Tnl->|              DetNet
End     |             V   1   V        V   2   V            | End
System  |    +--------+       +--------+       +--------+   | System
+---+   |    |   E1   |=======|   R2   |=======|   E3   |   |  +---+
|   |--------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|------|   |
|CE1|   |    |    \   |       |   X    |       |   /    |   |  |CE2|
|   |   |    |     \_.|..DF2..|._/ \__.|..DF4..|._/     |   |  |   |
+---+        |        |=======|        |=======|        |      +---+
             +--------+       +--------+       +--------+
             ^ Edge Node      Relay Node       Edge Node^
             | (T-PE)           (S-PE)          (T-PE)  |
             |                                          |
     <--IP-->| <-------- IP Over DetNet MPLS ---------> |<--IP-->
             |                                          |
             |<------ End to End DetNet Service ------->|

    X   = Optional service protection (none, PRF, PREOF, PEF/POF)
    DFx = DetNet member flow x over a TE LSP

Figure 5: MPLS-Based DetNet (non-MPLS End System)

4.2. DetNet IP over DetNet MPLS Encapsulation

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 Figure 6.

           /->     +------+  +------+  +------+              ^
           |       |  X   |  |  X   |  |  X   | IP App-Flow  :
           |       +------+  +------+  +------+              :
MPLS     <-+       |NProto|  |NProto|  |NProto|              :(1)
 App-Flow  |       +------+  +------+  +------+              :
           |       |  IP  |  |  IP  |  |  IP  |              v
           \-> +---+======+--+======+--+======+-----+
DetNet-MPLS        | d-CW |  | d-CW |  | d-CW |              ^
                   +------+  +------+  +------+              :(2)
                   |Labels|  |Labels|  |Labels|              v
Sub-Network        |  L2  |  | TSN  |  | UDP  |
                   +------+  +------+  +------+
                                       |  IP  |
                                       |  L2  |
    (1) DetNet IP Flow
    (2) DetNet MPLS Flow

Figure 6: Example DetNet IP over MPLS Sub-Network Formats

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 [I-D.ietf-detnet-ip], 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 [I-D.ietf-detnet-mpls].

Per [I-D.ietf-detnet-mpls], 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 [I-D.ietf-detnet-ip] states that a single DetNet flow is identified based on IP, and next level protocol, header information. Section 7.4. Aggregation Considerations in [I-D.ietf-detnet-ip] 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 Figure 4, 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.

4.3. DetNet IP over DetNet MPLS Flow Identification Procedures

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 [I-D.ietf-detnet-mpls] Section 6.1. PRF MAY be supported for DetNet IP flows sent over an DetNet MPLS network. Aggregation MAY be supported as defined in [I-D.ietf-detnet-mpls] Section 5.4. Aggregation Considerations in [I-D.ietf-detnet-ip] 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 [I-D.ietf-detnet-ip] 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.

4.4. DetNet IP over DetNet MPLS Traffic Treatment Procedures

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 [I-D.ietf-detnet-mpls] 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 [I-D.ietf-detnet-ip].

5. Security Considerations

The security considerations of DetNet in general are discussed in [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other security considerations will be added in a future version of this draft.

6. IANA Considerations


7. Contributors

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 Section 8.

   Loa Andersson

   Yuanlong Jiang

   Norman Finn
   3101 Rio Way
   Spring Valley, CA  91977

   Janos Farkas
   Magyar Tudosok krt. 11
   Budapest  1117

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911

   Tal Mizrahi
   6 Hamada st.

   Lou Berger
   LabN Consulting, L.L.C.

   Andrew G. Malis
   Huawei Technologies

8. Acknowledgements

The author(s) ACK and NACK.

The following people were part of the DetNet Data Plane Solution Design Team:

The DetNet chairs serving during the DetNet Data Plane Solution Design Team:

Thanks to Stewart Bryant for his extensive review of the previous versions of the document.

9. References

9.1. Normative references

[I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B. and J. Farkas, "Deterministic Networking Architecture", Internet-Draft draft-ietf-detnet-architecture-12, March 2019.
[I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J., "DetNet Data Plane IP", 2019.
[I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J., "DetNet MPLS", 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

9.2. Informative references

[I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Korhonen J., "DetNet Data Plane Framework", 2019.
[I-D.ietf-detnet-security] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K. and N. Finn, "Deterministic Networking (DetNet) Security Considerations", Internet-Draft draft-ietf-detnet-security-04, March 2019.

Authors' Addresses

Balázs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest, 1117 Hungary EMail:
János Farkas Ericsson Magyar Tudosok krt. 11. Budapest, 1117 Hungary EMail:
Lou Berger LabN Consulting, L.L.C. EMail:
Andrew G. Malis Huawei Technologies EMail:
Stewart Bryant Huawei Technologies EMail:
Jouni Korhonen EMail: