DetNet

Internet Engineering Task Force (IETF)                          B. Varga
Internet-Draft
Request for Comments: 9566                                     J. Farkas
Intended status:
Category: Informational                                         Ericsson
Expires: 25 August 2024
ISSN: 2070-1721                                                 A. Malis
                                                        Malis Consulting
                                                        22 February
                                                              April 2024

 Deterministic Networking (DetNet): DetNet PREOF (DetNet) Packet Replication, Elimination, and
            Ordering Functions (PREOF) via MPLS over UDP/IP
                draft-ietf-detnet-mpls-over-ip-preof-11

Abstract

   This document describes how the DetNet IP data plane can support the
   Packet Replication, Elimination, and Ordering Functions (PREOF) built
   on the existing MPLS PREOF solution defined for the DetNet MPLS Data
   Plane data
   plane and the mechanisms defined by MPLS-over-UDP technology.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of six months Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 25 August 2024.
   https://www.rfc-editor.org/info/rfc9566.

Copyright Notice

   Copyright (c) 2024 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 (https://trustee.ietf.org/
   license-info)
   (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements for adding Adding PREOF to DetNet IP  . . . . . . . . .   4
   4.  Adding PREOF to DetNet IP . . . . . . . . . . . . . . . . . .   4
     4.1.  Solution Basics . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Encapsulation . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Packet Processing . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Flow Aggregation  . . . . . . . . . . . . . . . . . . . .   6
     4.5.  PREOF Processing  . . . . . . . . . . . . . . . . . . . .   7
     4.6.  PREOF capable  PREOF-Capable DetNet IP domain  . . . . . . . . . . . . .   8 Domain
   5.  Control and Management Plane Parameters . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The DetNet Working Group has defined Packet Replication (PRF), Packet
   Elimination (PEF) (PEF), and Packet Ordering (POF) functions Functions (represented
   as PREOF) to provide service protection by the DetNet service sub-layer sub-
   layer [RFC8655].  The PREOF service protection method relies on
   copies of the same packet sent over multiple maximally disjoint paths
   and uses sequencing information to eliminate duplicates.  A possible
   implementation of the PRF and PEF functions is described in
   [IEEE8021CB] [IEEE8021CB], and the
   related YANG data model is defined in
   [IEEEP8021CBcv]. [IEEE8021CBcv].  A possible
   implementation of the POF function is described in [I-D.ietf-detnet-pof]. [RFC9550].  Figure 1 shows a
   DetNet flow on which PREOF functions are applied during forwarding from the
   source to the destination.

                                          +------------+
                +---------------E1---+    |            |
    +---+       |               |    +---R3---+        |          +---+
    |src|------R1           +---+             |        E3----O----+dst|
    +---+       |           |                 E2-------+          +---+
                +----------R2                 |
                            +-----------------+

    R: replication function Replication Function (PRF)
    E: elimination function Elimination Function (PEF)
    O: ordering function Ordering Function (POF)

                Figure 1: PREOF scenario Scenario in a DetNet network Network

   In general, the use of PREOF functions require sequencing information to be
   included in the packets of a DetNet compound flow.  This can be done
   by adding a sequence number or time stamp timestamp as part of DetNet
   encapsulation.  Sequencing information is typically added once, at or
   close to the source.

   The DetNet MPLS data plane [RFC8964] specifies how sequencing
   information is encoded in the MPLS header.  However, the DetNet IP
   data plane described in [RFC8939] does not specify how sequencing
   information can be encoded in the IP packet.  This document provides
   sequencing information to DetNet IP nodes, so it results in an
   improved version of the DetNet IP data plane.  As suggested by
   [RFC8938], the solution uses existing standardized headers and
   encapsulations.  The improvement is achieved by re-using reusing the DetNet
   MPLS over UDP/IP
   MPLS-over-UDP/IP data plane [RFC9025] with the restriction of using
   zero F-labels. F-Labels.

2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology established in the DetNet
   architecture [RFC8655], and it is assumed that the reader is assumed to be familiar
   with that document and its terminology.

2.2.  Abbreviations

   The following abbreviations are used in this document:

   DetNet        Deterministic Networking. Networking

   PEF           Packet Elimination Function. Function

   POF           Packet Ordering Function. Function

   PREOF         Packet Replication, Elimination Elimination, and Ordering Functions. Functions

   PRF           Packet Replication Function. Function

3.  Requirements for adding Adding PREOF to DetNet IP

   The requirements for adding PREOF to DetNet IP are:

   *  to reuse existing DetNet data plane solutions (e.g., [RFC8964],
      [RFC9025]).
      [RFC9025]), and

   *  to allow the DetNet service sub-layer for IP packet switched packet-switched
      networks with minimal implementation effort.

   The described solution practically gains from leverages MPLS header fields without requiring
   the support of the MPLS forwarding plane.

