DetNet                                                     B. Varga, Ed.
Internet-Draft                                                 J. Farkas
Intended status: Standards Track                                Ericsson
Expires: November 6, 2019 January 2, 2020                                       L. Berger
                                                 LabN Consulting, L.L.C.
                                                                A. Malis
                                                               S. Bryant
                                                  Futurewei Technologies
                                                             J. Korhonen
                                                             May 5,
                                                            July 1, 2019

                  DetNet Data Plane: MPLS over IP
                 draft-ietf-detnet-mpls-over-udp-ip-00 UDP/IP


   This document specifies the MPLS Deterministic Networking data plane
   operation and encapsulation over an IP network.  The approach is
   modeled on the operation of MPLS and PseudoWires (PW) over IP. UDP/IP packet switched

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 6, 2019. January 2, 2020.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  DetNet MPLS Operation over DetNet
       IP PSNs . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations
   4.  DetNet Data Plane Procedures  . . . . . . . . . . . . . . . .   5
   5.  Management and Control Information Summary  . . .   6
   6.  IANA Considerations . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . .   6
   7.  Contributors . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9   8

1.  Introduction

   Deterministic Networking (DetNet) is a service that can be offered by
   a network to DetNet flows.  DetNet provides these flows with a 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 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) leveraging MPLS Traffic Engineering mechanisms.

   This document specifies use of the MPLS DetNet encapsulation over an
   IP network.  The approach is modeled on the operation of MPLS and
   PseudoWires (PW) over an
   IP Packet Switched Network (PSN)
   [RFC3985][RFC4385][RFC7510]. [RFC7510].  It maps the MPLS data
   plane encapsulation described in [I-D.ietf-detnet-mpls] to the DetNet
   IP data plane defined in [I-D.ietf-detnet-ip].

   To carry DetNet flows with full functionality at the DetNet layer
   over an IP network, the following components are required (these are
   a subset of the requirements for MPLS encapsulation listed in

   1.  A method of identifying the DetNet flow group to the processing

   2.  A method of carrying the DetNet sequence number.

   3.  A method of distinguishing DetNet OAM packets from DetNet data

   4.  A method of carrying queuing and forwarding indication.

   These requirements are satisfied by the DetNet over MPLS
   Encapsulation described in [I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls] and they are partly
   satisfied by the DetNet IP data plane defined in [I-D.ietf-detnet-ip]

2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology established in the DetNet
   architecture [I-D.ietf-detnet-architecture], and the reader is
   assumed to be familiar with that document and its terminology.

2.2.  Abbreviations

   The following abbreviations are used in this document:

   CW            Control Word.

   d-CW          A DetNet Control Word (d-CW) is used for sequencing and
                 identifying duplicate packets of a DetNet flow at the
                 DetNet service sub-layer.

   DetNet        Deterministic Networking.

   A-Label       A special case of an S-Label, whose properties are
                 known only at the aggregation and deaggregation end-

   F-Label       A Detnet "forwarding" label that identifies the LSP
                 used to forward a DetNet flow across an MPLS PSN, e.g.,
                 a hop-by-hop label used between label switching routers

   LSR           Label Switching Router.

   MPLS          Multiprotocol Label Switching.

   OAM           Operations, Administration, and Maintenance.

   PEF           Packet Elimination Function.

   PRF           Packet Replication Function.

   PREOF         Packet Replication, Elimination and Ordering Functions.

   POF           Packet Ordering Function.

   PRF           Packet Replication Function.

   PSN           Packet Switched Network.

   PW            PseudoWire.

   S-Label       A DetNet "service" label that is used between DetNet
                 nodes that implement also the DetNet service sub-layer
                 functions.  An S-Label is also used to identify a
                 DetNet flow at DetNet service sub-layer.


2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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 MPLS Operation over DetNet IP PSNs

   This document builds on the specification of MPLS over UDP and IP defined in
   [RFC7510].  It replaces may replace partly or entirely the F-Label(s) used in
   [I-D.ietf-detnet-mpls] with UDP and IP headers.  The UDP and IP
   header information is used to identify DetNet flows, including member
   flows, per [I-D.ietf-detnet-ip].  The resulting encapsulation is
   shown in Figure 1.  There may be zero or more F-label(s) between the
   S-label and the UDP header.

   Note that this encapsulation works equally well with IPv4, IPv6, and
   IPv6-based Segment Routing [I-D.ietf-6man-segment-routing-header].

      |                                 |
      |         DetNet App-Flow         |
      |         Payload  Packet         |
      |                                 |
      +---------------------------------+ <--\
      |       DetNet Control Word       |    |
      +---------------------------------+    +--> DetNet data plane
      |             S-Label             |    |    MPLS encapsulation
      +---------------------------------+    |
      |          [ F-label(s) ]         |    |
      +---------------------------------+ <--+
      |           UDP Header            |    |
      +---------------------------------+    +--> DetNet data plane
      |           IP Header             |    |    IP encapsulation
      +---------------------------------+ <--/
      |           Data-Link             |
      |           Physical              |

               Figure 1: IP UDP/IP Encapsulation of DetNet MPLS

   d-CW and and

   d-CW, S-Labels and zero or more F-Labels are used as defined in
   [I-D.ietf-detnet-mpls] and are not modified by this document.  In
   case of aggregates the A-Label is treated as an S-Label and it too is
   not modified.

4.  DetNet Data Plane Procedures

   To support outgoing DetNet MPLS over IP, UDP/IP encapsulation, an
   implementation MUST support the provisioning of IP/UDP UDP and IP header
   information in addition or in place of
   sets of F-Labels.  Note that multiple sets of F-Labels can be
   provisioned to support PRF on transmitted DetNet flows and therefore, F-Label(s).  Note, when PRF is supported, multiple IP/UDP headers MAY
   performed at the MPLS service sub-layer, there will be provisioned.
   When multiple IP/UDP headers are provisioned for a particular
   outgoing app-flow, a copy of the outgoing packet, including
   member flows, and each member flow will require the
   pushed S-Label, MUST be made for each. provisioning of
   their own UDP and IP header information.  The headers for each
   outgoing packet MUST be based formatted on the configuration information
   and as defined in [RFC7510], with one exception.  The one exception is  Note that the UDP
   Source Port value MUST be set to uniquely identify the DetNet
   (forwarding sub-layer) flow.
   The packet MUST then be handed as a DetNet IP packet, per
   [I-D.ietf-detnet-ip].  This includes QoS related traffic treatment.

   To support receive processing an implementation MUST also support the
   provisioning of received IP/UDP UDP and IP header information.  When S-Labels
   are taken from platform label space, all that is required is to
   provision that receiving IP/UDP encapsulated DetNet MPLS packets is
   permitted.  Once the IP/UDP header is stripped, the S-label uniquely
   identifies the app-flow.  When S-Labels are not taken from platform
   label space, IP/UDP header information MUST be provisioned.  The
   provisioned information MUST then be used  The
   provisioned information MUST be used to identify incoming app-
   flows app-flows
   based on the combination of S-Label and incoming IP/UDP header. encapsulation header
   information.  Normal receive processing, processing as defined in
   [I-D.ietf-detnet-mpls], including PEOF PEF and POF, can then take place.

5.  Management and Control Information Summary

   The following summarizes the set of information that is needed to
   configure DetNet MPLS over UDP/IP:

   o  Label information (S-label or F-label) to be mapped to UDP/IP
      flow.  Note that a single S-Label can map to multiple sets of UPD/
      IP information when PREOF is used.

   o  IPv4 and IPv6 source address field.

   o  IPv4 and IPv6 destination address field.

   o  IPv4 Type of Service and IPv6 Traffic Class Fields.

   o  UDP Source Port.

   o  UDP Destination Port.

   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller or management plane.

   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.

6.  Security Considerations

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

   [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip].  This draft does not
   have additional security considerations.

7.  IANA Considerations

   This document makes no IANA requests.

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 many 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.

      Stewart Bryant
      Huawei Technologies

      Mach Chen
      Huawei Technologies

      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:

      Jouni Korhonen

      Janos Farkas authors wish to thank Pat Thaler, Norman Finn

      Balazs Varga Finn, Loa Andersson Anderson,
   David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi Mizrahi, David Mozes
   Mozes, Craig Gunther, George Swallow, Yuanlong Jiang
      Andrew Malis and Carlos J.

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

      Lou Berger

      Pat Thaler for their various contributions to this work.

9.  References

9.1.  Normative References

              Korhonen, J.,
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
              draft-ietf-detnet-ip-00 (work in progress), May 2019.

              Korhonen, J.,
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
              draft-ietf-detnet-mpls-00 (work in progress), May 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
              February 2006, <>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510,
              DOI 10.17487/RFC7510, April 2015,

   [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

              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d., "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-header-18 draft-ietf-6man-segment-routing-
              header-21 (work in progress), April June 2019.

              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), March May 2019.


              Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
              J., Austad, H., Stanton, K., and N. Finn, "Deterministic
              Networking (DetNet) Security
              Considerations, draft-sdt-detnet-security, work in
              progress", 2017.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, Considerations", draft-ietf-
              detnet-security-04 (work in progress), March 2005,
              <>. 2019.

Authors' Addresses

   Balazs Varga (editor)
   Magyar Tudosok krt. 11.
   Budapest  1117


   Janos Farkas
   Magyar Tudosok krt. 11.
   Budapest  1117


   Lou Berger
   LabN Consulting, L.L.C.


   Andrew G. Malis
   Futurewei Technologies


   Stewart Bryant
   Futurewei Technologies


   Jouni Korhonen