%% You should probably cite draft-edprop-opsawg-multi-layer-oam-ps instead of this I-D. @techreport{ww-opsawg-multi-layer-oam-00, number = {draft-ww-opsawg-multi-layer-oam-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ww-opsawg-multi-layer-oam/00/}, author = {Qin Wu and Mishael Wexler and Pradeep Jain}, title = {{Problem Statement and Architecture for Transport Independent OAM in the multiple layer network}}, pagetotal = 12, year = 2014, month = jun, day = 5, abstract = {Operations, Administration, and Maintenance (OAM) mechanisms {[}RFC6291{]} are basic building blocks for every communication layer and technology. The current practice is that many technologies and layers have their own OAM protocols. In the current situation there is a little or no re-use of software and hardware in the existing OAM protocols. Vendors and operators waste a lot through the whole OAM life-cycle when a new technology is introduced. Integration of OAM across multiple technologies is extremely difficult. In many cases it is desirable to have a generic OAM to cover heterogeneous networking technologies. An example to this generic approach is the Bidirectional Forwarding Detection {[}BFD{]} mechanism that offers a way to monitor, troubleshoot and maintain the network and services in support multi-layer OAM independent of media, data protocols, and routing protocols. Generic OAM tools can be deployed over various encapsulating protocols, and in various medium types. An example of an environment in which a generic and integrated OAM protocol would be valuable is Service Function Chaining. A Service Function Chaining is composed by series of service Functions, that can act in different layers but providing an end-to-end chain or path from a source to destination in a given order {[}I.D-ietf-sfc-problem- statement{]}. In service function chaining environment it is necessary to provide end to end OAM across certain or all entities and involving many layers. OAM information should be exchanged between service functions in different layers while using various encapsulating protocols. In some cases OAM should cross different administration and/or maintenance domains. This document sets out the problem statement and architecture for the Generic OAM in the Service Layer Routing. This document will cover at least the basic OAM functions and information such as Connectivity Verification (CV), Path Verification and Continuity Checks (CC),Path Discovery / Fault Localization and Performance Monitoring necessary to monitor and maintain the network.}, }