| Internet-Draft | Services Deployment Guideline in DetNet | October 2021 |
| Dang, et al. | Expires 12 April 2022 | [Page] |
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.¶
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 12 April 2022.¶
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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, it's the right time for DetNet deployment to do the live network experiments and even large-scale commercial deployments. 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. And the DetNet network belongs to the L3 layer network.¶
The processes of consists of deployment preparation, planning and configuration. Session 4 illustrates what information needs to be collected and how to use them and how to input the collected parameters into the network planning system. In session 5, the controller executes the operation instructions to generate configurations and even calculates specific explicit paths. Session 6 and the network element node performs configuration and path information received from the controller.¶
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 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.¶
Before deployment, a DetNet network administrator must first fully understand the concept of DetNet service defined in session 4.3 of RFC 8655, DetNet flow defined in RFC 9016, and explicit route defined in defined in session 3.2.3 of RFC8655. The essence of DetNet service deployment is to map the DetNet service to the corresponding DetNet flow, and then use the relevant explicit path to transmit on the network.¶
Next, the DetNet network administrator must investigate and understand the status of the network. After that she/he should input the information collected onto the DetNet planning tool, which may be integrated in the controller or appears as an independent system. The DetNet planning tool should have a certain degree of automation capabilities.¶
In this document, we do not introduce the connectivity deployment (such as IGP, BGP) of the basic network, and assume that the basic network connections are ready.¶
The DetNet network administrator must figure out the related DetNet system where DetNet service to be deployed. The DetNet system should include DetNet Edge and Transit Nodes, which node the DetNet flow will passes through via explicit paths. The DetNet network administrator must know the specific location of the relevant network nodes of DetNet system, which should be single-domain or cross-domain. If the DetNet network is cross-domain, some Transit Nodes may also perform the functions of ASBR.¶
The DetNet network administrator should collect the parameters of DetNet service and DetNet flow.¶
According to session 6 of RFC 9016, the management ID, delivery type, delivery profile, connectivity type and BiDir requirement and rank of the Detnet services should be collected.¶
According to session 5 of RFC9016, the management ID, payload type, format, identification and specification, endpoints, rank, requirement and BiDir Requirement of the Detnet flows should be collected. The flow identification for MPLS and IP Data Planes are described in [RFC8939] , [RFC8964], and Ethernet information (such as MAC address, VLAN) respectively.¶
The DetNet network administrator must plan how to map the DetNet services into a DetNet flow. If a DetNet service wants to join DetNet flow, the premise is that the encapsulation types of both of them must be the same and DetNet Edges to be used are same. About the encapsulation types, that is, the Delivery Type of the DetNet Service must be equal to the Payload Type of the DetNet Flow. Then it is necessary to determine whether the Requirements of the DetNet Flow can meet the requirements of the Delivery Profile of the DetNet Service. First, it is seen if MaxLatency, MaxLatencyVariation, MaxLoss, MaxConsecutiveLossTolerance, MaxMisordering are satisfied. If they are satisfied, it is judged whether MinBandwidth can be satisfied. The above work should be done using automation functions. It is finally determined that the DetNet services will join a DetNet flow, then a Management ID of the DetNet Flow is assigend to this DetNet services. To explain further, Management ID of the DetNet Flow, which is a unique identifier for identifying each DetNet flow, can be used to define the N:1 mapping of DetNet flows to a DetNet service.¶
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.¶
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.¶
The endpoints, where the Detnet service will access to and explicit paths will be running between, must be within the scope of the DetNet system. Based on the endpoints of the DetNet flow, the related DetNet Ingress PE and Egress PE are determined. The DetNet Ingress PE and Egress PE can run more than one explicit path to implement service protection and reordering on DetNet Edge nodes.¶
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 spreading the data over multiple disjointed forwarding paths. The PREOF embeded in the PE node ensures that packets are not out of order.¶
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.¶
Based on the traffic specification and rank of the DetNet flow, the buffer settings of the queue, including Guaranteed-Service IntServ, Cyclic Queuing and Forwarding and so on, need to refer to Internal, MaxPacketsPerInterval, MaxPayloadSize, MinPacketsPerInterval and DnFlowRank within them.¶
The DetNet network administrator obtains or sets the queuing type used by the network. For examplem, if the cyclic queuing mechanism is used in the network, the parameters of the queuing. This mechanism must allow multiple deterministic flows to share a periodic buffer.¶
The DetNet network administrator can enable network resource evaluation and reservation of the controller. The requirements of DetNet flow in section 5.9 of [RFC9016] include MinBandwidth, MaxLatency, MaxLoss, MaxConsecutiveLossTolerance and MaxMisordering. If the deterministic flow has requirement for Jitter, a new parameter named jitter needs to be added.¶
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.¶
Based on Requirements of DetNet flow, the resource reservation algorithm must completely satisfy them. Regarding MaxLatency, there are different precision degree of mechanisms, one is to seek a maximum degree of approximation, the other is to ensure accuracy. The CFQ mechanism is recommended when resource reservation works well.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The DetNet network administrator should let the planning tool connect to DetNet controller defined in draft-ietf-detnet-controller-plane-framework ,or the planning tool should automatically to notisfy the DetNet controller after the work finised in the planning tool. As draft-ietf-detnet-controller-plane-framework describes, the DetNet control plane is responsible for the instantiation and maintenance of DetNet services and DetNet flows and explicit path, for the functions of resource reservation, path caculation and service protection.¶
Finally, the DetNet controller should generate configuration and path information and download them on demand to the related DetNet network nodes.¶
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.¶
The DetNet network administrator should check the operation of the DetNet network nodes.¶
The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]).¶
After DetNet network node receives the information from the controller, the function will be executed.¶
Basic Network Configuration among DetNet Network nodes:¶
Ingress Node DetNet services Configuration:¶
Egress Node DetNet services Configuration:¶
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¶
The DetNet network administrator should work accroding to RFC 9055 which addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.¶