Deterministic Networking specific SID

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 https://datatracker.ietf.org/drafts/current/.¶

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 21 June 2025.¶

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

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]. This service protection method relies on copies of the same packet sent over multiple maximally disjoint paths and uses sequencing information to eliminate duplicates before delivered to its destination.¶

DetNet over an SRv6 data plane can provide a solution to transport sequencing information within a SID. This document describes a DetNet-specific SID (SID = Segment Identifier, [RFC8402]) and a set of related packet processing rules inside an SRv6 domain. The DetNet-specific SID provides Flow-ID and Sequence-Number information for the DetNet service sub-layer functions (i.e., PREOF).¶

The usage of DetNet-specific SID provides a native IPv6 data plane for DetNet networks and supports the implementation of PREOF functionalities on IPv6-only DetNet nodes. It is using native SRv6 technology and does not require additional tunneling or implementation of other protocol stack(s) (e.g., MPLS).¶

3. DetNet-specific SID

In SRv6, a SID represents a 128-bit value containing the following three parts [RFC8986]:¶

• Locator (LOC): first part of the SID with most significant bits and represents a specific SRv6 node.¶

• Function (FUNCT): the portion of the SID that is local to the owner node and designates a specific SRv6 function (network instruction) that is executed locally on a particular node (specified by Locator).¶

• Arguments (ARG): optional field and represents optional argument(s) to the function.¶

For PREOF processing, two arguments are needed:¶

1. Flow-ID: defines which DetNet flow the packet belongs to (what is used to determine which PREOF instance has to be used on a node). Its size is 20 bits for the DetNet MPLS data plane [RFC8986] and same size is appropriate for DetNet IP data plane as well.¶

2. Sequence Number: defines the sequencing information, it is created at the DetNet edge node (or by the first PRF node) and used by PEF/POF functionalities. For DetNet MPLS data plane the following sizes are defined: 0/16/28 bits [RFC8964].¶

The required size for these two arguments are maximum 48 bits.¶

The explicit format of DetNet-specific SID is network addressing design specific. PREOF specific parameters are encoded as follows:¶

• LOC: specifies the DetNet Relay node (same allocation rule applies as for any SRv6-enabled node).¶

• FUNCT: a single value represents all PREOF instances of a DetNet Relay node.¶

• ARG: Contains the Flow-ID and the Sequence Number parameters.¶

Note: if Function=PREOF, Arg=0 is also a meaningful value and does not refer to the lack of arguments.¶

The DetNet-specific SID must be the last segment in an SR Policy and it is associated with the PREOF functionality!¶

The following packet processing rules are defined as a new set of SRv6 SID behaviors regarding the DetNet-specific SID: (i) End.DPREOF, (ii) H.Encaps.PREOF, (iii) H.Encaps.PREOF.Red, (iv) H.Encaps.PREOF.L2, and (v) H.Encaps.PREOF.L2.Red.¶

4. SRv6 endpoint behaviors

This section describes the PREOF specific behaviors that can be associated with a SID.¶

+-------------+--------------------------------------------------+
| End.DPREOF  | Endpoint with decapsulation and PREOF Processing |
+-------------+--------------------------------------------------+

S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.    Send an ICMP Parameter Problem message to the Source Address
             with Code 0 (Erroneous header field encountered),
             and Pointer set to the Segments Left field,
             interrupt packet processing and discard the packet
S04.   }
S05.   Extract the ARG part of the SID
S06.   Remove the outer IPv6 header with all its extension headers
S07.   Forward the exposed payload and the ARG part to the PREOF
       functionality
S08. }

5. SR Policy Headend Behaviors

This section describes a set of SRv6 Policy Headend [RFC8402] behaviors.¶

+-----------------------+--------------------------------------------------+
| H.Encaps.PREOF        | SR Headend with PREOF Encapsulation              |
+-----------------------+--------------------------------------------------+
| H.Encaps.PREOF.Red    | H.Encaps with Reduced PREOF Encapsulation        |
+-----------------------+--------------------------------------------------+
| H.Encaps.PREOF.L2     | H.Encaps.PREOF Applied to Received L2 Frames     |
+-----------------------+--------------------------------------------------+
| H.Encaps.PREOF.L2.Red | H.Encaps.PREOF.Red Applied to Received L2 Frames |
+-----------------------+--------------------------------------------------+

S01. Push an IPv6 header with its own SRH
     Set the ARG part of the LAST SID in the segment list
S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
     in the segment list
S03. Set outer Payload Length, Traffic Class, Hop Limit, and
     Flow Label fields
S04. Set the outer Next Header value
S05. Decrement inner IPv6 Hop Limit or IPv4 TTL
S06. Submit the packet to the IPv6 module for transmission to S11

S01. Push an IPv6 header with its own SRH
     Set the ARG part of the LAST SID in the segment list
S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
     in the segment list
S03. Set outer Payload Length, Traffic Class, Hop Limit, and
     Flow Label fields
S04. Set the outer Next Header value
S05. <N/A>
S06. Submit the packet to the IPv6 module for transmission to S11

8. IANA Considerations

This document requires registration of End.DPREOF behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing Parameters" registry. IANA is requested to make one new assignments from the First Come First Served portion of the registry as follows:¶

 Value | Hex   | Endpoint Behavior | Reference  | Change Controller
 ------+-------+-------------------+------------+------------------
 TBD1  | xTBD1 | End.DPREOF        | [This.I-D] | IETF

9. Acknowledgements

Authors extend their appreciation to Janos Farkas, Istvan Moldovan and Miklos Mate for their insightful comments and productive discussion that helped to improve the document.¶

Authors' Addresses