Network                                                     Shaofu. Peng
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                         11 October 2024
Expires: 14 April 2025


                   Deterministic Source Route Header
                    draft-p-6man-deterministic-eh-01

Abstract

   This document introduces a new IPv6 Routing Header that is a variant
   of RPL Source Route Header (SRH) and used for deterministic
   forwarding wihch is generally a strict explicit path.  This Routing
   Header contains the decoupled topology instructions and deterministic
   forwarding resource indications.  The target is low cost of
   encapasultion and less amount of allocated SIDs.

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 14 April 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.



Peng                      Expires 14 April 2025                 [Page 1]


Internet-Draft      Deterministic Source Route Header       October 2024


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  The Source Route Headers for DetNet (DetNet SRH)  . . . . . .   3
   3.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Processing on the Headend Node  . . . . . . . . . . . . .   8
     3.2.  Processing on the Transit or Endpoint Node  . . . . . . .  10
   4.  Other Design Considerations . . . . . . . . . . . . . . . . .  11
     4.1.  Heterogeneous Segment List  . . . . . . . . . . . . . . .  11
     4.2.  Packet Parsing by Offline Tool  . . . . . . . . . . . . .  12
     4.3.  ICMP Error Processing . . . . . . . . . . . . . . . . . .  12
     4.4.  Upper-Layer Checksums . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   [RFC8655] describes the architecture of Deterministic Networking
   (DetNet) and defines the QoS goals: Minimum and maximum end-to-end
   latency from source to destination, timely delivery, and bounded
   jitter (packet delay variation); packet loss ratio under various
   assumptions as to the operational states of the nodes and links; an
   upper bound on out-of-order packet delivery.  In order to achieve
   these goals, DetNet use resource reservation, explicit routing,
   service protection and other means.  In general, the strictly
   explicit path is calculated by the centralized controller.  There is
   such a need that metadata related to each hop used to provide DetNet
   QoS needs to be carried in the packet to avoid network core
   maintenance flow states and meet large scaling requirements.

   [RFC8200] defines the Routing Header.  The source node of the IPv6
   packet can include some segment information in the Routing Header to
   control the packet's access to these segments before reaching the
   final destination node.  How to reduce the cost of Routing Header,
   especially in scenarios with strict explicit deterministic forwarding
   paths, is a concern.  Generally, there are two categories of
   optimization methods.  One is to use short indexes to map to IPv6
   addresses, and the other is to rely on a common prefix for all
   segments.  For example, [RFC9631] defines two new routing headers
   called CRH-16 and CRH-32, containing a short index for mapping to
   128-bit IPv6 addresses, and retrieving all forwarding information
   from the CRH-FIB entries matched by the index.  And, [RFC6554]



Peng                      Expires 14 April 2025                 [Page 2]


Internet-Draft      Deterministic Source Route Header       October 2024


   defines RPL Source Route Header (SRH), where only the different parts
   of each segment need to be stored in the segment list, and the common
   prefix of all elements is stored in the Destination Address field of
   the IPv6 header.  [I-D.ietf-spring-srv6-srh-compression] also
   describes another common prefixes based compression method suitable
   for SRv6 network.

   To meet the requirement of deterministic forwarding,
   [I-D.pb-6man-deterministic-crh] defines an Routing Header based on
   short index optimization category, that is a variant of CRH and
   termed as CRH-20.

   This document continue to introduce another Routing Header based on
   common prefix category, as a variant of RPL SRH and termed as DetNet
   SRH.  DetNet SRH inherits the idea of RPL SRH relying completely on
   the packet itself to provide encapsulation knowledge, which is
   beneficial in many scenarios.  DetNet SRH contains the decoupled
   topology instructions and deterministic forwarding resource
   indications.  Here, the decoupled means that the SIDs for topology
   instructions and resource indications for DetNet QoS are defined,
   signaled in control plane or forwarded in data plane, independently.
   Considering that there are many resource types and the huge amount of
   resource instances supported by each type, this document does not
   recommend distinguishing different resource instances by allocating
   different SIDs.  The target of DetNet SRH is low cost of
   encapasultion and less amount of SIDs.

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

2.  The Source Route Headers for DetNet (DetNet SRH)















Peng                      Expires 14 April 2025                 [Page 3]


