4. DetNet Control Plane for DetNet Mechanisms
この節では DetNet Controller Plane framework の RFC 原文を保持し, requirements, control-plane architectures, PREOF, MPLS/IP/Segment Routing considerations, OAM, multi-domain behavior, IANA, security considerations を含めます.
4. DetNet Control Plane for DetNet Mechanisms
This section discusses the requested control plane features for
DetNet mechanisms as defined in [RFC8655], including PREOF.
Different DetNet services may implement any or all of these based on
the requirements.
4.1. Explicit Paths
Explicit paths are required in DetNet to provide a stable forwarding
service and guarantee that the DetNet service is not impacted when
the network topology changes. The following features are necessary
in the control plane to implement explicit paths in DetNet:
* Path computation: DetNet explicit paths need to meet the Service
Level Agreement (SLA) requirements of the application, which
include bandwidth, maximum end-to-end delay, maximum end-to-end
delay variation, maximum loss ratio, etc. In a distributed
network system, an IGP with Constrained Shortest Path First (CSPF)
may be used to compute a set of feasible paths for a DetNet
service. In a centralized network system, the controller can
compute paths satisfying the requirements of DetNet based on the
network information collected from the DetNet domain.
* Path establishment: The computed path for the DetNet service has
to be sent/configured/signaled to the network device so that the
corresponding DetNet flow can pass through the network domain
following the specified path.
4.2. Resource Reservation
DetNet flows are supposed to be protected from congestion, so
sufficient resource reservation for a DetNet service could protect a
service from congestion. There are multiple types of resources in
the network that could be allocated to DetNet flows, e.g., packet
processing resources, buffer resources, and the bandwidth of the
output port. The network resource requested by a specified DetNet
service is determined by the SLA requirements and network capability.
* Resource Allocation: Port bandwidth is one of the basic attributes
of a network device that is easy to obtain or calculate. In
current traffic engineering implementations, network resource
allocation is synonymous with bandwidth allocation. A DetNet flow
is characterized by a traffic specification, as defined in
[RFC9016], including attributes such as Interval,
MaxPacketsPerInterval, and MaxPayloadSize. The traffic
specification describes the worst case, rather than the average
case, for the traffic to ensure that sufficient bandwidth and
buffering resources are reserved to satisfy the traffic
specification. However, in the case of DetNet, resource
allocation is more than simple bandwidth reservation. For
example, allocation of buffers and required queuing disciplines
during forwarding may be required as well. Furthermore, resources
must be ensured to execute DetNet service sub-layer functions on
the node, such as protection and reordering through the use of
PREOF.
* Device configuration with or without flow discrimination: The
resource allocation can be guaranteed by device configuration.
For example, an output port bandwidth reservation can be
configured as a parameter of queue management and the port
scheduling algorithm. When DetNet flows are aggregated, a group
of DetNet flows share the allocated resource in the network
device. When the DetNet flows are treated independently, the
device should maintain a mapping relationship between a DetNet
flow and its corresponding resources.
4.3. PREOF Support
DetNet path redundancy is supported via Packet Replication,
Elimination, and Ordering Functions (PREOF). A DetNet flow is
replicated and forwarded by multiple networks paths to avoid packet
loss caused by device or link failures. In general, current control
plane mechanisms that can be used to establish an explicit path,
whether distributed or centralized, support point-to-point (P2P) and
point-to-multipoint (P2MP) path establishment. PREOF requires the
ability to compute and establish a set of multiple paths (e.g.,
multiple Label Switched Path (LSP) segments in an MPLS network) from
the point(s) of packet replication to the point(s) of packet merging
and ordering. Mapping of DetNet flows or DetNet member flows to
explicit path segments has to be ensured as well. Protocol
extensions will be required to support these new features.
Terminology will also be required to refer to this coordinated set of
path segments (such as an "LSP graph" in the case of the DetNet MPLS
data plane).
4.4. Data-Plane-Specific Considerations
4.4.1. DetNet in an MPLS Domain
For the purposes of this document, "legacy MPLS" is defined as MPLS
without the use of Segment Routing (see Section 4.4.3 for a
discussion of MPLS with Segment Routing) or MPLS Transport Profile
(MPLS-TP) [RFC5960].
In legacy MPLS domains, a dynamic control plane using distributed
signaling protocols is typically used for the distribution of MPLS
labels used for forwarding MPLS packets. The dynamic signaling
protocols most commonly used for label distribution are LDP
[RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP-
based MPLS Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs
[RFC7432]).
Any of these protocols could be used to distribute DetNet Service
Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As
discussed in [RFC8938], S-Labels are similar to other MPLS service
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
LDP or BGP. If these were to be used for DetNet, they would require
extensions to support DetNet-specific features, such as PREOF,
aggregation (A-Labels), node resource allocation, and queue
placement.
4.4.2. DetNet in an IP Domain
For the purposes of this document, "legacy IP" is defined as IP
without the use of Segment Routing (see Section 4.4.3 for a
discussion of IP with Segment Routing). It 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 only one path per flow
or flow aggregate is required. Therefore, possible protocol
extensions are expected to be limited, e.g., to existing IP routing
protocols.
4.4.3. DetNet in a Segment Routing Domain
Segment Routing [RFC8402] is a scalable approach to building network
domains that provides explicit routing via source routing encoded in
packet headers, and it is combined with centralized network control
to compute paths through the network. Forwarding paths are
distributed with associated policies to network edge nodes for use in
packet headers. Segment Routing reduces the amount of network
signaling associated with distributed signaling protocols, such as
RSVP-TE, and also reduces the amount of state in core nodes compared
with that required for legacy MPLS and IP routing, as the state is
now in the packets rather than in the routers. This could be useful
for DetNet, where a very large number of flows through a network
domain are expected, which would otherwise require the instantiation
of state for each flow traversing each node in the network.
Note that the DetNet MPLS and IP data planes described in [RFC8964]
and [RFC8939] were constructed to be compatible with both types of
Segment Routing: Segment Routing over MPLS (SR-MPLS) [RFC8660] and
Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986].
4.5. Encapsulation and Metadata Support
To effectively manage DetNet flows, the controller plane will need to
have a clear understanding of the encapsulation and metadata
capabilities of the underlying network nodes. This will require a
control mechanism that can discover, configure, and manage these
parameters for each flow.
The controller plane needs to understand and manage the encapsulation
and metadata capabilities of the network nodes to provision DetNet
flows effectively. This process might need a discovery phase in
which the controller discovers which encapsulation types (e.g., MPLS,
IP) and metadata schemes (e.g., sequencing, timestamping) that each
node supports. After discovery, the controller might instruct nodes
on the specific encapsulation and companion metadata to apply for a
given flow. This ensures that DetNet packets are handled
consistently across the network. For example, the controller might
instruct a node to use an MPLS header and add a sequence number for a
particular flow.