< draft-dang-detnet-deployment-00.txt		draft-dang-detnet-deployment-01.txt >
	DetNet J. Dang, Ed.		DetNet J. Dang, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Informational Z. Du		Intended status: Informational Z. Du
	Expires: January 13, 2022 China Mobile		Expires: 12 April 2022 China Mobile
	July 12, 2021		L. Li, Ed.
			Huawei
			9 October 2021
	Services Deployment Guideline in DetNet Network		Services Deployment Guideline in DetNet Network
	draft-dang-detnet-deployment-00		draft-dang-detnet-deployment-01
	Abstract		Abstract
	Deterministic Networking (DetNet) defined in [RFC8655] provides a		Deterministic Networking (DetNet) defined in [RFC8655] provides a
	capability for the delivery of data flows with extremely low packet		capability for the delivery of data flows with extremely low packet
	loss rates and bounded end-to-end delivery latency. DetNet network		loss rates and bounded end-to-end delivery latency. DetNet network
	administrators worldwide can deploy DetNet services into their		administrators worldwide can deploy DetNet services into their
	networks. This document aims to provide a guideline for DetNet		networks. This document aims to provide a guideline for DetNet
	network administrators.		network administrators.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 38 ¶
	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 January 13, 2022.		This Internet-Draft will expire on 12 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3		3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3
	4. Preparation of DetNet networks . . . . . . . . . . . . . . . 3		4. Preparation and Planning of DetNet networks . . . . . . . . . 3
	5. How to Introduce Deterministic Flow into DetNet network . . . 4		4.1. Collecting and Planning information of DetNet system . . 4
	5.1. Parameter Specification . . . . . . . . . . . . . . . . . 4		4.2. Collecting and Planning parameters of DetNet service and
	5.1.1. Definition of Deterministic Flow . . . . . . . . . . 5		DetNet flow . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1.2. Establishing Explicit Path . . . . . . . . . . . . . 6		4.2.1. Explicit Path and Service Protection . . . . . . . . 5
	5.2. DetNet Network Element Configuration and Functions . . . 9		4.2.2. Encapsulation Type of Networking Technology . . . . . 5
	6. How to Maintain Deterministic Flow in DetNet network . . . . 9		4.2.3. Type of Queuing Mechanism . . . . . . . . . . . . . . 6
	7. How to Withdraw Deterministic Flow in DetNet network . . . . 10		4.3. DetNet Resource Evaluation . . . . . . . . . . . . . . . 6
	8. Deployment Trial Experience . . . . . . . . . . . . . . . . . 10		4.3.1. DetNet Bandwidth Evaluation and Reservation . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4.3.2. DetNet Latency Evaluation . . . . . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		4.3.3. DetNet Jitter Evaluation . . . . . . . . . . . . . . 8
	11. Normative References . . . . . . . . . . . . . . . . . . . . 10		5. Controller Processing and Operation . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		6. Performed Functions on DetNet Network Node . . . . . . . . . 9
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
			8. Normative References . . . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Deterministic Networking (DetNet) defined in [RFC8655] provides a		Deterministic Networking (DetNet) defined in [RFC8655] provides a
	capability for the delivery of data flows with extremely low packet		capability for the delivery of data flows with extremely low packet
	loss rates and bounded end-to-end delivery latency. The diverse		loss rates and bounded end-to-end delivery latency. The diverse
	industries in [RFC8578] have in common a need for "deterministic		industries in [RFC8578] have in common a need for "deterministic
	flows". How to introduce deterministic flows to the DetNet network		flows". How to introduce deterministic flows to the DetNet network
	is required.		is required.
	While the DetNet technologies are becoming mature, the DetNet		While the DetNet technologies are becoming mature, it's the right
	deployment is about to enter the live network experiment and even to		time for DetNet deployment to do the live network experiments and
	large-scale commercial deployment. The DetNet network is actively		even large-scale commercial deployments. The DetNet network is
	managed by a network operations entity (the "administrator", whether		actively managed by a network operations entity (the "administrator",
	a single person or a department of administrators). A network		whether a single person or a department of administrators). A
	administrator is responsible for the deployment of DetNet services,		network administrator is responsible for the deployment of DetNet
	who can must master the skills of how to introduce deterministic		services, who can must master the skills of how to introduce
	flows into DetNet networks and the related maintenance.		deterministic flows into DetNet networks and the related maintenance.
	This document is intended as guidance for DetNet network		This document is intended as guidance for DetNet network
	administrators.		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.
	2. Requirements Language		2. 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.		document are to be interpreted as described in RFC 2119.
	3. Terminology & Abbreviations		3. Terminology & Abbreviations
	DetNet UPE		DetNet UPE
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 42 ¶
	A DetNet edge node, where DetNet flows leave DetNet network.		A DetNet edge node, where DetNet flows leave DetNet network.
	DetNet source		DetNet source
	An end system is capable of originating a DetNet flow.		An end system is capable of originating a DetNet flow.
	DetNet Destination		DetNet Destination
	An end system is capable of terminating a DetNet flow.		An end system is capable of terminating a DetNet flow.
	4. Preparation of DetNet networks		4. Preparation and Planning 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.
	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		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.
	The section 5.1 focus on how to use these parameters.		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.
	5.1. Parameter Specification		In this document, we do not introduce the connectivity deployment
	5.1.1. Definition of Deterministic Flow		(such as IGP, BGP) of the basic network, and assume that the basic
			network connections are ready.
	A DetNet network administrator must figure out		4.1. Collecting and Planning information of DetNet system
	o how to identify a deterministic flow,		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.
	o the related DetNet SLA requirements,		4.2. Collecting and Planning parameters of DetNet service and DetNet
			flow
	o which node the DetNet flow is accessed from and which node the		The DetNet network administrator should collect the parameters of
	DetNet flow leaves from.		DetNet service and DetNet flow.
	This above information must be given the DetNet network administrator		According to session 6 of RFC 9016, the management ID, delivery type,
	by DetNet service providers who initiate or terminate DetNet flows.		delivery profile, connectivity type and BiDir requirement and rank of
			the Detnet services should be collected.
	The flow identification in [RFC9016] let the DetNet UPE node identify		According to session 5 of RFC9016, the management ID, payload type,
	the flow. Flow identification for MPLS and IP Data Planes are		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		described in [RFC8939] , [RFC8964], and Ethernet information (such as
	MAC address, VLAN) respectively.		MAC address, VLAN) respectively.
	o IP Data plane: five tuple		The DetNet network administrator must plan how to map the DetNet
			services into a DetNet flow. If a DetNet service wants to join
	o Ethernet data plane: MAC address or VLAN		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
	o MPLS or SR data plane: label		the encapsulation types, that is, the Delivery Type of the DetNet
			Service must be equal to the Payload Type of the DetNet Flow. Then
	The SLA information of DetNet flow in section 5.9 of [RFC9016] are		it is necessary to determine whether the Requirements of the DetNet
	listed as follows.		Flow can meet the requirements of the Delivery Profile of the DetNet
			Service. First, it is seen if MaxLatency, MaxLatencyVariation,
	o MinBandwidth		MaxLoss, MaxConsecutiveLossTolerance, MaxMisordering are satisfied.
			If they are satisfied, it is judged whether MinBandwidth can be
	o MaxLatency		satisfied. The above work should be done using automation functions.
			It is finally determined that the DetNet services will join a DetNet
	o MaxLoss		flow, then a Management ID of the DetNet Flow is assigend to this
			DetNet services. To explain further, Management ID of the DetNet
	o MaxConsecutiveLossTolerance		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.
	o MaxMisordering		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.
	If the deterministic flow has requirement for Jitter, a new parameter		4.2.1. Explicit Path and Service Protection
	named jitter needs to be added.
	In the follow-up work, the DetNet network administrator creates		In the follow-up work, the DetNet network administrator creates
	explicit route defined in section 3.2.3 of [RFC8655] according to the		explicit route defined in section 3.2.3 of [RFC8655] according to the
	information which node the DetNet flow is accessed from and which		information which node the DetNet flow is accessed from and which
	node the DetNet flow leaves from.		node the DetNet flow leaves from.
	5.1.2. Establishing Explicit Path		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 must pay attention to the		The DetNet network administrator can consider how to do with service
	encapsulation type of the explicit route, which is added to the		protection to meet MaxLoss, MaxConsecutiveLossTolerance and
	DetNet flows when DetNet flow enters the UPE node. The DetNet		MaxMisordering of a deterministic flow. The premise of service
	network administrator may freely choose encapsulation type of the		protection is that there are multiple available explicit paths for a
	networking technology according to his/her preferences. The way of		DetNet flow. These types of packet loss can be greatly reduced by
	IP over SR or [IP-Over-MPLS] or IP over SR) is recommended.		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.1. Encapsulation Type of Networking Technology		4.2.2. Encapsulation Type of Networking Technology
	The DetNet network administrator must pay attention to the		The DetNet network administrator must pay attention to the
	encapsulation type of the explicit route, which is added to the		encapsulation type of the explicit route, which is added to the
	DetNet flows when DetNet flow enters the UPE node. The DetNet		DetNet flows when DetNet flow enters the UPE node. The DetNet
	network administrator may freely choose encapsulation type of the		network administrator may freely choose encapsulation type of the
	networking technology according to his/her preferences. The way of		networking technology according to his/her preferences. The way of
	IP over SR or [IP-Over-MPLS] or IP over SR) is recommended.		IP over SR or [IP-Over-MPLS] or IP over SR is recommended.
	5.1.2.2. Type of Queuing Mechanism		4.2.3. Type of Queuing Mechanism
			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		The DetNet network administrator obtains or sets the queuing type
	used by the network. If the cyclic queuing mechanism is used in the		used by the network. For examplem, if the cyclic queuing mechanism
	network, the parameters of the queuing need to be set as follows.		is used in the network, the parameters of the queuing. This
	This mechanism must allow multiple deterministic flows to share a		mechanism must allow multiple deterministic flows to share a periodic
	periodic buffer.		buffer.
	o CyclicBufferSize: the length of the cyclic buffer		* CyclicBufferSize: the length of the cyclic buffer
	o CyclicInterval: duration of periodic scheduling		* CyclicInterval: duration of periodic scheduling
	o BufferNumber: the number of the cyclic buffer		* BufferNumber: the number of the cyclic buffer
	o MinBurstSize: the minimum burst size that can be tolerated by		* MinBurstSize: the minimum burst size that can be tolerated by
	cyclic queue mechanism, which is specified in octets per second		cyclic queue mechanism, which is specified in octets per second
	and excludes additional DetNet header (if any).Bandwidth used		and excludes additional DetNet header (if any).Bandwidth used
	above the Committed Information rate is called Burst traffic. It		above the Committed Information rate is called Burst traffic. It
	is used when the bandwidth available is more than CIR.		is used when the bandwidth available is more than CIR.
	MinBurstSize is the minimum burst size that has to be guaranteed		MinBurstSize is the minimum burst size that has to be guaranteed
	for the DetNet traffic. The queuing mechanism needs to pay		for the DetNet traffic. The queuing mechanism needs to pay
	attention to how to shape burst size traffic into buffers.		attention to how to shape burst size traffic into buffers.
	5.1.2.3. Definition of Service Protection		4.3. DetNet Resource Evaluation
	The DetNet network administrator can consider how to do with service		The DetNet network administrator can enable network resource
	protection to meet MaxLoss, MaxConsecutiveLossTolerance and		evaluation and reservation of the controller. The requirements of
	MaxMisordering of a deterministic flow. The premise of service		DetNet flow in section 5.9 of [RFC9016] include MinBandwidth,
	protection is that there are multiple available explicit paths for a		MaxLatency, MaxLoss, MaxConsecutiveLossTolerance and MaxMisordering.
	DetNet flow. These types of packet loss can be greatly reduced by		If the deterministic flow has requirement for Jitter, a new parameter
	spreading the data over multiple disjointed forwarding paths. The		named jitter needs to be added.
	PREOF embeded in the PE node ensures that packets are not out of
	order.
	5.1.2.4. Network Resource Evaluation and Reservation		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 network administrator can enable network resource		Based on Requirements of DetNet flow, the resource reservation
	evaluation and reservation of the controller. In fact, the network		algorithm must completely satisfy them. Regarding MaxLatency, there
	may support a distributed protocol similar to RSVP defined in		are different precision degree of mechanisms, one is to seek a
	[draft-trossen-detnet-rsvp-tsn], so this function can rely on the		maximum degree of approximation, the other is to ensure accuracy.
	distributed protocol.		The CFQ mechanism is recommended when resource reservation works
			well.
	The DetNet SLA requirements to the DetNet flow generally have		The DetNet SLA requirements to the DetNet flow generally have
	deterministic bandwidth, bounded latency and bounded jitter. But in		deterministic bandwidth, bounded latency and bounded jitter. But in
	fact these three parameters are interrelated. For example, the		fact these three parameters are interrelated. For example, the
	insufficient bandwidth reservation might introduce the additional		insufficient bandwidth reservation might introduce the additional
	delay or the additional jitter. Therefore, the bandwidth reservation		delay or the additional jitter. Therefore, the bandwidth reservation
	should consider the latency and jitter requirements.		should consider the latency and jitter requirements.
	There are three methods here to do with, one is to get it through		There are three methods here to do with, one is to get it through
	centralized calculation provided by controller or other centralized		centralized calculation provided by controller or other centralized
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 29 ¶
	These centralized and distributed solutions can cooperate with each		These centralized and distributed solutions can cooperate with each
	other, for example, if the centralized system is offline, the		other, for example, if the centralized system is offline, the
	distributed system functions will be enabled. Or in order to support		distributed system functions will be enabled. Or in order to support
	rapid network decision-making, the priority is given to using		rapid network decision-making, the priority is given to using
	distributed systems for deployment, and the centralized systems are		distributed systems for deployment, and the centralized systems are
	responsible for global optimization.		responsible for global optimization.
	The algorithm on the network resource reservation is not discussed		The algorithm on the network resource reservation is not discussed
	now in this document.		now in this document.
	5.1.2.4.1. DetNet Bandwidth Evaluation and Reservation		4.3.1. DetNet Bandwidth Evaluation and Reservation
	The DetNet network administrator must know the bandwidth resource		The DetNet network administrator must know the bandwidth resource
	evaluation and reservation can be divided into service access		evaluation and reservation can be divided into service access
	interface part on the DetNet UPE node and explicit route part.		interface part on the DetNet UPE node and explicit route part.
	o Service access interface part on the DetNet UPE node: The		* Service access interface part on the DetNet UPE node: The
	bandwidth of service access interface part on the DetNet UPE is		bandwidth of service access interface part on the DetNet UPE is
	reserved according to the MinBandwidth of the DetNet flow.		reserved according to the MinBandwidth of the DetNet flow.
	o Explicit route part: This mechanism ensures that the available		* Explicit route part: This mechanism ensures that the available
	bandwidth along the explicit path can meet MinBandwidth of DetNet		bandwidth along the explicit path can meet MinBandwidth of DetNet
	flow.		flow.
	The P node should take into account that there are multiple explicit		The P node should take into account that there are multiple explicit
	routes passing in the same direction. For example, if one interface		routes passing in the same direction. For example, if one interface
	of P node accesses 3 explicit paths, the reserved bandwidth of the		of P node accesses 3 explicit paths, the reserved bandwidth of the
	interface is the total required bandwidth of the 3 explicit paths.		interface is the total required bandwidth of the 3 explicit paths.
	It is emphasized that the remaining bandwidth of the interface on the		It is emphasized that the remaining bandwidth of the interface on the
	DetNet nodes can also be used for non-DetNet flows.		DetNet nodes can also be used for non-DetNet flows.
	5.1.2.4.2. DetNet Latency Evaluation		4.3.2. DetNet Latency Evaluation
	The DetNet network administrator can let the controller collect the		The DetNet network administrator can let the controller collect the
	network-wide delay information for calculation and evaluation, and		network-wide delay information for calculation and evaluation, and
	obtain the queuing type.		obtain the queuing type.
	Given that DetNet nodes have a finite amount of buffer space, the		Given that DetNet nodes have a finite amount of buffer space, the
	resource allocation necessarily results in a maximum end-to-end		resource allocation necessarily results in a maximum end-to-end
	latency. The overall latency of the explicit route can be calculated		latency. The overall latency of the explicit route can be calculated
	based on the queue scheduling mechanism on the data plane of the		based on the queue scheduling mechanism on the data plane of the
	DetNet nodes. The queue scheduling mechanisms have various types,		DetNet nodes. The queue scheduling mechanisms have various types,
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 28 ¶
	bound computations for such mechanisms that can be used by the		bound computations for such mechanisms that can be used by the
	control plane to provide DetNet QoS. If the CQF is used,		control plane to provide DetNet QoS. If the CQF is used,
	CyclicBufferSize, CyclicInterval and BufferNumber of queuing		CyclicBufferSize, CyclicInterval and BufferNumber of queuing
	mechanism can be included in the calculation factors that affect the		mechanism can be included in the calculation factors that affect the
	E2E delay.		E2E delay.
	The controller evaluates the path delay based on the resources of the		The controller evaluates the path delay based on the resources of the
	entire network, and judges whether it meets the MaxLatency of the		entire network, and judges whether it meets the MaxLatency of the
	deterministic flow.		deterministic flow.
	5.1.2.4.3. DetNet Jitter Evaluation		4.3.3. DetNet Jitter Evaluation
	The DetNet network administrator can figure out that there are two		The DetNet network administrator can figure out that there are two
	aspects to reduce network jitter. The first is through resource		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		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		effective queuing control methods. The former is not easy to
	evaluate jitter, but the latter is very convenient. The DetNet		evaluate jitter, but the latter is very convenient. The DetNet
	network administrator also can know the queuing type, because not all		network administrator also can know the queuing type, because not all
	queuing mechanisms have a jitter control mechanism. The CQF is		queuing mechanisms have a jitter control mechanism. The CQF is
	recommend to effectively solve the uncertainty of jitter. Under this		recommend to effectively solve the uncertainty of jitter. Under this
	mechanism, the end to end jitter can be controlled within 2 *		mechanism, the end to end jitter can be controlled within 2 *
	CyclicInterval.		CyclicInterval.
	5.2. DetNet Network Element Configuration and Functions		5. Controller Processing and Operation
			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,		After the information is input by the DetNet network administrator,
	the controller will convert the information into the network		the controller will convert the information into the network
	configuration and send it to the DetNet network element node, using a		configuration and send it to the DetNet network element node, using a
	protocol such as NETCONF [RFC6241]/YANG[RFC6020]. Deterministic		protocol such as NETCONF [RFC6241]/YANG[RFC6020]. Deterministic
	Networking (DetNet) YANG Model defined in [DetNet-YANG] contains the		Networking (DetNet) YANG Model defined in [DetNet-YANG] contains the
	specification for the Deterministic Networking YANG Model for		specification for the Deterministic Networking YANG Model for
	configuration and operational data for DetNet Flows.		configuration and operational data for DetNet Flows.
			6. Performed Functions on DetNet Network Node
			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:
			* MPLS TE or Segment Routing configuration RSVP configuration for
			resource reservation(optional)
			* Configuration Enabling DetNet capability Configuration of Queuing
			mechanism
			Ingress Node DetNet services Configuration:
			* DetNet flow Configuration Explicit path configuration
			* Configuration of Mapping DetNet flow to explicit path
			Configuration of Service Protection
			* Configuration of Queuing mechanism EgressConfiguration of Queuing
			mechanism Configuration of Service Protection
			Egress Node DetNet services Configuration:
			* DetNet flow Configuration Explicit path configuration
			* Configuration of Mapping DetNet flow to explicit path
			Configuration of Service Protection
			* Configuration of Queuing mechanism EgressConfiguration of Queuing
			mechanism Configuration of Service Protection
	After DetNet network equipment receives the configuration, it starts		After DetNet network equipment receives the configuration, it starts
	to execute. As Figure 2 is shown, the functions of each DetNet		to execute. As Figure 2 is shown, the functions of each DetNet
	network element is clearly visible.		network element is clearly visible.
	SDN +----+ 1.Entrance to the above information		SDN +----+ 1.Entrance to the above information
	Controller | | 2.Network Resource Evaluation and Reservation(Optional)		Controller | | 2.Network Resource Evaluation and Reservation(Optional)
	+----+ 3.Converting the information into the network configuration		+----+ 3.Converting the information into the network configuration
	|		|
	+--------+-------+------+		+--------+-------+------+
	| | | |		| | | |
	skipping to change at page 9, line 44 ¶		skipping to change at page 10, line 39 ¶
	| |Enabling queuing mechanism|		| |Enabling queuing mechanism|
	| +--------------------------+		| +--------------------------+
	+--> +-------------------------------------------------------+		+--> +-------------------------------------------------------+
	|1.Identifying a deterministic flow |		|1.Identifying a deterministic flow |
	|2.Establishing explicit path for the deterministic flow|		|2.Establishing explicit path for the deterministic flow|
	|3.Enabling queuing mechanism |		|3.Enabling queuing mechanism |
	+-------------------------------------------------------+		+-------------------------------------------------------+
	Figure-2: DetNet Network Functions		Figure-2: DetNet Network Functions
	6. How to Maintain Deterministic Flow in DetNet network		7. Security Considerations
	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.
	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		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.
	11. Normative References		8. Normative References
	[DetNet-Bounded-Latency]		[DetNet-Bounded-Latency]
	"DetNet Bounded Latency", <https://www.rfc-		"DetNet Bounded Latency", <https://www.rfc-
	editor.org/info/draft-ietf-detnet-bounded-latency>.		editor.org/info/draft-ietf-detnet-bounded-latency>.
	[DetNet-YANG]		[DetNet-YANG]
	"Deterministic Networking (DetNet) YANG Model",		"Deterministic Networking (DetNet) YANG Model",
	<https://www.rfc-editor.org/info/draft-ietf-detnet-yang-		<https://www.rfc-editor.org/info/draft-ietf-detnet-yang-
	12>.		12>.
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 17 ¶
	[RFC9016] "Flow and Service Information Model for Deterministic		[RFC9016] "Flow and Service Information Model for Deterministic
	Networking (DetNet)",		Networking (DetNet)",
	<https://www.rfc-editor.org/info/RFC9016>.		<https://www.rfc-editor.org/info/RFC9016>.
	[RFC9023] "Deterministic Networking (DetNet) Data Plane: IP over		[RFC9023] "Deterministic Networking (DetNet) Data Plane: IP over
	IEEE 802.1 Time-Sensitive Networking (TSN)",		IEEE 802.1 Time-Sensitive Networking (TSN)",
	<https://www.rfc-editor.org/info/rfc9023>.		<https://www.rfc-editor.org/info/rfc9023>.
	Authors' Addresses		Authors' Addresses
	Joanna Dang (editor)		Joanna Dang (editor)
	Huawei		Huawei
	No.156 Beiqing Road		No.156 Beiqing Road
	Beijing, P.R. China 100095		Beijing
			P.R. China, 100095
	China		China
	Email: dangjuanna@huawei.com		Email: dangjuanna@huawei.com
	Zongpeng Du		Zongpeng Du
	China Mobile		China Mobile
	32 Xuanwumen West St		32 Xuanwumen West St
	Beijing, P.R. China 100053		Beijing
			P.R. China, 100053
	China		China
	Email: duzongpeng@chinamobile.com		Email: duzongpeng@chinamobile.com
			Yizhou (editor)
			Huawei
			P.R. China,
			China
			Email: liyizhou@huawei.com
End of changes. 49 change blocks.
	199 lines changed or deleted		226 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/