4.  Adding PREOF to DetNet IP

4.1.  Solution Basics

   The DetNet IP encapsulation supporting the DetNet Service service sub-layer
   is based on the "UDP tunneling" concept.  The solution creates a set
   of underlay UDP/IP tunnels between an overlay set of DetNet relay
   nodes.

   At the edge of a PREOF capable PREOF-capable DetNet IP domain domain, the DetNet flow is
   encapsulated in an a UDP packet containing the sequence number used by
   PREOF functions within the domain.  This solution maintains the 6-
   tuple-based 6-tuple-based
   DetNet flow identification in DetNet transit nodes, which operate at
   the DetNet forwarding sub-layer between the DetNet service sub-layer
   nodes; therefore, it is compatible with [RFC8939].  Figure 2 shows
   how the PREOF capable PREOF-capable DetNet IP data plane fits into the DetNet sub-layers. sub-
   layers.

                    DetNet          IP
                       .
                       .
                 +------------+
                 |  Service   | d-CW, Service-ID (S-label) (S-Label)
                 +------------+
                 | Forwarding | UDP/IP Header
                 +------------+

                                *d-CW: DetNet Control Word

                Figure 2: PREOF capable PREOF-Capable DetNet IP data plane Data Plane

4.2.  Encapsulation

   The PREOF capable PREOF-capable DetNet IP encapsulation builds on encapsulating
   DetNet PseudoWire pseudowire (PW) directly over UDP.  That is, it combines
   DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without
   using any F-Labels F-Labels, as shown in Figure 3.  DetNet flows are
   identified at the receiving DetNet service sub-layer processing node
   via the S-Label and/or the UDP/IP header information.  Sequencing
   information for PREOF is provided by the DetNet Control Word (d-CW) as
   per [RFC8964].  The S-label S-Label is used to identify both the DetNet flow
   and the DetNet App-flow type.  The UDP tunnel is used to direct the
   packet across the DetNet domain to the next DetNet service sub-layer
   processing node.

      +---------------------------------+
      |                                 |
      |         DetNet App-Flow         |
      |       (original       (Original IP) Packet      |
      |                                 |
      +---------------------------------+ <--\
      |       DetNet Control Word       |    |
      +---------------------------------+    +--> PREOF capable PREOF-capable
      |       Service-ID (S-Label)      |    |    DetNet IP data
      +---------------------------------+    |    plane encapsulation
      |            UDP Header           |    |
      +---------------------------------+    |
      |            IP Header            |    |
      +---------------------------------+ <--/
      |            Data-Link            |
      +---------------------------------+
      |             Physical            |
      +---------------------------------+

              Figure 3: PREOF capable PREOF-Capable DetNet IP encapsulation Encapsulation

4.3.  Packet Processing

   IP ingress and egress nodes of the PREOF capable PREOF-capable DetNet IP domain add
   and remove a DetNet service-specific d-CW and Service-ID (i.e.,
   S-Label).  Relay nodes can change Service-ID values when processing a
   DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow
   can be different.  Service-ID values are provisioned per DetNet
   service via configuration, e.g., via the Controller Plane described
   in [RFC8938].  In some PREOF topologies, the node performing
   replication sends the packets to multiple nodes performing performing, e.g., PEF
   or POF POF, and the replication node can use different Service-ID values
   for the different member flows for the same DetNet service.

   Note,

   Note that Service-IDs the Service-ID is a local ID on the receiver side providing
   identification of that
   identifies the DetNet flow at the downstream DetNet service sub-layer
   receiver.

4.4.  Flow Aggregation

   Two methods can be used for flow aggregation:

   *  aggregation using same UDP tunnel, and

   *  aggregating  aggregation of DetNet flows as a new DetNet flow.

   In the first case, method, the different DetNet PseudoWires pseudowires use the same
   UDP tunnel, so they are treated as a single (aggregated) flow at the
   forwarding sub-layer.  At the service sub-layer, each flow uses a
   different Service ID Service-ID (see Figure 3 ). 3).

   For the second option, method, an additional hierarchy is created thanks to by adding
   an additional Service-ID and d-CW tuple added to the encapsulation.  The
   Aggregate-ID is a special case of a Service-ID, whose properties are
   known only at the aggregation and de-aggregation deaggregation end points.  It is a
   property of the Aggregate-ID that it is followed by a d-CW followed
   by a Service-ID/d-CW tuple.  Figure 4 shows the encapsulation in the
   case of aggregation.

      +---------------------------------+
      |                                 |
      |         DetNet App-Flow         |
      |         Payload  Packet         |
      |                                 |
      +---------------------------------+ <--\
      |       DetNet Control Word       |    |
      +---------------------------------+    +--> PREOF capable PREOF-capable
      |       Service-ID (S-Label)      |    |    DetNet IP data
      +---------------------------------+    |    plane encapsulation
      |       DetNet Control Word       |    |
      +---------------------------------+    |
      |      Aggregate-ID (A-Label)     |    |
      +---------------------------------+    |
      |           UDP Header            |    |
      +---------------------------------+    |
      |            IP Header            |    |
      +---------------------------------+ <--/
      |            Data-Link            |
      +---------------------------------+
      |             Physical            |
      +---------------------------------+

          Figure 4: Aggregating DetNet flows Flows as a new New DetNet flow Flow

   The option used for aggregation method is known by configuration of configured in the
   aggregation/de-aggregation aggregation/deaggregation
   nodes.

   If several Detnet DetNet flows are aggregated in a single UDP tunnel, they
   all need to follow the same path in the network.