Internet-Draft      Deterministic Source Route Header       October 2024


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |iES|nES| RT  |P|                   Common RI                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Segments j+2 ~ n                     ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MBZ               |CmprL|R|     Individual RI     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            SID j+1                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |nES|               MBZ                 |     Individual RI     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          SID j (128-bit)                      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             SID j-1                   |CmprL|R| Individual RI |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Segments i+2 ~ j-2                   ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             SID i+1                   |CmprL|R| Individual RI |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |nES|               MBZ                 |     Individual RI     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            SID i (128-bit)                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             SID i-1           |CmprL|R|     Individual RI     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Segments 2 ~ i-2                     ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             SID 1             |CmprL|R|     Individual RI     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Padding                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: DetNet SRH Format

   DetNet SRH contains the following fields:

   *  Next Header: Defined in [RFC8200].

   *  Hdr Ext Len: Defined in [RFC8200].

   *  Routing Type: TBA for DetNet SRH.






Peng                      Expires 14 April 2025                 [Page 4]


Internet-Draft      Deterministic Source Route Header       October 2024


   *  Segments Left: Represents how many units of 4-octets remain to be
      processed.  Typically, the length of each segment element
      (including topology instruction and resource indication) is 4
      octets.  However, segment elements with larger lengths (resulting
      in lower compression efficiency) may also exist in the DetNet SRH
      segment list as needed.

   *  Type-specific Data: Described in [RFC8200].

   In the DetNet SRH, the Type-specific data field contains topology
   instructions and forwarding resource indications.  In detailed:

   *  iES (initial Element Style): 2 bits for the strcuture style of the
      first segment element actually stored in the DetNet SRH segment
      list. 4 styles are defined as below:

      -  0: termed as style-0, the structure of the segment element is
         <SID(128), nES(2), MBZ(18), Individual RI(12)>, which occupies
         5 units.  For example, in Figure 1, the style of segment
         element i or j is style-0.

      -  1: termed as style-1, the structure of the segment element is
         <SID(16), CmprL(3), R(1), Individual RI(12)>, which occupies 1
         unit.  For example, in Figure 1, the styles of segment elements
         1 to i-1 are all style-1.

      -  2: termed as style-2, the structure of the segment element is
         <SID(20), CmprL(3), R(1), Individual RI(8)>, which occupies 1
         unit.  For example, in Figure 1, the styles of segment elements
         i+1 to j-1 are all style-2.

      -  3: termed as style-3, the structure of the segment element is
         <SID(32), MBZ(16), CmprL(3), R(1), Individual RI(12)>, which
         occupies 2 units.  For example, in Figure 1, the styles of
         segment elements j+1 to n are all style-3.

   *  nES (next Element Style): 2 bits for the strcuture style of the
      next segment element.  The header.nES field indicates the style of
      the next segment element of the active segment, while the style-0
      element.nES field indicates the style of the next segment element
      in the DetNet SRH segment list.

   *  RT (Resource Type): 3 bits for the forwarding resource types.  The
      following only defines the corresponding resource types for DetNet
      queueing mechanisms that need specify different resources per hop.






Peng                      Expires 14 April 2025                 [Page 5]


Internet-Draft      Deterministic Source Route Header       October 2024


      -  0: undefined.  In this case, Common RI field and Individual RI
         fields may also be 0 and ignored during forwarding procedure of
         the packet, or other values used for user defined purposes.

      -  1: Indicates that the forwarding resources is timeslot
         resources.  [I-D.peng-detnet-packet-timeslot-mechanism] defines
         the Timeslot Queueing and Forwarding (TQF) mechanism that can
         be used in IP/MPLS network.  Timeslot resources are defined as
         multiple equally time slots contained within a fixed length of
         periodic time (known as orchestration period).  Different nodes
         interoperate on the same orchestration period, but for the same
         orchestration period, different nodes may configure different
         timeslot lengths.  In this case, Common RI field contains
         orchestration period length (OPL) information, and Individual
         RI field contains the specific timeslot for the corresponding
         segment.

      -  2: Indicates that the forwarding resources is delay resources.
         [I-D.peng-detnet-deadline-based-forwarding] defines the
         Earliest Deadline First (EDF) mechanism that can be used in IP/
         MPLS network.  The network may provide multiple delay levels
         each ensuring a bounded latency according to the schedulability
         condition of EDF.  In this case, Common RI field contains the
         latency deviation (E) value which is dynamically changed per
         hop, and Individual RI field contains the planned residence
         time (D) for the corresponding segment.  All segments may have
         the same planned residence time (D) by evenly dividing the
         total residence time budget, but this is not mandatory.

      -  3: Indicates that the forwarding resources is damper resources.
         [ATS_Damper] or [I-D.eckert-detnet-glbf] defines the damper
         mechanism that can be used in IP/MPLS network.  It actually
         combines two sub-functions: the worst-case latency guarantee
         component (e.g., ATS) and the damper component.  In this case,
         Common RI field contains the damper delay (D) value which is
         dynamically changed per hop, and Individual RI field contains
         the worst-case latency (M) for the corresponding segment.  All
         segments may have the same worst-case latency (M), but this is
         not the often case because the admitted flow aggregation of
         each traffic class at different hop may be different.











