RFC 9633: Deterministic Networking (DetNet) YANG Data Model
- X. Geng,
- Y. Ryoo,
- D. Fedyk,
- R. Rahman,
- Z. Li
Abstract
This document contains the specification for the Deterministic Networking (DetNet) YANG data model for configuration and operational data for DetNet flows. The model allows the provisioning of an end-to-end DetNet service on devices along the path without depending 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).¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
DetNet (Deterministic Networking) provides the ability 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 [RFC8655].¶
This document defines a YANG data model for DetNet based on YANG data types and modeling language defined in [RFC6991] and [RFC7950].¶
This document also includes the following:¶
This YANG data model is scoped to the description of the
aggregation
2. Abbreviations
The following abbreviations are used in this document:¶
3. Terminology
This document uses the terminology defined in [RFC8655]. The terms "A-Label", "S-Label", and "F-Label" are used in this document as defined in [RFC8964].¶
4. DetNet YANG Module
The DetNet YANG module (Section 8) 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 Sections 4.1, 4.2, and 4.3, respectively.¶
Layers of the objects typically occur
in the different data instances forming the node types defined in
[RFC8655].
Table 1
illustrates the relationship between data instance node types and the included layers.
Node types are logical roles per DetNet service: one
DetNet service may use a device of one node type, while another service may use
the same device with a different node type.
This model is a controller
All of the layers have ingress
In the YANG data model defined in this document, 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" means "to the DetNet application", and "egress" means "from the application".
The terms "incoming" and "outgoing" represent
the flow direction towards the remote application as a unidirectional flow.
This means the terms are used at a sub-layer to represent
"incoming" to the sub-layer function and "outgoing" is viewed as leaving the sub-layer.
For the service sub-layer, "incoming" is typically aggregating applications flows or other service
sub-layers, etc.
For the forwarding sub-layer, "incoming" is typically aggregating service sub-layers.
However, this also means for both service and forwarding sub-layers at the egress DetNet node
"incoming" also handles external flows "incoming" to the respective sub-layer. For MPLS, this
would usually involve the removal of a label. For IP -- where the representative sub-layer is merely an
aggregation of an IP prefix or IP tuple -- there may be
no incoming
At the egress point, forwarding information is determined by the App-flow type with all DetNet-related headers removed. In the case of IP, the forwarding information can specify an output port or set a next-hop address. In the case of MPLS, it can set an MPLS label.¶
4.1. DetNet Application Flow YANG Attributes
DetNet application flows are 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 defined in [RFC9016] are used.¶
4.2. DetNet Service Sub-layer YANG Attributes
DetNet service functions, e.g., DetNet tunnel
initialization
4.3. DetNet Forwarding Sub-layer YANG Attributes
As defined in [RFC8655], the DetNet forwarding sub-layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network. Explicit routes provide another mechanism used by DetNet to avoid temporary interruptions caused by the convergence of routing or bridging protocols. Explicit routes are also implemented at the DetNet forwarding sub-layer.¶
To support congestion protection and explicit routes, the following
transport
5. DetNet Flow Aggregation
DetNet provides the ability to perform flow aggregation to improve the 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 reservation is used, the reservation should be a reasonable representation of the total aggregate bandwidth; if maximum delay bounds are used, the system should ensure that the total DetNet flow delay does not exceed the maximum delay bound of any individual flow.¶
The DetNet YANG data model defined in this document supports DetNet flow aggregation with the following functions:¶
The following DetNet aggregation scenarios are supported:¶
Traffic requirements and the traffic specification may be tracked for individual or aggregate flows, but reserving resources and tracking the services in the aggregated flow are out of scope.¶
6. DetNet YANG Structure Considerations
This diagram shows the general structure of the DetNet YANG data model:¶
There are three layer types in the DetNet YANG data model: the App-flow data layer, the service sub-layer, and the 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. The complete YANG tree is provided in Appendix A.¶
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
Depending on which DetNet layers and functions are required, some or all of the components may be configured. Examples are provided in Appendix B.¶
7. DetNet Configuration YANG Structures
The following is a partial tree representation of the DetNet YANG data model, per the guidelines provided in [RFC8340]. This corresponds to the layout of the diagram in Section 6.¶
8. DetNet Configuration YANG Data Model
This YANG data model imports typedefs from [RFC6991], [RFC8519], [RFC8294], [RFC8343], and [IEEE8021Q-2022]. This YANG data model also includes the following RFC references, which are not cited elsewhere in the body of this document: [RFC0791], [RFC4303], [RFC8200], [RFC8349], and [RFC8960].¶
9. IANA Considerations
IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -detnet¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
IANA has registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:¶
10. Security Considerations
Security considerations for DetNet are covered in "Deterministic Networking Architecture" [RFC8655] and "Deterministic Networking (DetNet) Security Considerations" [RFC9055].¶
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the
mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] 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 this YANG module that are
writable
Some of the readable data nodes in this YANG module 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 nodes and their
sensitivity
- /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 forwarding sub-layers, so this could also 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
/forwarding /sub -layer : - This defines the forwarding operations.¶
The above nodes can reveal some aspects of the network topology in the case of unauthorized access to this configuration.¶
11. References
11.1. Normative References
- [RFC0791]
-
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10
.17487 , , <https:///RFC0791 www >..rfc -editor .org /info /rfc791 - [RFC4303]
-
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10
.17487 , , <https:///RFC4303 www >..rfc -editor .org /info /rfc4303 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8200]
-
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10
.17487 , , <https:///RFC8200 www >..rfc -editor .org /info /rfc8200 - [RFC8294]
-
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10
.17487 , , <https:///RFC8294 www >..rfc -editor .org /info /rfc8294 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8349]
-
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10
.17487 , , <https:///RFC8349 www >..rfc -editor .org /info /rfc8349 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8519]
-
Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10
.17487 , , <https:///RFC8519 www >..rfc -editor .org /info /rfc8519 - [RFC8655]
-
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10
.17487 , , <https:///RFC8655 www >..rfc -editor .org /info /rfc8655 - [RFC8938]
-
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10
.17487 , , <https:///RFC8938 www >..rfc -editor .org /info /rfc8938 - [RFC8960]
-
Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", RFC 8960, DOI 10
.17487 , , <https:///RFC8960 www >..rfc -editor .org /info /rfc8960 - [RFC8964]
-
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10
.17487 , , <https:///RFC8964 www >..rfc -editor .org /info /rfc8964 - [RFC9016]
-
Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "Flow and Service Information Model for Deterministic Networking (DetNet)", RFC 9016, DOI 10
.17487 , , <https:///RFC9016 www >..rfc -editor .org /info /rfc9016
11.2. Informative References
- [IEEE8021Q-2022]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks
--Bridges and Bridged Networks" , DOI 10.1109 , IEEE Std 802.1Q-2022, , <https:///IEEESTD .2022 .10004498 ieeexplore >..ieee .org /document /10004498 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC8259]
-
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10
.17487 , , <https:///RFC8259 www >..rfc -editor .org /info /rfc8259 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC9055]
-
Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10
.17487 , , <https:///RFC9055 www >..rfc -editor .org /info /rfc9055
Appendix A. DetNet Configuration YANG Tree
This is the full YANG tree per the guidelines provided in [RFC8340].¶
Appendix B. Examples
This section provides several examples. These examples were tested with the "yanglint" program and use operational output to exercise both "config true" and "config false" objects. Note that IPv4 and IPv6 addresses are supported, but for clarity, IPv4 is used, with the exception of Example A-1 (Appendix B.1). The IP types are imported from [RFC6991]; these types support both IPv4 and IPv6.¶
The following conventions are used in the diagrams.¶
Below are examples of aggregation and disaggregation at various points in DetNet. Where indicated, figures are provided in the PDF and HTML copies of this document.¶
B.1. Example A-1: Application Flow Aggregation
This example illustrates multiple App-flows with the same source, destination, and traffic specification aggregated into 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 to illustrate this are provided in Figures 1 and 2; the JSON operational data model [RFC8259] corresponding to the diagrams is then shown in Figure 3. The address format used in this example is IPv6.¶
Figure 3 contains the operational JSON configuration for the ingress aggregation node illustrated in Figures 1 and 2. "app-0" and "app-1" are aggregated into service sub-layer ssl-1.¶
B.2. Example B-1: Aggregation Using a Forwarding Sub-layer
As illustrated in Figure 4, 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. The corresponding XML operational data for node "Ingress 1" follows.¶
Figure 5 contains the operational XML configuration for the ingress aggregation node illustrated in Figure 4. In this example, "app-0" and "app-1" are in separate service sub-layers with MPLS labels, and the aggregation happens at forwarding sub-layer afl-1, using MPLS labels.¶
B.3. Example B-2: Service Aggregation
As illustrated in Figure 6, 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. The corresponding JSON operational data for node "Ingress 1" follows.¶
Figure 7 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 6. In this example, service sub-layer ssl-1 for DetNet flow DN-1 and ssl-2 for DetNet flow DN-2 aggregate at service sub-layer DetNet flow asl-1. In this example, an aggregation service sub-layer, asl-1, is created to aggregate ssl-1 and ssl2, and that label is encapsulated in a separate forwarding sub-layer, afl-1, with MPLS labels.¶
B.4. Example C-1: DetNet Relay Service Sub-layer
Figure 8 illustrates the DetNet 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. Figure 8 illustrates both aggregation and disaggregation, and the corresponding JSON operational data follows.¶
Figure 9 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 8. In this example, a relay performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows -- DN-1 and DN-2 -- are replicated at each service sub-layer. The two forwarding sub-layers for the upper path are aggregated at the forwarding sub-layer with label 20000, and the two forwarding sub-layers for the lower path are aggregated at the forwarding sub-layer with label 20001. Figure 10 contains the operational JSON configuration for the egress disaggregation node illustrated in Figure 8.¶
B.5. Example C-2: DetNet Relay Service Sub-layer Aggregation/Disaggregation
Figure 11 illustrates the DetNet relay node's 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. Figure 11 illustrates both aggregation and disaggregation, and the corresponding JSON operational data follows.¶
Figure 12 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 11. In this example, a relay performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows -- DN-1 and DN-2 -- are replicated at each service sub-layer. Each replicated flow for the service sub-layer for the upper path is aggregated at the single forwarding sub-layer with MPLS label 20000, and each replicated flow for the service sub-layer for the lower path is aggregated at the forwarding sub-layer with MPLS label 20001. Figure 13 contains the operational JSON configuration for the egress disaggregation node illustrated in Figure 11.¶
B.6. Example C-3: DetNet Relay Service Sub-layer Aggregation/Disaggregation
Figure 14 illustrates the DetNet relay node's service sub-layer flows 1 and 2 aggregated into a service sub-layer flow. Multiple DetNet flows with the same requirements that 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 the aggregated DetNet flow. Figure 14 illustrates both aggregation and disaggregation, and the corresponding JSON operational data follows.¶
Figure 15 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 14. In this example, a relay performing aggregation at the service sub-layer is illustrated. Two DetNet flows -- DN-1 and DN-2 -- 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. Figure 16 contains the operational JSON configuration for the egress disaggregation node illustrated in Figure 14.¶
B.7. Example C-4: DetNet Relay Service Sub-layer Aggregation/Disaggregation
Figure 17 illustrates the DetNet relay node's forwarding sub-layer flows 1 and 2 aggregated into a service sub-layer DetNet flow. Multiple DetNet flows with the same requirements that 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. Figure 17 illustrates both aggregation and disaggregation, and the corresponding JSON operational data follows.¶
Figure 18 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 17. In this example, a relay performing aggregation at the service sub-layer is illustrated. Two DetNet flows -- DN-1 and DN-2 -- 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. Figure 19 contains the operational JSON configuration for the egress disaggregation node illustrated in Figure 17.¶
B.8. Example D-1: Transit Node Forwarding Sub-layer Aggregation/Disaggregation
As illustrated in Figure 20, 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. Figure 20 illustrates both aggregation and disaggregation, and the corresponding JSON operational data follows.¶
Figure 21 contains the operational JSON configuration for the ingress aggregation node illustrated in Figure 20. In this example, a transit node performing aggregation at the forwarding sub-layer is illustrated. Two DetNet flows -- DN-1 and DN-2 -- 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. Figure 22 contains the operational JSON configuration for the egress disaggregation transit node illustrated in Figure 20.¶
Acknowledgments
The authors of this document would like to thank Lou Berger, Tom Petch, Xufeng Liu, Julien Meuric, John Scudder, and Florian Kauer for their detailed comments.¶
Contributors
The authors of this document wish to thank and acknowledge the following individual, who contributed substantially to the content of this document and should be considered a coauthor:¶