Internet Draft Walter Weiss Expiration: October 2000 Lucent File: draft-durham-nim-req-00.txt David Durham Intel Andrea Westerinen SNIA Network Information Model Requirements Last Updated: 3/9/00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Conventions used in this document 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 [RFC-2119]. Weiss et al. [Page 1] Internet Draft Network Information Model Requirements March 2000 Status of this Memo................................................1 Conventions used in this document..................................1 Abstract...........................................................3 1. Introduction....................................................3 2. Motivation......................................................5 3. Specific Requirements for a Network Information Model:..........5 4. Glossary of Terms..............................................12 5. References.....................................................13 6. Author Information and Acknowledgments.........................14 Weiss et al. Expires October 2000 [Page 2] Internet Draft Network Information Model Requirements March 2000 Abstract Recently, a diverse set of technologies has been deployed to manage networking products. With some technologies, such as web-based management or proprietary text scripts, the data structures are defined in the absence of standards. With other technologies, such as MIBs, PIBs, or LDAP schemas, data structures are often defined many times over for the same application. For example, MIBs and LDAP schemas are being defined for DHCP, and for DiffServ, data structures are being defined in the form of MIBs, PIBs, and LDAP Schema. The problem is that this set of specifications often competes with itself and other methods that are used to manage devices. What is required is a common representation of data (an "information model") from which technology-specific data models can be derived to suit application-specific needs. Irrespective of the number of technologies that are deployed to manage networking devices, the industry would benefit from a more consistent specification of data structures across these technologies and the IETF would benefit from a reduction in the costs associated with defining these data structures. This document describes the requirements of an information model suitable for the modeling of network management constructs. The purpose of an information model is to represent data in a manner that is independent of technology and implementation. An Information model is used to unambiguously describe and define information, as well as the relationships between the entities that it defines. From this idealized information model, implementation-specific data models (which are bound to specific types of repositories and data storage and retrieval mechanisms, protocols, APIs, etc.) can be derived so as to avoid divergence of management information definitions between implementations. This document will describe requirements for the construction of an information model and the representation of basic constructs and data. These requirements are generally described in the areas of reusability, extensibility, associability, class naming, instance naming, expressiveness of data definitions through constraints, inheritance, etc. The purpose of this document is to ensure that the subsequent documents that describe the conventions for the information model and the information model itself are complete and consistent with the requirements stated herein. 1. Introduction As the Internet has grown and flourished, new technologies have been developed and deployed at a feverish pace. In the traditional IETF operations and management model, the working group developing the technology has also defined the data elements (usually in the form of MIBs) necessary to monitor and manage the technology. While this Weiss et al. Expires October 2000 [Page 3] Internet Draft Network Information Model Requirements March 2000 has been very successful, it has also led to a divergence of definitions and structures. In many cases, similar management elements that are to be applied to a specific technology have been completely reinvented in different working groups because of a lack of awareness. In other cases, duplication has occurred because of a subtle variation in the definition of the element or because the relationship between the data element and other elements is new or different. Divergence of management definitions and structures has resulted in an environment where programming effort is spent in the repetitive correlation, translation and data organization associated with each data management technology, instead of in doing actual management. There are three major benefits of an information model. First, it has a unique ability to consistently describe and organize various network management concepts and data for reuse across different applications. Second, it unifies information describing different aspects of managed objects (e.g., configuration and statistical data). In order to realize the benefits of an information model, each addition to the model needs to be scrutinized to ensure that the data being added is either new, or represents a refinement of existing data that have already been defined in the model. As such, the primary objective of this document is to specify the requirements for an information model that organizes information to achieve maximum reusability, as well as providing consistency in the information represented across various protocols and services. It is the goal of a network information model to act as a synchronizing root for other groups that are defining network management information so that consistency and reusability can be obtained across working groups. Just as MIB-I and MIB-II successfully standardized well-known constructs in the SNMP data model, this document will define the requirements for a more broadly applicable information model. This information model can then be expanded and exploited by a variety of other working groups within the IETF, and adapted to their transport-specific requirements. This will in turn produce domain-specific data models that are all derived from a common network information model. A key property of an information model is its universal applicability. Once the information model is established, standardized mappings can be developed for transforming the information model into specific data models, potentially including LDAP schema, MIBs, PIBs, and technology specific models used to implement low-level policies. This document only describes the requirements for the definition of common attributes, mechanisms and conventions for their organization into reusable data structures, and mechanisms for representing the attribute's relationships to other attributes and structures. The overall goal is to allow these attributes to be equally applicable to protocols, programmatic interfaces, and repositories. Weiss et al. Expires October 2000 [Page 4] Internet Draft Network Information Model Requirements March 2000 2. Motivation 1. Problem: With the exception of the Policy Framework's Core Information Model [PFCIM], no high-level network configuration information model exists in the IETF that is implementation- independent. Implementation independence yields a model that simply represents network constructs and data, relationships between constructs, and data constraints without regard to a particular data model, protocol, or repository. 2. Problem: The Distributed Management Task Force's (DMTF's) CIM (Common Information Model) [CIM] is not the optimal choice for a network information model. CIM provides no mechanism for defining class/model level constraints or for performing secure operations. CIM also has dictated a naming scheme that cannot be mapped into all implementations. Finally, the DMTF does not have the subject matter experts in networking, as does the IETF. Nevertheless, there is value in the modeling work done in the DMTF in terms of the definition of high-level constructs. Thus, CIM should be viewed as a starting point for development of a network information model within the IETF. 3. Problem: Current modeling representations are insufficient due to a lack of available tools, lack of a textual representation for ease of data exchange, or the expressiveness of the representations. In addition, for some or all of these representations, there is no constraint language, no suitable class naming conventions, no support for attribute level bindings, no ability to effectively create implementation-specific models, no ability to model associations, etc. Unfortunately, some are also dependent on proprietary or high-level graphical tools. It will be up to the working group to determine what tool set would be most appropriate in meeting the set of specific requirements listed below. 3. Specific Requirements for a Network Information Model: 1. The information model will need conventions for uniquely identifying the classes (constructs) and attributes (properties or data) that it defines, as well as complimentary classes developed by other working groups. Class naming and the ability to uniquely identify defined attributes is an important part of any information model. It is important that attribute naming conventions be developed that can be used equally effectively for reuse as well as to extend existing classes. The requirements will develop mechanisms that are complimentary to object-oriented naming conventions while not requiring the use of a central naming authority. There is a need to name class/attribute DEFINITIONS (as opposed to instances) uniquely without the need for a central naming authority (i.e., one mechanism might be to use GUIDs to identify classes/attributes). Weiss et al. Expires October 2000 [Page 5] Internet Draft Network Information Model Requirements March 2000 2. Experience has shown that different technologies (and even different implementations of the same technology) use different mechanisms for binding attribute groups to keys, instance identifiers, indexing schemes, or other data instance naming mechanisms. This model will avoid defining keys or rules for key bindings, unless no other alternative for interoperable operation can be defined. Mechanisms will be provided for supporting keys for mappings to various technologies, as the need for instance identification is universal. Instance naming needs to be flexible as implementations vary. That is, keys can be created in a number of ways, we assume they exist, and uniqueness within a context is required, but we will not force a particular keying mechanism. It will however, be important to understand how a particular implementation defines its keys and thereby names instances. Without this information, mapping between implementations will be difficult or impossible. 3. Exclusively using graphical models such is not suitable as there is a need for textual representations. Graphical models are also not easy for a computer to parse and require expensive tools. Thus, it is necessary that this information model chooses a textual representation suitable for representing an information model, completely & unambiguously, and is readily parseable by a computer program. Graphical methods can always be used to visualize this result. Ideally, the textual representation also has some tools associated with it. It should be up to the WG to decide the most appropriate data definition language based on these requirements. 4. To facilitate reuse, all data elements (attributes) of the information model must be clearly defined in terms of characteristics, scope and relationships to other attributes. This can be achieved through data types and value bounding which should be explicitly defined for attributes, classes, and associations between NIM constructs. Also, the ability to specify constraints is needed. When complete, the resulting model must be completely unambiguous. Constraints refer to the ability to completely specify the characteristics of one attribute/class/association or a set of these and how these constructs interact with and relate to others within the model. If a concept is defined in a broad or high-level manner in the information model, then it is more likely that different implementations that define their own mappings of it will be inconsistent. This undermines the basic benefit of the information model. The subsequent list of constraints, while not necessarily complete, is a minimal set of elements required for a more complete specification of attributes. Where the data modeling language is not capable of specifying the constraint, the information model is required to provide the most precise specification of attributes possible. Further, when a Weiss et al. Expires October 2000 [Page 6] Internet Draft Network Information Model Requirements March 2000 specific mapping of the information model to a specific data model is defined and the target data modeling language has a less robust mechanism for expressing constraints, additional documentation should accompany the data model to minimize confusion. If an information model representation is not capable of expressing a new kind of constraint, then this new constraint should be added to the information model in a well-defined manner. Need for data-level constraints: * Constraints for attributes. E.g., Attribute X is an integer that can have values in the range 10-100 and 234-235. * Constraints for classes. E.g., Class A should be created when Class BÆs attribute x is "OK". * Constraints for class/attribute associations. Allow instance class A to be associated with instance of class B only if not already associated with class C. * Constraints for attribute transactions, attribute A and attribute B have transactional dependencies (need to be modified together under a given context). * Another common characteristic of an attribute is its ability to be modified. While the majority of attributes can be retrieved and altered, for some attributes, such as counters or hard wired MAC addresses, it is only possible to retrieve the value but not to alter it. There may even be instances where an attribute value can be altered, but not retrieved. To facilitate consistent interpretation, each attribute definition must specify whether the attribute is read-only, read-write, or write-only. * There are many situations where an attribute is not required for the complete definition of the class. In other cases, an attribute is crucial for the definition of the service. Therefore, each attribute in the information model must specify whether an attribute is optional or required. * In some cases, there are attributes within the same class that have interdependencies. For example, two attributes together may define a x/y coordinate. There may be more extreme forms of relationships where one attribute may affect the value or range of values for another attribute. One such relationship exists in IPSEC, where the type of security algorithm determines the range of possible values for other attributes such as the corresponding key size. The most extreme form of multi-attribute relationships is a set of attributes that are dependent on each other for consistency. For example, a class may have two attributes, one expressing a date and the other expressing a day of the week. When the day of the week is changed the date should change simultaneously, and visa versa to prevent inconsistencies. Irrespective of the complexity of the relationship between attributes, the information model must express the relationship between attributes. 5. Need for an association mechanism. Associations describe relationships between classes. Some examples are dependency or whole-part relationships. There are a few things to note about associations: 1) relationships are primarily between only two class Weiss et al. Expires October 2000 [Page 7] Internet Draft Network Information Model Requirements March 2000 instances; 2) the same relationship may be repeated for a particular instance, associating that instance with others; and 3) since relationships are usually implemented as classes, they can sometimes have data as well as methods. An example of each of the previous points is that a device has various types of software associated with its configuration, operational and instrumentation software are just a few examples. So, software can be "associated" with one or more devices, and devices can have one or more pieces of software. The use of the software for the device can be described as part of the association. [Note: While at the information model level associations should be modeled as separate classes, some data models may only support associations as inline references that are part of a data class. It is noted that separate association classes force data classes to be maximally reusable, as the data class then makes no assumptions about how it can be related to other classes.] 6. Inheritance model: Inheritance allows the information model to avoid redundant data definitions among peer constructs, and define appropriate levels of abstraction and complexity. Single inheritance is recommended to optimize the model and its processing requirements. It is not required that the entire information model be derived from a single root. Those data models that require a single root, and a key binding consistency relative to the root, should provide for these requirements in the mapping of the information model to the specific data model. 7. The information model will define a general mechanism for representing possible access rights to attributes, classes or groups of these. The information model will not define what set of access rights a given class or attribute should have. These should be defined in the context of specific applications. In addition, some mappings of the information model to specific data models may not support access rights. For example, while CIM does not support read/write semantics and MIBs have no semantics for user rights, LDAP schemas can support both. Therefore, it is up to the mapping of the information model to a specific data model to determine what, if any, security rights are appropriate. 8. Mechanisms for describing the fundamental data types of attributes, as well as describing arrays of these fundamental types, are required. Possibly, the binary representation of the attributes may be specified. 9. Arbitrary groupings and combinations. There is a requirement that data be defined completely and unambiguously within the information model, utilizing the representation, constraint and encapsulation mechanisms discussed earlier. The concept of general containers, bags, groups, etc. are still allowed as arbitrators, but they must always encapsulate completely defined (meaning constrained) data. 10. When hundreds of classes may be defined in the information model, there is a need to create "standard" combinations of classes and associations, describing common scenarios or data models. It should be possible to define these combinations of classes and Weiss et al. Expires October 2000 [Page 8] Internet Draft Network Information Model Requirements March 2000 associations in the information model. And, for efficiency, the combinations should be instantiated, retrieved or manipulated as a whole. These standard combinations would be useful in reducing the arbitrariness of which classes to use, to solve a particular management modeling problem. 11. In an object-oriented implementation, a class' methods describe the actions or behaviors that are appropriate for, and can be invoked against, an instance. Methods allow the specification of return codes and input/output parameters, further influencing the specific action or behavior. In an information model, these concepts may be described as "signatures" or as fully-defined methods. (The correct approach must be determined as work on the Network Information Model proceeds.) The word, "signature", means the specification and grouping of attributes within an object, while "method" means a specific and predefined format and syntax. The goal of either a method or signature is to describe and invoke well-defined behaviors -describing the intent of the behavior, return code/status and parameters. Note that this is not a requirement for get/set or constructor/destructor methods, which are very much implementation dependent. It is a requirement to allow the definition of input/output parameters and return codes for behaviors and actions, and then specifically invoke their execution. Examples are "save/restore configuration" or a "reset" request issued to a network device. The ability to pass parameters, establish well-known return codes ("0" for successful, "1" for error or "2" for not supported)and invoke a behavior at a particular point in time are invaluable. In reality, few signatures or methods may be defined. This is because any specified action/behavior must be well-understood and consistently defined, in order to be abstracted and standardized in the information model. 12. It is assumed that the information model will model both static and infrequently changing data, as well as highly dynamic and state- dependent attributes. Since data update is assumed to occur, the model should be capable of defining subscriptions to subsets of the information. In this way, either data push or data pull may occur to acquire updated information. 13. As this information model will likely be mapped to a variety of data models and implementations, it is necessary that mechanisms be provided that ensure compliance to the information model. [Note: The specific requirement for this assurance is TBD and will be addressed, or removed, after further team discussion.] 14. As the information model will be deployed across a variety of implementations, it is recognized that not all implementations will Weiss et al. Expires October 2000 [Page 9] Internet Draft Network Information Model Requirements March 2000 be capable of supporting the model completely. Divergences from the model should be expressed in the form of a capability set that describes exactly what subset of the model is supported by a particular implementation or system. Further, as capability distribution is a service, the information model must specify a mechanism that allows for a consistent representation of capabilities across various management technologies. 15. The information model must allow classes to contain the attribute (property) set of other classes. This will maximize reuse and allow data to be completely described with minimum redundancy. For example, Class XYZ can contain as attributes Class ABC and Class DEF. The result would be that Class XYZÆs attribute set would be a superset of Classes ABC and DEF. Class containment should act as a mechanism for easily defining and describing class aggregations. LDAP schema definitions currently have the opposite behavior and instead constitute attribute merging. An information model should not have this same limitation. For example, in NIM, one may create a class called IPADDRESSMASK that defines and constrains IP subnetting. Using NIM, one then could create a new Filter Class that looks something like this: class Filter: { IPADDRESSMASK SourceIP; IPADDRESSMASK DestinationIP; PORTRANGE SourcePort; PORTRANGE DestinationPort; PROTOCOLID Protocol; }; Where IPADDRESSMASK is defined as follows: Class IPADDRESSMASK: { UINT32 IPAddress; UINT32 SubnetMask; }; Here the IPADDRESSMASK classes are not to be merged into one attribute, but remain two individually identifiable "contained" classes, one useful for defining the source, another for defining the destination of traffic in the context of the new class called Filter. It is important that all data models have standard mappings of this strictly definitional model into their data model-specific forms. 16. There are some attributes that, when changed, only take effect when the service is brought down or the system is rebooted. There are also mechanisms deployed that depend on polling to cause a modification of an attribute value to take effect. The model must Weiss et al. Expires October 2000 [Page 10] Internet Draft Network Information Model Requirements March 2000 fundamentally distinguish between the retrieval of attributes from the assignment of attributes, as these functions can often be asynchronous depending on the data and the technology being used to manipulate it. 17. The information model must allow for forward and backward compatibility as the model evolves. In addition, the model must support the ability to be extended for specific implementations in a manner that will allow multiple different extensions to coexist both from a programmatic and storage perspective. Weiss et al. Expires October 2000 [Page 11] Internet Draft Network Information Model Requirements March 2000 4. Glossary of Terms NIM: Network Information Model. CIM: Common Information Model proposed by the Distributed Mangement Task Force (DMTF). Constraint: A mechanism for bounding an attribute or class value to allowed values/ranges/targets/bitmaps etc. Data Type: A mechanism for identifying the binary representation of an atomic (as opposed to composite) attribute. Definition Name: Unique name used to identify an attribute or class definition. Instance Name: Key: Index: Name used to identify an instance of an attribute or class (recognized but not explicitly defined by this WG). NIM Attribute: An atomic or composite data type that is fully described, typed, uniquely named, and bounded via constraints. NIM Class: Synonymous with attribute although typically refers to an aggregation or set of attributes which can also inherit properties from parent classes to optimize data definitions. Information Model: Universally applicable model for representing and describing information that is not perverted by the shortcomings of a specific implementation. Data Model: An implementation specific or implementation constrained derivation of an information model. One information model can be used to develop multiple consistent data models. Weiss et al. Expires October 2000 [Page 12] Internet Draft Network Information Model Requirements March 2000 5. References [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers [CIM] http://www.dmtf.org/spec/cims.html [PFCIM] Moore, B., and E. Ellesson, J. Strassner, "Policy Framework Core Information Model", draft-ietf-policy-core-info-model- 02.txt, October 1999. Weiss et al. Expires October 2000 [Page 13] Internet Draft Network Information Model Requirements March 2000 6. Author Information and Acknowledgments Special thanks to John Strassner for his many helpful comments and significant edits to this document. Walter Weiss Lucent Technologies 300 Baker Ave. Concord, MA. 01742 Phone: +1-978-287-9130 Fax: +1-978-287-9050 E-mail: wweiss@lucent.com David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 503.264.6232 David.Durham@intel.com Andrea Westerinen Storage Networking Industry Association td@snia.org 425-891-8407 2570 W. El Camino Real Mountain View, CA 94040 Weiss et al. Expires October 2000 [Page 14]