Peng                      Expires 14 April 2025                 [Page 6]


Internet-Draft      Deterministic Source Route Header       October 2024


      -  4: Indicate that forwarding resources is network slice
         resources, also known as Network Resource Partition (NRP)
         resources.  [I-D.ietf-teas-ns-ip-mpls] defines a network
         slicing mechanism in IP/MPLS network.  The physical network may
         be partitioned into multiple slices dedicated to specific
         services or customers.  It is possible to directly reuse
         network slices to get DetNet QoS.  In this case, Common RI
         field contains the default NRP-ID, and Individual RI field
         contains the overrided NRP-ID when necessary.

      -  Other types may be defined in the future.

   *  P (Pad) flag: 1 bit to indicate whether there are padding field.
      If P flag is 0, there are no padding.  If P flag is 1, there are
      padding with 4 bytes.

   *  Common RI (Resource Indication): 24 bits for the common forwarding
      resource information that all segments shared.  The information
      contained in Common RI depends on RT.  Please see the above
      explanation of Resource Type field.

   *  SID (Segment Identifier): 16 bits (for style-1), or 20 bits (for
      style-2), or 32 bits (for style-3), or 128 bits (for style-0), for
      the topology instruction used to forward packets to specific
      outgoing interface.

   *  MBZ (Must Be Zero): used to match the length of segment element to
      a multiple of units.

   *  CmprL (Common Prefix Length): 3 bits for the indication of common
      prefix length that is shared by multiple segments.  This document
      recommend supporting only a few typical lengths, such as 4 to 10
      bytes.  This field is only included in style-1, 2, 3, since
      style-0 element contains the complete 128 bits address.  The
      compaction rule of the complete 128 bits address based on CmprL is
      defined as below:

      -  If CmprL is zero, the address is Common_Prefix::SID.  That is,
         the SID is placed in the least significant bits of the address.

      -  If CmprL is non zero, the common prefix length equals to CmprL
         + 3, and the address is Common_Prefix:SID::. That is, the SID
         is placed behind common prefix in the most significant bits of
         the address.







Peng                      Expires 14 April 2025                 [Page 7]


Internet-Draft      Deterministic Source Route Header       October 2024


   *  R (Revert) flag: 1 bit to indicate whether the style of the next
      segment element will revert back to style-0.  If R flag is 0, the
      next segment element's style remains unchanged from the current
      element's style, otherwise, it will revert back to style-0.

   *  Individual RI (Resource Indication): 8 bits (for style-2), or 12
      bits (for style-0, 1, 3), for the forwarding resource that is
      specific for the individual segment.  The information contained in
      Individual RI depends on RT.  Please see the above explanation of
      Resource Type field.

   *  Padding: 0 or 4 bytes to ensure 8-octet alignment.

   In DetNet SRH, each segment is constructed by one or more units of
   4-octets.  Segments are listed in reverse order.  So, the first
   segment in the DetNet SRH list represents the final interface in the
   path.  Because segments are listed in reverse order, the Segments
   Left field can be used as an index into the segment list.

   The first segment in the path can be omitted from the list.

3.  Processing Rules

3.1.  Processing on the Headend Node

   The headend node is responsible for encapsulating the DetNet SRH for
   the packet.  For a logical Segment List <S1, S2, ..., Sn>, set the
   topology instructions and resource information corresponding to each
   segment in DetNet SRH.  According to the compaction result of the
   logical Segment List, set iES, nES, RT, P and Common RI fields in the
   header, set CmprL and R fields for style-1, 2, 3 segment elements,
   and set nES field for style-0 elements.

   Typically, a single style, e.g., style-1, may be used, and all
   segment elements in the DetNet SRH segment list will be encapsulated
   using that style.  In this case, the R flag of all segment elements
   is set to 0, because there is no style switching.

   If there are multiple styles used, as shown in Figure 1, the R flag
   or nES field of each segment element will be set to indicate the
   style of the next segment element.  For example, the R flag of
   segment element i-1 is TRUE, indicating that the style of the next
   segment element will revert back to style-0; The nES field of segment
   element i is 2, indicating that the style of the next segment element
   will be switched to style-2; The nES of segment element j is 3,
   indicating that the style of the next segment element will be
   switched to style-3.




