idnits 2.17.1 draft-sambo-netmod-yang-fsm-05.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 693 has weird spacing: '...lter-id uin...' == Line 699 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 (May 21, 2019) is 1800 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 (-09) exists of draft-ietf-ippm-multipoint-alt-mark-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: November 22, 2019 G. Fioccola 6 Huawei Technologies 7 F. Cugini 8 CNIT 9 H. Song 10 T. Zhou 11 Huawei 12 May 21, 2019 14 YANG model for finite state machine 15 draft-sambo-netmod-yang-fsm-05 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; iv) for re- 39 routing in optical networks. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on November 22, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions used in this document . . . . . . . . . . . . . . 4 77 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. Example of application . . . . . . . . . . . . . . . . . . . 4 79 4.1. Pre-programming resiliency schemes in EONs . . . . . . . 4 80 4.2. Deploying Dynamic Probes for Programmable Network 81 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.3. IP Performance Measurements on multipoint-to-multipoint 83 large Networks . . . . . . . . . . . . . . . . . . . . . 10 84 4.4. Re-routing in optical networks . . . . . . . . . . . . . 11 85 5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 12 86 6. Implementation of the pre-programming resiliency schemes in 87 EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 16 90 7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 16 91 7.3. Example of values for the YANG model . . . . . . . . . . 29 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 93 9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 30 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 98 12.2. Informative References . . . . . . . . . . . . . . . . . 31 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 101 1. Introduction 103 Networks are evolving toward more programmability, flexibility, and 104 multi-vendor interoperability. Multi-vendor interoperability can be 105 applied in the context of nodes, i.e. a node composed of components 106 provided by different vendors (named fully disaggregated white box) 107 is assembled under the same control system. This way, operators can 108 optimize costs and network performance without the need of being tied 109 to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based 110 on YANG data modeling language RFC6020 [RFC6020] is emerging as a 111 candidate Software Defined Networking (SDN) enabled protocol. First, 112 NETCONF supports both control and management functionalities, thus 113 permits high programmability. Then, YANG enables data modeling in a 114 vendor-neutral way. Some recent works have provided YANG models to 115 describe attributes of links (e.g., identification), nodes (e.g., 116 connectivity matrix), media channels, and transponders (e.g., 117 supported forward error correction - FEC) of networks 118 ([I-D.ietf-i2rs-yang-network-topo] [I-D.vergara-ccamp-flexigrid-yang] 119 [I-D.zhang-ccamp-l1-topo-yang]), also including optical technologies. 120 This document presents YANG models to describe events, operations, 121 and finite state machine of YANG-defined network elements. Such 122 models can be applied to several use cases. In the context of 123 elastic optical networks (EONs), the model enables a centralized 124 remote network controller (managed by a network operator) to instruct 125 a transponder controller about the actions to perform when certain 126 events (e.g., failures) occur. The actions to be taken and the 127 events can be re-programmed on the device. In general data networks, 128 programmable network telemetry is considered a killer SDN application 129 which can help applications gain unprecedented visibility to network 130 data plane. Instead of providing raw data, network devices can be 131 configured to filter and process data directly on the data plane and 132 only hand preprocessed data to the collector, in order to save data 133 bandwidth and reduce reaction delay ([I-D.song-opsawg-dnp4iq]) . Such 134 configurations can be programed as custom probes and dynamically 135 deployed into data plane devices. A probe in many cases can be 136 modeled as an FSM. Another use case is the monitoring of packet loss 137 and delay through a network clustering approach: in this case, each 138 FSM state is determined by a specific subdivision of the network in 139 Clusters ([I-D.ietf-ippm-multipoint-alt-mark]). Finally, a use case 140 is related to enable automatic local reconfiguration of a backup 141 route in optical networks. 143 2. Conventions used in this document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC2119 [RFC2119]. 149 3. Terminology 151 ABNO: Application-Based Network Operations 153 BER: Bit Error Rate 155 EON: Elastic Optical Network 157 FEC: Forward Error Correction 159 FSM: Finite State Machine 161 NETCONF: Network Configuration Protocol 163 OAM: Operation Administration and Maintenance 165 SDN: Software Defined Network 167 YANG: Yet Another Network Generator 169 DNP: Dynamic Network Probe 171 AMM: Alternate Marking Method 173 4. Example of application 175 4.1. Pre-programming resiliency schemes in EONs 177 EONs (optical networks based on flexible grid supporting circuits of 178 different bandwidth) are expected to employ flexible transponders, 179 i.e. transponders supporting multiple bit rates, multiple modulation 180 formats, and multiple codes. Such transponders permits the (re-) 181 configuration of the bit rate value based on traffic requirements, as 182 well as the configuration of the modulation format and code based on 183 the physical characteristics of a path (e.g., quadrature phase shift 184 keying is more robust than 16 quadrature amplitude modulation). This 185 way, transmission parameters can be (re-) configured based on 186 physical layer changes. The YANG model presented in this draft 187 enables to pre-program reconfiguration settings of data plane devices 188 in case of failures or physical layer degradations. In particular, 189 soft failures are assumed. Soft failures imply transmission 190 performance degradation, in turns a bit error rate (BER) increase, 191 e.g. due to the ageing of some network devices. Without loosing 192 generality, the ABNO architecture is assumed for the control and 193 management of EONs (RFC7491 [RFC7491]). Considering the state of the 194 art, when pre-FEC BER passes above a predefined threshold, it is 195 expected that an alarm is sent to the OAM Handler, which communicates 196 with the ABNO controller that may trigger an SDN controller (that 197 could be the Provisioning Manager of ABNO RFC7491 [RFC7491]) for 198 computing new transmission parameters. The involved ABNO modules are 199 shown in the simplified ABNO architecture of Fig. 1. Then, 200 transponders are reconfigured. When alarms related to several 201 connections impacted by the soft failure are generated, this 202 procedure may be particularly time consuming. The related workflow 203 for transponder reconfiguration is shown in Fig. 2. The proposed 204 model enables an SDN controller to instruct the transponder about 205 reconfiguration of new transmission parameters values if a soft 206 failure occurs. This can be done before the failure occurs (e.g., 207 during the connection instantiation phase or during the connection 208 service), so that data plane devices can promptly reconfigure 209 themselves without querying the SDN controller to trigger an on- 210 demand recovery. This is expected to speed up the recovery process 211 from soft failures. The related flow chart is shown in Fig. 3. The 212 whole mechanism is based on a finite state machine where each state 213 is associated to a specific configuration of transmission parameters 214 (e.g., modulation format). The transition from a state to another 215 state is triggered by specific events at the physical layer such as 216 the bit error rate above a threshold. The transition from a state to 217 another state implies a set of actions, including the change of 218 transmission parameters (e.g., modulation format), which are actually 219 suitable for the current condition at the physical layer. Moreover, 220 since transmission and receiver must be synchronized about the 221 transmission settings (modulation format and so no) for a proper 222 transmission, another action consists of this synchronization. Thus, 223 when the transponder at the receiver side decides to change its 224 transmission parameters based on the monitored BER, the remote 225 transponder at the transmitter side has to do the same state 226 transition. In particular, the transponder at the receiver side 227 sends a message to the transmitter to synchronize about the 228 transmission parameters to be adopted. This message can be sent over 229 a control channel. This way both the transmitter and receiver 230 operates with the same transmission parameters: e.g. the format, FEC, 231 and so on. No central controller is involved at this stage, only a 232 notification can be sent to the central controller to inform it about 233 the successful reconfiguration. 235 ___________ ___________ 236 | ABNO | | OAM | 237 |controller | ------ | Handler | 238 |___________| |___________| 240 | | 241 | | 242 | | 243 ____________ | 244 | SDN | | 245 | controller | | 246 |____________| | 247 | 248 | | 249 | | 250 | | 251 _____________________________ 252 | Client | 253 | network | 254 |_____________________________| 256 Figure 1: Assumed ABNO functional modules 258 _____________________ 259 | 1 | 260 |Sending alarm to the | 261 | OAM Handler | 262 | | 263 |_____________________| 264 | 265 | 266 | 267 _____________________ 268 | 2 | 269 | Trigger | 270 | SDN Controller | 271 | | 272 |_____________________| 273 | 274 | 275 | 276 _____________________ 277 | 3 | 278 | Computation of | 279 | new transmission | 280 | parameters | 281 |_____________________| 282 | 283 | 284 | 285 _____________________ 286 | 4 | 287 | Data plane | 288 | reconfiguration | 289 | | 290 |_____________________| 292 Figure 2: Flow chart of the expected state-of-the-art approach 293 _______________________ 294 | 1 | 295 | Instructing the local | 296 | controller of | 297 | data plane devices | 298 |_______________________| 299 | 300 | 301 | 302 _______________________ 303 | 2 | 304 | Local reconfiguration | 305 | upon failure | 306 | detection | 307 |_______________________| 308 | 309 | 310 | 311 _______________________ 312 | 3 | 313 | | 314 | notification | 315 | | 316 |_______________________| 318 Figure 3: Flow chart of the approach exploiting YANG models in this 319 draft 321 4.2. Deploying Dynamic Probes for Programmable Network Telemetry 323 In the past, network data analytics was considered a separate 324 function from networks. They consume raw data extracted from 325 networks through piecemeal protocols and interfaces. With the advent 326 of user programmable data plane, we expect a paradigm shift that 327 makes the data plane be an active component of the data telemetry and 328 analytics solution. The programmable in-network data preprocessing 329 is efficient and flexible to offload some light-weight data 330 processing through dynamic data plane programming or configuration. 331 A universal network data analytics platform built on top of this 332 enables a tight and agile network control and OAM feedback loop. A 333 proposed dynamic network telemetry system architecture is illustrated 334 in Fig.4. 336 An application translates its data requirements into a set of Dynamic 337 Network Probes (DNP) targeting a subset of data plane devices. After 338 the probes are deployed, each probe conducts its corresponding in- 339 network data preprocessing and feeds the preprocessed data to the 340 collector. The collector finishes the data post-processing and 341 presents the results to the data-requesting application. 343 +-------------------------------------+ 344 | network telemetry applications | 345 +-------------------------------------+ 346 ^ | 347 | V 348 | +--------------------+ 349 | | DNP compile/config | 350 | +--------------------+ 351 | | 352 | V 353 +---------------+ +--------------------+ 354 |data collection| | Probe deployment | 355 +---------------+ +--------------------+ 356 ^ ^ ^ | | | 357 | | | V V V 358 +--------------------------------------+ 359 | network data plane devices | 360 | (in-network data preprocessing) | 361 +--------------------------------------+ 363 Figure 4: Deploy dynamic network probes using YANG FSM models 365 Many DNPs can be modeled as FSM which are configured to capture 366 specific events. Here FSMs essentially preprocess the raw stream 367 data and only report the necessary data to subscribing applications. 369 For example, a congestion control application needs to monitor the 370 router buffer occupancy. Instead of polling the buffer depth 371 periodically, it is only interested in the real-time events when the 372 buffer depth crosses a low and a high threshold. We can install a 373 probe to achieve this data plane function and the probe can be 374 modeled as a three-state FSM. Each state represents a buffer region: 375 below the low threshold, above the high threshold, and in between the 376 two thresholds. A possible state transition is checked against the 377 buffer depth for each incoming and outgoing packet. Whenever a state 378 transition happens, an event is generated and reported to the 379 application. This approach significantly reduces the amount of data 380 sent to the application and also allows a timely event notification. 382 For another example, an application would like to monitor the delay 383 experienced by a flow. The packet delay on its forwarding path can 384 be acquired by using iOAM [I-D.brockners-inband-oam-requirements]. 385 However, the application only needs to know that N consecutive flow 386 packets experience a delay longer than T. Instead of forwarding the 387 raw delay data to the application, a probe can be deployed to detect 388 the event. Similarly, the probe can be modeled as an FSM. 390 4.3. IP Performance Measurements on multipoint-to-multipoint large 391 Networks 393 Networks offer rich sets of network performance measurement data, but 394 traditional approaches run into limitations. One reason for this is 395 the fact that in many cases, the bottleneck is the generation and 396 export of the data and the amount of data that can be reasonably 397 collected from the network runs into bandwidth and processing 398 constraints in the network itself. In addition, management tasks 399 related to determining and configuring which data to generate lead to 400 significant deployment challenges. 402 In order to address these issues, an SDN controller application 403 orchestrates network performance measurements tasks across the 404 network to allow an optimized monitoring. In fact the IP Performance 405 Measurement SDN Controller Application in Figure 5 can calibrate how 406 deep can be obtained monitoring data from the network by configuring 407 measurement points roughly or meticulously. This can be established 408 by using the feedback mechanism reported in Figure 5. 410 For instance, the SDN Controller can configure initially an end to 411 end monitoring between ingress points and egress points of the 412 network. If the network does not experiment issues, this approximate 413 monitoring is good enough and is very cheap in terms of network 414 resources. But, in case of problems, the SDN Controller becomes 415 aware of the issues from this approximate monitoring and, in order to 416 localize the portion of the network that has issues, configures the 417 measurement points more exhaustively. So a new detailed monitoring 418 is performed. After the detection and resolution of the problem the 419 initial approximate monitoring can be used again. This idea is 420 general and can be applied to different performance measurements 421 techniques both active and passive (and hybrid). 423 +--------------------------------------+ 424 | IP Performance Measurement | 425 | SDN Controller Application | 426 +--------------------------------------+ 427 ^ ^ ^ | | | 428 | | | v v v 429 +--------------------------------------+ 430 | Multipoint Network | 431 +--------------------------------------+ 433 Figure 5: Feedback mechanism on multipoint-to-multipoint large 434 Networks 436 One of the most efficient methodology to perform packet, loss delay 437 and jitter measurements both in an IP and Overlay Networks is the 438 Alternate Marking method, as presented in RFC8321 [RFC8321] and 439 [I-D.ietf-ippm-multipoint-alt-mark]. 441 This technique can be applied to point-to-point flows but also to 442 multipoint.to-multipoint flows (see RFC8321 [RFC8321] and 443 [I-D.ietf-ippm-multipoint-alt-mark]). The Alternate Marking method 444 creates batches of packets by alternating the value of 1 or 2 bits of 445 the packet header. These batches of packets are unambiguously 446 recognized over the network and the comparison of packet counters 447 permits the packet loss calculation. The same idea can be applied 448 for delay measurement by selecting special packets with a marking bit 449 dedicated for delay measurements. This method needs two counters 450 each marking period for each flow under monitor. For this reason by 451 considering n measurement points and n monitored flows, the order of 452 magnitude of the packet counters for each time interval is n*n*2 (1 453 per color). 455 Multipoint Alternate Marking, described in 456 [I-D.ietf-ippm-multipoint-alt-mark], aims to reduce this value and 457 makes the performance monitoring more flexible in case a detailed 458 analysis is not needed. 460 It is possible to monitor a Multipoint Network without examining in 461 depth by using the Network Clustering (subnetworks that are portions 462 of the entire network that preserve the same property of the entire 463 network). So in case there is packet loss or the delay is too high 464 the filtering criteria could be specified more in order to perform a 465 per flow detailed analysis, as described in RFC8321 [RFC8321]. 467 An application of the multipoint performance monitoring can be done 468 by using FSM (each state is a composition of clusters) and feedback 469 mechanism where the SDN Controller is the brain of the network and 470 can manage flow control to the switches and routers and, in the same 471 way, can calibrate the performance measurements depending on the 472 necessity. 474 4.4. Re-routing in optical networks 476 FSM can be also applied for rerouting purposes as dynamic restoration 477 in optical networks. In such a use case all the nodes along the 478 backup route of a media channel should hold a FSM indicating the 479 reconfigurations to be performed in case that media channel is 480 rerouted along the backup path. Note that resources along the backup 481 route are not reserved neither configured during a normal operation 482 of the network as instead it happens for protection. 484 The proposed approach aims at achieving a sort of hybrid centralized/ 485 distributed rerouting solution applicable to all the networks 486 controlled with NETCONF. More specifically, the decision of the 487 backup route is taken centrally by the SDN controller, but it is 488 acted in a distributed way through FSM when a problem appears. 490 In particular, the transmitter, the receiver, and the ROADMs along 491 the backup route have installed in their agent a FSM including a "re- 492 routing" state, associated to a specific media channel. For the 493 transmitter and receiver, this state is associated to the 494 transmission parameters of the backup media channel: e.g., modulation 495 format, central frequency, FEC, and so on. Regarding the ROADMs, the 496 "re-routing" state is associated to the cross connections of the 497 backup route. 499 When a link failure occurs (e.g., fiber cut), the receiver reveals a 500 loss of light, which triggers the transition to the "re-routing" 501 state. Thus, the receiver can set itself to the new transmission 502 parameters. Moreover, similarly to the message sent over a control 503 channel to the transmitter in Sec. 4.1, the receiver sends a message 504 to the transmitter and the backup Reconfigurable Add-Drop Multiplexer 505 (ROADMs). The task of this message is to simply trigger a state 506 transition to the "re-routing" state so that each backup ROADM and 507 the transmitter can apply the proper reconfigurations. This way, the 508 SDN controller is not interrogated during the failure and the 509 recovery can be speeded up. After reconfigurations, the SDN 510 controller can be notified and the SDN controller can tear down the 511 primary path. Backup routes can be reprogrammed based on the network 512 states evolutions (e.g., link and spectrum occupancy). 514 5. YANG for finite state machine (FSM) 516 This model defines a list of states and transitions to describe a 517 generic finite state machine (FSM). The related code and tree are 518 shown in the Appendix. 520 : it defines the current state of the FSM. 521 : this element defines the FSM as follows. 522 : this list defines all the FSM states. 523 : this leaf attribute of defines the 524 identifier of the state 525 : this leaf attribute of defines the 526 name of the state 527 : this leaf is a "string" describing the 528 state 529 : this attribute defines a list of 530 transitions to other states in the FSM. 531 : this attribute defines the name of a 532 transition 533 : this attribute defines the type of the 534 transition from a pool of possible transition 535 types predefined inside the YANG model. 536 Together with the attribute, it 537 uniquely identifies the transition. 538 : this optional attribute is a 539 "string" describing the transition 540 : this leaf is a list of input 541 parameters related to the transition. This 542 attribute enables to further express a 543 transition: as an example, if a transition can 544 be triggered by a parameter (e.g., a monitored 545 performance parameter) exceeding a threshold 546 (as in Sec. 5), an element of the list defines 547 this threshold. Thus, if the parameter is 548 outside the threshold, the transition is 549 taken, otherwise not. 550 : this leaf of defines 551 a filter parameter. 552 : this leaf of 553 define the identifier number associated 554 with the attribute. 555 : this attribute defines a list of 556 actions to take during the transition. 557 : this attribute is the list of 558 actions 559 : this leaf of 560 defines the identifier number of 561 an action. 562 : this leaf of 563 defines the type of an action. 564 : this leaf defines 565 (differently from 566 detailed below) an action that 567 has to be directly executed. 568 : this attribute 569 recalls an RPC encapsulating 570 the effective task (action) 571 to be executed by the 572 hardware. If more actions 573 (e.g., "A" and "B"), defined 574 in the list, have 575 to be executed, these 576 actions can be executed 577 sequentially according to 578 the attribute 579 detailed below. Thus, by 580 referring to the tree of the 581 Appendix, when an action 582 ("A") is executed, the 583 attribute will 584 bring to another action 585 ("B"). If more actions have 586 to be executed in parallel 587 (e.g., "A" & "B"), not 588 sequentially, an element of 589 the list should be 590 defined to express an action 591 (e.g., "A&B") consisting of 592 more actions to be executed 593 in parallel. 594 : this 595 attribute defines the 596 identification number of a 597 next action that has to be 598 taken. The 599 can assume a NULL value. 600 : this leaf enables a 601 check ("true" or "false") to be 602 verified before executing the 603 action. Based on the check, the 604 proper attributes and 605 are considered. 606 : this leaf 607 of defines 608 the condition to be 609 verified before executing 610 the action. 611 : this leaf of 612 defines a 613 result of the check 614 associated to 615 . Proper 616 and 617 618 attributes are associated 619 with this result of the 620 check. 621 : this leaf of 622 defines a 623 result of the check 624 associated to 625 . Proper 626 and 627 628 attributes are associated 629 with this result of the 630 check. 631 : this attribute defines 632 the next state of FSM when an action is 633 executed. 635 6. Implementation of the pre-programming resiliency schemes in EONs 637 These presented model can be used to enable a centralized network 638 controller, managed by a network operator, to instruct data plane 639 hardware on its reconfiguration if some events, such as a failure or 640 physical layer degradation, occur. As an example, an optical signal 641 impacted by a soft failure (i.e., a physical layer degradation 642 inducing a pre forward error correction bit error rate increase - 643 pre-FEC) can be maintained by adapting the FEC of the signal itself. 644 This action to be taken and, more in general operations to be 645 executed depending on critical events, can be (re-) programmed on the 646 transponder by (re-) sending a NETCONF message to the 647 device controller including a FSM defined by the YANG model. Such a 648 system has the main goal to speed up the reaction of the network to 649 certain events/faults and to alleviate the workload of the 650 centralized controller. The speed up derives from the fact that the 651 centralized controller is able to pre-compute and pre-configure on 652 the network devices the actions to take when an event occurs taking 653 into account a global view and knowledge of the network. In this 654 way, the device is already aware of the actions to be locally applied 655 to reconfigure a connection, avoiding to inform the controller and to 656 wait for the response indicating what to do. Consequently, part of 657 the workload is also removed from the centralized controller. When 658 the reaction is successfully completed in the data plane, the 659 centralized controller can be notified about the faults and the taken 660 action. A flexible transponder supporting two FEC types, 7% and 20%, 661 is considered. A two-states FSM is also assumed. The states have 662 attribute set to "Steady" and "Fec-Baud-Adapt", respectively. 663 In the "Steady" state, the signal is in a healthy condition, adopting 664 a 7% FEC, with a pre-FEC BER below an assigned threshold of 9 x 10-4. 665 A transition from this state can be triggered by the event with 666 =BER_CHANGE and =9 x 10-4, thus expressing a 667 change of the pre-FEC BER above the threshold. In case the pre-FEC 668 BER exceeds 9 x 10-4 due to a soft failure, the state machine evolves 669 to the "Fec-Baud-Adapt" state and an adaptation to a more robust FEC 670 of 20% (executed by the attribute ) is performed. The 671 system can return to the "Steady" state if the pre-FEC BER goes below 672 another pre-defined threshold and the FEC is reconfigured to 7%. 674 7. Appendix 676 This appendix reports the YANG models code and the related tree. 678 7.1. YANG model for FSM - Tree 680 module: ietf-fsm 681 +--rw current-state? leafref 682 +--rw states 683 +--rw state [id] 684 +--rw id state-id-type 685 +--rw description? string 686 +--rw transitions 687 +--rw transition [name type] 688 +--rw name string 689 +--rw type transition-type 690 +--rw description? string 691 +--rw filters 692 | +--rw filter [filter-id] 693 | +--rw filter-id uint32 694 +--rw actions 695 +--rw action [id] 696 +--rw id transition-id-type 697 +--rw type enumeration 698 +--rw conditional 699 | +--rw statement string 700 | +--rw true 701 | | +--rw execute 702 | | +--rw next-action? transition-id-type 703 | | +--rw next-state? leafref 704 | +--rw false 705 | +--rw execute 706 | +--rw next-action? transition-id-type 707 | +--rw next-state? leafref 708 +--rw simple 709 +--rw execute 710 +--rw next-action? transition-id-type 711 +--rw next-state? leafref 713 7.2. YANG model for FSM - Code 715 file "ietf-fsm@2016-03-15.yang" 717 module ietf-fsm { 719 namespace "http://sssup.it/fsm"; 720 prefix fsm; 722 identity TRANSITION { 724 description "Base for all types of event"; 726 } 728 identity ON_CHANGE { 730 base TRANSITION; 732 description 734 "The event when the database changes."; 736 } 738 // typedef statements 740 typedef transition-type { 742 description "it defines the type of transition (event)"; 744 type identityref { 746 base TRANSITION; 748 } 750 } 752 typedef transition-id-type { 753 description "it defines the id of the transition (event)"; 755 type uint32; 757 } 759 // grouping statements 761 grouping action-block { 763 description "it defines the action to perform when a transition 764 occurs"; 766 leaf id { 768 description "it refers to the id of the transition"; 769 type transition-id-type; 771 } 773 leaf type { 775 description "it defines if the action has to be simply executed or if 776 a conditional statement has to be checked before execution"; 778 type enumeration { 780 enum "CONDITIONAL_OP" { 781 description "it defines the type CONDITIONAL OPERATION to check a 782 statement before execution"; 783 } 785 enum "SIMPLE_OP" { 786 description "it defines the type SIMPLE OPERATION: i.e., an operation 787 to be directly executed; 788 } 790 } 792 mandatory true; 794 } 796 grouping execution-top { 797 description "it defines the execution attribute"; 799 anyxml execute { 801 description "Represent the action to perform"; 803 } 805 leaf next-action { 807 type transition-id-type; 809 description "the id of the next action to execute"; 811 } 813 } 815 container conditional { 817 description "it defines the container CONDITIONAL"; 819 when "../type = 'CONDITIONAL_OP'"; 821 leaf statement { 823 type string; 825 mandatory true; 827 description 829 "The statement to be evaluated before execution. 831 E.g. if a=b"; 833 } 835 container true { 837 description "it is referred to the result TRUE of a conditional 838 statement"; 840 uses execution-top; 842 } 844 container false { 846 description "it is referred to the result FALSE of a conditional 847 statement "; 849 uses execution-top; 851 } 853 } 855 container simple { 856 description "Simple execution of an action without checking any 857 condition"; 859 when "../type = 'SIMPLE_OP'"; 861 uses execution-top; 863 } 865 } 867 grouping action-top { 869 description "it defines the grouping of action"; 871 list action { 873 description "it defines the list of actions"; 875 key "id"; 877 ordered-by user; 879 uses action-block; 881 } 883 } 885 grouping on-change { 887 description 889 "Event occuring when a modification of one or more 891 objects occurs"; 893 container filters { 895 description 897 "This container contains a list of configurable filters 899 that can be applied to subscriptions. This facilitates 901 the reuse of complex filters once defined."; 903 list filter { 905 key "filter-id"; 907 description 909 "A list of configurable filters that can be applied to 911 subscriptions."; 913 leaf filter-id { 915 type uint32; 917 description 919 "An identifier to differentiate between filters."; 921 } 923 } 925 } 927 } 929 grouping transition-top { 931 description "it defines the grouping transition"; 933 leaf name { 935 description "it defines the transition name"; 937 type string; 939 mandatory true; 941 } 943 leaf type { 945 description "it defines the transition type"; 947 type transition-type; 949 mandatory true; 951 } 953 leaf description { 955 description "it describes the transition "; 957 type string; 959 } 961 // list of all possible events 963 uses on-change { 964 when "type = 'ON_CHANGE'"; 966 } 968 container actions { 970 description "it defines the container action"; 972 uses action-top; 974 } 976 } 978 grouping transitions-top { 980 description "it defines the grouping transition"; 982 container transitions { 984 description "it defines the container transitions"; 986 list transition { 988 description "it defines the list of transitions"; 990 key "name type"; 992 uses transition-top; 994 } 996 } 998 } 1000 // data definition statements 1001 uses transitions-top; 1003 // extension statements 1005 // feature statements 1007 // augment statements 1009 organization 1011 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 1013 contact 1015 " Editor: Matteo Dallaglio 1017 1019 "; 1021 description 1023 "This module contains a YANG definitions of a generic finite state 1024 machine."; 1026 revision 2016-03-15 { 1028 description "Initial Revision."; 1030 reference 1032 "RFC xxxx:"; 1034 } 1036 // identity statements 1038 // typedef statements 1040 typedef state-id-type { 1042 description "it defines the id type of the states"; 1044 type uint32; 1046 } 1048 // grouping statements 1050 grouping state-top { 1052 description "it defines the grouping state"; 1054 leaf id { 1056 description "it defines the id of a transition"; 1058 type state-id-type; 1060 } 1062 leaf description { 1064 description "it describes a transition"; 1066 type string; 1068 } 1070 grouping next-state-top { 1072 description "it defines the grouping for the next state"; 1074 leaf next-state { 1076 description "it defines the next state"; 1078 type leafref { 1080 description "it refers to its id"; 1082 path "../../../../../../../../../states/state/id"; 1084 } 1086 description "Id of the next state"; 1088 } 1090 } 1092 uses transitions-top { 1094 augment "transitions/transition/actions/action/conditional/true" { 1096 uses next-state-top; 1098 } 1100 augment "transitions/transition/actions/action/conditional/false" { 1101 uses next-state-top; 1103 } 1105 augment "transitions/transition/actions/action/simple" { 1107 //uses next-state-top; 1109 leaf next-state { 1111 description "it defines the next state"; 1113 type leafref { 1115 description "it refers to its id"; 1116 path "../../../../../../../../states/state/id"; 1118 } 1120 description "Id of the next state"; 1122 } 1124 } 1126 } 1128 } 1130 grouping states-top { 1132 description "it defines the grouping states"; 1134 leaf current-state { 1136 description "it defines the current state"; 1138 type leafref { 1140 description "it refers to its id"; 1141 path "../states/state/id"; 1143 } 1145 } 1147 container states { 1148 description "it defines the container states"; 1150 list state { 1152 description "it defines the list of states"; 1154 key "id"; 1156 uses state-top; 1158 } 1160 } 1162 } 1164 // data definition statements 1166 uses states-top; 1168 // extension statements 1170 // feature statements 1171 // augment statements. 1173 // rpc statements 1175 }//module fsm 1177 1179 7.3. Example of values for the YANG model 1180 FIELD NAME | YANG DATA TYPE | VALUE 1181 _________________|_____________________|________________________ 1182 Current State | leafref | "an existing state id 1183 | | in the FSM" 1184 | | 1185 State | | 1186 id | uint32 | 1 1187 name | string | Steady 1188 description | string | "whatever string" 1189 | | 1190 transition | | 1191 name | string | "whatever string" 1192 type | enum | BER_CHANGE 1193 description | string | "whatever string" 1194 | | 1195 filter | | 1196 filter-id | uint32 | 2 1197 filter-type | anyxml or xpath | BER>0.0009 1198 | | 1199 action | | 1200 id | uint32 | 3 1201 type | enum | SIMPLE 1202 statement | string | "whatever string" 1203 execute | anyxml | "this recalls an RPC 1204 | | where the FEC value 1205 | | is expressed" 1206 next-operation | uint32 | NULL 1207 next-state | leafref | "an existing state id 1208 | | in the FSM" 1210 8. Acknowledgements 1212 This work has been partially supported by the European Commission 1213 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 1214 dynamic networks using a Holistic cross-layEr, Self-configurable 1215 Truly flexible approach, grant agreement no: H2020-645360) project. 1216 The views expressed here are those of the authors only. The European 1217 Commission is not liable for any use that may be made of the 1218 information in this document. 1220 9. Other Contributors 1222 Matteo Dallaglio (Scuola Superiore Sant'Anna), Andrea Di Giglio 1223 (Telecom Italia), Giacomo Bernini (Nextworks). 1225 10. Security Considerations 1227 TBD 1229 11. IANA Considerations 1231 TBD 1233 12. References 1235 12.1. Normative References 1237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1238 Requirement Levels", BCP 14, RFC 2119, 1239 DOI 10.17487/RFC2119, March 1997, 1240 . 1242 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1243 the Network Configuration Protocol (NETCONF)", RFC 6020, 1244 DOI 10.17487/RFC6020, October 2010, 1245 . 1247 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1248 and A. Bierman, Ed., "Network Configuration Protocol 1249 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1250 . 1252 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1253 Application-Based Network Operations", RFC 7491, 1254 DOI 10.17487/RFC7491, March 2015, 1255 . 1257 12.2. Informative References 1259 [I-D.brockners-inband-oam-requirements] 1260 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1261 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1262 T., Lapukhov, P., and r. remy@barefootnetworks.com, 1263 "Requirements for In-situ OAM", draft-brockners-inband- 1264 oam-requirements-03 (work in progress), March 2017. 1266 [I-D.ietf-i2rs-yang-network-topo] 1267 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1268 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1269 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1270 progress), December 2017. 1272 [I-D.ietf-ippm-multipoint-alt-mark] 1273 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 1274 "Multipoint Alternate Marking method for passive and 1275 hybrid performance monitoring", draft-ietf-ippm- 1276 multipoint-alt-mark-01 (work in progress), March 2019. 1278 [I-D.song-opsawg-dnp4iq] 1279 Song, H. and J. Gong, "Requirements for Interactive Query 1280 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 1281 (work in progress), June 2017. 1283 [I-D.vergara-ccamp-flexigrid-yang] 1284 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1285 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1286 Flexi-Grid Optical Networks", draft-vergara-ccamp- 1287 flexigrid-yang-06 (work in progress), January 2018. 1289 [I-D.zhang-ccamp-l1-topo-yang] 1290 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 1291 Liu, "A YANG Data Model for Optical Transport Network 1292 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 1293 progress), April 2017. 1295 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 1296 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1297 "Alternate-Marking Method for Passive and Hybrid 1298 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 1299 January 2018, . 1301 Authors' Addresses 1303 Nicola Sambo 1304 Scuola Superiore Sant'Anna 1305 Via Moruzzi 1 1306 Pisa 56124 1307 Italy 1309 Email: nicola.sambo@sssup.it 1311 Piero Castoldi 1312 Scuola Superiore Sant'Anna 1313 Via Moruzzi 1 1314 Pisa 56124 1315 Italy 1317 Email: piero.castoldi@sssup.it 1318 Giuseppe Fioccola 1319 Huawei Technologies 1320 Riesstrasse, 25 1321 Munich 80992 1322 Germany 1324 Email: giuseppe.fioccola@huawei.com 1326 Filippo Cugini 1327 CNIT 1328 Via Moruzzi 1 1329 Pisa 56124 1330 Italy 1332 Email: filippo.cugini@cnit.it 1334 Haoyu Song 1335 Huawei 1336 2330 Central Expressway 1337 Santa Clara, CA 95050 1338 USA 1340 Email: haoyu.song@huawei.com 1342 Tianran Zhou 1343 Huawei 1344 156 Beiqing Road 1345 Beijing 100095 1346 China 1348 Email: zhoutianran@huawei.com