Internet-Draft | Echo Request/Reply for DetNet Capability | October 2024 |
Zhang, et al. | Expires 13 April 2025 | [Page] |
This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions.¶
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 13 April 2025.¶
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.¶
[RFC8655] provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Currently DetNet operates on IP and MPLS data plane.¶
DetNet functionality is divided into two sub-layers. The DetNet service sub-layer provides DetNet service protection with functionalities and operation of PREOF, a collective name for Packet Replication, Elimination, and Ordering Functions. The DetNet forwarding sub-layer provides resource allocation for DetNet flows over paths provided by the underlying network.¶
[I-D.ietf-detnet-oam-framework] details the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. OAM for the DetNet MPLS data plane is described in [I-D.ietf-detnet-mpls-oam] and OAM for the DetNet IP data plane is described in [I-D.ietf-detnet-ip-oam].¶
[I-D.ietf-detnet-oam-framework] described the DetNet service sub-layer oam requirements of discovering DetNet relay nodes , collecting DetNet service sub-layer specific (e.g., configuration/operation/status) information from DetNet relay nodes, as well as discovering the locations of PREOF functions.¶
These requirements, could be satisfied using alternative technologies like NETCONF/YANG, IGP flooding or ping/traceroute. [I-D.varga-detnet-service-sub-layer-oam] introduced a ping/traceroute method, "DetNet Ping", and mentions that it could be used for discovering DetNet capabilities of DetNet relay nodes.¶
This document introduced extensions to DetNet Ping (echo request/reply) used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer.¶
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.¶
The abbreviations used in this document are:¶
DetNet: Deterministic Networking¶
OAM: Operation, Administration, and Maintenance¶
PRF: Packet Replication Function¶
PEF: Packet Elimination Function¶
POF: Packet Ordering Function¶
PREOF: Packet Replication, Elimination and Ordering Function¶
Once the DetNet PING initiator node is triggered to discover the enabled DetNet capabilities of each DetNet relay node, the initiator node will send DetNet echo requests that include the DetNet Capabilities Discovery Header.
First, with TTL equal to 1 to reach the closest node, which may be an DetNet relay node or not. Then with TTL equal to 2 to reach the second nearest node, which also may be an DetNet relay node or not.
And further, increasing by 1 the TTL every time the initiator node sends a new echo request. As a result, the echo requests sent by the initiator node will reach all nodes one by one along the transport path of DetNet service flow.
Alternatively, if the initiator node knows precisely all the DetNet relay nodes beforehand, once the initiator node is triggered to discover the enabled DetNet capabilities, it can send an echo request to each DetNet relay node directly, without TTL expiration.¶
For echo DetNet request/reply message used for DetNet capability discovery, DetNet capabilities information are delivered by several kinds of DetNet Capabilities Discovery Objects. This document introduces an abstract header which has the corresponding format depending on the type of DetNet data plane. The format of DetNet Capabilities Discovery Object is shown as below.¶
DetNet Capabilities Discovery Header: abstract header of DetNet Capabilities Discovery Object, with varied length and format depending on the type of DetNet data plane. DetNet Capabilities Discovery Data: detailed information of DetNet Capabilities Discovery Object, with fixed length and format depending on the type of Detnet capability.¶
Flags (4 bytes): DetNet Capability Flags * S: Service sub-layer capability * F: Forwarding sub-layer capability * I: Incoming flow configuration * O: Outgoing flow configuration¶
Node ID (20 bits): The value of the Node ID field identifies the DetNet node that originated the packet. It is same as defined in {{I-D.ietf-detnet-mpls-oam}}. OP (3 bits): Service operation on the node. 0x00: No operation for DetNet service sub-layer 0x01: Initiation for DetNet service sub-layer encapsulation 0x02: Termination for DetNet service sub-layer encapsulation 0x03: Relay(Swap) operation for DetNet service sub-layer¶
IPv4 address(4 bytes): An IPv4 address. This address is treated as a prefix based on the prefix length value. Prefix length(1 bytes): Length in bits of the IPv4 prefix. OP (3 bits): Service operation on the node. 0x00: No operation for DetNet service sub-layer 0x01: Initiation for DetNet service sub-layer encapsulation 0x02: Termination for DetNet service sub-layer encapsulation 0x03: Relay(Swap) operation for DetNet service sub-layer¶
IPv6 address: An IPv6 address. This address is treated as a prefix based on the prefix length value. Prefix length: Length in bits of the IPv6 prefix. OP (3 bits): Service operation on the node. 0x00: No operation for DetNet service sub-layer 0x01: Initiation for DetNet service sub-layer encapsulation 0x02: Termination for DetNet service sub-layer encapsulation 0x03: Relay(Swap) operation for DetNet service sub-layer¶
flags (4 bytes): service protection flags. * SL (2 bits): Sequence number length. 0b00: no sequence number 0b01: sequence number length of 16 bits 0b10: sequence number length of 28 bits¶
Flags (4 bytes): unused.¶
Flags (4 bytes): unused.¶
Flags (4 bytes): unused.¶
Flags (4 bytes): * I: Incoming flow * O: Outgoing flow * P: platform-label-space¶
Service Label (4 bytes): S-Label, DetNet Service identifier with MPLS data plane.¶
Flags (4 bytes): * I: Incoming flow * O: Outgoing flow * A: IPv4 flow identifier, including Source Address, Destination Address, Source Port, Destination Port, Protocol and Dscp * S: IPSec-spi¶
Source Address (4 bytes): IPv4 source address of the packet. Destination Address (4 bytes): IPv4 destination address of the packet. Source Port (2 bytes): Source port of the packet. Destination Port (2 bytes): Destination port of the packet. Protocol (1 byte): Protocol of the packet. Dscp (1 byte): Differentiated Services Code Point.¶
Flags (4 bytes): * I: Incoming flow * O: Outgoing flow * A: IPv6 flow identifier, including Source Address, Destination Address, Source Port, Destination Port, Protocol and Dscp * S: IPSec-spi * L: IPv6 flow label¶
Source Address (16 bytes): IPv6 source address of the packet. Destination Address (16 bytes): IPv6 destination address of the packet. Source Port (2 bytes): Source port of the packet. Destination Port (2 bytes): Destination port of the packet. Protocol (1 byte): Protocol of the packet. Dscp (1 byte): Differentiated Services Code Point.¶
IPv6 Flow Label (4 bytes): The flow label value of the header. IPv6 only.¶
IPSec-SPI (4 bytes): IPsec Security Parameters Index¶
DetNet echo request/reply messages in MPLS data plane, could encapsulate DetNet Capabilities Discovery Objects with typical TLV header format in place of the "DetNet Capabilities Discovery Header", as defined in {#detnet-cap-disc-obj}. The values of tlv types had not been defined yet.¶
Type (2 bytes): Tlv type Length (2 bytes): Tlv Length¶
TBD.¶
The security considerations described in [RFC8655] apply to the extensions defined in this document as well. This document does not raise new security issues.¶