4.5.  PREOF Processing

   A node operating on a received DetNet flow at the DetNet service sub-
   layer uses the local context associated with a received Service-ID to
   determine which local DetNet operation(s) are applied to the received
   packet.  A unique Service-ID can be allocated to be unique and enabling can be used to
   identify a DetNet flow identification regardless of which input interface or UDP
   tunnel receives the packet is received. packet.  It is important to note that Service-
   ID Service-ID
   values are driven by the receiver, not the sender.

   The DetNet forwarding sub-layer is supported by the UDP tunnel and is
   responsible for providing resource allocation and explicit routes.

   The outgoing PREOF encapsulation and processing can be implemented
   via the provisioning of UDP and IP header information.  Note, when
   PRF is performed at the DetNet service sub-layer, there are multiple
   member flows, and each member flow requires their its own Service-ID, UDP
   header information, and IP header information.  The headers for each
   outgoing packet are formatted according to the configuration
   information, and the UDP Source Port value is set to uniquely
   identify the DetNet flow.  The packet is then handled as a PREOF PREOF-
   capable DetNet IP packet.

   The incoming PREOF processing can be implemented via by assigning a
   Service-ID to the provisioning
   of received Service-ID, DetNet flow and processing the information
   in the UDP and IP header information. headers.  The provisioned information is used to
   identify incoming app-flows App-flows based on the combination of Service-ID
   and/or incoming encapsulation header information.

