]> Echo Request/Reply for DetNet Capability Discovery Huawei
China zhangli344@huawei.com
Huawei
China hongyi.huang@huawei.com
Huawei
China zhoutianran@huawei.com
Routing Area detnet Working Group DetNet OAM Ping Echo request Echo reply 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.
Introduction 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. 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 and OAM for the DetNet IP data plane is described in . 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. 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.
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 when, and only when, they appear in all capitals, as shown here.
Terminology 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
DetNet Capability Discovery
DetNet Capability Discovery Operation 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.
DetNet Capability Discovery Header 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.
The Format of Mandatory Section of A BFD Control Packet
DetNet Capabilities Discovery Objects
DetNet Capability Object
DetNet Capability Object Format
DetNet Relay Node Identifier Object
DetNet Node Identifier Object (MPLS)
DetNet Node Identifier Object (MPLS) Format
DetNet Node Identifier Object (IPv4)
DetNet Node Identifier Object (IPv4) Format
DetNet Node Identifier Object (IPv6)
DetNet Node Identifier Object (IPv6) Format
DetNet service protection function objects
Service Protection Object
Service Protection Object Format
Replication Capability Object
Replication Capability Object Format
Elimination Capability Object
Elimination Capability Object Format
Ordering Capability Object
Ordering Capability Object Format
DetNet Service Flow Information Objects
DetNet Service Flow Identifier Object (MPLS)
DetNet Service Flow Identifier Object Format
Service Label Object
Service Label Object Format
DetNet Service Flow Identifier Object (IPv4)
DetNet Service Flow Identifier Object (IPv4) Object Format
IPv4 Flow Identifier Object
IPv4 Flow Identifier Object Format
DetNet Service Flow Identifier Object (IPv6)
DetNet Service Flow Identifier Object (IPv6) Object Format
IPv6 Flow Identifier Object
IPv6 Flow Identifier Object Format
IPv6 Flow Label Object
IPv6 Flow Label Object Format
IPSec-SPI Object
IPSec-SPI Object Format
DetNet Data Plane Considerations
MPLS Data Plane 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.
MPLS TLV Header Format
DetNet Capabilities Discovery Object (MPLS) Format
IP Data Plane TBD.
IANA Considerations NA.
Security Considerations The security considerations described in apply to the extensions defined in this document as well. This document does not raise new security issues.
References Normative References Deterministic Networking Architecture This document 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. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1. Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet) Ericsson CNRS IMT Atlantique Universidad Carlos III de Madrid Ericsson Ericsson Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane Ericsson Huawei Ericsson This document defines format and usage principles of the Deterministic Network (DetNet) service Associated Channel over a DetNet network with the MPLS data plane. The DetNet service Associated Channel can be used to carry test packets of active Operations, Administration, and Maintenance protocols that are used to detect DetNet failures and measure performance metrics. Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Ericsson Huawei Dell EMC This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Deterministic Networking (DetNet): OAM Functions for The Service Sub-Layer Ericsson Ericsson Ericsson Operation, Administration, and Maintenance (OAM) tools are essential for a deterministic network. The DetNet architecture [RFC8655] has defined two sub-layers: (1) DetNet service sub-layer and (2) DetNet forwarding sub-layer. OAM mechanisms exist for the DetNet forwarding sub-layer. Nonetheless, OAM for the service sub-layer might require new extensions to the existing OAM protocols. This draft presents an analysis of OAM procedures for the DetNet service sub-layer functions.
Acknowledgements