idnits 2.17.1 draft-sambo-netmod-yang-fsm-04.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 649 has weird spacing: '...lter-id uin...' == Line 655 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 (October 22, 2018) is 2012 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 Summary: 1 error (**), 0 flaws (~~), 4 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: April 25, 2019 G. Fioccola 6 Huawei Technologies 7 F. Cugini 8 CNIT 9 H. Song 10 T. Zhou 11 Huawei 12 October 22, 2018 14 YANG model for finite state machine 15 draft-sambo-netmod-yang-fsm-04 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 April 25, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. IP Performance Measurements on multipoint-to-multipoint 82 large Networks . . . . . . . . . . . . . . . . . . . . . 10 83 5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 11 84 6. Implementation of the pre-programming resiliency schemes in 85 EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 15 88 7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 16 89 7.3. Example of values for the YANG model . . . . . . . . . . 28 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 91 9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 29 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 96 12.2. Informative References . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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. The 208 whole mechanism is based on a finite state machine where each state 209 is associated to a specific configuration of transmission parameters 210 (e.g., modulation format). The transition from a state to another 211 state is triggered by specific events at the physical layer such as 212 the bit error rate above a threshold. The transition from a state to 213 another state implies a set of actions, including the change of 214 transmission parameters (e.g., modulation format), which are actually 215 suitable for the current condition at the physical layer. Moreover, 216 since transmission and receiver must be synchronized about the 217 transmission settings (modulation format and so no) for a proper 218 transmission, another action consists of this synchronization. Thus, 219 when the transponder at the receiver side decides to change its 220 transmission parameters based on the monitored BER, the remote 221 transponder at the transmitter side has to do the same state 222 transition. In particular, the transponder at the receiver side 223 sends a message to the transmitter to synchronize about the 224 transmission parameters to be adopted. This message can be sent over 225 a control channel. This way both the transmitter and receiver 226 operates with the same transmission parameters: e.g. the format, FEC, 227 and so on. No central controller is involved at this stage, only a 228 notification can be sent to the central controller to inform it about 229 the successful reconfiguration. 231 ___________ ___________ 232 | ABNO | | OAM | 233 |controller | ------ | Handler | 234 |___________| |___________| 236 | | 237 | | 238 | | 239 ____________ | 240 | SDN | | 241 | controller | | 242 |____________| | 243 | 244 | | 245 | | 246 | | 247 _____________________________ 248 | Client | 249 | network | 250 |_____________________________| 252 Figure 1: Assumed ABNO functional modules 254 _____________________ 255 | 1 | 256 |Sending alarm to the | 257 | OAM Handler | 258 | | 259 |_____________________| 260 | 261 | 262 | 263 _____________________ 264 | 2 | 265 | Trigger | 266 | SDN Controller | 267 | | 268 |_____________________| 269 | 270 | 271 | 272 _____________________ 273 | 3 | 274 | Computation of | 275 | new transmission | 276 | parameters | 277 |_____________________| 278 | 279 | 280 | 281 _____________________ 282 | 4 | 283 | Data plane | 284 | reconfiguration | 285 | | 286 |_____________________| 288 Figure 2: Flow chart of the expected state-of-the-art approach 289 _______________________ 290 | 1 | 291 | Instructing the local | 292 | controller of | 293 | data plane devices | 294 |_______________________| 295 | 296 | 297 | 298 _______________________ 299 | 2 | 300 | Local reconfiguration | 301 | upon failure | 302 | detection | 303 |_______________________| 304 | 305 | 306 | 307 _______________________ 308 | 3 | 309 | | 310 | notification | 311 | | 312 |_______________________| 314 Figure 3: Flow chart of the approach exploiting YANG models in this 315 draft 317 4.2. Deploying Dynamic Probes for Programmable Network Telemetry 319 In the past, network data analytics was considered a separate 320 function from networks. They consume raw data extracted from 321 networks through piecemeal protocols and interfaces. With the advent 322 of user programmable data plane, we expect a paradigm shift that 323 makes the data plane be an active component of the data telemetry and 324 analytics solution. The programmable in-network data preprocessing 325 is efficient and flexible to offload some light-weight data 326 processing through dynamic data plane programming or configuration. 327 A universal network data analytics platform built on top of this 328 enables a tight and agile network control and OAM feedback loop. A 329 proposed dynamic network telemetry system architecture is illustrated 330 in Fig.4. 332 An application translates its data requirements into a set of Dynamic 333 Network Probes (DNP) targeting a subset of data plane devices. After 334 the probes are deployed, each probe conducts its corresponding in- 335 network data preprocessing and feeds the preprocessed data to the 336 collector. The collector finishes the data post-processing and 337 presents the results to the data-requesting application. 339 +-------------------------------------+ 340 | network telemetry applications | 341 +-------------------------------------+ 342 ^ | 343 | V 344 | +--------------------+ 345 | | DNP compile/config | 346 | +--------------------+ 347 | | 348 | V 349 +---------------+ +--------------------+ 350 |data collection| | Probe deployment | 351 +---------------+ +--------------------+ 352 ^ ^ ^ | | | 353 | | | V V V 354 +--------------------------------------+ 355 | network data plane devices | 356 | (in-network data preprocessing) | 357 +--------------------------------------+ 359 Figure 4: Deploy dynamic network probes using YANG FSM models 361 Many DNPs can be modeled as FSM which are configured to capture 362 specific events. Here FSMs essentially preprocess the raw stream 363 data and only report the necessary data to subscribing applications. 365 For example, a congestion control application needs to monitor the 366 router buffer occupancy. Instead of polling the buffer depth 367 periodically, it is only interested in the real-time events when the 368 buffer depth crosses a low and a high threshold. We can install a 369 probe to achieve this data plane function and the probe can be 370 modeled as a three-state FSM. Each state represents a buffer region: 371 below the low threshold, above the high threshold, and in between the 372 two thresholds. A possible state transition is checked against the 373 buffer depth for each incoming and outgoing packet. Whenever a state 374 transition happens, an event is generated and reported to the 375 application. This approach significantly reduces the amount of data 376 sent to the application and also allows a timely event notification. 378 For another example, an application would like to monitor the delay 379 experienced by a flow. The packet delay on its forwarding path can 380 be acquired by using iOAM [I-D.brockners-inband-oam-requirements]. 381 However, the application only needs to know that N consecutive flow 382 packets experience a delay longer than T. Instead of forwarding the 383 raw delay data to the application, a probe can be deployed to detect 384 the event. Similarly, the probe can be modeled as an FSM. 386 4.3. IP Performance Measurements on multipoint-to-multipoint large 387 Networks 389 Networks offer rich sets of network performance measurement data, but 390 traditional approaches run into limitations. One reason for this is 391 the fact that in many cases, the bottleneck is the generation and 392 export of the data and the amount of data that can be reasonably 393 collected from the network runs into bandwidth and processing 394 constraints in the network itself. In addition, management tasks 395 related to determining and configuring which data to generate lead to 396 significant deployment challenges. 398 In order to address these issues, an SDN controller application 399 orchestrates network performance measurements tasks across the 400 network to allow an optimized monitoring. In fact the IP Performance 401 Measurement SDN Controller Application in Figure 5 can calibrate how 402 deep can be obtained monitoring data from the network by configuring 403 measurement points roughly or meticulously. This can be established 404 by using the feedback mechanism reported in Figure 5. 406 For instance, the SDN Controller can configure initially an end to 407 end monitoring between ingress points and egress points of the 408 network. If the network does not experiment issues, this approximate 409 monitoring is good enough and is very cheap in terms of network 410 resources. But, in case of problems, the SDN Controller becomes 411 aware of the issues from this approximate monitoring and, in order to 412 localize the portion of the network that has issues, configures the 413 measurement points more exhaustively. So a new detailed monitoring 414 is performed. After the detection and resolution of the problem the 415 initial approximate monitoring can be used again. This idea is 416 general and can be applied to different performance measurements 417 techniques both active and passive (and hybrid). 419 +--------------------------------------+ 420 | IP Performance Measurement | 421 | SDN Controller Application | 422 +--------------------------------------+ 423 ^ ^ ^ | | | 424 | | | v v v 425 +--------------------------------------+ 426 | Multipoint Network | 427 +--------------------------------------+ 429 Figure 5: Feedback mechanism on multipoint-to-multipoint large 430 Networks 432 One of the most efficient methodology to perform packet, loss delay 433 and jitter measurements both in an IP and Overlay Networks is the 434 Alternate Marking method, as presented in [I-D.ietf-ippm-alt-mark] 435 and [I-D.fioccola-ippm-multipoint-alt-mark]. 437 This technique can be applied to point-to-point flows but also to 438 multipoint.to-multipoint flows (see [I-D.ietf-ippm-alt-mark] and 439 [I-D.fioccola-ippm-multipoint-alt-mark]). The Alternate Marking 440 method creates batches of packets by alternating the value of 1 or 2 441 bits of the packet header. These batches of packets are 442 unambiguously recognized over the network and the comparison of 443 packet counters permits the packet loss calculation. The same idea 444 can be applied for delay measurement by selecting special packets 445 with a marking bit dedicated for delay measurements. This method 446 needs two counters each marking period for each flow under monitor. 447 For this reason by considering n measurement points and n monitored 448 flows, the order of magnitude of the packet counters for each time 449 interval is n*n*2 (1 per color). 451 Multipoint Alternate Marking, described in 452 [I-D.fioccola-ippm-multipoint-alt-mark], aims to reduce this value 453 and makes the performance monitoring more flexible in case a detailed 454 analysis is not needed. 456 It is possible to monitor a Multipoint Network without examining in 457 depth by using the Network Clustering (subnetworks that are portions 458 of the entire network that preserve the same property of the entire 459 network). So in case there is packet loss or the delay is too high 460 the filtering criteria could be specified more in order to perform a 461 per flow detailed analysis, as described in [I-D.ietf-ippm-alt-mark]. 463 An application of the multipoint performance monitoring can be done 464 by using FSM (each state is a composition of clusters) and feedback 465 mechanism where the SDN Controller is the brain of the network and 466 can manage flow control to the switches and routers and, in the same 467 way, can calibrate the performance measurements depending on the 468 necessity. 470 5. YANG for finite state machine (FSM) 472 This model defines a list of states and transitions to describe a 473 generic finite state machine (FSM). The related code and tree are 474 shown in the Appendix. 476 : it defines the current state of the FSM. 477 : this element defines the FSM as follows. 478 : this list defines all the FSM states. 479 : this leaf attribute of defines the 480 identifier of the state 481 : this leaf attribute of defines the 482 name of the state 483 : this leaf is a "string" describing the 484 state 485 : this attribute defines a list of 486 transitions to other states in the FSM. 487 : this attribute defines the name of a 488 transition 489 : this attribute defines the type of the 490 transition from a pool of possible transition 491 types predefined inside the YANG model. 492 Together with the attribute, it 493 uniquely identifies the transition. 494 : this optional attribute is a 495 "string" describing the transition 496 : this leaf is a list of input 497 parameters related to the transition. This 498 attribute enables to further express a 499 transition: as an example, if a transition can 500 be triggered by a parameter (e.g., a monitored 501 performance parameter) exceeding a threshold 502 (as in Sec. 5), an element of the list defines 503 this threshold. Thus, if the parameter is 504 outside the threshold, the transition is 505 taken, otherwise not. 506 : this leaf of defines 507 a filter parameter. 508 : this leaf of 509 define the identifier number associated 510 with the attribute. 511 : this attribute defines a list of 512 actions to take during the transition. 513 : this attribute is the list of 514 actions 515 : this leaf of 516 defines the identifier number of 517 an action. 518 : this leaf of 519 defines the type of an action. 520 : this leaf defines 521 (differently from 522 detailed below) an action that 523 has to be directly executed. 524 : this attribute 525 recalls an RPC encapsulating 526 the effective task (action) 527 to be executed by the 528 hardware. If more actions 529 (e.g., "A" and "B"), defined 530 in the list, have 531 to be executed, these 532 actions can be executed 533 sequentially according to 534 the attribute 535 detailed below. Thus, by 536 referring to the tree of the 537 Appendix, when an action 538 ("A") is executed, the 539 attribute will 540 bring to another action 541 ("B"). If more actions have 542 to be executed in parallel 543 (e.g., "A" & "B"), not 544 sequentially, an element of 545 the list should be 546 defined to express an action 547 (e.g., "A&B") consisting of 548 more actions to be executed 549 in parallel. 550 : this 551 attribute defines the 552 identification number of a 553 next action that has to be 554 taken. The 555 can assume a NULL value. 556 : this leaf enables a 557 check ("true" or "false") to be 558 verified before executing the 559 action. Based on the check, the 560 proper attributes and 561 are considered. 562 : this leaf 563 of defines 564 the condition to be 565 verified before executing 566 the action. 567 : this leaf of 568 defines a 569 result of the check 570 associated to 571 . Proper 572 and 573 574 attributes are associated 575 with this result of the 576 check. 577 : this leaf of 578 defines a 579 result of the check 580 associated to 581 . Proper 582 and 583 584 attributes are associated 585 with this result of the 586 check. 587 : this attribute defines 588 the next state of FSM when an action is 589 executed. 591 6. Implementation of the pre-programming resiliency schemes in EONs 593 These presented model can be used to enable a centralized network 594 controller, managed by a network operator, to instruct data plane 595 hardware on its reconfiguration if some events, such as a failure or 596 physical layer degradation, occur. As an example, an optical signal 597 impacted by a soft failure (i.e., a physical layer degradation 598 inducing a pre forward error correction bit error rate increase - 599 pre-FEC) can be maintained by adapting the FEC of the signal itself. 600 This action to be taken and, more in general operations to be 601 executed depending on critical events, can be (re-) programmed on the 602 transponder by (re-) sending a NETCONF message to the 603 device controller including a FSM defined by the YANG model. Such a 604 system has the main goal to speed up the reaction of the network to 605 certain events/faults and to alleviate the workload of the 606 centralized controller. The speed up derives from the fact that the 607 centralized controller is able to pre-compute and pre-configure on 608 the network devices the actions to take when an event occurs taking 609 into account a global view and knowledge of the network. In this 610 way, the device is already aware of the actions to be locally applied 611 to reconfigure a connection, avoiding to inform the controller and to 612 wait for the response indicating what to do. Consequently, part of 613 the workload is also removed from the centralized controller. When 614 the reaction is successfully completed in the data plane, the 615 centralized controller can be notified about the faults and the taken 616 action. A flexible transponder supporting two FEC types, 7% and 20%, 617 is considered. A two-states FSM is also assumed. The states have 618 attribute set to "Steady" and "Fec-Baud-Adapt", respectively. 619 In the "Steady" state, the signal is in a healthy condition, adopting 620 a 7% FEC, with a pre-FEC BER below an assigned threshold of 9 x 10-4. 621 A transition from this state can be triggered by the event with 622 =BER_CHANGE and =9 x 10-4, thus expressing a 623 change of the pre-FEC BER above the threshold. In case the pre-FEC 624 BER exceeds 9 x 10-4 due to a soft failure, the state machine evolves 625 to the "Fec-Baud-Adapt" state and an adaptation to a more robust FEC 626 of 20% (executed by the attribute ) is performed. The 627 system can return to the "Steady" state if the pre-FEC BER goes below 628 another pre-defined threshold and the FEC is reconfigured to 7%. 630 7. Appendix 632 This appendix reports the YANG models code and the related tree. 634 7.1. YANG model for FSM - Tree 636 module: ietf-fsm 637 +--rw current-state? leafref 638 +--rw states 639 +--rw state [id] 640 +--rw id state-id-type 641 +--rw description? string 642 +--rw transitions 643 +--rw transition [name type] 644 +--rw name string 645 +--rw type transition-type 646 +--rw description? string 647 +--rw filters 648 | +--rw filter [filter-id] 649 | +--rw filter-id uint32 650 +--rw actions 651 +--rw action [id] 652 +--rw id transition-id-type 653 +--rw type enumeration 654 +--rw conditional 655 | +--rw statement string 656 | +--rw true 657 | | +--rw execute 658 | | +--rw next-action? transition-id-type 659 | | +--rw next-state? leafref 660 | +--rw false 661 | +--rw execute 662 | +--rw next-action? transition-id-type 663 | +--rw next-state? leafref 664 +--rw simple 665 +--rw execute 666 +--rw next-action? transition-id-type 667 +--rw next-state? leafref 669 7.2. YANG model for FSM - Code 671 file "ietf-fsm@2016-03-15.yang" 673 module ietf-fsm { 675 namespace "http://sssup.it/fsm"; 677 prefix fsm; 679 identity TRANSITION { 681 description "Base for all types of event"; 683 } 685 identity ON_CHANGE { 687 base TRANSITION; 689 description 691 "The event when the database changes."; 693 } 695 // typedef statements 697 typedef transition-type { 699 description "it defines the type of transition (event)"; 701 type identityref { 703 base TRANSITION; 705 } 707 } 709 typedef transition-id-type { 710 description "it defines the id of the transition (event)"; 712 type uint32; 714 } 716 // grouping statements 718 grouping action-block { 720 description "it defines the action to perform when a transition 721 occurs"; 723 leaf id { 725 description "it refers to the id of the transition"; 726 type transition-id-type; 728 } 730 leaf type { 732 description "it defines if the action has to be simply executed or if 733 a conditional statement has to be checked before execution"; 735 type enumeration { 737 enum "CONDITIONAL_OP" { 738 description "it defines the type CONDITIONAL OPERATION to check a 739 statement before execution"; 740 } 742 enum "SIMPLE_OP" { 743 description "it defines the type SIMPLE OPERATION: i.e., an operation 744 to be directly executed; 745 } 747 } 749 mandatory true; 751 } 753 grouping execution-top { 755 description "it defines the execution attribute"; 757 anyxml execute { 759 description "Represent the action to perform"; 761 } 763 leaf next-action { 765 type transition-id-type; 767 description "the id of the next action to execute"; 769 } 771 } 773 container conditional { 775 description "it defines the container CONDITIONAL"; 777 when "../type = 'CONDITIONAL_OP'"; 779 leaf statement { 781 type string; 783 mandatory true; 785 description 787 "The statement to be evaluated before execution. 789 E.g. if a=b"; 791 } 793 container true { 795 description "it is referred to the result TRUE of a conditional 796 statement"; 798 uses execution-top; 800 } 802 container false { 804 description "it is referred to the result FALSE of a conditional 805 statement "; 807 uses execution-top; 809 } 811 } 813 container simple { 814 description "Simple execution of an action without checking any 815 condition"; 817 when "../type = 'SIMPLE_OP'"; 819 uses execution-top; 821 } 823 } 825 grouping action-top { 827 description "it defines the grouping of action"; 829 list action { 831 description "it defines the list of actions"; 832 key "id"; 834 ordered-by user; 836 uses action-block; 838 } 840 } 842 grouping on-change { 844 description 846 "Event occuring when a modification of one or more 848 objects occurs"; 850 container filters { 852 description 854 "This container contains a list of configurable filters 856 that can be applied to subscriptions. This facilitates 858 the reuse of complex filters once defined."; 860 list filter { 862 key "filter-id"; 864 description 866 "A list of configurable filters that can be applied to 868 subscriptions."; 870 leaf filter-id { 872 type uint32; 874 description 875 "An identifier to differentiate between filters."; 877 } 879 } 881 } 883 } 885 grouping transition-top { 887 description "it defines the grouping transition"; 889 leaf name { 891 description "it defines the transition name"; 893 type string; 895 mandatory true; 897 } 899 leaf type { 901 description "it defines the transition type"; 903 type transition-type; 905 mandatory true; 907 } 909 leaf description { 911 description "it describes the transition "; 913 type string; 915 } 917 // list of all possible events 919 uses on-change { 921 when "type = 'ON_CHANGE'"; 923 } 925 container actions { 927 description "it defines the container action"; 929 uses action-top; 931 } 933 } 935 grouping transitions-top { 937 description "it defines the grouping transition"; 939 container transitions { 941 description "it defines the container transitions"; 943 list transition { 945 description "it defines the list of transitions"; 947 key "name type"; 949 uses transition-top; 951 } 953 } 955 } 957 // data definition statements 959 uses transitions-top; 961 // extension statements 963 // feature statements 965 // augment statements 967 organization 969 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 971 contact 973 " Editor: Matteo Dallaglio 975 977 "; 979 description 981 "This module contains a YANG definitions of a generic finite state 982 machine."; 984 revision 2016-03-15 { 986 description "Initial Revision."; 988 reference 990 "RFC xxxx:"; 992 } 994 // identity statements 996 // typedef statements 998 typedef state-id-type { 1000 description "it defines the id type of the states"; 1002 type uint32; 1004 } 1006 // grouping statements 1008 grouping state-top { 1010 description "it defines the grouping state"; 1012 leaf id { 1014 description "it defines the id of a transition"; 1016 type state-id-type; 1018 } 1019 leaf description { 1021 description "it describes a transition"; 1023 type string; 1025 } 1027 grouping next-state-top { 1029 description "it defines the grouping for the next state"; 1031 leaf next-state { 1033 description "it defines the next state"; 1035 type leafref { 1037 description "it refers to its id"; 1039 path "../../../../../../../../../states/state/id"; 1041 } 1043 description "Id of the next state"; 1045 } 1047 } 1049 uses transitions-top { 1051 augment "transitions/transition/actions/action/conditional/true" { 1052 uses next-state-top; 1054 } 1056 augment "transitions/transition/actions/action/conditional/false" { 1058 uses next-state-top; 1060 } 1062 augment "transitions/transition/actions/action/simple" { 1064 //uses next-state-top; 1066 leaf next-state { 1068 description "it defines the next state"; 1070 type leafref { 1072 description "it refers to its id"; 1073 path "../../../../../../../../states/state/id"; 1075 } 1077 description "Id of the next state"; 1079 } 1081 } 1083 } 1085 } 1086 grouping states-top { 1088 description "it defines the grouping states"; 1090 leaf current-state { 1092 description "it defines the current state"; 1094 type leafref { 1095 description "it refers to its id"; 1096 path "../states/state/id"; 1098 } 1100 } 1102 container states { 1103 description "it defines the container states"; 1105 list state { 1107 description "it defines the list of states"; 1109 key "id"; 1111 uses state-top; 1113 } 1115 } 1117 } 1119 // data definition statements 1120 uses states-top; 1122 // extension statements 1124 // feature statements 1126 // augment statements. 1128 // rpc statements 1130 }//module fsm 1132 1134 7.3. Example of values for the YANG model 1135 FIELD NAME | YANG DATA TYPE | VALUE 1136 _________________|_____________________|________________________ 1137 Current State | leafref | "an existing state id 1138 | | in the FSM" 1139 | | 1140 State | | 1141 id | uint32 | 1 1142 name | string | Steady 1143 description | string | "whatever string" 1144 | | 1145 transition | | 1146 name | string | "whatever string" 1147 type | enum | BER_CHANGE 1148 description | string | "whatever string" 1149 | | 1150 filter | | 1151 filter-id | uint32 | 2 1152 filter-type | anyxml or xpath | BER>0.0009 1153 | | 1154 action | | 1155 id | uint32 | 3 1156 type | enum | SIMPLE 1157 statement | string | "whatever string" 1158 execute | anyxml | "this recalls an RPC 1159 | | where the FEC value 1160 | | is expressed" 1161 next-operation | uint32 | NULL 1162 next-state | leafref | "an existing state id 1163 | | in the FSM" 1165 8. Acknowledgements 1167 This work has been partially supported by the European Commission 1168 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 1169 dynamic networks using a Holistic cross-layEr, Self-configurable 1170 Truly flexible approach, grant agreement no: H2020-645360) project. 1171 The views expressed here are those of the authors only. The European 1172 Commission is not liable for any use that may be made of the 1173 information in this document. 1175 9. Other Contributors 1177 Matteo Dallaglio (Scuola Superiore Sant'Anna), Andrea Di Giglio 1178 (Telecom Italia), Giacomo Bernini (Nextworks). 1180 10. Security Considerations 1182 TBD 1184 11. IANA Considerations 1186 TBD 1188 12. References 1190 12.1. Normative References 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, 1194 DOI 10.17487/RFC2119, March 1997, 1195 . 1197 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1198 the Network Configuration Protocol (NETCONF)", RFC 6020, 1199 DOI 10.17487/RFC6020, October 2010, 1200 . 1202 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1203 and A. Bierman, Ed., "Network Configuration Protocol 1204 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1205 . 1207 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1208 Application-Based Network Operations", RFC 7491, 1209 DOI 10.17487/RFC7491, March 2015, 1210 . 1212 12.2. Informative References 1214 [I-D.brockners-inband-oam-requirements] 1215 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1216 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1217 T., <>, P., and r. remy@barefootnetworks.com, 1218 "Requirements for In-situ OAM", draft-brockners-inband- 1219 oam-requirements-03 (work in progress), March 2017. 1221 [I-D.fioccola-ippm-multipoint-alt-mark] 1222 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 1223 "Multipoint Alternate Marking method for passive and 1224 hybrid performance monitoring", draft-fioccola-ippm- 1225 multipoint-alt-mark-04 (work in progress), June 2018. 1227 [I-D.ietf-i2rs-yang-network-topo] 1228 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1229 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1230 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1231 progress), December 2017. 1233 [I-D.ietf-ippm-alt-mark] 1234 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 1235 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1236 "Alternate Marking method for passive and hybrid 1237 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 1238 in progress), December 2017. 1240 [I-D.song-opsawg-dnp4iq] 1241 Song, H. and J. Gong, "Requirements for Interactive Query 1242 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 1243 (work in progress), June 2017. 1245 [I-D.vergara-ccamp-flexigrid-yang] 1246 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1247 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1248 Flexi-Grid Optical Networks", draft-vergara-ccamp- 1249 flexigrid-yang-06 (work in progress), January 2018. 1251 [I-D.zhang-ccamp-l1-topo-yang] 1252 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 1253 Liu, "A YANG Data Model for Optical Transport Network 1254 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 1255 progress), April 2017. 1257 Authors' Addresses 1259 Nicola Sambo 1260 Scuola Superiore Sant'Anna 1261 Via Moruzzi 1 1262 Pisa 56124 1263 Italy 1265 Email: nicola.sambo@sssup.it 1267 Piero Castoldi 1268 Scuola Superiore Sant'Anna 1269 Via Moruzzi 1 1270 Pisa 56124 1271 Italy 1273 Email: piero.castoldi@sssup.it 1274 Giuseppe Fioccola 1275 Huawei Technologies 1276 Riesstrasse, 25 1277 Munich 80992 1278 Germany 1280 Email: giuseppe.fioccola@huawei.com 1282 Filippo Cugini 1283 CNIT 1284 Via Moruzzi 1 1285 Pisa 56124 1286 Italy 1288 Email: filippo.cugini@cnit.it 1290 Haoyu Song 1291 Huawei 1292 2330 Central Expressway 1293 Santa Clara, CA 95050 1294 USA 1296 Email: haoyu.song@huawei.com 1298 Tianran Zhou 1299 Huawei 1300 156 Beiqing Road 1301 Beijing 100095 1302 China 1304 Email: zhoutianran@huawei.com