4.6.  PREOF capable  PREOF-Capable DetNet IP domain Domain

   Figure 5 shows using PREOF in a PREOF capable PREOF-capable DetNet IP network,
   where service protection is provided end to end, an and not only within
   sub-networks like
   sub-networks, as is depicted in Figure 4 <https://www.rfc-
   editor.org/rfc/rfc8939#figure-4> of [RFC8939].

             <---------- PREOF capable PREOF-capable DetNet IP --------------->
                                       ______
                             ____     /      \__
                  ____      /     \__/          \____________
   +----+      __/    \____/                                 \    +----+
   |src |_____/                                               \___| dst|
   +----+     \_______            DetNet network    __________/   +----+
                      \_______                    _/
                              \         __     __/
                               \_______/  \___/

                                          +------------+
                +---------------E1---+    |            |
   +----+       |               |    +---R3---+        |          +----+
   |src |------R1           +---+             |        E3----O----+ dst|
   +----+       |           |                 E2-------+          +----+
                +----------R2                 |
                            +-----------------+

                  Figure 5: PREOF capable PREOF-Capable DetNet IP domain Domain

5.  Control and Management Plane Parameters

   The information needed to identify individual and aggregated DetNet
   flows is summarized as follows:

   *  Service-ID information to be mapped to UDP/IP flows.  Note that,
      for example, a single Service-ID can map to multiple sets of UDP/
      IP information when PREOF is used.

   *  IPv4 or IPv6 source address Source Address field.

   *  IPv4 or IPv6 source address prefix length, where a zero (0) value
      effectively means that the address field is ignored.

   *  IPv4 or IPv6 destination address Destination Address field.

   *  IPv4 or IPv6 destination address prefix length, where a zero (0)
      effectively means that the address field is ignored.

   *  IPv6 flow label Flow Label field.

   *  IPv4 protocol Protocol field being equal to "UDP".

   *  IPv6 (last) next header Next Header field being equal to "UDP".

   *  For the IPv4 Type of Service and IPv6 Traffic Class Fields: fields:

      -  Whether or not the DSCP Differentiated Services Code Point (DSCP)
         field is used in flow identification identification, as the use of the DSCP
         field for flow identification is optional.

      -  If the DSCP field is used to identify a flow, then the flow
         identification information (for that flow) includes a list of
         DSCPs used by the given DetNet flow.

   *  UDP Source Port.  Support for both exact and wildcard matching is
      required.  Port ranges can optionally be used.

   *  UDP Destination Port.  Support for both exact and wildcard
      matching is required.  Port ranges can optionally be used.

   *  For end systems, an optional maximum IP packet size that should be
      used for that outgoing DetNet IP flow.

   This information is provisioned per DetNet flow via configuration,
   e.g., via the controller plane. Controller Plane.

   Ordering of the set of information used to identify an individual
   DetNet flow can, for example, be used to provide a DetNet service for
   a specific UDP flow, with unique Source and Destination Port field
   values, while providing a different service for the aggregate of all
   other flows with that same UDP Destination Port value.

   The minimum set of information for the configuration of the DetNet
   service sub-layer is summarized as follows:

   *  App-flow identification information. information

   *  Sequence number length. length

   *  Type of PREOF + related Service-ID(s). to be executed on the DetNet flow

   *  Service-ID(s) used by the member flows

   *  Associated forwarding sub-layer information. information

   *  Service aggregation information. information

   The minimum set of information for the configuration of the DetNet
   forwarding sub-layer is summarized as follows:

   *  UDP tunnel specific information. tunnel-specific information

   *  Traffic parameters. parameters

   These parameters are defined in the DetNet Flow flow and Service service
   information model [RFC9016] and the DetNet YANG model.

   Note: this document focuses on the use of MPLS over UDP/IP MPLS-over-UDP/IP
   encapsulation throughout an entire DetNet IP network, making MPLS-
   based DetNet OAM Operations, Administration, and Maintenance (OAM)
   techniques applicable [I-D.ietf-detnet-mpls-oam]. [RFC9546].  Using the described encapsulation
   only for a portion of a DetNet IP network that handles the PREOF functionality would
   complicate OAM.

