idnits 2.17.1
draft-ietf-detnet-flow-information-model-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 24, 2021) is 1185 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-16) exists of
draft-ietf-detnet-security-13
== Outdated reference: A later version (-20) exists of
draft-ietf-detnet-yang-09
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DetNet B. Varga
3 Internet-Draft J. Farkas
4 Intended status: Informational Ericsson
5 Expires: July 28, 2021 R. Cummings
6 National Instruments
7 Y. Jiang
8 Huawei Technologies Co., Ltd.
9 D. Fedyk
10 LabN Consulting, L.L.C.
11 January 24, 2021
13 DetNet Flow and Service Information Model
14 draft-ietf-detnet-flow-information-model-14
16 Abstract
18 This document describes flow and service information model for
19 Deterministic Networking (DetNet). These models are defined for IP
20 and MPLS DetNet data planes
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on July 28, 2021.
39 Copyright Notice
41 Copyright (c) 2021 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
57 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
60 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6
61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
62 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 7
63 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7
64 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7
65 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7
66 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8
67 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8
68 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8
69 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9
70 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9
71 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10
72 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10
73 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10
74 5.4. Identification and Specification of DetNet Flows . . . . 10
75 5.4.1. DetNet MPLS Flow Identification and Specification . . 11
76 5.4.2. DetNet IP Flow Identification and Specification . . . 11
77 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11
78 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12
79 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 13
80 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 13
81 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 14
82 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 14
83 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14
84 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14
85 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14
86 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14
87 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 15
88 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 15
89 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 15
90 6.1. Management ID of the DetNet service . . . . . . . . . . . 15
91 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15
92 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 16
93 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 16
94 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 16
95 6.3.3. Maximum Latency Variation of the DetNet Service . . . 16
96 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16
97 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16
98 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 17
99 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 17
100 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 17
101 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 17
102 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17
103 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 18
104 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 19
105 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 19
106 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 19
107 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
111 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
112 11.2. Informative References . . . . . . . . . . . . . . . . . 20
113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
115 1. Introduction
117 Deterministic Networking (DetNet) provides a capability to carry
118 specified unicast or multicast data flows for real-time applications
119 with extremely low packet loss rates and assured maximum end-to-end
120 delivery latency. A description of the general background and
121 concepts of DetNet can be found in [RFC8655].
123 This document describes the Detnet Flow and Service Information
124 Model. For reference [RFC3444] describes the rationale behind
125 Information Models in general. This document describes the Flow and
126 Service information models for operators and users to understand
127 Detnet services, and for implementors as a guide to the functionality
128 required by Detnet services.
130 The DetNet Architecture treats the DetNet related data plane
131 functions decomposed into two sub-layers: a service sub-layer and a
132 forwarding sub-layer. The service sub-layer is used to provide
133 DetNet service protection and reordering. The forwarding sub-layer
134 provides resource allocation (to ensure low loss, assured latency,
135 and limited out-of-order delivery) and leverages Traffic Engineering
136 mechanisms.
138 DetNet service utilizes IP or MPLS and DetNet is currently defined
139 for IP and MPLS networks as shown in Figure 1 based on Figure 2 and
140 Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive Networking (TSN)
141 utilizes Ethernet and is defined over Ethernet networks. A DetNet
142 flow includes one or more App-flow(s) as payload. App-flows can be
143 Ethernet, MPLS, or IP flows, which impacts which header fields are
144 utilized to identify a flow. DetNet flows are identified by the
145 DetNet encapsulation of App-flow(s) (e.g., MPLS labels, IP 6-tuple
146 etc.). In some scenarios App-flow and DetNet flow look similar on
147 the wire (e.g., L3 App-flow over a DetNet IP network).
149 +-----+
150 | TSN |
151 +-------+ +-+-----+-+
152 | DN IP | | DN MPLS |
153 +--+--+----+----+ +-+---+-----+-+
154 | TSN | DN MPLS | | TSN | DN IP |
155 +-----+---------+ +-----+-------+
157 Figure 1: DetNet Service Examples as per Data Plane Framework
159 As shown in Figure 1 as per [RFC8938] a DetNet flow can be treated as
160 an application level flow (App-flow) e.g., at DetNet flow aggregation
161 or in a sub-network that interconnects DetNet nodes.
163 The DetNet flow and service information model provided by this
164 document contains both DetNet flow and App-flow specific information
165 in an integrated fashion.
167 In a given network scenario three information models can be
168 distinguished:
170 o Flow models that describe characteristics of data flows. These
171 models describe in detail all relevant aspects of a flow that are
172 needed to support the flow properly by the network between the
173 source and the destination(s).
175 o Service models that describe characteristics of services being
176 provided for data flows over a network. These models can be
177 treated as a network operator independent information model.
179 o Configuration models that describe in detail the settings required
180 on network nodes to provide a data flow proper service.
182 Service and flow information models are used between the user and the
183 network operator. Configuration information models are used between
184 the management/control plane entity of the network and the network
185 nodes. They are shown in Figure 2.
187 User Network Operator
188 flow/service
189 /\ info model +---+
190 / \ <---------------> | X | management/control
191 ---- +-+-+ plane entity
192 ^
193 | configuration
194 | info model
195 +------------+
196 v | |
197 +-+ | v Network
198 +-+ v +-+ nodes
199 +-+ +-+
200 +-+
202 Figure 2: Usage of Information models (flow, service and
203 configuration)
205 DetNet flow and service information model is based on [RFC8655] and
206 on the concept of data model specified by [IEEE8021Qcc]. In addition
207 to the TSN data model, [IEEE8021Qcc] also specifies configuration of
208 TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]).
209 The common architecture and flow model, allow configured features to
210 be consistent in certain deployment scenarios, e.g., when the network
211 that provides the DetNet service includes both L3 and L2 network
212 segments.
214 1.1. Goals
216 As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates
217 with IEEE 802.1 TSN in order to define a common architecture for both
218 Layer 2 and Layer 3. This is beneficial for several reasons, e.g.,
219 in order to simplify implementations and maintain consistency across
220 diverse networks. The flow and service information models are also
221 aligned for those reasons. Therefore, the DetNet flow and service
222 information models described in this document are based on
223 [IEEE8021Qcc], which is an amendment to [IEEE8021Q].
225 This document specifies flow and service information models only.
227 1.2. Non Goals
229 This document does not specify flow data models or DetNet
230 configuration. Therefore, the goals of this document differ from the
231 goals of [IEEE8021Qcc], which also specifies the TSN data model and
232 configuration of certain TSN features.
234 The DetNet specific YANG data model is described in
235 [I-D.ietf-detnet-yang].
237 2. Terminology
239 2.1. Terms Used in This Document
241 This document uses the terminology established in the DetNet
242 architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938].
243 The reader is assumed to be familiar with these documents and any
244 terminology defined therein. The DetNet <=> TSN dictionary of
245 [RFC8655] is used to perform translation from [IEEE8021Qcc] to this
246 document.
248 The following terminology is used in accordance with [RFC8655]:
250 App-flow The payload (data) carried over a DetNet service.
252 DetNet flow A DetNet flow is a sequence of packets which conform
253 uniquely to a flow identifier, and to which the DetNet
254 service is to be provided. It includes any DetNet
255 headers added to support the DetNet service and
256 forwarding sub-layers.
258 The following terminology is introduced in this document:
260 Source Reference point for an App-flow, where the flow starts.
262 Destination Reference point for an App-flow, where the flow
263 terminates.
265 DN Ingress Reference point for the start of a DetNet flow.
266 Networking technology specific encapsulation may be
267 added here to the served App-flow(s).
269 DN Egress Reference point for the termination of a DetNet flow.
270 Networking technology specific encapsulation may be
271 removed here from the served App-flow(s).
273 2.2. Abbreviations
275 The following abbreviations are used in this document:
277 DetNet Deterministic Networking.
279 DN DetNet.
281 MPLS Multiprotocol Label Switching.
283 PSN Packet Switched Network.
285 TSN Time-Sensitive Networking.
287 2.3. Naming Conventions
289 The following naming conventions were used for naming information
290 model components in this document. It is recommended that extensions
291 of the model use the same conventions.
293 o Descriptive names are used.
295 o Names start with uppercase letters.
297 o Composed names use capital letters for the first letter of each
298 component. All other letters are lowercase, even for acronyms.
299 Exceptions are made for acronyms containing a mixture of lowercase
300 and capital letters, such as IPv6. Example composed names are
301 SourceMacAddress and DestinationIPv6Address.
303 3. DetNet Domain and its Modeling
305 3.1. DetNet Service Overview
307 The DetNet service can be defined as a service that provides a
308 capability to carry a unicast or a multicast data flow for an
309 application with constrained requirements on network performance,
310 e.g., low packet loss rate and/or latency.
312 Figure 5 and Figure 8 in [RFC8655] show the DetNet service related
313 reference points and main components.
315 3.2. Reference Points Used in Modeling
317 From service design perspective a fundamental question is the
318 location of the service/flow endpoints, i.e., where the service/flow
319 starts and ends.
321 App-flow specific reference points are the Source (where it starts)
322 and the Destination (where it terminates). Similarly a DetNet flow
323 has reference points termed DN Ingress (where a DetNet flow starts)
324 and DN Egress (where a DetNet flow ends). These reference points may
325 coexist in the same node (e.g., in a DetNet IP end system). DN
326 Ingress and DN Egress reference points are intermediate reference
327 points for a served App-flow.
329 All reference points are assumed in this document to be packet-based
330 reference points. A DN Ingress may add and a DN Egress may remove
331 networking technology specific encapsulation to/from the served App-
332 flow(s) (e.g., MPLS label(s), UDP and IP headers).
334 3.3. Information Elements
336 The DetNet flow information model and the service model relies on
337 three groups of information elements:
339 o App-flow related parameters: these describe the App-flow
340 characteristics (e.g., identification, encapsulation, traffic
341 specification, endpoints, status, etc.) and the App-flow service
342 expectations (e.g., delay, loss, etc.).
344 o DetNet flow related parameters: these describe the DetNet flow
345 characteristics (e.g., identification, format, traffic
346 specification, endpoints, rank, etc.).
348 o DetNet service related parameters: these describe the expected
349 service characteristics (e.g., delivery type, connectivity delay/
350 loss, status, rank, etc.).
352 In the information model a DetNet flow contains one or more
353 (aggregated) App-flows (N:1 mapping). During DetNet aggregation the
354 aggregated DetNet flows are treated simply as App-flows and the
355 aggregate is the DetNet flow, which provides N:1 mapping. Similarly,
356 there is an aggregated many to one relationship for the DetNet
357 flow(s) to the DetNet Service.
359 4. App-flow Related Parameters
361 When Deterministic service is required by time/loss sensitive
362 application(s) running on an end system during communication with its
363 peer(s), the resulting data exchange has various requirements on
364 delay and/or loss parameters.
366 4.1. App-flow Characteristics
368 App-flow characteristics are described by the following parameters:
370 o FlowID: a unique (management) identifier of the App-flow. It can
371 be used to define the N:1 mapping of App-flows to a DetNet flow.
373 o FlowType: set by the encapsulation format of the flow. It can be
374 Ethernet (TSN), MPLS, or IP.
376 o DataFlowSpecification: a flow descriptor, defining which packets
377 belongs to a flow, using specific packet header fields such as
378 src-addr, dst-addr, label, VLAN-ID, etc.
380 o TrafficSpecification: a flow descriptor, defining traffic
381 parameters such as packet size, transmission time interval, and
382 maximum packets per time interval.
384 o FlowEndpoints: delineate the start and termination reference
385 points of the App-flow by pointing to the source interface/node
386 and destination interface(s)/node(s).
388 o FlowStatus: indicates the status of the App-flow with respect to
389 the establishment of the flow by the connected network, e.g.,
390 ready, failed, etc.
392 o FlowRank: indicates the rank of this flow relative to other flows
393 in the connected network.
395 Note: When defining the N:1 mapping of App-flows to a DetNet flow,
396 the App-flows must have the same FlowType and different
397 DataFlowSpecification parameters
399 4.2. App-flow Requirements
401 App-flow requirements are described by the following parameters:
403 o FlowRequirements: defines the attributes of the App-flow regarding
404 bandwidth, latency, latency variation, loss, and misordering
405 tolerance.
407 o FlowBiDir: defines the data path requirement of the App-flow
408 whether it must share the same data path and physical path for
409 both directions through the network, e.g., to provide congruent
410 paths in the two directions.
412 5. DetNet Flow Related Parameters
414 The Data model specified by [IEEE8021Qcc] describes data flows using
415 TSN service as periodic flows with fixed packet size (i.e., Constant
416 Bit Rate (CBR) flows) or with variable packet size. The same concept
417 is applied for flows using DetNet service.
419 Latency and loss parameters are correlated because the effect of late
420 delivery can result in data loss for an application. However, not
421 all applications require hard limits on both latency and loss. For
422 example, some real-time applications allow graceful degradation if
423 loss happens (e.g., sample-based data processing, media
424 distribution). Some other applications may require high-bandwidth
425 connections that make use of packet replication techniques which are
426 economically challenging or even impossible. Some applications may
427 not tolerate loss, but are not delay sensitive (e.g., bufferless
428 sensors). Time or loss sensitive applications may have somewhat
429 special requirements especially for loss (e.g., no loss over two
430 consecutive communication cycles; very low outage time, etc.).
432 DetNet flows have the following attributes:
434 a. DnFlowID (Section 5.1)
435 b. DnPayloadType (Section 5.2)
436 c. DnFlowFormat (Section 5.3)
437 d. DnFlowSpecification (Section 5.4)
438 e. DnTrafficSpecification (Section 5.5)
439 f. DnFlowEndpoints (Section 5.6)
440 g. DnFlowRank (Section 5.7)
441 h. DnFlowStatus (Section 5.8)
443 DetNet flows have the following requirement attributes:
445 o DnFlowRequirements (Section 5.9)
446 o DnFlowBiDir (Section 5.10)
448 Flow attributes are described in the following sections.
450 5.1. Management ID of the DetNet Flow
452 A unique (management) identifier is needed for each DetNet flow
453 within the DetNet domain. It is specified by DnFlowID. It can be
454 used to define the N:1 mapping of DetNet flows to a DetNet service.
456 5.2. Payload type of the DetNet Flow
458 The DnPayloadType attribute is set according to the encapsulated App-
459 flow format. The attribute can be Ethernet, MPLS, or IP.
461 5.3. Format of the DetNet Flow
463 The DnFlowFormat attribute is set according to the DetNet PSN
464 technology. The attribute can be MPLS or IP.
466 5.4. Identification and Specification of DetNet Flows
468 Identification options for DetNet flows at the Ingress/Egress and
469 within the DetNet domain are specified as follows; see Section 5.4.1
470 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows.
472 5.4.1. DetNet MPLS Flow Identification and Specification
474 The identification of DetNet MPLS flows within the DetNet domain is
475 based on the MPLS context in the service information model. The
476 attributes are specific to the MPLS forwarding paradigm within the
477 DetNet domain [I-D.ietf-detnet-mpls]. DetNet MPLS flows can be
478 identified and specified by the following attributes:
480 a. SLabel
481 b. FLabelStack
483 5.4.2. DetNet IP Flow Identification and Specification
485 DetNet IP flows can be identified and specified by the following
486 attributes [RFC8939]:
488 a. SourceIpAddress
489 b. DestinationIpAddress
490 c. IPv6FlowLabel
491 d. Dscp (attribute)
492 e. Protocol
493 f. SourcePort
494 g. DestinationPort
495 h. IPSecSpi
497 The IP 6-tuple that is used for DetNet IP flow identification
498 consists of items a, b, d, e, f, and g. Items c and h are additional
499 attributes that can be used for DetNet flow identification in
500 addition to the 6-tuple. 6-tuple and use of wild cards for these
501 attributes are specified in [RFC8939].
503 5.5. Traffic Specification of the DetNet Flow
505 DnTrafficSpecification attributes specify how the DN Ingress
506 transmits packets for the DetNet flow. This is effectively the
507 promise/request of the DN Ingress to the network. The network uses
508 this traffic specification to allocate resources and adjust queue
509 parameters in network nodes.
511 TrafficSpecification has the following attributes:
513 a. Interval: the period of time in which the traffic specification
514 is specified.
516 b. MaxPacketsPerInterval: the maximum number of packets that the
517 Ingress will transmit in one Interval.
519 c. MaxPayloadSize: the maximum payload size that the Ingress will
520 transmit.
522 d. MinPayloadSize: the minimum payload size that the Ingress will
523 transmit.
525 e. MinPacketsPerInterval: the minimum number of packets that the
526 Ingress will transmit in one Interval.
528 These attributes can be used to describe any type of traffic (e.g.,
529 CBR, VBR, etc.) and can be used during resource allocation to
530 represent worst case scenarios. Intervals are specified as an
531 integer number of nanoseconds. PayloadSizes are specified in octets.
533 Flows exceeding the traffic specification (i.e., having more traffic
534 than defined by the maximum attributes) may receive a different
535 network behavior than the DetNet network has been engineered for.
536 Excess traffic due to malicious or malfunctioning devices can be
537 prevented or mitigated (e.g., through the use of existing mechanisms
538 such as policing and shaping).
540 When MinPayloadSize and MinPacketsPerInterval parameters are used,
541 then all packets less than the MinPayloadSize will be counted as
542 being of the size MinPayloadSize during packet processing when packet
543 size matters, e.g., when policing; and all flows having less than
544 MinPacketsPerInterval will be counted as having MinPacketsPerInterval
545 when the number of packets per interval matters, e.g., during
546 resource reservation. However, flows having less than
547 MinPacketsPerInterval may result in a different network behavior than
548 the DetNet network has been engineered for. MinPayloadSize and
549 MinPacketsPerInterval parameters, for example, may be used when
550 engineering the latency bounds of a DetNet flow when POF is applied
551 to the given DetNet flow.
553 Further optional attributes can be considered to achieve more
554 efficient resource allocation. Such optional attributes might be
555 worth for flows with soft requirements (i.e., the flow is only loss
556 sensitive or only delay sensitive, but not both delay-and-loss
557 sensitive). Possible options how to extend DnTrafficSpecification
558 attributes is for further discussion.
560 5.6. Endpoints of the DetNet Flow
562 The DnFlowEndpoints attribute defines the starting and termination
563 reference points of the DetNet flow by pointing to the ingress
564 interface/node and egress interface(s)/node(s). Depending on the
565 network scenario it defines an interface or a node. Interface can be
566 defined for example if the App-flow is a TSN Stream and it is
567 received over a well defined UNI (User-to-Network Interface). For
568 example, for App-flows with MPLS encapsulation defining an ingress
569 node is more common when per platform label space is used.
571 5.7. Rank of the DetNet Flow
573 The DnFlowRank attribute provides the rank of this flow relative to
574 other flows in the DetNet domain. Rank (range: 0-255) is used by the
575 DetNet domain to decide which flows can and cannot exist when network
576 resources reach their limit. Rank is used to help to determine which
577 flows can be bumped (i.e., removed from node configuration thereby
578 releasing its resources) if for example a port of a node becomes
579 oversubscribed (e.g., due to network re-configuration). DnFlowRank
580 value 0 is the highest priority.
582 5.8. Status of the DetNet Flow
584 DnFlowStatus provides the status of the DetNet flow with respect to
585 the establishment of the flow by the DetNet domain.
587 The DnFlowStatus includes the following attributes:
589 a. DnIngressStatus is an enumeration for the status of the flow's
590 Ingress reference point:
592 * None: no Ingress.
593 * Ready: Ingress is ready.
594 * Failed: Ingress failed.
595 * OutOfService: Administratively blocked.
597 b. DnEgressStatus is an enumeration for the status of the flow's
598 Egress reference points:
600 * None: no Egress.
601 * Ready: all Egresses are ready.
602 * PartialFailed: One or more Egress ready, and one or more
603 Egress failed. The DetNet flow can be used if the Ingress is
604 Ready.
605 * Failed: All Egresses failed.
606 * OutOfService: All Egresses are administratively blocked.
608 c. FailureCode: A non-zero code that specifies the error if the
609 DetNet flow encounters a failure (e.g., packet replication and
610 elimination is requested but not possible, or DnIngressStatus is
611 Failed, or DnEgressStatus is Failed, or DnEgressStatus is
612 PartialFailed).
614 Defining FailureCodes for DetNet is out-of-scope in this document.
615 Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.
617 5.9. Requirements of the DetNet Flow
619 DnFlowRequirements specifies requirements to ensure the service level
620 desired for the DetNet flow.
622 The DnFlowRequirements includes the following attributes:
624 a. MinBandwidth(Section 5.9.1)
625 b. MaxLatency(Section 5.9.2)
626 c. MaxLatencyVariation(Section 5.9.3)
627 d. MaxLoss(Section 5.9.4)
628 e. MaxConsecutiveLossTolerance(Section 5.9.5)
629 f. MaxMisordering(Section 5.9.6)
631 5.9.1. Minimum Bandwidth of the DetNet Flow
633 MinBandwidth is the minimum bandwidth that has to be guaranteed for
634 the DetNet flow. MinBandwidth is specified in octets per second.
636 5.9.2. Maximum Latency of the DetNet Flow
638 MaxLatency is the maximum latency from Ingress to Egress(es) for a
639 single packet of the DetNet flow. MaxLatency is specified as an
640 integer number of nanoseconds.
642 5.9.3. Maximum Latency Variation of the DetNet Flow
644 MaxLatencyVariation is the difference between the minimum and the
645 maximum end-to-end one-way latency. MaxLatencyVariation is specified
646 as an integer number of nanoseconds.
648 5.9.4. Maximum Loss of the DetNet Flow
650 MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
651 the DetNet flow between the Ingress and Egress(es) and the loss
652 measurement interval.
654 5.9.5. Maximum Consecutive Loss of the DetNet Flow
656 Some applications have special loss requirement, such as
657 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
658 parameter describes the maximum number of consecutive packets whose
659 loss can be tolerated. The maximum consecutive loss tolerance can be
660 measured for example based on sequence number.
662 5.9.6. Maximum Misordering Tolerance of the DetNet Flow
664 MaxMisordering describes the tolerable maximum number of packets that
665 can be received out of order. The value zero for the maximum allowed
666 misordering indicates that in order delivery is required, misordering
667 cannot be tolerated.
669 The maximum allowed misordering can be measured for example based on
670 sequence numbers. When a packet arrives at the egress after a packet
671 with a higher sequence number, the difference between the sequence
672 number values cannot be bigger than "MaxMisordering + 1".
674 5.10. BiDir requirement of the DetNet Flow
676 DnFlowBiDir attribute defines the requirement that the flow and the
677 corresponding reverse direction flow must share the same path (links
678 and nodes) through the routed or switch network in the DetNet domain,
679 e.g., to provide congruent paths in the two directions that share
680 fate and path characteristics.
682 6. DetNet Service Related Parameters
684 DetNet service have the following attributes:
686 a. DnServiceID (Section 6.1)
687 b. DnServiceDeliveryType (Section 6.2)
688 c. DnServiceDeliveryProfile (Section 6.3)
689 d. DNServiceConnectivity (Section 6.4)
690 e. DnServiceBiDir (Section 6.5)
691 f. DnServiceRank (Section 6.6)
692 g. DnServiceStatus (Section 6.7)
694 Service attributes are described in the following sections.
696 6.1. Management ID of the DetNet service
698 A unique (management) identifier for each DetNet service within the
699 DetNet domain. It can be used to define the many to one mapping of
700 DetNet flows to a DetNet service.
702 6.2. Delivery Type of the DetNet service
704 The DnServiceDeliveryType attribute is set according to the payload
705 of the served DetNet flow (i.e., the encapsulated App-flow format).
706 The attribute can be Ethernet, MPLS, or IP.
708 6.3. Delivery Profile of the DetNet Service
710 DnServiceDeliveryProfile specifies delivery profile to ensure proper
711 serving of the DetNet flow.
713 The DnServiceDeliveryProfile includes the following attributes:
715 a. MinBandwidth(Section 6.3.1)
716 b. MaxLatency(Section 6.3.2)
717 c. MaxLatencyVariation(Section 6.3.3)
718 d. MaxLoss(Section 6.3.4)
719 e. MaxConsecutiveLossTolerance(Section 6.3.5)
720 f. MaxMisordering(Section 6.3.6)
722 6.3.1. Minimum Bandwidth of the DetNet Service
724 MinBandwidth is the minimum bandwidth that has to be guaranteed for
725 the DetNet service. MinBandwidth is specified in octets per second
726 and excludes additional DetNet header (if any).
728 6.3.2. Maximum Latency of the DetNet Service
730 MaxLatency is the maximum latency from Ingress to Egress(es) for a
731 single packet of the DetNet flow. MaxLatency is specified as an
732 integer number of nanoseconds.
734 6.3.3. Maximum Latency Variation of the DetNet Service
736 MaxLatencyVariation is the difference between the minimum and the
737 maximum end-to-end one-way latency. MaxLatencyVariation is specified
738 as an integer number of nanoseconds.
740 6.3.4. Maximum Loss of the DetNet Service
742 MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the
743 DetNet service between the Ingress and Egress(es) of the DetNet
744 domain.
746 6.3.5. Maximum Consecutive Loss of the DetNet Service
748 Some applications have special loss requirement, such as
749 MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance
750 parameter describes the maximum number of consecutive packets whose
751 loss can be tolerated. The maximum consecutive loss tolerance can be
752 measured for example based on sequence number.
754 6.3.6. Maximum Misordering Tolerance of the DetNet Service
756 MaxMisordering describes the tolerable maximum number of packets that
757 can be received out of order. The maximum allowed misordering can be
758 measured for example based on sequence number. The value zero for
759 the maximum allowed misordering indicates that in order delivery is
760 required, misordering cannot be tolerated.
762 6.4. Connectivity Type of the DetNet Service
764 Two connectivity types are distinguished: point-to-point (p2p) and
765 point-to-multipoint (p2mp). Connectivity type p2mp may be created by
766 a forwarding function (e.g., p2mp LSP). (Note: from service
767 perspective mp2mp connectivity can be treated as a superposition of
768 p2mp connections.)
770 6.5. BiDir requirement of the DetNet Service
772 The DnServiceBiDir attribute defines the requirement that the flow
773 and the corresponding reverse direction flow must share the same path
774 (links and nodes) through the routed or switch network in the DetNet
775 domain, e.g., to provide congruent paths in the two directions that
776 share fate and path characteristics.
778 6.6. Rank of the DetNet Service
780 The DnServiceRank attribute provides the rank of a service instance
781 relative to other services in the DetNet domain. DnServiceRank
782 (range: 0-255) is used by the network in case of network resource
783 limitation scenarios. DnServiceRank value 0 is the highest priority.
785 6.7. Status of the DetNet Service
787 DnServiceStatus information group includes elements that specify the
788 status of the service specific state of the DetNet domain. This
789 information group informs the user whether or not the service is
790 ready for use.
792 The DnServiceStatus includes the following attributes:
794 a. DnServiceIngressStatus is an enumeration for the status of the
795 service's Ingress:
797 * None: no Ingress.
798 * Ready: Ingress is ready.
799 * Failed: Ingress failed.
800 * OutOfService: Administratively blocked.
802 b. DnServiceEgressStatus is an enumeration for the status of the
803 service's Egress:
805 * None: no Egress.
806 * Ready: all Egresses are ready.
807 * PartialFailed: One or more Egress ready, and one or more
808 Egress failed. The DetNet flow can be used if the Ingress is
809 Ready.
810 * Failed: All Egresses failed.
811 * OutOfService: Administratively blocked.
813 c. DnServiceFailureCode: A non-zero code that specifies the error if
814 the DetNet service encounters a failure (e.g., packet replication
815 and elimination is requested but not possible, or
816 DnServiceIngressStatus is Failed, or DnServiceEgressStatus is
817 Failed, or DnServiceEgressStatus is PartialFailed).
819 Defining DnServiceFailureCodes for DetNet service is out-of-scope in
820 this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure
821 codes.
823 7. Flow Specific Operations
825 The DetNet flow information model relies on three high level
826 information groups:
828 o DnIngress: The DnIngress information group includes elements that
829 specify the source for a single DetNet flow. This information
830 group is applied from the user of the DetNet service to the
831 network.
833 o DnEgress: The DnEgress information group includes elements that
834 specify the destination for a single DetNet flow. This
835 information group is applied from the user of the DetNet service
836 to the network.
838 o DnFlowStatus: The status information group includes elements that
839 specify the status of the flow in the network. This information
840 group is applied from the network to the user of the DetNet
841 service. This information group informs the user whether or not
842 the DetNet flow is ready for use.
844 There are three possible operations for each DetNet flow with respect
845 to its DetNet service at a DN Ingress or a DN Egress (similarly to
846 App-flows at a Source or a Destination):
848 o Join: DN Ingress/DN Egress intends to join the flow.
849 o Leave: DN Ingress/DN Egress intends to leave the flow.
851 o Modify: DN Ingress/DN Egress intends to change the flow.
853 7.1. Join Operation
855 For the join operation, the DnFlowSpecification, DnFlowRank,
856 DnFlowEndpoint, and DnTrafficSpecification are included within the
857 DnIngress or DnEgress information group. For the join operation, the
858 DnServiceRequirements groups can be included.
860 7.2. Leave Operation
862 For the leave operation, the DnFlowSpecification and DnFlowEndpoint
863 are included within the DnIngress or DnEgress information group.
865 7.3. Modify Operation
867 For the modify operation, the DnFlowSpecification, DnFlowRank,
868 DnFlowEndpoint, and DnTrafficSpecification are included within the
869 DnIngress or DnEgress information group. For the join operation, the
870 DnServiceRequirements groups can be included.
872 The Modify operation can be considered to address cases when a flow
873 is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been
874 changed. The advantage of having a Modify is that it allows
875 initiation of a change of flow spec while leaving the current flow is
876 operating until the change is accepted. If there is no linkage
877 between the Join and the Leave, then while figuring out whether the
878 new flow spec can be supported, the controller entity has to assume
879 that the resources committed to the current flow are in use. By
880 using Modify the controller entity knows that the resources
881 supporting the current flow can be available for supporting the
882 altered flow. Modify is considered to be an optional operation due
883 to possible controller plane limitations.
885 8. Summary
887 This document describes the DetNet flow information model and the
888 service information model for DetNet IP networks and DetNet MPLS
889 networks. These models are used as input for creating the DetNet
890 specific YANG model.
892 9. IANA Considerations
894 N/A.
896 10. Security Considerations
898 The external interfaces of the DetNet domain need to be subject to
899 appropriate confidentiality. Additionally, knowledge of which flows/
900 services are provided to a customer or delivered by a network
901 operator may supply information that can be used in a variety of
902 security attacks. Security considerations for DetNet are described
903 in detail in [I-D.ietf-detnet-security]. General security
904 considerations are described in [RFC8655]. This document discusses
905 modeling the information, not how it is exchanged.
907 11. References
909 11.1. Normative References
911 [I-D.ietf-detnet-mpls]
912 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
913 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
914 detnet-mpls-13 (work in progress), October 2020.
916 [IEEE8021Qcc]
917 IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE
918 Standard for Local and metropolitan area networks -
919 Bridges and Bridged Networks -- Amendment 31: Stream
920 Reservation Protocol (SRP) Enhancements and Performance
921 Improvements", 2018,
922 .
924 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
925 "Deterministic Networking Architecture", RFC 8655,
926 DOI 10.17487/RFC8655, October 2019,
927 .
929 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
930 Bryant, "Deterministic Networking (DetNet) Data Plane:
931 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
932 .
934 11.2. Informative References
936 [I-D.ietf-detnet-security]
937 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
938 Networking (DetNet) Security Considerations", draft-ietf-
939 detnet-security-13 (work in progress), December 2020.
941 [I-D.ietf-detnet-yang]
942 Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and
943 Z. Li, "Deterministic Networking (DetNet) Configuration
944 YANG Model", draft-ietf-detnet-yang-09 (work in progress),
945 November 2020.
947 [IEEE8021Q]
948 IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE
949 Standard for Local and metropolitan area networks -
950 Bridges and Bridged Networks", 2018,
951 .
953 [IEEE8021Qbv]
954 IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE
955 Standard for Local and metropolitan area networks -
956 Bridges and Bridged Networks - Amendment 25: Enhancements
957 for Scheduled Traffic", 2015,
958 .
960 [IETFDetNet]
961 IETF, "IETF Deterministic Networking (DetNet) Working
962 Group", .
964 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
965 Information Models and Data Models", RFC 3444,
966 DOI 10.17487/RFC3444, January 2003,
967 .
969 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
970 Bryant, "Deterministic Networking (DetNet) Data Plane
971 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
972 .
974 Authors' Addresses
976 Balazs Varga
977 Ericsson
978 Magyar tudosok korutja 11
979 Budapest 1117
980 Hungary
982 Email: balazs.a.varga@ericsson.com
983 Janos Farkas
984 Ericsson
985 Magyar tudosok korutja 11
986 Budapest 1117
987 Hungary
989 Email: janos.farkas@ericsson.com
991 Rodney Cummings
992 National Instruments
993 11500 N. Mopac Expwy
994 Bldg. C
995 Austin, TX 78759-3504
996 USA
998 Email: rodney.cummings@ni.com
1000 Yuanlong Jiang
1001 Huawei Technologies Co., Ltd.
1002 Bantian, Longgang district
1004 Shenzhen 518129
1005 China
1007 Email: jiangyuanlong@huawei.com
1009 Don Fedyk
1010 LabN Consulting, L.L.C.
1012 Email: dfedyk@labn.net