Deterministic Networking (DetNet) YANG Model Huawei Technologies
gengxuesong@huawei.com
ETRI
dbduscjf@etri.re.kr
LabN Consulting, L.L.C.
dfedyk@labn.net
Equinix
reshad@yahoo.com
China Mobile
lizhenqiang@chinamobile.com
This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data of DetNet Flows. The model allows for provisioning of end-to-end DetNet service on devices along the path without dependency on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA).
Introduction DetNet (Deterministic Networking) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end delivery latency. A description of the general background and concepts of DetNet can be found in . This document defines a YANG model for DetNet based on YANG data types and modeling language defined in and . DetNet service, which is designed for describing the characteristics of services being provided for application flows over a network, and DetNet configuration, which is designed for DetNet flow path establishment, flow status reporting, and DetNet functions configuration in order to achieve end-to-end bounded latency and zero congestion loss, are both included in this document. This Yang model is scoped to the description of the aggregation/disaggregation and data plane capabilities of the DetNet data planes defined in the DetNet Architecture and DetNet Framework . DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN).
Abbreviations The following abbreviations are used in this document:
PEF
Packet Elimination Function
PRF
Packet Replication Function
PEOF
Packet Elimination and Ordering Functions
PERF
Packet Elimination and Replication Functions
PREOF
Packet Replication, Elimination and Ordering Functions
MPLS
Multiprotocol Label Switching
Terminology This document uses the terminology defined in . The terms A-label, S-label, and F-label are used in this document as defined in .
DetNet YANG Module The DetNet YANG module includes DetNet App-flow, DetNet Service Sub-layer, and DetNet Forwarding Sub-layer configuration and operational objects. The corresponding attributes used in different sub-layers are defined in , , respectively. Layers of the objects typically occur in the different data instances forming the node types defined in . illustrates the relationship between data instance node types and the included layers. Node types are logical roles per DetNet service: a device along one DetNet service can be of one node type, while another service may use the same device with a different node type. This model is a controller based model because a controller or operator configures all the devices to form a service.
DetNet Layers and Node Types
All of the layers have ingress/incoming and egress/outgoing operations, but any instance may be configured as only unidirectional. Ingress refers to any DetNet layer where a DetNet context is applied. Ingress allows functions such as switching, aggregation and encapsulation. Likewise, egress refers to any DetNet layer where a DetNet context is removed. Egress allows functions such as switching, disaggregation and decapsulation. This means that each unidirectional flow identifier configuration is programmed starting at the ingress and flow status is reported at ingress on each end. In the MPLS cases once encapsulated, the IP 6-tuple, see , parameters may not be required to be programmed again. In the IP case, without encapsulation, various IP flow id parameters must be configured along the flow path. In the YANG model the terms source and destination are used as flow identifiers whereas ingress and egress refer to a DetNet application direction from the application edge. Ingress is to the DetNet application and egress is from the application. The terms incoming and outgoing generally represent the flow direction towards the remote application. Outgoing is viewed as going down the stack from Application to Service sub-layer to Forwarding sub-layer and incoming is the reverse. Although, in examples where there is aggregation and disaggregation outgoing relates to the aggregating output and incoming relates to the disaggregating flows. At the egress point, forwarding information is determined by the App-flow type with all DetNet-related headers removed. The forwarding information can specify an output port, or set a next-hop-address in case of IP, or set an MPLS label in case of MPLS.
DetNet Application Flow YANG Attributes DetNet application flow is responsible for mapping between application flows and DetNet flows at the edge node (egress/ingress node). The application flows can be either layer 2 or layer 3 flows. To map a flow at the User Network Interface (UNI), the corresponding attributes are defined in .
DetNet Service Sub-layer YANG Attributes DetNet service functions, e.g., DetNet tunnel initialization/termination and service protection, are provided in the DetNet service sub-layer. To support these functions, the following service attributes need to be configured:
  • DetNet flow identification
  • Service function indication, indicates which service function will be invoked at a DetNet edge, relay node or end station. (DetNet tunnel initialization or termination are default functions in the DetNet service layer, so there is no need for explicit indication). The corresponding arguments for service functions also need to be defined.
DetNet Forwarding Sub-layer YANG Attributes As defined in , DetNet forwarding sub-layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network. Explicit route is another mechanism that is used by DetNet to avoid temporary interruptions caused by the convergence of routing or bridging protocols, and it is also implemented at the DetNet forwarding sub-layer. To support congestion protection and explicit route, the following transport layer related attributes are necessary:
  • Flow Specification and Traffic Requirements, as described in the information model in . These may be used for resource reservation, flow shaping, filtering and policing by a control plane or other network management and control mechanisms.
  • Since this model programs the data plane existing explicit route mechanisms can be reused. If a static MPLS tunnel is used as the transport tunnel, the configuration needs to be at every transit node along the path. For an IP-based path, the static configuration is similar to the static MPLS case. This document provides data-plane configuration of IP addresses or MPLS labels but it does not provide control plane mapping or other aspects.
DetNet Flow Aggregation DetNet provides the capability of flow aggregation to improve scalability of DetNet data, management and control planes. Aggregated flows can be viewed by some DetNet nodes as individual DetNet flows. When aggregating DetNet flows, the flows should be compatible: if bandwidth reservations are used, the reservation should be a reasonable representation of the individual reservations; if maximum delay bounds are used, the system should ensure that the aggregate does not exceed the delay bounds of the individual flows. The DetNet YANG model defined in this document supports DetNet flow aggregation with the following functions:
  • Aggregated flow encapsulation/decapsulation/identification
  • Mapping individual DetNet flows to an aggregated flow
  • Changing traffic specification parameters for aggregated flows
The following cases of DetNet aggregation are supported:
  • Ingress node aggregates App flows into a service sub-layer of DetNet flow
  • In ingress node, the service sub-layers of DetNet flows are aggregated into a forwarding sub-layer
  • In ingress node, the service sub-layers of DetNet flows are aggregated into a service sub-layer of an aggregated DetNet flow
  • Relay node aggregates the forwarding sub-layers DetNet flows into a forwarding sub-layer
  • Relay node aggregates the service sub-layers of DetNet flows into a forwarding sub-layer
  • Relay node aggregates the service sub-layers of DetNet flows into a service sub-layer of Aggregated DetNet flow
  • Relay node aggregates the forwarding sub-layers of DetNet flow into a service sub-layer of Aggregated DetNet flow
  • Transit node aggregates the forwarding sub-layers of DetNet flows into a forwarding sub-layer
