3. DetNet Control Plane Architecture

Dieser Abschnitt bewahrt den RFC-Text fuer das DetNet Controller Plane framework, einschliesslich requirements, control-plane architectures, PREOF, MPLS/IP/Segment Routing considerations, OAM, multi-domain behavior, IANA und security considerations.

3.  DetNet Control Plane Architecture

   As noted in the Introduction, the DetNet Control Plane is responsible
   for the instantiation and maintenance of flows, the allocation and
   distribution of flow-related information (e.g., MPLS label), and
   active in-band or out-of-band information distribution to support
   these functions.

   The following sections define three types of DetNet Control Plane
   architectures: 1) a fully distributed control plane utilizing dynamic
   signaling protocols, 2) a fully centralized SDN-like control plane,
   and 3) a hybrid control plane containing both distributed protocols
   and centralized controlling.  This document describes the various
   information exchanges between entities in the network for each type
   of these architectures and the corresponding advantages and
   disadvantages.

   The examples in the following sections illustrate possible mechanisms
   that could be used in each type of the architectures.  They are not
   meant to be exhaustive or to preclude any other possible mechanism
   that could be used in place of those used in the examples.

3.1.  Distributed Control Plane and Signaling Protocols

   In a fully distributed configuration model, the User-Network
   Interface (UNI) information is transmitted over a DetNet UNI protocol
   from the user side to the network side.  Then, the UNI and network
   configuration information propagates in the network via distributed
   control plane signaling protocols.  Such a DetNet UNI protocol is not
   necessary when the end systems are DetNet capable.

   Taking an RSVP-TE [RFC3209] MPLS network as an example, where end
   systems are not part of the DetNet domain:

   1.  Network nodes collect topology information and DetNet
       capabilities of the network nodes through IGP.

   2.  The ingress edge node receives a flow establishment request from
       the UNI and calculates one or more valid paths.

   3.  The ingress node sends a PATH message with an explicit route
       through RSVP-TE.  After receiving the PATH message, the egress
       edge node sends a RESV message with the distributed label and
       resource reservation request.

   In this example, both the IGP and RSVP-TE may require extensions for
   DetNet.

3.2.  Fully Centralized Control Plane

   In the fully centralized configuration model (e.g., using an SDN
   controller), both flow and UNI information can be transmitted from a
   centralized user controller or from other applications, via an API or
   northbound interface, to a centralized controller.  Network node
   configurations for DetNet flows are performed by the controller using
   a protocol such as NETCONF [RFC6241], YANG [RFC6020] [RFC7950],
   DetNet YANG [RFC9633], or a PCE-based central controller (PCE-CC)
   [RFC8283].

   Take the following case as an example:

   1.  A centralized controller collects topology information and DetNet
       capabilities of the network nodes via NETCONF/YANG.

   2.  The controller receives a flow establishment request from a UNI
       and calculates one or more valid paths through the network.

   3.  The controller chooses the optimal path and configures the
       devices along that path for DetNet flow transmission via PCE-CC.

   The protocols in the above example may require extensions for DetNet.

3.3.  Hybrid Control Plane (Partly Centralized and Partly Distributed)

   In the hybrid model, the controller and control plane protocols work
   together to provide DetNet services, and there are a number of
   possible combinations.

   In the following case, the RSVP-TE and controller are used together:

   1.  A controller collects topology information and DetNet
       capabilities of the network nodes via an IGP and/or the Border
       Gateway Protocol - Link State (BGP-LS) [RFC9552].

   2.  A controller receives a flow establishment request through API
       and calculates one or more valid paths through the network.

   3.  Based on the calculation result, the controller distributes flow
       path information to the ingress edge node and configures network
       nodes along the path with necessary DetNet information (e.g., for
       replication/duplicate elimination).

   4.  Using RSVP-TE, the ingress edge node sends a PATH message with an
       explicit route.  After receiving the PATH message, the egress
       edge node sends a RESV message with the distributed label and
       resource reservation request.

   There are many other variations that could be included in a hybrid
   control plane.  The requested DetNet extensions for a protocol in
   each possible case is for future work.