[nmrg] Minutes of 8th NMRG meeting

[Szabolcs Boros <[e-mail]>]

Below are the minutes from the 8th NMRG meeting in Austin, TX.
szabi boros



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) - [e-mail]
 2. M. Brunner (MB) - NEC Europe Ltd. - [e-mail]
 3. D. Durham (DD) - Intel Corp. - [e-mail]
 4. D. Harrington (DH) - Enterasys - [e-mail]
 5. J.P. Martin-Flatin (JP) - AT&T Research Lab - [e-mail]
 *. G. Pavlou - University of Surrey - [e-mail] (2000-12-09)
 6. R. Parhonyi (RP) - Univ. of Twente (minute taker) - [e-mail]
 7. D. Perkins (DP) - SNMPinfo - [e-mail]
 8. A. Pras (AP) - Univ. of Twente (chair) - [e-mail]
 9. J. Schoenwaelder (JP) - TU Braunschweig - [e-mail]
10. D. Sidor (DS) - Nortel Networks - [e-mail]
11. A. Westerinen (AW)- Cisco Systems - [e-mail]
12. B. Wijnen (BW) - Lucent - [e-mail]


****************************************
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.