doc: Add RFC documents

1 files changed, 537 insertions, 0 deletions

diff --git a/doc/rfc/rfc9566.txt b/doc/rfc/rfc9566.txt
new file mode 100644
index 0000000..39c68a4
--- /dev/null
+++ b/doc/rfc/rfc9566.txt
@@ -0,0 +1,537 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Varga
+Request for Comments: 9566                                     J. Farkas
+Category: Informational                                         Ericsson
+ISSN: 2070-1721                                                 A. Malis
+                                                        Malis Consulting
+                                                              April 2024
+
+
+ Deterministic Networking (DetNet) Packet Replication, Elimination, and
+            Ordering Functions (PREOF) via MPLS over UDP/IP
+
+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 and the mechanisms defined by MPLS-over-UDP technology.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of 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 obtained at
+   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) 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.  Terminology
+     2.1.  Terms Used in This Document
+     2.2.  Abbreviations
+   3.  Requirements for Adding PREOF to DetNet IP
+   4.  Adding PREOF to DetNet IP
+     4.1.  Solution Basics
+     4.2.  Encapsulation
+     4.3.  Packet Processing
+     4.4.  Flow Aggregation
+     4.5.  PREOF Processing
+     4.6.  PREOF-Capable DetNet IP Domain
+   5.  Control and Management Plane Parameters
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The DetNet Working Group has defined Packet Replication (PRF), Packet
+   Elimination (PEF), and Packet Ordering (POF) Functions (represented
+   as PREOF) to provide service protection by the DetNet service 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 PRF and PEF is described in [IEEE8021CB], and the
+   related YANG data model is defined in [IEEE8021CBcv].  A possible
+   implementation of POF is described in [RFC9550].  Figure 1 shows a
+   DetNet flow on which PREOF are applied during forwarding from the
+   source to the destination.
+
+                                          +------------+
+                +---------------E1---+    |            |
+    +---+       |               |    +---R3---+        |          +---+
+    |src|------R1           +---+             |        E3----O----+dst|
+    +---+       |           |                 E2-------+          +---+
+                +----------R2                 |
+                            +-----------------+
+
+    R: Replication Function (PRF)
+    E: Elimination Function (PEF)
+    O: Ordering Function (POF)
+
+                Figure 1: PREOF Scenario in a DetNet Network
+
+   In general, the use of PREOF require sequencing information to be
+   included in the packets of a DetNet compound flow.  This can be done
+   by adding a sequence number or 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 reusing the DetNet
+   MPLS-over-UDP/IP data plane [RFC9025] with the restriction of using
+   zero 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 familiar
+   with that document and its terminology.
+
+2.2.  Abbreviations
+
+   The following abbreviations are used in this document:
+
+   DetNet        Deterministic Networking
+
+   PEF           Packet Elimination Function
+
+   POF           Packet Ordering Function
+
+   PREOF         Packet Replication, Elimination, and Ordering Functions
+
+   PRF           Packet Replication Function
+
+3.  Requirements for 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]), and
+
+   *  to allow the DetNet service sub-layer for IP packet-switched
+      networks with minimal implementation effort.
+
+   The described solution 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 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 DetNet IP domain, the DetNet flow is
+   encapsulated in a UDP packet containing the sequence number used by
+   PREOF within the domain.  This solution maintains the 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 DetNet IP data plane fits into the DetNet sub-
+   layers.
+
+                    DetNet          IP
+                       .
+                       .
+                 +------------+
+                 |  Service   | d-CW, Service-ID (S-Label)
+                 +------------+
+                 | Forwarding | UDP/IP Header
+                 +------------+
+
+                                *d-CW: DetNet Control Word
+
+                Figure 2: PREOF-Capable DetNet IP Data Plane
+
+4.2.  Encapsulation
+
+   The PREOF-capable DetNet IP encapsulation builds on encapsulating
+   DetNet pseudowire (PW) directly over UDP.  That is, it combines
+   DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without
+   using any 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)
+   per [RFC8964].  The 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 IP) Packet      |
+      |                                 |
+      +---------------------------------+ <--\
+      |       DetNet Control Word       |    |
+      +---------------------------------+    +--> PREOF-capable
+      |       Service-ID (S-Label)      |    |    DetNet IP data
+      +---------------------------------+    |    plane encapsulation
+      |            UDP Header           |    |
+      +---------------------------------+    |
+      |            IP Header            |    |
+      +---------------------------------+ <--/
+      |            Data-Link            |
+      +---------------------------------+
+      |             Physical            |
+      +---------------------------------+
+
+              Figure 3: PREOF-Capable DetNet IP Encapsulation
+
+4.3.  Packet Processing
+
+   IP ingress and egress nodes of the 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, e.g., PEF
+   or POF, and the replication node can use different Service-ID values
+   for the different member flows for the same DetNet service.
+
+   Note that the Service-ID is a local ID on the receiver side 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
+
+   *  aggregation of DetNet flows as a new DetNet flow.
+
+   In the first method, the different DetNet 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 (see Figure 3).
+
+   For the second method, an additional hierarchy is created by adding
+   an additional Service-ID and d-CW tuple to the encapsulation.  The
+   Aggregate-ID is a special case of a Service-ID, whose properties are
+   known only at the aggregation and 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
+      |       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 as a New DetNet Flow
+
+   The aggregation method is configured in the aggregation/deaggregation
+   nodes.
+
+   If several 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 and can be used to
+   identify a DetNet flow regardless of which input interface or UDP
+   tunnel receives the packet.  It is important to note that 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 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-
+   capable DetNet IP packet.
+
+   The incoming PREOF processing can be implemented by assigning a
+   Service-ID to the received DetNet flow and processing the information
+   in the UDP and IP headers.  The provisioned information is used to
+   identify incoming App-flows based on the combination of Service-ID
+   and/or incoming encapsulation header information.
+
+4.6.  PREOF-Capable DetNet IP Domain
+
+   Figure 5 shows using PREOF in a PREOF-capable DetNet IP network,
+   where service protection is provided end to end, and not only within
+   sub-networks, as is depicted in Figure 4 <https://www.rfc-
+   editor.org/rfc/rfc8939#figure-4> of [RFC8939].
+
+             <---------- PREOF-capable DetNet IP --------------->
+                                       ______
+                             ____     /      \__
+                  ____      /     \__/          \____________
+   +----+      __/    \____/                                 \    +----+
+   |src |_____/                                               \___| dst|
+   +----+     \_______            DetNet network    __________/   +----+
+                      \_______                    _/
+                              \         __     __/
+                               \_______/  \___/
+
+                                          +------------+
+                +---------------E1---+    |            |
+   +----+       |               |    +---R3---+        |          +----+
+   |src |------R1           +---+             |        E3----O----+ dst|
+   +----+       |           |                 E2-------+          +----+
+                +----------R2                 |
+                            +-----------------+
+
+                  Figure 5: PREOF-Capable DetNet IP 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 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 field.
+
+   *  IPv4 or IPv6 destination address prefix length, where a zero (0)
+      effectively means that the address field is ignored.
+
+   *  IPv6 Flow Label field.
+
+   *  IPv4 Protocol field being equal to "UDP".
+
+   *  IPv6 (last) Next Header field being equal to "UDP".
+
+   *  For the IPv4 Type of Service and IPv6 Traffic Class fields:
+
+      -  Whether or not the Differentiated Services Code Point (DSCP)
+         field is used in flow 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.
+
+   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
+
+   *  Sequence number length
+
+   *  Type of PREOF to be executed on the DetNet flow
+
+   *  Service-ID(s) used by the member flows
+
+   *  Associated forwarding sub-layer information
+
+   *  Service aggregation information
+
+   The minimum set of information for the configuration of the DetNet
+   forwarding sub-layer is summarized as follows:
+
+   *  UDP tunnel-specific information
+
+   *  Traffic parameters
+
+   These parameters are defined in the DetNet flow and service
+   information model [RFC9016] and the DetNet YANG model.
+
+   Note: this document focuses on the use of MPLS-over-UDP/IP
+   encapsulation throughout an entire DetNet IP network, making MPLS-
+   based DetNet Operations, Administration, and Maintenance (OAM)
+   techniques applicable [RFC9546].  Using the described encapsulation
+   only for a portion of a DetNet IP network that handles PREOF would
+   complicate OAM.
+
+6.  Security Considerations
+
+   There are no new 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 has no IANA actions.
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [RFC9546]  Mirsky, G., Chen, M., and B. Varga, "Operations,
+              Administration, and Maintenance (OAM) for Deterministic
+              Networking (DetNet) with the MPLS Data Plane", RFC 9546,
+              DOI 10.17487/RFC9546, February 2024,
+              <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://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, and Management Information Base Module", Amendment
+              to IEEE Std 802.1CB-2017, IEEE 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 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