idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2020) is 1500 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) == Missing Reference: 'This I-D' is mentioned on line 193, but not defined == Unused Reference: 'RFC7471' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC7823' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'RFC8294' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'RFC8570' is defined on line 1254, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-07 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Y. Lee, Ed. 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track D. Dhody, Ed. 5 Expires: September 9, 2020 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 March 8, 2020 15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling 16 Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-02 19 Abstract 21 This document provides YANG data models that describe performance 22 monitoring telemetry and scaling intent mechanism for TE-tunnels and 23 Virtual Networks (VN). 25 The models presented in this draft allow customers to subscribe to 26 and monitor their key performance data of their interest on the level 27 of TE-tunnel or VN. The models also provide customers with the 28 ability to program autonomic scaling intent mechanism on the level of 29 TE-tunnel as well as VN. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 9, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 69 2. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Design of the Data Models . . . . . . . . . . . . . . . . . . 7 71 3.1. TE KPI Telemetry Model . . . . . . . . . . . . . . . . . 7 72 3.2. VN KPI Telemetry Model . . . . . . . . . . . . . . . . . 8 73 4. Autonomic Scaling Intent Mechanism . . . . . . . . . . . . . 9 74 5. Notification . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. YANG Push Subscription Examples . . . . . . . . . . . . . 11 76 6. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Yang Data Model . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1. ietf-te-kpi-telemetry model . . . . . . . . . . . . . . . 15 79 7.2. ietf-vn-kpi-telemetry model . . . . . . . . . . . . . . . 20 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 85 11.2. Informative References . . . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 88 1. Introduction 90 The YANG model discussed in [I-D.ietf-teas-actn-vn-yang] is used to 91 operate customer-driven Virtual Networks (VNs) during the VN 92 instantiation, VN computation, and its life-cycle service management 93 and operations. YANG model discussed in [I-D.ietf-teas-yang-te] is 94 used to operate TE-tunnels during the tunnel instantiation, and its 95 life-cycle management and operations. 97 The models presented in this draft allow the applications hosted by 98 the customers to subscribe to and monitor their key performance data 99 of their interest on the level of VN [I-D.ietf-teas-actn-vn-yang] or 100 TE-tunnel [I-D.ietf-teas-yang-te]. The key characteristic of the 101 models presented in this document is a top-down programmability that 102 allows the applications hosted by the customers to subscribe to and 103 monitor key performance data of their interest and autonomic scaling 104 intent mechanism on the level of VN as well as TE-tunnel. 106 According to the classification of [RFC8309], the YANG data models 107 presented in this document can be classified as customer service 108 models, which is mapped to CMI (Customer Network Controller (CNC)- 109 Multi-Domain Service Coordinator (MSDC) interface) of ACTN [RFC8453]. 111 [RFC8233] describes key network performance data to be considered for 112 end-to-end path computation in TE networks. Key performance 113 indicator (KPI) is a term that describes critical performance data 114 that may affect VN/TE-tunnel service. The services provided can be 115 optimized to meet the requirements (such as traffic patterns, 116 quality, and reliability) of the applications hosted by the 117 customers. 119 This document provides YANG data models generically applicable to any 120 VN/TE-Tunnel service clients to provide an ability to program their 121 customized performance monitoring subscription and publication data 122 models and automatic scaling in/out intent data models. These models 123 can be utilized by a client network controller to initiate these 124 capability to a transport network controller communicating with the 125 client controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] 126 interface. 128 The term performance monitoring being used in this document is 129 different from the term that has been used in transport networks for 130 many years. Performance monitoring in this document refers to 131 subscription and publication of streaming telemetry data. 132 Subscription is initiated by the client (e.g., CNC) while publication 133 is provided by the network (e.g., MDSC/PNC) based on the client's 134 subscription. As the scope of performance monitoring in this 135 document is telemetry data on the level of client's VN or TE- tunnel, 136 the entity interfacing the client (e.g., MDSC) has to provide VN or 137 TE-tunnel level information. This would require controller 138 capability to derive VN or TE-tunnel level performance data based on 139 lower-level data collected via PM counters in the Network Elements 140 (NE). How the controller entity derives such customized level data 141 (i.e., VN or TE-tunnel level) is out of the scope of this document. 143 The data model includes configuration and state data according to the 144 new Network Management Datastore Architecture [RFC8342]. 146 1.1. Terminology 148 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 149 in this document. 151 Key Performance Data: This refers to a set of data the customer is 152 interested in monitoring for their instantiated VNs or TE-tunnels. 153 Key performance data and key performance indicators are inter- 154 exchangeable in this draft. 156 Scaling: This refers to the network ability to re-shape its own 157 resources. Scale out refers to improve network performance by 158 increasing the allocated resources, while scale in refers to decrease 159 the allocated resources, typically because the existing resources are 160 unnecessary. 162 Scaling Intent: To declare scaling conditions, scaling intent is 163 used. Specifically, scaling intent refers to the intent expressed by 164 the client that allows the client to program/configure conditions of 165 their key performance data either for scaling out or scaling in. 166 Various conditions can be set for scaling intent on either VN or TE- 167 tunnel level. 169 Network Autonomics: This refers to the network automation capability 170 that allows client to initiate scaling intent mechanisms and provides 171 the client with the status of the adjusted network resources based on 172 the client's scaling intent in an automated fashion. 174 1.2. Tree diagram 176 A simplified graphical representation of the data model is used in 177 Section 5 of this this document. The meaning of the symbols in these 178 diagrams is defined in [RFC8340]. 180 1.3. Prefixes in Data Node Names 182 In this document, names of data nodes and other data model objects 183 are prefixed using the standard prefix associated with the 184 corresponding YANG imported modules, as shown in Table 1. 186 +----------+-----------------------+-------------------------------+ 187 | Prefix | YANG module | Reference | 188 +----------+-----------------------+-------------------------------+ 189 | te | ietf-te | [I-D.ietf-teas-yang-te] | 190 | te-types | ietf-te-types | [I-D.ietf-teas-yang-te-types] | 191 | te-tel | ietf-te-kpi-telemetry | [This I-D] | 192 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 193 | vn-tel | ietf-vn-kpi-telemetry | [This I-D] | 194 +----------+-----------------------+-------------------------------+ 196 Table 1: Prefixes and corresponding YANG modules 198 2. Use-Cases 200 [I-D.xu-actn-perf-dynamic-service-control] describes use-cases 201 relevant to this draft. It introduces the dynamic creation, 202 modification and optimization of services based on the performance 203 monitoring. Figure 1 shows a high-level workflows for dynamic 204 service control based on traffic monitoring. 206 +----------------------------------------------+ 207 | Client +-----------------------------+ | 208 | | Dynamic Service Control APP | | 209 | +-----------------------------+ | 210 +----------------------------------------------+ 211 1.Traffic| /|\4.Traffic | /|\ 212 Monitor& | | Monitor | | 8.Traffic 213 Optimize | | Result 5.Service | | modify & 214 Policy | | modify& | | optimize 215 \|/ | optimize Req.\|/ | result 216 +----------------------------------------------+ 217 | Orchestrator | 218 | +-------------------------------+ | 219 | |Dynamic Service Control Agent | | 220 | +-------------------------------+ | 221 | +---------------+ +-------------------+ | 222 | | Flow Optimize | | vConnection Agent | | 223 | +---------------+ +-------------------+ | 224 +----------------------------------------------+ 225 2. Path | /|\3.Traffic | /|\ 226 Monitor | | Monitor | |7.Path 227 Request | | Result 6.Path | | modify & 228 | | modify& | | optimize 229 \|/ | optimize Req.\|/ | result 230 +----------------------------------------------+ 231 | Network SDN Controller | 232 | +----------------------+ +-----------------+| 233 | | Network Provisioning | |Abstract Topology|| 234 | +----------------------+ +-----------------+| 235 | +------------------+ +--------------------+ | 236 | |Network Monitoring| |Physical Topology DB| | 237 | +------------------+ +--------------------+ | 238 +----------------------------------------------+ 240 Figure 1: Workflows for dynamic service control based on traffic 241 monitoring 243 Some of the key points from 244 [I-D.xu-actn-perf-dynamic-service-control] are as follows: 246 o Network traffic monitoring is important to facilitate automatic 247 discovery of the imbalance of network traffic, and initiate the 248 network optimization, thus helping the network operator or the 249 virtual network service provider to use the network more 250 efficiently and save the Capital Expense (CAPEX) and the Operating 251 Expense (OPEX). 253 o Customer services have various Service Level Agreement (SLA) 254 requirements, such as service availability, latency, latency 255 jitter, packet loss rate, Bit Error Rate (BER), etc. The 256 transport network can satisfy service availability and BER 257 requirements by providing different protection and restoration 258 mechanisms. However, for other performance parameters, there are 259 no such mechanisms. In order to provide high quality services 260 according to customer SLA, one possible solution is to measure the 261 SLA related performance parameters, and dynamically provision and 262 optimize services based on the performance monitoring results. 264 o Performance monitoring in a large scale network could generate a 265 huge amount of performance information. Therefore, the 266 appropriate way to deliver the information in the client and 267 network interfaces should be carefully considered. 269 3. Design of the Data Models 271 The YANG models developed in this document describe two models: 273 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 274 performance monitoring mechanism and scaling intent mechanism 275 that allows scale in/out programming by the customer. (See 276 Section 3.1 & Section 7.1 for details). 278 (ii) VN KPI Telemetry Model which provides the VN level of the 279 aggregated performance monitoring mechanism and scaling intent 280 mechanism that allows scale in/out programming by the customer 281 (See Section 3.2 & Section 7.2 for details). 283 3.1. TE KPI Telemetry Model 285 This module describes performance telemetry for TE-tunnel model. The 286 telemetry data is augmented to tunnel state. This module also allows 287 autonomic traffic engineering scaling intent configuration mechanism 288 on the TE-tunnel level. Various conditions can be set for auto- 289 scaling based on the telemetry data (See Section 5 for details) 291 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance TE 292 performance monitoring capability. This monitoring capability will 293 facilitate proactive re-optimization and reconfiguration of TEs based 294 on the performance monitoring data collected via the TE KPI Telemetry 295 YANG model. 297 +------------+ +--------------+ 298 | TE-Tunnel | | TE KPI | 299 | Model |<---------| Telemetry | 300 +------------+ augments | Model | 301 +--------------+ 303 3.2. VN KPI Telemetry Model 305 This module describes performance telemetry for VN model. The 306 telemetry data is augmented both at the VN Level as well as 307 individual VN member level. This module also allows autonomic 308 traffic engineering scaling intent configuration mechanism on the VN 309 level. Scale in/out criteria might be used for network autonomics in 310 order the controller to react to a certain set of variations in 311 monitored parameters (See Section 4 for illustrations). 313 Moreover, this module also provides mechanism to define aggregated 314 telemetry parameters as a grouping of underlying VN level telemetry 315 parameters. Grouping operation (such as maximum, mean) could be set 316 at the time of configuration. For example, if maximum grouping 317 operation is used for delay at the VN level, the VN telemetry data is 318 reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. 319 delay_vn_member_N}. Thus, this telemetry abstraction mechanism allows 320 the grouping of a certain common set of telemetry values under a 321 grouping operation. This can be done at the VN-member level to 322 suggest how the E2E telemetry be inferred from the per domain tunnel 323 created and monitored by PNCs. One proposed example is the 324 following: 326 +------------------------------------------------------------+ 327 | Client | 328 | | 329 +------------------------------------------------------------+ 330 1.Client sets the | /|\ 2. Orchestrator pushes: 331 grouping op, and | | 332 subscribes to the | | VN level telemetry for 333 VN level telemetry for | | - VN Utilized-bw-percentage 334 Delay and | | (Minimum across VN Members) 335 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 336 \|/ | Members) 337 +------------------------------------------------------------+ 338 | Orchestrator | 339 | | 340 +------------------------------------------------------------+ 342 The VN Telemetry Model augments the basic VN model to enhance VN 343 monitoring capability. This monitoring capability will facilitate 344 proactive re-optimization and reconfiguration of VNs based on the 345 performance monitoring data collected via the VN Telemetry YANG 346 model. 348 +----------+ +--------------+ 349 | VN | augments | VN | 350 | Model |<---------| Telemetry | 351 +----------+ | Model | 352 +--------------+ 354 4. Autonomic Scaling Intent Mechanism 356 Scaling intent configuration mechanism allows the client to configure 357 automatic scale-in and scale-out mechanisms on both the TE-tunnel and 358 the VN level. Various conditions can be set for auto- scaling based 359 on the PM telemetry data. 361 There are a number of parameters involved in the mechanism: 363 o scale-out-intent or scale-in-intent: whether to scale-out or 364 scale-in. 366 o performance-type: performance metric type (e.g., one-way-delay, 367 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 368 delay-min, two-way-delay-max, utilized bandwidth, etc.) 370 o threshold-value: the threshold value for a certain performance- 371 type that triggers scale-in or scale-out. 373 o scaling-operation-type: in case where scaling condition can be set 374 with one or more performance types, then scaling-operation-type 375 (AND, OR, MIN, MAX, etc.) is applied to these selected performance 376 types and its threshold values. 378 o Threshold-time: the duration for which the criteria must hold 379 true. 381 o Cooldown-time: the duration after a scaling action has been 382 triggered, for which there will be no further operation. 384 The following tree is a part of ietf-te-kpi-telemetry tree whose 385 model is presented in full detail in Sections 6 & 7. 387 module: ietf-te-kpi-telemetry 388 augment /te:te/te:tunnels/te:tunnel: 389 +--rw te-scaling-intent 390 | +--rw scale-in-intent 391 | | +--rw threshold-time? uint32 392 | | +--rw cooldown-time? uint32 393 | | +--rw scaling-condition* [performance-type] 394 | | +--rw performance-type identityref 395 | | +--rw threshold-value? string 396 | | +--rw scale-in-operation-type? 397 | | scaling-criteria-operation 398 | +--rw scale-out-intent 399 | +--rw threshold-time? uint32 400 | +--rw cooldown-time? uint32 401 | +--rw scaling-condition* [performance-type] 402 | +--rw performance-type identityref 403 | +--rw threshold-value? string 404 | +--rw scale-out-operation-type? 405 | scaling-criteria-operation 407 Let say the client wants to set the scaling out operation based on 408 two performance-types (e.g., two-way-delay and utilized-bandwidth for 409 a te-tunnel), it can be done as follows: 411 o Set Threshold-time: x (sec) (duration for which the criteria must 412 hold true) 414 o Set Cooldown-time: y (sec) (the duration after a scaling action 415 has been triggered, for which there will be no further operation) 417 o Set AND for the scale-out-operation-type 419 In the scaling condition's list, the following two components can be 420 set: 422 List 1: Scaling Condition for Two-way-delay 424 o performance type: Two-way-delay 426 o threshold-value: z milli-seconds 428 List 2: Scaling Condition for Utilized bandwidth 430 o performance type: Utilized bandwidth 432 o threshold-value: w megabytes 434 5. Notification 436 This model does not define specific notifications. To enable 437 notifications, the mechanism defined in [RFC8641] and [RFC8640] can 438 be used. This mechanism currently allows the user to: 440 o Subscribe to notifications on a per client basis. 442 o Specify subtree filters or xpath filters so that only interested 443 contents will be sent. 445 o Specify either periodic or on-demand notifications. 447 5.1. YANG Push Subscription Examples 449 [RFC8641] allows subscriber applications to request a continuous, 450 customized stream of updates from a YANG datastore. 452 Below example shows the way for a client to subscribe to the 453 telemetry information for a particular tunnel (Tunnel1). The 454 telemetry parameter that the client is interested in is one-way- 455 delay. 457 459 461 462 463 464 465 Tunnel1 466 467 468 470 471 472 473 474 475 476 477 500 478 encode-xml 479 480 482 This example shows the way for a client to subscribe to the telemetry 483 information for all VNs. The telemetry parameter that the client is 484 interested in is one-way-delay and one-way-utilized- bandwidth. 486 488 490 491 492 493 494 495 496 498 499 500 501 502 503 504 505 500 506 507 509 6. YANG Data Tree 511 module: ietf-te-kpi-telemetry 512 augment /te:te/te:tunnels/te:tunnel: 513 +--rw te-scaling-intent 514 | +--rw scale-in-intent 515 | | +--rw threshold-time? uint32 516 | | +--rw cooldown-time? uint32 517 | | +--rw scaling-condition* [performance-type] 518 | | +--rw performance-type identityref 519 | | +--rw threshold-value? string 520 | | +--rw scale-in-operation-type? 521 | | scaling-criteria-operation 522 | +--rw scale-out-intent 523 | +--rw threshold-time? uint32 524 | +--rw cooldown-time? uint32 525 | +--rw scaling-condition* [performance-type] 526 | +--rw performance-type identityref 527 | +--rw threshold-value? string 528 | +--rw scale-out-operation-type? 529 | scaling-criteria-operation 530 +--ro te-telemetry 531 +--ro id? string 532 +--ro performance-metrics-one-way 533 | +--ro one-way-delay? uint32 534 | +--ro one-way-delay-normality? 535 | | te-types:performance-metrics-normality 536 | +--ro one-way-residual-bandwidth? 537 | | rt-types:bandwidth-ieee-float32 538 | +--ro one-way-residual-bandwidth-normality? 539 | | te-types:performance-metrics-normality 540 | +--ro one-way-available-bandwidth? 541 | | rt-types:bandwidth-ieee-float32 542 | +--ro one-way-available-bandwidth-normality? 543 | | te-types:performance-metrics-normality 544 | +--ro one-way-utilized-bandwidth? 545 | | rt-types:bandwidth-ieee-float32 546 | +--ro one-way-utilized-bandwidth-normality? 547 | te-types:performance-metrics-normality 548 +--ro performance-metrics-two-way 549 +--ro two-way-delay? uint32 550 +--ro two-way-delay-normality? 551 te-types:performance-metrics-normality 553 module: ietf-vn-kpi-telemetry 554 augment /vn:vn/vn:vn-list: 555 +--rw vn-scaling-intent 556 | +--rw scale-in-intent 557 | | +--rw threshold-time? uint32 558 | | +--rw cooldown-time? uint32 559 | | +--rw scaling-condition* [performance-type] 560 | | +--rw performance-type identityref 561 | | +--rw threshold-value? string 562 | | +--rw scale-in-operation-type? 563 | | scaling-criteria-operation 564 | +--rw scale-out-intent 565 | +--rw threshold-time? uint32 566 | +--rw cooldown-time? uint32 567 | +--rw scaling-condition* [performance-type] 568 | +--rw performance-type identityref 569 | +--rw threshold-value? string 570 | +--rw scale-out-operation-type? 571 | scaling-criteria-operation 572 +--ro vn-telemetry 573 +--ro performance-metrics-one-way 574 | +--ro one-way-delay? uint32 575 | +--ro one-way-delay-normality? 576 | | te-types:performance-metrics-normality 577 | +--ro one-way-residual-bandwidth? 578 | | rt-types:bandwidth-ieee-float32 579 | +--ro one-way-residual-bandwidth-normality? 580 | | te-types:performance-metrics-normality 581 | +--ro one-way-available-bandwidth? 582 | | rt-types:bandwidth-ieee-float32 583 | +--ro one-way-available-bandwidth-normality? 584 | | te-types:performance-metrics-normality 585 | +--ro one-way-utilized-bandwidth? 586 | | rt-types:bandwidth-ieee-float32 587 | +--ro one-way-utilized-bandwidth-normality? 588 | te-types:performance-metrics-normality 589 +--ro performance-metrics-two-way 590 | +--ro two-way-delay? uint32 591 | +--ro two-way-delay-normality? 592 | te-types:performance-metrics-normality 593 +--ro grouping-operation? grouping-operation 594 augment /vn:vn/vn:vn-list/vn:vn-member-list: 595 +--ro vn-member-telemetry 596 +--ro performance-metrics-one-way 597 | +--ro one-way-delay? uint32 598 | +--ro one-way-delay-normality? 599 | | te-types:performance-metrics-normality 600 | +--ro one-way-residual-bandwidth? 601 | | rt-types:bandwidth-ieee-float32 602 | +--ro one-way-residual-bandwidth-normality? 603 | | te-types:performance-metrics-normality 604 | +--ro one-way-available-bandwidth? 605 | | rt-types:bandwidth-ieee-float32 606 | +--ro one-way-available-bandwidth-normality? 607 | | te-types:performance-metrics-normality 608 | +--ro one-way-utilized-bandwidth? 609 | | rt-types:bandwidth-ieee-float32 610 | +--ro one-way-utilized-bandwidth-normality? 611 | te-types:performance-metrics-normality 612 +--ro performance-metrics-two-way 613 | +--ro two-way-delay? uint32 614 | +--ro two-way-delay-normality? 615 | te-types:performance-metrics-normality 616 +--ro te-grouped-params* 617 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id 618 +--ro grouping-operation? grouping-operation 620 7. Yang Data Model 622 7.1. ietf-te-kpi-telemetry model 624 The YANG code is as follows: 626 file "ietf-te-kpi-telemetry@2020-03-08.yang" 627 module ietf-te-kpi-telemetry { 628 yang-version 1.1; 629 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 630 prefix te-tel; 632 import ietf-te { 633 prefix te; 634 reference 635 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 636 Engineering Tunnels and Interfaces"; 637 } 638 import ietf-te-types { 639 prefix te-types; 640 reference 641 "I-D.ietf-teas-yang-te-types: Traffic Engineering Common 642 YANG Types"; 643 } 645 organization 646 "IETF Traffic Engineering Architecture and Signaling (TEAS) 647 Working Group"; 648 contact 649 "WG Web: 650 WG List: 651 Editor: Young Lee 652 Dhruv Dhody "; 653 description 654 "This module describes YANG data model for performance 655 monitoring telemetry for te tunnels. 657 Copyright (c) 2020 IETF Trust and the persons identified as 658 authors of the code. All rights reserved. 660 Redistribution and use in source and binary forms, with or 661 without modification, is permitted pursuant to, and subject to 662 the license terms contained in, the Simplified BSD License set 663 forth in Section 4.c of the IETF Trust's Legal Provisions 664 Relating to IETF Documents 665 (https://trustee.ietf.org/license-info). 667 This version of this YANG module is part of RFC XXXX; see the 668 RFC itself for full legal notices. 670 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 671 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 672 'MAY', and 'OPTIONAL' in this document are to be interpreted as 673 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 674 they appear in all capitals, as shown here."; 676 /* Note: The RFC Editor will replace XXXX with the number 677 assigned to the RFC once draft-ietf-teas-pm-telemetry- 678 autonomics becomes an RFC.*/ 680 revision 2020-03-08 { 681 description 682 "Initial revision."; 683 reference 684 "RFC XXXX: YANG models for VN/TE Performance Monitoring 685 Telemetry and Scaling Intent Autonomics"; 686 } 688 identity telemetry-param-type { 689 description 690 "Base identity for telemetry param types"; 691 } 693 identity one-way-delay { 694 base telemetry-param-type; 695 description 696 "To specify average Delay in one (forward) 697 direction"; 698 reference 699 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 700 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 701 RFC7823: Performance-Based Path Selection for Explicitly 702 Routed Label Switched Paths (LSPs) Using TE Metric 703 Extensions"; 704 } 706 identity two-way-delay { 707 base telemetry-param-type; 708 description 709 "To specify average Delay in both (forward and reverse) 710 directions"; 711 reference 712 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 713 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 714 RFC7823: Performance-Based Path Selection for Explicitly 715 Routed Label Switched Paths (LSPs) Using TE Metric 716 Extensions"; 717 } 719 identity one-way-delay-variation { 720 base telemetry-param-type; 721 description 722 "To specify average Delay Variation in one (forward) direction"; 723 reference 724 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 725 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 726 RFC7823: Performance-Based Path Selection for Explicitly 727 Routed Label Switched Paths (LSPs) Using TE Metric 728 Extensions"; 729 } 731 identity two-way-delay-variation { 732 base telemetry-param-type; 733 description 734 "To specify average Delay Variation in both (forward and reverse) 735 directions"; 736 reference 737 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 738 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 739 RFC7823: Performance-Based Path Selection for Explicitly 740 Routed Label Switched Paths (LSPs) Using TE Metric 741 Extensions"; 742 } 744 identity utilized-bandwidth { 745 base telemetry-param-type; 746 description 747 "To specify utilized bandwidth over the specified source 748 and destination."; 749 reference 750 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 751 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 752 RFC7823: Performance-Based Path Selection for Explicitly 753 Routed Label Switched Paths (LSPs) Using TE Metric 754 Extensions"; 755 } 757 identity utilized-percentage { 758 base telemetry-param-type; 759 description 760 "To specify utilization percentage of the entity 761 (e.g., tunnel, link, etc.)"; 762 } 763 typedef scaling-criteria-operation { 764 type enumeration { 765 enum AND { 766 description 767 "AND operation"; 768 } 769 enum OR { 770 description 771 "OR operation"; 772 } 773 } 774 description 775 "Operations to analize list of scaling criterias"; 776 } 778 grouping scaling-duration { 779 description 780 "Base scaling criteria durations"; 781 leaf threshold-time { 782 type uint32; 783 units "seconds"; 784 description 785 "The duration for which the criteria must hold true"; 786 } 787 leaf cooldown-time { 788 type uint32; 789 units "seconds"; 790 description 791 "The duration after a scaling-in/scaling-out action has been 792 triggered, for which there will be no further operation"; 793 } 794 } 796 grouping scaling-criteria { 797 description 798 "Grouping for scaling criteria"; 799 leaf performance-type { 800 type identityref { 801 base telemetry-param-type; 802 } 803 description 804 "Reference to the tunnel level telemetry type"; 805 } 806 leaf threshold-value { 807 type string; 808 description 809 "Scaling threshold for the telemetry parameter type"; 810 } 812 } 814 grouping scaling-in-intent { 815 description 816 "Basic scaling in intent"; 817 uses scaling-duration; 818 list scaling-condition { 819 key "performance-type"; 820 description 821 "Scaling conditions"; 822 uses scaling-criteria; 823 leaf scale-in-operation-type { 824 type scaling-criteria-operation; 825 default "AND"; 826 description 827 "Operation to be applied to check between scaling criterias 828 to check if the scale in threshold condition has been met. 829 Defaults to AND"; 830 } 831 } 832 } 834 grouping scaling-out-intent { 835 description 836 "Basic scaling out intent"; 837 uses scaling-duration; 838 list scaling-condition { 839 key "performance-type"; 840 description 841 "Scaling conditions"; 842 uses scaling-criteria; 843 leaf scale-out-operation-type { 844 type scaling-criteria-operation; 845 default "OR"; 846 description 847 "Operation to be applied to check between scaling criterias 848 to check if the scale out threshold condition has been met. 849 Defauls to OR"; 850 } 851 } 852 } 854 augment "/te:te/te:tunnels/te:tunnel" { 855 description 856 "Augmentation parameters for config scaling-criteria TE 857 tunnel topologies. Scale in/out criteria might be used 858 for network autonomics in order the controller to react 859 to a certain set of monitored params."; 861 container te-scaling-intent { 862 description 863 "scaling intent"; 864 container scale-in-intent { 865 description 866 "scale-in"; 867 uses scaling-in-intent; 868 } 869 container scale-out-intent { 870 description 871 "scale-out"; 872 uses scaling-out-intent; 873 } 874 } 875 container te-telemetry { 876 config false; 877 description 878 "telemetry params"; 879 leaf id { 880 type string; 881 description 882 "Id of telemetry param"; 883 } 884 uses te-types:performance-metrics-attributes; 885 } 886 } 887 } 889 891 7.2. ietf-vn-kpi-telemetry model 893 The YANG code is as follows: 895 file "ietf-vn-kpi-telemetry@2020-03-08.yang" 896 module ietf-vn-kpi-telemetry { 897 yang-version 1.1; 898 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry"; 899 prefix vn-tel; 901 import ietf-vn { 902 prefix vn; 903 reference 904 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 905 Operation"; 906 } 907 import ietf-te { 908 prefix te; 909 reference 910 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 911 Engineering Tunnels and Interfaces"; 912 } 913 import ietf-te-types { 914 prefix te-types; 915 reference 916 "I-D.ietf-teas-yang-te-types: Traffic Engineering Common 917 YANG Types"; 918 } 919 import ietf-te-kpi-telemetry { 920 prefix te-kpi; 921 reference 922 "RFC XXXX: YANG models for VN/TE Performance Monitoring 923 Telemetry and Scaling Intent Autonomics"; 924 } 926 /* Note: The RFC Editor will replace YYYY with the number 927 assigned to the RFC once draft-lee-teas-actn-pm-telemetry 928 -autonomics becomes an RFC.*/ 930 organization 931 "IETF Traffic Engineering Architecture and Signaling (TEAS) 932 Working Group"; 933 contact 934 "WG Web: 935 WG List: 936 Editor: Young Lee 937 Dhruv Dhody "; 938 description 939 "This module describes YANG data models for performance 940 monitoring telemetry for vn. 942 Copyright (c) 2020 IETF Trust and the persons identified as 943 authors of the code. All rights reserved. 945 Redistribution and use in source and binary forms, with or 946 without modification, is permitted pursuant to, and subject to 947 the license terms contained in, the Simplified BSD License set 948 forth in Section 4.c of the IETF Trust's Legal Provisions 949 Relating to IETF Documents 950 (https://trustee.ietf.org/license-info). 952 This version of this YANG module is part of RFC XXXX; see the 953 RFC itself for full legal notices. 955 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 956 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 957 'MAY', and 'OPTIONAL' in this document are to be interpreted as 958 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 959 they appear in all capitals, as shown here."; 961 /* Note: The RFC Editor will replace XXXX with the number 962 assigned to the RFC once draft-lee-teas-pm-telemetry- 963 autonomics becomes an RFC.*/ 965 revision 2020-03-08 { 966 description 967 "Initial revision."; 968 reference 969 "RFC XXXX: YANG models for VN/TE Performance Monitoring 970 Telemetry and Scaling Intent Autonomics"; 971 } 973 typedef grouping-operation { 974 type enumeration { 975 enum MINIMUM { 976 description 977 "Select the minimum param"; 978 } 979 enum MAXIMUM { 980 description 981 "Select the maximum param"; 982 } 983 enum MEAN { 984 description 985 "Select the MEAN of the params"; 986 } 987 enum STD_DEV { 988 description 989 "Select the standard deviation of the monitored params"; 990 } 991 enum AND { 992 description 993 "Select the AND of the params"; 994 } 995 enum OR { 996 description 997 "Select the OR of the params"; 998 } 999 } 1000 description 1001 "Operations to analize list of monitored params"; 1002 } 1004 grouping vn-telemetry-param { 1005 description 1006 "augment of te-kpi:telemetry-param for VN specific params"; 1007 leaf-list te-grouped-params { 1008 type leafref { 1009 path 1010 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id"; 1011 } 1012 description 1013 "Allows the definition of a vn-telemetry param 1014 as a grouping of underlying TE params"; 1015 } 1016 leaf grouping-operation { 1017 type grouping-operation; 1018 description 1019 "describes the operation to apply to 1020 te-grouped-params"; 1021 } 1022 } 1024 augment "/vn:vn/vn:vn-list" { 1025 description 1026 "Augmentation parameters for state TE VN topologies."; 1027 container vn-scaling-intent { 1028 description 1029 "scaling intent"; 1030 container scale-in-intent { 1031 description 1032 "VN scale-in"; 1033 uses te-kpi:scaling-in-intent; 1034 } 1035 container scale-out-intent { 1036 description 1037 "VN scale-out"; 1038 uses te-kpi:scaling-out-intent; 1039 } 1040 } 1041 container vn-telemetry { 1042 config false; 1043 description 1044 "VN telemetry params"; 1045 uses te-types:performance-metrics-attributes; 1046 leaf grouping-operation { 1047 type grouping-operation; 1048 description 1049 "describes the operation to apply to the VN-members"; 1050 } 1051 } 1052 } 1053 augment "/vn:vn/vn:vn-list/vn:vn-member-list" { 1054 description 1055 "Augmentation parameters for state TE vn member topologies."; 1056 container vn-member-telemetry { 1057 config false; 1058 description 1059 "VN member telemetry params"; 1060 uses te-types:performance-metrics-attributes; 1061 uses vn-telemetry-param; 1062 } 1063 } 1064 } 1066 1068 8. Security Considerations 1070 The YANG module specified in this document defines a schema for data 1071 that is designed to be accessed via network management protocols such 1072 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1073 is the secure transport layer, and the mandatory-to-implement secure 1074 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1075 is HTTPS, and the mandatory-to-implement secure transport is TLS 1076 [RFC8446]. 1078 The NETCONF access control model [RFC8341] provides the means to 1079 restrict access for particular NETCONF users to a preconfigured 1080 subset of all available NETCONF protocol operations and content. The 1081 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method 1082 for invoking and running NETCONF within a Secure Shell (SSH) session 1083 as an SSH subsystem. The Network Configuration Access Control Model 1084 (NACM) [RFC8341] provides the means to restrict access for particular 1085 NETCONF or RESTCONF users to a preconfigured subset of all available 1086 NETCONF or RESTCONF protocol operations and content. 1088 A number of configuration data nodes defined in this document are 1089 writable/deletable (i.e., "config true"). These data nodes may be 1090 considered sensitive or vulnerable in some network environments. 1092 There are a number of data nodes defined in this YANG module that are 1093 writable/creatable/deletable (i.e., config true, which is the 1094 default). These data nodes may be considered sensitive or vulnerable 1095 in some network environments. Write operations (e.g., edit-config) 1096 to these data nodes without proper protection can have a negative 1097 effect on network operations. These are the subtrees and data nodes 1098 and their sensitivity/vulnerability: 1100 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1101 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1103 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent 1105 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent 1107 9. IANA Considerations 1109 This document registers the following namespace URIs in the IETF XML 1110 registry [RFC3688]: 1112 -------------------------------------------------------------------- 1113 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1114 Registrant Contact: The IESG. 1115 XML: N/A, the requested URI is an XML namespace. 1116 -------------------------------------------------------------------- 1118 -------------------------------------------------------------------- 1119 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1120 Registrant Contact: The IESG. 1121 XML: N/A, the requested URI is an XML namespace. 1122 -------------------------------------------------------------------- 1124 This document registers the following YANG modules in the YANG 1125 Module. 1127 Names registry [RFC7950]: 1129 -------------------------------------------------------------------- 1130 name: ietf-te-kpi-telemetry 1131 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1132 prefix: te-tel 1133 reference: RFC XXXX (TDB) 1134 -------------------------------------------------------------------- 1136 -------------------------------------------------------------------- 1137 name: ietf-vn-kpi-telemetry 1138 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1139 prefix: vn-tel 1140 reference: RFC XXXX (TDB) 1141 -------------------------------------------------------------------- 1143 10. Acknowledgements 1145 We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful 1146 discussions and their suggestions for this work. 1148 11. References 1150 11.1. Normative References 1152 [I-D.ietf-teas-actn-vn-yang] 1153 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1154 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1155 teas-actn-vn-yang-07 (work in progress), October 2019. 1157 [I-D.ietf-teas-yang-te] 1158 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1159 "A YANG Data Model for Traffic Engineering Tunnels and 1160 Interfaces", draft-ietf-teas-yang-te-22 (work in 1161 progress), November 2019. 1163 [I-D.ietf-teas-yang-te-types] 1164 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1165 "Traffic Engineering Common YANG Types", draft-ietf-teas- 1166 yang-te-types-13 (work in progress), November 2019. 1168 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1169 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1170 . 1172 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1173 Ceccarelli, D., and X. Zhang, "Problem Statement and 1174 Architecture for Information Exchange between 1175 Interconnected Traffic-Engineered Networks", BCP 206, 1176 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1177 . 1179 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1180 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1181 . 1183 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1184 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1185 . 1187 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1188 "Extensions to the Path Computation Element Communication 1189 Protocol (PCEP) to Compute Service-Aware Label Switched 1190 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1191 2017, . 1193 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1194 Access Control Model", STD 91, RFC 8341, 1195 DOI 10.17487/RFC8341, March 2018, 1196 . 1198 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1199 and R. Wilton, "Network Management Datastore Architecture 1200 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1201 . 1203 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1204 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1205 . 1207 11.2. Informative References 1209 [I-D.xu-actn-perf-dynamic-service-control] 1210 Xu, Y., Zhang, G., Cheng, W., and z. 1211 zhenghaomian@huawei.com, "Use Cases and Requirements of 1212 Dynamic Service Control based on Performance Monitoring in 1213 ACTN Architecture", draft-xu-actn-perf-dynamic-service- 1214 control-03 (work in progress), April 2015. 1216 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1217 DOI 10.17487/RFC3688, January 2004, 1218 . 1220 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1221 and A. Bierman, Ed., "Network Configuration Protocol 1222 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1223 . 1225 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1226 Previdi, "OSPF Traffic Engineering (TE) Metric 1227 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1228 . 1230 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1231 "Performance-Based Path Selection for Explicitly Routed 1232 Label Switched Paths (LSPs) Using TE Metric Extensions", 1233 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1234 . 1236 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1237 "Common YANG Data Types for the Routing Area", RFC 8294, 1238 DOI 10.17487/RFC8294, December 2017, 1239 . 1241 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1242 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1243 . 1245 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1246 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1247 . 1249 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1250 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1251 DOI 10.17487/RFC8453, August 2018, 1252 . 1254 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1255 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1256 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1257 2019, . 1259 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1260 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1261 and Datastores over NETCONF", RFC 8640, 1262 DOI 10.17487/RFC8640, September 2019, 1263 . 1265 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1266 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1267 September 2019, . 1269 Authors' Addresses 1271 Young Lee (editor) 1272 Samsung Electronics 1274 Email: younglee.tx@gmail.com 1276 Dhruv Dhody (editor) 1277 Huawei Technologies 1278 Divyashree Techno Park, Whitefield 1279 Bangalore, Karnataka 560066 1280 India 1282 Email: dhruv.ietf@gmail.com 1283 Satish Karunanithi 1284 Huawei Technologies 1285 Divyashree Techno Park, Whitefield 1286 Bangalore, Karnataka 560066 1287 India 1289 Email: satish.karunanithi@gmail.com 1291 Ricard Vilalta 1292 CTTC 1293 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1294 Barcelona 1295 Spain 1297 Email: ricard.vilalta@cttc.es 1299 Daniel King 1300 Lancaster University 1302 Email: d.king@lancaster.ac.uk 1304 Daniele Ceccarelli 1305 Ericsson 1306 Torshamnsgatan,48 1307 Stockholm, Sweden 1309 Email: daniele.ceccarelli@ericsson.com