idnits 2.17.00 (12 Aug 2021) /tmp/idnits45989/draft-sambo-netmod-yang-fsm-02.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 58 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 627 has weird spacing: '...lter-id uin...' == Line 633 has weird spacing: '...atement str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2018) is 1541 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) ** Downref: Normative reference to an Informational RFC: RFC 7491 == Outdated reference: A later version (-04) exists of draft-fioccola-ippm-multipoint-alt-mark-02 == Outdated reference: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: draft-ietf-ippm-alt-mark has been published as RFC 8321 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group N. Sambo 3 Internet-Draft P. Castoldi 4 Intended status: Standards Track Scuola Superiore Sant'Anna 5 Expires: September 3, 2018 G. Fioccola 6 Telecom Italia 7 F. Cugini 8 CNIT 9 H. Song 10 T. Zhou 11 Huawei 12 March 2, 2018 14 YANG model for finite state machine 15 draft-sambo-netmod-yang-fsm-02 17 Abstract 19 Network operators and service providers are facing the challenge of 20 deploying systems from different vendors while looking for a trade- 21 off among transmission performance, network device reuse, and capital 22 expenditure without the need of being tied to single vendor 23 equipment. The deployment and operation of more dynamic and 24 programmable network infrastructures can be driven by adopting model- 25 driven and software-defined control and management paradigms. In 26 this context, YANG enables to compile a set of consistent vendor- 27 neutral data models for networks and components based on actual 28 operational needs emerging from heterogeneous use cases. This 29 document proposes YANG models to describe events, operations, and 30 finite state machine of YANG-defined network elements. The proposed 31 models can be applied in several use cases: i) in the context of 32 optical networks to pre-instruct data plane devices (e.g., an optical 33 transponder) on the actions to be performed (e.g., code adaptation) 34 in case some events, such as physical layer degradations, occur; ii) 35 in general data networks, network telemetry applications can define 36 and embed custom data probes into data plane devices. A probe in 37 many cases can be modeled as an FSM; iii) the monitoring of packet 38 loss and delay through a network clustering approach. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 3, 2018. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Conventions used in this document . . . . . . . . . . . . . . 3 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Example of application . . . . . . . . . . . . . . . . . . . 4 78 4.1. Pre-programming resiliency schemes in EONs . . . . . . . 4 79 4.2. Deploying Dynamic Probes for Programmable Network 80 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.3. IP Performance Measurements on multipoint-to-multipoint 82 large Networks . . . . . . . . . . . . . . . . . . . . . 9 83 5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 10 84 6. Implementation of the pre-programming resiliency schemes in 85 EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 14 88 7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 15 89 7.3. Example of values for the YANG model . . . . . . . . . . 27 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 91 9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 28 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 96 12.2. Informative References . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 99 1. Introduction 101 Networks are evolving toward more programmability, flexibility, and 102 multi-vendor interoperability. Multi-vendor interoperability can be 103 applied in the context of nodes, i.e. a node composed of components 104 provided by different vendors (named fully disaggregated white box) 105 is assembled under the same control system. This way, operators can 106 optimize costs and network performance without the need of being tied 107 to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based 108 on YANG data modeling language RFC6020 [RFC6020] is emerging as a 109 candidate Software Defined Networking (SDN) enabled protocol. First, 110 NETCONF supports both control and management functionalities, thus 111 permits high programmability. Then, YANG enables data modeling in a 112 vendor-neutral way. Some recent works have provided YANG models to 113 describe attributes of links (e.g., identification), nodes (e.g., 114 connectivity matrix), media channels, and transponders (e.g., 115 supported forward error correction - FEC) of networks 116 ([I-D.ietf-i2rs-yang-network-topo] [I-D.vergara-ccamp-flexigrid-yang] 117 [I-D.zhang-ccamp-l1-topo-yang]), also including optical technologies. 118 This document presents YANG models to describe events, operations, 119 and finite state machine of YANG-defined network elements. Such 120 models can be applied to several use cases. In the context of 121 elastic optical networks (EONs), the model enables a centralized 122 remote network controller (managed by a network operator) to instruct 123 a transponder controller about the actions to perform when certain 124 events (e.g., failures) occur. The actions to be taken and the 125 events can be re-programmed on the device. In general data networks, 126 programmable network telemetry is considered a killer SDN application 127 which can help applications gain unprecedented visibility to network 128 data plane. Instead of providing raw data, network devices can be 129 configured to filter and process data directly on the data plane and 130 only hand preprocessed data to the collector, in order to save data 131 bandwidth and reduce reaction delay ([I-D.song-opsawg-dnp4iq]) . Such 132 configurations can be programed as custom probes and dynamically 133 deployed into data plane devices. A probe in many cases can be 134 modeled as an FSM. Another use case is the monitoring of packet loss 135 and delay through a network clustering approach: in this case, each 136 FSM state is determined by a specific subdivision of the network in 137 Clusters ([I-D.fioccola-ippm-multipoint-alt-mark]). 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC2119 [RFC2119]. 145 3. Terminology 147 ABNO: Application-Based Network Operations 149 BER: Bit Error Rate 151 EON: Elastic Optical Network 153 FEC: Forward Error Correction 155 FSM: Finite State Machine 157 NETCONF: Network Configuration Protocol 159 OAM: Operation Administration and Maintenance 161 SDN: Software Defined Network 163 YANG: Yet Another Network Generator 165 DNP: Dynamic Network Probe 167 AMM: Alternate Marking Method 169 4. Example of application 171 4.1. Pre-programming resiliency schemes in EONs 173 EONs (optical networks based on flexible grid supporting circuits of 174 different bandwidth) are expected to employ flexible transponders, 175 i.e. transponders supporting multiple bit rates, multiple modulation 176 formats, and multiple codes. Such transponders permits the (re-) 177 configuration of the bit rate value based on traffic requirements, as 178 well as the configuration of the modulation format and code based on 179 the physical characteristics of a path (e.g., quadrature phase shift 180 keying is more robust than 16 quadrature amplitude modulation). This 181 way, transmission parameters can be (re-) configured based on 182 physical layer changes. The YANG model presented in this draft 183 enables to pre-program reconfiguration settings of data plane devices 184 in case of failures or physical layer degradations. In particular, 185 soft failures are assumed. Soft failures imply transmission 186 performance degradation, in turns a bit error rate (BER) increase, 187 e.g. due to the ageing of some network devices. Without loosing 188 generality, the ABNO architecture is assumed for the control and 189 management of EONs (RFC7491 [RFC7491]). Considering the state of the 190 art, when pre-FEC BER passes above a predefined threshold, it is 191 expected that an alarm is sent to the OAM Handler, which communicates 192 with the ABNO controller that may trigger an SDN controller (that 193 could be the Provisioning Manager of ABNO RFC7491 [RFC7491]) for 194 computing new transmission parameters. The involved ABNO modules are 195 shown in the simplified ABNO architecture of Fig. 1. Then, 196 transponders are reconfigured. When alarms related to several 197 connections impacted by the soft failure are generated, this 198 procedure may be particularly time consuming. The related workflow 199 for transponder reconfiguration is shown in Fig. 2. The proposed 200 model enables an SDN controller to instruct the transponder about 201 reconfiguration of new transmission parameters values if a soft 202 failure occurs. This can be done before the failure occurs (e.g., 203 during the connection instantiation phase or during the connection 204 service), so that data plane devices can promptly reconfigure 205 themselves without querying the SDN controller to trigger an on- 206 demand recovery. This is expected to speed up the recovery process 207 from soft failures. The related flow chart is shown in Fig. 3. 209 ___________ ___________ 210 | ABNO | | OAM | 211 |controller | ------ | Handler | 212 |___________| |___________| 214 | | 215 | | 216 | | 217 ____________ | 218 | SDN | | 219 | controller | | 220 |____________| | 221 | 222 | | 223 | | 224 | | 225 _____________________________ 226 | Client | 227 | network | 228 |_____________________________| 230 Figure 1: Assumed ABNO functional modules 232 _____________________ 233 | 1 | 234 |Sending alarm to the | 235 | OAM Handler | 236 | | 237 |_____________________| 238 | 239 | 240 | 241 _____________________ 242 | 2 | 243 | Trigger | 244 | SDN Controller | 245 | | 246 |_____________________| 247 | 248 | 249 | 250 _____________________ 251 | 3 | 252 | Computation of | 253 | new transmission | 254 | parameters | 255 |_____________________| 256 | 257 | 258 | 259 _____________________ 260 | 4 | 261 | Data plane | 262 | reconfiguration | 263 | | 264 |_____________________| 266 Figure 2: Flow chart of the expected state-of-the-art approach 267 _______________________ 268 | 1 | 269 | Instructing the local | 270 | controller of | 271 | data plane devices | 272 |_______________________| 273 | 274 | 275 | 276 _______________________ 277 | 2 | 278 | Local reconfiguration | 279 | upon failure | 280 | detection | 281 |_______________________| 282 | 283 | 284 | 285 _______________________ 286 | 3 | 287 | | 288 | notification | 289 | | 290 |_______________________| 292 Figure 3: Flow chart of the approach exploiting YANG models in this 293 draft 295 4.2. Deploying Dynamic Probes for Programmable Network Telemetry 297 In the past, network data analytics was considered a separate 298 function from networks. They consume raw data extracted from 299 networks through piecemeal protocols and interfaces. With the advent 300 of user programmable data plane, we expect a paradigm shift that 301 makes the data plane be an active component of the data telemetry and 302 analytics solution. The programmable in-network data preprocessing 303 is efficient and flexible to offload some light-weight data 304 processing through dynamic data plane programming or configuration. 305 A universal network data analytics platform built on top of this 306 enables a tight and agile network control and OAM feedback loop. A 307 proposed dynamic network telemetry system architecture is illustrated 308 in Fig.4. 310 An application translates its data requirements into a set of Dynamic 311 Network Probes (DNP) targeting a subset of data plane devices. After 312 the probes are deployed, each probe conducts its corresponding in- 313 network data preprocessing and feeds the preprocessed data to the 314 collector. The collector finishes the data post-processing and 315 presents the results to the data-requesting application. 317 +-------------------------------------+ 318 | network telemetry applications | 319 +-------------------------------------+ 320 ^ | 321 | V 322 | +--------------------+ 323 | | DNP compile/config | 324 | +--------------------+ 325 | | 326 | V 327 +---------------+ +--------------------+ 328 |data collection| | Probe deployment | 329 +---------------+ +--------------------+ 330 ^ ^ ^ | | | 331 | | | V V V 332 +--------------------------------------+ 333 | network data plane devices | 334 | (in-network data preprocessing) | 335 +--------------------------------------+ 337 Figure 4: Deploy dynamic network probes using YANG FSM models 339 Many DNPs can be modeled as FSM which are configured to capture 340 specific events. Here FSMs essentially preprocess the raw stream 341 data and only report the necessary data to subscribing applications. 343 For example, a congestion control application needs to monitor the 344 router buffer occupancy. Instead of polling the buffer depth 345 periodically, it is only interested in the real-time events when the 346 buffer depth crosses a low and a high threshold. We can install a 347 probe to achieve this data plane function and the probe can be 348 modeled as a three-state FSM. Each state represents a buffer region: 349 below the low threshold, above the high threshold, and in between the 350 two thresholds. A possible state transition is checked against the 351 buffer depth for each incoming and outgoing packet. Whenever a state 352 transition happens, an event is generated and reported to the 353 application. This approach significantly reduces the amount of data 354 sent to the application and also allows a timely event notification. 356 For another example, an application would like to monitor the delay 357 experienced by a flow. The packet delay on its forwarding path can 358 be acquired by using iOAM [I-D.brockners-inband-oam-requirements]. 359 However, the application only needs to know that N consecutive flow 360 packets experience a delay longer than T. Instead of forwarding the 361 raw delay data to the application, a probe can be deployed to detect 362 the event. Similarly, the probe can be modeled as an FSM. 364 4.3. IP Performance Measurements on multipoint-to-multipoint large 365 Networks 367 Networks offer rich sets of network performance measurement data, but 368 traditional approaches run into limitations. One reason for this is 369 the fact that in many cases, the bottleneck is the generation and 370 export of the data and the amount of data that can be reasonably 371 collected from the network runs into bandwidth and processing 372 constraints in the network itself. In addition, management tasks 373 related to determining and configuring which data to generate lead to 374 significant deployment challenges. 376 In order to address these issues, an SDN controller application 377 orchestrates network performance measurements tasks across the 378 network to allow an optimized monitoring. In fact the IP Performance 379 Measurement SDN Controller Application in Figure 5 can calibrate how 380 deep can be obtained monitoring data from the network by configuring 381 measurement points roughly or meticulously. This can be established 382 by using the feedback mechanism reported in Figure 5. 384 For instance, the SDN Controller can configure initially an end to 385 end monitoring between ingress points and egress points of the 386 network. If the network does not experiment issues, this approximate 387 monitoring is good enough and is very cheap in terms of network 388 resources. But, in case of problems, the SDN Controller becomes 389 aware of the issues from this approximate monitoring and, in order to 390 localize the portion of the network that has issues, configures the 391 measurement points more exhaustively. So a new detailed monitoring 392 is performed. After the detection and resolution of the problem the 393 initial approximate monitoring can be used again. This idea is 394 general and can be applied to different performance measurements 395 techniques both active and passive (and hybrid). 397 +--------------------------------------+ 398 | IP Performance Measurement | 399 | SDN Controller Application | 400 +--------------------------------------+ 401 ^ ^ ^ | | | 402 | | | v v v 403 +--------------------------------------+ 404 | Multipoint Network | 405 +--------------------------------------+ 407 Figure 5: Feedback mechanism on multipoint-to-multipoint large 408 Networks 410 One of the most efficient methodology to perform packet, loss delay 411 and jitter measurements both in an IP and Overlay Networks is the 412 Alternate Marking method, as presented in [I-D.ietf-ippm-alt-mark] 413 and [I-D.fioccola-ippm-multipoint-alt-mark]. 415 This technique can be applied to point-to-point flows but also to 416 multipoint.to-multipoint flows (see [I-D.ietf-ippm-alt-mark] and 417 [I-D.fioccola-ippm-multipoint-alt-mark]). The Alternate Marking 418 method creates batches of packets by alternating the value of 1 or 2 419 bits of the packet header. These batches of packets are 420 unambiguously recognized over the network and the comparison of 421 packet counters permits the packet loss calculation. The same idea 422 can be applied for delay measurement by selecting special packets 423 with a marking bit dedicated for delay measurements. This method 424 needs two counters each marking period for each flow under monitor. 425 For this reason by considering n measurement points and n monitored 426 flows, the order of magnitude of the packet counters for each time 427 interval is n*n*2 (1 per color). 429 Multipoint Alternate Marking, described in 430 [I-D.fioccola-ippm-multipoint-alt-mark], aims to reduce this value 431 and makes the performance monitoring more flexible in case a detailed 432 analysis is not needed. 434 It is possible to monitor a Multipoint Network without examining in 435 depth by using the Network Clustering (subnetworks that are portions 436 of the entire network that preserve the same property of the entire 437 network). So in case there is packet loss or the delay is too high 438 the filtering criteria could be specified more in order to perform a 439 per flow detailed analysis, as described in [I-D.ietf-ippm-alt-mark]. 441 An application of the multipoint performance monitoring can be done 442 by using FSM (each state is a composition of clusters) and feedback 443 mechanism where the SDN Controller is the brain of the network and 444 can manage flow control to the switches and routers and, in the same 445 way, can calibrate the performance measurements depending on the 446 necessity. 448 5. YANG for finite state machine (FSM) 450 This model defines a list of states and transitions to describe a 451 generic finite state machine (FSM). The related code and tree are 452 shown in the Appendix. 454 : it defines the current state of the FSM. 455 : this element defines the FSM as follows. 456 : this list defines all the FSM states. 457 : this leaf attribute of defines the 458 identifier of the state 459 : this leaf attribute of defines the 460 name of the state 461 : this leaf is a "string" describing the 462 state 463 : this attribute defines a list of 464 transitions to other states in the FSM. 465 : this attribute defines the name of a 466 transition 467 : this attribute defines the type of the 468 transition from a pool of possible transition 469 types predefined inside the YANG model. 470 Together with the attribute, it 471 uniquely identifies the transition. 472 : this optional attribute is a 473 "string" describing the transition 474 : this leaf is a list of input 475 parameters related to the transition. This 476 attribute enables to further express a 477 transition: as an example, if a transition can 478 be triggered by a parameter (e.g., a monitored 479 performance parameter) exceeding a threshold 480 (as in Sec. 5), an element of the list defines 481 this threshold. Thus, if the parameter is 482 outside the threshold, the transition is 483 taken, otherwise not. 484 : this leaf of defines 485 a filter parameter. 486 : this leaf of 487 define the identifier number associated 488 with the attribute. 489 : this attribute defines a list of 490 actions to take during the transition. 491 : this attribute is the list of 492 actions 493 : this leaf of 494 defines the identifier number of 495 an action. 496 : this leaf of 497 defines the type of an action. 498 : this leaf defines 499 (differently from 500 detailed below) an action that 501 has to be directly executed. 502 : this attribute 503 recalls an RPC encapsulating 504 the effective task (action) 505 to be executed by the 506 hardware. If more actions 507 (e.g., "A" and "B"), defined 508 in the list, have 509 to be executed, these 510 actions can be executed 511 sequentially according to 512 the attribute 513 detailed below. Thus, by 514 referring to the tree of the 515 Appendix, when an action 516 ("A") is executed, the 517 attribute will 518 bring to another action 519 ("B"). If more actions have 520 to be executed in parallel 521 (e.g., "A" & "B"), not 522 sequentially, an element of 523 the list should be 524 defined to express an action 525 (e.g., "A&B") consisting of 526 more actions to be executed 527 in parallel. 528 : this 529 attribute defines the 530 identification number of a 531 next action that has to be 532 taken. The 533 can assume a NULL value. 534 : this leaf enables a 535 check ("true" or "false") to be 536 verified before executing the 537 action. Based on the check, the 538 proper attributes and 539 are considered. 540 : this leaf 541 of defines 542 the condition to be 543 verified before executing 544 the action. 545 : this leaf of 546 defines a 547 result of the check 548 associated to 549 . Proper 550 and 551 552 attributes are associated 553 with this result of the 554 check. 555 : this leaf of 556 defines a 557 result of the check 558 associated to 559 . Proper 560 and 561 562 attributes are associated 563 with this result of the 564 check. 565 : this attribute defines 566 the next state of FSM when an action is 567 executed. 569 6. Implementation of the pre-programming resiliency schemes in EONs 571 These presented model can be used to enable a centralized network 572 controller, managed by a network operator, to instruct data plane 573 hardware on its reconfiguration if some events, such as a failure or 574 physical layer degradation, occur. As an example, an optical signal 575 impacted by a soft failure (i.e., a physical layer degradation 576 inducing a pre forward error correction bit error rate increase - 577 pre-FEC) can be maintained by adapting the FEC of the signal itself. 578 This action to be taken and, more in general operations to be 579 executed depending on critical events, can be (re-) programmed on the 580 transponder by (re-) sending a NETCONF message to the 581 device controller including a FSM defined by the YANG model. Such a 582 system has the main goal to speed up the reaction of the network to 583 certain events/faults and to alleviate the workload of the 584 centralized controller. The speed up derives from the fact that the 585 centralized controller is able to pre-compute and pre-configure on 586 the network devices the actions to take when an event occurs taking 587 into account a global view and knowledge of the network. In this 588 way, the device is already aware of the actions to be locally applied 589 to reconfigure a connection, avoiding to inform the controller and to 590 wait for the response indicating what to do. Consequently, part of 591 the workload is also removed from the centralized controller. When 592 the reaction is successfully completed in the data plane, the 593 centralized controller can be notified about the faults and the taken 594 action. A flexible transponder supporting two FEC types, 7% and 20%, 595 is considered. A two-states FSM is also assumed. The states have 596 attribute set to "Steady" and "Fec-Baud-Adapt", respectively. 597 In the "Steady" state, the signal is in a healthy condition, adopting 598 a 7% FEC, with a pre-FEC BER below an assigned threshold of 9 x 10-4. 599 A transition from this state can be triggered by the event with 600 =BER_CHANGE and =9 x 10-4, thus expressing a 601 change of the pre-FEC BER above the threshold. In case the pre-FEC 602 BER exceeds 9 x 10-4 due to a soft failure, the state machine evolves 603 to the "Fec-Baud-Adapt" state and an adaptation to a more robust FEC 604 of 20% (executed by the attribute ) is performed. The 605 system can return to the "Steady" state if the pre-FEC BER goes below 606 another pre-defined threshold and the FEC is reconfigured to 7%. 608 7. Appendix 610 This appendix reports the YANG models code and the related tree. 612 7.1. YANG model for FSM - Tree 614 module: ietf-fsm 615 +--rw current-state? leafref 616 +--rw states 617 +--rw state [id] 618 +--rw id state-id-type 619 +--rw description? string 620 +--rw transitions 621 +--rw transition [name type] 622 +--rw name string 623 +--rw type transition-type 624 +--rw description? string 625 +--rw filters 626 | +--rw filter [filter-id] 627 | +--rw filter-id uint32 628 +--rw actions 629 +--rw action [id] 630 +--rw id transition-id-type 631 +--rw type enumeration 632 +--rw conditional 633 | +--rw statement string 634 | +--rw true 635 | | +--rw execute 636 | | +--rw next-action? transition-id-type 637 | | +--rw next-state? leafref 638 | +--rw false 639 | +--rw execute 640 | +--rw next-action? transition-id-type 641 | +--rw next-state? leafref 642 +--rw simple 643 +--rw execute 644 +--rw next-action? transition-id-type 645 +--rw next-state? leafref 647 7.2. YANG model for FSM - Code 649 file "ietf-fsm@2016-03-15.yang" 651 module ietf-fsm { 653 namespace "http://sssup.it/fsm"; 655 prefix fsm; 657 identity TRANSITION { 659 description "Base for all types of event"; 661 } 663 identity ON_CHANGE { 665 base TRANSITION; 667 description 669 "The event when the database changes."; 671 } 673 // typedef statements 675 typedef transition-type { 677 description "it defines the type of transition (event)"; 679 type identityref { 681 base TRANSITION; 683 } 685 } 687 typedef transition-id-type { 688 description "it defines the id of the transition (event)"; 690 type uint32; 692 } 694 // grouping statements 696 grouping action-block { 698 description "it defines the action to perform when a transition occurs"; 700 leaf id { 702 description "it refers to the id of the transition"; 703 type transition-id-type; 705 } 707 leaf type { 709 description "it defines if the action has to be simply executed or if a conditional statement has to be checked before execution"; 711 type enumeration { 713 enum "CONDITIONAL_OP" { 714 description "it defines the type CONDITIONAL OPERATION to check a statement before execution"; 715 } 717 enum "SIMPLE_OP" { 718 description "it defines the type SIMPLE OPERATION: i.e., an operation to be directly executed; 719 } 721 } 723 mandatory true; 725 } 727 grouping execution-top { 729 description "it defines the execution attribute"; 731 anyxml execute { 733 description "Represent the action to perform"; 735 } 737 leaf next-action { 739 type transition-id-type; 741 description "the id of the next action to execute"; 743 } 745 } 747 container conditional { 749 description "it defines the container CONDITIONAL"; 751 when "../type = 'CONDITIONAL_OP'"; 753 leaf statement { 755 type string; 757 mandatory true; 759 description 761 "The statement to be evaluated before execution. 763 E.g. if a=b"; 765 } 767 container true { 769 description "it is referred to the result TRUE of a conditional statement "; 771 uses execution-top; 773 } 775 container false { 777 description "it is referred to the result FALSE of a conditional statement "; 779 uses execution-top; 781 } 783 } 785 container simple { 786 description "Simple execution of an action without checking any condition"; 788 when "../type = 'SIMPLE_OP'"; 790 uses execution-top; 792 } 794 } 796 grouping action-top { 798 description "it defines the grouping of action"; 800 list action { 802 description "it defines the list of actions"; 804 key "id"; 806 ordered-by user; 808 uses action-block; 810 } 812 } 814 grouping on-change { 816 description 818 "Event occuring when a modification of one or more 820 objects occurs"; 822 container filters { 824 description 826 "This container contains a list of configurable filters 828 that can be applied to subscriptions. This facilitates 830 the reuse of complex filters once defined."; 832 list filter { 834 key "filter-id"; 836 description 838 "A list of configurable filters that can be applied to 840 subscriptions."; 842 leaf filter-id { 844 type uint32; 846 description 848 "An identifier to differentiate between filters."; 850 } 852 } 854 } 856 } 858 grouping transition-top { 860 description "it defines the grouping transition"; 862 leaf name { 864 description "it defines the transition name"; 866 type string; 868 mandatory true; 870 } 872 leaf type { 874 description "it defines the transition type"; 876 type transition-type; 878 mandatory true; 880 } 882 leaf description { 884 description "it describes the transition "; 886 type string; 888 } 890 // list of all possible events 891 uses on-change { 893 when "type = 'ON_CHANGE'"; 895 } 897 container actions { 899 description "it defines the container action"; 901 uses action-top; 903 } 905 } 907 grouping transitions-top { 909 description "it defines the grouping transition"; 911 container transitions { 913 description "it defines the container transitions"; 915 list transition { 917 description "it defines the list of transitions"; 919 key "name type"; 921 uses transition-top; 923 } 925 } 927 } 929 // data definition statements 930 uses transitions-top; 932 // extension statements 934 // feature statements 936 // augment statements 938 organization 940 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 942 contact 944 " Editor: Matteo Dallaglio 946 948 "; 950 description 952 "This module contains a YANG definitions of a generic finite state 953 machine."; 955 revision 2016-03-15 { 957 description "Initial Revision."; 959 reference 961 "RFC xxxx:"; 963 } 965 // identity statements 967 // typedef statements 969 typedef state-id-type { 971 description "it defines the id type of the states"; 973 type uint32; 975 } 977 // grouping statements 979 grouping state-top { 981 description "it defines the grouping state"; 983 leaf id { 985 description "it defines the id of a transition"; 987 type state-id-type; 989 } 991 leaf description { 993 description "it describes a transition"; 995 type string; 997 } 999 grouping next-state-top { 1001 description "it defines the grouping for the next state"; 1003 leaf next-state { 1005 description "it defines the next state"; 1007 type leafref { 1009 description "it refers to its id"; 1011 path "../../../../../../../../../states/state/id"; 1013 } 1015 description "Id of the next state"; 1017 } 1019 } 1021 uses transitions-top { 1023 augment "transitions/transition/actions/action/conditional/true" { 1025 uses next-state-top; 1027 } 1029 augment "transitions/transition/actions/action/conditional/false" { 1030 uses next-state-top; 1032 } 1034 augment "transitions/transition/actions/action/simple" { 1036 //uses next-state-top; 1038 leaf next-state { 1040 description "it defines the next state"; 1042 type leafref { 1044 description "it refers to its id"; 1045 path "../../../../../../../../states/state/id"; 1047 } 1049 description "Id of the next state"; 1051 } 1053 } 1055 } 1057 } 1059 grouping states-top { 1061 description "it defines the grouping states"; 1063 leaf current-state { 1065 description "it defines the current state"; 1067 type leafref { 1069 description "it refers to its id"; 1070 path "../states/state/id"; 1072 } 1074 } 1076 container states { 1077 description "it defines the container states"; 1079 list state { 1081 description "it defines the list of states"; 1083 key "id"; 1085 uses state-top; 1087 } 1089 } 1091 } 1093 // data definition statements 1095 uses states-top; 1097 // extension statements 1099 // feature statements 1100 // augment statements. 1102 // rpc statements 1104 }//module fsm 1106 1108 7.3. Example of values for the YANG model 1109 FIELD NAME | YANG DATA TYPE | VALUE 1110 _________________|_____________________|________________________ 1111 Current State | leafref | "an existing state id 1112 | | in the FSM" 1113 | | 1114 State | | 1115 id | uint32 | 1 1116 name | string | Steady 1117 description | string | "whatever string" 1118 | | 1119 transition | | 1120 name | string | "whatever string" 1121 type | enum | BER_CHANGE 1122 description | string | "whatever string" 1123 | | 1124 filter | | 1125 filter-id | uint32 | 2 1126 filter-type | anyxml or xpath | BER>0.0009 1127 | | 1128 action | | 1129 id | uint32 | 3 1130 type | enum | SIMPLE 1131 statement | string | "whatever string" 1132 execute | anyxml | "this recalls an RPC 1133 | | where the FEC value 1134 | | is expressed" 1135 next-operation | uint32 | NULL 1136 next-state | leafref | "an existing state id 1137 | | in the FSM" 1139 8. Acknowledgements 1141 This work has been partially supported by the European Commission 1142 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 1143 dynamic networks using a Holistic cross-layEr, Self-configurable 1144 Truly flexible approach, grant agreement no: H2020-645360) project. 1145 The views expressed here are those of the authors only. The European 1146 Commission is not liable for any use that may be made of the 1147 information in this document. 1149 9. Other Contributors 1151 Matteo Dallaglio (Scuola Superiore Sant'Anna), Andrea Di Giglio 1152 (Telecom Italia), Giacomo Bernini (Nextworks). 1154 10. Security Considerations 1156 TBD 1158 11. IANA Considerations 1160 TBD 1162 12. References 1164 12.1. Normative References 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, 1168 DOI 10.17487/RFC2119, March 1997, 1169 . 1171 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1172 the Network Configuration Protocol (NETCONF)", RFC 6020, 1173 DOI 10.17487/RFC6020, October 2010, 1174 . 1176 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1177 and A. Bierman, Ed., "Network Configuration Protocol 1178 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1179 . 1181 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1182 Application-Based Network Operations", RFC 7491, 1183 DOI 10.17487/RFC7491, March 2015, 1184 . 1186 12.2. Informative References 1188 [I-D.brockners-inband-oam-requirements] 1189 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1190 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1191 T., <>, P., and r. remy@barefootnetworks.com, 1192 "Requirements for In-situ OAM", draft-brockners-inband- 1193 oam-requirements-03 (work in progress), March 2017. 1195 [I-D.fioccola-ippm-multipoint-alt-mark] 1196 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 1197 "Multipoint Alternate Marking method for passive and 1198 hybrid performance monitoring", draft-fioccola-ippm- 1199 multipoint-alt-mark-02 (work in progress), March 2018. 1201 [I-D.ietf-i2rs-yang-network-topo] 1202 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1203 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1204 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1205 progress), December 2017. 1207 [I-D.ietf-ippm-alt-mark] 1208 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 1209 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1210 "Alternate Marking method for passive and hybrid 1211 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 1212 in progress), December 2017. 1214 [I-D.song-opsawg-dnp4iq] 1215 Song, H. and J. Gong, "Requirements for Interactive Query 1216 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 1217 (work in progress), June 2017. 1219 [I-D.vergara-ccamp-flexigrid-yang] 1220 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1221 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1222 Flexi-Grid Optical Networks", draft-vergara-ccamp- 1223 flexigrid-yang-06 (work in progress), January 2018. 1225 [I-D.zhang-ccamp-l1-topo-yang] 1226 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 1227 Liu, "A YANG Data Model for Optical Transport Network 1228 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 1229 progress), April 2017. 1231 Authors' Addresses 1233 Nicola Sambo 1234 Scuola Superiore Sant'Anna 1235 Via Moruzzi 1 1236 Pisa 56124 1237 Italy 1239 Email: nicola.sambo@sssup.it 1241 Piero Castoldi 1242 Scuola Superiore Sant'Anna 1243 Via Moruzzi 1 1244 Pisa 56124 1245 Italy 1247 Email: piero.castoldi@sssup.it 1248 Giuseppe Fioccola 1249 Telecom Italia 1250 Via Reiss Romoli, 274 1251 Torino 10148 1252 Italy 1254 Email: giuseppe.fioccola@telecomitalia.it 1256 Filippo Cugini 1257 CNIT 1258 Via Moruzzi 1 1259 Pisa 56124 1260 Italy 1262 Email: filippo.cugini@cnit.it 1264 Haoyu Song 1265 Huawei 1266 2330 Central Expressway 1267 Santa Clara, CA 95050 1268 USA 1270 Email: haoyu.song@huawei.com 1272 Tianran Zhou 1273 Huawei 1274 156 Beiqing Road 1275 Beijing 100095 1276 China 1278 Email: zhoutianran@huawei.com