Deterministic Networking
(DetNet) Configuration YANG ModelHuawei Technologiesgengxuesong@huawei.comHuawei Technologiesmach.chen@huawei.comETRIdbduscjf@etri.re.krLabN Consulting, L.L.C.dfedyk@labn.netIndividualreshad@yahoo.comChina Mobilelizhenqiang@chinamobile.comThis document contains the specification for Deterministic Networking
flow configuration YANG Model. The model allows for provisioning of
end-to-end DetNet service along the path without dependency on any
signaling protocol.The YANG module defined in this document conforms 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.DetNet (Deterministic Networking) provides a capability 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 .This document defines a YANG model for DetNet based on YANG data
types and modeling language defined in and
. DetNet service, which is designed for
describing the characteristics of services being provided for
application flows over a network, and DetNet configuration, which is
designed for DetNet flow path establishment, flow status reporting, and
DetNet functions configuration in order to achieve end-to-end bounded
latency and zero congestion loss, are both included in this
document.This documents uses the terminologies defined in .DetNet configuration module includes DetNet App-flow configuration,
DetNet Service Sub-layer configuration, and DetNet Forwarding Sub-layer
configuration. The corresponding attributes used in different sub-layers
are defined in Section 3.1, 3.2, 3.3 respectively.DetNet application flow 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 map a flow at the User Network Interface (UNI), the
corresponding attributes are defined in .DetNet service functions, e.g., DetNet tunnel
initialization/termination and service protection, are provided in
DetNet service sub-layer. To support these functions, the following
service attributes need to be configured:DetNet flow identificationService 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). The corresponding arguments for service functions
also needs to be defined.As defined in , DetNet forwarding sub-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 forwarding sub-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
resource 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.DetNet provides the capability of flow aggregation to improve
scaleability of DetNet data, management and control planes. Aggregated
flows can be viewed by the some DetNet nodes as individual DetNet flows.
When aggregating DetNet flows, the flows should be compatible: if
bandwidth reservations are used, the reservation should be a reasonable
representation of the individual reservations; if maximum delay bounds
are used, the system should ensure that the aggregate does not exceed
the delay bounds of the individual flows.The DetNet YANG model defined in this document supports DetNet flow
aggregation with the following functions:Aggregation flow encapsulation/decapsulation/identificationMapping individual DetNet flows to an aggregated flowChanging traffic specification parameters for aggregated flowThe following cases of DetNet aggregation are supported:aggregate data flows into an application which is then mapped to
a service sub-layer at the ingress node. Note the data flows may be
other DetNet flows.map each DetNet application to a single service sub-layer and
allowing the aggregation of multiple applications at the ingress
node, and vice versa for de-aggregation. A classifier may be
required to de-aggregate the respective applications.map each DetNet application uniquely to a single service
sub-layer where those sub-layers may be encapsulated as a single
service sub-layer and hence aggregating the applications at the
ingress node, and vice versa for de-aggregation. In this case, the
service sub-layer identifier may be sufficient to identify the
application. A classifier may be required to de-aggregate the
service sub-layers.aggregate DetNet service sub-layers into an aggregated flow by
using the same forwarding sub-layer at ingress node or relay node,
and vice versa for de-aggregation.aggregate DetNet flows with different forwarding sub-layer into
an aggregated flow by using the same forwarding sub-layer at transit
node, and vice versa for de-aggregation.Traffic requirements and traffic specification may be tracked for
individual or aggregate flows but reserving resources and tracking the
services in the aggregated flow is out of scope.The picture shows that the general structure of the DetNet YANG
Model:There are three instances in DetNet YANG Model: App-flow instance,
service sub-layer instance and forwarding sub-layer instance,
respectively corresponding to four parts of DetNet functions defined in
section 3.There are some open issues that are still under discussion:Terminology.Security Considerations.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>The following examples are provided.A simple DetNet application illustrting multiplexing of
Application Flows.A case of Forwarding sub-layer aggregation using a single
forwarding sublayer.A case of Service sub-layer aggregation with and aggrgation
label.
draft-ietf-detnet-yang-10.txt draft-ietf-detnet-yang-10.txt
<?xml version="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <rfc category="std" docName="draft-ietf-detnet-yang-10" ipr="trust200902" submissionType="IETF">