Deterministic Networking
(DetNet) YANG ModelHuawei Technologiesgengxuesong@huawei.comETRIdbduscjf@etri.re.krLabN Consulting, L.L.C.dfedyk@labn.netIndividualreshad@yahoo.comChina Mobilelizhenqiang@chinamobile.comThis document contains the specification for the Deterministic Networking
YANG Model for configuration and operational data for 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.
An operator or network controller programs the configuration of the devices.The YANG module defined in this document conforms to the Network
Management Datastore Architecture (NMDA).IntroductionDetNet (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.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
TerminologyThis document uses the terminology defined in .DetNet YANG ModuleThe 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 Section 3.1, 3.2, 3.3 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 typically are logical per DetNet service
and one DetNet service can be one node type while another is another node type on
same device.
This model is a controller based model because a controller or operator
configures all the devices to form a service.
All of the layers have ingress/incoming and egress/outgoing operations but any instance
may be configured as only unidirectional. 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 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 the YANG model is handing off IP or MPLS to a next hop and a routing
next hop structure is used.
DetNet Application Flow YANG AttributesDetNet 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 AttributesDetNet 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 DetNet service layer, so there is no need for explicit
indication). The corresponding arguments for service functions
also needs to be defined.
DetNet Forwarding Sub-layer YANG AttributesAs 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, refers to . These may 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 need 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 the 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:
Mapping individual DetNet flows to an aggregated flow
Changing traffic specification parameters for aggregated flow
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 ConsiderationsThe picture shows that the general structure of the DetNet YANG
Model:
There are three layer types in 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 a summary YANG tree showing the major items.
A complete YANG tree is in section .
A traffic profile can be created for application, service sub-layer or forwarding sub-layer.
A single profile may be shared by multiple applications/sub-layer.
Each profile indicates the members that currently are using a profile.
Depending on which DetNet layers and functions are required,
some or all of the components may 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 folowing 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) 2022 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.";
revision 2022-01-05 {
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/egresss 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 0 is 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 forwarding-operations {
type enumeration {
enum impose-and-forward {
description
"This operation impose outgoing label(s) and forward 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 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 forward to next-hop.";
}
enum pop-and-lookup {
description
"This operation pops 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
"This enum value means copy the app-flow sequence number
to the DetNet-flow.";
}
enum generate-by-detnet-flow {
description
"This enum value means generate the sequence number by the
DetNet flow.";
}
}
description
"An enumeration for the sequence number behaviors supported.";
}
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
"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. 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.1Qcx-2020.";
}
leaf pcp {
type dot1q-types:priority-type;
description
"The priority value of the Ethernet header.";
reference
"IEEE 802.1Qcx-2020.";
}
}
grouping destination-ip-port-id {
description
"The TCP/UDP port(source/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/destination) 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 {
mandatory true;
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-no-zone;
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-no-zone;
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 {
mandatory true;
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 {
choice operation-type {
description
"This is the IP forwarding operation choices.";
case ip-forwarding {
leaf next-hop-address {
type inet:ip-address-no-zone;
description
"This is an IP address as a next hop.";
}
}
case mpls-over-ip-encapsulation {
uses ip-header;
}
}
}
case mpls {
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 {
choice operation-type {
description
"These are the next hop choices.";
case ip-forwarding {
leaf next-hop-address {
type inet:ip-address-no-zone;
description
"This is an IP address as a next hop.";
}
}
case mpls-over-ip-encapsulation {
uses ip-header;
}
}
}
case mpls {
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
"An Aggregation group ID.";
}
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 4.2";
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 4.2";
}
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. Any value above the MAX 4,294,967,295
is displayed as MAX";
reference
"RFC 9016 Section 4.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 4.2";
}
leaf max-loss {
type uint32;
description
"This defines the maximum Packet Loss Ratio (PLR)
parameter for the DetNet service between the Ingress and
Egress(es) of the DetNet domain.";
reference
"RFC 9016 Section 4.2";
}
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 4.2";
}
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 4.2";
}
}
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 {
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-service {
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 interface {
type if:interface-ref;
mandatory true;
description
"Interface is used for any service type when
matching all flows to the interface.";
}
uses data-flow-spec;
} //End of app-ingress
container egress {
description
"Route's next-hop attribute.";
choice application-type {
description
"This is the application type choices.";
container ethernet {
description
"This is TSN unaware traffic that maps to an
interface.";
leaf interface {
type if:interface-ref;
description
"This is an Ethernet or TSN interfaces.";
}
}
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 {
mandatory true;
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 outgoing {
description
"The DetNet service sub-layer outgoing configuration.";
choice outgoing {
mandatory true;
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 sent 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 sent 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
sublayer 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 sent 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 sent 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 sent 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 Traffic 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 forwarding-operations;
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 {
mandatory true;
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 {
mandatory true;
description
"This is when a service connected directly to an
interface with no forwarding sub-layer.";
container
interface {
description
"This forwarding sub-layer is sent 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 sent 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 sent 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 sent 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 sent 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 ConsiderationsThis 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 Archtiecture
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. Write operations (e.g., edit-config) to these data nodes without
proper protection can break or incorrectly connect DetNet flows.
Since this is a configured Data Plane any changes that are not coordinated with
all devices along the path the whole DetNet module is considered vulnerable and should
have authorized access only.
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: This links traffic profiles to applications, o this also coudl be considered moer sensitive. The trafic profiles liked to service sub-layer and forwarding sub-layer are less 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.
ContributorsThe 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 Technologiesmach.chen@huawei.comAcknowledgments The editors of this document would like to thank Lou Berger, Tom Petch and
Xufeng Lui for their detailed comments.
ReferencesNormative ReferencesInformative ReferencesIEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged NetworksIEEEIEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks Amendment 33: YANG Data Model for Connectivity Fault ManagementIEEEDetNet 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 are examples of aggregation and disaggregation at various points in Detnet. Figures
are provided in the PDF version of this document.
Example A-1 JSON Configuration/Operational
This illustrates simple aggregation. 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.
Example B-1 XML Config: Aggregation using a Forwarding Sub-layer
This illustrates aggrgation in the service sub-layers of DetNet.
Flows 1 and 2 are aggregated into a forwarding sub-layer. A diagram
illustrating this case is shown and then the
corresponding XML operational data follows.
Example B-2 JSON Service Aggregation Configuration
This illustrates the service sub-layers of DetNet. Flows 1
and 2 are aggregated into a service sub-layer of aggregated DetNet flow 1.
A diagram illustrating this case is shown and then the
corresponding JSON operational data follows.
Example C-1 JSON Relay Aggregation/Disaggregation Configuration
This illustrates the Relay node 1 aggregating the forwarding
sub-layers of DetNet flows 1 and 2 into a forwarding sub-layer.
A diagram illustrating both aggregation and disaggregation is shown and then the
corresponding JSON operational data follows.
Example C-2 JSON Relay Aggregation Service Sub-Layer
This illustrates the Relay node 1 aggregating the service sub-layers
of DetNet flows 1 and 2 into a forwarding sub-layer
A diagram illustrating both aggregation and disaggregation is shown and then the
corresponding JSON operational data follows.
Example C-3 JSON Relay Service Sub-Layer Aggregation/Disaggregation
This illustrates the Relay node 1 aggregating the
service sub-layers of DetNet flows 1 and 2 into a service sub-layer of Aggregated DetNet flow 1.
It also illustrates the Relay node 2 disaggregating the aggregated
DetNet flow 1 into the DetNet flows 1 and 2 service sub-layers.
A diagram illustrating both aggregation and disaggregation is shown and then the
corresponding JSON operational data follows.
Example C-4 JSON Relay Service Sub-Layer Aggregation/Disaggregation
This illustrates the Relay node 1 aggregating the
forwarding sub-layers of DetNet flow 1 and 2 into a service sub-layer of Aggregated DetNet flow 1.
This also illustrates the Relay node 2 disaggregating the service sub-layer of
Aggregated DetNet flow 1 to forwarding sub-layers of DetNet flow 1 and 2.
A diagram illustrating both aggregation and disaggregation is shown and then the
corresponding JSON operational data follows.
Example D-1 JSON Transit Forwarding Sub-Layer Aggregation/Disaggregation
This illustrates the Transit node 1 aggregating the forwarding
sub-layers of DetNet flow 1 and 2 into a forwarding sub-layer.
This also illustrates a Transit node 4 disaggregating a forwarding sub-layer
into DetNet flow 1 and 2 forwarding sub-layers.