idnits 2.17.1 draft-geng-detnet-conf-yang-01.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 == Line 719 has weird spacing: '... enum cycli...' == Line 723 has weird spacing: '... enum async...' == Line 795 has weird spacing: '... enum trans...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 05, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1204, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-04 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-00 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-flow-information-model (ref. 'I-D.ietf-detnet-flow-information-model') == Outdated reference: A later version (-04) exists of draft-geng-detnet-info-distribution-01 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-14 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-12 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: September 6, 2018 Z. Li 6 China Mobile 7 March 05, 2018 9 DetNet Configuration YANG Model 10 draft-geng-detnet-conf-yang-01 12 Abstract 14 This document defines a YANG data Model for Deterministic Networking 15 (DetNet), covering the device / link capabilities and resources. It 16 can be used in network capability advertising, device configuration 17 and status reporting. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. DetNet Configuration Attribute . . . . . . . . . . . . . . . 4 62 3.1. DetNet Topology Attribute . . . . . . . . . . . . . . . . 4 63 3.1.1. Node Type . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.2. Replication Capability . . . . . . . . . . . . . . . 6 65 3.1.3. Elimination Capability . . . . . . . . . . . . . . . 6 66 3.1.4. Queuing Management Algorithm . . . . . . . . . . . . 6 67 3.1.5. Resource Reservation Base . . . . . . . . . . . . . . 7 68 3.1.6. Bandwidth Metric . . . . . . . . . . . . . . . . . . 7 69 3.1.7. Delay Metric . . . . . . . . . . . . . . . . . . . . 8 70 3.1.8. Synchronization Accuracy . . . . . . . . . . . . . . 9 71 3.2. DetNet Path Configuration Attribute . . . . . . . . . . . 9 72 3.2.1. Path Constrains . . . . . . . . . . . . . . . . . . . 9 73 3.2.2. Explicit Routing . . . . . . . . . . . . . . . . . . 9 74 3.3. DetNet Flow Configuration Attribute . . . . . . . . . . . 9 75 3.3.1. Flow Identification . . . . . . . . . . . . . . . . . 9 76 3.3.2. Traffic Specification . . . . . . . . . . . . . . . . 10 77 3.3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . 10 78 3.3.4. Flow Priority . . . . . . . . . . . . . . . . . . . . 10 79 3.3.5. Queuing Parameters . . . . . . . . . . . . . . . . . 11 80 3.3.6. Replication Function . . . . . . . . . . . . . . . . 11 81 3.3.7. Elimination Function . . . . . . . . . . . . . . . . 11 82 3.3.8. Routing . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.4. DetNet Status Attribute . . . . . . . . . . . . . . . . . 12 84 3.4.1. Performance Status . . . . . . . . . . . . . . . . . 12 85 3.4.2. Replication/Elimination Status . . . . . . . . . . . 13 86 4. DetNet Configuration YANG Model . . . . . . . . . . . . . . . 13 87 4.1. DetNet Topology YANG Model . . . . . . . . . . . . . . . 13 88 4.2. DetNet Static Configuration YANG Model . . . . . . . . . 19 89 5. DetNet Configuration Model Classification . . . . . . . . . . 23 90 5.1. Fully Distributed Configuration Model . . . . . . . . . . 23 91 5.2. Fully Centralized Configuration Model . . . . . . . . . . 23 92 5.3. Hybrid Configuration Model . . . . . . . . . . . . . . . 24 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 9.2. Informative References . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 101 1. Introduction 103 A lot of use cases in industry and other areas require the network to 104 provide service that can satisfy strict quality requirements, e.g., 105 extremely low packet loss rate, bounded low latency and jitter, 106 together with other best effort flows [I-D.ietf-detnet-use-cases]. 107 Deterministic Networking (DetNet) is able to provide high quality 108 deterministic service in layer 3 in an IP/MPLS network. 110 [I-D.ietf-detnet-architecture] defines the whole picture of DetNet; 111 [I-D.dt-detnet-dp-sol] defines DetNet flow encapsulation and 112 forwarding process; 114 As defined in the [I-D.ietf-detnet-flow-information-model] , DetNet 115 information model can be distinguished as: 117 o Flow models describe characteristics of data flows. These models 118 describe in detail all relevant aspects of a flow that are needed 119 to support the flow properly by the network between the source and 120 the destination(s). 122 o Service models describe characteristics of services being provided 123 for data flows over a network. These models can be treated as a 124 network operator independent information model. 126 o Configuration models describe in detail the settings required on 127 network nodes to serve a data flow properly. Service and flow 128 information models are used between the user and the network 129 operator. Configuration information models are used between the 130 management/control plane entity of the network and the network 131 nodes. 133 They are shown in the Figure 1. 135 User Network Operator 136 flow/service 137 /\ info model +---+ 138 / \ <---------------> | X | management/control 139 ---- +-+-+ plane entity 140 ^ 141 | configuration 142 | info model 143 +------------+ 144 v | | 145 +-+ | v Network 146 +-+ v +-+ nodes 147 +-+ +-+ 148 +-+ 150 Figure 1. Three Information Models 152 [I-D.ietf-detnet-flow-information-model] defines the user network 153 interface (UNI), including flow/service information model. 155 This document defines DetNet configuration information model and YANG 156 data Model, covering the device / link capabilities and resources. 157 It can be used in network capability advertising, device 158 configuration and status reporting. The YANG model is protocol 159 irrelevant, and serves as a base data model that other DetNet 160 specific models can augment. 162 2. Terminologies 164 This documents uses the terminologies defined in 165 [I-D.ietf-detnet-architecture]. 167 3. DetNet Configuration Attribute 169 This section defines network attributes for DetNet, which are used 170 for capability advertising/collection (section 3.1 DetNet Topology 171 Attribute), flow configuration (section 3.2 DetNet Path Configuration 172 Attribute/ section 3.3 DetNet Device configuration Attribute) and 173 status reporting (section 3.4 DetNet Status Attribute). 175 3.1. DetNet Topology Attribute 177 DetNet Topology Attribute describes the network topology and 178 capability, which is the basis of path computation and flow 179 transmission. 181 3.1.1. Node Type 183 Figure 2 shows a basic architecture of a DetNet Network. Three types 184 of DetNet nodes are showed in the picture, which play different roles 185 with different functions, as defined in 186 [I-D.ietf-detnet-architecture]. 188 Transit Transit 189 |<-Tnl->| |<-Tnl->| 190 End V 1 V V 2 V End 191 System +--------+ +--------+ +--------+ System 192 +---+ | R1 |=======| R2 |=======| R3 | +---+ 193 | X.| | | | | | | |.X | 194 | H1|========| | | | | |======| H2| 195 | | | | | | | | | | 196 +---+ | |=======| |=======| | +---+ 197 ^ +--------+ +--------+ +--------+ ^ 198 | Edge Node Relay Node Edge Node | 199 | | 200 |<--------------- End to End DetNet Service -------------->| 202 Figure 2. DetNet Architecture 204 Edge node 206 Edge node is the boundary of a DetNet network, including ingress and 207 egress. The DetNet flow is started at an edge node, then the packet 208 of a DetNet flow is forwarded to the DetNet Network after being 209 encapsulated or recapsulated in the edge node. Once having passed 210 through the network, DetNet flow is ended at another edge node; the 211 packet is decapsulated or recapsulated, and forwarded to the end 212 system or another network. Ingress and Egress may also do 213 repliaction/elimination, flow aggregation/split and load balance 214 [I-D.thubert-tsvwg-detnet-transport]. Edge node can be proxy of the 215 network and connect to the controller through UNI 216 [I-D.ietf-detnet-flow-information-model]. 218 Relay node 220 Relay node is designed to do replication and elimination in the 221 DetNet network to satisfy the reliability requirement. The packet of 222 a DetNet flow is replicated in one relay node and forwarded to 223 disjoint paths. These paths merge with each other in another relay 224 node, and after the redundant packets being eliminated, only one copy 225 of the flow is forwared to the next hop. Relay node can identify 226 DetNet flow and guide the packet to the next relay node or edge node, 227 so it can also be the tunnul initial/terminal which is very important 228 to guarantee DetNet explicit route. 230 Transit node 232 The node between relay node/edge node is transit node, just like the 233 p node in MPLS. Packet is transmitted through transit node hop by 234 hop. If the DetNet service requires bounded latency, every node in 235 the network is supposed to do congestion protection, with some 236 queuing management algorithm to guanrantee per hop latency, including 237 the transit node. 239 NodeType attribute specifies which type of DetNet node one device 240 belongs to. It indicates DetNet node capability, which can be used 241 in path computation. These three nodes are explianed in capability 242 ascending order above, that is to say normally, the DetNet node 243 capability: Edge node>Relay node> Transit node; the more capable node 244 type can play a less capable node's role, for example, using a Relay 245 node as a transit node. However, this attribute doesn't implicate 246 specific functions of the node, which have their own corresponding 247 attributes stated in the following text. 249 3.1.2. Replication Capability 251 ReplicationCapability specifies whether a DetNet node has the 252 capability of packet replication. A DetNet Node with replication 253 capability can: 1) identify the packets that need to be replicated; 254 2) do packet replication; 3) encapsulate the replicated packets and 255 send them to different next hop. 257 3.1.3. Elimination Capability 259 EliminationCapability specifies whether a DetNet node has the 260 capability of packet elimination. DetNet Node with elimination 261 capability can: 1) record the packets that have been received from 262 different port; 2) Filter the redundant packets from the same flow 263 and eliminate the redundant packets; 3) encapsulate the first- 264 received packets and send them to the right next hop. 266 3.1.4. Queuing Management Algorithm 268 Queuing Management Algorithm is the most important method of 269 congestion protection, including scheduling, shaping and preemption. 270 IEEE defines some queuing management algorithms to guarantee TSN 271 service quality, most of them can be used in DetNet, for example: 273 o Credit-based shaper algorithm [IEEE802.1Q-2014] 275 o Frame Preemption[IEEE802.1Qbu] 277 o Scheduled Traffic [IEEE802.1Qbv] 278 o Per-Stream Filtering and Policing [IEEE802.1Qci] 280 o Cyclic Queuing and Forwarding [IEEE802.1Qch] 282 This attribute specifies which type of Queuing Management 283 Algorithm(s) is(are) used in the output queue for DetNet (except for 284 IEEE802.1Qci, which is normally used in input queue). 286 Editor's Note: Every queuing management algorithm has its parameters, 287 which are to be defined in the next step work. However, one of the 288 concerns of this part of work is whether it is out of the charter's 289 scope. 291 3.1.5. Resource Reservation Base 293 There is a set of parameters that inflence reservation operation for 294 the entire device. Those parameters are contained in Reservation 295 Base attribute, including the following parameters: 297 o MaxFanInPorts: maximum number of fan-in ports in the device 299 o MaxPacketSize: maximum packet size that the node allows to 300 transmit 302 o MaxDetNetClasses: maximum number of traffic classes that can be 303 reserved for DetNet 305 3.1.6. Bandwidth Metric 307 [I-D.ietf-teas-yang-te-topo] defines the following parameters for 308 bandwidth reservation: 310 o Max-link-bandwidth: maximum link bandwidth 312 o Max-resv-link-bandwidth: maximum reservable link bandwidth 314 o Unreserved-bandwidth(N): unreserved bandwidth for priority N 316 Considering the features of DetNet, bandwidth reservation parameters 317 for DetNet are defined as follows to augment the te-topology: 319 o Maximum DetNet Reservable Bandwidth(N): is represented as a 320 percentage of port transmit rate, that can be used by DetNet of 321 traffic class N and it is also available for other DetNet traffic 322 classes that have lower latency requirements; 324 o DetNet Unreserved Bandwidth(N): is represented as a percentage of 325 maximum DetNet Reservable bandwidth that has not been reserved; 327 For example, there are three classes of DetNet service A, B, and C, 328 with A the lowest latency and C the highest. 'Maximum DetNet 329 Reservable Bandwidth(N)' can be presented as 'MaxBw(N)'; DetNet 330 Unreserved Bandwidth(N) can be presented as 'UnBw(N)'. MaxBw(A) can 331 be used by A; MaxBw(B) can by used by A&B, and MaxBw(C) can be used 332 by A&B&C. So, if MaxBw(A)=10, MaxBw(B)=25, MaxBw(C)=40, and we 333 allocate 15 to A, 30 to B and 10 to C, then UnBw(A)=0, UnBw(B)= 0, 334 UnBw(C)=20. 336 3.1.7. Delay Metric 338 Delay Metric is used to describe the delay of every hop, which 339 includes the following parameters: 341 o Link Delay 343 o Maximum Packet Processing Delay 345 o Minimum Packet Processing Delay 347 o Maximum Output Queuing Delay 349 o Minimum Output Queuing Delay 351 Link Delay specifies the delay along the network media for a packet 352 transmitted from the specified Port of this station to the 353 neighboring Port on a different station. 355 Operations causing Packet Processing Delay includes: Per-Stream 356 Filtering and Policing([IEEE802.1Qci]), Flow Classification, Looking 357 up in Forwarding Information Base, and etc. It covers the process 358 from the packet being received by the node to the packet being sent 359 to the output queue. It is packet length dependent. 361 Queuing Delay specifies the delay for a packet in the output queue. 362 It is determined by the Queuing Management Algorithm and Port 363 Transmission Rate. 365 The delay of every hop is the sum of link delay, packet processing 366 delay and output queuing delay. 368 Editor's Note: The delay metric is also discussed in IEEE with other 369 considerations, which can be found: 370 and . More discussions are needed 373 here. 375 3.1.8. Synchronization Accuracy 377 Most of the DetNet service requires clock synchronization. 378 Synchronization Accuracy is necessary for queuing algorithm 379 configuration and delay prediction. For example, Synchronization 380 Accuracy is an important parameter when calculating the guard band 381 for CQF[IEEE802.1Qch]. 383 Editor's Note: The method used to achieve time synchronization is not 384 specified in this draft. 386 3.2. DetNet Path Configuration Attribute 388 Path Attribute is used for path configuration in DetNet Edge 389 Node(Ingress). 391 3.2.1. Path Constrains 393 DetNet path constrains are mainly based on the application 394 requirement, including maximum latency/number of replication trees, 395 and traffic specification, which can be used to calculate bandwidth 396 requirement[I-D.ietf-detnet-flow-information-model]. There may be 397 other path constrains when the path is established, which can be 398 added in this attribute in the future version. 400 3.2.2. Explicit Routing 402 Explicit routing attribute describes an end-to-end path for DetNet 403 flow, by listing nodes along the path in order and specifying their 404 types. The DetNet node type has been specified in section 4.1.1. If 405 service protection is needed, DetNet flow is replicated in relay 406 node, going through different paths, and eliminated in another relay 407 node. It makes the DetNet route a point-to-multipoint-to-point (P- 408 MP-P) path. In [RFC4875], explicit routing of a P-MP LSP is 409 represented by a P-MP tree. Similarly, a P-MP-P tree is needed in 410 DetNet, and the rules of building the tree is to be defined. 412 3.3. DetNet Flow Configuration Attribute 414 DetNet Configuration Attribute is used for path configuration after 415 the path has been calculated, preparing for the DetNet Flow 416 Transportation. 418 3.3.1. Flow Identification 420 Flow Identification is data plane relevant, and it is defined in 421 [I-D.ietf-detnet-flow-information-model]. 423 3.3.2. Traffic Specification 425 Traffic Specification is defined 426 in[I-D.ietf-detnet-flow-information-model] . 428 3.3.3. Encapsulation 430 [I-D.dt-detnet-dp-sol] defines more than one data plane protocols for 431 DetNet service, and DetNet Encapsulation attribute specifies the type 432 of encapsulation used in the node, including: 434 o MPLS Pseudo Wire 436 o Native IPv6 438 o TSN 440 Notes: In one DetNet domain, the encapsulation should be the same; 441 When a flow goes across different domains, the encapsulation needs to 442 be changed. For example, when an DetNet Edge Node connects two TSN 443 domains, at the entry or exit boundary of the DetNet domain, the 444 encapsulation needs to be changed accordingly. Parameters in the 445 encapsulation also needs to do the mapping. for example, the 446 translation from flow Unique ID defined [IEEE802.1Qcc] to DetNet flow 447 ID defined in [I-D.dt-detnet-dp-sol] should be defined in the 448 configuration of the edge node . 450 3.3.4. Flow Priority 452 Flow Priority attribute specifies the priority reserved for DetNet 453 flow in PSN header. The transit node can distinguish DetNet flow 454 from non-DetNet flow by DetNet priority. And, if more than one 455 DetNet priority is defined, it can also be used to describe DetNet 456 flows with different quality requirements, e.g. , low latency DetNet 457 flows and high latency DetNet flows. 459 Notes: In one DetNet domain, the priority reserved for DetNet should 460 be the same. When crossing DetNet domains, the priority should be 461 translated accordingly. For example, the priority transition from 462 TSN domain to DetNet domain is defined in 463 [I-D.varga-detnet-service-model] Annex 2 "Integrating Layer 3 and 464 Layer 2 QoS". 466 This attribute is also data plane relevant. If there is no priority 467 reserved for DetNet, other attribute should be specified to 468 distinguish DetNet flows. The mapping from flow priority to output 469 queue also makes it necessary to take queuing management 470 algorithm(section 3.1.4) into consideration when defining the DetNet 471 priority. 473 3.3.5. Queuing Parameters 475 Queuing Management Algorithm Type is described in section 3.1.4. 476 Different algorithm use different parameters to manage queue. In a 477 fully-centralized configuration model, the parameters can be 478 distributed by CNC; in a distributed configuration model, the device 479 can configure itself based on the application requirement and flow 480 traffic specification information. 482 The queuing management configuration parameters and the corresponding 483 YANG model are being defined in IEEE. For example, when stream 484 policing and filtering defined in[IEEE802.1Qci] is deployed in one 485 node, the parameter of Stream filter instance table ([IEEE802.1Qci] 486 8.6.5.1.1), Stream gate instance table ([IEEE802.1Qci] 8.6.5.1.2), 487 Flow meter instance table ([IEEE802.1Qci] 8.6.5.1.3) should be 488 configured by CNC or other control plane protocol. 490 3.3.6. Replication Function 492 This attribute specifies whether the node will do replication to the 493 packet of this flow. Configuration of Replication in relay node is 494 defined in [IEEE802.1CB]. 496 3.3.7. Elimination Function 498 This attribute specifies whether the node will do elimination to the 499 packet of a flow. For a multicast flow, elimination can be performed 500 on some ports, but not on others in one node. Configuration of 501 Elimination in relay node is defined in [IEEE802.1CB]. 503 3.3.8. Routing 505 Routing configuration is data plane relevant, but no matter what the 506 encapsulation is, the following attributes should be contained: 508 o Flow Identification: in the current data plane design, flow ID, PW 509 label or other relevant information can be used in flow 510 identification. Flow Identification Information may be not needed 511 in Transit Node; 513 o Operation: forwarding / replication / elimination / 514 elimination&replication; 516 o Next-hop; 517 o Encapsulation: the packet should be re-encapsulated after 518 replication or elimination. Usually, encapsulation Information is 519 not needed in the Transit Node; 521 It is also relevent to the data plane identification. Take MPLS 522 solution defined in [I-D.dt-detnet-dp-sol] 524 as an example: 526 Transit Node: Operation at a transit (P) node is normal MPLS 527 forwarding. The outer label is either swapped or popped as required, 528 and the packet is forwarded along the LSP. 530 Relay Node: S-lable is used to identfiy the flow and indicate whether 531 the packet should be replicated or eliminated or both. In ono of the 532 relay nodes in the path, the parameter table can be as follows: 534 ______________________________________________________________ 535 | Incoming | | | | Outcoming | 536 | S-Label | Flow ID | Replication | Elimination | S-Label | 537 -------------------------------------------------------------- 538 | Label-1 | Flow 1 | Yes | No | Label-5 | 539 -------------------------------------------------------------- 540 | Label-2 | Flow 2 | No | Yes | Label-6 | 541 -------------------------------------------------------------- 542 | Label-3 | Flow 3 | Yes | Yes | Label-7 | 543 -------------------------------------------------------------- 545 In this table, Lable-1/ Lable-2/ Label-3 are distributed from the 546 current relay node to the previous relay node in the path; Lable-5/ 547 Lable-6/ Label-7 are distributed from the next relay node to the 548 current relay node in the path; 550 3.4. DetNet Status Attribute 552 The DetNet status attributes are provided by the device for each 553 DetNet flow. The Status Attributes describe the status of the flow 554 when it is transmitted in the network. 556 3.4.1. Performance Status 558 Performance Status contains: 560 o Maximum Link Latency: which is measured by the packet's timestamp 562 o Packet Loss: which describes the packet loss of a particular flow 563 in this node 565 o Flow Policing and Filtering Status: the illegal behavior of the 566 flow that is recorded by the node 568 3.4.2. Replication/Elimination Status 570 Detailed discussion of Replication/Elimination status is specified in 571 [IEEE802.1CB]. 573 If the S-label indicates that the packet is supposed to be 574 eliminated, the relay node should read the sequence number of the 575 packet and see whether this packet has been received before. For 576 example, the parameters of one relay node can be: 578 _____________________________ 579 | Flow ID | Sequence Number | 580 ----------------------------- 581 | Flow 1 | 1001 | 582 ----------------------------- 583 | Flow 1 | 1002 | 584 ----------------------------- 585 | Flow 1 | 1003 | 586 ----------------------------- 588 If a packet of flow 1 with the sequence number of 1001 is received, 589 it should be dropped in this relay node; If a packet of flow 1 with 590 the sequence number of 1005 is received, it should be forwarded in 591 this relay node, and the parameter talbe will be updated. 593 4. DetNet Configuration YANG Model 595 This section specifies the network management information that is 596 used for the fully centralized DetNet configuration model. YANG 597 model for other configuration model is to be defined in the future 598 version of the draft. 600 4.1. DetNet Topology YANG Model 602 file "ietf-detnet-topology@2018-01-15.yang" 603 module ietf-te-detnet-topology { 604 namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-topology"; 605 prefix "detnet-to"; 607 import ietf-te-types { 608 prefix "te-types"; 609 } 611 import ietf-routing-types { 612 prefix "rt-types"; 613 } 615 import ietf-te-topology { 616 prefix "tet"; 617 } 619 import ietf-network { 620 prefix "nw"; 621 } 623 import ietf-network-topology { 624 prefix "nt"; 625 } 627 organization 628 "IETF Deterministic Networking(detnet)Working Group"; 630 contact 631 "WG Web: 632 WG List: 634 WG Chair: Lou Berger 635 637 Editor: Xuesong Geng 638 640 Editor: Mach Chen 641 "; 643 description 644 "This YAGN module augments the 'ietf-te-topology' 645 module with detnet capability data for detnet 646 configuration"; 648 revision "2018-01-15" { 649 description "Initial revision"; 650 reference "RFC XXXX: YANG Data Model for DetNet Topologies"; 651 //RFC Ed.: replace XXXX with actual RFC number and remove 652 // this note 653 } 655 grouping detnet-link-info-attributes{ 656 description 657 "DetNet capability attributes in a DetNet topology"; 658 container detnet-performance-metric-attributes{ 659 description 660 "Link performance information in real time."; 661 uses detnet-performance-metric-attributes; 662 } 663 container detnet-queuing-management-algorithm{ 664 description 665 "Detnet queuing management algorithm used in 666 output queue"; 667 uses detnet-queuing-management-algorithm; 668 } 669 } 671 grouping detnet-performance-metric-attributes{ 672 description 673 "Link performance information in real time."; 674 container maximum-detnet-reservable-bandwidth{ 675 uses te-types:te-bandwidth; 676 description 677 "This container specifies the maximum bandwidth 678 that is reserved for DetNet on this link."; 679 } 680 container reserved-detnet-bandwidth{ 681 uses te-types:te-bandwidth; 682 description 683 "This container specifies the bandwidth that has 684 been reserved for DetNet on this link."; 685 } 686 container available-detnet-bandwidth{ 687 uses te-types:te-bandwidth; 688 description 689 "This container specifies the bandwidth that can 690 be used for new DetNet flows on this link."; 691 } 692 leaf minimum-detnet-device-delay{ 693 type uint32; 694 description 695 "Minimum delay in the device for DetNet flows"; 696 } 697 leaf maximum-detnet-device-delay{ 698 type uint32; 699 description 700 "Maximum delay in the device for DetNet flows"; 701 } 702 } 704 grouping detnet-queuing-management-algorithm{ 705 description 706 "Detnet queuing management algorithm used in 707 output queue"; 709 leaf queuing-management-algorithm{ 710 type enumeration{ 711 enum credit-based-shaping{ 712 reference 713 "IEEE P802.1 Qav"; 714 } 715 enum time-aware-shaping{ 716 reference 717 "IEEE P802.1 Qbv"; 718 } 719 enum cyclic-queuing-and-forwarding{ 720 reference 721 "IEEE P802.1 Qch"; 722 } 723 enum asynchronous-traffic-shaping{ 724 reference 725 "IEEE P802.1 Qcr"; 726 } 727 } 728 description 729 "Detnet queuing management algorithm type"; 730 } 731 } 733 grouping detnet-node-info-attributes{ 734 description 735 "DetNet capability attributes in a DetNet node"; 736 container detnet-node-type{ 737 description 738 "Three types of DetNet nodes"; 739 reference 740 "draft-ietf-detnet-architecture-03: 741 Deterministic Networking Architecture"; 742 uses detnet-node-type; 743 } 744 container detnet-resource-reservation-attributes{ 745 description 746 "Attributes about resource reservation for 747 DetNet flows"; 748 uses detnet-resource-reservation-attributes; 749 } 750 leaf detnet-elimination-capability{ 751 type boolean; 752 description 753 "This node is able to do DetNet packet 754 elimination"; 755 } 756 leaf detnet-replication-capability{ 757 type boolean; 758 description 759 "This node is able to do DetNet packet 760 replication"; 761 } 762 } 764 grouping detnet-node-type{ 765 description 766 "This grouping defines three types of DetNet nodes"; 767 reference 768 "draft-ietf-detnet-architecture-03:Deterministic 769 Networking Architecture"; 770 leaf detnet-node-type{ 771 type enumeration{ 772 enum edge-node{ 773 description 774 "An instance of a DetNet relay node that 775 includes either a DetNet service layer proxy 776 function for DetNet service protection (e.g. 777 the addition or removal of packet sequencing 778 information) for one or more end systems, or 779 starts or terminate congestion protection at 780 the DetNet transport layer,analogous to a 781 Label Edge Router (LER)."; 782 } 783 enum relay-node{ 784 description 785 "A DetNet node including a service layer 786 function that interconnects different DetNet 787 transport layer paths to provide service 788 protection.A DetNet relay node can be a bridge, 789 a router, a firewall, or any other system that 790 participates in the DetNet service layer. It 791 typically incorporates DetNet transport layer 792 functions as well, in which case it is 793 collocated with a transit node."; 794 } 795 enum transit-node{ 796 description 797 "A node operating at the DetNet transport layer, 798 that utilizes link layer and/or network layer 799 switching across multiple links and/or 800 sub-networks to provide paths for DetNet 801 service layer functions.Optionally provides 802 congestion protection over those paths.An MPLS 803 LSR is an example of a DetNet transit node."; 805 } 806 } 807 description 808 "The type this node belongs to, which also determines 809 the role the node can play in DetNet "; 810 } 811 } 813 grouping detnet-resource-reservation-attributes{ 814 description 815 "This grouping describs reservation operation for 816 the entire device"; 817 leaf MaxFanInPorts{ 818 type uint32; 819 description 820 "maximum number of fan-in ports in the device"; 821 } 822 leaf MaxPacketSize{ 823 type uint32; 824 description 825 "maximum Packet size the device allows"; 826 } 827 leaf MaxDetNetClasses{ 828 type uint32; 829 description 830 "maximum number of traffic classes that can be 831 reserved for DetNet"; 832 } 833 } 835 augment "/nw:networks/nw:network/nw:node" { 836 when "../nw:network-types/tet:te-topology" 837 { 838 description 839 ""; 840 } 841 description 842 "Advertised DetNet link information attributes."; 843 uses detnet-link-info-attributes; 844 } 846 augment "/nw:networks/nw:network/nt:link" { 847 when "../nw:network-types/tet:te-topology" 848 { 849 description 850 ""; 851 } 852 description 853 "Advertised DetNet node information attributes."; 854 uses detnet-node-info-attributes; 855 } 856 } 857 859 4.2. DetNet Static Configuration YANG Model 861 file "ietf-detnet-static @2018-01-15.yang" 862 module ietf-detnet-static { 863 namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-static"; 864 prefix "detnet-static"; 866 import ietf-routing { 867 prefix "rt"; 868 } 870 import ietf-yang-types{ 871 prefix "yang"; 872 } 874 import ietf-inet-types{ 875 prefix "inet"; 876 } 878 import ietf-routing-types { 879 prefix "rt-types"; 880 } 882 organization 883 "IETF Deterministic Networking(detnet)Working Group"; 885 contact 886 "WG Web: 887 WG List: 889 WG Chair: Lou Berger 890 892 Editor: Xuesong Geng 893 895 Editor: Mach Chen 896 "; 898 description 899 "This YAGN module augments the 'ietf-routing'module 900 with detnet flow configuration attribute"; 902 revision "2018-01-15" { 903 description "Initial revision"; 904 reference "RFC XXXX: YANG Data Model for DetNet Topologies"; 905 //RFC Ed.: replace XXXX with actual RFC number and remove 906 // this note 907 } 909 grouping flow-identfication { 910 description 911 "DetNet flow identification"; 912 reference 913 "draft-farkas-detnet-flow-information-model"; 914 leaf source-ip-address { 915 type inet:ip-address; 916 description 917 "Source IP address"; 918 } 919 leaf destination-ip-address { 920 type inet:ip-address; 921 description 922 "Destination IP address"; 923 } 924 leaf source-mac-address { 925 type yang:mac-address; 926 description 927 "Source MAC address"; 928 } 929 leaf destination-mac-address { 930 type yang:mac-address; 931 description 932 "Destination MAC address"; 933 } 934 leaf ipv6-flow-label { 935 type uint32; 936 description 937 "ipv6 flow label"; 938 } 939 leaf mpls-label { 940 type rt-types:mpls-label; 941 description 942 "MPLS Label"; 943 } 944 } 946 grouping traffic-specification{ 947 description 948 "traffic-specification specifies how the Source 949 transmits packets for the flow. This is the 950 promise/request of the Source to the network. 951 The network uses this traffic specification 952 to allocate resources and adjust queue 953 parameters in network nodes."; 954 reference 955 "draft-farkas-detnet-flow-information-model"; 956 leaf max-packets-per-interval{ 957 type uint16; 958 description 959 "max-packets-per-interval specifies the maximum 960 number of packets that the application shall 961 transmit in one Interval."; 962 } 963 leaf max-packet-size{ 964 type uint16; 965 description 966 "max-packet-size specifies maximum packet size 967 that the Source will transmit"; 968 } 969 leaf queuing-algorithm-selection{ 970 type uint8; 971 description 972 ""; 973 } 974 } 976 grouping routing-configuration{ 977 description 978 "configuration parameters direct data plane 979 operations"; 980 container flow-identification{ 981 description 982 "flow identification"; 983 uses flow-identfication; 984 } 985 leaf operation{ 986 type enumeration{ 987 enum transmission{ 988 description 989 "Operation: transmit "; 990 } 991 enum replication{ 992 description 993 "Operation: packet replication"; 994 } 995 enum elimination{ 996 description 997 "Operation: packet elimination"; 999 } 1000 enum elimination-and-replication{ 1001 description 1002 "Operation: packet elimination and 1003 replication"; 1004 } 1005 } 1006 description 1007 "The operation will be done to the 1008 packet"; 1009 } 1010 } 1012 grouping queuing-parameters{ 1013 description 1014 "The paramters used to configure 1015 queuing managment algorithm"; 1016 } 1018 grouping replication-function{ 1019 description 1020 "The paramters used to configure 1021 packet replication"; 1022 } 1024 grouping elimination-function{ 1025 description 1026 "The paramters used to configure 1027 packet elimination"; 1028 } 1030 augment "/rt:routing"{ 1031 description 1032 "DetNet node static configuration 1033 attributes."; 1034 uses flow-identfication; 1035 uses traffic-specification; 1036 uses routing-configuration; 1037 uses queuing-parameters; 1038 uses replication-function; 1039 uses elimination-function; 1040 } 1041 } 1042 1044 5. DetNet Configuration Model Classification 1046 This section defines three classes of DetNet configuration model: 1047 fully distributed configuration model, fully centralized 1048 configuration model, hybrid configuration model, based on different 1049 network architectures, showing how configuration information 1050 exchanges between various entities in the network. 1052 5.1. Fully Distributed Configuration Model 1054 In a fully distributed configuration model, UNI information is 1055 transmitted over DetNet UNI protocol from the user side to the 1056 network side; then UNI information and network configuration 1057 information propagate in the network over distributed control plane 1058 protocol. For example: 1060 1) IGP collects topology information and DetNet capabilities of 1061 network([I-D.geng-detnet-info-distribution]); 1063 2) Control Plane of the Edge Node(Ingress) receives a flow 1064 establishment request from UNI and calculates a/some valid path(s); 1066 3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 1067 explicit route. After receiving the PATH message, the other Edge 1068 Node(Egress) sends a Resv message with distributed label and resource 1069 reservation request. 1071 Current distributed control plane protocol,e.g., RSVP-TE[RFC3209], 1072 SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while 1073 the configuration of a fine-grained schedule, e.g.,Time Aware 1074 Shaping(TAS) defined in [IEEE802.1Qbv], is not supported. 1076 The fully distributed configuration model is not covered by this 1077 draft. It should be discussed in the future DetNet control plane 1078 work. 1080 5.2. Fully Centralized Configuration Model 1082 In the fully centralized configuration model, UNI information is 1083 transmitted from Centralized User Configuration (CUC) to Centralized 1084 Network Configuration(CNC). Configurations of routers for DetNet 1085 flows are performed by CNC with network management protocol.For 1086 example: 1088 1) CNC collects topology information and DetNet capability of network 1089 through Netconf; 1090 2) CNC receives a flow establishment request from UNI and calculates 1091 a/some valid path(s); 1093 3) CNC configures the devices along the path for flow transmission. 1095 5.3. Hybrid Configuration Model 1097 In the hybrid configuration model, controller and control plane 1098 protocols work together to offer DetNet service, and there are a lot 1099 of possible combinations. For example: 1101 1) CNC collects topology information and DetNet capability of network 1102 through IGP/BGP-LS; 1104 2) CNC receives a flow establishment request from UNI and calculates 1105 a/some valid path(s); 1107 3) Based on the calculation result, CNC distributes flow path 1108 information to Edge Node(Ingress) and other information(e.g. 1109 replication/elimination) to the relevant nodes. 1111 4) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 1112 explicit route. After receiving the PATH message, the other Edge 1113 Node(Egress) sends a Resv message with distributed label and resource 1114 reservation request. 1116 or 1118 1) Controller collects topology information and DetNet capability of 1119 network through IGP/BGP-LS; 1121 2) Control Plane of Edge Node(Ingress) receives a flow establishment 1122 request from UNI; 1124 3) Edge Node(Ingress) sends the path establishment request to CNC 1125 through PCEP; 1127 4) After Calculation, CNC sends back the path information of the flow 1128 to the Edge Node(Ingress) through PCEP; 1130 5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 1131 explicit route. After receiving the PATH message, the other Edge 1132 Node(Egress) sends a Resv message with distributed label and resource 1133 reservation request. 1135 There are also other variations that can be included in the hybrid 1136 model. This draft can not coverer all the control plane data needed 1137 in hybrid configuration models. Every solution has there own 1138 mechanism and corresponding parameters to make it work. 1140 Editor's Note: 1142 1. There are a lot of optional DetNet configuration models, and 1143 different scenario in different use case can choose one of them based 1144 on its conditions. Maybe next step of the work is to pick up one or 1145 more typical scenarios and give a practical solution. 1147 2. [IEEE802.1Qcc] also defines three TSN configuration models: 1148 fully-centralized model, fully-distributed model, centralized Network 1149 / distributed User Model. This section defines the configuration 1150 model roughly the same, to keep the design of L2 and L3 in the same 1151 structure. Hybrid configuration model is slightly different from the 1152 'centralized Network / distributed User Model'. The hybrid 1153 configuration model intends to contain more variations. 1155 6. IANA Considerations 1157 This document makes no request of IANA. 1159 Note to RFC Editor: this section may be removed on publication as an 1160 RFC. 1162 7. Security Considerations 1164 8. Acknowledgements 1166 9. References 1168 9.1. Normative References 1170 [I-D.dt-detnet-dp-sol] 1171 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 1172 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 1173 "DetNet Data Plane Encapsulation", draft-dt-detnet-dp- 1174 sol-02 (work in progress), September 2017. 1176 [I-D.ietf-detnet-architecture] 1177 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1178 "Deterministic Networking Architecture", draft-ietf- 1179 detnet-architecture-04 (work in progress), October 2017. 1181 [I-D.ietf-detnet-flow-information-model] 1182 Farkas, J., Varga, B., rodney.cummings@ni.com, r., Jiang, 1183 Y., and Y. Zha, "DetNet Flow Information Model", draft- 1184 ietf-detnet-flow-information-model-00 (work in progress), 1185 January 2018. 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, 1189 DOI 10.17487/RFC2119, March 1997, 1190 . 1192 9.2. Informative References 1194 [I-D.geng-detnet-info-distribution] 1195 Geng, X. and M. Chen, "IGP-TE Extensions for DetNet 1196 Information Distribution", draft-geng-detnet-info- 1197 distribution-01 (work in progress), September 2017. 1199 [I-D.ietf-detnet-use-cases] 1200 Grossman, E., "Deterministic Networking Use Cases", draft- 1201 ietf-detnet-use-cases-14 (work in progress), February 1202 2018. 1204 [I-D.ietf-teas-yang-te] 1205 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 1206 I. Bryskin, "A YANG Data Model for Traffic Engineering 1207 Tunnels and Interfaces", draft-ietf-teas-yang-te-12 (work 1208 in progress), February 2018. 1210 [I-D.ietf-teas-yang-te-topo] 1211 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1212 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1213 Topologies", draft-ietf-teas-yang-te-topo-15 (work in 1214 progress), February 2018. 1216 [I-D.thubert-tsvwg-detnet-transport] 1217 Thubert, P., "A Transport Layer for Deterministic 1218 Networks", draft-thubert-tsvwg-detnet-transport-01 (work 1219 in progress), October 2017. 1221 [I-D.varga-detnet-service-model] 1222 Varga, B. and J. Farkas, "DetNet Service Model", draft- 1223 varga-detnet-service-model-02 (work in progress), May 1224 2017. 1226 [IEEE802.1CB] 1227 "IEEE, "Frame Replication and Elimination for Reliability 1228 (IEEE Draft P802.1CB)", 2017, 1229 .", 1230 2016. 1232 [IEEE802.1Q-2014] 1233 "IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks", 1234 2014, .", 1235 2014. 1237 [IEEE802.1Qbu] 1238 "IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks - 1239 Amendment 26: Frame Preemption", 2016, 1240 .", 2016. 1242 [IEEE802.1Qbv] 1243 "IEEE, "IEEE Std 802.1Qbu Bridges and Bridged Networks - 1244 Amendment 25: Enhancements for Scheduled Traffic", 2015, 1245 .", 2016. 1247 [IEEE802.1Qcc] 1248 "IEEE, "Stream Reservation Protocol (SRP) Enhancements and 1249 Performance Improvements (IEEE Draft P802.1Qcc)", 2017, 1250 .". 1252 [IEEE802.1Qch] 1253 "IEEE, "Cyclic Queuing and Forwarding (IEEE Draft 1254 P802.1Qch)", 2017, 1255 .", 1256 2016. 1258 [IEEE802.1Qci] 1259 "IEEE, "Per-Stream Filtering and Policing (IEEE Draft 1260 P802.1Qci)", 2016, 1261 .", 1262 2016. 1264 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1265 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1266 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1267 . 1269 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1270 Yasukawa, Ed., "Extensions to Resource Reservation 1271 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1272 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1273 DOI 10.17487/RFC4875, May 2007, 1274 . 1276 Authors' Addresses 1278 Xuesong Geng 1279 Huawei 1281 Email: gengxuesong@huawei.com 1283 Mach(Guoyi) Chen 1284 Huawei 1286 Email: mach.chen@huawei.com 1288 Zhenqiang 1289 China Mobile 1291 Email: lizhenqiang@chinamobile.com