idnits 2.17.00 (12 Aug 2021) /tmp/idnits47020/draft-sambo-netmod-yang-fsm-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 626 has weird spacing: '...lter-id yp:...' == Line 632 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 (January 9, 2018) is 1593 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-01 == 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: July 13, 2018 G. Fioccola 6 Telecom Italia 7 F. Cugini 8 CNIT 9 H. Song 10 T. Zhou 11 Huawei 12 January 9, 2018 14 YANG model for finite state machine 15 draft-sambo-netmod-yang-fsm-01 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 July 13, 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 95 11.2. Informative References . . . . . . . . . . . . . . . . . 29 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 98 1. Introduction 100 Networks are evolving toward more programmability, flexibility, and 101 multi-vendor interoperability. Multi-vendor interoperability can be 102 applied in the context of nodes, i.e. a node composed of components 103 provided by different vendors (named fully disaggregated white box) 104 is assembled under the same control system. This way, operators can 105 optimize costs and network performance without the need of being tied 106 to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based 107 on YANG data modeling language RFC6020 [RFC6020] is emerging as a 108 candidate Software Defined Networking (SDN) enabled protocol. First, 109 NETCONF supports both control and management functionalities, thus 110 permits high programmability. Then, YANG enables data modeling in a 111 vendor-neutral way. Some recent works have provided YANG models to 112 describe attributes of links (e.g., identification), nodes (e.g., 113 connectivity matrix), media channels, and transponders (e.g., 114 supported forward error correction - FEC) of networks 115 ([I-D.ietf-i2rs-yang-network-topo] [I-D.vergara-ccamp-flexigrid-yang] 116 [I-D.zhang-ccamp-l1-topo-yang]), also including optical technologies. 117 This document presents YANG models to describe events, operations, 118 and finite state machine of YANG-defined network elements. Such 119 models can be applied to several use cases. In the context of 120 elastic optical networks (EONs), the model enables a centralized 121 remote network controller (managed by a network operator) to instruct 122 a transponder controller about the actions to perform when certain 123 events (e.g., failures) occur. The actions to be taken and the 124 events can be re-programmed on the device. In general data networks, 125 programmable network telemetry is considered a killer SDN application 126 which can help applications gain unprecedented visibility to network 127 data plane. Instead of providing raw data, network devices can be 128 configured to filter and process data directly on the data plane and 129 only hand preprocessed data to the collector, in order to save data 130 bandwidth and reduce reaction delay ([I-D.song-opsawg-dnp4iq]) . Such 131 configurations can be programed as custom probes and dynamically 132 deployed into data plane devices. A probe in many cases can be 133 modeled as an FSM. Another use case is the monitoring of packet loss 134 and delay through a network clustering approach: in this case, each 135 FSM state is determined by a specific subdivision of the network in 136 Clusters ([I-D.fioccola-ippm-multipoint-alt-mark]). 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC2119 [RFC2119]. 144 3. Terminology 146 ABNO: Application-Based Network Operations 148 BER: Bit Error Rate 150 EON: Elastic Optical Network 152 FEC: Forward Error Correction 154 FSM: Finite State Machine 156 NETCONF: Network Configuration Protocol 158 OAM: Operation Administration and Maintenance 160 SDN: Software Defined Network 162 YANG: Yet Another Network Generator 164 DNP: Dynamic Network Probe 166 AMM: Alternate Marking Method 168 4. Example of application 170 4.1. Pre-programming resiliency schemes in EONs 172 EONs (optical networks based on flexible grid supporting circuits of 173 different bandwidth) are expected to employ flexible transponders, 174 i.e. transponders supporting multiple bit rates, multiple modulation 175 formats, and multiple codes. Such transponders permits the (re-) 176 configuration of the bit rate value based on traffic requirements, as 177 well as the configuration of the modulation format and code based on 178 the physical characteristics of a path (e.g., quadrature phase shift 179 keying is more robust than 16 quadrature amplitude modulation). This 180 way, transmission parameters can be (re-) configured based on 181 physical layer changes. The YANG model presented in this draft 182 enables to pre-program reconfiguration settings of data plane devices 183 in case of failures or physical layer degradations. In particular, 184 soft failures are assumed. Soft failures imply transmission 185 performance degradation, in turns a bit error rate (BER) increase, 186 e.g. due to the ageing of some network devices. Without loosing 187 generality, the ABNO architecture is assumed for the control and 188 management of EONs (RFC7491 [RFC7491]). Considering the state of the 189 art, when pre-FEC BER passes above a predefined threshold, it is 190 expected that an alarm is sent to the OAM Handler, which communicates 191 with the ABNO controller that may trigger an SDN controller (that 192 could be the Provisioning Manager of ABNO RFC7491 [RFC7491]) for 193 computing new transmission parameters. The involved ABNO modules are 194 shown in the simplified ABNO architecture of Fig. 1. Then, 195 transponders are reconfigured. When alarms related to several 196 connections impacted by the soft failure are generated, this 197 procedure may be particularly time consuming. The related workflow 198 for transponder reconfiguration is shown in Fig. 2. The proposed 199 model enables an SDN controller to instruct the transponder about 200 reconfiguration of new transmission parameters values if a soft 201 failure occurs. This can be done before the failure occurs (e.g., 202 during the connection instantiation phase or during the connection 203 service), so that data plane devices can promptly reconfigure 204 themselves without querying the SDN controller to trigger an on- 205 demand recovery. This is expected to speed up the recovery process 206 from soft failures. The related flow chart is shown in Fig. 3. 208 ___________ ___________ 209 | ABNO | | OAM | 210 |controller | ------ | Handler | 211 |___________| |___________| 213 | | 214 | | 215 | | 216 ____________ | 217 | SDN | | 218 | controller | | 219 |____________| | 220 | 221 | | 222 | | 223 | | 224 _____________________________ 225 | Client | 226 | network | 227 |_____________________________| 229 Figure 1: Assumed ABNO functional modules 231 _____________________ 232 | 1 | 233 |Sending alarm to the | 234 | OAM Handler | 235 | | 236 |_____________________| 237 | 238 | 239 | 240 _____________________ 241 | 2 | 242 | Trigger | 243 | SDN Controller | 244 | | 245 |_____________________| 246 | 247 | 248 | 249 _____________________ 250 | 3 | 251 | Computation of | 252 | new transmission | 253 | parameters | 254 |_____________________| 255 | 256 | 257 | 258 _____________________ 259 | 4 | 260 | Data plane | 261 | reconfiguration | 262 | | 263 |_____________________| 265 Figure 2: Flow chart of the expected state-of-the-art approach 266 _______________________ 267 | 1 | 268 | Instructing the local | 269 | controller of | 270 | data plane devices | 271 |_______________________| 272 | 273 | 274 | 275 _______________________ 276 | 2 | 277 | Local reconfiguration | 278 | upon failure | 279 | detection | 280 |_______________________| 281 | 282 | 283 | 284 _______________________ 285 | 3 | 286 | | 287 | notification | 288 | | 289 |_______________________| 291 Figure 3: Flow chart of the approach exploiting YANG models in this 292 draft 294 4.2. Deploying Dynamic Probes for Programmable Network Telemetry 296 In the past, network data analytics was considered a separate 297 function from networks. They consume raw data extracted from 298 networks through piecemeal protocols and interfaces. With the advent 299 of user programmable data plane, we expect a paradigm shift that 300 makes the data plane be an active component of the data telemetry and 301 analytics solution. The programmable in-network data preprocessing 302 is efficient and flexible to offload some light-weight data 303 processing through dynamic data plane programming or configuration. 304 A universal network data analytics platform built on top of this 305 enables a tight and agile network control and OAM feedback loop. A 306 proposed dynamic network telemetry system architecture is illustrated 307 in Fig.4. 309 An application translates its data requirements into a set of Dynamic 310 Network Probes (DNP) targeting a subset of data plane devices. After 311 the probes are deployed, each probe conducts its corresponding in- 312 network data preprocessing and feeds the preprocessed data to the 313 collector. The collector finishes the data post-processing and 314 presents the results to the data-requesting application. 316 +-------------------------------------+ 317 | network telemetry applications | 318 +-------------------------------------+ 319 ^ | 320 | V 321 | +--------------------+ 322 | | DNP compile/config | 323 | +--------------------+ 324 | | 325 | V 326 +---------------+ +--------------------+ 327 |data collection| | Probe deployment | 328 +---------------+ +--------------------+ 329 ^ ^ ^ | | | 330 | | | V V V 331 +--------------------------------------+ 332 | network data plane devices | 333 | (in-network data preprocessing) | 334 +--------------------------------------+ 336 Figure 4: Deploy dynamic network probes using YANG FSM models 338 Many DNPs can be modeled as FSM which are configured to capture 339 specific events. Here FSMs essentially preprocess the raw stream 340 data and only report the necessary data to subscribing applications. 342 For example, a congestion control application needs to monitor the 343 router buffer occupancy. Instead of polling the buffer depth 344 periodically, it is only interested in the real-time events when the 345 buffer depth crosses a low and a high threshold. We can install a 346 probe to achieve this data plane function and the probe can be 347 modeled as a three-state FSM. Each state represents a buffer region: 348 below the low threshold, above the high threshold, and in between the 349 two thresholds. A possible state transition is checked against the 350 buffer depth for each incoming and outgoing packet. Whenever a state 351 transition happens, an event is generated and reported to the 352 application. This approach significantly reduces the amount of data 353 sent to the application and also allows a timely event notification. 355 For another example, an application would like to monitor the delay 356 experienced by a flow. The packet delay on its forwarding path can 357 be acquired by using iOAM [I-D.brockners-inband-oam-requirements]. 358 However, the application only needs to know that N consecutive flow 359 packets experience a delay longer than T. Instead of forwarding the 360 raw delay data to the application, a probe can be deployed to detect 361 the event. Similarly, the probe can be modeled as an FSM. 363 4.3. IP Performance Measurements on multipoint-to-multipoint large 364 Networks 366 Networks offer rich sets of network performance measurement data, but 367 traditional approaches run into limitations. One reason for this is 368 the fact that in many cases, the bottleneck is the generation and 369 export of the data and the amount of data that can be reasonably 370 collected from the network runs into bandwidth and processing 371 constraints in the network itself. In addition, management tasks 372 related to determining and configuring which data to generate lead to 373 significant deployment challenges. 375 In order to address these issues, an SDN controller application 376 orchestrates network performance measurements tasks across the 377 network to allow an optimized monitoring. In fact the IP Performance 378 Measurement SDN Controller Application in Figure 5 can calibrate how 379 deep can be obtained monitoring data from the network by configuring 380 measurement points roughly or meticulously. This can be established 381 by using the feedback mechanism reported in Figure 5. 383 For instance, the SDN Controller can configure initially an end to 384 end monitoring between ingress points and egress points of the 385 network. If the network does not experiment issues, this approximate 386 monitoring is good enough and is very cheap in terms of network 387 resources. But, in case of problems, the SDN Controller becomes 388 aware of the issues from this approximate monitoring and, in order to 389 localize the portion of the network that has issues, configures the 390 measurement points more exhaustively. So a new detailed monitoring 391 is performed. After the detection and resolution of the problem the 392 initial approximate monitoring can be used again. This idea is 393 general and can be applied to different performance measurements 394 techniques both active and passive (and hybrid). 396 +--------------------------------------+ 397 | IP Performance Measurement | 398 | SDN Controller Application | 399 +--------------------------------------+ 400 ^ ^ ^ | | | 401 | | | v v v 402 +--------------------------------------+ 403 | Multipoint Network | 404 +--------------------------------------+ 406 Figure 5: Feedback mechanism on multipoint-to-multipoint large 407 Networks 409 One of the most efficient methodology to perform packet, loss delay 410 and jitter measurements both in an IP and Overlay Networks is the 411 Alternate Marking method, as presented in [I-D.ietf-ippm-alt-mark] 412 and [I-D.fioccola-ippm-multipoint-alt-mark]. 414 This technique can be applied to point-to-point flows but also to 415 multipoint.to-multipoint flows (see [I-D.ietf-ippm-alt-mark] and 416 [I-D.fioccola-ippm-multipoint-alt-mark]). The Alternate Marking 417 method creates batches of packets by alternating the value of 1 or 2 418 bits of the packet header. These batches of packets are 419 unambiguously recognized over the network and the comparison of 420 packet counters permits the packet loss calculation. The same idea 421 can be applied for delay measurement by selecting special packets 422 with a marking bit dedicated for delay measurements. This method 423 needs two counters each marking period for each flow under monitor. 424 For this reason by considering n measurement points and n monitored 425 flows, the order of magnitude of the packet counters for each time 426 interval is n*n*2 (1 per color). 428 Multipoint Alternate Marking, described in 429 [I-D.fioccola-ippm-multipoint-alt-mark], aims to reduce this value 430 and makes the performance monitoring more flexible in case a detailed 431 analysis is not needed. 433 It is possible to monitor a Multipoint Network without examining in 434 depth by using the Network Clustering (subnetworks that are portions 435 of the entire network that preserve the same property of the entire 436 network). So in case there is packet loss or the delay is too high 437 the filtering criteria could be specified more in order to perform a 438 per flow detailed analysis, as described in [I-D.ietf-ippm-alt-mark]. 440 An application of the multipoint performance monitoring can be done 441 by using FSM (each state is a composition of clusters) and feedback 442 mechanism where the SDN Controller is the brain of the network and 443 can manage flow control to the switches and routers and, in the same 444 way, can calibrate the performance measurements depending on the 445 necessity. 447 5. YANG for finite state machine (FSM) 449 This model defines a list of states and transitions to describe a 450 generic finite state machine (FSM). The related code and tree are 451 shown in the Appendix. 453 : it defines the current state of the FSM. 454 : this element defines the FSM as follows. 455 : this list defines all the FSM states. 456 : this leaf attribute of defines the 457 identifier of the state 458 : this leaf attribute of defines the 459 name of the state 460 : this leaf is a "string" describing the 461 state 462 : this attribute defines a list of 463 transitions to other states in the FSM. 464 : this attribute defines the name of a 465 transition 466 : this attribute defines the type of the 467 transition from a pool of possible transition 468 types predefined inside the YANG model. 469 Together with the attribute, it 470 uniquely identifies the transition. 471 : this optional attribute is a 472 "string" describing the transition 473 : this leaf is a list of input 474 parameters related to the transition. This 475 attribute enables to further express a 476 transition: as an example, if a transition can 477 be triggered by a parameter (e.g., a monitored 478 performance parameter) exceeding a threshold 479 (as in Sec. 5), an element of the list defines 480 this threshold. Thus, if the parameter is 481 outside the threshold, the transition is 482 taken, otherwise not. 483 : this leaf of defines 484 a filter parameter. 485 : this leaf of 486 define the identifier number associated 487 with the attribute. 488 : this attribute defines a list of 489 actions to take during the transition. 490 : this attribute is the list of 491 actions 492 : this leaf of 493 defines the identifier number of 494 an action. 495 : this leaf of 496 defines the type of an action. 497 : this leaf defines 498 (differently from 499 detailed below) an action that 500 has to be directly executed. 501 : this attribute 502 recalls an RPC encapsulating 503 the effective task (action) 504 to be executed by the 505 hardware. If more actions 506 (e.g., "A" and "B"), defined 507 in the list, have 508 to be executed, these 509 actions can be executed 510 sequentially according to 511 the attribute 512 detailed below. Thus, by 513 referring to the tree of the 514 Appendix, when an action 515 ("A") is executed, the 516 attribute will 517 bring to another action 518 ("B"). If more actions have 519 to be executed in parallel 520 (e.g., "A" & "B"), not 521 sequentially, an element of 522 the list should be 523 defined to express an action 524 (e.g., "A&B") consisting of 525 more actions to be executed 526 in parallel. 527 : this 528 attribute defines the 529 identification number of a 530 next action that has to be 531 taken. The 532 can assume a NULL value. 533 : this leaf enables a 534 check ("true" or "false") to be 535 verified before executing the 536 action. Based on the check, the 537 proper attributes and 538 are considered. 539 : this leaf 540 of defines 541 the condition to be 542 verified before executing 543 the action. 544 : this leaf of 545 defines a 546 result of the check 547 associated to 548 . Proper 549 and 550 551 attributes are associated 552 with this result of the 553 check. 554 : this leaf of 555 defines a 556 result of the check 557 associated to 558 . Proper 559 and 560 561 attributes are associated 562 with this result of the 563 check. 564 : this attribute defines 565 the next state of FSM when an action is 566 executed. 568 6. Implementation of the pre-programming resiliency schemes in EONs 570 These presented model can be used to enable a centralized network 571 controller, managed by a network operator, to instruct data plane 572 hardware on its reconfiguration if some events, such as a failure or 573 physical layer degradation, occur. As an example, an optical signal 574 impacted by a soft failure (i.e., a physical layer degradation 575 inducing a pre forward error correction bit error rate increase - 576 pre-FEC) can be maintained by adapting the FEC of the signal itself. 577 This action to be taken and, more in general operations to be 578 executed depending on critical events, can be (re-) programmed on the 579 transponder by (re-) sending a NETCONF message to the 580 device controller including a FSM defined by the YANG model. Such a 581 system has the main goal to speed up the reaction of the network to 582 certain events/faults and to alleviate the workload of the 583 centralized controller. The speed up derives from the fact that the 584 centralized controller is able to pre-compute and pre-configure on 585 the network devices the actions to take when an event occurs taking 586 into account a global view and knowledge of the network. In this 587 way, the device is already aware of the actions to be locally applied 588 to reconfigure a connection, avoiding to inform the controller and to 589 wait for the response indicating what to do. Consequently, part of 590 the workload is also removed from the centralized controller. When 591 the reaction is successfully completed in the data plane, the 592 centralized controller can be notified about the faults and the taken 593 action. A flexible transponder supporting two FEC types, 7% and 20%, 594 is considered. A two-states FSM is also assumed. The states have 595 attribute set to "Steady" and "Fec-Baud-Adapt", respectively. 596 In the "Steady" state, the signal is in a healthy condition, adopting 597 a 7% FEC, with a pre-FEC BER below an assigned threshold of 9 x 10-4. 598 A transition from this state can be triggered by the event with 599 =BER_CHANGE and =9 x 10-4, thus expressing a 600 change of the pre-FEC BER above the threshold. In case the pre-FEC 601 BER exceeds 9 x 10-4 due to a soft failure, the state machine evolves 602 to the "Fec-Baud-Adapt" state and an adaptation to a more robust FEC 603 of 20% (executed by the attribute ) is performed. The 604 system can return to the "Steady" state if the pre-FEC BER goes below 605 another pre-defined threshold and the FEC is reconfigured to 7%. 607 7. Appendix 609 This appendix reports the YANG models code and the related tree. 611 7.1. YANG model for FSM - Tree 613 module: finite-state-machine 614 +--rw current-state? leafref 615 +--rw states 616 +--rw state [id] 617 +--rw id state-id-type 618 +--rw description? string 619 +--rw transitions 620 +--rw transition [name type] 621 +--rw name string 622 +--rw type transition-type 623 +--rw description? string 624 +--rw filters 625 | +--rw filter [filter-id] 626 | +--rw filter-id yp:filter-id 627 +--rw actions 628 +--rw action [id] 629 +--rw id transition-id-type 630 +--rw type enumeration 631 +--rw conditional 632 | +--rw statement string 633 | +--rw true 634 | | +--rw execute 635 | | +--rw next-action? transition-id-type 636 | | +--rw next-state? leafref 637 | +--rw false 638 | +--rw execute 639 | +--rw next-action? transition-id-type 640 | +--rw next-state? leafref 641 +--rw simple 642 +--rw execute 643 +--rw next-action? transition-id-type 644 +--rw next-state? leafref 646 7.2. YANG model for FSM - Code 648 file "ietf-fsm@2016-03-15.yang" 650 module transitions { 652 namespace "http://sssup.it/transitions"; 654 prefix ev; 656 import ietf-yang-push { 658 prefix yp; 660 } 662 organization 664 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 666 contact 668 " Editor: Matteo Dallaglio 670 672 "; 674 description 676 "This module contains a YANG definitions of events and generic 677 reactions."; 679 revision 2016-03-15 { 681 description "Initial Revision."; 683 reference 684 "RFC xxxx: A YANG data model for the description of events and 685 reactions"; 687 } 689 // identity statements 691 identity TRANSITION { 693 description "Base for all types of event"; 695 } 697 identity ON_CHANGE { 699 base TRANSITION; 701 description 703 "The event when the database changes."; 705 } 707 // typedef statements 709 typedef transition-type { 711 type identityref { 713 base TRANSITION; 715 } 717 } 719 typedef transition-id-type { 720 type uint32; 722 } 724 // grouping statements 726 grouping action-block { 728 leaf id { 730 type transition-id-type; 732 } 734 leaf type { 736 type enumeration { 738 enum CONDITIONAL_OP; 740 enum SIMPLE_OP; 742 } 744 mandatory true; 746 } 748 grouping execution-top { 750 anyxml execute { 752 description "Represent the action to perform"; 754 } 756 leaf next-action { 758 type transition-id-type; 760 description "the id of the next action to execute"; 762 } 764 } 766 container conditional { 768 when "../type = 'CONDITIONAL_OP'"; 770 leaf statement { 772 type string; 774 mandatory true; 776 description 778 "The statement to be evaluated before execution. 780 E.g. if a=b"; 782 } 784 container true { 786 uses execution-top; 788 } 790 container false { 792 uses execution-top; 794 } 796 } 798 container simple { 800 when "../type = 'SIMPLE_OP'"; 802 description 804 "Simple execution of an action without checking any condition"; 806 uses execution-top; 808 } 810 } 812 grouping action-top { 814 list action { 816 key "id"; 818 ordered-by user; 820 uses action-block; 822 } 824 } 826 grouping on-change { 828 description 830 "Event occuring when a modification of one or more 832 objects occurs"; 834 container filters { 836 description 838 "This container contains a list of configurable filters 840 that can be applied to subscriptions. This facilitates 842 the reuse of complex filters once defined."; 844 list filter { 846 key "filter-id"; 847 description 849 "A list of configurable filters that can be applied to 851 subscriptions."; 853 leaf filter-id { 855 type yp:filter-id; 857 description 859 "An identifier to differentiate between filters."; 861 } 863 uses yp:datatree-filter; 865 } 867 } 869 } 871 grouping transition-top { 873 leaf name { 875 type string; 877 mandatory true; 879 } 881 leaf type { 883 type transition-type; 885 mandatory true; 887 } 888 leaf description { 890 type string; 892 } 894 // list of all possible events 896 uses on-change { 898 when "type = 'ON_CHANGE'"; 900 } 902 container actions { 904 uses action-top; 906 } 908 } 910 grouping transitions-top { 912 container transitions { 914 list transition { 916 key "name type"; 918 uses transition-top; 920 } 922 } 924 } 925 // data definition statements 927 uses transitions-top; 929 // extension statements 931 // feature statements 933 // augment statements 935 // rpc statements 937 // notification statements 939 }//module transitions 941 module finite-state-machine { 943 namespace "http://sssup.it/fsm"; 945 prefix fsm; 947 import transitions { 949 prefix ev; 951 } 952 organization 954 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 956 contact 958 " Editor: Matteo Dallaglio 960 962 "; 964 description 966 "This module contains a YANG definitions of a generic finite state 967 machine."; 969 revision 2016-03-15 { 971 description "Initial Revision."; 973 reference 975 "RFC xxxx:"; 977 } 979 // identity statements 981 // typedef statements 983 typedef state-id-type { 985 type uint32; 987 } 988 // grouping statements 990 grouping state-top { 992 leaf id { 994 type state-id-type; 996 } 998 leaf description { 1000 type string; 1002 } 1004 grouping next-state-top { 1006 leaf next-state { 1008 type leafref { 1010 path "../../../../../../../../../states/state/id"; 1012 } 1014 description "Id of the next state"; 1016 } 1018 } 1020 uses ev:transitions-top { 1022 augment "transitions/transition/actions/action/conditional/true" { 1024 uses next-state-top; 1026 } 1028 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 type leafref { 1042 path "../../../../../../../../states/state/id"; 1044 } 1046 description "Id of the next state"; 1048 } 1050 } 1052 } 1054 } 1056 grouping states-top { 1058 leaf current-state { 1060 type leafref { 1062 path "../states/state/id"; 1064 } 1066 } 1068 container states { 1070 list state { 1072 key "id"; 1074 uses state-top; 1076 } 1078 } 1080 } 1082 // data definition statements 1084 uses states-top; 1086 // extension statements 1088 // feature statements 1090 // augment statements. 1092 // rpc statements 1094 // notification statements 1096 }//module fsm 1098 1100 7.3. Example of values for the YANG model 1101 FIELD NAME | YANG DATA TYPE | VALUE 1102 _________________|_____________________|________________________ 1103 Current State | leafref | "an existing state id 1104 | | in the FSM" 1105 | | 1106 State | | 1107 id | uint32 | 1 1108 name | string | Steady 1109 description | string | "whatever string" 1110 | | 1111 transition | | 1112 name | string | "whatever string" 1113 type | enum | BER_CHANGE 1114 description | string | "whatever string" 1115 | | 1116 filter | | 1117 filter-id | uint32 | 2 1118 filter-type | anyxml or xpath | BER>0.0009 1119 | | 1120 action | | 1121 id | uint32 | 3 1122 type | enum | SIMPLE 1123 statement | string | "whatever string" 1124 execute | anyxml | "this recalls an RPC 1125 | | where the FEC value 1126 | | is expressed" 1127 next-operation | uint32 | NULL 1128 next-state | leafref | "an existing state id 1129 | | in the FSM" 1131 8. Acknowledgements 1133 This work has been partially supported by the European Commission 1134 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 1135 dynamic networks using a Holistic cross-layEr, Self-configurable 1136 Truly flexible approach, grant agreement no: H2020-645360) project. 1137 The views expressed here are those of the authors only. The European 1138 Commission is not liable for any use that may be made of the 1139 information in this document. 1141 9. Other Contributors 1143 Matteo Dallaglio (Scuola Superiore Sant'Anna), Andrea Di Giglio 1144 (Telecom Italia), Giacomo Bernini (Nextworks). 1146 10. Security Considerations 1148 TBD 1150 11. References 1152 11.1. Normative References 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", BCP 14, RFC 2119, 1156 DOI 10.17487/RFC2119, March 1997, 1157 . 1159 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1160 the Network Configuration Protocol (NETCONF)", RFC 6020, 1161 DOI 10.17487/RFC6020, October 2010, 1162 . 1164 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1165 and A. Bierman, Ed., "Network Configuration Protocol 1166 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1167 . 1169 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1170 Application-Based Network Operations", RFC 7491, 1171 DOI 10.17487/RFC7491, March 2015, 1172 . 1174 11.2. Informative References 1176 [I-D.brockners-inband-oam-requirements] 1177 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1178 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1179 T., <>, P., and r. remy@barefootnetworks.com, 1180 "Requirements for In-situ OAM", draft-brockners-inband- 1181 oam-requirements-03 (work in progress), March 2017. 1183 [I-D.fioccola-ippm-multipoint-alt-mark] 1184 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 1185 "Multipoint Alternate Marking method for passive and 1186 hybrid performance monitoring", draft-fioccola-ippm- 1187 multipoint-alt-mark-01 (work in progress), October 2017. 1189 [I-D.ietf-i2rs-yang-network-topo] 1190 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1191 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1192 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1193 progress), December 2017. 1195 [I-D.ietf-ippm-alt-mark] 1196 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 1197 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1198 "Alternate Marking method for passive and hybrid 1199 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 1200 in progress), December 2017. 1202 [I-D.song-opsawg-dnp4iq] 1203 Song, H. and J. Gong, "Requirements for Interactive Query 1204 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 1205 (work in progress), June 2017. 1207 [I-D.vergara-ccamp-flexigrid-yang] 1208 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1209 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1210 Flexi-Grid Optical Networks", draft-vergara-ccamp- 1211 flexigrid-yang-06 (work in progress), January 2018. 1213 [I-D.zhang-ccamp-l1-topo-yang] 1214 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 1215 Liu, "A YANG Data Model for Optical Transport Network 1216 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 1217 progress), April 2017. 1219 Authors' Addresses 1221 Nicola Sambo 1222 Scuola Superiore Sant'Anna 1223 Via Moruzzi 1 1224 Pisa 56124 1225 Italy 1227 Email: nicola.sambo@sssup.it 1229 Piero Castoldi 1230 Scuola Superiore Sant'Anna 1231 Via Moruzzi 1 1232 Pisa 56124 1233 Italy 1235 Email: piero.castoldi@sssup.it 1236 Giuseppe Fioccola 1237 Telecom Italia 1238 Via Reiss Romoli, 274 1239 Torino 10148 1240 Italy 1242 Email: giuseppe.fioccola@telecomitalia.it 1244 Filippo Cugini 1245 CNIT 1246 Via Moruzzi 1 1247 Pisa 56124 1248 Italy 1250 Email: filippo.cugini@cnit.it 1252 Haoyu Song 1253 Huawei 1254 2330 Central Expressway 1255 Santa Clara, CA 95050 1256 USA 1258 Email: haoyu.song@huawei.com 1260 Tianran Zhou 1261 Huawei 1262 156 Beiqing Road 1263 Beijing 100095 1264 China 1266 Email: zhoutianran@huawei.com