IRTF - NMRG meeting Austin, Texas J.J. Pickle Research Campus December 8-9, 2000 List of Participants (in alphabetical order) 1. Sz. Boros (SB) - Univ. of Twente (minute taker) - boros@cs.utwente.nl 2. M. Brunner (MB) - NEC Europe Ltd. - brunner@ccrle.nec.de 3. D. Durham (DD) - Intel Corp. - david.durham@intel.com 4. D. Harrington (DH) - Enterasys - dbh@enterasys.com 5. J.P. Martin-Flatin (JP) - AT&T Research Lab - jp.martin-flatin@ieee.org *. G. Pavlou - University of Surrey - g.pavlou@ee.surrey.ac.uk (2000-12-09) 6. R. Parhonyi (RP) - Univ. of Twente (minute taker) - parhonyi@cs.utwente.nl 7. D. Perkins (DP) - SNMPinfo - dperkins@snmpinfo.com 8. A. Pras (AP) - Univ. of Twente (chair) - pras@ctit.utwente.nl 9. J. Schoenwaelder (JP) - TU Braunschweig - schoenw@ibr.cs.tu-bs.de 10. D. Sidor (DS) - Nortel Networks - djsidor@nortelnetworks.com 11. A. Westerinen (AW)- Cisco Systems - andeaw@cisco.com 12. B. Wijnen (BW) - Lucent - bwijnen@lucent.com **************************************** 08-12-2000 **************************************** The purpose of the meeting was defined as learning from each other, discuss high level things and do not go into details. The title of the meeting can be formulated as follows: Network Information Modeling Workshop. There is a need to define a set of terms: - information model (IM) - data model (DM) - interface - conceptual model - object oriented (OO) model and also to answer some questions/issues: - IM vs. protocol. Should the IM be protocol independent/neutral? - IM vs. API - What is the scope of IM? - How many models do we need? One or more? - What are the benefits of IM? Users of IM? Standards. - Should we use OO techniques to describe an IM/DM? Proposal for the IM definition: (a) conceptual model: list of keywords (defines entities) (b) structuring all the information keywords (c) naming scheme for all the entities (d) meta model defined in the entities An IM should contain: - abstracts (conceptual model - modeling the world in abstract objects) - structure: - data model - object model - inverted tree - ... - naming - meta model (also some COPS documents deal with IM) The DM is related more to object repository. There are other approaches for an IM: 1. IM / | \ / | \ / | \ --> Conceptual -------------------------------------------- / | \ --> Computational - as opposed to conceptual (term was removed later from the board) DM DM DM ... (this can be implemented (MIB, LDAP schema), it's technology specific and standardizable) (This model is close to the ITU-T approach.) 2. ODP approach (open distributed processing) - Enterprise viewpoint - Information viewpoint - Computation viewpoint - Engineering viewpoint - Technology viewpoint Question: How can the two approaches be mapped? How can this be done? Structure and meta model belong together. IM - protocol independent DM - protocol specific +--------------------------------+ | | MAPPING: | v v +------------------+ +---------------+ data m. | abstracts | | |--> obj. m. <--| structure | | IM | inverted tree | naming (1) | | | | meta model | +---------------+ +------------------+ / | \ \ ^ \ / | \ \ | IM / | \ -----------------------------+ / | \ naming DM DM protocol (HTTP) encoding (XML) (1) not yet defined in IETF, but CIM has it. SMIv2 is a data model. SMIng tries to do the converging of data models. SMIng is more than a DM, and it has IM flavour. No functionality can be put into a DM that is not in the IM. 11:00 - 11:30 Coffie break OMG people try to implement everything valuable of TINA-C. TINA uses UML for information view, uses CORBA at computational view. The IM is conceptual, but it has to be encoded somehow. The encoding carries the protocol. The DM is more like an encoding. The IM is independent of CMIP, MIB. The IM is more static. The Computational model is running on this static IM. Discussion about the terms: conceptual and computational. Maybe "computational" is not the right term because it is not opposed to "conceptual". What should be instead of "computational"? Isn't "protocol specific" enough for the DM layer? There were pros and cons. Though this is not the ideal solution, this is what we have in IETF at this moment and our goal is to stay within the range of IETF, we don't define a model for the entire world. A common proposal for both IETF and DMTF can be pictured: IM / | \ +------> SMI / ASN.1 / | \ / / | \ / / | +--------------------------+ CIM PIB | | /MOF/ /SPPI/ | | Data Model / | | SNMP MIBs | / | | | ---------------------------|--------------------------|-- wire / | | | | | | | XML BER | | encoding for HTTP | | for LDAP +--------------------------+ (DMTF) (IETF) ASN.1 was designed to describe protocols (e.g. PDUs). CMIP includes actions not just values, MIBs have two operations. IM includes the operations. DTD and XML schema operate at the same level. XML schema is broad, is more suited to complex problems. DTD is a simplified form. Summarized picture: IM / | \ / | \ / | \ CIM PIB MIB data models schema /SPPI/ /SMI, XML/ / | \ / | \ ------------------------------------------------------- wire /|\ | /|\ / | \ | / | \ XML for BER BER encoding HTTP How important are the BER for Information Modeling? There is a difference between "expressing a concept" and "the way to transmit it over the wire". "Protocol" encompasses both bottom levels of the picture; i.e. protocol = actions + encoding. Mapping MIB into BER, or CIM into XML is not a 1:1 mapping. XML is more powerful and can be used to describe different levels (DM level and encoding level). Different Data Models can be expressed in different ways: we use schemas for CIM, SPPI for PIBs and SMI for MIBs. But XML can be also used to express a MIB on the DM level. Even more, XML can be used also for the IM level. In DMTF the data model is fully Object Oriented. In SNMP the object model has to be translated into a DM which is not an OO model. The question is whether DM does contain information or only the way how the information is encoded. The Data Model Language (SMI, XML, SPPI or MOF) is the way to express the information, the DM is only the content. 12:30-13:40 Lunch break A discussion went on upon the term: "interface". The term was heavily used in IETF, but with a different meaning than in ITU-T where interface is part of the functional architecture and it is the boundary between managed and management entities, while in SNMP world interface was mostly used in the IF-MIB tables. In the view of ITU interfaces are between and/or within the Network Element - Network - Service - Business layers. Interface is different between each of these levels (interfaces between layers or between elements in the same layer). Discussion over introducing OO in IM/DM or not. MIBs of OSI defined with GDMO look OO. At IM level could be anything, but typically there should be an OO approach at this layer. The DM layer doesn't have to be necessarily OO. However, if DM can be OO, then IM has to map to various DMs, therefore IM has to be OO. Otherwise how do you map something that is not OO to a DM that is OO, which is a superset. If one uses an OO language to have an IM and uses a non-OO language for DM -> that will not work necessarilly well. One looses information of a OO model while mapping it to a non-OO model. It won't work necessarily well if using an non-OO IM and an OO based DM. OOness is represented in UML; core concepts of UML are inheritance, classes, attributes and methods, associations and cardinality. UML is a graphical notation and has a state model. ITU-T decided that they want to use things that were considered important (eg. UML). There could be used the existing languages and not defining a new one. UML is not the perfect language. ITU-T has another language: SDL (Specification and Definition Language), it is combined in a project UML and SDL. What is an OO model? The key concepts of an OO model are: - abstraction & encapsulation - classes (attributes, methods, notifications, behaviour are included) & instances - inheritance - relationships - naming Benefits and drawbacks of these characteristics were discussed. Is it necessary that IM is OO? Yes, because then it is easier to map it to the OO Data Model. The formal representation of IM (whether it is UML or a structured English) is OO, including all features. There was a consensus upon the fact that people SHOULD use OO techniques for specifying the IM (specification tools must be able to do OO). Since the DM is to be choosen based on the protocol, it is not necessarily OO. Discussion over the definition of "control model". (CM) What is a CM? Where it comes from? ITU-T world. ITU has a data - control - management model. It's a term to see if there's distinction between action and data. Control means modifying the characteristics of specific data. CM should be put in the "methods", instead of having it between the other models (IM/DM). 15-15:30 Break Discussions over the characteristics of IM: - scope - reusability - ease of use - focus is on customer - how easy you can define? - how easy you can implement? Is there any experience what a good/bad scope is? Can we give examples for good scope? It is to be noticed that CIM has a very large scope (tries to model a large spectrum of things). Eventually it was agreed upon that scope can be any of the following: DiffServ, element, networks/services, generic high level base model, arbitrary systems, networks/services/business, etc. IM means reusability of terms, implementation doesn't count here. If focusing on standards, implementing is not necessarily relevant. Ease of implementation is indirectly useful. Question: Is "ease to define" the following explanation: if you can define high-level concepts can people on lower levels make implementations? If you have good tools then it's an easy way, but the model is also important. What about ease of use? Is it for customers, managers of operators? Customers demand that you have a consistent model for similar things on the network to be managed. Ease of use is for the customer. Is this important to have it embedded in such a high level model? It is not necessarily part of it but it can be added without changing the underlying protocol. Discussion over the benefits of OO. Reusability? Is it such a great attribute of OO? In theory yes, in practice it's a question. On a long term it seems to be not so great, because in the beginning there are a few classes and you can use whatever you want, but on a long term when there are classes everywhere it would take you too much time to find the base class that you need and add an attribute. You just have to construct your own new class. OO may bring lots of other benefits. For example, an OO model can be structured. Summarizing the benefits of OO approach we could say that in general OO is good, but we should not oversell it. - modularity - encapsulation: you can modify your implementation without affecting your interface. - inheritance: may not be the strongest benefit, it's a nice thing to have as long as you got very clear control over it. If the networking environment changes quickly then inheritance could be a problem. Inheritance adds dependencies and complexity. But it still can be a powerful tool. It is necesary to specify explicitly that it is dangerous. - abstraction - naming (in OO terms naming is scoped -> this is an advantage) - classes - instances - relationships: may be benefical - methods. Relationships/methods: Question: Would it be a good idea to have relationships like in OO technology? A relationship in a model documents that there is something between two entities. One can have relationships just to point out to attributes, or some other attributes of other entities. An IM could define classes and relationships, in implementation you have to define instances and pointers. In IM we don't have pointers but we have relationships, in a DM we have pointers. Mapping between these two can be difficult. Summarizing relationships: Juergen said that if you start doing it top down it's nice, but if you have a list of existing things then it can be difficult. You run into the risk that if you have methods in the IM then they would be heavily used, creating in your system a lot of code and interactions. That is something that we should be aware of. SNMP was designed not to do methods. SNMP was developed from CMIP and the action capability was deliberately removed because it added such a complexity. One reason why methods are not in SNMP is because by limiting the operation improves interoperability, which allows us to define standards decently. Adding methods will impact interoperability. Methods at IM level are different from methods at DM level. Interoperability issues arise only when adding methods at DM level. In the process of mapping IM to a specific DM (eg. SNMP) we get rid of the methods and map them to some (SNMP) specific mechanisms. But if we are going to define methods in the IM, SNMP will be extended to support methods. There are now some MIBs that really need methods and operations. And SMIng is extensible, this is one of its features. Methods have to be added to SNMP, because they bring some ease of use, or else, CORBA will take over. Scenario: Suppose you have methods in both models, the result would be lots of code and inefficient communication. Assume people would really like the methods in the IM then they start using them, so you have problems because of the inefficient code and communication. That would be a good reason to convince the people to go to the new version of SNMP. **************************************** 09-12-2000 **************************************** Discussion about the 3rd agenda item: is SMIng suited for an IM? The abstract of the SMIng document states that it is a data model. SMIng has classes, inheritance, attributes, but no methods. There are events that map to SNMP notifications. An event is part of a class, while in SMI it is a standalone thing. The current SMI was not written for IM. Is SMIng usable for information modeling? - SMIng is a data definition language to replace SMIv2 and SPPI; the underlaying protocols at this moment do not allow method invocation; - a replacement that merges two different languages; - it is not the goal of the language to be suited for IM, but it is benefical; - it is a protocol independent data definition language. Q: Does SMIng conform to the definition of IM that we had yesterday? A: No, because there is no abstract representation of relationships. Q: Would be difficult to map SMIng to IDL? A: Not more than the mapping of SMIv2 to IDL. When SMIng was designed one of the things we had in mind was to make mappings to other DM and protocols such as CORBA IDL not harder. Reusability is needed in data definitions. SMIng was designed OO to provide this. Another reason was structuring and ease of use. Reusability was the main reason to make SMIng OO. An IM language should be OO, and SMIng does not include methods. SMIng is a good candidate for DM, but does not qualify for IM. In IM, it is clear what is a method. We have clear parameters and we know their semantics. In DM the clarity can be taken and mapped in whatever is needed. However SMIng is moving to the right direction, and it can become good IM. The key elements for an IM should be: - OO - methods - relationships. Q: What does an IM require in order to model relationships? A: IM has a concept to describe relationships. You need more than pointers, you need a way to formally express relationships. You need something to describe and document the relationships. Relationships should not only be simulated, but they should be built into the language. Q: Suppose relationships are easy to map to DM. Do we really need methods? A: Methods would be something that you can always map to the DM, on the other hand Jurgen left it out from the SMIng because it would be inefficient with current IETF management protocols. DMTF uses UML to present graphically the entities. Use UML to represent something then discuss it, define the MOF. UML is the basics (class diagrams & relationships, no sequence diagrams). For modeling protocols we need sequence diagrams. Sequence diagrams are useful for identifying the methods. +---------------+ | | / "informal"/English _____ class diagram | IM |/ / | |\ / +---------------+ \ "formal"/UML ------------ sequence diagram /|\ \ / | \ \_____ use cases ... | \ | \ SMIv2| \SPPI | \ MIBs PIBs / \ / \ DM ---------------------------------------- / \ BER BER It is difficult to do UML without tools. OMG has copyright for UML. We need ASCII representation of the UML diagrams, IETF has requirement for ASCII. If the diagrams could be represented in ASCII many people would be happy. Also need public domain implementations. Q: Do we have to standardize the IM in the IETF? A: Yes, IM should be standardized. And it has to be done in ASCII file for IETF. 10:45-11:30 Coffie break Some UML-related ITU-T documents: M.3020 - TMN methodology focused on UML M.3208.3 - IM using UML M.3108.3 - DM using UML ITU-T 564/IETF ftp site ip address: 47.234.32.16 user id: anon path: /itu_to_ietf/56 DMTF documents: www.dmtf.org/spec/cims.html (click on Schema v2.4) www.dmtf.org/educ/whit.html (white papers, recommended The CORE Model). Pointers to IETF? Some relevant documents? WGs? SPPI draft, SMIng - RFCs. Policy Framework WG, SMIng WG, RAP WG (SPPI), IPSP WG. OMG with CORBA: OMG has Telecom Domain Task Force: TMN with CORBA activities. "CORBA notification service" was produced. OMG did not produce network models. - created corba models for trouble ticketing. - study group 4 has some proposals to use CORBA models. - docs are going for approval in january 2001. OMG document: Common Information Structure 3GPP group approved a set of specification for config+fault mgmt, they created DMs based on CORBA: 32.016, 32.111 docs. 3GPP uses aspects of class diagrams, but the large part is their own creation, using structured English. ATM Forum has a protocol neutral model. ATM Forum uses structured English. TINA-C has some docs from 1996. Network Resource IM - TINA. SUN has some work there (in 3 groups), has created an infrastructure with object manager. MS: Win Mgt Info: took the CIM schema and added OO design in a strange way. CISCO: have DMTF models + extensions: CIM models are used. There was a demo. www.snia.org Intel, IBM are working also implementing CIM. Enterasys is also working with CIM-LDAP stuff, but no success yet. Q: How much of the work is used in the world? What was implemented and being used (deployment)? A: Some ITU-T docs were just finished, no implementation yet. Telco's in Europe implement and extend proprietary GMDO-CMIP stuff in an inconsistent way. Conclusion: On IM level ITU-T has docs, but they are too new, no implementations. 12:35-13:20 Lunch break JS: =presentation of SMIng= example: module INET-FILTER { ... class Filter { attribute DisplayString255 name ... } } class InetFilter:Filter { attribute InetSubnet src; attribute InetSubnet dst; ... } class InetSubnet { attribute InetNetworkEndpoint endpoint; attribute InetMask mask; ... } - multiple inheritance is not allowed (it is way to complicated for the benefits it brings) - attributes can be overwritten (there are some restrictions) The XML schema is very similar to SMIng. General discussion about SMIv2 and SMIng. Similarities and differences, notifications, events, mappings to CMIP, DIAMETER, SNMP. snmp { table ifTable { oid interfaces 2; index (); implements Interface { object ifIndex index; ... } } } There was a research proposal: mapping to CORBA. 14:50-15:20 Break Finalization of the meeting: - questions answered, - issues discussed. Q: What to do with the output of this meeting? Are there other issues to be addressed? A: Write an article for the SimpleTimes. It could be a good idea to use this output as an input for the NIM group. IM requirements document, discuss it on the mailing list. 15:50 Closing of the meeting.