Peng                      Expires 14 April 2025                 [Page 8]


Internet-Draft      Deterministic Source Route Header       October 2024


   A single style is common in intra-domain scenarios, while multiple
   styles are usually occurs in inter-domain cases (in which case the
   common prefix, or the common prefix length, or the length of
   compressed SID used in each domain may be different).

   The header.iES field is set to the style of the first segment element
   that is actually placed in DetNet SRH segment list.  The first
   segment element may be the first logical segment S1, or may be the
   second logical segment S2 if S1 is not stored in DetNet SRH. iES will
   never be changed on the journey of the packet forwarding.

   The header.nES field is set to the style of the second logical
   segment S2.  If there is no S2 in the logical segment list, it must
   be set to style-0.

   In one implementation, the header.nES field may also be set based on
   the R flag or nES field of the first logical segment S1 (although S1
   itself may not be actually included in DetNet SRH).  Namely:

      If S1 is not style-0:

      -  If S1.R equals to 0, header.nES = S1.style;

      -  If S1.R equals to 1, header.nES = style-0;

      If S1 is style-0, header.nES = S1.nES;

   RT, Common RI, and Individual RI are set based on the type of
   resource that the packet wants to consume.  For example of timeslot
   based TE path, RT is set to 1 (timeslot resource type), Common RI is
   set to orchestration period length, and each Individual RI is set to
   the timeslot id that is reserved for the flow.

   If DetNet SRH segment list is aligned with 8 bytes, then the Padding
   field is empty, and the P flag is set to 0; Otherwise, the Padding
   field has 4 bytes, and the P flag is set to 1.

   For each non style-0 segment element, its ComprL field is set
   according to the above compaction rule.

   Copy the complete 128 bit IPv6 address related to the first logical
   segment S1 to the DA field of the IPv6 header.

   Calculate the number of units of the compressed segment list
   (excluding the first logical segment S1), and set the Segment Left
   field to that number.





Peng                      Expires 14 April 2025                 [Page 9]


Internet-Draft      Deterministic Source Route Header       October 2024


   In one implementation, the Segment Left field may also be set based
   on the style the first logical segment S1 (although S1 itself may not
   be actually included in DetNet SRH).  Namely:

      Calculate the number of units of the compressed segment list,
      e.g., m.

      If the style of S1 is style-0, then SL = m - 5;

      If the style of S1 is style-1,2, then SL = m - 1;

      If the style of S1 is style-3, then SL = m - 2;

   In order to further save the cost of DetNet SRH, because the
   destination IPv6 address corresponding to the first logical segment
   S1 has already been copied to the DA field of the IPv6 header, the
   headend node may exclude the first logical segment S1 from the DetNet
   SRH segment list.  Note that this attempting to reduce overhead may
   not make sense due to the need for 8-octet alignment.

   The headend must ensure that when forwarding packets to the first
   logical segment S1, it consume the forwarding resources associated
   with S1.  Especially for the resources provided by EDF or damper
   mechanisms, the common RI field is set when the packet leaves the
   queue.

3.2.  Processing on the Transit or Endpoint Node

   When a transit or endpoint node receives an IPv6 packet, if the DA in
   the IPv6 header matches the local IP address, and the Next Header
   field of the IPv6 header indicates that the next layer header is
   DetNet SRH, then continue to process DetNet SRH as below:



















Peng                      Expires 14 April 2025                [Page 10]


