draft-ietf-detnet-yang-00.txt   draft-ietf-detnet-yang-01.txt 
Network Working Group X. Geng Network Working Group X. Geng
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Intended status: Standards Track Huawei Technologies
Expires: April 25, 2019 Z. Li Expires: July 18, 2019 Z. Li
China Mobile China Mobile
R. Rahman R. Rahman
Cisco Systems Cisco Systems
October 22, 2018 January 14, 2019
DetNet Configuration YANG Model Deterministic Networking (DetNet) Configuration YANG Model
draft-ietf-detnet-yang-00 draft-ietf-detnet-yang-01
Abstract Abstract
This document defines a YANG data model for Deterministic Networking This document contains the specification for Deterministic Networking
(DetNet), which includes the DetNet topology YANG module, DetNet flow flow configuration YANG Model. The model allows for provisioning of
configuration YANG module and DetNet Transport QoS YANG Module. end-to-end DetNet service along the path without dependency on any
signaling protocol.
The YANG modules in this document conform to the Network Management The YANG module defined in this document conforms to the Network
Datastore Architecture (NMDA). Management Datastore Architecture (NMDA).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 45 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on July 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DetNet Topology Model . . . . . . . . . . . . . . . . . . . . 4 3. DetNet Configuration Model . . . . . . . . . . . . . . . . . 4
3.1. DetNet Node Attributes . . . . . . . . . . . . . . . . . 5 3.1. DetNet Service Proxy Configuration Attributes . . . . . . 4
3.2. DetNet Link Attributes . . . . . . . . . . . . . . . . . 6 3.2. DetNet Service Layer Configuration Attributes . . . . . . 5
3.3. DetNet Link Terminate Point Attributes . . . . . . . . . 7 3.3. DetNet Transport Layer Configuration Attributes . . . . . 7
4. DetNet Flow Configuration Model . . . . . . . . . . . . . . . 9 4. DetNet Configuration YANG Structure . . . . . . . . . . . . . 8
4.1. DetNet Service Proxy Configuration Attributes . . . . . . 9 5. DetNet Configuration YANG Model . . . . . . . . . . . . . . . 14
4.2. DetNet Service Layer Configuration Attributes . . . . . . 10 6. DetNet Configuration Model Classification . . . . . . . . . . 31
4.3. DetNet Transport Layer Configuration Attributes . . . . . 12 6.1. Fully Distributed Configuration Model . . . . . . . . . . 31
4.4. DetNet Flow Configuration Example . . . . . . . . . . . . 13 6.2. Fully Centralized Configuration Model . . . . . . . . . . 31
5. DetNet Transport QoS Model . . . . . . . . . . . . . . . . . 14 6.3. Hybrid Configuration Model . . . . . . . . . . . . . . . 32
6. DetNet Yang Structure . . . . . . . . . . . . . . . . . . . . 15 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. DetNet Topology Model Tree Diagram . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
6.2. DetNet Flow Configuration Model Tree Diagram . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7. DetNet YANG Model . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
7.1. DetNet Topology YANG Model . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. DetNet Flow Configuration YANG Model . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
8. DetNet Configuration Model Classification . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 35
8.1. Fully Distributed Configuration Model . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Fully Centralized Configuration Model . . . . . . . . . . 46
8.3. Hybrid Configuration Model . . . . . . . . . . . . . . . 46
9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . 48
13.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] is Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] is
defined to provide high-quality network service with extremely low defined to provide high-quality network service with extremely low
packet loss rate, bounded low latency and jitter. packet loss rate, bounded low latency and jitter.
DetNet flow information is defined DetNet flow information is defined
in[I-D.ietf-detnet-flow-information-model], and the DetNet models are in[I-D.ietf-detnet-flow-information-model], and the DetNet models are
categorized as: categorized as:
skipping to change at page 3, line 50 skipping to change at page 3, line 40
| model | model
+------------+ +------------+
v | | v | |
+-+ | v network +-+ | v network
+-+ v +-+ nodes +-+ v +-+ nodes
+-+ +-+ +-+ +-+
+-+ +-+
Figure 1. Three Information Models Figure 1. Three Information Models
This document defines DetNet configuration YANG [RFC7950] DetNet YANG [RFC7950] [RFC6991] models include:
[RFC6991]data models, which include:
o 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
[I-D.ietf-teas-yang-te-topo]. The detail of DetNet topology
model is defined in Section 3.
o DetNet flow configuration model
DetNet 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.
o DetNet transport QoS model
DetNet transport QoS model is designed for QoS attributes DetNet YANG [RFC7950] [RFC6991] models are used for DetNet service
configuration of transport tunnels to achieve end-to-end configurations, QoS configuration and topology discovery. DetNet
bounded latency and zero congestion loss. The detail of DetNet topology model is defined in ietf-detnet-topology-yang. This
transport QoS model is defined in Section 5. document defines two YANG models, which are referred to as DetNet
flow configuration model and DetNet transport QoS model. DetNet flow
model is designed for DetNet flow path configuration and flow status
reporting. DetNet transport QoS model is designed for QoS attributes
configuration of transport tunnels to achieve end-to-end bounded
latency and zero congestion loss.
2. Terminologies 2. Terminologies
This documents uses the terminologies defined in This documents uses the terminologies defined in
[I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture].
3. DetNet Topology Model 3. DetNet Configuration Model
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 [I-D.ietf-teas-yang-te-topo].
Figure 2 shows a simple DetNet topology: A is a DetNet node, B is
DetNet a LTP, and C is a DetNet link.
+---+ +---+
| A |o(B)--(C)--| |
+---+ +---+
Figure 2. An example of DetNet Topology
DetNet topology model (ietf-detnet-topology) augments ietf-te-
topology model [I-D.ietf-teas-yang-te-topo] to cover the following
attributes, which are necessary for supporting DetNet congestion
protection and service protection functions:
o Bandwidth related attributes (e.g., bandwidth reserved for
DetNet);
o Buffer/queue management related attributes (e.g., queue management
algorithm, etc.);
o PREOF (Packet Replication, Ordering and Elimination Function)
capabilities and parameters (e.g., maximum out-of-order packets,
etc.);
o 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.
3.1. DetNet Node Attributes
Section 4.3 of [I-D.finn-detnet-bounded-latency] 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:
o Maximum DetNet packet processing delay
o Minimum DetNet packet processing delay
o Maximum DetNet packet processing delay variation
The modeling structure is shown below:
augment /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes:
+--rw detnet-node-attributes
+--rw minimum-packet-processing-delay? uint32
+--rw maximum-packet-processing-delay? uint32
+--rw maximum-packet-processing-delay-variation? uint32
3.2. DetNet Link Attributes
DetNet link attributes include link delay and link bandwidth for
DetNet. This document introduces the following link related
attributes:
o Link delay: link delay is a constant that only depends on the
physical connection. It has been defined in ietf-te-topology
[I-D.ietf-teas-yang-te-topo], and DetNet can reuse it directly.
o 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.
o Reserved DetNet bandwidth: the bandwidth that has been reserved
for DetNet flows.
o 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:
augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes:
+--rw detnet-link-attributes
+--rw maximum-reservable-bandwidth
| +--rw te-bandwidth
| +--rw (technology)?
| +--:(generic)
| +--rw generic? te-bandwidth
+--rw reserved-detnet-bandwidth
| +--rw te-bandwidth
| +--rw (technology)?
| +--:(generic)
| +--rw generic? te-bandwidth
+--rw available-detnet-bandwidth
+--rw te-bandwidth
+--rw (technology)?
+--:(generic)
+--rw generic? te-bandwidth
3.3. DetNet Link Terminate Point Attributes
The concept of LTP is introduced in [I-D.ietf-teas-yang-te-topo], and
this section introduces attributes for DetNet LTP.
PREOF (Packet Replication/Elimination/Ordering Function) is for
DetNet service protection, which includes :
o In-order delivery function: defined in Section 3.2.2.1 of
[I-D.ietf-detnet-architecture]
o Packet replication function: defined in Section 3.2.2.2 of
[I-D.ietf-detnet-architecture]
o Packet elimination function: defined in Section 3.2.2.3 of
[I-D.ietf-detnet-architecture]
The above functions are modeled as a set of capabilities and relevant
parameters, which are listed below:
o in-order-capability: indicates whether a LTP has the in-order
delivery capability.
o 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.
o replication-capability: indicates whether a LTP has the packet
replication capability.
o 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 [I-D.finn-detnet-bounded-latency]. Queuing related
attributes are listed below:
o queuing-algorithm-capabilities: it is modeled as a list that
includes all queuing algorithms that a LTP supports.
o detnet-queues: it's modeled as a list that includes all queues of
a DetNet LTP. For each queue, it has the following attributes:
o 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.
o queue-buffer-size: the size of a queue with unit of bytes.
o enabled-queuing-algorithm: indicates what queuing management
algorithm is enabled.
o maximum-queuing-delay: the maximum queuing delay that a packet
will undergo when transmitted through the queue.
o minimum-queuing-delay: the minimum queuing delay that a packet
will undergo when transmitted through the queue.
o 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:
augment /nw:networks/nw:network/nw:node/nt:termination-point/tet:te:
+--rw detnet-terminate-point-attributes
+--rw elimination-capability? boolean
+--rw replication-capability? boolean
+--rw in-ordering-capability
| +--rw in-ordering-capability? boolean
| +--rw maximum-out-of-order-packets? uint32
+--rw queuing-algorithm-capabilities
| +--rw credit-based-shaping? boolean
| +--rw time-aware-shaping? boolean
| +--rw cyclic-queuing-and-forwarding? boolean
| +--rw asynchronous-traffic-shaping? boolean
+--rw queues* [queue-identifier]
+--rw queue-identifier uint32
+--rw queue-buffer-size? uint32
+--rw enabled-queuing-algorithm
| +--rw credit-based-shaping? boolean
| +--rw time-aware-shaping? boolean
| +--rw cyclic-queuing-and-forwarding? boolean
| +--rw asynchronous-traffic-shaping? boolean
+--rw minimum-queuing-delay? uint32
+--rw maximum-queuing-delay? uint32
+--rw maximum-queuing-delay-variation? uint32
4. DetNet Flow Configuration Model
DetNet flow configuration includes DetNet Service Proxy DetNet flow configuration includes DetNet Service Proxy
configuration, DetNet Service Layer configuration and DetNet configuration, DetNet Service Layer configuration and DetNet
Transport Layer configuration. The corresponding attributes used in Transport Layer configuration. The corresponding attributes used in
different layers are defined in Section 4.1, 4.2, 4.3, respectively. different layers are defined in Section 3.1, 3.2, 3.3, respectively.
Section 4.4 gives a simple example on how to use these attributes for
DetNet flow configuration.
4.1. DetNet Service Proxy Configuration Attributes 3.1. DetNet Service Proxy Configuration Attributes
DetNet service proxy is responsible for mapping between application DetNet service proxy is responsible for mapping between application
flows and DetNet flows at the edge node(egress/ingress node). Where 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 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 identify a flow at the User Network Interface (UNI), as defined in
[I-D.ietf-detnet-flow-information-model], the following flow [I-D.ietf-detnet-flow-information-model], the following flow
attributes are introduced: attributes are introduced:
o DetNet L3 Flow Identification, refers to Section 7.1.1 of o DetNet L3 Flow Identification, refers to Section 7.1.1 of
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
skipping to change at page 10, line 35 skipping to change at page 5, line 35
| | +--rw source-port? inet:port-number | | +--rw source-port? inet:port-number
| | +--rw destination-port? inet:port-number | | +--rw destination-port? inet:port-number
| | +--rw protocol? uint8 | | +--rw protocol? uint8
| +--rw traffic-specification | +--rw traffic-specification
| +--rw interval? uint32 | +--rw interval? uint32
| +--rw max-packets-per-interval? uint32 | +--rw max-packets-per-interval? uint32
| +--rw max-payload-size? uint32 | +--rw max-payload-size? uint32
| +--rw average-packets-per-interval? uint32 | +--rw average-packets-per-interval? uint32
| +--rw average-payload-size? uint32 | +--rw average-payload-size? uint32
4.2. DetNet Service Layer Configuration Attributes 3.2. DetNet Service Layer Configuration Attributes
DetNet service functions, e.g., DetNet tunnel initialization/ DetNet service functions, e.g., DetNet tunnel initialization/
termination and service protection, are provided in DetNet service termination and service protection, are provided in DetNet service
layer. To support these functions, the following service attributes layer. To support these functions, the following service attributes
need to be configured: need to be configured:
o DetNetwork flow identification, refers to Section 7.1.3 of o DetNet flow identification, refers to Section 7.1.3 of
[I-D.ietf-detnet-flow-information-model]. [I-D.ietf-detnet-flow-information-model].
o Service function indication, indicates which service function will o Service function indication, indicates which service function will
be invoked at a DetNet edge, relay node or end station. (DetNet be invoked at a DetNet edge, relay node or end station. (DetNet
tunnel initialization or termination are default functions in tunnel initialization or termination are default functions in
DetNet service layer, so there is no need for explicit DetNet service layer, so there is no need for explicit
indication.) indication.)
o Flow Rank, refers to Section 7.3 of o Flow Rank, refers to Section 7.3 of
[I-D.ietf-detnet-flow-information-model]. [I-D.ietf-detnet-flow-information-model].
o Service Rank, refers to Section 7.4 of o Service Rank, refers to Section 7.4 of
[I-D.ietf-detnet-flow-information-model]. [I-D.ietf-detnet-flow-information-model].
o Service decapsulation, refers to Section 6.2 of
[I-D.ietf-detnet-dp-sol-mpls]
o Transport decapsulation, refers to Section 6.2 of
[I-D.ietf-detnet-dp-sol-mpls] and Section 3 of
[I-D.ietf-detnet-dp-sol-ip]
o Service encapsulation, refers to Section 6.2 of o Service encapsulation, refers to Section 6.2 of
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
o Transport encapsulation, refers to Section 6.2 of o Transport encapsulation, refers to Section 6.2 of
[I-D.ietf-detnet-dp-sol-mpls]and Section 3 of [I-D.ietf-detnet-dp-sol-mpls]and Section 3 of
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
The YANG module structure is shown below: The YANG module structure is shown below:
| +--rw relay-node | +--rw relay-node
skipping to change at page 12, line 35 skipping to change at page 7, line 42
| | +--:(label-swap) | | +--:(label-swap)
| | +--rw label-swap | | +--rw label-swap
| | +--rw out-label uint32 | | +--rw out-label uint32
| | +--rw ttl-action? ttl-action-definition | | +--rw ttl-action? ttl-action-definition
| +--rw interval? uint32 | +--rw interval? uint32
| +--rw max-packets-per-interval? uint32 | +--rw max-packets-per-interval? uint32
| +--rw max-payload-size? uint32 | +--rw max-payload-size? uint32
| +--rw average-packets-per-interval? uint32 | +--rw average-packets-per-interval? uint32
| +--rw average-payload-size? uint32 | +--rw average-payload-size? uint32
4.3. DetNet Transport Layer Configuration Attributes 3.3. DetNet Transport Layer Configuration Attributes
As defined in [I-D.ietf-detnet-architecture], DetNet transport layer As defined in [I-D.ietf-detnet-architecture], DetNet transport layer
optionally provides congestion protection for DetNet flows over paths optionally provides congestion protection for DetNet flows over paths
provided by the underlying network. Explicit route is another provided by the underlying network. Explicit route is another
mechanism that is used by DetNet to avoid temporary interruptions mechanism that is used by DetNet to avoid temporary interruptions
caused by the convergence of routing or bridging protocols, and it is caused by the convergence of routing or bridging protocols, and it is
also implemented at the DetNet transport layer. also implemented at the DetNet transport layer.
To support congestion protection and explicit route, the following To support congestion protection and explicit route, the following
transport layer related attributes are necessary: transport layer related attributes are necessary:
skipping to change at page 13, line 24 skipping to change at page 8, line 31
| +--rw transit-node | +--rw transit-node
| +--rw interval? uint32 | +--rw interval? uint32
| +--rw max-packets-per-interval? uint32 | +--rw max-packets-per-interval? uint32
| +--rw max-payload-size? uint32 | +--rw max-payload-size? uint32
| +--rw average-packets-per-interval? uint32 | +--rw average-packets-per-interval? uint32
| +--rw average-payload-size? uint32 | +--rw average-payload-size? uint32
The parameters for DetNet transport QoS are defined in Section 5. The parameters for DetNet transport QoS are defined in Section 5.
4.4. DetNet Flow Configuration Example 4. DetNet Configuration YANG Structure
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.
DF: DetNet Flow
DSPI: DetNet Service Proxy Instance
DSI: DetNet Service Instance
DTI: DetNet Transport Instance
Tnl: Tunnel
|<------- End to End DetNet Service ------>|
| DetNet DetNet |
(AC) | |<-Tnl->| |<-Tnl->| | (AC)
End | V V 1 V V 2/3 V V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | E1 |=======| R1 |=======| E2 | | +---+
| |--|----|--------| |--------| |--------|---|---| |
|CE1| | | DSPI 1 | | | | DSPI 2 | | |CE2|
| | |+-------+ | | +-------+| | |
+---+ || DSI 1 | | DSI 2 | | DSI 3 || +---+
|| + | +------+ | ||
|| +-----+ | |DTI 2 |..DF2..| ||
|| |DTI 1|..DF1..| +------+ | ||
|| +-----+ | |DTI 3 |..DF3..| ||
|+-------+ | +------+ +-------+|
+--------+=======+--------+=======+--------+
Edge Node Relay Node Edge Node
| |
|<-------- DetNet Service --------->|
Figure 3. End-to-end DetNet Flow Configuration
5. DetNet Transport QoS Model
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].
6. DetNet Yang Structure
6.1. DetNet Topology Model Tree Diagram
module: ietf-detnet-topology
augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+--rw detnet-topology!
augment /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes:
+--rw detnet-node-attributes
+--rw minimum-packet-processing-delay? uint32
+--rw maximum-packet-processing-delay? uint32
+--rw maximum-packet-processing-delay-variation? uint32
augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes:
+--rw detnet-link-attributes
+--rw maximum-reservable-bandwidth
| +--rw te-bandwidth
| +--rw (technology)?
| +--:(generic)
| +--rw generic? te-bandwidth
+--rw reserved-detnet-bandwidth
| +--rw te-bandwidth
| +--rw (technology)?
| +--:(generic)
| +--rw generic? te-bandwidth
+--rw available-detnet-bandwidth
+--rw te-bandwidth
+--rw (technology)?
+--:(generic)
+--rw generic? te-bandwidth
augment /nw:networks/nw:network/nw:node/nt:termination-point/tet:te:
+--rw detnet-terminate-point-attributes
+--rw elimination-capability? boolean
+--rw replication-capability? boolean
+--rw in-ordering-capability
| +--rw in-ordering-capability? boolean
| +--rw maximum-out-of-order-packets? uint32
+--rw queuing-algorithm-capabilities
| +--rw credit-based-shaping? boolean
| +--rw time-aware-shaping? boolean
| +--rw cyclic-queuing-and-forwarding? boolean
| +--rw asynchronous-traffic-shaping? boolean
+--rw queues* [queue-identifier]
+--rw queue-identifier uint32
+--rw queue-buffer-size? uint32
+--rw enabled-queuing-algorithm
| +--rw credit-based-shaping? boolean
| +--rw time-aware-shaping? boolean
| +--rw cyclic-queuing-and-forwarding? boolean
| +--rw asynchronous-traffic-shaping? boolean
+--rw minimum-queuing-delay? uint32
+--rw maximum-queuing-delay? uint32
+--rw maximum-queuing-delay-variation? uint32
6.2. DetNet Flow Configuration Model Tree Diagram
module: ietf-detnet-flow-config module: ietf-detnet-flow-config
+--rw detnet-flow +--rw detnet-flow
+--rw (detnet-node-role)? +--rw (detnet-node-role)?
+--:(transit-node) +--:(transit-node)
| +--rw transit-node | +--rw transit-node
| +--rw interval? uint32 | +--rw interval? uint32
| +--rw max-packets-per-interval? uint32 | +--rw max-packets-per-interval? uint32
| +--rw max-payload-size? uint32 | +--rw max-payload-size? uint32
| +--rw average-packets-per-interval? uint32 | +--rw average-packets-per-interval? uint32
skipping to change at page 22, line 38 skipping to change at page 14, line 16
| +--:(label-swap) | +--:(label-swap)
| +--rw label-swap | +--rw label-swap
| +--rw out-label uint32 | +--rw out-label uint32
| +--rw ttl-action? ttl-action-definition | +--rw ttl-action? ttl-action-definition
+--rw interval? uint32 +--rw interval? uint32
+--rw max-packets-per-interval? uint32 +--rw max-packets-per-interval? uint32
+--rw max-payload-size? uint32 +--rw max-payload-size? uint32
+--rw average-packets-per-interval? uint32 +--rw average-packets-per-interval? uint32
+--rw average-payload-size? uint32 +--rw average-payload-size? uint32
7. DetNet YANG Model 5. DetNet Configuration YANG Model
7.1. DetNet Topology YANG Model
<CODE BEGINS> file "ietf-detnet-topology@20180910.yang"
module ietf-detnet-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-topology";
prefix "detnet-topology";
import ietf-te-types {
prefix "te-types";
}
import ietf-te-topology {
prefix "tet";
}
import ietf-network {
prefix "nw";
}
import ietf-network-topology {
prefix "nt";
}
organization
"IETF Deterministic Networking(DetNet)Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/detnet/>
WG List: <mailto:detnet@ietf.org>
WG Chair: Lou Berger
<mailto:lberger@labn.net>
Janos Farkas
<janos.farkas@ericsson.com>
Editor: Xuesong Geng
<mailto:gengxuesong@huawei.com>
Editor: Mach Chen
<mailto:mach.chen@huawei.com>
Editor: Zhenqiang Li
<lizhenqiang@chinamobile.com>
Editor: Reshad Rahman
<rrahman@cisco.com>";
description
"This YANG module augments the 'ietf-te-topology'
module with DetNet related capabilities and
parameters.";
revision "2018-09-10" {
description "Initial revision";
reference "RFC XXXX: draft-geng-detnet-config-yang-05";
}
grouping detnet-queuing-algorithms {
description
"Relationship with IEEE 802.1 TSN YANG models is TBD.";
}
grouping detnet-node-attributes{
description
"DetNet node related attributes.";
leaf minimum-packet-processing-delay{
type uint32;
description
"Minimum packet processing delay
in a node. The unit of the delay
is microsecond(us)";
}
leaf maximum-packet-processing-delay{
type uint32;
description
"Maximum packet processing delay
in a node. The unit of the delay
is microsecond(us)";
}
leaf maximum-packet-processing-delay-variation{
type uint32;
description
"Maximum packet processing delay
variation in a node. The unit of
the delay variation is microsecond(us)";
}
}
grouping detnet-link-attributes{
description
"DetNet link related attributes.";
container maximum-reservable-bandwidth{
uses te-types:te-bandwidth;
description
"This container specifies the maximum bandwidth
that is reserved for DetNet on this link.";
}
container reserved-detnet-bandwidth{
uses te-types:te-bandwidth;
description
"This container specifies the bandwidth that has
been reserved for DetNet on this link.";
}
container available-detnet-bandwidth{
uses te-types:te-bandwidth;
description
"This container specifies the bandwidth that is
available for new DetNet flows on this link.";
}
}
grouping detnet-terminate-point-attributes{
description
"DetNet terminate point related attributes.";
leaf elimination-capability{
type boolean;
description
"Indicates whether a node is able to do packet
elimination.";
reference
"Section 3.2.2.3 of
draft-ietf-detnet-architecture";
}
leaf replication-capability{
type boolean;
description
"Indicates whether a node is able to do packet
replication.";
reference
"Section 3.2.2.2 of
draft-ietf-detnet-architecture";
}
container in-ordering-capability {
description
"Indicates the parameters needed for
packet in-ordering.";
reference
"Section 3.2.2.1 of
draft-ietf-detnet-architecture";
leaf in-ordering-capability {
type boolean;
description
"Indicates whether a node is able to do packet
in-ordering.";
}
leaf maximum-out-of-order-packets {
type uint32;
description
"The maximum number of out-of-order packets.";
}
}
container queuing-algorithm-capabilities {
description
"All queuing algorithms that a LTP supports.";
uses detnet-queuing-algorithms;
}
list queues {
key "queue-identifier";
description
"A list of DetNet queues.";
leaf queue-identifier {
type uint32;
description
"The identifier of the queue.";
}
leaf queue-buffer-size {
type uint32;
description
"The size of the queue with unit of bytes.";
}
container enabled-queuing-algorithm {
description
"The queuing algorithms that are enabled on the queue.";
uses detnet-queuing-algorithms;
}
leaf minimum-queuing-delay{
type uint32;
description
"The minimum queuing delay of the queue.
The unit of the delay is microsecond(us)";
}
leaf maximum-queuing-delay{
type uint32;
description
"The maximum queuing delay of the queue.
The unit of the delay is microsecond(us)";
}
leaf maximum-queuing-delay-variation{
type uint32;
description
"The maximum queuing delay variation of the queue.
The unit of the delay variation is microsecond(us)";
}
}
}
augment "/nw:networks/nw:network/nw:network-types/tet:te-topology"{
description
"Introduce new network type for TE topology.";
container detnet-topology {
presence "Indicates DetNet topology.";
description
"Its presence identifies the DetNet topology type";
}
}
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes" {
when "../../../nw:network-types/tet:te-topology/"
+ "detnet-topology:detnet-topology" {
description
"Augmentation parameters apply only for networks with
DetNet topology type.";
}
description
"Augmentation parameters apply for DetNet node attributes.";
container detnet-node-attributes {
description
"Attributes for DetNet node.";
uses detnet-node-attributes;
}
}
augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes" {
when "../../../nw:network-types/tet:te-topology/"
+ "detnet-topology:detnet-topology" {
description
"Augmentation parameters apply only for networks with
DetNet topology type.";
}
description
"Augmentation parameters apply for DetNet link attributes.";
container detnet-link-attributes {
description
"Attributes for DetNet link.";
uses detnet-link-attributes;
}
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point/"
+ "tet:te" {
when "../../../nw:network-types/tet:te-topology/"
+ "detnet-topology:detnet-topology" {
description
"Augmentation parameters apply only for networks with
DetNet topology type.";
}
description
"Augmentation parameters apply for DetNet
link termination point.";
container detnet-terminate-point-attributes {
description
"Attributes for DetNet link terminate point.";
uses detnet-terminate-point-attributes;
}
}
} //topology module
<CODE ENDS>
7.2. DetNet Flow Configuration YANG Model
<CODE BEGINS> file "ietf-detnet-flow@20180910.yang" <CODE BEGINS> file "ietf-detnet-config@20190114.yang"
module ietf-detnet-flow-config { module ietf-detnet-config {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-flow-config"; namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-flow-config";
prefix "detnet-flow"; prefix "detnet-flow";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
import ietf-inet-types{ import ietf-inet-types{
prefix "inet"; prefix "inet";
skipping to change at page 45, line 16 skipping to change at page 31, line 5
description description
"End station container."; "End station container.";
uses detnet-service-proxy-instance; uses detnet-service-proxy-instance;
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
8. DetNet Configuration Model Classification 6. DetNet Configuration Model Classification
This section defines three classes of DetNet configuration model: This section defines three classes of DetNet configuration model:
fully distributed configuration model, fully centralized fully distributed configuration model, fully centralized
configuration model, hybrid configuration model, based on different configuration model, hybrid configuration model, based on different
network architectures, showing how configuration information network architectures, showing how configuration information
exchanges between various entities in the network. exchanges between various entities in the network.
8.1. Fully Distributed Configuration Model 6.1. Fully Distributed Configuration Model
In a fully distributed configuration model, UNI information is In a fully distributed configuration model, UNI information is
transmitted over DetNet UNI protocol from the user side to the transmitted over DetNet UNI protocol from the user side to the
network side; then UNI information and network configuration network side; then UNI information and network configuration
information propagate in the network over distributed control plane information propagate in the network over distributed control plane
protocol. For example: protocol. For example:
1) IGP collects topology information and DetNet capabilities of 1) IGP collects topology information and DetNet capabilities of
network([I-D.geng-detnet-info-distribution]); network([I-D.geng-detnet-info-distribution]);
skipping to change at page 46, line 5 skipping to change at page 31, line 41
Current distributed control plane protocol,e.g., RSVP-TE[RFC3209], Current distributed control plane protocol,e.g., RSVP-TE[RFC3209],
SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while
the configuration of a fine-grained schedule, e.g.,Time Aware the configuration of a fine-grained schedule, e.g.,Time Aware
Shaping(TAS) defined in [IEEE802.1Qbv], is not supported. Shaping(TAS) defined in [IEEE802.1Qbv], is not supported.
The fully distributed configuration model is not covered by this The fully distributed configuration model is not covered by this
draft. It should be discussed in the future DetNet control plane draft. It should be discussed in the future DetNet control plane
work. work.
8.2. Fully Centralized Configuration Model 6.2. Fully Centralized Configuration Model
In the fully centralized configuration model, UNI information is In the fully centralized configuration model, UNI information is
transmitted from Centralized User Configuration (CUC) to Centralized transmitted from Centralized User Configuration (CUC) to Centralized
Network Configuration(CNC). Configurations of routers for DetNet Network Configuration(CNC). Configurations of routers for DetNet
flows are performed by CNC with network management protocol. For flows are performed by CNC with network management protocol. For
example: example:
1) CNC collects topology information and DetNet capability of network 1) CNC collects topology information and DetNet capability of network
through Netconf; through Netconf;
2) CNC receives a flow establishment request from UNI and calculates 2) CNC receives a flow establishment request from UNI and calculates
a/some valid path(s); a/some valid path(s);
3) CNC configures the devices along the path for flow transmission. 3) CNC configures the devices along the path for flow transmission.
8.3. Hybrid Configuration Model 6.3. Hybrid Configuration Model
In the hybrid configuration model, controller and control plane In the hybrid configuration model, controller and control plane
protocols work together to offer DetNet service, and there are a lot protocols work together to offer DetNet service, and there are a lot
of possible combinations. For example: of possible combinations. For example:
1) CNC collects topology information and DetNet capability of network 1) CNC collects topology information and DetNet capability of network
through IGP/BGP-LS; through IGP/BGP-LS;
2) CNC receives a flow establishment request from UNI and calculates 2) CNC receives a flow establishment request from UNI and calculates
a/some valid path(s); a/some valid path(s);
skipping to change at page 47, line 32 skipping to change at page 33, line 22
more typical scenarios and give a practical solution. more typical scenarios and give a practical solution.
2. [IEEE802.1Qcc] also defines three TSN configuration models: 2. [IEEE802.1Qcc] also defines three TSN configuration models:
fully-centralized model, fully-distributed model, centralized Network fully-centralized model, fully-distributed model, centralized Network
/ distributed User Model. This section defines the configuration / distributed User Model. This section defines the configuration
model roughly the same, to keep the design of L2 and L3 in the same model roughly the same, to keep the design of L2 and L3 in the same
structure. Hybrid configuration model is slightly different from the structure. Hybrid configuration model is slightly different from the
'centralized Network / distributed User Model'. The hybrid 'centralized Network / distributed User Model'. The hybrid
configuration model intends to contain more variations. configuration model intends to contain more variations.
9. Open issues 7. Open Issues
There are some open issues that are still under disccusion: There are some open issues that are still under discussion:
o The Relationship with 802.1 TSN YANG models is TBD. TSN YANG o The Relationship with 802.1 TSN YANG models is TBD. TSN YANG
models include: P802.1Qcw, which defines TSN YANG for Qbv, Qbu, models include: P802.1Qcw, which defines TSN YANG for Qbv, Qbu,
and Qci, and P802.1CBcv, which defines YANG for 802.1CB. The and Qci, and P802.1CBcv, which defines YANG for 802.1CB. The
possible problem here is how to avoid possible overlap among yang possible problem here is how to avoid possible overlap among yang
models defined in IETF and IEEE. A common YANG model may be models defined in IETF and IEEE. A common YANG model may be
defined in the future to shared by both TSN and DetNet. More defined in the future to shared by both TSN and DetNet. More
discussion are needed here. discussion are needed here.
o How to suppport DetNet OAM is TBD. o How to support DetNet OAM is TBD.
These issues will be resolved in the following versions of the draft. These issues will be resolved in the following versions of the draft.
10. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 9. Security Considerations
<TBD> <TBD>
12. Acknowledgements 10. Acknowledgements
13. References 11. References
13.1. Normative References 11.1. Normative References
[I-D.finn-detnet-bounded-latency] [I-D.finn-detnet-bounded-latency]
Finn, N., Boudec, J., Mohammadpour, E., Varga, B., and J. Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga,
Farkas, "DetNet Bounded Latency", draft-finn-detnet- B., and J. Farkas, "DetNet Bounded Latency", draft-finn-
bounded-latency-01 (work in progress), July 2018. detnet-bounded-latency-02 (work in progress), October
2018.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-08 (work in progress), September 2018. detnet-architecture-10 (work in progress), December 2018.
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
Korhonen, J. and B. Varga, "DetNet IP Data Plane Korhonen, J. and B. Varga, "DetNet IP Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-ip-00 (work in Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in
progress), July 2018. progress), October 2018.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-00 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
progress), July 2018. progress), October 2018.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., rodney.cummings@ni.com, r., Jiang, Farkas, J., Varga, B., Cummings, R., Jiang, Y., and Y.
Y., and Y. Zha, "DetNet Flow Information Model", draft- Zha, "DetNet Flow Information Model", draft-ietf-detnet-
ietf-detnet-flow-information-model-01 (work in progress), flow-information-model-02 (work in progress), October
March 2018. 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
13.2. Informative References 11.2. Informative References
[I-D.geng-detnet-info-distribution] [I-D.geng-detnet-info-distribution]
Geng, X., Chen, M., and Z. Li, "IGP-TE Extensions for Geng, X., Chen, M., and Z. Li, "IGP-TE Extensions for
DetNet Information Distribution", draft-geng-detnet-info- DetNet Information Distribution", draft-geng-detnet-info-
distribution-02 (work in progress), March 2018. distribution-03 (work in progress), October 2018.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018. ietf-detnet-use-cases-20 (work in progress), December
2018.
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and
I. Bryskin, "A YANG Data Model for Traffic Engineering I. Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work Tunnels and Interfaces", draft-ietf-teas-yang-te-17 (work
in progress), July 2018. in progress), October 2018.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-18 (work in Topologies", draft-ietf-teas-yang-te-topo-18 (work in
progress), June 2018. progress), June 2018.
[I-D.thubert-tsvwg-detnet-transport] [I-D.thubert-tsvwg-detnet-transport]
Thubert, P., "A Transport Layer for Deterministic Thubert, P., "A Transport Layer for Deterministic
Networks", draft-thubert-tsvwg-detnet-transport-01 (work Networks", draft-thubert-tsvwg-detnet-transport-01 (work
skipping to change at page 51, line 8 skipping to change at page 37, line 8
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
Authors' Addresses Authors' Addresses
Xuesong Geng Xuesong Geng
Huawei Huawei Technologies
Email: gengxuesong@huawei.com Email: gengxuesong@huawei.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei Technologies
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Zhenqiang Li Zhenqiang Li
China Mobile China Mobile
Email: lizhenqiang@chinamobile.com Email: lizhenqiang@chinamobile.com
Reshad Rahman Reshad Rahman
Cisco Systems Cisco Systems
 End of changes. 45 change blocks. 
712 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/