Network Working Group M. Alexander Internet-Draft WU-Wien Intended status: Standards Track March 22, 2007 Expires: September 23, 2007 NE/Facilities/Lines/Protocols/Services Modeling draft-alexan-datamod-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Alexander Expires September 23, 2007 [Page 1] Internet-Draft Data Modeling March 2007 Abstract This draft presents a framework document for modeling network elements (NE), facilities, lines, protocols and services for substantially easing development and operation of element manager systems (EMS), network management systems (NMS) and operations support systems (OSS). The framework is independent of the access method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC, etc.) It covers configuration, alarms, current-historical performance, accounting management and security. The frameworks builds on and reuses the existing base of MIBs. The documents presents a light-weight, structured and very simplified framework and method to data modeling for defining and maintaining meta models, device etc. models, and device etc. descriptors. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 5. Independence from Access Methods . . . . . . . . . . . . . . . 10 6. Core Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Secondary Scope . . . . . . . . . . . . . . . . . . . . . . . 13 8. Items NOT in Scope . . . . . . . . . . . . . . . . . . . . . . 14 9. Dependencies-Requirements on Others . . . . . . . . . . . . . 15 10. Process-Cycle Time . . . . . . . . . . . . . . . . . . . . . . 16 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 14. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Alexander Expires September 23, 2007 [Page 2] Internet-Draft Data Modeling March 2007 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Alexander Expires September 23, 2007 [Page 3] Internet-Draft Data Modeling March 2007 2. Problem Statement Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch. In a common fallacy, programmatic access methods towards an NE such as operations on attributes via SNMP, CLI or XML-Netconf etc. are frequently taken as equating to 'network management'. Yet, in order for a Craft Terminal/EMS/NMS/Service Management System to provide sensible services to either a GUI operator or a mechanized interface, the device data of an NE has to be in a structured model. Managed objects alone - but in rare cases - do not allow to provision a subscriber, retrieve an alarm, examine a performance metric etc. From e.g. an NMS viewpoint, they tend to be 'flat' data structures which need to be put into a defined structure the NMS can understand so to perform any logical flow of actions on them. That is, a "flat" device attribute list does not enable an operator or mechanized interface to manage an NE. Unfortunately, there is little commonality in data models, respectively managed objects exposed by NEs to their northbound interfaces. Even worse, the plethora of NMS/ Service Managers each have their own models, leading to the present- day situation in which a large set of management systems with different models map to a large set of NEs with - differing models, both of which ever changing. The following comparison highlights the problem from an implementation-effort perspective: It takes an experienced NM person about a year to understand a medium-complexity carrier device's data model in its entirety. This familiarity is necessary to build EMSs/ NMSs/Service Management Systems with human-operable GUIs, or machine- to-machine interfaces for high-level operations (enable a service/ disable a service etc.). To adapt a given NMS's model for only one NM constituent, such as configuration management, the effort to initially map and then maintain the NE's to the NMS's data model is vast. For example, only to cover configuration management of a single service of a multi-service switch man-years of effort may be necessary to match the two models. Yet in contrast, the effort to effect an attribute value change with SNMP, CLI or XML- Netconf etc. even with little prior knowledge of a device's functionality, model and behavior is comparatively minuscule. Setting a given NE attribute via a prompted CLI may take Alexander Expires September 23, 2007 [Page 4] Internet-Draft Data Modeling March 2007 an NM-person with only rudimentary knowledge of a given device minutes; SNMP, depending on the design of the MIB takes longer, similarly for XML or CORBA etc. Comparing the discrepancy in the distribution of efforts again: the implementation of one leg of NM tends to be measured in man-years, the second leg of device access may range from man-hours to man-weeks. Logically, one might suppose that standards development would match this distribution. Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. The problem was recognized early, but it took time until technologies such as markup languages, with their key property of being human readable, reached the mainstream and ubiquity: "Although some positive sentiment was expressed for defining a kind of "super SMI" metalanguage to aid in the definition of a general API, it was not clear whether the current crop of supporting protocols had sufficient semantic commonality to be used in this way. The matter remains open for investigation." [Vince Cerf, RFC 1109] Alexander Expires September 23, 2007 [Page 5] Internet-Draft Data Modeling March 2007 3. Use Cases The framework addresses the following use cases: o Design and Implementation of EMSs o Design and Implementation of NMSs o Design and Implementation of OSSs o Design and Implementation of Northbound and Southbound Interfaces EMSs and NMSs are composed of the following main components: access to NEs, data model and database (a special case being '"MIB-less" managers with limited modeling and no database), NE-logic to augment NE methods or define new ones using entities from the NE's exposed management functionality, application logic, presentation logic, besides security and system functions at al. Over the mission-life of an EMS/NMS/OSS/SMS, the component that consumes a majority of design and development resources is the data models and their implementation. This applies to single - NE/Service managers as well as multi NE-type or service managers where the efforts to initially define and stay current with the respective NE/ service versions increases non-linearly. In some cases point-of- diminishing returns in multi-NE EMSs, at large due to NE model differences. They result in more and more device- specific adaptations and shortcuts to the EMS's own meta model or in the manager's application logic leading to eventually highly complex and time-consuming coverage of additional devices and releases. EMS/NMS are the more usable the more depth the NEs models have. In a polar extreme, an EMS with a GUI that only offers a human operator a flat representation of an NE data structure, requires a fair amount of device/device model/device behavior knowledge on part of this human operator. If, however, the device model is detailed, an EMS can e.g. give the human operator a detailed view of the node, being able to drill down from e.g. a shelf view down to management information of given protocol running on a given port. Covering a new NE with e.g. 2000 managed objects based on an "average" MIB model in an existing EMS with pre-existing related coverage takes -- depending on the granularity scope -- on the lower- end several manyears. People doing the device integration have to build a well-structured, multi-level model of the device in the EMS so for the EMS to be easy to use for a human operator. If the device MIB does not adequately convey the NE behavior, the Alexander Expires September 23, 2007 [Page 6] Internet-Draft Data Modeling March 2007 facility hierarchy and interrelation of objects and their attributes, the effort can be substantially higher. The modeler(s) adding support for a particular device to an EMS may have to (re) model the equipment's hierarchy and discover its behavior through (lengthy) series of experiments. If, in contrast, if there is data model than conveys managed objects in a normative way and there is a normative namespace/meta model, then the task becomes substantially easier. If, in addition, the device model specifies rules and equipment behavior in at least a semi-normative way, then high-depth support for the particular device becomes attainable in a fraction of the time than having to go from plain MIBs. Similarly, if the task were to build a prompted CLI for the device, the main effort would be create a definition file that specifies the CLI hierarchy levels and which operations would be permissible at a given level -- a formidable task for a large MIB. In contrast, if there is a namespace/meta model in conjunction with a device data model that is based on a device class model, then the prompted CLI (but of the application logic) could to a large extend be derived or generated from the models. The same goes for building NMSs, which allow for drilling down into lines and devices. Yet, NMSs in addition require alarm templates. Creating alarm templates involves in depth knowledge of the equipment's behavior, if it has not been properly abstracted. Creating alarm templates for root-cause analysis involving multiple devices without pre-existing models is highly time and resource intensive, possibly involving multiple testing cycles. The proposed approach for simplifying alarm modeling is: an alarm meta model as part of the namespace/meta model and an alarm template class model as part of the device/service/protocol class model. Not a use case per se is the necessity to uniquely locate equipment, facilities, lines and their termination points in a network. If a large number of network elements are involved, then they should be put into inventory using a schema which incorporates at least a unique serial, a unique product ID bound to the vendor partnumber, vendor partnumber, the container equipment (for e.g. cards), the organization's location classification (such as country/city/ location/room), a unique serial and dating. There needs to be a meta model for inventory codes and schemata for the individual types of inventory. The binding between the equipment type categories and the unique serial could be done based on a normative registry, similar to the binding between domains and IP address in DNS. Implementing EMSs/NMSs/CLIs and OSS interfaces are different use Alexander Expires September 23, 2007 [Page 7] Internet-Draft Data Modeling March 2007 cases from the creation of device models. Provided a namespace/and class-type meta models for the device exist, individual vendors can model their own devices or charter 3rd parties to do so, thereby allowing a wide range of NMS/OSS software to recognize and manage their devices. They could be cataloged and put into a repository, and be bound against the various (vendor dependent) unique serials from the last paragraph. Alexander Expires September 23, 2007 [Page 8] Internet-Draft Data Modeling March 2007 4. Backward Compatibility MIBs are the most common data structure for internal device data representation. MIBs are also the most common non-proprietary EMS/ NMS/OSS data representations. The investment in them is vast, hence it should be preserved. Therefore, backward compatibility with MIBs SHALL be preserved. Existing MIBs need to be covertable ("import") into the new set of DM models. This can be done in two ways: (a) the could be converted into an applicable regular namespace, or (b) into a free form variant not having the property of a direct line to a common root. Reverse imports of DM Models into MIBs is not feasible. MIB conversion does not have to use a generative approach. While it may be possible to write converters that do not take manual intervention, in order to produce (b), or a converter that takes conversion directives embedded or references in the MIB source, this approach will not yield well-structured models for (a). In order to convert existing MIBs into the new namespaces and models derived from the new meta models, partially automated/facilitated/tools supported manual conversion will be necessary. Alexander Expires September 23, 2007 [Page 9] Internet-Draft Data Modeling March 2007 5. Independence from Access Methods Data Models need to be independent of access methods; Talking to a device via SNMP, a CLI, Netconf, CORBA, XML-RPC, Batch Config Transfer, etc. is relatively insignificant in time/resources relative to designing-implementing-maintaining data models. For example, a clean data model of a 5000 managed objects device can be talked to in ANY of the above access methods provides the device has an agent that exposes the objects. The ratio of efforts between adapting an EMS/NMS/OSS to talk to a particular device access method protocol agent to refining an "average" MIB data model approaches 0 the more complex a devices is. Alexander Expires September 23, 2007 [Page 10] Internet-Draft Data Modeling March 2007 6. Core Scope The core initial focus includes a set of meta models, an initial network type focus, and service focus. Prior to that, a set of initial namespaces such as for the ones below is necessary: o Base equipment hierarchy (rack::power::supplies::shelf::slot:: port::facility::protocols ::services o Base network types: IP, SDH SONET, ATM, Ethernet The proposed initial network type focus is: IP-Routing, Ethernet, SDH/SONET and ATM. The proposed initial services to model are: barebones SIP, Ethernet VLANs, DiffServ (as a service in the models). Prerequisite to model network types or services are a set of meta models shown in Figure 1 below: The respective layers are explained in the following. +-----------+------------------------------------------------------+ | Layer VII | Device/Line/Service/Protocol Instance | +-----------+------------------------------------------------------+ | Layer VI | Device/Line/Service/Protocol Model | +-----------+------------------------------------------------------+ | Layer V | Device/Line/Service/Protocol Type Meta Model | | | Derived from class model | | | Captures behavior, rules | +-----------+------------------------------------------------------+ | Layer IV | Device/Line/Service/Protocol Class Meta Model | | | Alarm template class model | +-----------+------------------------------------------------------+ | Layer III | Namespaces/Meta Model | | | Derived from existing CLI (option?),from scratch | | | Constructs etc. | | | Alarm template meta model | +-----------+------------------------------------------------------+ | Layer II | Object Model | | | Prototype methods-operations, data types | +-----------+------------------------------------------------------+ | Layer I | Access Method | | | SNMP, CLI, Netconf, CMIP, CORBA, XML-RPC, SOAP .. | +-----------+-----------------------------------------------------+ Figure 1 Layer I (Access Method) is the protocol used to talk to the NE. As emphasized before, in the existing status-quo given different data Alexander Expires September 23, 2007 [Page 11] Internet-Draft Data Modeling March 2007 models on the device and on the manager, the effort to code the NE communication with a given protocol is relatively low compared to refining the respective manager models to match that of the device. I.e. is the access methods offers sufficient operations to act on a given managed object, the choice of protocol may be a matter of other criteria. Layer II (Object Model) defines the base primitives including operations that can effect managed objects. A superset of data types should also be defined in this layer. Layer III (Namespaces/Meta Model) is (a) concerned with the naming hierarchies (namespaces) for devices/lines/services and protocols. For example, part of the base equipment hierarchy from before (rack:: power::supplies::shelf::slot::port::facility) would form a namespace. The meta model is (b) the prototype model for the higher layer device/line/service/protocol {Class Meta Model, Type Meta Model, Model and Instance}. That is, it integrates the object model and the namespaces and provides a framework model for the higher layers and defines constructs, language they can utilize. In addition, a meta model for alarm templates needs to be defined at this layer. Layer IV (Device/Line/Service/Protocol Class Meta Model) defines meta models for classes of e.g. devices. An example for classes of devices are Routers, Ethernet switches, or ATM switches. In the same layer, alarm template class models (deriving from the alarm template model on Layer III) need to be defined in order to support root-cause alarming with a high degree of accuracy. Layer V (Device/Line/Service/Protocol Class Type Model) extends the Layer IV Class Meta Model. It defines types of device-line/service/ protocols further. For example, the class routers might branch into routing switches, pure IP routers, multi-protocol routers, access routers, edge routers, core routers, etc. Furthermore, the layer suits defintions of rules and attributes describing the equipment type's behavior. Layer VI (Device/Line/Service/Protocol Model) extends the type meta model with information that is particular to a specific device/line/ service/protocol. For devices, this might be a specific product or product range in case of an equipment vendor. For services, it might be a service as deployed by a specific operator. Layer VII (Device/Line/Service/Protocol Instance) is the actual instance of the e.g. device model which could be a data model for a particular vendor's device at a given release level. Alexander Expires September 23, 2007 [Page 12] Internet-Draft Data Modeling March 2007 7. Secondary Scope The secondary scope follows in sequence after the initial scope, largely because of dependencies. It includes: o Unique equipment/line locators o Alarm template registries o Protection, failover modeling (1+1, 1:n, 1:1, etc.) o Device/service/protocol models to be defined in the respective areas/WGs Unique equipment/line locators have been discussed before as a use case. As indicated, a schema which incorporates at least a unique serial, a unique product ID bound to the vendor partnumber, vendor partnumber, the container equipment, the organization's location classification (such as country/city/location/room), a unique serial and dating is necessary. This needs to be in conjunction with a meta model for inventory codes and schemata for the individual types of inventory. The binding between the equipment type categories and the unique serial could be kept in a public database similar to a registry. Along the same lines, (a) registry(ies) could be formed for alarm templates. The secondary scope also includes protection, failover modeling (1+1, 1:n, 1:1, etc.), which involves a revision of all metamodels. At the 2nd stage in the effort, it could also be trialed that individual areas/ working groups define their device/service/ protocol models independently, based on the underlying meta models. Alexander Expires September 23, 2007 [Page 13] Internet-Draft Data Modeling March 2007 8. Items NOT in Scope The data model SHALL NOT include support for Business Support Systems (BSS) and workflow in general. It is SHALL NOT attempt to cover all aspects of enterprise and carrier network operations. Alexander Expires September 23, 2007 [Page 14] Internet-Draft Data Modeling March 2007 9. Dependencies-Requirements on Others There are no hard requirements on other efforts. One item, for which there exists a workaround, would be good to have at the earliest point though is a Netconf RPC call in-line with the DM object model (layer II): Netconf 1.0 presently allows for free-form RPC calls. The DM effort and anybody involved in EMS/NMS/OSS modeling would in general greatly benefit if devices were to expose more high-level functions/methods. For example, instead of having to set a large number of attributes in order to provision a customer on a given port, a method provision_customer() exposed by the NE, described in the data model and called by the EMS/NMS/OSS would greatly reduce complexity. Having a formalized method call which is congruent with the object model might induce more vendors to expose simplified methods in their devices. Elegant integration of management information into protocol specifications natural gets much easier for protocol designers if Protocol Class Meta Model is available. Once this is the case, individual working groups outside the OPS area should be able to define their own protocol models. Hence, there is a depency from them on the availability of the meta models. Alexander Expires September 23, 2007 [Page 15] Internet-Draft Data Modeling March 2007 10. Process-Cycle Time The complexity for DM is significantly higher than for many protocols (e.g. not TCP though). A high initial rate of changes in the specifications is expected until steady-state is reached. Still, even in steady-state a comparatively large number of changes per revision is expected to be occuring in the regular update cycle. Branches of the models outside the main modeling effort will need to be allowed. Here, the process might become to fold normative schema extensions into main as much as possible, allowing of private branches and allowing specialization without folding. The target time for the first iteration of the initial scope is one year. The projected cycle times are: o Device/Line/Service/Protocol Instances: on discretion of equipment/nm vendors o Device/Line/Service/Protocol Model: initial: 6 months, steady- state 6 months, synced with protocols o All meta models: initial: 6 months, steady-state 8-9 months o Object model and data types: initial: 6 months, steady-state 3-4 years or longer Alexander Expires September 23, 2007 [Page 16] Internet-Draft Data Modeling March 2007 11. Open Issues Three issues are not addressed in the present draft: Rules language, metamodel language and the issue of state model inclusion and language. While good data modeling uses overspecification (which facilitates device modeling), the immediate benefit from the inclusion of a state model and a state model specification language is lower than for the core namespaces and metamodels. Once at least the primary scope has completed, the addition of state model information would aid the EMS/ NMS/OSS modeler in further codifying the equipment's behavior, facilitating tasks such as deciding on the sequence when to issue operations and with timing issues in general. Similarly, rules could be specified in a separate rules language, which could be added at a later point. The issue is different, however, for a metamodel language. Having a full language for it would greatly increase expressivity. Introducing a metamodel language at a different time than from the onset is not a good option though. Alexander Expires September 23, 2007 [Page 17] Internet-Draft Data Modeling March 2007 12. Security Considerations The framework goes beyond assuming both the management stations and the NEs being in secure networks. The Meta models SHALL include both authentication and multi-level authorization which to be defined in separate drafts. The frameworks covers both, manging of NEs providing security functionality, and the authentication and authorization of the NEs per se. Alexander Expires September 23, 2007 [Page 18] Internet-Draft Data Modeling March 2007 13. Acknowledgements The author would like to acknowledge inputs in the form of drafts, comments, discussions etc. from the following people: David Appel, Ray Atarashi, Jan Bergkvis, Andy Bierman, Ron Bonica, Sharon Chisholm, David Harrington, Robert Natale, Hideki Okita, Amy Pendleton, Dan Romascanu, Juergen Schoewaelder, Henning Schulzrinne, Thomas Stolz, Iijima Tomoyuki and Margot Wasserman. Alexander Expires September 23, 2007 [Page 19] Internet-Draft Data Modeling March 2007 14. Normative References [RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management Review Group", RFC 1109, August 1989. [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. Alexander Expires September 23, 2007 [Page 20] Internet-Draft Data Modeling March 2007 Author's Address Michael Alexander Wirtschaftsuniversitaet Wien Augasse 2-6 Vienna 1090 Austria Phone: +43.1.31336.4467 Email: malexand@wu-wien.ac.at Alexander Expires September 23, 2007 [Page 21] Internet-Draft Data Modeling March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Alexander Expires September 23, 2007 [Page 22]