6.  Security Considerations

   There are no new DetNet related DetNet-related security considerations introduced by
   this solution.  Security considerations of DetNet MPLS [RFC8964] and
   DetNet MPLS over UDP/IP [RFC9025] apply.

7.  IANA Considerations

   This document makes has no IANA requests. actions.

8.  Acknowledgements

   Authors extend their appreciation to Stewart Bryant, Pascal Thubert,
   David Black, Shirley Yangfan and Greg Mirsky for their insightful
   comments and productive discussion that helped to improve the
   document.

9.  References

9.1.

8.1.  Normative References

   [I-D.ietf-detnet-mpls-oam]
              Mirsky, G., Chen, M., and B. Varga, "Operations,
              Administration and Maintenance (OAM) for Deterministic
              Networks (DetNet) with MPLS Data Plane", Work in Progress,
              Internet-Draft, draft-ietf-detnet-mpls-oam-15, 12 January
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              detnet-mpls-oam-15>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8938]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane
              Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
              <https://www.rfc-editor.org/info/rfc8938>.

   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
              <https://www.rfc-editor.org/info/rfc8939>.

   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "Deterministic Networking (DetNet)
              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
              2021, <https://www.rfc-editor.org/info/rfc8964>.

   [RFC9016]  Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
              Fedyk, "Flow and Service Information Model for
              Deterministic Networking (DetNet)", RFC 9016,
              DOI 10.17487/RFC9016, March 2021,
              <https://www.rfc-editor.org/info/rfc9016>.

   [RFC9025]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
              2021, <https://www.rfc-editor.org/info/rfc9025>.

9.2.  Informative References

   [I-D.ietf-detnet-pof]

   [RFC9546]  Mirsky, G., Chen, M., and B. Varga, B., Farkas, J., Kehrer, S., "Operations,
              Administration, and T. Heer,
              "Deterministic Maintenance (OAM) for Deterministic
              Networking (DetNet): Packet Ordering
              Function", Work in Progress, Internet-Draft, draft-ietf-
              detnet-pof-11, 15 January (DetNet) with the MPLS Data Plane", RFC 9546,
              DOI 10.17487/RFC9546, February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              pof-11>.
              <https://www.rfc-editor.org/info/rfc9546>.

8.2.  Informative References

   [IEEE8021CB]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability", IEEE Std 802.1CB-2017,
              DOI 10.1109/IEEESTD.2017.8091139, October 2017,
              <https://standards.ieee.org/standard/802_1CB-2017.html>.

   [IEEEP8021CBcv]
              Kehrer, S., "FRER
              <https://doi.org/10.1109/IEEESTD.2017.8091139>.

   [IEEE8021CBcv]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability - Amendment 1: Information Model, YANG Data Model
              Model, and Management Information Base Module", Amendment
              to IEEE Std 802.1CB-2017, IEEE P802.1CBcv
              /D1.2 P802.1CBcv, Std 802.1CBcv-2021,
              DOI 10.1109/IEEESTD.2022.9715061, February 2022,
              <https://doi.org/10.1109/IEEESTD.2022.9715061>.

   [RFC9550]  Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer,
              "Deterministic Networking (DetNet): Packet Ordering
              Function", RFC 9550, DOI 10.17487/RFC9550, March 2021,
              <https://www.ieee802.org/1/files/private/cv-drafts/d1/802-
              1CBcv-d1-2.pdf>. 2024,
              <https://www.rfc-editor.org/info/rfc9550>.

Acknowledgements

   Authors extend their appreciation to Stewart Bryant, Pascal Thubert,
   David Black, Shirley Yangfan, and Greg Mirsky for their insightful
   comments and productive discussion that helped to improve the
   document.

Authors' Addresses

   Balazs Varga
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary
   Email: balazs.a.varga@ericsson.com

   Janos Farkas
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary
   Email: janos.farkas@ericsson.com

   Andrew G. Malis
   Malis Consulting
   Email: agmalis@gmail.com