Internet-Draft      Deterministic Source Route Header       October 2024


    S01. When a DetNet SRH is processed {
    S02.   if (Segments Left == 0) {
    S03.      Stop processing the DetNet SRH, and proceed to process the
                next header in the packet, whose type is identified by
                the Next Header field in the routing header.
    S04.   }
    S05.   if (IPv6 Hop Limit <= 1) {
    S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit), interrupt
                packet processing, and discard the packet.
    S07.   }
    S08.   Decrement IPv6 Hop Limit by 1
    S09.   Decrement Segments Left by 1
    S10.   Read the the next segment from Segment List[Segments Left]
             (i.e., read 1 unit when SRH.nES is style-1,2, or read 2
             units and subtract Segment Left by 1 again when SRH.nES is
             style-3, or read 5 units and subtract Segment Left by 4
             again when SRH.nES is style-0).
    S11.   Update the DA field of the IPv6 header based on the next
             segment read (i.e., DA = common_prefix:SID:: or
             common_prefix::SID for next non style-0 segment, or DA =
             SID for next style-0 segment).
    S12.   Update SRH.nES based on the next segment read (i.e., for next
             non style-0 segment, if R flag is zero, SRH.nES remains
             unchanged, otherwise SRH.nES is changed to style-0; for
             next style-0 segment, SRH.nES = segment.nES.).
           }
    S13.   Submit the packet to the egress IPv6 FIB lookup for
             transmission to the new destination, and, consume the
             forwarding resource indicated by Common RI field and
             Individual RI field of the next segment read. Especially
             for the resources provided by EDF or damper mechanisms,
             the common RI field is set when the packet leaves the
             queue.
    S14. }

4.  Other Design Considerations

4.1.  Heterogeneous Segment List

   DetNet SRH can support a combination of various type of segments in a
   single Segment List to reduce encapsulation size.  This can be used
   in scenarios that an E2E Segment List may across multiple domains and
   each domain has different common prefix.  In this case, a style-0
   segment element may be inserted in the DetNet SRH Segment List, to
   provide new prefix information for the next domain.





Peng                      Expires 14 April 2025                [Page 11]


Internet-Draft      Deterministic Source Route Header       October 2024


4.2.  Packet Parsing by Offline Tool

   DetNet SRH is friendly to offline tool parsing of packet and does not
   rely on FIB states maintained on network nodes to provide
   encapsulation knowledge of the packet.  Following this principle is
   beneficial, otherwise, an asynchronous FIB state, that may be
   updated, deleted, or occasionally mismatched, may provide unexpected
   compaction length information of each segment field, and result in a
   failure to obtain the correct segment list.

   The length of the DetNet SRH segment list can be obtained based on
   Hdr Ext Len and P flag, to locate the first actually stored segment
   element.  Then, the iTS field indicate the style and number of units
   of the first segment element.  Using the R flag or nES of the first
   segment element, the style and number of units of the second segment
   element can be obtained, and so on.

4.3.  ICMP Error Processing

   The invoking packet in the ICMP error message may contain an DetNet
   SRH.  Since the destination address of a packet with an DetNet SRH
   changes as each segment is processed, it may not be the destination
   used by the socket or application that generated the invoking packet.

   For the source of an invoking packet to process the ICMP error
   message, the ultimate destination address of the IPv6 header may be
   required.  The following logic is used to determine the destination
   address for use by protocol-error handlers.

      Walk all extension headers of the invoking IPv6 packet to the
      routing extension header preceding the upper-layer header.

      -  If routing header is type DetNet SRH

         o  Walk to the last segment element which may be used as the
            destination address of the invoking packet.

4.4.  Upper-Layer Checksums

   [RFC8200] specifies that any transport or other upper-layer protocol
   that includes the addresses from the IP header in its checksum
   computation must be modified for use over IPv6, to include the
   128-bit IPv6 addresses.  If the IPv6 packet contains a Routing
   header, the Destination Address used in the pseudo-header is that of
   the final destination.  At the originating node, that address will be
   in the last element of the Routing header; at the recipient(s), that
   address will be in the Destination Address field of the IPv6 header.




Peng                      Expires 14 April 2025                [Page 12]


Internet-Draft      Deterministic Source Route Header       October 2024


   For DetNet SRH, at the originating node, the Destination Address
   field in the pseudo-header will be the last segment that is before
   compaction; At the recipient(s), that address will be naturally
   restored and placed in the Destination Address field of the IPv6
   header; And, at the midpoint, the final address can also be retrieved
   by parsing the DetNet SRH segment list.

5.  IANA Considerations

   This document request to register the following in the "Routing
   Types" subregistry within the "Internet Protocol Version 6 (IPv6)
   Parameters" registry:

       +==========+=============+===============+
       | Value    | Description |   Reference   |
       +==========+=============+===============+
       | TBA      | DetNet SRH  | this document |
       +----------+-------------+---------------+


