DetNet J. Dang, Ed.
Internet-Draft Huawei
Intended status: Informational Z. Du
Expires: January 13, 2022 China Mobile
July 12, 2021
Services Deployment Guideline in DetNet Network
draft-dang-detnet-deployment-00
Abstract
Deterministic Networking (DetNet) defined in [RFC8655] provides a
capability for the delivery of data flows with extremely low packet
loss rates and bounded end-to-end delivery latency. DetNet network
administrators worldwide can deploy DetNet services into their
networks. This document aims to provide a guideline for DetNet
network administrators.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Dang & Du Expires January 13, 2022 [Page 1]
Internet-Draft July 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3
4. Preparation of DetNet networks . . . . . . . . . . . . . . . 3
5. How to Introduce Deterministic Flow into DetNet network . . . 4
5.1. Parameter Specification . . . . . . . . . . . . . . . . . 4
5.1.1. Definition of Deterministic Flow . . . . . . . . . . 5
5.1.2. Establishing Explicit Path . . . . . . . . . . . . . 6
5.2. DetNet Network Element Configuration and Functions . . . 9
6. How to Maintain Deterministic Flow in DetNet network . . . . 9
7. How to Withdraw Deterministic Flow in DetNet network . . . . 10
8. Deployment Trial Experience . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Deterministic Networking (DetNet) defined in [RFC8655] provides a
capability for the delivery of data flows with extremely low packet
loss rates and bounded end-to-end delivery latency. The diverse
industries in [RFC8578] have in common a need for "deterministic
flows". How to introduce deterministic flows to the DetNet network
is required.
While the DetNet technologies are becoming mature, the DetNet
deployment is about to enter the live network experiment and even to
large-scale commercial deployment. The DetNet network is actively
managed by a network operations entity (the "administrator", whether
a single person or a department of administrators). A network
administrator is responsible for the deployment of DetNet services,
who can must master the skills of how to introduce deterministic
flows into DetNet networks and the related maintenance.
This document is intended as guidance for DetNet network
administrators.
2. Requirements Language
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.
Dang & Du Expires January 13, 2022 [Page 2]
Internet-Draft July 2021
3. Terminology & Abbreviations
DetNet UPE
A DetNet edge node, which connects DetNet flows into DetNet network.
DetNet P
A DetNet relay node or DetNet transit node.
DetNet PE
A DetNet edge node, where DetNet flows leave DetNet network.
DetNet source
An end system is capable of originating a DetNet flow.
DetNet Destination
An end system is capable of terminating a DetNet flow.
4. Preparation of DetNet networks
The premise of this section is that the network has not yet enabled
DetNet capability. First of all, a network administrator must enable
the DetNet capability of the network on demand.
The DetNet network administrator must plan the scope of DetNet
network, DetNet network topology and DetNet network element roles.
As usual, the network controller has collected the topology of the
entire network. So the DetNet network administrators only need to
specify the scope of DetNet networks, DetNet network topology and
DetNet network element roles on the controller interface. When the
scope of the DetNet network is determined, the DetNet network
administrators can naturally get the DetNet network topology. At
that time, the DetNet network administrators must figure out whether
the DetNet network is in a single domain or in multiple domains.
o If in a single domain, it contains DetNet Ingress UPE nodes,
DetNet P nodes, DetNet PE nodes. In fact, a P node may be
connected to multiple different UPE devices or PE nodes or P node.
o If in multiple domains, it also contains ASBR nodes in addition to
Ingress UPE nodes, DetNet P nodes and DetNet PE nodes, for the
purpose of cross-domain interconnection.
Dang & Du Expires January 13, 2022 [Page 3]
Internet-Draft July 2021
The example is shown in Figure 1, which contain DetNet Ingress UPE
node, DetNet P nodes, DetNet PE node. In fact, a P node may be
connected to multiple different UPE devices or PE nodes or P node.
DetNet DetNet
Source Destination
DetNet-UNI (U)
+--+--+ | +--+--+
| | | | |
+--+--+ v +--+--+
| |
| +----+ +---+ +---+ +---+ |
+----U PE +---+ P +---+...+---+ PE+----+
+----+ +---+ +---+ +---+
| |
| End-to-End Service |
|------------------------------------->|
| Explicit Routes (DetNet Network) |
| |--------------------------->| |
Figure-1: DetNet Network
5. How to Introduce Deterministic Flow into DetNet network
For the next work, the DetNet network administrator must specify the
following information on the controller.
1. Definition of Deterministic Flow
2. Establishing Explicit Path for Deterministic Flow
* Definition of Deterministic Flow
* Specifying Encapsulation Type of Networking Technology
* Specifying Type of Queuing Mechanism
* Definition of Service Protection
* Network Resource Evaluation and Reservation
The section 5.1 focus on how to use these parameters.
5.1. Parameter Specification
Dang & Du Expires January 13, 2022 [Page 4]
Internet-Draft July 2021
5.1.1. Definition of Deterministic Flow
A DetNet network administrator must figure out
o how to identify a deterministic flow,
o the related DetNet SLA requirements,
o which node the DetNet flow is accessed from and which node the
DetNet flow leaves from.
This above information must be given the DetNet network administrator
by DetNet service providers who initiate or terminate DetNet flows.
The flow identification in [RFC9016] let the DetNet UPE node identify
the flow. Flow identification for MPLS and IP Data Planes are
described in [RFC8939] , [RFC8964], and Ethernet information (such as
MAC address, VLAN) respectively.
o IP Data plane: five tuple
o Ethernet data plane: MAC address or VLAN
o MPLS or SR data plane: label
The SLA information of DetNet flow in section 5.9 of [RFC9016] are
listed as follows.
o MinBandwidth
o MaxLatency
o MaxLoss
o MaxConsecutiveLossTolerance
o MaxMisordering
If the deterministic flow has requirement for Jitter, a new parameter
named jitter needs to be added.
In the follow-up work, the DetNet network administrator creates
explicit route defined in section 3.2.3 of [RFC8655] according to the
information which node the DetNet flow is accessed from and which
node the DetNet flow leaves from.
Dang & Du Expires January 13, 2022 [Page 5]
Internet-Draft July 2021
5.1.2. Establishing Explicit Path
The DetNet network administrator must pay attention to the
encapsulation type of the explicit route, which is added to the
DetNet flows when DetNet flow enters the UPE node. The DetNet
network administrator may freely choose encapsulation type of the
networking technology according to his/her preferences. The way of
IP over SR or [IP-Over-MPLS] or IP over SR) is recommended.
5.1.2.1. Encapsulation Type of Networking Technology
The DetNet network administrator must pay attention to the
encapsulation type of the explicit route, which is added to the
DetNet flows when DetNet flow enters the UPE node. The DetNet
network administrator may freely choose encapsulation type of the
networking technology according to his/her preferences. The way of
IP over SR or [IP-Over-MPLS] or IP over SR) is recommended.
5.1.2.2. Type of Queuing Mechanism
The DetNet network administrator obtains or sets the queuing type
used by the network. If the cyclic queuing mechanism is used in the
network, the parameters of the queuing need to be set as follows.
This mechanism must allow multiple deterministic flows to share a
periodic buffer.
o CyclicBufferSize: the length of the cyclic buffer
o CyclicInterval: duration of periodic scheduling
o BufferNumber: the number of the cyclic buffer
o MinBurstSize: the minimum burst size that can be tolerated by
cyclic queue mechanism, which is specified in octets per second
and excludes additional DetNet header (if any).Bandwidth used
above the Committed Information rate is called Burst traffic. It
is used when the bandwidth available is more than CIR.
MinBurstSize is the minimum burst size that has to be guaranteed
for the DetNet traffic. The queuing mechanism needs to pay
attention to how to shape burst size traffic into buffers.
5.1.2.3. Definition of Service Protection
The DetNet network administrator can consider how to do with service
protection to meet MaxLoss, MaxConsecutiveLossTolerance and
MaxMisordering of a deterministic flow. The premise of service
protection is that there are multiple available explicit paths for a
DetNet flow. These types of packet loss can be greatly reduced by
Dang & Du Expires January 13, 2022 [Page 6]
Internet-Draft July 2021
spreading the data over multiple disjointed forwarding paths. The
PREOF embeded in the PE node ensures that packets are not out of
order.
5.1.2.4. Network Resource Evaluation and Reservation
The DetNet network administrator can enable network resource
evaluation and reservation of the controller. In fact, the network
may support a distributed protocol similar to RSVP defined in
[draft-trossen-detnet-rsvp-tsn], so this function can rely on the
distributed protocol.
The DetNet SLA requirements to the DetNet flow generally have
deterministic bandwidth, bounded latency and bounded jitter. But in
fact these three parameters are interrelated. For example, the
insufficient bandwidth reservation might introduce the additional
delay or the additional jitter. Therefore, the bandwidth reservation
should consider the latency and jitter requirements.
There are three methods here to do with, one is to get it through
centralized calculation provided by controller or other centralized
systems, the other is to get it through negotiation between DetNet
Nodes along the explicit routes, and the third is to rely on the
human brain. When the scale of the network becomes larger or the
types of services become more, the third method is difficult to
handle. Therefore, the first and the second methods are recommended.
These centralized and distributed solutions can cooperate with each
other, for example, if the centralized system is offline, the
distributed system functions will be enabled. Or in order to support
rapid network decision-making, the priority is given to using
distributed systems for deployment, and the centralized systems are
responsible for global optimization.
The algorithm on the network resource reservation is not discussed
now in this document.
5.1.2.4.1. DetNet Bandwidth Evaluation and Reservation
The DetNet network administrator must know the bandwidth resource
evaluation and reservation can be divided into service access
interface part on the DetNet UPE node and explicit route part.
o Service access interface part on the DetNet UPE node: The
bandwidth of service access interface part on the DetNet UPE is
reserved according to the MinBandwidth of the DetNet flow.
Dang & Du Expires January 13, 2022 [Page 7]
Internet-Draft July 2021
o Explicit route part: This mechanism ensures that the available
bandwidth along the explicit path can meet MinBandwidth of DetNet
flow.
The P node should take into account that there are multiple explicit
routes passing in the same direction. For example, if one interface
of P node accesses 3 explicit paths, the reserved bandwidth of the
interface is the total required bandwidth of the 3 explicit paths.
It is emphasized that the remaining bandwidth of the interface on the
DetNet nodes can also be used for non-DetNet flows.
5.1.2.4.2. DetNet Latency Evaluation
The DetNet network administrator can let the controller collect the
network-wide delay information for calculation and evaluation, and
obtain the queuing type.
Given that DetNet nodes have a finite amount of buffer space, the
resource allocation necessarily results in a maximum end-to-end
latency. The overall latency of the explicit route can be calculated
based on the queue scheduling mechanism on the data plane of the
DetNet nodes. The queue scheduling mechanisms have various types,
such as DiffServ,Qch[IEEE802.1QCH] and so on.
[DetNet-Bounded-Latency] provides end-to-end delay bound and backlog
bound computations for such mechanisms that can be used by the
control plane to provide DetNet QoS. If the CQF is used,
CyclicBufferSize, CyclicInterval and BufferNumber of queuing
mechanism can be included in the calculation factors that affect the
E2E delay.
The controller evaluates the path delay based on the resources of the
entire network, and judges whether it meets the MaxLatency of the
deterministic flow.
5.1.2.4.3. DetNet Jitter Evaluation
The DetNet network administrator can figure out that there are two
aspects to reduce network jitter. The first is through resource
reservation in section 4.4.1 to 4.4.2 , and the second is through
effective queuing control methods. The former is not easy to
evaluate jitter, but the latter is very convenient. The DetNet
network administrator also can know the queuing type, because not all
queuing mechanisms have a jitter control mechanism. The CQF is
recommend to effectively solve the uncertainty of jitter. Under this
mechanism, the end to end jitter can be controlled within 2 *
CyclicInterval.
Dang & Du Expires January 13, 2022 [Page 8]
Internet-Draft July 2021
5.2. DetNet Network Element Configuration and Functions
After the information is input by the DetNet network administrator,
the controller will convert the information into the network
configuration and send it to the DetNet network element node, using a
protocol such as NETCONF [RFC6241]/YANG[RFC6020]. Deterministic
Networking (DetNet) YANG Model defined in [DetNet-YANG] contains the
specification for the Deterministic Networking YANG Model for
configuration and operational data for DetNet Flows.
After DetNet network equipment receives the configuration, it starts
to execute. As Figure 2 is shown, the functions of each DetNet
network element is clearly visible.
SDN +----+ 1.Entrance to the above information
Controller | | 2.Network Resource Evaluation and Reservation(Optional)
+----+ 3.Converting the information into the network configuration
|
+--------+-------+------+
| | | |
+----+ +---+ +---+ +---+
U PE +---+ P +---+...+---+ PE+
+----+ +---+ +---+ +---+
| | |
| | +-->+-----------------------------+
| | |1. Enabling queuing mechanism|
| | |2. End Explicit Path |
| | +-----------------------------+
| +-->+--------------------------+
| |Enabling queuing mechanism|
| +--------------------------+
+--> +-------------------------------------------------------+
|1.Identifying a deterministic flow |
|2.Establishing explicit path for the deterministic flow|
|3.Enabling queuing mechanism |
+-------------------------------------------------------+
Figure-2: DetNet Network Functions
6. How to Maintain Deterministic Flow in DetNet network
TBD
If a new DetNet flow needs to be added into the existing DetNet
network, the network administrators will operate according to section
4.1~4.5.
Dang & Du Expires January 13, 2022 [Page 9]
Internet-Draft July 2021
7. How to Withdraw Deterministic Flow in DetNet network
TBD
If a DetNet flow deployed needs to be canceled, the network
administrator will execute the corresponding undo operation through
the controller, and the network will release the corresponding
resources.
8. Deployment Trial Experience
TBD
9. Security Considerations
TBD
10. Acknowledgements
TBD
11. Normative References
[DetNet-Bounded-Latency]
"DetNet Bounded Latency", <https://www.rfc-
editor.org/info/draft-ietf-detnet-bounded-latency>.
[DetNet-YANG]
"Deterministic Networking (DetNet) YANG Model",
<https://www.rfc-editor.org/info/draft-ietf-detnet-yang-
12>.
[draft-trossen-detnet-rsvp-tsn]
"RSVP for TSN Networks", <https://www.rfc-editor.org/info/
draft-trossen-detnet-rsvp-tsn>.
[IEEE802.1QCH]
"IEEE Standard for Local and metropolitan area networks--
Bridges and Bridged Networks--Amendment 29: Cyclic Queuing
and Forwarding",
<https://ieeexplore.ieee.org/document/7961303>.
[IP-Over-MPLS]
"DetNet Data Plane: IP over MPLS", <https://www.rfc-
editor.org/info/draft-ietf-detnet-ip-over-mpls>.
Dang & Du Expires January 13, 2022 [Page 10]
Internet-Draft July 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels",
<https://www.rfc-editor.org/info/rfc3209>.
[RFC6020] "YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)",
<https://www.rfc-editor.org/info/RFC6020>.
[RFC6241] "Network Configuration Protocol (NETCONF)",
<https://www.rfc-editor.org/info/RFC6241>.
[RFC8402] "Segment Routing Architecture",
<https://www.rfc-editor.org/info/RFC8402>.
[RFC8578] "Deterministic Networking Use Cases",
<https://www.rfc-editor.org/info/rfc8578>.
[RFC8655] "Deterministic Networking Architecture",
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8934] "Deterministic Networking (DetNet) Data Plane: MPLS",
<https://www.rfc-editor.org/info/rfc8934>.
[RFC8939] "Deterministic Networking (DetNet) Data Plane: IP",
<https://www.rfc-editor.org/info/rfc8939>.
[RFC8964] "Deterministic Networking (DetNet) Data Plane: MPLS",
<https://www.rfc-editor.org/info/rfc8964>.
[RFC9016] "Flow and Service Information Model for Deterministic
Networking (DetNet)",
<https://www.rfc-editor.org/info/RFC9016>.
[RFC9023] "Deterministic Networking (DetNet) Data Plane: IP over
IEEE 802.1 Time-Sensitive Networking (TSN)",
<https://www.rfc-editor.org/info/rfc9023>.
Authors' Addresses
Dang & Du Expires January 13, 2022 [Page 11]
Internet-Draft July 2021
Joanna Dang (editor)
Huawei
No.156 Beiqing Road
Beijing, P.R. China 100095
China
Email: dangjuanna@huawei.com
Zongpeng Du
China Mobile
32 Xuanwumen West St
Beijing, P.R. China 100053
China
Email: duzongpeng@chinamobile.com
Dang & Du Expires January 13, 2022 [Page 12]