Deterministic Networking specific SID
draft-varga-spring-preof-sid-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Balazs Varga , Ferenc Fejes | ||
| Last updated | 2024-06-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-varga-spring-preof-sid-00
SPRING B. Varga, Ed.
Internet-Draft F. Fejes
Intended status: Standards Track Ericsson
Expires: 21 December 2024 19 June 2024
Deterministic Networking specific SID
draft-varga-spring-preof-sid-00
Abstract
Replication, Elimination and Ordering functions of the DetNet
Architecture require packet sequence information (i.e., sequence
number) to provide service protection by the DetNet service sub-
layer. This document extends SRv6 Network Programming [RFC8986] with
new SR endpoint and transit behaviors to be performed on packets of
DetNet flows to support the specific service protection treatment.
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 December 2024.
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.
Varga & Fejes Expires 21 December 2024 [Page 1]
Internet-Draft PREOF SID June 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. DetNet-specific SID . . . . . . . . . . . . . . . . . . . . . 3
4. SRv6 endpoint behaviors . . . . . . . . . . . . . . . . . . . 4
4.1. End.PREOF: Endpoint with PREOF . . . . . . . . . . . . . 5
5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 5
5.1. H.Encaps.PREOF: SR Headend with PREOF . . . . . . . . . . 5
5.2. H.Encaps.PREOF.Red: H.Encaps.PREOF with Reduced
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
5.3. H.Encaps.PREOF.L2: H.Encaps.PREOF Applied to Received L2
Frames . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. H.Encaps.PREOF.L2.Red: H.Encaps.PREOF.L2 with Reduced
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7
6. DetNet-specific SID related counters . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
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).
Varga & Fejes Expires 21 December 2024 [Page 2]
Internet-Draft PREOF SID June 2024
2. Terminology
2.1. Terms Used in This Document
This document uses the terminology established in the DetNet
architecture [RFC8655] and in the SRv6 Network Programming [RFC8986].
The reader is assumed to be familiar with that document and its
terminology.
2.2. Abbreviations
The following abbreviations are used in this document:
ARG Arguments.
DetNet Deterministic Networking.
FUNCT Function.
LOC Locator.
PEF Packet Elimination Function.
POF Packet Ordering Function.
PREOF Packet Replication, Elimination and Ordering Functions.
PRF Packet Replication Function.
SeqNum Sequence Number.
2.3. 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.
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.
Varga & Fejes Expires 21 December 2024 [Page 3]
Internet-Draft PREOF SID June 2024
* 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!
The following packet processing rules are defined as a new set of
SRv6 SID behaviors regarding the DetNet-specific SID: (i) End.PREOF,
(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
Varga & Fejes Expires 21 December 2024 [Page 4]
Internet-Draft PREOF SID June 2024
4.1. End.PREOF: Endpoint with PREOF
When a node "N" receives a packet whose IPv6 DA is "S" and "S" is a
local End.PREOF SID, "N" does the following:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Send an ICMP Parameter Problem message to the Source Address
Code TBD-SRH (SR Upper-layer Header Error),
Pointer set to the offset of the upper-layer header,
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
5.1. H.Encaps.PREOF: SR Headend with PREOF
When a node "N" receives a packet P=(A, B) identified as a DetNet
Flow. B is neither a local address nor SID of "N". It executes the
DetNet Flow related PREOF functions, resulting in one or more member
flow (P1=(A, B), P2=(A, B), ...) with related parameters ([Flow-ID1,
SeqNum], [Flow-ID2, SeqNum], ...).
Node "N" is configured with an IPv6 address "T" (e.g., assigned to
its loopback). "N" steers the egress packet P1 into an SRv6 Policy
with a Source Address T and a segment list SP1=<S11, S12, S13>, where
S13 is a DetNet-specific SID (LOC+FUNCT) with 0 as ARG.
The H.Encaps.PREOF encapsulation behavior is defined as follows (SA:
source address, DA: destination address):
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
After the H.Encaps.PREOF behavior, P1, and P2 respectively look like:
Varga & Fejes Expires 21 December 2024 [Page 5]
Internet-Draft PREOF SID June 2024
* (T, S11) (S13, S12, S11; SL=2) (A, B), note: S13.ARG=Flow-ID1,
SeqNum
* (T, S21) (S23, S22, S21; SL=2) (A, B), note: S23.ARG=Flow-ID2,
SeqNum
The member flow packet is encapsulated unmodified (with the exception
of the IPv4 TTL or IPv6 Hop Limit that is decremented).
The push of the SRH MAY be omitted when the SRv6 Policy only contains
one segment and there is no need to use any flag, tag, or TLV. In
such cases the outer destination address is the DetNet-specific SID.
5.2. H.Encaps.PREOF.Red: H.Encaps.PREOF with Reduced Encapsulation
The H.Encaps.PREOF.Red behavior is an optimization of the
H.Encaps.PREOF behavior.
H.Encaps.PREOF.Red reduces the length of the SRH by excluding the
first SID in the SRH of the pushed IPv6 header. The first SID is
only placed in the Destination Address field of the pushed IPv6
header.
After the H.Encaps.PREOF.Red behavior, P1, and P2 respectively look
like:
* (T, S11) (S13, S12; SL=2) (A, B), note: S13.ARG=Flow-ID1, SeqNum
* (T, S21) (S23, S22; SL=2) (A, B), note: S23.ARG=Flow-ID2, SeqNum
5.3. H.Encaps.PREOF.L2: H.Encaps.PREOF Applied to Received L2 Frames
The H.Encaps.PREOF.L2 behavior encapsulates a received Ethernet frame
and its attached VLAN header, if present, in an IPv6 packet with an
SRH. The Ethernet frame becomes the payload of the new IPv6 packet.
The H.Encaps.PREOF.L2 encapsulation behavior is similar to
H.Encaps.PREOF but sets an Ethernet specific outer Next Header and
lacks the TTL/Hop Limit related action. H.Encaps.PREOF.L2 is defined
as follows:
Varga & Fejes Expires 21 December 2024 [Page 6]
Internet-Draft PREOF SID June 2024
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
The Next Header field of the SRH MUST be set to 143.
The push of the SRH MAY be omitted when the SRv6 Policy only contains
one segment and there is no need to use any flag, tag, or TLV.
The encapsulating node MUST remove the preamble (if any) and frame
check sequence (FCS) from the Ethernet frame upon encapsulation, and
the decapsulating node MUST regenerate, as required, the preamble and
FCS before forwarding the Ethernet frame.
5.4. H.Encaps.PREOF.L2.Red: H.Encaps.PREOF.L2 with Reduced
Encapsulation
The H.Encaps.PREOF.L2.Red behavior is an optimization of the
H.Encaps.PREOF.L2 behavior.
H.Encaps.PREOF.L2.Red reduces the length of the SRH by excluding the
first SID in the SRH of the pushed IPv6 header. The first SID is
only placed in the Destination Address field of the pushed IPv6
header.
The push of the SRH MAY be omitted when the SRv6 Policy only contains
one segment and there is no need to use any flag, tag, or TLV.
6. DetNet-specific SID related counters
PREOF implementation may provide counters per DetNet flow. However,
in order to be inline with the intention of RFC8986 (section 6.
Counters), its recommendation may apply on the DetNet-specific SID
and the above described set of SR Behaviors. It means, a node
supporting DetNet-specific SID should implement a pair of traffic
counters (one for packets and one for bytes) per local SID entry, for
traffic that matched that SID and was processed successfully (i.e.,
packets that generate ICMP Error Messages or are dropped are not
counted). The retrieval of these counters from MIB, NETCONF/YANG, or
any other data structure is outside the scope of this document.
Varga & Fejes Expires 21 December 2024 [Page 7]
Internet-Draft PREOF SID June 2024
7. Security Considerations
DetNet PREOF related security considerations are described in section
3.3 of [RFC9055]. There are no additional related security
considerations originating from this document.
SRv6 Network Programming related security considerations are
described in section 9 of [RFC8986]. There are no additional related
security considerations originating from this document.
8. IANA Considerations
This document makes no IANA requests.
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.
10. Normative References
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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>.
[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>.
Varga & Fejes Expires 21 December 2024 [Page 8]
Internet-Draft PREOF SID June 2024
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>.
Authors' Addresses
Balazs Varga (editor)
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: balazs.a.varga@ericsson.com
Ferenc Fejes
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: ferenc.fejes@ericsson.com
Varga & Fejes Expires 21 December 2024 [Page 9]