DetNet Configuration YANG ModelHuaweigengxuesong@huawei.comHuaweimach.chen@huawei.comChina Mobilelizhenqiang@chinamobile.comCisco Systemsrrahman@cisco.comThis document defines a YANG data model for Deterministic Networking
(DetNet), which includes the DetNet topology YANG module, DetNet flow
configuration YANG module and DetNet Transport QoS YANG Module.The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.Deterministic Networking (DetNet) is defined to provide
high-quality network service with extremely low packet loss rate,
bounded low latency and jitter.DetNet flow information is defined in, and the DetNet
models are categorized as:Flow models: describe characteristics of data flows. These models
describe in detail all relevant aspects of a flow that are needed to
support the flow properly by the network between the source and the
destination(s).Service models: describe characteristics of services being
provided for data flows over a network. These models can be treated
as a network operator independent information model.Configuration models: describe in detail the settings required on
network nodes to serve a data flow properly. Service and flow
information models are used between the user and the network
operator. Configuration information models are used between the
management/control plane entity of the network and the network
nodes.They are shown in the Figure 1.This document defines DetNet configuration YANG data models, which
include:DetNet topology model DetNet topology model is designed for DetNet
topology/capability discovery and device configuration, it is an
augmentation of the ietf-te-toplogy model . The detail of DetNet
topology model is defined in Section 3.DetNet flow configuration modelDetNet flow model is designed for DetNet flow path
configuration and flow status reporting. The detail of DetNet
flow configuration model is defined in Section 4.DetNet transport QoS modelDetNet transport QoS model is designed for QoS attributes
configuration of transport tunnels to achieve end-to-end bounded
latency and zero congestion loss. The detail of DetNet transport
QoS model is defined in Section 5.This documents uses the terminologies defined in .A DetNet topology is composed of a set of DetNet nodes and DetNet
links. DetNet nodes represent the network devices that can transport
DetNet services, which are connected by DetNet links. A DetNet Link
Terminate Point(LTP) is the connection point between a DetNet node and a
DetNet link, which represents the port or interface of a network node.
The concept of DetNet node/link/LTP are similar as TE node/link/LTP that
are defined in .Figure 2 shows a simple DetNet topology: A is a DetNet node, B is
DetNet a LTP, and C is a DetNet link. DetNet topology model (ietf-detnet-topology) augments
ietf-te-topology model to
cover the following attributes, which are necessary for supporting
DetNet congestion protection and service protection functions:Bandwidth related attributes (e.g., bandwidth reserved for
DetNet);Buffer/queue management related attributes (e.g., queue
management algorithm, etc.);PREOF (Packet Replication, Ordering and Elimination Function)
capabilities and parameters (e.g., maximum out-of-order packets,
etc.);Delay related attributes (e.g., node processing delay, queuing
delay, link delay, etc.);The above attributes are categorized into three types: node
attributes, link attributes and LTP attributes. The detailed
descriptions and model definitions are specified in section 4.1, 4.2 and
4.3, respectively.Section 4.3 of
gives a DetNet time model, which defines that the delay within a node
includes five parts: processing delay, regulation delay, queuing
delay, output delay and preemption delay. The processing delay,
queuing delay and regulation delay are variable in general, but for
DetNet, these delays should be bounded, which is the basic assumption
of deterministic networking. These bounded delay parameters are
necessary to perform DetNet path computation. Among this delay
attributes, processing delay and regulation delay are node relevant,
and the queuing delay is LTP relevant. In addition, in order to
simplify the model and implementation, the processing delay and
regulation delay are combined as processing delay, and the preemption
delay is included in queuing delay. [Editor notes: more comments and
inputs need here].For the DetNet node attributes, the following variables are
introduced:Maximum DetNet packet processing delayMinimum DetNet packet processing delayMaximum DetNet packet processing delay
variationThe modeling structure is shown below:DetNet link attributes include link delay and link bandwidth for
DetNet. This document introduces the following link related
attributes:Link delay: link delay is a constant that only depends on the
physical connection. It has been defined in ietf-te-topology , and DetNet can reuse it
directly.Maximum DetNet reservable bandwidth: the maximum reservable
bandwidth that is allocated to DetNet. For a 10G link, if 50% of
the bandwidth is allocated to DetNet, then the maximum DetNet
reservable bandwidth is 5G. That means there are 5G bandwidth that
can be used by DetNet flows.Reserved DetNet bandwidth: the bandwidth that has been reserved
for DetNet flows.Available DetNet bandwidth: the bandwidth that is available for
new DetNet flows.The DetNet link attributes are modeled within a link, and the
YANG module structure is shown below:The concept of LTP is introduced in , and this section introduces
attributes for DetNet LTP.PREOF (Packet Replication/Elimination/Ordering Function) is for
DetNet service protection, which includes :In-order delivery function: defined in Section 3.2.2.1 of Packet replication function: defined in Section 3.2.2.2 of
Packet elimination function: defined in Section 3.2.2.3 of
The above functions are modeled as a set of capabilities and
relevant parameters, which are listed below:in-order-capability: indicates whether a LTP has the in-order
delivery capability.maximum-number-of-out-of-order-packets: indicates the maximum
number of out-of-order packets that an LTP can support, it depends
on the reserved buffer size for packet reordering.replication-capability: indicates whether a LTP has the packet
replication capability.elimination-capability: indicates whether a LTP has the packet
elimination capability.In addition, DetNet LTP also includes queuing management
algorithms and queuing delay attributes. In the context of DetNet, the
delay of queuing is bounded, and the bound depends on what queuing
management method is used and how many buffers are allocated. More
information can be found in . Queuing related attributes
are listed below:queuing-algorithm-capabilities: it is modeled as a list that
includes all queuing algorithms that a LTP supports.detnet-queues: it's modeled as a list that includes all queues
of a DetNet LTP. For each queue, it has the following
attributes:queue-identifier: an identifier of a queue. It could be an
internal identifier that is only used within a node. Or it could
be used by a centralized controller to specify in which specific
queue a flow/packet is required to enter.queue-buffer-size: the size of a queue with unit of bytes.enabled-queuing-algorithm: indicates what queuing management
algorithm is enabled.maximum-queuing-delay: the maximum queuing delay that a packet
will undergo when transmitted through the queue.minimum-queuing-delay: the minimum queuing delay that a packet
will undergo when transmitted through the queue.maximum-queuing-delay-variation: the maximum queuing delay
variation that a packet will undergo when transmitted the
queue.The DetNet LTP attributes are modeled with a LTP, the YANG
module structure is shown below:DetNet flow configuration includes DetNet Service Proxy
configuration, DetNet Service Layer configuration and DetNet Transport
Layer configuration. The corresponding attributes used in different
layers are defined in Section 4.1, 4.2, 4.3, respectively. Section 4.4
gives a simple example on how to use these attributes for DetNet flow
configuration.DetNet service proxy is responsible for mapping between application
flows and DetNet flows at the edge node(egress/ingress node). Where
the application flows can be either layer 2 or layer 3 flows. To
identify a flow at the User Network Interface (UNI), as defined in
, the following
flow attributes are introduced:DetNet L3 Flow Identification, refers to Section 7.1.1 of DetNet L2 Flow Identification, refers to Section 7.1.2 of DetNet service proxy can also do flow filtering and policing
at the ingress to prevent the misbehaviored flows from going into the
network, which needs:Traffic Specification, refers to Section 7.2 of The YANG module structure is shown below:DetNet service functions, e.g., DetNet tunnel
initialization/termination and service protection, are provided in
DetNet service layer. To support these functions, the following
service attributes need to be configured:DetNetwork flow identification, refers to Section 7.1.3 of
.Service function indication, indicates which service function
will be invoked at a DetNet edge, relay node or end station.
(DetNet tunnel initialization or termination are default functions
in DetNet service layer, so there is no need for explicit
indication.)Flow Rank, refers to Section 7.3 of .Service Rank, refers to Section 7.4 of .Service encapsulation, refers to Section 6.2 of Transport encapsulation, refers to Section 6.2 of and Section 3 of The YANG module structure is shown below:As defined in , DetNet
transport layer optionally provides congestion protection for DetNet
flows over paths provided by the underlying network. Explicit route is
another mechanism that is used by DetNet to avoid temporary
interruptions caused by the convergence of routing or bridging
protocols, and it is also implemented at the DetNet transport
layer.To support congestion protection and explicit route, the following
transport layer related attributes are necessary:Traffic Specification, refers to Section 7.2 of . It may used for
bandwidth reservation, flow shaping, filtering and policing.Explicit path, existing explicit route mechanisms can be
reused. For example, if Segment Routing (SR) tunnel is used as the
transport tunnel, the configuration is mainly at the ingress node
of the transport layer; if the static MPLS tunnel is used as the
transport tunnel, the configurations need to be at every transit
node along the path; for pure IP based transport tunnel, it's
similar to the static MPLS case.The YANG module structure is shown below:The parameters for DetNet transport QoS are defined in Section
5.This section gives an example about how to implement an end-2-end
DetNet service with the collaboration of DetNet proxy, service and
transport layers.To simplify the explanation, several terms are introduced. This
document defines DetNet Service Proxy Instance (DSPI), DetNet Service
Instance (DSI) and DetNet Transport Instance for end-to-end DetNet
flow configuration as showed in Figure 4. DSPI 1 at Edge Node 1 (E1)
maps an application flow to a DetNet Flow (DF1), which is transmitted
over a DetNet tunnel (Tn1). In DSI 2 of Relay Node 1 (R1), DetNet Flow
1(DF1) was replicated into two member flows: DetNet Flow 2 (DF2)
transmitted by DetNet Tunnel 2 (Tnl2) and DetNet Flow 3 (DF3) by
DetNet Tunnel 3(Tnl3). In DSPI 3 of Edge Node 2 (E2), DetNet Flow 2
(DF2) and DetNet Flow 3(DF3) were merged and mapped to application
flow used by CE2.The YANG data model of transport QoS is very important to achieve
end-to-end bounded latency and zero congestion loss. There are three
possible methods to deal with the DetNet transport QoS YANG:1. DetNet service is not aware of any QoS/queuing/bounded-latency
information, and all relative parameters are defined in separate YANG
models;2. DetNet service is not aware of any of Qos/queuing/bounded-latency
information, but it should maintain an interface to the corresponding
YANG models;3. DetNet service should be aware of the Qos/queuing/bounded-latency
information, because some Qos/queuing/bounded-latency mechanisms are
required to be configured with flow information;How to define transport QoS YANG is still under discussion and the
transport QoS YANG model is not included in the current version of the
draft.[Editor notes: more comments and inputs need here].This section defines three classes of DetNet configuration model:
fully distributed configuration model, fully centralized configuration
model, hybrid configuration model, based on different network
architectures, showing how configuration information exchanges between
various entities in the network.In a fully distributed configuration model, UNI information is
transmitted over DetNet UNI protocol from the user side to the network
side; then UNI information and network configuration information
propagate in the network over distributed control plane protocol. For
example:1) IGP collects topology information and DetNet capabilities of
network();2) Control Plane of the Edge Node(Ingress) receives a flow
establishment request from UNI and calculates a/some valid
path(s);3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.Current distributed control plane protocol,e.g., RSVP-TE, SRP, can only reserve
bandwidth along the path, while the configuration of a fine-grained
schedule, e.g.,Time Aware Shaping(TAS) defined in , is not supported.The fully distributed configuration model is not covered by this
draft. It should be discussed in the future DetNet control plane
work.In the fully centralized configuration model, UNI information is
transmitted from Centralized User Configuration (CUC) to Centralized
Network Configuration(CNC). Configurations of routers for DetNet flows
are performed by CNC with network management protocol. For
example:1) CNC collects topology information and DetNet capability of
network through Netconf;2) CNC receives a flow establishment request from UNI and
calculates a/some valid path(s);3) CNC configures the devices along the path for flow
transmission.In the hybrid configuration model, controller and control plane
protocols work together to offer DetNet service, and there are a lot
of possible combinations. For example:1) CNC collects topology information and DetNet capability of
network through IGP/BGP-LS;2) CNC receives a flow establishment request from UNI and
calculates a/some valid path(s);3) Based on the calculation result, CNC distributes flow path
information to Edge Node(Ingress) and other information(e.g.
replication/elimination) to the relevant nodes.4) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.or1) Controller collects topology information and DetNet capability
of network through IGP/BGP-LS;2) Control Plane of Edge Node(Ingress) receives a flow
establishment request from UNI;3) Edge Node(Ingress) sends the path establishment request to CNC
through PCEP;4) After Calculation, CNC sends back the path information of the
flow to the Edge Node(Ingress) through PCEP;5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.There are also other variations that can be included in the hybrid
model. This draft can not coverer all the control plane data needed in
hybrid configuration models. Every solution has there own mechanism
and corresponding parameters to make it work.Editor's Note:1. There are a lot of optional DetNet configuration models, and
different scenario in different use case can choose one of them based
on its conditions. Maybe next step of the work is to pick up one or
more typical scenarios and give a practical solution.2. also defines three TSN
configuration models: fully-centralized model, fully-distributed
model, centralized Network / distributed User Model. This section
defines the configuration model roughly the same, to keep the design
of L2 and L3 in the same structure. Hybrid configuration model is
slightly different from the 'centralized Network / distributed User
Model'. The hybrid configuration model intends to contain more
variations.There are some open issues that are still under disccusion:The Relationship with 802.1 TSN YANG models is TBD. The possible
problems include: what is the relationship between DetNet YANG and
TSN YANG that will be defined in IEEE 802.1 CBcv, whether a common
YANG model should be defined to be shared by both TSN and DetNet,
and so on.DetNet Transport QoS Model is TBD. The possible problem is how to
provide an interface to use the queuing management algorithms
defined in IEEE.These issues will be resolved in the following versions of the
draft.This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.<TBD>IEEE, "Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements (IEEE Draft P802.1Qcc)", 2017,
<http://www.ieee802.org/1/files/private/cc-drafts/>.IEEE, "IEEE Std 802.1Qbu Bridges and Bridged Networks -
Amendment 25: Enhancements for Scheduled Traffic", 2015,
<http://ieeexplore.ieee.org/document/7572858/>.IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks", 2014,
<http://ieeexplore.ieee.org/document/6991462/>.IEEE, "Cyclic Queuing and Forwarding (IEEE Draft P802.1Qch)",
2017,
<http://www.ieee802.org/1/files/private/ch-drafts/>.IEEE, "Per-Stream Filtering and Policing (IEEE Draft
P802.1Qci)", 2016,
<http://www.ieee802.org/1/files/private/ci-drafts/>.IEEE, "IEEE Std 802.1Qbu Bridges and Bridged Networks -
Amendment 26: Frame Preemption", 2016,
<http://ieeexplore.ieee.org/document/7553415/>.IEEE, "Frame Replication and Elimination for Reliability
(IEEE Draft P802.1CB)", 2017,
<http://www.ieee802.org/1/files/private/cb-drafts/>.