idnits 2.17.1 draft-ww-opsawg-multi-layer-oam-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2014) is 3560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1157' is mentioned on line 528, but not defined == Missing Reference: 'RFC4176' is mentioned on line 567, but not defined == Unused Reference: 'RFC2119' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-problem-statement' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'I-D.jain-nvo3-overlay-oam' is defined on line 776, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-jain-nvo3-overlay-oam-01 == Outdated reference: A later version (-01) exists of draft-tissa-netmod-oam-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Working Group Q. Wu 3 Internet-Draft M. Wexler 4 Intended status: Informational Huawei 5 Expires: December 31, 2014 M. Boucadair 6 France Telecom 7 S. Aldrin 8 Huawei USA 9 G. Mirsky 10 Ericsson 11 P. Jain 12 Nuage Networks 13 June 29, 2014 15 Problem Statement and Architecture for Transport-Independent Multiple 16 Layer OAM 17 draft-ww-opsawg-multi-layer-oam-01.txt 19 Abstract 21 Operations, Administration, and Maintenance (OAM) mechanismsare 22 critical building blocks in network operations that are used for 23 service assurance, fulfillment, or service diagnosis, 24 troubleshooting, and repair. The current practice is that many 25 technologies rely on their own OAM protocols that are exclusive to a 26 given layer. There is little consolidation of OAM in either data 27 plane or management plane nor well-documented inter-layer OAM 28 operations. Vendors and Operators dedicate significant resources and 29 effort through the whole OAM life-cycle each time when a new 30 technology is (to be) introduced. This is even exacerbated when 31 dealing with integration of OAM across multiple technologies. 33 This document describes the problem space and defines an architecture 34 for the generic and integrated OAM with a focus of multi-layer and 35 cross-layer considerations. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 31, 2014. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 6 74 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Use of Existing Protocols . . . . . . . . . . . . . . . . 7 76 3.2. Strong Technology dependency . . . . . . . . . . . . . . 8 77 3.3. Weakness of Cross-Layer OAM . . . . . . . . . . . . . . . 8 78 3.4. Lack of OAM above Layer 3 . . . . . . . . . . . . . . . . 9 79 3.5. Issues of Abstraction . . . . . . . . . . . . . . . . . . 9 80 3.6. Issue of OAM Information Gathering from Layers Covering 81 Heterogeneous Network Technologies . . . . . . . . . . . 10 82 3.6.1. Focus on Service Function Chaining . . . . . . . . . 10 83 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 11 84 5. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6. Architectural Consideration . . . . . . . . . . . . . . . . . 13 86 6.1. Basic Components . . . . . . . . . . . . . . . . . . . . 13 87 6.1.1. Overlay OAM . . . . . . . . . . . . . . . . . . . . . 13 88 6.1.2. OAM at the top of Layer 3 . . . . . . . . . . . . . . 13 89 6.2. OAM Functions in the Data Plane . . . . . . . . . . . . . 13 90 6.2.1. Continuity Check . . . . . . . . . . . . . . . . . . 13 91 6.2.2. Connectivity Verification . . . . . . . . . . . . . . 13 92 6.2.3. Path Discovery . . . . . . . . . . . . . . . . . . . 14 93 6.2.4. Performance Measurement . . . . . . . . . . . . . . . 14 94 6.2.5. Protection Switching Coordination . . . . . . . . . . 14 95 6.2.6. Alarm/defect Indication . . . . . . . . . . . . . . . 14 96 6.2.7. Maintenance Commands . . . . . . . . . . . . . . . . 14 98 6.3. OAM in Management Plane . . . . . . . . . . . . . . . . . 14 99 7. Building on Existing Protocols . . . . . . . . . . . . . . . 15 100 8. Scoping Future Work . . . . . . . . . . . . . . . . . . . . . 15 101 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 106 12.2. Informative References . . . . . . . . . . . . . . . . . 17 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 109 1. Introduction 111 Operations, Administration, and Maintenance (OAM) mechanisms being 112 understood and used in context of RFC 6291 [RFC6291] are critical 113 building blocks in network operations that are used for service 114 assurance, fulfillment, or service diagnosis, troubleshooting, and 115 repair. The key foundations of OAM and its functional roles in 116 monitoring and diagnosing the behavior of networks have been studied 117 at OSI layers 1, 2 and 3 since a while. As a reminder, OAM functions 118 are used in many management applications for various objectives such 119 as (i) failure detection, (ii) reporting the defect/ failure 120 information, (iii) defect/failure localization, (iv) performance 121 monitoring, and (v) service recovery. 123 The current practice that consists in enabling OAM techniques for 124 each layer has shown its limits; this is a need for cross-layer and 125 inter-layer OAM considerations [RFC7276]. This need for inter-layer 126 OAM is motivated by the need to achieve: network optimization, 127 efficient enforcement of TE (Traffic Engineering) techniques 128 including ensuring path diversity at distinct layers or computing 129 completely disjoint paths at several layers, fine-grain tweaking, 130 ease of root cause analysis, ability to maintain a network-wise 131 visibility in addition to layer-specific one, etc. 133 It is worth to mention also that there are two restrictions for 134 multi-layer structure as discussed in [RFC7276]: 136 o Each layer has its own OAM protocol, OAM should not cross layer 137 boundaries. 139 o Each layer OAM used at different level of hierarchy in the 140 network. 142 Moreover, there is little consolidation of OAM in either data plane 143 or management plane. Vendors and operators dedicate a lot resources 144 and effort through the whole OAM life-cycle each time a new 145 technology is (to be) introduced. Integration of OAM across multiple 146 technologies in either data plane or management plane is extremely 147 difficult to achieve. 149 When operating networks with more than one technology, maintenance 150 and troubleshooting are achieved per technology and per layer, 151 operation process can be very cumbersome since OAM is not defined to 152 cross layer boundaries. Another challenge is presented by use of 153 different technologies and corresponding OAM on the same layer of 154 adjacent network domains. Interworking between different OAM often 155 not defined and are left to proprietary solutions. In many cases 156 when keeping network complexity down and simplifying OAM is needed, 157 it is desirable to have a generic and integrated OAM to cover 158 heterogeneous networking technologies. 160 This document defines the problem space and describes an architecture 161 for the generic and integrated OAM in the multi-layer and multi- 162 domain networks. In particular, it outlines the problems encountered 163 with existing OAM protocols and their impact on introduction of new 164 technologies (see Section 3). 166 This document covers the following: 168 o Data plane OAM consolidation by looking at the common active OAM 169 functions (including, Connectivity Verification (CV), Path 170 Verification and Continuity Checks (CC), Path Discovery, 171 Performance Measurement) necessary to monitor and diagnose a 172 network; 174 o Management plane consolidation by interacting with data plane OAM 175 and abstracting OAM information common to different layer via 176 uniformed interface. 178 2. Terminology 180 This document defines the following terms: 182 Transport Independent Multi-Layer OAM : 184 In an multi-layer network, transport independent OAM is OAM that 185 can be deployed independent of media, data protocols, and routing 186 protocols It denotes the ability to exchange OAM information 187 across layers and domains between nodes along forwarding path, and 188 gather OAM information that are common to different layers and 189 expose it to the management application through a unified 190 interface. These aspects are not specific to a given transport 191 technology. 193 OAM function : 195 Refers to the atomic building blocks of OAM; an OAM function 196 defines an OAM capability (See section 2.2.3 of [RFC7276]). 198 OAM protocol : 200 Refers to a protocol used for implementing one or more OAM 201 functions (See section 2.2.3 of [RFC7276]). 203 OAM tool : 205 Denotes a specific means of applying one or more OAM functions. 206 An OAM protocol can be an OAM tool. An OAM tool can use a set of 207 OAM protocols or a set of protocols that are not strictly OAM 208 related (See section 2.2.3 of [RFC7276]). 210 OAM packet : 212 Refers to a packet generated at Maintenance Point using an OAM 213 protocol. An OAM packet, which carries OAM information, is 214 usually forwarded through the same route/path as the data traffic 215 and receive the same (forwarding) treatment. 217 Maintenance Domain (MD): 219 Refers to the part of a network whereOAM function is performed 220 (initiated). 222 Maintenance Point (MP): 224 Is a generic functional entity that is associated with a 225 particular MD, defined at a specific layer of a network and can 226 initiate and/or react to OAM packets. 228 Maintenance Endpoint (MEP): 230 Is an endpoint MP that initiates OAM packets and responds to them. 232 Maintenance Intermediary Point(MIP): 234 In between MEPs, there are zero or more intermediate points, 235 called Maintenance Intermediary Point. A Maintenance Intermediary 236 Point (MIP) is an intermediate MP that does not generally initiate 237 OAM packets but is able to respond to OAM packets that are 238 destined to it. 240 Network Element (NE) : 242 Denotes a physical or virtual network device/function that 243 connects directly to the network. NE can host MPs and provide 244 network connectivity to one or many MPs. 246 2.1. Acronyms and Abbreviations 248 CC - Continuity Check 250 CV - Connectivity Verification 252 SNMP - Simple Network Management Protocol 254 NETCONF - Network Configuration 256 ETH - Ethernet 258 APS - Automatic Protection Switching 260 LT - LinkTrace 262 RDI - Remote Defect Indication 264 AIS - Alarm indication Signal 266 OWAMP - One Way Active Measurement Protocol 268 TWAMP - Two Way Active Measurement Protocol 270 CFM - Connectivity Fault Management 272 3. Problem Statement 274 OAM mechanisms are usually oriented toward a single network 275 technology or a single layer. Each technology or layer has its best 276 suited OAM tools. Some of them providing rich functionality rely on 277 the capabilities of one protocol, while the others provide each 278 function with a different protocol; In the current situation, there 279 is little, or no re-use, of software and hardware for each OAM 280 protocol. 282 Integration of OAM across multiple technologies is extremely 283 difficult. Vendors and operators waste a lot through the whole OAM 284 life-cycle when a new technology is introduced: 286 (1) Design and development: For every new protocol there is a need 287 to invest in complete life-cycle (i.e.,the design and development 288 of data, control and management planes). In some cases, even 289 adding a single OAM function requires the above complete life- 290 cycle. 292 (2) Operation and Maintenance: There is a need to re-train 293 operation people for almost every newly introduced technology or 294 feature. The above causes a slow time-to-market and a waste of 295 time and effort for any new technology and/or OAM function. 297 Specifically, in Service Function Chaining environment, every Service 298 Function may operate at a different layer and may use different 299 encapsulation and tunneling techniques. When taking into account 300 virtualization related technologies, the number of encapsulation and 301 tunneling options increase even more. Still, end-to-end service OAM 302 mechanisms and information exchanges between Service Functions should 303 be provided to operate and maintain the network as a whole. This 304 requires a generic toolkit that can provide all necessary tools in 305 context of multi-technology, multi-layer, physical and virtual 306 environments. 308 A particular problem is how OAM information at different layer is 309 made available to a management application for use and learnt via the 310 unified management interface. For example, in the case of an multi- 311 layer network, OAM information needs to be imposed to the packet and 312 injected into the network and at last abstracted from various layers 313 and expose them to the management application. 315 3.1. Use of Existing Protocols 317 OAM information resides at each layer and may currently be exchanged 318 at each network layer in a domain by using various encapsulation 319 technologies at the Layer 2 & Layer 3 levels. OAM information may be 320 gathered and exported from a domain (for example, northbound) using 321 SNMP [RFC3411]or NETCONF/YANG [RFC6241]. 323 It is desirable that a solution to the problem described in this 324 document does not require the implementation of a new, network-wide 325 protocol or introduce a shim layer to carry OAM information. 326 Instead, it would be advantageous to make use of an existing 327 protocols or functionalities that are commonly implemented and are 328 currently deployed in operational networks. This has many benefits 329 in network stability, time to deployment, and operator training. 331 It is recognized, however, that existing protocols or functionalities 332 are unlikely to be immediately suitable to this problem space without 333 some protocol extensions. Extending protocols must be done with care 334 and with consideration for the stability of existing deployments. In 335 extreme cases, when there is a lack of functionality, although 336 similar mechanisms exist in other technologies, a new protocol can be 337 preferable to a "messy" hack of an existing protocol. 339 3.2. Strong Technology dependency 341 OAM protocols are relying heavily on the specific network technology 342 they are associated with. For example, ICMP, LSP Ping are using 343 different network technologies but provide the same OAM 344 functionality, i.e., Path Discovery. Another example is BFD,LSP Ping 345 are using different network technologies but provide the same 346 functionality, i.e., Continuity Verification. Figure 1 shows common 347 OAM functionalities shared by various existing OAM protocols. 349 |--------+------------+--------------+--------------+------------+ 350 | |Continuity | Connectivity| Path | Performance| 351 | | Check | Verification| Discovery | Measurement| 352 +--------+------------+--------------+--------------+------------+ 353 | | | | |-Delay | 354 | ICMP | Echo(Ping) | Echo(Ping) | Traceroute |-Loss rough | 355 | | | | | measurement| 356 +--------+------------+--------------+--------------+------------+ 357 | | | | | | 358 | BFD | BFD | BFD Echo | | | 359 | | Control | | | | 360 +--------+------------+--------------+--------------+------------+ 361 | LSP | | | | - Delay | 362 | Ping | | Ping | Traceroute | - Packet | 363 | | | | | Loss | 364 +--------+------------+--------------+--------------+------------+ 365 | | | | | -OWAMP | 366 | IPPM | | | | -TWAMP | 367 | | | | | | 368 |--------+------------+--------------+--------------+------------+ 369 | MPLS-TP| | | | | 370 | OAM | CC | CV | Traceroute | -Delay | 371 | |(use of BFD)|(use of BFD) | | -Packet | 372 | | | | | Loss | 373 +--------+------------+--------------+--------------+------------+ 375 Figure 1.Examples of OAM tools 377 3.3. Weakness of Cross-Layer OAM 379 Troubleshooting is cumbersome due to protocol variety and lack of 380 multi-layer OAM. Usually OAM messages should not cross layer 381 boundaries. Each of the service, network and transport layers 382 possesses its well-discernable and native OAM stream. In addition, 383 OAM messages should not be leaked outside of a management domain 384 within a layer, where a management domain is governed by a single 385 business organization. When having networks with more than one 386 technology, maintenance and troubleshooting are done per technology 387 and layer. 389 These rules could in some cases ease the understanding in which 390 technology the operation is done or fault is located. In some cases, 391 when one layer OAM fails, it may be desirable to drop down to the 392 another layer OAM and issue the corresponding OAM command, using the 393 same APIs, if OAM in multiple layers can be supported. However, in 394 most cases switching tools and layers in the same operation process 395 is cumbersome and not serving the main idea - to find the root cause 396 location. It would be very helpful to have a generic mechanisms that 397 is end to end basis, allow management application interact with data 398 plane OAM and can ping IPv4 host by an IPv6 source or having one tool 399 to troubleshoot combined IP, MPLS, Ethernet, GRE and VXLAN network. 401 In Service Function Chaining environment, it is necessary to provide 402 end-to-end OAM across certain or all entities and involving many 403 layers. Inter-layer OAM considerations are key in an SFC context 404 because problems may occur at the network layer or at the service 405 chaining layer. 407 3.4. Lack of OAM above Layer 3 409 The Layer 2/3 OAM protocols are quite rich in their functionality, 410 well defined, standardized and heavily used. In the last years a lot 411 of work was conducted to consider maintenance domains and levels in 412 order to better handle the issues of technology re-use, smooth 413 interoperability and interworking between domains. 415 The above mechanisms are not defined for the technologies above Layer 416 3. Therefore, in the SFC environment where a Service Function 417 Chaining is composed by a set of Service Functions, but providing an 418 end-to-end chain or path from a source to destination in a given 419 order [I.D-ietf-sfc- problem- statement], no standard exists as a 420 reference for OAM since when the service packets is steered through a 421 set of service nodes distributed in the network, each service node 422 may act at different layers above layer 3. 424 3.5. Issues of Abstraction 426 In multi-layer network, OAM functions are enabled at different layers 427 and various OAM information needs to be gathered from various layers. 428 Without multi-layer OAM in place, it is hard for management 429 applications to understand what information at different layers 430 stands for. One possible solution to these issues is to abstract the 431 OAM information shared across layers, i.e., using the same tool or 432 API to activate the OAM functions at different layers and retrieve 433 the results. 435 The challenge is to abstract in a way that retains as much useful 436 information as possible while filtering the data that is not needed 437 to be leaked to other layers. An important part of this effort is a 438 clear understanding of what information is actually needed. 440 3.6. Issue of OAM Information Gathering from Layers Covering 441 Heterogeneous Network Technologies 443 In SFC, the service packets are steered through a set of service 444 nodes distributed in the network. In the NVO3 network, the data 445 packet may also traverse a set of overlay nodes distributed in the 446 network. Overlay technologies or other tunneling technologies can be 447 used to stitch these service nodes or overlay node in order to form 448 end to end path. 450 When any overlay Segment or segment of service chain fails to deliver 451 user traffic, there is a need to provide a tool that would enable 452 users to detect such failures, and a mechanism to isolate faults. It 453 may also be desirable to test the data path before mapping user 454 traffic to the Overlay Segment or segment of service chain. 456 3.6.1. Focus on Service Function Chaining 458 When the service packets are steered through a set of service nodes 459 distributed in the network, each service node may work at different 460 layer above layer 3 and may have several SFs collocated with itself. 461 When OAM mechanism is applied, it is necessary to allow OAM packet To 462 be exchanged between these service nodes or service function at 463 different layers. When Service functions that are part of the SFC 464 doesn't support OAM capability(e.g., an SFC-unaware service 465 function), service node should be responsible for monitoring and 466 diagnosing and reporting service availability to the service 467 function. It is more desirable to allow a service function register 468 with service node. Either service function reports status to service 469 node or service node performs live check of the service function. 471 In addition, service functions usually don't have Layer 2-3 472 switching/routing capability and therefore are not aware of any OAM 473 function at Layer 2-3. Also when there are no OAM functions at 474 service Layers above layer 3, it is hard to identify layer that can 475 be used to gather OAM information when it comes to a fault situation 476 or degradation of performance. For example, when a data packet is 477 transmitted from one service function to another service function and 478 the data packet may be lost between two service functions or 479 discarded by either of them. Consider when two service functions are 480 embedded in (associated with) two different service nodes, how to 481 detect the fault between them and how to isolate problem to that 482 layer? 484 Editor's Note: Section 3.6.1 is too specific. This text can be 485 presented as an example to illustrate a problem not a problem per se 486 or moved to a use case draft. 488 4. Architecture Overview 490 Figure 2 shows the reference architecture for Layering OAM. This 491 reference architecture assumes that 493 o Any network element can use different technologies and 494 corresponding OAM on the same layer at the boundary of two 495 adjacent domains 497 o Any two network element may provide service delivery at different 498 layer 500 o Management entity can manage network devices in more than one 501 maintenance domains. 503 In this architecture, three layers are defined: 505 M1: "Data Plane layer" 507 M2: "Management Plane layer" 509 M3: "Service Plane layer" 511 In the M1 layer, a typical network can be partitioned into several 512 domains. Each domain has at least two MEPs and none or one to more 513 MIPs. MEP is a maintenance functional entity that is implemented 514 into a Network Element either at the maintenance domain boundary or 515 in the maintenance domain and can generate, send and receive OAM 516 packets. MIP is a maintenance functional entity that is implemented 517 into a Network Element in the maintenance domain and can forward OAM 518 packets. Either MEP or MIP may be at different layer and use various 519 different encapsulating protocols. 521 The M2 contains the interface which management entity uses to manage 522 individual network devices. In this document, we further require 523 management entities to use this interface as uniform interface (API 524 and or UI) to gather OAM information from MEP and MIP in the network 525 devices(either physical or virtual entity) and execute transactions 526 or operations on MEP and MIP across domains, layers and vendors. 527 Protocols that can be used to manipulate the configuration of a 528 network device include SNMP [RFC1157], Command Line Interfaces, 529 NETCONF [RFC6241], and other protocols. 531 On the M3 layer, there is a uniform interface (API and/or UI) that 532 covers all the managed devices and can execute network-wide 533 transactions. This layer allows applications and operators to 534 execute configuration, monitoring and action tasks across multiple 535 network devices, from a mix of domains, layers, vendors. Still the 536 abstraction level is that of the network elements themselves, so 537 whatever configuration, status, actions and notifications they 538 provide, that is what you get here, but without having to worry about 539 the location and the protocol to reach the device. 541 Service +-------------------+ 542 ---- Plane | Customer | 543 ^ Layer +-------------------+ 544 | 545 | +-------------+ +-------------+ 546 V | Management | | Management | 547 ---Management | Entity | | Entity | 548 ^ Plane +-------------+ +-------------+ 549 | Layer 550 | 551 | 552 | |----------------------------+ +---------------------+ 553 | |Maintenance Domain 1 | |Maintenance Domain 2 | 554 | | | | | 555 | | | | | 556 | NE| NE NE NE| | NE NE | 557 V +-----+ +-----+ +-----+ +------+ +-----+ +--+--+ 558 ---- | MEP +----+ MIP +--| MIP +----| MEP +-----| MIP +-----+ MEP | 559 +-----+ +-----+ +-----+ ++----++ +-----+ +-----+ 560 Data Plane | | | 561 Layer | | | 562 +----------------------------+ +---------------------+ 564 Figure 2 Architecture for Layering OAM in the management plane 566 An example of service-specific that depicts OAM layers can be found 567 in [RFC4176] (L3VPN case). 569 5. Existing Work 571 The following discuss related IETF work and is provided for 572 reference. This section is not exhaustive, rather it provides an 573 overview of few initiatives focusing on the pain-points of OAM: 575 1. [I-D.tissa-netmod-oam] is an important work that creates a YANG 576 unified data model for OAM that is based on IEEE CFM model. This 577 model may be used also for IP OAM functionality. This effort is 578 focused on the management plane of OAM and should be complemented 579 by an accompanying data-plane and/or control-plane work. It may 580 require also some extensions to address wider variety of 581 functions and technologies. 583 2. Several contributions conducted in the past years, had tried to 584 address new technologies using existing mechanisms. [I-D.jain- 585 nvo3-overlay- oam] and MPLS-TP OAM documents are only examples 586 for such efforts. 588 6. Architectural Consideration 590 6.1. Basic Components 592 6.1.1. Overlay OAM 594 6.1.2. OAM at the top of Layer 3 596 6.2. OAM Functions in the Data Plane 598 Many OAM functions may require protocol extensions or new protocol 599 development to meet the transport requirements. In the existing OAM 600 tools, Some of them providing rich functionality in one protocol,the 601 other providing each function with a different protocol and each 602 technology is developed independently. 604 To consolidate OAM in the data plane, the OAM in multi-layer 605 Environment is expect to support the following common OAM functions 606 used in OAM-related standards. These functions are used as building 607 blocks in the data plane OAM standards described in this document. 609 6.2.1. Continuity Check 611 This type of mechanisms check that the monitored layer and/or entity 612 are alive and providing path from specific point(s) to other 613 point(s). Some examples are IP Ping, BFD [RFC5880] and ETH CC. 615 6.2.2. Connectivity Verification 617 Verifying that the actual connection is consistent with the required 618 connection and no misconnection occurred. Some examples are IP Ping, 619 and ETH loopback. 621 6.2.3. Path Discovery 623 Used to discover the path that specific service traverses in the 624 network. Some examples are LSP Traceroute, IP Traceroute and ETH-LT/ 625 linktrace. 627 6.2.4. Performance Measurement 629 A function that monitors the performance parameters of a network 630 entity. Such parameters could be Delay, Delay-variation, loss, 631 availability of services and class of services. Examples are 632 TWAMP[RFC5357]/ OWAMP[RFC4656] and Y.1731,MPLS Loss and Delay 633 Measurement [RFC6374]. 635 6.2.5. Protection Switching Coordination 637 A function that is used to signal protection switching states and 638 commands. Examples are ETH APS messages and MPLS-TP Protection 639 Switching Coordination OAM [RFC6378]. 641 6.2.6. Alarm/defect Indication 643 A function that is used to indicate that a failure occurred 644 downstream or upstream within a connection/service. Used also to 645 trigger fast protection or to suppress alarms. Examples are ETH AIS 646 and ETH RDI, MPLS-TP RDI [RFC6428]. 648 6.2.7. Maintenance Commands 650 A function that is used to signal a maintenance state or command 651 within a connection/service. Examples can be ETH Lockout. 653 6.3. OAM in Management Plane 655 Management systems play an important role in configuring or 656 provisioning OAM functionality consistently across all devices in the 657 network, and for automating the monitoring and troubleshooting of 658 network faults. However OAM is not provision. In general, 659 provisioning is used to configure the network to provide new 660 services, whereas OAM is used to keep the network in a state that it 661 can support already existing services. 663 As we know each layer has its own OAM protocols. OAM can be used at 664 different levels of hierarchy in the network to form a multi-layer 665 OAM solution [RFC7276]. To support multi-layer OAM covering various 666 heterogeneous transport technologies, the OAM in the management needs 667 to be consolidated as follows: 669 o OAM information needs to be abstracted that are common to 670 different layer and different domain. 672 o Support customized OAM service, e.g., customized service diagnose. 674 o OAM information is provided to management entity from managed 675 device via a uniform interface (API and/or UI) 677 o Sets up MD MEP and MIP in the network provision phase 679 o Enables basic OAM functionality(e.g., enable the origin of ping 680 and trace packets or configure Connectivity Fault Management 681 (CFM)) on the managed devices in the service activation phase. 683 The different OAM tools may be used in one of two basic types of 684 activation: 686 o Proactive activation - indicates that the tool is activated on a 687 continual basis, where messages are sent periodically, and errors 688 are detected when a certain number of expected messages are not 689 received. 691 o On-demand activation - indicates that the tool is activated 692 "manually" to detect a specific anomaly. 694 7. Building on Existing Protocols 696 8. Scoping Future Work 698 This section includes a set of candidate items for activities to be 699 conducted within IETF. 701 These objectives are not frozen; further discussion is required to 702 target key issues and scope the work to be conducted within IETF 703 accordingly. 705 Candidate investigation items are listed below: 707 o Understand and discuss situations where an OAM protocol can be 708 tuned and optimized for a specific data plane. 710 o OAM consolidation in the data plane: 712 * Exchange OAM information at the service layer atop of layer 3. 714 * Deployed over various encapsulating protocols, and in various 715 medium types 717 o OAM consolidation in the management plane: 719 * Abstract OAM information common to different layers. 721 * Expose OAM information via unified interface to management 722 entities, independently of the layer they belong to. 724 * Discuss how information gathered from various layers can be 725 correlated for the sake of network operations optimization 726 purposes. 728 * Propose means to help during service diagnosis; these means may 729 rely on filtering information to be leaked to other layers so 730 that time recovery can be optimized. A typical example would 731 be efficient root cause analysis that is fed with input from 732 various layers. 734 * Propose means that would help to optimize a network as a whole 735 instead of the monolithic approach that is specific to a given 736 layer. For example, investigate means that would help in 737 computing diverse and completely disjoint paths, not only at 738 layer 3 but also at the physical layer. 740 9. Manageability Considerations 742 10. Security Considerations 744 Security considerations are not addressed in this problem statement 745 only document. Given the scope of OAM, and the implications on data 746 and control planes, security considerations are clearly important and 747 will be addressed in the specific protocol and deployment documents. 749 11. Acknowledgements 751 The authors would like to thank Romascanu, Dan, Tissa Senevirathne 752 for their valuable reviews and suggestions. 754 12. References 756 12.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", March 1997. 761 [RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., 762 and S. Mansfield, "Guidelines for the Use of the "OAM" 763 Acronym in the IETF", RFC 6291, June 2011. 765 [RFC7276] Mizrahi, T. and N. Sprecher, "An Overview of Operations, 766 Administration, and Maintenance (OAM) Tools", RFC 7276, 767 June 2014. 769 12.2. Informative References 771 [I-D.ietf-sfc-problem-statement] 772 Quinn, P., Guichard, J., and S. Surendra, "Network Service 773 Chaining Problem Statement", ID draft-ietf-sfc-problem- 774 statement, August 2013. 776 [I-D.jain-nvo3-overlay-oam] 777 Jain, P., "Generic Overlay OAM and Datapath Failure 778 Detection", ID draft-jain-nvo3-overlay-oam-01, February 779 2014. 781 [I-D.tissa-netmod-oam] 782 Senevirathne , T., Finn, N., Kumar , D., and S. Salam , 783 "YANG Data Model for Operations Administration and 784 Maintenance (OAM)", ID draft-tissa-netmod-oam-00, March 785 2014. 787 [RFC3411] Harrington, D. and R. Presuhn, "An Architecture for 788 Describing Simple Network Management Protocol (SNMP) 789 Management Frameworks", RFC 3411, December 2002. 791 [RFC4656] Shalunov, S., Karp, A., Boote, J., and M. Zekauskas, "A 792 One-way Active Measurement Protocol (OWAMP)", RFC 4656, 793 September 2006. 795 [RFC5357] Hedeyat, K., Krzanowski, R., Morton, A., Yum, K., and J. 796 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 797 RFC 5357, October 2008. 799 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 800 (BFD)", RFC 5880, June 2010. 802 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 803 Bierman, "Network Configuration Protocol (NETCONF)", RFC 804 6241, June 2011. 806 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 807 Measurement for MPLS Networks", RFC 6374, September 2011. 809 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 810 A. Fuligoli, "Packet Loss and Delay Measurement for MPLS 811 Networks", RFC 6378, October 2011. 813 [RFC6428] Allan, D., Swallow, G., and J. Drake, "Proactive 814 Connectivity Verification, Continuity Check, and Remote 815 Defect Indication for the MPLS Transport Profile", RFC 816 6428, November 2011. 818 Authors' Addresses 820 Qin Wu 821 Huawei 822 101 Software Avenue, Yuhua District 823 Nanjing, Jiangsu 210012 824 China 826 Email: bill.wu@huawei.com 828 Mishael Wexler 829 Huawei 830 Riesstr. 25 831 Munich 80992 832 Germany 834 Email: mishael.wexler@huawei.com 836 Mohamed Boucadair 837 France Telecom 838 Rennes 35000 839 France 841 Email: mohamed.boucadair@orange.com 843 Sam Aldrin 844 Huawei Technologies USA 845 2330 Central Expressway 846 NSanta Clara, CA 95051 847 USA 849 Email: aldrin.ietf@gmail.com 851 Greg Mirsky 852 Ericsson 854 Email: gregory.mirsky@ericsson.com 855 Pradeep Jain 856 Nuage Networks 857 755 Ravendale Drive 858 Mountain View, CA 94043 859 USA 861 Email: pradeep@nuagenetworks.net