idnits 2.17.00 (12 Aug 2021) /tmp/idnits15206/draft-sambo-ccamp-yang-fsm-transponder-reconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 81 characters in excess of 72. ** The abstract seems to contain references ([I-D.sambo-netmod-yang-fsm]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2018) is 1538 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: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: A later version (-05) exists of draft-sambo-netmod-yang-fsm-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group N. Sambo 3 Internet-Draft P. Castoldi 4 Intended status: Standards Track A. Sgambelluri 5 Expires: September 6, 2018 Scuola Superiore Sant'Anna 6 G. Fioccola 7 Telecom Italia 8 F. Cugini 9 CNIT 10 D. Ceccarelli 11 Ericsson 12 H. Song 13 T. Zhou 14 Huawei 15 March 5, 2018 17 Finite state machine YANG model augmentation for Transponder 18 Reconfiguration 19 draft-sambo-ccamp-yang-fsm-transponder-reconf-00 21 Abstract 23 YANG enables to compile a set of consistent vendor-neutral data 24 models for optical networks and components based on actual 25 operational needs emerging from heterogeneous use cases. A YANG 26 model has been also proposed to describe finite state machine to 27 program network elements that are modeled with YANG. This document 28 augments the more generic YANG model for finite state machine 29 [I-D.sambo-netmod-yang-fsm], in order to pre-instruct an optical 30 transponder on the actions to be performed (e.g., code adaptation) in 31 case some events, such as physical layer degradations, occur. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions used in this document . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Flexible Transponders . . . . . . . . . . . . . . . . . . . . 4 71 5. Augmenting the FSM YANG model for transponder reconfiguration 7 72 6. Code of the YANG model for transponder reconfiguration . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Networks are evolving toward more programmability, flexibility, and 84 multi-vendor interoperability. Multi-vendor interoperability can be 85 applied in the context of nodes, i.e. a node composed of components 86 provided by different vendors (named fully disaggregated white box) 87 is assembled under the same control system. This way, operators can 88 optimize costs and network performance without the need of being tied 89 to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based 90 on YANG data modeling language RFC6020 [RFC6020] is emerging as a 91 candidate Software Defined Networking (SDN) enabled protocol. First, 92 NETCONF supports both control and management functionalities, thus 93 permits high programmability. Then, YANG enables data modeling in a 94 vendor-neutral way. Some recent works have provided YANG models to 95 describe attributes of links (e.g., identification), nodes (e.g., 96 connectivity matrix), media channels, and transponders (e.g., 97 supported forward error correction - FEC) of networks 98 ([I-D.ietf-i2rs-yang-network-topo] [I-D.vergara-ccamp-flexigrid-yang] 99 [I-D.zhang-ccamp-l1-topo-yang]), also including optical technologies. 100 A YANG model [I-D.sambo-netmod-yang-fsm] has been also proposed to 101 describe finite state machines (FSMs) in order to program actions 102 based on conditions and events in YANG-described devices. Such draft 103 mainly refers to elastic optical networks (EONs), i.e. optical 104 networks based on flexible grid where circuits with different 105 bandwidth requirements are switched. EONs are expected to employ 106 flexible transponders, i.e. transponders supporting multiple bit 107 rates, multiple modulation formats, and multiple codes. Such 108 transponders permits the (re-) configuration of the bit rate value 109 based on traffic requirements, as well as the configuration of the 110 modulation format and code based on the physical characteristics of a 111 path (e.g., quadrature phase shift keying is more robust than 16 112 quadrature amplitude modulation). This document augments the YANG 113 model for FSM [I-D.sambo-netmod-yang-fsm] to be applied in 114 programming reconfiguration of transponders in EONs based on physical 115 layer conditions. In particular, the model enables a centralized 116 remote network controller (managed by a network operator) to instruct 117 a transponder controller about the actions to perform when certain 118 events (e.g., failures) occur. The actions to be taken and the 119 events can be re-programmed on the device. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC2119 [RFC2119]. 127 3. Terminology 129 ABNO: Application-Based Network Operations 131 BER: Bit Error Rate 133 EON: Elastic Optical Network 135 FEC: Forward Error Correction 137 FSM: Finite State Machine 139 NETCONF: Network Configuration Protocol 141 OAM: Operation Administration and Maintenance 143 SDN: Software Defined Network 145 YANG: Yet Another Network Generator 147 4. Flexible Transponders 149 Flexible transponders enable several parameters' configurations, 150 through the support of multiple modulation formats, baud rate, and 151 forward error correction (FEC) schemes. This way, transmission 152 parameters can be (re-)configured based on the physical layer 153 conditions. The YANG model presented in this draft enables to pre- 154 program reconfiguration settings of data plane devices in case of 155 changes in the physical layer conditions. In particular, soft 156 failures can be assumed. Soft failures imply transmission 157 performance degradation, in turns a bit error rate (BER) increase, 158 e.g. due to the ageing of some network devices. Without loosing 159 generality, the ABNO architecture is assumed for the control and 160 management of EONs (RFC7491 [RFC7491]). Considering the state of the 161 art, when pre-FEC BER passes above a predefined threshold, it is 162 expected that an alarm is sent to the OAM Handler, which communicates 163 with the ABNO controller that may trigger an SDN controller (that 164 could be the Provisioning Manager of ABNO RFC7491 [RFC7491]) for 165 computing new transmission parameters. The involved ABNO modules are 166 shown in the simplified ABNO architecture of Fig. 1. Then, 167 transponders are reconfigured. When alarms related to several 168 connections impacted by the soft failure are generated, this 169 procedure may be particularly time consuming. The related workflow 170 for transponder reconfiguration is shown in Fig. 2. The proposed 171 model enables an SDN controller to instruct the transponder about 172 reconfiguration of new transmission parameters values if a soft 173 failure occurs. This can be done before the failure occurs (e.g., 174 during the connection instantiation phase or during the connection 175 service), so that data plane devices can promptly reconfigure 176 themselves without querying the SDN controller to trigger an on- 177 demand recovery. This is expected to speed up the recovery process 178 from soft failures. The related flow chart is shown in Fig. 3. 180 ___________ ___________ 181 | ABNO | | OAM | 182 |controller | ------ | Handler | 183 |___________| |___________| 185 | | 186 | | 187 | | 188 ____________ | 189 | SDN | | 190 | controller | | 191 |____________| | 192 | 193 | | 194 | | 195 | | 196 _____________________________ 197 | Client | 198 | network | 199 |_____________________________| 201 Figure 1: Assumed ABNO functional modules 203 _____________________ 204 | 1 | 205 |Sending alarm to the | 206 | OAM Handler | 207 | | 208 |_____________________| 209 | 210 | 211 | 212 _____________________ 213 | 2 | 214 | Trigger | 215 | SDN Controller | 216 | | 217 |_____________________| 218 | 219 | 220 | 221 _____________________ 222 | 3 | 223 | Computation of | 224 | new transmission | 225 | parameters | 226 |_____________________| 227 | 228 | 229 | 230 _____________________ 231 | 4 | 232 | Data plane | 233 | reconfiguration | 234 | | 235 |_____________________| 237 Figure 2: Flow chart of the expected state-of-the-art approach 238 _______________________ 239 | 1 | 240 | Instructing the local | 241 | controller of | 242 | data plane devices | 243 |_______________________| 244 | 245 | 246 | 247 _______________________ 248 | 2 | 249 | Local reconfiguration | 250 | upon failure | 251 | detection | 252 |_______________________| 253 | 254 | 255 | 256 _______________________ 257 | 3 | 258 | | 259 | notification | 260 | | 261 |_______________________| 263 Figure 3: Flow chart of the approach exploiting YANG models in this 264 draft 266 5. Augmenting the FSM YANG model for transponder reconfiguration 268 This section augments the FSM YANG model presented in 269 [I-D.sambo-netmod-yang-fsm] to address the specific use case of 270 transponder reconfiguration triggered by physical layer changes. The 271 FSM model is based on the following main attributes: states, 272 transitions (corresponding to some specific event), and actions. In 273 particular, more specifically with respect to 274 [I-D.sambo-netmod-yang-fsm], in such a use case, a state corresponds 275 to a specific configuration of transponder transmission parameters: 276 e.g., given by the modulation format and the FEC. A transition is 277 triggered when the pre-FEC BER (or another parameter such as the 278 OSNR) is below or above a threshold. To this purpose, with respect 279 to [I-D.sambo-netmod-yang-fsm], the attribute is expressed 280 by the definition of thresholds and operators. The action mainly 281 consists of the change of modulation format and/or FEC. 283 The Tree of the YANG model for transponder reconfiguration 284 (augmentation of the YANG model for FSM) is reported below. 286 module: ietf-treconf 287 +--rw current-state? leafref 288 +--rw states 289 +--rw state [id] 290 +--rw id state-id-type 291 +--rw description? string 292 +--rw transitions 293 +--rw transition [name] 294 +--rw name string 295 +--rw description? string 296 +--rw threshold-parameter? decimal64 297 +--rw threshold-operator? string 298 +--rw transition-action 299 +--rw action [id] 300 +--rw id transition-id-type 301 +--rw type enumeration 302 +--rw simple 303 +--rw execute 304 +--rw next-action? transition-id-type 305 +--rw next-state? Leafref 307 More specifically, the attribute is a list defining all the 308 transponder states. is an attribute defining a list of 309 events that may trigger the change of transponder state (e.g., BER 310 change). defines a threshold value, while 311 defines the operator <,>,<=,>=. Thus, if the 312 event BER>TH has to be modeled, the attribute 313 has to be set to "TH" while to ">". 314 defines a list of actions to take during the transition (e.g. change 315 of modulation format) defines the next transponder state 316 when an action is executed (e.g., new modulation format and FEC). 318 For more details about the other model attributes, the reader can 319 refer to [I-D.sambo-netmod-yang-fsm]. 321 In such a use case, we assume that an event (e.g., BER>TH) is 322 revealed by the digital signal processing (DSP) of the receiver. 323 Once the event is recognized, the modulation format and/or the FEC 324 have to be changed, both at the receiver and the transmitter. Thus, 325 the list of actions to be executed includes the change of 326 transmission parameters at the receiver side, as well as the 327 generation of a message sent by the receiver controller to the 328 transmitter controller to synchronize about the transmission 329 parameters to be adopted. This message can be sent over a control 330 channel between transmitter and receiver. Such transponder 331 reconfiguration based on FSM has been successfully demonstrated by 332 integrating control and data planes in a lab and field trials. 334 6. Code of the YANG model for transponder reconfiguration 336 The related code is reported below. 338 file "ietf-treconf@2016-03-15.yang" 340 module ietf-treconf { 341 namespace "http://sssup.it/fsm"; 342 prefix fsm; 344 organization 345 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 347 contact 348 " Editor: Matteo Dallaglio 349 350 "; 352 description 353 "This module contains a YANG definitions of a generic finite state machine."; 355 revision 2016-03-15 { 356 description "Initial Revision."; 357 reference 358 "RFC xxxx:"; 359 } 361 identity TRANSITION { 362 description "Base for all types of event"; 363 } 365 identity ON_CHANGE { 366 base TRANSITION; 367 description 368 "The event when the database changes."; 369 } 371 // typedef statements 373 typedef transition-type { 374 description "it defines the transition type"; 375 type identityref { 376 base TRANSITION; 377 } 379 } 381 typedef transition-id-type { 382 description "it defines the transition id type"; 383 type uint32; 384 } 386 // grouping statements 387 grouping action-block { 388 description "it defines the grouping action"; 389 leaf id { 390 description "it defines the id of the transition"; 391 type transition-id-type; 392 } 393 leaf type { 394 description "it defines if the action has to be simply executed or if a conditional statement has to be checked before execution"; 396 type enumeration { 397 enum "CONDITIONAL_OP"{ 398 description "it defines the type CONDITIONAL OPERATION to check a statement before execution. In this draft, at the moment, only SIMPLE will be assumed"; 400 } 401 enum "SIMPLE_OP"{ 402 description "it defines the type SIMPLE OPERATION: i.e., an operation to be directly executed; 403 } 404 } 405 mandatory true; 406 } 408 grouping execution-top { 409 description "it defines the execution attribute"; 410 anyxml execute { 411 description "Represent the action to perform"; 412 } 413 leaf next-action { 414 type transition-id-type; 415 description "the id of the next action to execute"; 416 } 417 } 419 container simple { 420 when "../type = 'SIMPLE_OP'"; 421 description 422 "Simple execution of an action without checking any condition"; 423 uses execution-top; 424 } 426 } 428 grouping action-top { 429 description "it defines the grouping of action"; 430 list action { 431 description "it defines the list of actions"; 432 key "id"; 434 ordered-by user; 435 uses action-block; 436 } 437 } 439 grouping on-change { 440 description 441 "Event occuring when a modification of one or more 442 objects occurs"; 444 leaf threshold-parameter { 445 description "it defines the threshold of an event determined by a threshold exceed"; 446 type decimal64; 447 } 449 leaf threshold-operator { 450 description "it defines the operator to check the threshold exceed: <, > <=, >="; 451 type string; 452 } 454 } 456 grouping transition-top { 457 description "it defines the grouping transition"; 458 leaf name { 459 description "it defines the transition name"; 460 type string; 461 mandatory true; 462 } 464 leaf description { 465 description "it describes the transition with a string"; 466 type string; 467 } 469 // list of all possible events 470 uses on-change { 471 when "type = 'ON_CHANGE'"; 472 } 474 container transition-action { 475 description "it defines the container actions to take during the transition"; 476 uses action-top; 477 } 478 } 480 grouping transitions-top { 481 description "it defines the grouping transition"; 482 container transitions { 483 description "it defines the container transitions"; 484 list transition { 485 description "it defines the list of transitions"; 486 key "name"; 487 uses transition-top; 489 } 490 } 491 } 493 // data definition statements 495 uses transitions-top; 497 // extension statements 499 // feature statements 501 // augment statements 503 // rpc statements 505 // notification statements 507 // identity statements 509 // typedef statements 511 typedef state-id-type { 512 description "it defines the id type of the states"; 513 type uint32; 514 } 516 // grouping statements 517 grouping state-top { 518 description "it defines the grouping state"; 519 leaf id { 520 description "it defines the id of the state"; 521 type state-id-type; 522 } 524 leaf description { 525 description "it describes the state with a string"; 526 type string; 527 } 529 grouping next-state-top { 530 description "it defines the grouping next state"; 531 leaf next-state { 532 type leafref { 533 path "../../../../../../../../../states/state/id"; 534 } 535 description "Id of the next state"; 536 } 537 } 539 uses transitions-top { 540 augment "transitions/transition/transition-action/action/simple" { 541 //uses next-state-top; 542 leaf next-state { 543 type leafref { 544 path "../../../../../../../../states/state/id"; 545 } 546 description "Id of the next state"; 547 } 548 } 549 } 551 } 553 grouping states-top { 554 description "it defines the attributes of state-top"; 555 leaf current-state { 556 description "it defines the current state"; 557 type leafref { 558 description "it refers to its id"; 559 path "../states/state/id"; 560 } 561 } 562 container states { 563 description "it defines the container states"; 564 list state { 565 description "it defines the list of states"; 566 key "id"; 567 uses state-top; 568 } 569 } 570 } 572 // data definition statements 574 uses states-top; 576 // extension statements 578 // feature statements 580 // augment statements. 582 // rpc statements 584 // notification statements 586 }//module fsm 588 590 7. Acknowledgements 592 This work has been partially supported by the European Commission 593 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 594 dynamic networks using a Holistic cross-layEr, Self-configurable 595 Truly flexible approach, grant agreement no: H2020-645360) project. 596 The views expressed here are those of the authors only. The European 597 Commission is not liable for any use that may be made of the 598 information in this document. 600 8. Security Considerations 602 TBD 604 9. IANA Considerations 606 TBD 608 10. References 610 10.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 618 the Network Configuration Protocol (NETCONF)", RFC 6020, 619 DOI 10.17487/RFC6020, October 2010, 620 . 622 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 623 and A. Bierman, Ed., "Network Configuration Protocol 624 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 625 . 627 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 628 Application-Based Network Operations", RFC 7491, 629 DOI 10.17487/RFC7491, March 2015, 630 . 632 10.2. Informative References 634 [I-D.ietf-i2rs-yang-network-topo] 635 Clemm, A., Medved, J., Varga, R., Bahadur, N., 636 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 637 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 638 progress), December 2017. 640 [I-D.sambo-netmod-yang-fsm] 641 Sambo, N., Castoldi, P., Fioccola, G., Cugini, F., Song, 642 H., and T. Zhou, "YANG model for finite state machine", 643 draft-sambo-netmod-yang-fsm-02 (work in progress), March 644 2018. 646 [I-D.vergara-ccamp-flexigrid-yang] 647 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 648 King, D., Lee, Y., and G. Galimberti, "YANG data model for 649 Flexi-Grid Optical Networks", draft-vergara-ccamp- 650 flexigrid-yang-06 (work in progress), January 2018. 652 [I-D.zhang-ccamp-l1-topo-yang] 653 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 654 Liu, "A YANG Data Model for Optical Transport Network 655 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 656 progress), April 2017. 658 Authors' Addresses 660 Nicola Sambo 661 Scuola Superiore Sant'Anna 662 Via Moruzzi 1 663 Pisa 56124 664 Italy 666 Email: nicola.sambo@sssup.it 668 Piero Castoldi 669 Scuola Superiore Sant'Anna 670 Via Moruzzi 1 671 Pisa 56124 672 Italy 674 Email: piero.castoldi@sssup.it 676 Andrea Sgambelluri 677 Scuola Superiore Sant'Anna 678 Via Moruzzi 1 679 Pisa 56124 680 Italy 682 Email: andrea.sgambelluri@sssup.it 684 Giuseppe Fioccola 685 Telecom Italia 686 Via Reiss Romoli, 274 687 Torino 10148 688 Italy 690 Email: giuseppe.fioccola@telecomitalia.it 691 Filippo Cugini 692 CNIT 693 Via Moruzzi 1 694 Pisa 56124 695 Italy 697 Email: filippo.cugini@cnit.it 699 Daniele Ceccarelli 700 Ericsson 701 Torshamnsgatan,48 702 Stockholm 164 40 703 Sweden 705 Email: daniele.ceccarelli@ericsson.com 707 Haoyu Song 708 Huawei 709 2330 Central Expressway 710 Santa Clara, CA 95050 711 USA 713 Email: haoyu.song@huawei.com 715 Tianran Zhou 716 Huawei 717 156 Beiqing Road 718 Beijing 100095 719 China 721 Email: zhoutianran@huawei.com