Internet Draft Walter Weiss Expiration: January 2001 Ellacoya File: draft-durham-nim-req-01.txt David Durham Intel Andrea Westerinen Cisco Network Information Model Requirements Last Updated: 7/7/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 July 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:..........6 4. Glossary of Terms..............................................13 5. References.....................................................14 6. Author Information and Acknowledgments.........................15 Weiss et al. Expires January 2001 [Page 2] Internet Draft Network Information Model Requirements July 2000 Abstract As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These very from Web based products, standard management protocols, and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the programmatics, with proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that a single application such as DHCP or Differentiated Services may be represented in many different inconsistent fashions. Even the existing standard descriptive technologies have not been focussed on re-use across domains and commonality. The situation would be significantly improved if there were to be a common representation of data (an "information model") from which technology-specific data models can be derived to suit application- specific configuration and management needs. This would allow the industry to build common descriptions, resulting in consistency across the paradigms, and better interoperability. Such an "information model" would also assist other IETF working groups by reducing the work needed to determine how to represent those parts of their technology that are already in the common model. 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 modeling constructs. These requirements are generally described in the areas of reusability, extensibility, associability, class naming, instance naming, expressiveness of data definitions through constraints, and inheritance. 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 Weiss et al. Expires January 2001 [Page 3] Internet Draft Network Information Model Requirements July 2000 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 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, as opposed to implementing a single management interface/infrastructure. There are two 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 constructs 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 an information model that is applicable to largest possible cross-section of network management paradigms and protocols. 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 wide spread 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 device models (such as [Device]) using the Policy Framework Core Information Model [PCIM] to mechanism-specific policies. This document only describes the requirements for the definition of common attributes, mechanisms and conventions for their organization Weiss et al. Expires January 2001 [Page 4] Internet Draft Network Information Model Requirements July 2000 into reusable data structures, and mechanisms for representing the attribute's relationships to other attributes and structures. In addition, requirements for specifying methods will also be described. As methods and attributes provide an alternate means for describing a management interface, guidelines for using each in a consistent manner will be developed in a separate document, and is therefore outside the scope of this document. The overall goal is to allow the modelÆs attributes and methods to be equally applicable across a broad range of paradigms, protocols and interfaces. Specifically, there are some paradigms that treat a networking device as a client while other paradigms treat the device as a server. There are some paradigms that assume a synchronous (transactional) interface between the managing and managed elements while other paradigms assume an asynchronous model. With some management paradigms a single instance of a structure is applicable to many instances of devices or device components (COPS-PR, SNMPCONF, or shared repository structures) while in other paradigms each component is managed directly on a one-to-one basis. These paradigms can be implemented in a variety of ways. In some cases there may be programmatic interfaces that directly manipulate management structures through methods or remote procedure calls. In other cases a repository, such as a directory, may be used to store configuration information in a central store or even use the store to pass information between networking components. Paradigms can even take the form of simple text scripts that get pushed into a device. While any of these scenarios could leverage a shared information model for representing network configuration and management structures, the degree to which a common model can be mapped to all of these implementations will vary on a case-by-case basis. It is in fact the purpose of this model to be able to represent more relationships than can be easily reflected in the common subset of all implementations. Representing such methods and relationships in a common information model helps ensure that the differing representations will work together both where they overlap and where they complement. While the model could be extended to support other interfaces that may exist within and between networking components such as interfaces between routing and traffic engineering, these interfaces are beyond the current scope of this work. Initial models will focus exclusively on those interfaces needed to manage and configure various components within a networking environment. 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 Weiss et al. Expires January 2001 [Page 5] Internet Draft Network Information Model Requirements July 2000 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. CIM also has dictated a naming scheme that cannot be mapped easily into all management technologies. Finally, the DMTF does not have the subject matter experts in networking. 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), attributes (properties or data) and methods (signatures) 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). 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 Weiss et al. Expires January 2001 [Page 6] Internet Draft Network Information Model Requirements July 2000 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. Ideally, the textual representation provides sufficient detail for algorithmic mappings of the information model to as large a cross-section of protocols/interfaces as possible. 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. Constraints refer to the ability to clearly 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 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 Weiss et al. Expires January 2001 [Page 7] Internet Draft Network Information Model Requirements July 2000 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 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 Weiss et al. Expires January 2001 [Page 8] Internet Draft Network Information Model Requirements July 2000 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. Mechanisms for describing the fundamental data types of attributes, as well as describing arrays, sets, or ranges of these fundamental types, are required. Possibly, the binary representation of the attributes may be specified. 8. 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 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. In other words, groupings of classes may facilitate the initialization or configuration of classes by logical groupings. This is a feature that people could use to determine the scope of a particular domain (DS, MPLS, DHCP, etc.) rather than a packaging format. 9. 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 Weiss et al. Expires January 2001 [Page 9] Internet Draft Network Information Model Requirements July 2000 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. Methods or signatures must operate under the same modeling restrictions as those described in requirement 4 for Attribute definitions. Mechanisms must be provided in the model to fully specify the operating constraints of both the method and the attributes passed to and from the method. Specifically: * Constraints for attributes passed through a method. E.g., Attribute X is an integer that can have values in the range 10- 100 and 234-235. * If the modeling language supports the ability to pass classes or class references, the constraints of the passed classes should be fully specified if different from the general definition of the class. E.g., This method allows the passed in Class A to be removed or copied. * If methods are used to perform associations between classes passed in through the method, this must be specified. If special circumstances determine the outcome of the association, this must also be represented in the model. Allow instance class A to be associated with instance of class B only if not already associated with class C. * Constraints for attribute transactions within a method, method parameter A and method parameter B have transactional dependencies (need to be modified together under a given context or the modification of one is dependent on the value of the other). * To facilitate consistent interpretation of the method, each parameter definition must specify whether the attribute is read- only, read-write, or write-only. * If it is possible for one method to invoke or use another method, this must be documented. This is particularly important when the embedded method updates structures that can also be manipulated directly or through other externally visible methods. If method A invokes method B and method B updates attribute X, it must be clearly documented that X is being updated to prevent the consumer to inadvertently also update X. 10. 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.] 11. As the information model will be deployed across a variety of implementations, it is recognized that not all implementations will 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 (or superset) of the model Weiss et al. Expires January 2001 [Page 10] Internet Draft Network Information Model Requirements July 2000 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. 12. 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. 13. 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 January 2001 [Page 11] Internet Draft Network Information Model Requirements July 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. For example, if I have an attribute called AS_Number, for which a change of the value can only take effect when routing is brought down, I may have at least two values of AS_Number in the system: currently active and proposed. The model must be capable of distinguishing the two. A simple approach might be to define two attributes in the class. However, different products will make different implementation decisions for when attribute updates take effect. Further, some configuration management paradigms like LDAP rely on polling to make changes to systems, so the state in the directory may not reflect the state of the device until the device actually retrieves the value and notifies the directory that the new value is in effect. These various scenarios suggest the need for a general mechanism in the model that distinguishes the actual configuration from the desired configuration. 14. 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 January 2001 [Page 12] Internet Draft Network Information Model Requirements July 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 and the rules for manipulating an attribute with that type. 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: Typically refers to an aggregation or set of one or more attributes that 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 January 2001 [Page 13] Internet Draft Network Information Model Requirements July 2000 5. References [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers [CIM] http://www.dmtf.org/spec/cims.html [DEVICE] J. Strassner, W. Weiss, D. Durham, and A. Westerninen, " Information Model for Describing Network Device QoS Mechanisms ", draft-ietf-policy-qos-device-info-model- 00.txt, March 2000. [PFCIM] Moore, B., and E. Ellesson, J. Strassner, "Policy Framework Core Information Model", draft-ietf-policy-core-info-model- 06.txt, May 2000. Weiss et al. Expires January 2001 [Page 14] Internet Draft Network Information Model Requirements July 2000 6. Author Information and Acknowledgments Special thanks to Joel Halpern, Juergen Schoenwaelder, and John Strassner for their many helpful comments and significant edits to this document. Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 Phone: +1-603-879-7364 E-mail: wweiss@ellacoya.com David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 503.264.6232 David.Durham@intel.com Andrea Westerinen Cisco Systems andreaw@cisco.com 425-891-8407 2570 W. El Camino Real Mountain View, CA 94040 Weiss et al. Expires January 2001 [Page 15]