Traffic requirements and traffic specification may be tracked for individual or aggregate flows but reserving resources and tracking the services in the aggregated flow is out of scope.
DetNet YANG Structure Considerations The picture shows the general structure of the DetNet YANG Model: There are three layer types in the DetNet YANG Model: App-flow data layer, service sub-layer and forwarding sub-layer. Additionally, the Traffic parameters are captured in a Traffic profile that can be referenced by any of the layers. Below is a summary YANG tree showing the major items. A complete YANG tree is in section . A traffic profile can be created for an application, a service sub-layer or a forwarding sub-layer. A single profile may be shared by multiple applications/sub-layer. Each profile indicates the members currently using that profile. Depending on which DetNet layers and functions are required, some or all of the components may be configured. Examples are shown in .
DetNet Configuration YANG Structures The following is a partial tree representation of the YANG as defined in . This corresponds to the structure layout in the previous section.
DetNet Configuration YANG Model This YANG model imports typedefs from , , , , and . This YANG model also has the following references to RFCs that are not in the document text body , , , , , , and . WG List: Editor: Xuesong Geng Editor: Yeoncheol Ryoo Editor: Don Fedyk ; Editor: Reshad Rahman Editor: Zhenqiang Li "; description "This YANG module describes the parameters needed for DetNet flow configuration and flow status reporting. This YANG module conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove // this note // replace '2024-02-21' with the module publication date // the format is (year-month-day) revision 2024-02-21 { description "Initial revision"; reference "RFC XXXX: Deterministic Networking (DetNet) YANG Model"; } identity app-status { description "Base identity from which all application-status status types are derived."; reference "RFC 9016 Section 5.8"; } identity none { base app-status; description "This application has no status. This identity is expected when the configuration is incomplete."; reference "RFC 9016 Section 5.8"; } identity ready { base app-status; description "Application ingress/egress ready."; reference "RFC 9016 Section 5.8"; } identity failed { base app-status; description "Application ingres/egress failed."; reference "RFC 9016 Section 5.8"; } identity out-of-service { base app-status; description "Application administratively blocked."; reference "RFC 9016 Section 5.8"; } identity partial-failed { base app-status; description "This is an application with one or more Egress ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready."; reference "RFC 9016 Section 5.8"; } typedef app-flow-ref { type leafref { path "/dnet:detnet" + "/dnet:app-flows" + "/dnet:app-flow" + "/dnet:name"; } description "This is an application Reference."; } typedef service-sub-layer-ref { type leafref { path "/dnet:detnet" + "/dnet:service" + "/dnet:sub-layer" + "/dnet:name"; } description "This is a service sub-layer Reference."; } typedef forwarding-sub-layer-ref { type leafref { path "/dnet:detnet" + "/dnet:forwarding" + "/dnet:sub-layer" + "/dnet:name"; } description "This is a forwarding sub-layer Reference."; } typedef traffic-profile-ref { type leafref { path "/dnet:detnet" + "/dnet:traffic-profile" + "/dnet:name"; } description "This is a traffic Profile Reference."; } typedef ipsec-spi { type uint32 { range "1..max"; } description "IPsec Security Parameters Index. A 32 bit value where some values are reserved."; reference "IETF RFC 4303 Encapsulating Security Payload (ESP)."; } typedef operation { type enumeration { enum initiation { description "This is an initiating service sub-layer encapsulation."; } enum termination { description "Operation for DetNet service sub-layer decapsulation."; } enum relay { description "Operation for DetNet service sub-layer swap."; } enum non-detnet { description "No operation for DetNet service sub-layer."; } } description "Operation type identifies the behavior for this service sub-layer. Operations are described as unidirectional but a service sub-layer may combine operation types."; } typedef mpls-fwd-operation { type enumeration { enum impose-and-forward { description "This operation imposes outgoing label(s) and forwards to next-hop."; reference " A YANG Data Model for MPLS Base RFC 8960."; } enum pop-and-forward { description "This operation pops the incoming label and forwards to the next-hop."; reference " A YANG Data Model for MPLS Base RFC 8960."; } enum pop-impose-and-forward { description "This operation pops the incoming label, imposes one or more outgoing label(s) and forwards to the next-hop."; reference " A YANG Data Model for MPLS Base RFC 8960."; } enum swap-and-forward { description "This operation swaps an incoming label, with an outgoing label and forwards to the next-hop."; reference " A YANG Data Model for MPLS Base RFC 8960."; } enum forward { description "This operation forwards to next-hop."; } enum pop-and-lookup { description "This operation pops an incoming label and performs a lookup."; } } description "MPLS operations types. This is an enum modeled after the MPLS enum. The enums are the same as A YANG Data Model for MPLS Base. RFC 8960."; } typedef service-protection { type enumeration { enum none { description "No service protection provided."; } enum replication { description "A Packet Replication Function (PRF) replicates DetNet flow packets and forwards them to one or more next hops in the DetNet domain. The number of packet copies sent to each next hop is a DetNet flow-specific parameter at the node doing the replication. PRF can be implemented by an edge node, a relay node, or an end system."; } enum elimination { description "A Packet Elimination Function (PEF) eliminates duplicate copies of packets to prevent excess packets flooding the network or duplicate packets being sent out of the DetNet domain. PEF can be implemented by an edge node, a relay node, or an end system."; } enum ordering { description "A Packet Ordering Function (POF) re-orders packets within a DetNet flow that are received out of order. This function can be implemented by an edge node, a relay node, or an end system."; } enum elimination-ordering { description "A combination of PEF and POF that can be implemented by an edge node, a relay node, or an end system."; } enum elimination-replication { description "A combination of PEF and PRF that can be implemented by an edge node, a relay node, or an end system."; } enum elimination-ordering-replication { description "A combination of PEF, POF and PRF that can be implemented by an edge node, a relay node, or an end system."; } } description "This typedef describes the service protection enumeration values."; } typedef sequence-number-generation { type enumeration { enum copy-from-app-flow { description "Copy-from-app-flow is used to extend and use the sequence number used in App-flow. This function is required when encapsulating App-flows that have been replicated and received through multiple ingress nodes into a member flow, and then eliminate it at the relay node."; } enum generate-by-detnet-flow { description "Generate-by-detnet-flow is used to create a new sequence number for a DetNet flow at the ingress node. Care must be taken when using this option to ensure there is only one source for generating sequence numbers."; } } description "This typedef defines how to generate sequence numbers to be used in DetNet encapsulation."; } typedef sequence-number-field { type enumeration { enum zero-sn { description "No DetNet sequence number field is used."; } enum short-sn { value 16; description "A 16-bit DetNet sequence number field is used."; } enum long-sn { value 28; description "A 28-bit DetNet sequence number field is used."; } } description "This enumeration configures the sequence number behavior."; } grouping ip-header { description "This grouping captures the IPv4/IPv6 packet header information. It is modeled after existing fields."; leaf src-ip-address { type inet:ip-address-no-zone; description "The source IP address in the header."; reference "RFC 6991 Common YANG Data Types"; } leaf dest-ip-address { type inet:ip-address-no-zone; description "The destination IP address in the header."; reference "RFC 6991 Common YANG Data Types"; } leaf protocol-next-header { type uint8; description "In IPv4 refers to the protocol of the payload. In IPv6, this field is known as 'next-header', and identifies the type of header immediately following the IPv6 header."; reference "RFC 791: Internet Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; } leaf dscp { type inet:dscp; description "The traffic class value in the header."; reference "RFC 6991 Common YANG Data Types"; } leaf flow-label { type inet:ipv6-flow-label; description "The flow label value of the header. IPv6 only."; reference "RFC 6991 Common YANG Data Types"; } leaf source-port { type inet:port-number; description "The source port number."; reference "RFC 6991 Common YANG Data Types"; } leaf destination-port { type inet:port-number; description "The destination port number."; reference "RFC 6991 Common YANG Data Types"; } } grouping l2-header { description "The Ethernet or TSN packet header information."; leaf source-mac-address { type yang:mac-address; description "The source MAC address value of the Ethernet header."; } leaf destination-mac-address { type yang:mac-address; description "The destination MAC address value of the Ethernet header."; } leaf ethertype { type ethertypes:ethertype; description "The Ethernet packet type value of the Ethernet header."; } leaf vlan-id { type dot1q-types:vlanid; description "The VLAN value of the Ethernet header."; reference "IEEE 802.1Q-2022."; } leaf pcp { type dot1q-types:priority-type; description "The priority value of the Ethernet header."; reference "IEEE 802.1Q-2022."; } } grouping destination-ip-port-id { description "The TCP/UDP port destination identification information."; container destination-port { uses packet-fields:port-range-or-operator; description "This grouping captures the destination port fields."; } } grouping source-ip-port-id { description "The TCP/UDP port source identification information."; container source-port { uses packet-fields:port-range-or-operator; description "This grouping captures the source port fields."; } } grouping ip-flow-id { description "The IPv4/IPv6 packet header identification information."; leaf src-ip-prefix { type inet:ip-prefix; description "The source IP prefix."; reference "RFC 6991 Common YANG Data Types"; } leaf dest-ip-prefix { type inet:ip-prefix; description "The destination IP prefix."; reference "RFC 6991 Common YANG Data Types"; } leaf protocol-next-header { type uint8; description "Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header', and if extension headers are present, the protocol is present in the 'upper-layer' header."; reference "RFC 791: Internet Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; } leaf dscp { type inet:dscp; description "The traffic class value in the header."; reference "RFC 6991 Common YANG Data Types"; } leaf flow-label { type inet:ipv6-flow-label; description "The flow label value of the header."; reference "RFC 6991 Common YANG Data Types"; } uses source-ip-port-id; uses destination-ip-port-id; leaf ipsec-spi { type ipsec-spi; description "IPsec Security Parameters Index of the Security Association."; reference "IETF RFC 4303 Encapsulating Security Payload (ESP)."; } } grouping mpls-flow-id { description "The MPLS packet header identification information."; choice label-space { description "Designates the label space being used."; case context-label-space { uses rt-types:mpls-label-stack; } case platform-label-space { leaf label { type rt-types:mpls-label; description "This is the case for Platform label space."; } } } } grouping data-flow-spec { description "app-flow identification."; choice data-flow-type { description "The Application flow type choices."; container tsn-app-flow { uses l2-header; description "The L2 header for application."; } container ip-app-flow { uses ip-flow-id; description "The IP header for application."; } container mpls-app-flow { uses mpls-flow-id; description "The MPLS header for application."; } } } grouping detnet-flow-spec { description "detnet-flow identification."; choice detnet-flow-type { description "The DetNet flow type choices."; case ip-detnet-flow { uses ip-flow-id; } case mpls-detnet-flow { uses mpls-flow-id; } } } grouping app-flows-group { description "Incoming or outgoing app-flow reference group."; leaf-list flow { type app-flow-ref; description "List of ingress or egress app-flows."; } } grouping service-sub-layer-group { description "Incoming or outgoing service sub-layer reference group."; leaf-list sub-layer { type service-sub-layer-ref; description "List of incoming or outgoing service sub-layers that have to aggregate or disaggregate."; } } grouping forwarding-sub-layer-group { description "Incoming or outgoing forwarding sub-layer reference group."; leaf-list sub-layer { type forwarding-sub-layer-ref; description "List of incoming or outgoing forwarding sub-layers that have to aggregate or disaggregate."; } } grouping detnet-header { description "DetNet header info for DetNet encapsulation or swap."; choice header-type { description "The choice of DetNet header type."; case mpls { description "MPLS label stack for DetNet MPLS encapsulation or forwarding."; uses rt-types:mpls-label-stack; } case ip { description "IPv4/IPv6 packet header for DetNet IP encapsulation."; uses ip-header; } } } grouping detnet-app-next-hop-content { description "Generic parameters of DetNet next hops. This follows the principles for next hops in RFC 8349"; choice next-hop-options { description "Options for next hops. It is expected that further cases will be added through augments from other modules, e.g., for recursive next hops."; case simple-next-hop { description "This case represents a simple next hop consisting of the next-hop address and/or outgoing interface."; leaf outgoing-interface { type if:interface-ref; description "The outgoing interface, when matching all flows to the interface."; } choice flow-type { description "The flow type choices."; case ip { leaf next-hop-address { type inet:ip-address; description "The IP next hop case."; } } case mpls { uses rt-types:mpls-label-stack; description "The MPLS label stack next hop case."; } } } case next-hop-list { description "Container for multiple next hops."; list next-hop { key "hop-index"; description "An entry in a next-hop list."; leaf hop-index { type uint8; description "A user-specified identifier utilized to uniquely reference the next-hop entry in the next-hop list. The value of this index has no semantic meaning other than for referencing the entry."; } leaf outgoing-interface { type if:interface-ref; description "The outgoing interface, when matching all flows to the interface."; } choice flow-type { description "The flow types supported."; case ip { leaf next-hop-address { type inet:ip-address; description "This is the IP flow type next hop."; } } case mpls { uses rt-types:mpls-label-stack; } } } } } } grouping detnet-forwarding-next-hop-content { description "Generic parameters of DetNet next hops. This follows the principles for next hops in RFC 8349"; choice next-hop-options { description "Options for next hops. It is expected that further cases will be added through augments from other modules, e.g., for recursive next hops."; case simple-next-hop { description "This case represents a simple next hop consisting of the next-hop address and/or outgoing interface."; leaf outgoing-interface { type if:interface-ref; description "The outgoing interface, when matching all flows to the interface."; } choice flow-type { description "These are the flow type next hop choices."; case ip { description "Use IP data plane for forwarding."; leaf next-hop-address { type inet:ip-address; description "This is an IP address as a next hop."; } uses ip-header; } case mpls { description "Use MPLS data plane for forwarding."; uses rt-types:mpls-label-stack; } } } case next-hop-list { description "Container for multiple next hops."; list next-hop { key "hop-index"; description "An entry in a next-hop list."; leaf hop-index { type uint8; description "The value of the index for a hop."; } leaf outgoing-interface { type if:interface-ref; description "The outgoing interface, when matching all flows to the interface."; } choice flow-type { description "These are the flow type next hop choices."; case ip { description "Use IP data plane for forwarding."; leaf next-hop-address { type inet:ip-address; description "This is an IP address as a next hop."; } uses ip-header; } case mpls { description "Use MPLS data plane for forwarding."; uses rt-types:mpls-label-stack; } } } } } } container detnet { description "The top level DetNet container. This contains applications, service sub-layers and forwarding sub-layers as well as the traffic profiles."; list traffic-profile { key "name"; description "A traffic profile."; leaf name { type string; description "The name of the traffic profile which is used as a reference to this profile."; } container traffic-requirements { description "This defines the attributes of the App-flow regarding bandwidth, latency, latency variation, loss, and misordering tolerance."; reference "RFC 9016 Section 5.9"; leaf min-bandwidth { type uint64; units 'octets per second'; description "This is the minimum bandwidth that has to be guaranteed for the DetNet service. MinBandwidth is specified in octets per second."; reference "RFC 9016 Section 5.9.1"; } leaf max-latency { type uint32; units "nanoseconds"; description "This is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow. MaxLatency is specified as an integer number of nanoseconds. The MAX value is 4,294,967,295 nanoseconds."; reference "RFC 9016 Section 5.9.2"; } leaf max-latency-variation { type uint32; units "nanoseconds"; description "This is the difference between the minimum and the maximum end-to-end one-way latency. MaxLatencyVariation is specified as an integer number of nanoseconds."; reference "RFC 9016 Section 5.9.3"; } leaf max-loss { type decimal64 { fraction-digits 10; range "0 .. 100"; } units "percent"; description "This defines the maximum Packet Loss Rate (PLR) parameter for the DetNet service between the Ingress and Egress(es) of the DetNet domain. Packet loss rate is calculated by the number of transmitted packets minus the number of received packets divided by the number transmitted packets expressed as a percent."; reference "RFC 9016 Section 5.9.4"; } leaf max-consecutive-loss-tolerance { type uint32; units "packets"; description "Some applications have special loss requirement, such as MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured for example based on sequence number."; reference "RFC 9016 Section 5.9.5"; } leaf max-misordering { type uint32; units "packets"; description "This describes the tolerable maximum number of packets that can be received out of order. The maximum allowed misordering can be measured for example based on sequence number. The value zero for the maximum allowed misordering indicates that in order delivery is required, misordering cannot be tolerated."; reference "RFC 9016 Section 5.9.6"; } } container traffic-spec { description "Traffic-specification specifies how the Source transmits packets for the flow. This is the promise/request of the Source to the network. The network uses this flow specification to allocate resources and adjust queue parameters in network nodes."; reference "RFC 9016 Section 5.5"; leaf interval { type uint32; units "nanoseconds"; description "The period of time in which the traffic specification should not be exceeded."; reference "RFC 9016 Section 5.5, IEEE802.1Q"; } leaf max-pkts-per-interval { type uint32; description "The maximum number of packets that the source will transmit in one interval."; reference "RFC 9016 Section 5.5, IEEE802.1Q"; } leaf max-payload-size { type uint32; description "The maximum payload size that the source will transmit."; reference "RFC 9016 Section 5.5, IEEE802.1Q"; } leaf min-payload-size { type uint32; description "The minimum payload size that the source will transmit., IEEE802.1Q"; } leaf min-pkts-per-interval { type uint32; description "The minimum number of packets that the source will transmit in one interval."; reference "RFC 9016 Section 5.5, IEEE802.1Q"; } } leaf-list member-app-flow { type app-flow-ref; config false; description "A list of Applications attached to this profile. Each application that uses a profile has an automatically populated reference."; reference "RFC XXXX: Deterministic Networking (DetNet) YANG Model Section 5"; } leaf-list member-svc-sublayer { type service-sub-layer-ref; config false; description "A list of Service Sub-layers attached to this profile. Each Service Sub-layers that uses a profile has an automatically populated reference."; reference "RFC XXXX: Deterministic Networking (DetNet) YANG Model Section 5"; } leaf-list member-fwd-sublayer { type forwarding-sub-layer-ref; config false; description "A list of Forwarding Sub-layers attached to this profile. Each Forwarding Sub-layers that uses a profile has an automatically populated reference."; reference "RFC XXXX: Deterministic Networking (DetNet) YANG Model Section 5"; } } container app-flows { description "The DetNet app-flow configuration."; reference "RFC 9016 Section 4.1"; list app-flow { key "name"; description "A unique (management) identifier of the App-flow."; leaf name { type string; description "A unique (management) identifier of the App-flow."; reference "RFC 9016 Sections 4.1, 5.1"; } leaf bidir-congruent { type boolean; default false; description "Defines the data path requirement of the App-flow whether it must share the same data path and physical path for both directions through the network, e.g., to provide congruent paths in the two directions."; reference "RFC 9016 Section 4.2"; } leaf outgoing-service { type service-sub-layer-ref; config false; description "Binding to this applications outgoing service."; } leaf incoming-service { type service-sub-layer-ref; config false; description "Binding to this applications incoming service."; } leaf traffic-profile { type traffic-profile-ref; description "The Traffic Profile for this group."; } container ingress { description "Ingress DetNet application flows or a compound flow."; leaf app-flow-status { type identityref { base app-status; } default none; config false; description "Status of ingress application flow. This is an operational status and defaults to none if incomplete."; reference "RFC 9016 Sections 4.1, 5.8"; } leaf-list interface { type if:interface-ref; description "Interface is optional for a service type. When matching a flow to a single interface one interface is specified. The list allows for matching a subset of interfaces. When more than one interfaces is specified, these flows are simply aggregated and the service sub-layer is unaware of the aggregation."; } uses data-flow-spec; } //End of app-ingress container egress { description "Egress DetNet application flows or a compound flow."; uses data-flow-spec; choice application-type { description "This is the application type choices."; container ethernet { description "This is Ethernet or TSN traffic that maps to an interface."; leaf-list interface { type if:interface-ref; description "This is one or more Ethernet or TSN interfaces. If multiple interfaces are specified, this application flow is replicated to those interfaces. DetNet application Flow filtering applies to the whole list of interfaces. For fine grain flow filtering, use a single interface per application."; } } container ip-mpls { description "This is IP or MPLS DetNet application types."; uses detnet-app-next-hop-content; } } } } } container service { description "The DetNet service sub-layer configuration."; list sub-layer { key "name"; description "Services are indexed by name."; leaf name { type string; description "The name of the DetNet service sub-layer."; } leaf service-rank { type uint8; default 255; description "The DetNet rank for this service. Defaults to 255 lowest rank if not specified."; reference "RFC 9016 Section 5.7."; } leaf traffic-profile { type traffic-profile-ref; description "The Traffic Profile for this service."; } container service-protection { description "This is the service protection type and sequence number options."; leaf protection { type service-protection; description "The DetNet service protection type such as Packet Replication Function (PRF), Packet Elimination Function (PEF), Packet Replication, Elimination, and Ordering Functions (PREOF)."; reference "RFC 8938 Section 4.3"; } leaf sequence-number-length { type sequence-number-field; default zero-sn; description "Sequence number field length can be one of 0 (none), 16-bits or 28-bits. The default is none."; } } leaf operation { type operation; description "This is the service operation type for this service sub-layer;"; } container incoming { description "The DetNet service sub-layer incoming configuration."; choice incoming { description "A service sub-layer may have App flows or other service sub-layers."; container app-flow { description "This service sub-layer is related to the app-flows of the upper layer and provide ingress proxy or ingress aggregation at the ingress node."; uses app-flows-group; } container service-aggregation { description "This service sub-layer is related to the service sub-layer of the upper layer and provide service-to-service aggregation at the ingress node or relay node."; uses service-sub-layer-group; } container forwarding-aggregation { description "This service sub-layer is related to the forwarding sub-layer of the upper layer and provide forwarding-to-service aggregation at the ingress node or relay node."; uses forwarding-sub-layer-group; } container service-id { description "This service sub-layer is related to the service or forwarding sub-layer of the lower layer and provide DetNet service relay or termination at the relay node or egress node."; uses detnet-flow-spec; } container forwarding-sub-layer { description "This entry specifies one or more forwarding sub-layers. No or minimal service sub-layer encapsulation is allowed."; leaf-list sub-layer { type forwarding-sub-layer-ref; config false; description "List of outgoing forwarding sub-layers."; } } } } container outgoing { description "The DetNet service sub-layer outgoing configuration."; choice outgoing { description "The outgoing type may be a forwarding Sub-layer or a service sub-layer or aggregation type."; container forwarding-sub-layer { description "This service sub-layer is sending to the forwarding sub-layers of the lower layer for DetNet service forwarding or service-to-forwarding aggregation at the ingress node or relay node. When the operation type is service-initiation, The service sub-layer encapsulates the DetNet Control-Word and services label, which are for individual DetNet flow when the incoming type is app-flow and for aggregated DetNet flow when the incoming type is service or forwarding. The service sub-layer swaps the service label when the operation type is service-relay."; reference "RFC 8964 Section 4.2.1 and 4.2.2."; list service-outgoing { key "index"; description "List of the outgoing service that separately for each node where services will be eliminated."; leaf index { type uint8; description "This index allows a list of multiple outgoing forwarding sub-layers"; } uses detnet-header; uses forwarding-sub-layer-group; } } container service-sub-layer { description "This service sub-layer is sending to the service sub-layers of the lower layer for service-to-service aggregation at the ingress node or relay node. The service sub-layer encapsulates the DetNet Control-Word and S-label when the operation type is service-initiation, and swaps the S-label when the operation type is service-relay."; reference "RFC 8964 Section 4.2.1 and 4.2.2."; leaf aggregation-sub-layer { type service-sub-layer-ref; description "reference point of the service-sub-layer at which this service will be aggregated."; } container service-label { description "This is the MPLS service sub-layer label. This is optional and only used when the service sub-layer uses MPLS. It is an MPLS stack since more than a single label may be used."; uses rt-types:mpls-label-stack; } } container app-flow { description "This service sub-layer is sending to the app-flow of the upper layer for egress proxy at the egress node, and decapsulates the DetNet Control-Word and S-label for individual DetNet service. This outgoing type only can be chosen when the operation type is service-termination."; reference "RFC 8964 Section 4.2.1 and 4.2.2."; uses app-flows-group; } container service-disaggregation { description "This service sub-layer is sending to the service sub-layer of the upper layer for service-to-service disaggregation at the relay node or egress node, and decapsulates the DetNet Control-Word and A-label for aggregated DetNet service. This outgoing type only can be chosen when the operation type is service-termination."; reference "RFC 8964 Section 4.2.1 and 4.2.2."; uses service-sub-layer-group; } container forwarding-disaggregation { description "This service sub-layer is sending to the forwarding sub-layer of the upper layer for forwarding-to-service disaggregation at the relay node or egress node, and decapsulates the DetNet Control-Word and A-label for aggregated DetNet service. This outgoing type only can be chosen when the operation type is service-termination."; reference "RFC 8964 Section 4.2.1 and 4.2.2."; uses forwarding-sub-layer-group; } } } } } container forwarding { description "The DetNet forwarding sub-layer configuration."; list sub-layer { key "name"; description "The list is one or more DetNet service/forwarding types."; leaf name { type string; description "The name of the DetNet forwarding sub-layer."; } leaf traffic-profile { type traffic-profile-ref; description "The Traffic Profile for this group."; } leaf operation { type mpls-fwd-operation; description "This is the forwarding operation types impose-and-forward, pop-and-forward, pop-impose-and-forward, forward, pop-and-lookup."; } container incoming { description "The DetNet forwarding sub-layer incoming configuration."; choice incoming { description "Cases of incoming types."; container service-sub-layer { description "This forwarding sub-layer is related to the service sub-layers of the upper layer and provide DetNet forwarding or service-to-forwarding aggregation at the ingress node or relay node."; uses service-sub-layer-group; } container forwarding-aggregation { description "This forwarding sub-layer is related to the forwarding sub-layer of the upper layer and provide forwarding-to-forwarding aggregation at the ingress node or relay node or transit node."; uses forwarding-sub-layer-group; } container forwarding-id { description "This forwarding sub-layer is related to all of the lower layer and provide DetNet forwarding swap or termination at the transit node or relay node or egress node."; leaf interface { type if:interface-ref; description "This is the interface associated with the forwarding sub-layer."; } uses detnet-flow-spec; } } } container outgoing { description "The DetNet forwarding sub-layer outbound configuration."; choice outgoing { description "This is when a service connected directly to an interface with no forwarding sub-layer."; container interface { description "This forwarding sub-layer is sending to the interface for send to next-hop at the ingress node or relay node or transit node."; uses detnet-forwarding-next-hop-content; } container service-aggregation { description "This forwarding sub-layer is sending to the service sub-layers of the lower layer for forwarding-to-service aggregation at the ingress node or relay node."; leaf aggregation-sub-layer { type service-sub-layer-ref; description "This is a reference to the service sub-layer."; } container optional-forwarding-label { description "This is the optional forwarding label for service aggregation."; uses rt-types:mpls-label-stack; } } container forwarding-sub-layer { description "This forwarding sub-layer is sending to the forwarding sub-layers of the lower layer for forwarding-to-forwarding aggregation at the ingress node or relay node or transit node."; leaf aggregation-sub-layer { type forwarding-sub-layer-ref; description "This is a reference to the forwarding sub-layer."; } container forwarding-label { description "This is the forwarding label for forwarding sub-layer aggregation."; uses rt-types:mpls-label-stack; } } container service-sub-layer { description "This forwarding sub-layer is sending to the service sub-layer of the upper layer and decapsulate the F-label for DetNet service or service-to-forwarding disaggregation at the relay node or egress node. This outgoing type only can be chosen when the operation type is pop-and-lookup."; uses service-sub-layer-group; reference "RFC 8964 Section 4.2.3"; } container forwarding-disaggregation { description "This forwarding sub-layer is sending to the forwarding sub-layer of the upper layer and decapsulate the F-label for forwarding-to-forwarding disaggregation at the transit node or relay node or egress node. This outgoing type only can be chosen when the operation type is pop-and-lookup."; uses forwarding-sub-layer-group; } } } } } } } ]]>
IANA Considerations This document registers a URI in the "IETF XML Registry" . Following the format in , the following registration is requested to be made:
ID:
yang:ietf-detnet
URI:
urn:ietf:params:xml:ns:yang:ietf-detnet
Registrant Contact:
The IESG.
XML:
N/A, the requested URI is an XML namespace.
This document registers YANG modules in the "YANG Module Names" registry .
Name:
ietf-detnet
Maintained by IANA:
N
Namespace:
urn:ietf:params:xml:ns:yang:ietf-detnet
Prefix:
dnet
Reference:
This RFC when published.
Security Considerations Security considerations for DetNet are covered in the DetNet Architecture and DetNet Security Considerations . The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols, such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in the module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Unauthorized write operations (e.g., edit-config) to any elements of this module can break or incorrectly connect DetNet flows. Since DetNet is a configured Data Plane, any changes that are not coordinated with all devices along the path will create a denial of service. In addition, arbitrary write operations could also enable an attacker to modify a network path to enable select traffic to avoid inspection or treatment by security controls, or route traffic in a way that it would be subject to inspect/modification by an adversary node. Similarly, the data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data node and their sensitivity/vulnerability: /detnet/app-flows: This controls the application details so it could be considered sensitive. /detnet/traffic-profile/member-app-flow: This links traffic profiles to applications, service sub-layers and/or and forwarding sub-layers so this also could be considered more sensitive. /detnet/service/sub-layer/incoming/app-flow: This links applications to services. /detnet/service/sub-layer/outgoing/app-flow: This links applications to services. The above nodes can reveal identifiable characteristics of the application flows. /detnet/service/sub-layer: This defines the service and forwarding operations. /detnet/fowarding/sub-layer: This defines the forwarding operations. The above nodes can reveal some aspects of the network topology of there is unauthorized access to this configuration.
Contributors The editors of this document wish to thank and acknowledge the following people who contributed substantially to the content of this document and should be considered coauthors: Huawei Technologies
mach.chen@huawei.com
Acknowledgments The editors of this document would like to thank Lou Berger, Tom Petch Xufeng Lui, Julien Meuric, John Scudder` and Florian Kauer for their detailed comments.
References Normative References Informative References IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks IEEE
DetNet Configuration YANG Tree This is the full YANG tree as described in .
Examples The following examples are provided. These examples are tested with Yanglint and use operational output to exercise both config true and config false objects. Note that IPv4 and IPv6 addresses are supported but for clarity in the examples and diagrams IPv4 has been used in most examples. The IP types are imported from and these support both IPv4 and IPv6. The following conventions are used in the diagrams.
  • Replication and Elimination points are shown as an R in and E in circles respectively.
  • Packet Headers including DetNet aggregation label or A-label, Service label or S-label and Forwarding label or F-label are illustrated at each hop as defined in .
  • Aggregation/Disaggregation nodes are indicated by dashed line boxes.
  • Since the model augments IETF interfaces, minimal interface YANG data is provided to validate the interface data as well. This shows up as a named value such as "eth0" etc. that is referenced by the configuration.
The following are examples of aggregation and disaggregation at various points in DetNet. Figures are provided in the PDF and HTML version of this document.
Example A-1 JSON Configuration/Operational This illustrates that multiple App flows with the same source, the same destination, and the same traffic specification are aggregated in a single DetNet flow service sub-layer. Ingress node 1 aggregates App flows 0 and 1 into a service sub-layer of DetNet flow 1. Two ways of illustrating this follow, then the JSON operational data model corresponding to the diagrams follows. This example uses IPv6 address format.
Case A-1 Application Aggregation Source 12001:db8::1 Ingress 1 Relay 1 Relay 2 Egress 1 Transit 2 Transit 1 Destination 12001:db8::8 MPLS S-label101 MPLS F-label10001 MPLS F-label10002 MPLS S-label101 MPLS F-label10003 MPLS F-label10004 MPLS S-label100 MPLS F-label10000 MPLS S-label102 MPLS F-label10005 MPLS S-label101 MPLS S-label101 App-0 App-0 DN-1 App-1 App-1 2001:db8::12001:db8::8 DATA 0 DATA 1 R E R E aggregationdisaggregation 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1 2001:db8::12001:db8::8 DATA 0 DATA 1IPIP
Case A-1 Application Aggregation Flow Stack Detail app-0 ssl-1 fsl-1outgoing-serviceoutgoingforwarding sub-layerincomingservice sub-layeroutgoinginterface app-1outgoing-serviceCase A-1 (Ingress 1) incomingapp-flow app svc fwd appincoming-serviceCase A-1 (Egress 1) incoming-serviceoutgoingservice sub-layerincomingservice-identificationoutgoingapp-flowincomingforwarding-identification App to Svc
contains the operational JSON configuration for the ingress aggregation node illustrated in and . App-0 and app-1 are aggregated into Service Sub-layer ssl-1.
Example A-1 DetNet configuration Application Aggregation
Example B-1 XML Config: Aggregation using a Forwarding Sub-layer illustrates the DetNet service sub-layer flows 1 and 2 are aggregated into a single forwarding sub-layer. For the same destination multiple DetNet flows use a single forwarding path and service protection is performed by the corresponding service sub-layer of each flow. A diagram illustrating this case is shown and then the corresponding XML operational data for node Ingress 1 follows.
Case B-1 Example Config: Aggregation using a Forwarding Sub-layer DN-2 Source 1192.0.2.1 Ingress 1 Relay 2Egress 1Transit 2 Transit 1 Destination 1192.0.2.8 Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 App-2 App-2 MPLSF-label20000 MPLSS-label103 MPLSS-label100 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 IP 192.0.2.1192.0.2.8 MPLSF-label20001 MPLSF-label20002 MPLSS-label101 IP192.0.2.1192.0.2.8 DATA 1 MPLSS-label104 IP192.0.2.2192.0.2.9 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSF-label20003 MPLSF-label20004 MPLSS-label104 MPLSS-label101 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSF-label20005 MPLSS-label105 MPLSS-label102 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 IP 192.0.2.1192.0.2.8 DN-1 / DN-2 DN-2 DN-1 DN-2 DN-1 DN-1 / DN-2 DN-2 DN-1 DN-1 / DN-2 DN-1 DATA 1 DATA 1 App-1 App-1Note: S-label in thisdiagram includes d-CW. R E R E aggregationdisaggregation Relay 1
contains the operational XML configuration for the ingress aggregation node illustrated in . In this example app-0 and app-1 are in separate service sub-layers with MPLS labels and the aggregation happens at the forwarding sub-layer afl-1 using MPLS labels.
Example B-1 DetNet configuration Forwarding Layer Aggregation eth0 ia:ethernetCsmacd up 2024-02-21T23:59:00Z eth1 ia:ethernetCsmacd up 2024-02-21T23:59:00Z eth2 ia:ethernetCsmacd up 2024-02-21T23:59:00Z app-1 false ssl-1 1 ready eth0 192.0.2.1/32 192.0.2.8/32 6 app-2 false ssl-2 1 ready eth1 192.0.2.2/32 192.0.2.9/32 7 1 100000000 100000000 20000000 0.0000001 5 0 5 10 1500 app-1 app-2 2 100000000 100000000 20000000 0.000001 5 0 ssl-1 ssl-2 3 5 20 1500 afl-1 ssl-1 10 2 initiation none long-sn app-1 0 0 afl-1 ssl-2 10 2 initiation none long-sn app-2 0 0 afl-1 afl-1 3 impose-and-forward ssl-1 ssl-2 eth2 0 ]]>
Example B-2 JSON Service Aggregation Configuration illustrates DetNet service sub-layer flows 1 and 2 are aggregated into a service sub-layer of an aggregated flow. Multiple DetNet flows with the same requirements for the same destination are aggregated into a single aggregated DetNet flow, and service protection and resource allocation are performed by an aggregated DetNet flow service sub-layer and forwarding sub-layer. A diagram illustrating this case is shown and then the corresponding JSON operational data for node Ingress 1 follows.
Case B-2 Example Service Aggregation Source 1192.0.2.1 Ingress 1192.0.2.2 Relay 1 Relay 2 Egress 1 Transit 2 Transit 1 Destination 1192.0.2.8 Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 App-2 App-2 DN-2 DN-1 Aggregated DN-1 DN-2 DN-1 MPLSS-label105 MPLSF-label20000 MPLSS-label102 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 IP 192.0.2.1192.0.2.8 MPLSA-label1000 MPLSF-label20001 MPLSF-label20002 MPLSA-label1001 MPLSA-label1001 MPLSS-label102 IP192.0.2.1192.0.2.8 DATA1 MPLSS-label105 IP192.0.2.2192.0.2.9 DATA 2 MPLSS-label102 MPLSS-label105 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label105 MPLSF-label20003 MPLSF-label20004 MPLSA-label1001 MPLSA-label1001 MPLSS-label102 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label102 MPLSS-label105 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label105 MPLSF-label20005 MPLSS-label102 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSA-label1002 IP 192.0.2.1192.0.2.8 App-1 App-1 DATA 1 DATA 1 R E R ENotes:-S and A labels in this diagram include d-CWsof their own. aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example, service sub-layer ssl-1 for DetNet flow DN1 and ssl-2 for flow DN2 aggregate at service sub-layer Detet flow asl-1. In this example an aggregation service sub-layer asl-1 is created to aggregated ssl-1 and ssl2 and that label is encapsulated in a separate forwarding sub-layer afl-1 with MPLS labels.
Example B-2 DetNet Service Aggregation
Example C-1 JSON Relay Aggregation/Disaggregation Configuration illustrates the relay node's forwarding sub-layer flows 1 and 2 aggregated into a single forwarding sub-layer. Service protection and resource allocation are performed by the corresponding service sub-layer and forwarding sub-layer of each flow. A diagram illustrating both aggregation and disaggregation is shown and then the corresponding JSON operational data follows.
Case C-1 Example Service Aggregation/Disaggregation Source 1192.0.2.1 Ingress 1 Relay 1Relay 2Egress 1 Transit 2 Transit 1 Destination 1 DATA 1 MPLS F-label20000 MPLS F-label20001 MPLS F-label20002 MPLS F-label20003 DATA 1 IP 192.0.2.1192.0.2.8 IP 192.0.2.1192.0.2.8 MPLS S-label100 MPLS F-label10000 DATA 1 IP 192.0.2.1192.0.2.8 MPLS S-label102 MPLS F-label10005 DATA 1 IP 192.0.2.1192.0.2.8Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 MPLS S-label103 DATA 2 IP 192.0.2.2192.0.2.9 Ingress 2 Egress 2 MPLS F-label10006 MPLS S-label105 DATA 2 IP 192.0.2.2192.0.2.9 App-1 App-2 App-1 App-2 DN-1 DN-2 DN-1 DN-2 R E R E MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSF-label10003 MPLSF-label10009 MPLSF-label10004 MPLSF-label10010 MPLSF-label10003 MPLSF-label10009 MPLSF-label10004 MPLSF-label10010 MPLS F-label10011Note: S-label in thisdiagram includes d-CW. DN-1 DN-2 DN-1 / DN-2 DN-1 DN-2 aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example, a relay performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows DN1 and DN2 are replicated at each service sub-layer. The two forwarding sub-layers for the upside path are aggregated at the forwarding sub-layer with label 20000 and the two forwarding sub-layers for the downside path are aggregated at the forwarding sub-layer with label 20001. contains the operational JSON configuration for the egress disaggregation node illustrated in .
Example C-1 DetNet Relay Service Aggregation
Example C-1 DetNet Relay Service Disaggregation
Example C-2 JSON Relay Aggregation/Disaggregation Service Sub-Layer illustrates the DetNet relay node service sub-layer flows 1 and 2 aggregated into a single forwarding sub-layer. Service protection is performed by the corresponding service sub-layer of each flow and resource allocation is performed by an aggregated forwarding sub-layer for all aggregated flows. A diagram illustrating both aggregation and disaggregation is shown and then the corresponding JSON operational data follows.
Case C-2 Example Service Aggregation/Disaggregation Source 1192.0.2.1 Ingress 1 Relay 1Relay 2Egress 1 Transit 2 Transit 1 Destination 1192.0.2.8 DATA 1 MPLS F-label20000 MPLS F-label20001 MPLS F-label20002 MPLS F-label20003 DATA1 IP 192.0.2.1192.0.2.8 IP 192.0.2.1192.0.2.8 MPLS S-label100 MPLS F-label10000 DATA 1 IP 192.0.2.1192.0.2.8 MPLSS-label 102 MPLS F-label10005 DATA 1 IP 192.0.2.1192.0.2.8Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 MPLS S-label103 DATA 2 IP 192.0.2.2192.0.2.9 Ingress 2 Egress 2 MPLS F-label10006 MPLS S-label105 DATA 2 IP 192.0.2.2192.0.2.9 App-1 App-2 App-1 App-2 DN-1 DN-2 DN-1 DN-2 R E R E MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLS F-label10011Note: S-label in thisdiagram includes d-CW. DN-1 DN-2 DN-1 / DN-2 DN-1 DN-2 aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example, a relay performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows DN1 and DN2 are replicated at each service sub-layer, and the replicated each service sub-layer for the upside path is aggregated at the single forwarding sub-layer with MPLS label 20000, and the replicated each service sub-layer for the downside path is aggregated at the forwarding sub-layer with MPLS label 20001. contains the operational JSON configuration for the egress disaggregation node illustrated in .
Example C-2 DetNet Relay Aggregation Service Sub-Layer
Example C-2 DetNet Relay Disaggregation Service Sub-Layer
Example C-3 JSON Relay Service Sub-Layer Aggregation/Disaggregation illustrates the DetNet relay node service sub-layer flows 1 and 2 aggregated into a service sub-layer flow. Multiple DetNet flows with the same requirements which can use the same path are aggregated into a single aggregated DetNet flow, and service protection and resource allocation are performed by the service sub-layer and forwarding sub-layer of aggregated DetNet flow. A diagram illustrating both aggregation and disaggregation is shown and then the corresponding JSON operational data follows.
Case C-3 Example Service Aggregation/Disaggregation MPLSS-label104Source 1192.0.2.1 Ingress 1 Relay 1Relay 2Egress 1 Transit 2 Transit 1 Destination 1192.0.2.8 DATA 1 MPLS F-label20000 MPLS F-label20001 MPLS F-label20002 MPLS F-label20003 DATA 1 IP 192.0.2.1192.0.2.8 IP 192.0.2.1192.0.2.8 MPLS S-label100 MPLS F-label10000 DATA 1 IP 192.0.2.1192.0.2.8 MPLS S-label102 MPLS F-label10005 DATA 1 IP 192.0.2.1192.0.2.8Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 MPLS A-label1000 MPLS S-label103 DATA 2 IP 192.0.2.2192.0.2.9 MPLS A-label1000 MPLS A-label1000 MPLS A-label1000 Ingress 2 Egress 2 MPLS F-label10006 MPLS S-label105 MPLS F-label10011 DATA 2 IP 192.0.2.2192.0.2.9 App-1 App-2 App-1 App-2 DN-1 DN-2 DN-1 DN-2 R E R E MPLSS-label101 IP192.0.2.1192.0.2.8 DATA 1 MPLSS-label104 IP192.0.2.2192.0.2.9 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2Note: S and A labels in thisdiagram include d-CWs of theirown. DN-1 DN-2 Aggregated DN-1 DN-1 DN-2 aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example a relay performing aggregation at the service sub-layer is illustrated. Two DetNet flows DN1 and DN2 are relayed at each service sub-layer with MPLS labels 101 and 104 respectively, and each service sub-layer is aggregated at a single service sub-layer flow and replicated. contains the operational JSON configuration for the egress disaggregation node illustrated in .
Example C-3 DetNet Relay Service Sub-Layer Aggregation
Example C-3 DetNet Relay Service Sub-Layer Disaggregation
Example C-4 JSON Relay Service Sub-Layer Aggregation/Disaggregation illustrates the relay node DetNet forwarding sub-layer flows 1 and 2 aggregated into a service sub-layer DetNet flow. Multiple DetNet flows with the same requirements which can use the same path are aggregated into a single aggregated DetNet flow. Service protection is performed by the service sub-layer of the aggregated DetNet flow and resource allocation is performed by the forwarding sub-layer of each aggregated DetNet flow. A diagram illustrating both aggregation and disaggregation is shown and then the corresponding JSON operational data follows.
Case C-4 Example Service Aggregation/Disaggregation 18Source 1192.0.2.1 Ingress 1 Relay 1 Relay 2 Egress 1 Transit 2 Transit Destination 1192.0.2.8 DATA 1 MPLS F-label20000 MPLS F-label20001 MPLS F-label20002 MPLS F-label20003 DATA 1 IP 192.0.2.1192.0.2.8 IP 192.0.2.1192.0.2.8 MPLS S-label100 MPLS F-label10000 DATA 1 IP 192.0.2.1192.0.2.8 MPLS S-label102 MPLS F-label10005 DATA 1 IP 192.0.2.1192.0.2.8Source 2192.0.2.2 DATA 2 IP 192.0.2.2192.0.2.9Destination 2192.0.2.9 DATA 2 IP 192.0.2.2192.0.2.9 MPLS A-label1000 MPLS S-label103 DATA 2 IP 192.0.2.2192.0.2.9 MPLS A-label1000 MPLS A-label1000 MPLS A-label1000 Ingress 2192.0.2.23 Egress 2192.0.2.78 MPLS F-label10006 MPLS S-label105 MPLS F-label10011 DATA 2 IP 192.0.2.2192.0.2.9 App-1 App-2 App-1 App-2 DN-1 DN-2 DN-1 DN-2 R E R E MPLSS-label101 IP192.0.2.1192.0.2.8 DATA 1 MPLSS-label104 IP192.0.2.2192.0.2.9 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSS-label101 MPLSS-label104 IP192.0.2.1192.0.2.8 IP192.0.2.2192.0.2.9 DATA 1 DATA 2 MPLSF-label20004 MPLSF-label20005 MPLSF-label20004 MPLSF-label20005 MPLSF-label20004 MPLSF-label20005 MPLSF-label20004 MPLSF-label20005Note: S and A labels in this diagraminclude d-CWs of their own. DN-1 DN-2 Aggregated DN-1 DN-1 DN-2 aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example, a relay performing aggregation at the service sub-layer is illustrated. Two DetNet flows DN1 and DN2 are relayed at each service sub-layer. The two DetNet forwarding sub-layer flows with MPLS labels 20004 and 20005 are aggregated at the single service sub-layer DetNet flow and then replicated. contains the operational JSON configuration for the egress disaggregation node illustrated in .
Example C-4 DetNet Relay Service Sub-Layer Aggregation
Example C-4 DetNet Relay Service Sub-Layer Disaggregation
Example D-1 JSON Transit Forwarding Sub-Layer Aggregation/Disaggregation illustrates at the transit node, forwarding sub-layer flows 1 and 2 are aggregated into a single forwarding sub-layer. Resource allocation is performed by the corresponding forwarding sub-layer for all aggregated flows. illustrating both aggregation and disaggregation is shown and then the corresponding JSON operational data follows.
Case D-1 Example Transit Node Forwarding Aggregation/Disaggregation Ingress 1192.0.2.2 Transit 1 Transit 4 Egress 1 Transit 3 Transit 2 MPLS S-label100 MPLS F-label10000 DATA 1 IP 192.0.2.1192.0.2.9 MPLS S-label100 MPLS F-label10003 DATA 1 IP 192.0.2.1192.0.2.9 Ingress 2 Egress 2 Source 1192.0.2.1 DATA 1 IP 192.0.2.1192.0.2.9Source 2192.0.2.2 Destination 2192.0.2.9 Destination 1192.0.2.8 DATA 1 IP 192.0.2.1192.0.2.9 App-1 DN - 1 App-1 DN-1 App-2 App-2 DN-2 DN-2 DN-1 / DN-2 DN-1 / DN-2 MPLS S-label101 MPLS F-label10004 DATA 2 IP 192.0.2.2192.0.2.8 DATA 2 IP 192.0.2.2192.0.2.8 MPLS F-label20000 MPLS F-label20001 MPLSS-label100 MPLSS-label101 IP192.0.2.1192.0.2.9 IP192.0.2.2192.0.2.8 DATA 1 DATA 2 MPLSS-label100 MPLSS-label101 IP192.0.2.1192.0.2.9 IP192.0.2.2192.0.2.8 DATA 1 DATA 2 MPLS F-label10002 MPLS F-label10006 MPLS F-label10002 MPLS F-label10006 MPLS S-label101 MPLS F-label10007 DATA 2 IP 192.0.2.2192.0.2.8 DATA 2 IP 192.0.2.2192.0.2.8 aggregationdisaggregation
contains the operational JSON configuration for the ingress aggregation node illustrated in . In this example, a transit node performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows DN1 and DN2 are transmitted at each forwarding sub-layer. The DetNet forwarding sub-layer flows with MPLS labels 10002 and 10006 are aggregated at the single forwarding sub-layer. The resulting aggregated DetNet flow has MPLS label 20000. contains the operational JSON configuration for the egress disaggregation transit node illustrated in .
Example D-1 Transit Node Forwarding Aggregation
Example D-1 Transit Node Forwarding Disaggregation