6.  Security Considerations

   The DetNet SRH domain is treated as a trusted domain, and the nodes
   outside the DetNet SRH domain are not trusted.  This is enforced by
   two levels of access control lists:

      On the ingress of DetNet SRH domain, any packet entering the
      DetNet SRH domain and destined to an IPv6 address within the
      DetNet SRH domain, is dropped.

      On the transit or egress of DetNet SRH domain, any packet with a
      destination address within the DetNet SRH domain but the source
      address not within, is dropped.

   It will block the attacks documented in [RFC5095] from outside the
   DetNet SRH domain, including bypassing filtering devices, reaching
   otherwise-unreachable Internet systems, network topology discovery,
   bandwidth exhaustion, and defeating anycast.

   Additionally, domains deny traffic with spoofed addresses by
   implementing the recommendations in BCP 84 [RFC3704].

   [RFC6554] requires RPL routers to check for loops in the SRH and drop
   datagrams that contain such loops.  However, for the flexibility of
   Segment List programming for any scenario, DetNet SRH doesn't do this
   check, but relevant security mechanisms to avoid tampering with
   Segment List should be adopted, such as HMAC mechanism introduced in
   [RFC8754].



Peng                      Expires 14 April 2025                [Page 13]


Internet-Draft      Deterministic Source Route Header       October 2024


   The generation of ICMPv6 error messages may be used to attempt
   denial-of-service attacks by sending an error-causing DetNet SRH in
   back-to-back datagrams.  An implementation that correctly follows
   Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-
   limiting mechanism.

7.  Acknowledgements

   TBD

8.  References

8.1.  Normative References

   [I-D.eckert-detnet-glbf]
              Eckert, T. T., Clemm, A., Bryant, S., and S. Hommes,
              "Deterministic Networking (DetNet) Data Plane - guaranteed
              Latency Based Forwarding (gLBF) for bounded latency with
              low jitter and asynchronous forwarding in Deterministic
              Networks", Work in Progress, Internet-Draft, draft-eckert-
              detnet-glbf-03, 5 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-eckert-
              detnet-glbf-03>.

   [I-D.ietf-teas-ns-ip-mpls]
              Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli,
              D., Halpern, J. M., Peng, S., Chen, R., Liu, X.,
              Contreras, L. M., Rokui, R., and L. Jalil, "Realizing
              Network Slices in IP/MPLS Networks", Work in Progress,
              Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-ns-ip-mpls-04>.

   [I-D.peng-detnet-deadline-based-forwarding]
              Peng, S., Du, Z., Basu, K., cheng, Yang, D., and C. Liu,
              "Deadline Based Deterministic Forwarding", Work in
              Progress, Internet-Draft, draft-peng-detnet-deadline-
              based-forwarding-12, 8 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-peng-detnet-
              deadline-based-forwarding-12>.

   [I-D.peng-detnet-packet-timeslot-mechanism]
              Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., and G.
              Peng, "Timeslot Queueing and Forwarding Mechanism", Work
              in Progress, Internet-Draft, draft-peng-detnet-packet-
              timeslot-mechanism-09, 12 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-peng-detnet-
              packet-timeslot-mechanism-09>.



Peng                      Expires 14 April 2025                [Page 14]


Internet-Draft      Deterministic Source Route Header       October 2024


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,
              <https://www.rfc-editor.org/info/rfc5095>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/info/rfc6554>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

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

   [RFC9631]  Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L.
              Jalil, "The IPv6 Compact Routing Header (CRH)", RFC 9631,
              DOI 10.17487/RFC9631, August 2024,
              <https://www.rfc-editor.org/info/rfc9631>.

8.2.  Informative References





Peng                      Expires 14 April 2025                [Page 15]


Internet-Draft      Deterministic Source Route Header       October 2024


   [ATS_Damper]
              "Constant Delay Switching: Asynchronous Traffic Shaping
              with Jitter Control", 2022,
              <https://ieeexplore.ieee.org/document/9829777>.

   [I-D.ietf-spring-srv6-srh-compression]
              Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
              Clad, "Compressed SRv6 Segment List Encoding", Work in
              Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
              compression-18, 22 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-srh-compression-18>.

   [I-D.pb-6man-deterministic-crh]
              Peng, S. and R. Bonica, "Deterministic Routing Header",
              Work in Progress, Internet-Draft, draft-pb-6man-
              deterministic-crh-00, 29 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-pb-6man-
              deterministic-crh-00>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

Author's Address

   Shaofu Peng
   ZTE Corporation
   China
   Email: peng.shaofu@zte.com.cn




















Peng                      Expires 14 April 2025                [Page 16]