rfc9938.original   rfc9938.txt 
Network Working Group A. Malis Internet Engineering Task Force (IETF) A. Malis
Internet-Draft Independent Request for Comments: 9938 Independent
Intended status: Informational X. Geng, Ed. Category: Informational X. Geng, Ed.
Expires: 28 March 2026 M. Chen ISSN: 2070-1721 M. (Guoyi)Chen
Huawei Huawei
B. Varga B. Varga
Ericsson Ericsson
CJ. Bernardos CJ. Bernardos
UC3M UC3M
24 September 2025 February 2026
A Framework for Deterministic Networking (DetNet) Controller Plane A Framework for the Deterministic Networking (DetNet) Controller Plane
draft-ietf-detnet-controller-plane-framework-15
Abstract Abstract
This document provides a framework overview for the Deterministic This document provides a framework overview for the Deterministic
Networking (DetNet) controller plane. It discusses concepts and Networking (DetNet) Controller Plane. It discusses concepts and
requirements for DetNet controller plane which could be the basis for requirements for the DetNet Controller Plane, which could be the
a future solution specification. basis for a future solution specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 28 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9938.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. DetNet Controller Plane Requirements . . . . . . . . . . . . 4 2. DetNet Controller Plane Requirements
2.1. DetNet Control Plane Requirements . . . . . . . . . . . . 4 2.1. DetNet Control Plane Requirements
2.2. DetNet Management Plane Requirements . . . . . . . . . . 5 2.2. DetNet Management Plane Requirements
2.3. Requirements For Both Planes . . . . . . . . . . . . . . 5 2.3. Requirements for Both Planes
3. DetNet Control Plane Architecture . . . . . . . . . . . . . . 6 3. DetNet Control Plane Architecture
3.1. Distributed Control Plane and Signaling Protocols . . . . 7 3.1. Distributed Control Plane and Signaling Protocols
3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 7 3.2. SDN/Fully Centralized Control Plane
3.3. Hybrid Control Plane (partly centralized, partly 3.3. Hybrid Control Plane (Partly Centralized and Partly
distributed) . . . . . . . . . . . . . . . . . . . . . . 8 Distributed)
4. DetNet Control Plane for DetNet Mechanisms . . . . . . . . . 8 4. DetNet Control Plane for DetNet Mechanisms
4.1. Explicit Paths . . . . . . . . . . . . . . . . . . . . . 8 4.1. Explicit Paths
4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 9 4.2. Resource Reservation
4.3. PREOF Support . . . . . . . . . . . . . . . . . . . . . . 10 4.3. PREOF Support
4.4. Data Plane specific considerations . . . . . . . . . . . 10 4.4. Data-Plane-Specific Considerations
4.4.1. DetNet in an MPLS Domain . . . . . . . . . . . . . . 10 4.4.1. DetNet in an MPLS Domain
4.4.2. DetNet in an IP Domain . . . . . . . . . . . . . . . 11 4.4.2. DetNet in an IP Domain
4.4.3. DetNet in a Segment Routing Domain . . . . . . . . . 11 4.4.3. DetNet in a Segment Routing Domain
4.5. Encapsulation and metadata support . . . . . . . . . . . 11 4.5. Encapsulation and Metadata Support
5. Management Plane Overview . . . . . . . . . . . . . . . . . . 12 5. Management Plane Overview
5.1. DetNet Operations, Administration and Maintenance 5.1. DetNet Operations, Administration, and Maintenance (OAM)
(OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. OAM for Performance Monitoring (PM)
5.1.1. OAM for Performance Monitoring (PM) . . . . . . . . . 12 5.1.2. OAM for Connectivity and Fault Management (CFM)
5.1.2. OAM for Connectivity and Fault/Defect Management 6. Multi-Domain Aspects
(CFM) . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations
6. Multidomain Aspects . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Contributors
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
DetNet (Deterministic Networking) provides the ability to carry Deterministic Networking (DetNet) provides the ability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [RFC8655]. concepts of DetNet can be found in [RFC8655].
The DetNet data plane is defined in a set of documents that are The DetNet data plane is defined in a set of documents that are
anchored by the DetNet Data Plane Framework [RFC8938] (and the anchored by the DetNet data plane framework [RFC8938] (as well as the
associated DetNet MPLS defined in [RFC8964] and DetNet IP defined in associated DetNet MPLS defined in [RFC8964], the DetNet IP defined in
[RFC8939] and other data plane specifications defined in [RFC9023], [RFC8939], and other data plane specifications defined in [RFC9023],
[RFC9024], [RFC9025], [RFC9037] and [RFC9056]). [RFC9024], [RFC9025], [RFC9037], and [RFC9056]).
Note that in the DetNet overall architecture, the controller plane Note that in the DetNet overall architecture, the controller plane
includes what are more traditionally considered separate control and includes what are more traditionally considered separate control and
management planes (see section 4.4.2 of [RFC8655]). Traditionally, management planes (see Section 4.4.2 of [RFC8655]). Traditionally,
the management plane is primarily involved with fault management, the management plane is primarily involved with fault management,
configuration management and performance management (sometimes configuration management, and performance management (sometimes
accounting management and security management is also considered in accounting management and security management are also considered in
the management plane (see section 4.2 of [RFC6632]), but not in the the management plane (Section 4.2 of [RFC6632]) but they are out of
scope of this document), while the control plane is primarily the scope of this document). At the same time, the control plane is
responsible for the instantiation and maintenance of flows, MPLS primarily responsible for the instantiation and maintenance of flows,
label allocation and distribution, and active in-band or out-of-band MPLS label allocation and distribution, and active in-band or out-of-
signaling to support DetNet functions. In the DetNet architecture, band signaling to support DetNet functions. In the DetNet
all of this functionality is combined into a single controller plane. architecture, all of this functionality is combined into a single
See Section 4.4.2 of [RFC8655] and the aggregation of control and controller plane. See Section 4.4.2 of [RFC8655] and the aggregation
management planes in [RFC7426] for further details. of control and management planes in [RFC7426] for further details.
While the DetNet Architecture and Data Plane documents are primarily While the DetNet architecture and data plane documents are primarily
concerned with data plane operations, they do contain some concerned with data plane operations, they do contain some
requirements, and considerations for functions that would be required requirements and considerations for functions that would be required
in order to automate DetNet service provisioning and monitoring via a in order to automate DetNet service provisioning and monitoring via a
DetNet controller plane (e.g., section 4 of [RFC8938]). The purpose DetNet Controller Plane (e.g., see Section 4 of [RFC8938]). The
of this document is to take these requirements and considerations purpose of this document is to take these requirements and
into a single document and extend and discuss how various possible considerations into a single document and extend and discuss how
DetNet controller plane architectures could be used to satisfy these various possible DetNet Controller Plane architectures could be used
requirements, while not providing the protocol details for a DetNet to satisfy these requirements, while not providing the protocol
controller plane solution. Such controller plane protocol solutions details for a DetNet Controller Plane solution. Such controller
will be the subject of subsequent documents. Therefore, this plane protocol solutions will be the subject of subsequent documents.
document should be considered as the authoritative reference to be Therefore, this document should be considered as the authoritative
considered if/when protocol work on the DetNet controller plane reference to be considered if/when protocol work on the DetNet
starts. Controller Plane starts.
2. DetNet Controller Plane Requirements 2. DetNet Controller Plane Requirements
Other DetNet documents, including [RFC8655] , [RFC8938], [RFC9551] Other DetNet documents, including [RFC8655], [RFC8938], [RFC9551],
and [RFC9055], among others, contain requirements for the Controller and [RFC9055], among others, contain requirements for the controller
Plane. For convenience, these requirements have been compiled here. plane. For convenience, these requirements have been compiled here.
These requirements have been organized into 3 groups requirements These requirements have been organized into three groups: 1)
primarily applicable to the control plane, requirements primarily requirements primarily applicable to the control plane, 2)
applicable to the management plane and requirements applicable to requirements primarily applicable to the management plane, and 3)
both planes. In addition, security requirements for the DetNet requirements applicable to both planes. In addition, security
Controller Plane have been discussed in [RFC9055], and a summary of requirements for the DetNet Controller Plane have been discussed in
those requirements is provided in Section 2.4. For the sake of [RFC9055], and a summary of those requirements is provided in
clarity, when applicable, the document where the requirements Section 2.4. For the sake of clarity, when applicable, the document
originally appears is referenced. in which the requirements originally appear is referenced.
2.1. DetNet Control Plane Requirements 2.1. DetNet Control Plane Requirements
The primary requirements for the DetNet Control Plane include: The primary requirements for the DetNet Control Plane are as follows:
* Support the dynamic instantiation, modification, and deletion of * Support the dynamic instantiation, modification, and deletion of
DetNet flows. This may include some or all of explicit path DetNet flows. This may include some or all of explicit path
determination, link bandwidth reservations, restricting flows to determination, link bandwidth reservations, restriction of flows
specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) to specific links (e.g., IEEE 802.1 Time-Sensitive Networking
links), node buffer and other resource reservations, specification (TSN) links), node buffer and other resource reservations,
of required queuing disciplines along the path, ability to manage specification of required queuing disciplines along the path, the
bidirectional flows, etc., as needed for a flow [RFC8938]. ability to manage bidirectional flows, etc., as needed for a flow
[RFC8938].
* Support DetNet flow aggregation and de-aggregation via the ability * Support DetNet flow aggregation and de-aggregation via the ability
to dynamically create and delete flow aggregates (FAs), and be to dynamically create and delete flow aggregates (FAs) and modify
able to modify existing FAs by adding or deleting participating existing FAs by adding or deleting participating flows [RFC8938].
flows [RFC8938].
* Allow flow instantiation requests to originate in an end * Allow flow instantiation requests to originate in an end
application (via an Application Programming Interface (API), via application (via an Application Programming Interface (API) via
static provisioning, or via a dynamic control plane, such as an static provisioning or via a dynamic control plane, such as a
SDN (Software-Defined Networking) controller or distributed Software-Defined Networking (SDN) controller or distributed
signaling protocols. See Section 3 for further discussion of signaling protocols). See Section 3 for further discussion of
these options. these options.
* In the case of the DetNet MPLS data plane, manage DetNet Service * Manage, in the case of the DetNet MPLS data plane, DetNet Service
Label (S-Label), Forwarding Label (F-Label), and Aggregation Label Label (S-Label), Forwarding Label (F-Label), and Aggregation Label
(A-Label) [RFC8964] allocation and distribution [RFC8938]. (A-Label) [RFC8964] allocation and distribution [RFC8938].
* Also in the case of the DetNet MPLS data plane, support the DetNet * Support, also in the case of the DetNet MPLS data plane, the
service sub-layer, which provides DetNet service functions such as DetNet service sub-layer, which provides DetNet service functions,
protection and reordering through the use of packet replication, such as protection and reordering through the use of Packet
elimination, and ordering functions (PREOF) [RFC8655]. Replication, Elimination, and Ordering Functions (PREOF)
[RFC8655].
* Support queue control techniques defined in Section 4.5 of * Support the queue control techniques defined in [RFC8655],
[RFC8655] and [RFC9320] that require time synchronization among Section 4.5 and [RFC9320] that require time synchronization among
network data plane nodes. the network data plane nodes.
* Advertise static and dynamic node and link characteristics such as * Advertise static and dynamic node and link characteristics, such
capabilities and adjacencies to other network nodes (for dynamic as capabilities and adjacencies to other network nodes (for
signaling approaches) or to network controllers (for centralized dynamic signaling approaches) or to network controllers (for
approaches) [RFC8938]. centralized approaches) [RFC8938].
* Scale to handle the number of DetNet flows expected in a domain * Scale to handle the number of DetNet flows expected in a domain
(which may require per-flow signaling or provisioning) [RFC8938]. (which may require per-flow signaling or provisioning) [RFC8938].
* Provision flow identification information at each of the nodes * Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the along the path. Flow identification may differ depending on the
location in the network and the DetNet functionality (e.g., location in the network and the DetNet functionality (e.g.,
transit node vs. relay node) [RFC8938]. transit node vs. relay node) [RFC8938].
2.2. DetNet Management Plane Requirements 2.2. DetNet Management Plane Requirements
The primary requirements of the DetNet management plane are that it The primary requirements for the DetNet management plane are as
must be able to: follows:
* Monitor the performance of DetNet flows and nodes to ensure that * Monitor the performance of DetNet flows and nodes to ensure that
they are meeting required objectives, both proactively and on- they are meeting required objectives, both proactively and on
demand [RFC9551]. demand [RFC9551].
* Support DetNet flow continuity check and connectivity verification * Support DetNet flow continuity check and connectivity verification
functions [RFC9551]. functions [RFC9551].
* Support testing and monitoring of packet replication, duplicate * Support testing and monitoring of packet replication, duplicate
elimination, and packet ordering functionality in the DetNet elimination, and packet ordering functionality in the DetNet
domain [RFC9551]. domain [RFC9551].
2.3. Requirements For Both Planes 2.3. Requirements for Both Planes
The following requirements apply to both the DetNet control and The following requirements apply to both the DetNet control and
management planes: management planes:
* Operate in a converged network domain that contains both DetNet * Operate in a converged network domain that contains both DetNet
and non-DetNet flows [RFC8655]. and non-DetNet flows [RFC8655].
* Adapt to DetNet domain topology changes such as links or nodes * Adapt to DetNet domain topology changes such as link or node
failures (fault recovery/restoration), additions and removals failures (fault recovery/restoration), additions, and removals
[RFC8655]. [RFC8655].
In addition to the above, the DetNet controller Plane should also In addition to the above, the DetNet Controller Plane should also
satisfy security requirements derived from [RFC9055], which defines satisfy security requirements derived from [RFC9055], which defines
the security framework for DetNet. The following requirements are the security framework for DetNet. The following requirements are
especially relevant: especially relevant:
* Integrity and authenticity of control/signaling packets: The * Integrity and authenticity of control/signaling packets: The
controller plane should ensure that signaling and control messages controller plane should ensure that signaling and control messages
cannot be modified or injected by unauthorized entities and cannot be modified or injected by unauthorized entities and should
prevent spoofing and segmentation attacks. prevent spoofing and segmentation attacks.
* Protection against controller compromise: Mechanisms should exist * Protection against controller compromise: Mechanisms should exist
to verify the legitimacy of controllers and prevent unauthorized to verify the legitimacy of controllers and to prevent
components from impersonating them. unauthorized components from impersonating them.
* System-wide security design: The architecture must account for the * System-wide security design: The architecture must account for the
possibility of compromised nodes or controllers, ensuring possibility of compromised nodes or controllers, ensuring
resilience so that the failure or subversion of a single component resilience so that the failure or subversion of a single component
does not cause catastrophic impact. does not cause catastrophic impact.
* Timely delivery of control plane messages: The controller plane * Timely delivery of control plane messages: The controller plane
should ensure control and signaling messages are delivered without should ensure that control and signaling messages are delivered
undue delay to prevent disruption of DetNet services without without undue delay to prevent disruption of DetNet services
resource leakage. without resource leakage.
3. DetNet Control Plane Architecture 3. DetNet Control Plane Architecture
As noted in the Introduction, the DetNet control plane is responsible As noted in the Introduction, the DetNet Control Plane is responsible
for the instantiation and maintenance of flows, allocation and for the instantiation and maintenance of flows, the allocation and
distribution of flow related information (e.g., MPLS label), and distribution of flow-related information (e.g., MPLS label), and
active in-band or out-of-band information distribution to support active in-band or out-of-band information distribution to support
these functions. these functions.
The following sections define three types of DetNet control plane The following sections define three types of DetNet Control Plane
architectures: a fully distributed control plane utilizing dynamic architectures: 1) a fully distributed control plane utilizing dynamic
signaling protocols, a fully centralized SDN-like control plane, and signaling protocols, 2) a fully centralized SDN-like control plane,
a hybrid control plane containing both distributed protocols and and 3) a hybrid control plane containing both distributed protocols
centralized controlling. This document describes the various and centralized controlling. This document describes the various
information exchanges between entities in the network for each type information exchanges between entities in the network for each type
of these architectures and the corresponding advantages and of these architectures and the corresponding advantages and
disadvantages. disadvantages.
In each of the following sections, there are examples to illustrate The examples in the following sections illustrate possible mechanisms
possible mechanisms that could be used in each type of the that could be used in each type of the architectures. They are not
architectures. They are not meant to be exhaustive or to preclude meant to be exhaustive or to preclude any other possible mechanism
any other possible mechanism that could be used in place of those that could be used in place of those used in the examples.
used in the examples.
3.1. Distributed Control Plane and Signaling Protocols 3.1. Distributed Control Plane and Signaling Protocols
In a fully distributed configuration model, User-to-Network Interface In a fully distributed configuration model, the User-Network
(UNI) information is transmitted over a DetNet UNI protocol from the Interface (UNI) information is transmitted over a DetNet UNI protocol
user side to the network side. Then UNI and network configuration from the user side to the network side. Then, the UNI and network
information propagate in the network via distributed control plane configuration information propagates in the network via distributed
signaling protocols. Such a DetNet UNI protocol is not necessary control plane signaling protocols. Such a DetNet UNI protocol is not
when the End-systems are DetNet capable. necessary when the end systems are DetNet capable.
Taking an RSVP-TE [RFC3209] MPLS network as an example, where end Taking an RSVP-TE [RFC3209] MPLS network as an example, where end
systems are not part of the DetNet domain: systems are not part of the DetNet domain:
1. Network nodes collect topology information and DetNet 1. Network nodes collect topology information and DetNet
capabilities of the network nodes through IGP; capabilities of the network nodes through IGP.
2. The ingress edge node receives a flow establishment request from 2. The ingress edge node receives a flow establishment request from
the UNI and calculates one or more valid path(s); the UNI and calculates one or more valid paths.
3. The ingress node sends a PATH message with an explicit route 3. The ingress node sends a PATH message with an explicit route
through RSVP-TE. After receiving the PATH message, the egress through RSVP-TE. After receiving the PATH message, the egress
edge node sends a RESV message with the distributed label and edge node sends a RESV message with the distributed label and
resource reservation request. resource reservation request.
In this example, both the IGP and RSVP-TE may require extensions for In this example, both the IGP and RSVP-TE may require extensions for
DetNet. DetNet.
3.2. SDN/Fully Centralized Control Plane 3.2. SDN/Fully Centralized Control Plane
In the fully SDN/centralized configuration model, flow/UNI In the fully SDN/centralized configuration model, flow/UNI
information is transmitted from a centralized user controller or from information is transmitted either from a centralized user controller
applications via an API/ northbound interface to a centralized or from applications via an API/northbound interface to a centralized
controller. Network node configurations for DetNet flows are controller. Network node configurations for DetNet flows are
performed by the controller using a protocol such as NETCONF performed by the controller using a protocol such as NETCONF
[RFC6241]/YANG [RFC6020][RFC7950] DetNet YANG [RFC9633] or PCE-CC [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], or PCE-CC
[RFC8283]. [RFC8283].
Take the following case as an example: Take the following case as an example:
1. A centralized controller collects topology information and DetNet 1. A centralized controller collects topology information and DetNet
capabilities of the network nodes via NETCONF/YANG; capabilities of the network nodes via NETCONF/YANG.
2. The controller receives a flow establishment request from a UNI 2. The controller receives a flow establishment request from a UNI
and calculates one or more valid path(s) through the network; and calculates one or more valid paths through the network.
3. The controller chooses the optimal path and configures the 3. The controller chooses the optimal path and configures the
devices along that path for DetNet flow transmission via PCE-CC. devices along that path for DetNet flow transmission via PCE-CC.
Protocols in the above example may require extensions for DetNet. The protocols in the above example may require extensions for DetNet.
3.3. Hybrid Control Plane (partly centralized, partly distributed) 3.3. Hybrid Control Plane (Partly Centralized and Partly Distributed)
In the hybrid model, controller and control plane protocols work In the hybrid model, the controller and control plane protocols work
together to provide DetNet services, and there are a number of together to provide DetNet services, and there are a number of
possible combinations. possible combinations.
In the following case, RSVP-TE and controller are used together: In the following case, the RSVP-TE and controller are used together:
1. A controller collects topology information and DetNet 1. A controller collects topology information and DetNet
capabilities of the network nodes via an IGP and/or BGP-LS capabilities of the network nodes via an IGP and/or the Border
[RFC9552]; Gateway Protocol - Link State (BGP-LS) [RFC9552].
2. A controller receives a flow establishment request through API 2. A controller receives a flow establishment request through API
and calculates one or more valid path(s) through the network; and calculates one or more valid paths through the network.
3. Based on the calculation result, the controller distributes flow 3. Based on the calculation result, the controller distributes flow
path information to the ingress edge node and configures network path information to the ingress edge node and configures network
nodes along the path with necessary DetNet information (e.g., for nodes along the path with necessary DetNet information (e.g., for
replication/duplicate elimination) replication/duplicate elimination).
4. Using RSVP-TE, the ingress edge node sends a PATH message with an 4. Using RSVP-TE, the ingress edge node sends a PATH message with an
explicit route. After receiving the PATH message, the egress explicit route. After receiving the PATH message, the egress
edge node sends a RESV message with the distributed label and edge node sends a RESV message with the distributed label and
resource reservation request. resource reservation request.
There are many other variations that could be included in a hybrid There are many other variations that could be included in a hybrid
control plane. The requested DetNet extensions for a protocol in control plane. The requested DetNet extensions for a protocol in
each possible case is for future work. each possible case is for future work.
4. DetNet Control Plane for DetNet Mechanisms 4. DetNet Control Plane for DetNet Mechanisms
This section discusses the requested control plane features for This section discusses the requested control plane features for
DetNet mechanisms as defined in [RFC8655], including explicit path, DetNet mechanisms as defined in [RFC8655], including PREOF.
resource reservation, service protection (PREOF). Different DetNet Different DetNet services may implement any or all of these based on
services may implement any or all of these based on the requirements. the requirements.
4.1. Explicit Paths 4.1. Explicit Paths
Explicit paths are required in DetNet to provide a stable forwarding Explicit paths are required in DetNet to provide a stable forwarding
service and guarantee that DetNet service is not impacted when the service and guarantee that the DetNet service is not impacted when
network topology changes. The following features are necessary in the network topology changes. The following features are necessary
the control plane to implement explicit paths in DetNet: in the control plane to implement explicit paths in DetNet:
* Path computation: DetNet explicit paths need to meet the SLA * Path computation: DetNet explicit paths need to meet the Service
(Service Level Agreement) requirements of the application, which Level Agreement (SLA) requirements of the application, which
include bandwidth, maximum end- to-end delay, maximum end-to-end include bandwidth, maximum end-to-end delay, maximum end-to-end
delay variation, maximum loss ratio, etc. In a distributed delay variation, maximum loss ratio, etc. In a distributed
network system, an IGP with CSPF (Constrained Shortest Path First) network system, an IGP with Constrained Shortest Path First (CSPF)
may be used to compute a set of feasible paths for a DetNet may be used to compute a set of feasible paths for a DetNet
service. In a centralized network system, the controller can service. In a centralized network system, the controller can
compute paths satisfying the requirements of DetNet based on the compute paths satisfying the requirements of DetNet based on the
network information collected from the DetNet domain. network information collected from the DetNet domain.
* Path establishment: The computed path for the DetNet service has * Path establishment: The computed path for the DetNet service has
to be sent/configured/signaled to the network device, so the to be sent/configured/signaled to the network device so that the
corresponding DetNet flow could pass through the network domain corresponding DetNet flow can pass through the network domain
following the specified path. following the specified path.
4.2. Resource Reservation 4.2. Resource Reservation
DetNet flows are supposed to be protected from congestion, so DetNet flows are supposed to be protected from congestion, so
sufficient resource reservation for a DetNet service could protect a sufficient resource reservation for a DetNet service could protect a
service from congestion. There are multiple types of resources in service from congestion. There are multiple types of resources in
the network that could be allocated to DetNet flows, e.g., packet the network that could be allocated to DetNet flows, e.g., packet
processing resources, buffer resources, and bandwidth of the output processing resources, buffer resources, and the bandwidth of the
port. The network resource requested by a specified DetNet service output port. The network resource requested by a specified DetNet
is determined by the SLA requirements and network capability. service is determined by the SLA requirements and network capability.
* Resource Allocation: Port bandwidth is one of the basic attributes * Resource Allocation: Port bandwidth is one of the basic attributes
of a network device which is easy to obtain or calculate. In of a network device that is easy to obtain or calculate. In
current traffic engineering implementations, network resource current traffic engineering implementations, network resource
allocation is synonymous with bandwidth allocation. A DetNet flow allocation is synonymous with bandwidth allocation. A DetNet flow
is characterized with a traffic specification as defined in is characterized by a traffic specification, as defined in
[RFC9016], including attributes such as Interval, Maximum Packets [RFC9016], including attributes such as Interval,
Per Interval, and Maximum Payload Size. The traffic specification MaxPacketsPerInterval, and MaxPayloadSize. The traffic
describes the worst case, rather than the average case, for the specification describes the worst case, rather than the average
traffic, to ensure that sufficient bandwidth and buffering case, for the traffic to ensure that sufficient bandwidth and
resources are reserved to satisfy the traffic specification. buffering resources are reserved to satisfy the traffic
However, in the case of DetNet, resource allocation is more than specification. However, in the case of DetNet, resource
simple bandwidth reservation. For example, allocation of buffers allocation is more than simple bandwidth reservation. For
and required queuing disciplines during forwarding may be required example, allocation of buffers and required queuing disciplines
as well. Furthermore, resources must be ensured to execute DetNet during forwarding may be required as well. Furthermore, resources
service sub-layer functions on the node, such as protection and must be ensured to execute DetNet service sub-layer functions on
reordering through the use of packet replication, duplicate the node, such as protection and reordering through the use of
elimination, and packet ordering functions (PREOF). PREOF.
* Device configuration with or without flow discrimination: The * Device configuration with or without flow discrimination: The
resource allocation can be guaranteed by device configuration. resource allocation can be guaranteed by device configuration.
For example, an output port bandwidth reservation can be For example, an output port bandwidth reservation can be
configured as a parameter of queue management and the port configured as a parameter of queue management and the port
scheduling algorithm. When DetNet flows are aggregated, a group scheduling algorithm. When DetNet flows are aggregated, a group
of DetNet flows share the allocated resource in the network of DetNet flows share the allocated resource in the network
device. When the DetNet flows are treated independently, the device. When the DetNet flows are treated independently, the
device should maintain a mapping relationship between a DetNet device should maintain a mapping relationship between a DetNet
flow and its corresponding resources. flow and its corresponding resources.
4.3. PREOF Support 4.3. PREOF Support
DetNet path redundancy is supported via packet replication, duplicate DetNet path redundancy is supported via Packet Replication,
elimination, and packet ordering functions (PREOF). A DetNet flow is Elimination, and Ordering Functions (PREOF). A DetNet flow is
replicated and forwarded by multiple networks paths to avoid packet replicated and forwarded by multiple networks paths to avoid packet
loss caused by device or link failures. In general, current control loss caused by device or link failures. In general, current control
plane mechanisms that can be used to establish an explicit path, plane mechanisms that can be used to establish an explicit path,
whether distributed or centralized, support point-to-point (P2P) and whether distributed or centralized, support point-to-point (P2P) and
point-to-multipoint (P2MP) path establishment. PREOF requires the point-to-multipoint (P2MP) path establishment. PREOF requires the
ability to compute and establish a set of multiple paths (e.g., ability to compute and establish a set of multiple paths (e.g.,
multiple LSP segments in an MPLS network) from the point(s) of packet multiple Label Switched Path (LSP) segments in an MPLS network) from
replication to the point(s) of packet merging and ordering. Mapping the point(s) of packet replication to the point(s) of packet merging
of DetNet (member) flows to explicit path segments has to be ensured and ordering. Mapping of DetNet (member) flows to explicit path
as well. Protocol extensions will be required to support these new segments has to be ensured as well. Protocol extensions will be
features. Terminology will also be required to refer to this required to support these new features. Terminology will also be
coordinated set of path segments (such as an 'LSP graph' in the case required to refer to this coordinated set of path segments (such as
of the DetNet MPLS data plane). an "LSP graph" in the case of the DetNet MPLS data plane).
4.4. Data Plane specific considerations 4.4. Data-Plane-Specific Considerations
4.4.1. DetNet in an MPLS Domain 4.4.1. DetNet in an MPLS Domain
For the purposes of this document, 'traditional MPLS' is defined as For the purposes of this document, "traditional MPLS" is defined as
MPLS without the use of segment routing (see Section 4.4.3 for a MPLS without the use of segment routing (see Section 4.4.3 for a
discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. discussion of MPLS with segment routing) or MPLS Transport Profile
(MPLS-TP) [RFC5960].
In traditional MPLS domains, a dynamic control plane using In traditional MPLS domains, a dynamic control plane using
distributed signaling protocols is typically used for the distributed signaling protocols is typically used for the
distribution of MPLS labels used for forwarding MPLS packets. The distribution of MPLS labels used for forwarding MPLS packets. The
dynamic signaling protocols most commonly used for label distribution dynamic signaling protocols most commonly used for label distribution
are LDP [RFC5036], RSVP-TE[RFC4875], and BGP [RFC8277] (which enables are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which
BGP/MPLS-based Layer 3 VPNs [RFC4384] Layer 2 VPNs [RFC4664] and EVPN enables BGP/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs
[RFC7432]). [RFC4664], and EVPNs [RFC7432]).
Any of these protocols could be used to distribute DetNet Service Any of these protocols could be used to distribute DetNet Service
Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As
discussed in [RFC8938], S-Labels are similar to other MPLS service discussed in [RFC8938], S-Labels are similar to other MPLS service
labels, such as pseudowire, L3 VPN, and L2 VPN labels, and could be labels, such as pseudowire and L3 VPN and L2 VPN labels, and could be
distributed in a similar manner, such as through the use of targeted distributed in a similar manner, such as through the use of targeted
LDP or BGP. If these were to be used for DetNet, they would require LDP or BGP. If these were to be used for DetNet, they would require
extensions to support DetNet-specific features such as PREOF, extensions to support DetNet-specific features, such as PREOF,
aggregation (A-Labels), node resource allocation, and queue aggregation (A-Labels), node resource allocation, and queue
placement. placement.
4.4.2. DetNet in an IP Domain 4.4.2. DetNet in an IP Domain
For the purposes of this document, 'traditional IP' is defined as IP For the purposes of this document, "traditional IP" is defined as IP
without the use of segment routing (see Section 4.4.3 for a without the use of segment routing (see Section 4.4.3 for a
discussion of IP with segment routing). This section will discuss discussion of IP with segment routing). This section will discuss
possible protocol extensions to existing IP routing protocols. It possible protocol extensions to existing IP routing protocols. It
should be noted that a DetNet IP data plane [RFC8939] is simpler than should be noted that a DetNet IP data plane [RFC8939] is simpler than
a DetNet MPLS data plane [RFC8964], and doesn't support PREOF, so a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only
only one path per flow or flow aggregate is required. one path per flow or flow aggregate is required.
4.4.3. DetNet in a Segment Routing Domain 4.4.3. DetNet in a Segment Routing Domain
Segment Routing [RFC8402] is a scalable approach to building network Segment Routing [RFC8402] is a scalable approach to building network
domains that provides explicit routing via source routing encoded in domains that provides explicit routing via source routing encoded in
packet headers and it is combined with centralized network control to packet headers, and it is combined with centralized network control
compute paths through the network. Forwarding paths are distributed to compute paths through the network. Forwarding paths are
with associated policy to network edge nodes for use in packet distributed with associated policies to network edge nodes for use in
headers. Segment Routing reduces the amount of network signaling packet headers. Segment Routing reduces the amount of network
associated with distributed signaling protocols such as RSVP-TE, and signaling associated with distributed signaling protocols, such as
also reduces the amount of state in core nodes compared with that RSVP-TE, and also reduces the amount of state in core nodes compared
required for traditional MPLS and IP routing, as the state is now in with that required for traditional MPLS and IP routing, as the state
the packets rather than in the routers. This could be useful for is now in the packets rather than in the routers. This could be
DetNet, where a very large number of flows through a network domain useful for DetNet, where a very large number of flows through a
are expected, which would otherwise require the instantiation of network domain are expected, which would otherwise require the
state for each flow traversing each node in the network. instantiation of state for each flow traversing each node in the
network.
Note that the DetNet MPLS and IP data planes described in [RFC8964] Note that the DetNet MPLS and IP data planes described in [RFC8964]
and [RFC8939] were constructed to be compatible with both types of and [RFC8939] were constructed to be compatible with both types of
segment routing, SR-MPLS [RFC8660] and SRv6 [RFC8754] [RFC8986]. segment routing: Segment Routing over MPLS (SR-MPLS) [RFC8660] and
Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986].
4.5. Encapsulation and metadata support 4.5. Encapsulation and Metadata Support
To effectively manage DetNet flows, the controller plane will need To effectively manage DetNet flows, the controller plane will need to
have a clear understanding of the encapsulation and metadata have a clear understanding of the encapsulation and metadata
capabilities of the underlying network nodes. This will require a capabilities of the underlying network nodes. This will require a
control mechanism that can discover, configure, and manage these control mechanism that can discover, configure, and manage these
parameters for each flow. parameters for each flow.
The controller plane needs to understand and manage the encapsulation The controller plane needs to understand and manage the encapsulation
and metadata capabilities of the network nodes to provision DetNet and metadata capabilities of the network nodes to provision DetNet
flows effectively. This process might need a discovery phase, in flows effectively. This process might need a discovery phase in
which the controller discovers which encapsulation types (e.g., MPLS, which the controller discovers which encapsulation types (e.g., MPLS,
IP) and metadata schemes (e.g., sequencing, timestamping) each node IP) and metadata schemes (e.g., sequencing, timestamping) that each
supports. After discovery, the controller might instruct nodes on node supports. After discovery, the controller might instruct nodes
the specific encapsulation and companion metadata to apply for a on the specific encapsulation and companion metadata to apply for a
given flow. This ensures that DetNet packets are handled given flow. This ensures that DetNet packets are handled
consistently across the network. For example, the controller might consistently across the network. For example, the controller might
instruct a node to use an MPLS header and add a sequence number for a instruct a node to use an MPLS header and add a sequence number for a
particular flow. particular flow.
5. Management Plane Overview 5. Management Plane Overview
The management plane includes the ability to statically provision The management plane includes the ability to statically provision
network nodes and to use OAM to monitor DetNet performance and detect network nodes and to use Operations, Administration, and Maintenance
outages or other issues at the DetNet layer. (OAM) to monitor DetNet performance and to detect outages or other
issues at the DetNet layer.
5.1. DetNet Operations, Administration and Maintenance (OAM) 5.1. DetNet Operations, Administration, and Maintenance (OAM)
This document covers the general considerations for OAM. This document covers the general considerations for OAM.
5.1.1. OAM for Performance Monitoring (PM) 5.1.1. OAM for Performance Monitoring (PM)
5.1.1.1. Active PM 5.1.1.1. Active PM
Active PM is performed by injecting OAM packets into the network to Active PM is performed by injecting OAM packets into the network to
estimate the performance of the network by measuring the performance estimate the performance of the network and by then measuring the
of the OAM packets. Adding extra traffic can affect the delay and performance of those OAM packets. Adding extra traffic can affect
throughput performance of the network, and for this reason active PM the delay and throughput performance of the network, and for this
is not recommended for use in operational DetNet domains. However, reason, Active PM is not recommended for use in operational DetNet
it is a useful test tool when commissioning a new network or during domains. However, it is a useful test tool when commissioning a new
troubleshooting. network or during troubleshooting.
5.1.1.2. Passive PM 5.1.1.2. Passive PM
Passive PM, such as IOAM [RFC9197], monitors the actual service Passive PM, such as In Situ Operations, Administration, and
traffic in a network domain in order to measure its performance Maintenance (IOAM) [RFC9197], monitors the actual service traffic in
without having a detrimental effect on the network. As compared to a network domain in order to measure its performance without having a
Active PM, Passive PM is much preferred for use in DetNet domains. detrimental effect on the network. As compared to Active PM, Passive
PM is much preferred for use in DetNet domains.
5.1.2. OAM for Connectivity and Fault/Defect Management (CFM) 5.1.2. OAM for Connectivity and Fault Management (CFM)
The detailed requirements for connectivity and fault/defect detection The detailed requirements for CFM in a DetNet IP domain and a DetNet
and management in DetNet IP domain and DetNet MPLS domain are defined MPLS domain are defined in [RFC9551], [RFC9634], and [RFC9546],
in [RFC9551] [RFC9634] and [RFC9546], respectively. respectively.
6. Multidomain Aspects 6. Multi-Domain Aspects
When there are multiple domains involved, one or multiple controller When there are multiple domains involved, one or multiple Controller
plane functions (CPF) would have to collaborate to implement the Plane Functions (CPFs) would have to collaborate to implement the
requests received from the flow management entity (FME, as defined in requests received from the Flow Management Entity (FME) [RFC8655] as
[RFC8655]) as per-flow, per-hop behaviors installed in the DetNet per-flow, per-hop behaviors installed in the DetNet nodes for each
nodes for each individual flow. Adding multi-domain support might individual flow. Adding multi-domain support might require some
require some support at the CPF. For example, CPFs of different support at the CPF. For example, CPFs of different domains, e.g.,
domains, e.g., PCEs need to discover each other, authenticate and PCEs, need to discover each other and then authenticate and negotiate
negotiate per-hop behaviors. Furthermore, in the case of wireless per-hop behaviors. Furthermore, in the case of wireless domains,
domains, the per-domain RAW [I-D.ietf-raw-architecture] specific per-domain functions specific to Reliable and Available Wireless
functions like the PLR (Point of Local Repair)s have to be also (RAW) [RAW-ARCH], such as Point of Local Repairs (PLRs), have to also
considered, e.g., in addition to the PCEs. Depending on the multi- be considered, e.g., in addition to the PCEs. Depending on the
domain support provided by the application plane, the controller multi-domain support provided by the application plane, the
plane might be relieved from some responsibilities (e.g., if the controller plane might be relieved from some responsibilities (e.g.,
application plane takes care of splitting what needs to be provided if the application plane takes care of splitting what needs to be
by each domain). provided by each domain).
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations 8. Security Considerations
This document provides a framework for the DetNet controller plane, This document provides a framework for the DetNet Controller Plane
and does not include any protocol specifications. Any future and does not include any protocol specifications. Any future
specification that is defined to support the DetNet controller plane specification that is defined to support the DetNet Controller Plane
is expected to include appropriate security considerations. For is expected to include the appropriate security considerations. For
overall security considerations of DetNet see [RFC8655] and [RFC9055] overall security considerations of DetNet, see [RFC8655] and
[RFC9055].
9. Acknowledgments
Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their
review comments.
Authors would also like to thank Deb Cooley, Mike Bishop, Mohamed
Boucadair, Gorry Fairhurst and Dave Thaler for their comments during
the different directorate and IESG reviews.
10. Contributors
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>. <https://www.rfc-editor.org/info/rfc8938>.
skipping to change at page 14, line 37 skipping to change at line 612
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>. 2021, <https://www.rfc-editor.org/info/rfc9055>.
[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, [RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos,
CJ., Varga, B., and J. Farkas, "Framework of Operations, CJ., Varga, B., and J. Farkas, "Framework of Operations,
Administration, and Maintenance (OAM) for Deterministic Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551, Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551,
March 2024, <https://www.rfc-editor.org/info/rfc9551>. March 2024, <https://www.rfc-editor.org/info/rfc9551>.
11.2. Informative References 9.2. Informative References
[I-D.ietf-raw-architecture] [RAW-ARCH] Thubert, P., Ed., "Reliable and Available Wireless
Thubert, P., "Reliable and Available Wireless
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-raw-architecture-30, 25 July 2025, ietf-raw-architecture-30, 25 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-
architecture-30>. architecture-30>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 18, line 27 skipping to change at line 782
"Deterministic Networking (DetNet) YANG Data Model", "Deterministic Networking (DetNet) YANG Data Model",
RFC 9633, DOI 10.17487/RFC9633, October 2024, RFC 9633, DOI 10.17487/RFC9633, October 2024,
<https://www.rfc-editor.org/info/rfc9633>. <https://www.rfc-editor.org/info/rfc9633>.
[RFC9634] Mirsky, G., Chen, M., and D. Black, "Operations, [RFC9634] Mirsky, G., Chen, M., and D. Black, "Operations,
Administration, and Maintenance (OAM) for Deterministic Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the IP Data Plane", RFC 9634, Networking (DetNet) with the IP Data Plane", RFC 9634,
DOI 10.17487/RFC9634, October 2024, DOI 10.17487/RFC9634, October 2024,
<https://www.rfc-editor.org/info/rfc9634>. <https://www.rfc-editor.org/info/rfc9634>.
Acknowledgments
Thanks to Jim Guichard, Donald Eastlake 3rd, and Stewart Bryant for
their reviews and comments.
The authors would also like to thank Deb Cooley, Mike Bishop, Mohamed
Boucadair, Gorry Fairhurst, and Dave Thaler for their comments during
the different directorate and IESG reviews.
Contributors
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Authors' Addresses Authors' Addresses
Andrew G. Malis Andrew G. Malis
Independent Independent
Email: agmalis@gmail.com Email: agmalis@gmail.com
Xuesong Geng Xuesong Geng (editor)
Huawei Huawei
Email: gengxuesong@huawei.com Email: gengxuesong@huawei.com
Mach (Guoyi) Chen Mach (Guoyi)Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Balazs Varga Balazs Varga
Ericsson Ericsson
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
28911 Leganes, Madrid 28911 Leganes, Madrid
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
 End of changes. 94 change blocks. 
306 lines changed or deleted 305 lines changed or added

This html diff was produced by rfcdiff 1.48.