idnits 2.17.1 draft-geng-detnet-conf-yang-00.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 678 has weird spacing: '... enum cycli...' == Line 682 has weird spacing: '... enum async...' == Line 749 has weird spacing: '... enum trans...' -- The document date (October 29, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1002, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 == Outdated reference: A later version (-04) exists of draft-geng-detnet-info-distribution-01 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-09 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-13 Summary: 0 errors (**), 0 flaws (~~), 9 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: Experimental Huawei 5 Expires: May 2, 2018 October 29, 2017 7 DetNet Configuration YANG Model 8 draft-geng-detnet-conf-yang-00 10 Abstract 12 This document describes configuration model for Deterministic 13 Networking(DetNet). It defines DetNet configuration attribute and 14 the corresponding YANG model, which is used for DetNet capabilities 15 configuration/discovery, DetNet flow configuration and DetNet flow 16 status collection in the network. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 2, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. DetNet Configuration Model . . . . . . . . . . . . . . . . . 3 61 3.1. Fully Distributed Configuration . . . . . . . . . . . . . 3 62 3.2. Fully Centralized Configuration . . . . . . . . . . . . . 4 63 3.3. Hybrid Configuration . . . . . . . . . . . . . . . . . . 4 64 4. DetNet Configuration Attribute . . . . . . . . . . . . . . . 5 65 4.1. DetNet Topology Attribute . . . . . . . . . . . . . . . . 6 66 4.1.1. Node Type . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1.2. Replication Capability . . . . . . . . . . . . . . . 6 68 4.1.3. Elimination Capability . . . . . . . . . . . . . . . 6 69 4.1.4. Queuing Management Algorithm . . . . . . . . . . . . 7 70 4.1.5. Reservation Base . . . . . . . . . . . . . . . . . . 7 71 4.1.6. Bandwidth Metric . . . . . . . . . . . . . . . . . . 7 72 4.1.7. Delay Metric . . . . . . . . . . . . . . . . . . . . 8 73 4.1.8. Synchronization Accuracy . . . . . . . . . . . . . . 9 74 4.2. DetNet Path Configuration Attribute . . . . . . . . . . . 9 75 4.2.1. Path Constrains . . . . . . . . . . . . . . . . . . . 9 76 4.2.2. Explicit Routing . . . . . . . . . . . . . . . . . . 9 77 4.3. DetNet Flow Configuration Attribute . . . . . . . . . . . 10 78 4.3.1. Flow Identification . . . . . . . . . . . . . . . . . 10 79 4.3.2. Traffic Specification . . . . . . . . . . . . . . . . 10 80 4.3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . 10 81 4.3.4. Flow Priority . . . . . . . . . . . . . . . . . . . . 10 82 4.3.5. Queuing Parameters . . . . . . . . . . . . . . . . . 11 83 4.3.6. Replication Function . . . . . . . . . . . . . . . . 11 84 4.3.7. Elimination Function . . . . . . . . . . . . . . . . 11 85 4.3.8. Routing . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.4. DetNet Status Attribute . . . . . . . . . . . . . . . . . 12 87 4.4.1. Performance Status . . . . . . . . . . . . . . . . . 12 88 4.4.2. Replication/Elimination Status . . . . . . . . . . . 12 89 5. DetNet Configuration YANG Model . . . . . . . . . . . . . . . 12 90 5.1. DetNet Topology YANG Model . . . . . . . . . . . . . . . 13 91 5.2. DetNet Static Configuration YANG Model . . . . . . . . . 17 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 9.2. Informative References . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 A Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] 103 provides a capability to carry a unicast or a multicast data flow for 104 an application with strict service quality requirements, e.g., 105 extremely low packet loss rate and bounded latency. The DetNet 106 service is provided either for a Layer 3 (L3) flow or a Layer 2 (L2) 107 flow by an IP/MPLS network. 109 This document describes configuration model for Deterministic 110 Networking(DetNet). It defines DetNet configuration attribute and 111 the corresponding YANG model, which is used for DetNet capabilities 112 configuration/discovery, DetNet flow configuration and DetNet flow 113 status collection in the network. 115 This draft includes three parts: DetNet configuration model defined 116 in section 3, DetNet configuration attribute defined in section 4 and 117 DetNet configuration YANG model defined in section 5. 119 2. Terminologies 121 This documents uses the terminologies defined 122 in[I-D.ietf-detnet-architecture]. 124 3. DetNet Configuration Model 126 This section introduces three kinds of DetNet configuration models. 127 The models can cover different network architectures, showing how 128 configuration information exchanges between various entities in the 129 network. Example with candidate control plane protocol is attached 130 to each configuration model to show how DetNet may work in current 131 Layer 3 network. To make the configuration model complete, user/ 132 network interface(UNI) information is also included in this section. 133 UNI Information is out of scope of this draft, and more discussions 134 about DetNet UNI information can be found in 135 [I-D.farkas-detnet-flow-information-model]. 137 3.1. Fully Distributed Configuration 139 In a fully distributed configuration model, UNI information is 140 transmitted over DetNet UNI protocol from the user side to the 141 network side; then UNI information and network configuration 142 information propagate in the network over distributed control plane 143 protocol. For example: 145 1) IGP collects topology information and DetNet capabilities of 146 network([I-D.geng-detnet-info-distribution]); 148 2) Control Plane of the Edge Node(Ingress) receives a flow 149 establishment request from UNI and calculates a/some valid path(s); 151 3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 152 explicit route. After receiving the PATH message, the other Edge 153 Node(Egress) sends a Resv message with distributed label and resource 154 reservation request. 156 Current distributed control plane protocol,e.g., RSVP-TE[RFC3209], 157 SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while 158 the configuration of a fine-grained schedule, e.g.,Time Aware 159 Shaping(TAS) defined in [IEEE802.1Qbv], is not supported. 161 The fully distributed configuration model is not covered by this 162 draft. It should be discussed in the future DetNet control plane 163 work. 165 3.2. Fully Centralized Configuration 167 In the fully centralized configuration model, UNI information is 168 transmitted from Centralized User Configuration (CUC) to Centralized 169 Network Configuration(CNC). Configurations of routers for DetNet 170 flows are performed by CNC with network management protocol.For 171 example: 173 1) CNC collects topology information and DetNet capability of network 174 through Netconf; 176 2) CNC receives a flow establishment request from UNI and calculates 177 a/some valid path(s); 179 3) CNC configures the devices along the path for flow transmission. 181 3.3. Hybrid Configuration 183 In the hybrid configuration model, controller and control plane 184 protocols are used together to offer DetNet service, and there are a 185 lot of possible combinations. For example: 187 1) CNC collects topology information and DetNet capability of network 188 through IGP/BGP-LS; 190 2) CNC receives a flow establishment request from UNI and calculates 191 a/some valid path(s); 192 3) Based on the calculation result, CNC distributes flow path 193 information to Edge Node(Ingress) and other information(e.g. 194 replication/elimination) to the relevant nodes. 196 or 198 1) IGP collects topology information and DetNet capability of network 199 through IGP/BGP-LS; 201 2) Control Plane of Edge Node(Ingress) receives a flow establishment 202 request from UNI; 204 3) Edge Node(Ingress) sends the path establishment request to CNC 205 through PCEP; 207 4) After Calculation, CNC sends back the path information of the flow 208 to the Edge Node(Ingress) through PCEP; 210 5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 211 explicit route. After receiving the PATH message, the other Edge 212 Node(Egress) sends a Resv message with distributed label and resource 213 reservation request. 215 There are also other variations that can included in the hybrid 216 model. The hybrid configuration model is not covered by this draft. 217 It should be discussed in the future DetNet control plane work. 219 Note: [IEEE802.1Qcc] also defines three TSN configuration models: 220 fully-centralized model, fully-distributed model, centralized Network 221 / distributed User Model. This section defines the configuration 222 model roughly the same, to keep the design of L2 and L3 in the same 223 structure. Hybrid configuration model is slightly different from the 224 'centralized Network / distributed User Model' , which intends to 225 contain more variations. 227 4. DetNet Configuration Attribute 229 According to section 3, different configuration model with different 230 control plane protocol or yang model use different configuration 231 attribute. This section tries to cover the possible attributes that 232 is used in fully centralized configuration model. Some of the 233 attributes can also be used as reference of the definition of other 234 two configuration models in the future work. 236 Note: When the working group get the control plane into 237 consideration, other yang models that cooperate with or configure the 238 control plane protocols should also be included in this draft 240 4.1. DetNet Topology Attribute 242 DetNet Topology Attribute is the basis of path computation, 243 describing the DetNet relative topology and capability of the 244 network. 246 4.1.1. Node Type 248 There are three kinds of DetNet nodes defined in 249 [I-D.ietf-detnet-architecture]: Edge Node, Relay Node and Transit 250 Node. 252 Edge node includes either a DetNet service layer proxy function for 253 DetNet service protection (e.g. the addition or removal of packet 254 sequencing information) for one or more end systems, or starts or 255 terminates congestion protection at the DetNet transport layer. 256 Boundary of a DetNet Domain SHALL be an edge note. 258 Relay node includes a service layer function that interconnects 259 different DetNet transport layer paths to provide service protection. 260 A DetNet relay node can be a bridge, a router, a firewall, or any 261 other system that participates in the DetNet service layer. It 262 typically incorporates DetNet transport layer functions as well, in 263 which case it is collocated with a transit node. 265 Transit node operates at the DetNet transport layer, that utilizes 266 link layer and/or network layer switching across multiple links and/ 267 or sub-networks to provide paths for DetNet service layer functions. 268 Optionally provides congestion protection over those paths. An MPLS 269 LSR is an example of a DetNet transit node. 271 NodeType specifies which type a DetNet node belongs to, which also 272 indicates its role in the DetNet service. 274 4.1.2. Replication Capability 276 ReplicationCapability specifies whether a DetNet node has the 277 capability of packet replication. Replication Capability 278 requirements include: 1) identify the packets that need to be 279 replicated; 2) do packet replication; 3) encapsulate the replicated 280 packets and send them to different next hop. 282 4.1.3. Elimination Capability 284 EliminationCapability specifies whether a DetNet node has the 285 capability of packet elimination. Elimination Capability 286 requirements include: 1) record the packets that have been received 287 from different port; 2) eliminate the redundant packets; 3) 288 encapsulate the first-received packets and send them to the next hop. 290 4.1.4. Queuing Management Algorithm 292 IEEE defines some queuing management algorithms to guarantee TSN 293 service quality, most of them can be used in DetNet, for example: 295 o Credit-based shaper algorithm [IEEE802.1Q-2014] 297 o Frame Preemption[IEEE802.1Qbu] 299 o Scheduled Traffic [IEEE802.1Qbv] 301 o Per-Stream Filtering and Policing [IEEE802.1Qci] 303 o Cyclic Queuing and Forwarding [IEEE802.1Qch] 305 This attribute specifies what kind of Queuing Management Algorithm(s) 306 is(are) used in the output queue for DetNet (except for IEEE802.1Qci, 307 which is always used in input queue) . 309 4.1.5. Reservation Base 311 There is a set of parameters that describe reservation operation for 312 the entire device. Those parameters are contained in Reservation 313 Base attribute, including the following parameters: 315 o MaxFanInPorts: maximum number of fan-in ports in the device 317 o MaxPacketSize: maximum packet size that the node allows to 318 transmit 320 o MaxDetNetClasses: maximum number of traffic classes that can be 321 reserved for DetNet 323 4.1.6. Bandwidth Metric 325 [I-D.ietf-teas-yang-te-topo] defines the following parameters for 326 bandwidth reservation: 328 o Max-link-bandwidth: maximum link bandwidth 330 o Max-resv-link-bandwidth: maximum reservable link bandwidth 332 o Unreserved-bandwidth(N): unreserved bandwidth for priority N 333 Considering the features of DetNet, bandwidth reservation parameters 334 for DetNet are defined as follows to augment the te-topology: 336 o Maximum DetNet Reservable Bandwidth(N): is represented as a 337 percentage of port transmit rate, that can be used by DetNet of 338 traffic class N and it is also available for other DetNet traffic 339 classes that have lower latency requirements; 341 o DetNet Unreserved Bandwidth(N): is represented as a percentage of 342 maximum DetNet Reservable bandwidth that has not been reserved; 344 For example, there are three classes of DetNet service A, B, and C, 345 with A the lowest latency and C the highest. 'Maximum DetNet 346 Reservable Bandwidth(N)' can be presented as 'MaxBw(N)'; DetNet 347 Unreserved Bandwidth(N) can be presented as 'UnBw(N)'. MaxBw(A) can 348 be used by A; MaxBw(B) can by used by A&B, and MaxBw(C) can be used 349 by A&B&C. So, if MaxBw(A)=10, MaxBw(B)=25, MaxBw(C)=40, and we 350 allocate 15 to A, 30 to B and 10 to C, then UnBw(A)=0, UnBw(B)= 0, 351 UnBw(C)=20. 353 4.1.7. Delay Metric 355 Delay Metric is used to describe the delay of every hop, which 356 includes the following parameters: 358 o Link Delay 360 o Maximum Packet Processing Delay 362 o Minimum Packet Processing Delay 364 o Maximum Output Queuing Delay 366 o Minimum Output Queuing Delay 368 Link Delay specifies the delay along the network media for a packet 369 transmitted from the specified Port of this station to the 370 neighboring Port on a different station. 372 Packet Processing Delay includes: Per-Stream Filtering and 373 Policing([IEEE802.1Qci]), Flow Classification, Looking up in 374 Forwarding Information Base, and etc. It covers the process from the 375 packet being received by the node to the packet being sent to the 376 output queue. It is packet length dependent. 378 Queuing Delay specifies the delay for a packet in the output queue. 379 It is determined by the Queuing Management Algorithm and Port 380 Transmission Rate. 382 The delay of every hop is the sum of link delay, packet processing 383 delay and output queuing delay. 385 Notes: The delay metric is also discussed in IEEE with other 386 considerations, which can be found: 387 and . More discussions are needed 390 here. 392 4.1.8. Synchronization Accuracy 394 Most of the DetNet service requires clock synchronization. 395 Synchronization Accuracy is necessary for queuing algorithm 396 configuration and delay prediction. For example, Synchronization 397 Accuracy is an important parameter when calculating the guard band 398 for CQF[IEEE802.1Qch]. 400 Note: The method used to achieve time synchronization is not 401 specified in this draft. 403 4.2. DetNet Path Configuration Attribute 405 Path Attribute is used for path configuration in DetNet Edge 406 Node(Ingress). 408 4.2.1. Path Constrains 410 DetNet path constrains are mainly based on the application 411 requirement, including maximum latency/number of replication trees, 412 and traffic specification, which can be used to calculate bandwidth 413 requirement[I-D.farkas-detnet-flow-information-model]. There may be 414 other path constrains when the path is established, which can be 415 added in this attribute in the future version. 417 4.2.2. Explicit Routing 419 Explicit routing attribute describes an end-to-end path for DetNet 420 flow, by listing nodes along the path in order and specifying their 421 types. The DetNet node type has been specified in section 4.1.1. If 422 service protection is needed, DetNet flow is replicated in relay 423 node, going through different paths, and eliminated in another relay 424 node. It makes the DetNet route a point-to-multipoint-to-point (P- 425 MP-P) path. In [RFC4875], explicit routing of a P-MP LSP is 426 represented by a P-MP tree. Similarly, a P-MP-P tree is needed in 427 DetNet, and the rules of building the tree is to be defined. 429 4.3. DetNet Flow Configuration Attribute 431 DetNet Configuration Attribute is used for path configuration after 432 the path has been calculated, preparing for the DetNet Flow 433 Transportation. 435 4.3.1. Flow Identification 437 Flow Identification is data plane relevant, and it is defined in 438 [I-D.farkas-detnet-flow-information-model]. 440 4.3.2. Traffic Specification 442 Traffic Specification is defined 443 in[I-D.farkas-detnet-flow-information-model] . 445 4.3.3. Encapsulation 447 [I-D.dt-detnet-dp-sol] defines more than one data plane protocols for 448 DetNet service, and DetNet Encapsulation attribute specifies the type 449 of encapsulation used in the node, including: 451 o MPLS Pseudo Wire 453 o Native IPv6 455 o TSN 457 Notes: In one DetNet domain, the encapsulation should be the same; 458 When a flow goes across different domains, the encapsulation needs to 459 be changed. For example, when an DetNet Edge Node connects two TSN 460 domains, at the entry or exit boundary of the DetNet domain, the 461 encapsulation needs to be changed accordingly. Parameters in the 462 encapsulation also needs to do the mapping. for example, the 463 translation from flow Unique ID defined [IEEE802.1Qcc] to DetNet flow 464 ID defined in [I-D.dt-detnet-dp-sol] should be defined in the 465 configuration of the edge node . 467 4.3.4. Flow Priority 469 Flow Priority attribute specifies the priority reserved for DetNet 470 flow in PSN header. The intermediate node can distinguish DetNet 471 flow from non-DetNet flow by DetNet priority. And, if more than one 472 DetNet priority is defined, it can also be used to describe DetNet 473 flows with different quality requirements, e.g. , low latency DetNet 474 flows and high latency DetNet flows. 476 Notes: In one DetNet domain, the priority reserved for DetNet should 477 be the same. When crossing DetNet domains, the priority should be 478 translated accordingly. For example, the priority translation from 479 TSN domain to DetNet domain is defined in 480 [I-D.varga-detnet-service-model] Annex 2 "Integrating Layer 3 and 481 Layer 2 QoS". 483 This attribute is also data plane relevant. If there is no priority 484 reserved for DetNet, other attribute should be specified to 485 distinguish DetNet flows. The mapping from flow priority to output 486 queue also makes it necessary to take queuing management 487 algorithm(section 4.1.4) into consideration when defining the DetNet 488 priority. 490 4.3.5. Queuing Parameters 492 Queuing Management Algorithm Type is described in section 4.1.4. 493 Different algorithm use different parameters to manage queue. In a 494 fully-centralized configuration model, the parameters can be 495 distributed by CNC; in a distributed configuration model, the device 496 can configure itself based on the application requirement and flow 497 traffic specification information. 499 The queuing management configuration parameters and the corresponding 500 YANG model are being defined in IEEE. For example, when stream 501 policing and filtering defined in[IEEE802.1Qci] is deployed in one 502 node, the parameter of Stream filter instance table (IEEE P802.1Qci 503 8.6.5.1.1), Stream gate instance table (IEEE P802.1Qci 8.6.5.1.2), 504 Flow meter instance table (IEEE P802.1Qci 8.6.5.1.3) should be 505 configured by CNC or other control plane protocol. 507 4.3.6. Replication Function 509 This attribute specifies whether the node will do replication to the 510 packet of this flow. Configuration of Replication in relay node is 511 defined in [IEEE802.1CB]. 513 4.3.7. Elimination Function 515 This attribute specifies whether the node will do elimination to the 516 packet of a flow. For a multicast flow, elimination can be performed 517 on some ports, but not on others in one node. Configuration of 518 Elimination in relay node is defined in [IEEE802.1CB]. 520 4.3.8. Routing 522 Routing configuration is data plane relevant, but no matter what the 523 encapsulation is, the following attributes should be contained: 525 o Flow Identification: in the current data plane design, flow ID, PW 526 label or other relevant information can be used in flow 527 identification. Flow Identification Information may be not needed 528 in Transit Node; 530 o Operation: transmission / replication / elimination / 531 elimination&replication; 533 o Next-hop; 535 o Encapsulation: the packet should be re-encapsulated after 536 replication or elimination. Usually, encapsulation Information is 537 not needed in the Transit Node; 539 4.4. DetNet Status Attribute 541 The DetNet status attributes are provided by the device for each 542 DetNet flow. The Status Attributes describe the status of the flow 543 when it is transmitted in the network. 545 4.4.1. Performance Status 547 Performance Status contains: 549 o Maximum Link Latency: which is measured by the packet's timestamp 551 o Packet Loss: which describes the packet loss of a particular flow 552 in this node 554 o Flow Policing and Filtering Status: the illegal behavior of the 555 flow that is recorded by the node 557 4.4.2. Replication/Elimination Status 559 Detailed discussion of Replication/Elimination status is specified in 560 [IEEE802.1CB]. 562 5. DetNet Configuration YANG Model 564 This section specifies the network management information that is 565 used for the fully centralized DetNet configuration model. YANG 566 model for other configuration model is to be defined in the future 567 version of the draft. 569 5.1. DetNet Topology YANG Model 571 file "ietf-detnet-topology@2017-10-24.yang" 572 module ietf-te-detnet-topology { 573 yang-version 1.0; 574 namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-topology"; 576 prefix "detnet-to"; 578 import ietf-network-state { 579 prefix "nw-s"; 580 } 582 import ietf-network-topology-state { 583 prefix "nt-s"; 584 } 586 import ietf-te-types { 587 prefix "te-types"; 588 } 590 import ietf-te-topology{ 591 prefix "tet"; 592 } 594 organization "IETF Deterministic Networking(detnet)Working Group"; 596 contact 597 "WG Web: 598 WG List: 600 WG Chair: Lou Berger 601 603 Editor: Xuesong Geng 604 606 Editor: Mach Chen 607 "; 609 description 610 "This YAGN module augments the 'ietf-te-topology' 611 module with detnet capability data for detnet 612 configuration"; 614 grouping detnet-link-info-attributes{ 615 description 616 "DetNet capability attributes in a DetNet topology"; 618 container detnet-performance-metric-attributes{ 619 description 620 "Link performance information in real time."; 621 uses detnet-performance-metric-attributes; 622 } 623 container detnet-queuing-management-algorithm{ 624 description 625 "Detnet queuing management algorithm used in 626 output queue"; 627 uses detnet-queuing-management-algorithm; 628 } 629 } 631 grouping detnet-performance-metric-attributes{ 632 description 633 "Link performance information in real time."; 634 container maximum-detnet-reservable-bandwidth{ 635 uses te-types:te-bandwidth; 636 description 637 "This container specifies the maximum bandwidth 638 that is reserved for DetNet on this link."; 639 } 640 container reserved-detnet-bandwidth{ 641 uses te-types:te-bandwidth; 642 description 643 "This container specifies the bandwidth that has 644 been reserved for DetNet on this link."; 645 } 646 container available-detnet-bandwidth{ 647 uses te-types:te-bandwidth; 648 description 649 "This container specifies the bandwidth that can 650 be used for new DetNet flows on this link."; 651 } 652 leaf minimum-detnet-device-delay{ 653 type unit 32; 654 description 655 "Minimum delay in the device for DetNet flows"; 656 } 657 leaf maximum-detnet-device-delay{ 658 type unit 32; 659 description 660 "Maximum delay in the device for DetNet flows"; 661 } 662 } 664 grouping detnet-queuing-management-algorithm{ 665 description 666 "Detnet queuing management algorithm used in 667 output queue"; 668 leaf queuing-management-algorithm{ 669 type enumeration{ 670 enum credit-based-shaping{ 671 reference 672 "IEEE P802.1 Qav"; 673 } 674 enum time-aware-shaping{ 675 reference 676 "IEEE P802.1 Qbv"; 677 } 678 enum cyclic-queuing-and-forwarding{ 679 reference 680 "IEEE P802.1 Qch"; 681 } 682 enum asynchronous-traffic-shaping{ 683 reference 684 "IEEE P802.1 Qcr"; 685 } 686 } 687 } 688 } 690 grouping detnet-node-info-attributes{ 691 description 692 "DetNet capability attributes in a DetNet node"; 693 container detnet-node-type{ 694 description 695 "Three types of DetNet nodes"; 696 reference 697 "draft-ietf-detnet-architecture-03: 698 Deterministic Networking Architecture"; 699 uses detnet-node-type; 700 } 701 container detnet-resource-reservation-attributes{ 702 uses detnet-resource-reservation-attributes; 703 } 704 leaf detnet-elimination-capability{ 705 type boolean; 706 description 707 "This node is able to do DetNet packet 708 elimination"; 709 } 710 leaf detnet-replication-capability{ 711 type boolean; 712 description 713 "This node is able to do DetNet packet 714 replication"; 715 } 716 } 718 grouping detnet-node-type{ 719 description 720 "This grouping defines three types of DetNet nodes"; 721 reference 722 "draft-ietf-detnet-architecture-03:Deterministic 723 Networking Architecture"; 724 leaf detnet-node-type{ 725 type enumeration{ 726 enum edge-node{ 727 description 728 "An instance of a DetNet relay node that 729 includes either a DetNet service layer proxy 730 function for DetNet service protection (e.g. 731 the addition or removal of packet sequencing 732 information) for one or more end systems, or 733 starts or terminate congestion protection at 734 the DetNet transport layer,analogous to a 735 Label Edge Router (LER)."; 736 } 737 enum relay-node{ 738 description 739 "A DetNet node including a service layer 740 function that interconnects different DetNet 741 transport layer paths to provide service 742 protection.A DetNet relay node can be a bridge, 743 a router, a firewall, or any other system that 744 participates in the DetNet service layer. It 745 typically incorporates DetNet transport layer 746 functions as well, in which case it is 747 collocated with a transit node."; 748 } 749 enum transit-node{ 750 description 751 "A node operating at the DetNet transport layer, 752 that utilizes link layer and/or network layer 753 switching across multiple links and/or 754 sub-networks to provide paths for DetNet 755 service layer functions.Optionally provides 756 congestion protection over those paths.An MPLS 757 LSR is an example of a DetNet transit node."; 758 } 759 } 760 } 762 } 764 grouping detnet-resource-reservation-attributes{ 765 description 766 "This grouping describs reservation operation for 767 the entire device"; 768 leaf MaxFanInPorts{ 769 type Unit32 770 description 771 "maximum number of fan-in ports in the device"; 772 } 773 leaf MaxPacketSize{ 774 type Unit32 775 description 776 "maximum Packet size the device allows"; 777 } 778 leaf MaxDetNetClasses{ 779 type Unit32 780 description 781 "maximum number of traffic classes that can be 782 reserved for DetNet"; 783 } 785 augment "/nw-s:networks/nw-s:network/nt-s:link/tet:te/"{ 786 container advertise-info{ 787 description 788 "Advertised DetNet link information attributes."; 789 uses detnet-link-info-attributes; 790 } 791 } 793 augment "/nw-s:networks/nw-s:network/nw-s:node/tet:te/"{ 794 description 795 "Advertised DetNet node information attributes."; 796 container{ 797 uses detnet-node-info-attributes; 798 } 799 } 800 802 5.2. DetNet Static Configuration YANG Model 804 file "ietf-detnet-static @2017-10-26.yang" 805 module ietf-detnet-static { 806 yang-version 1.0; 807 namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-static"; 809 prefix "detnet-static"; 810 import ietf-routing { 811 prefix "rt"; 812 } 813 import ietf-yang-types{ 814 prefix "yang"; 815 } 817 organization "IETF Deterministic Networking(detnet)Working Group"; 819 contact 820 "WG Web: 821 WG List: 823 WG Chair: Lou Berger 824 826 Editor: Xuesong Geng 827 829 Editor: Mach Chen 830 "; 832 description 833 "This YAGN module augments the 'ietf-routing'module 834 with detnet flow configuration attribute"; 836 grouping flow-identfication { 837 description 838 "DetNet flow identification"; 839 reference 840 "draft-farkas-detnet-flow-information-model" 841 leaf source-ip-address { 842 type yang:ip-address; 843 description 844 "Source IP address"; 845 } 846 leaf destination-ip-address { 847 type yang:ip-address; 848 description 849 "Destination IP address"; 850 } 851 leaf source-mac-address { 852 type yang:mac-address; 853 description 854 "Source MAC address"; 855 } 856 leaf destination-mac-address { 857 type yang:mac-address; 858 description 859 "Destination MAC address"; 860 } 861 leaf ipv6-flow-label { 862 ; 863 } 864 leaf mpls-label { 865 ; 866 } 867 } 869 grouping traffic-specification{ 870 descprition 871 "traffic-specification specifies how the Source 872 transmits packets for the flow. This is the 873 promise/request of the Source to the network. 874 The network uses this traffic specification 875 to allocate resources and adjust queue 876 parameters in network nodes."; 877 reference 878 "draft-farkas-detnet-flow-information-model" 879 leaf max-packets-per-interval{ 880 type uint16; 881 description 882 "max-packets-per-interval specifies the maximum 883 number of packets that the application shall 884 transmit in one Interval."; 885 } 886 leaf max-packet-size{ 887 type unit16; 888 description 889 "max-packet-size specifies maximum packet size 890 that the Source will transmit"; 891 } 892 leaf queuing-algorithm-selection{ 893 type uint8; 894 descprition 895 ""; 896 } 897 } 899 grouping routing-configuration{ 900 descprition 901 "configuration parameters direct data plane 902 operations"; 903 container flow-identification{ 904 uses flow-identfication; 906 } 907 leaf operation{ 908 type enumeration{ 909 enum transmission{ 910 description 911 "Operation: transmit "; 912 } 913 enum replication{ 914 description 915 "Operation: packet replication"; 916 } 917 enum elimination{ 918 description 919 "Operation: packet elimination"; 920 } 921 enum elimination-and-replication{ 922 description 923 "Operation: packet elimination and 924 replication"; 925 } 926 } 927 } 928 } 930 grouping queuing-parameters{ 932 } 934 grouping replication-function{ 936 } 938 grouping elimination-function{ 940 } 942 augment "/rt:routing{ 943 description 944 "DetNet node static configuration 945 attributes."; 946 container{ 947 uses flow-identfication; 948 uses traffic-specificatio; 949 uses routing-configuration; 950 uses queuing-parameters; 951 uses replication-function; 952 uses elimination-function; 953 } 955 } 956 958 6. IANA Considerations 960 This document makes no request of IANA. 962 Note to RFC Editor: this section may be removed on publication as an 963 RFC. 965 7. Security Considerations 967 8. Acknowledgements 969 9. References 971 9.1. Normative References 973 [I-D.dt-detnet-dp-sol] 974 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 975 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 976 "DetNet Data Plane Encapsulation", draft-dt-detnet-dp- 977 sol-02 (work in progress), September 2017. 979 [I-D.farkas-detnet-flow-information-model] 980 Farkas, J., Varga, B., rodney.cummings@ni.com, r., Jiang, 981 Y., and Y. Zha, "DetNet Flow Information Model", draft- 982 farkas-detnet-flow-information-model-02 (work in 983 progress), October 2017. 985 [I-D.ietf-detnet-architecture] 986 Finn, N., Thubert, P., Varga, B., and J. Farkas, 987 "Deterministic Networking Architecture", draft-ietf- 988 detnet-architecture-03 (work in progress), August 2017. 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, 992 DOI 10.17487/RFC2119, March 1997, 993 . 995 9.2. Informative References 997 [I-D.geng-detnet-info-distribution] 998 Geng, X. and M. Chen, "IGP-TE Extensions for DetNet 999 Information Distribution", draft-geng-detnet-info- 1000 distribution-01 (work in progress), September 2017. 1002 [I-D.ietf-teas-yang-te] 1003 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 1004 I. Bryskin, "A YANG Data Model for Traffic Engineering 1005 Tunnels and Interfaces", draft-ietf-teas-yang-te-09 (work 1006 in progress), October 2017. 1008 [I-D.ietf-teas-yang-te-topo] 1009 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1010 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1011 Topologies", draft-ietf-teas-yang-te-topo-13 (work in 1012 progress), October 2017. 1014 [I-D.varga-detnet-service-model] 1015 Varga, B. and J. Farkas, "DetNet Service Model", draft- 1016 varga-detnet-service-model-02 (work in progress), May 1017 2017. 1019 [IEEE802.1CB] 1020 "IEEE, "Frame Replication and Elimination for Reliability 1021 (IEEE Draft P802.1CB)", 2017, 1022 .", 1023 2016. 1025 [IEEE802.1Q-2014] 1026 "IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks", 1027 2014, .", 1028 2014. 1030 [IEEE802.1Qbu] 1031 "IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks - 1032 Amendment 26: Frame Preemption", 2016, 1033 .", 2016. 1035 [IEEE802.1Qbv] 1036 "IEEE, "IEEE Std 802.1Qbu Bridges and Bridged Networks - 1037 Amendment 25: Enhancements for Scheduled Traffic", 2015, 1038 .", 2016. 1040 [IEEE802.1Qcc] 1041 "IEEE, "Stream Reservation Protocol (SRP) Enhancements and 1042 Performance Improvements (IEEE Draft P802.1Qcc)", 2017, 1043 .". 1045 [IEEE802.1Qch] 1046 "IEEE, "Cyclic Queuing and Forwarding (IEEE Draft 1047 P802.1Qch)", 2017, 1048 .", 1049 2016. 1051 [IEEE802.1Qci] 1052 "IEEE, "Per-Stream Filtering and Policing (IEEE Draft 1053 P802.1Qci)", 2016, 1054 .", 1055 2016. 1057 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1058 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1059 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1060 . 1062 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1063 Yasukawa, Ed., "Extensions to Resource Reservation 1064 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1065 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1066 DOI 10.17487/RFC4875, May 2007, 1067 . 1069 Authors' Addresses 1071 Xuesong Geng 1072 Huawei 1074 Email: gengxuesong@huawei.com 1076 Mach(Guoyi) Chen 1077 Huawei 1079 Email: mach.chen@huawei.com