Minutes of the 6th Network Management Research Group meeting, held at the University of Twente in Enschede, The Netherlands on march 16-17, 2000. Present: Juergen Schoenwaelder (JS), Frank Strauss (FS), Aiko Pras (AP), Szabolcs Boros (SB), Robert Parhonyi (RP), Ron Sprenkels (RS, minutes), Bert-Jan van Beijnum (BB), Bert Wijnen (BW) Agenda 1) Data modeling 2) SMIng and operations 3) SNMP architecture extensions for operations 4) SNMP protocol extensions for operations Agenda Item #1: Data modeling Discussion of on Network Information Model Requirements. The draft proposes to develop a technology independent network information model, and map it to existing data models. AP has strong doubts if this idea will work. He mentions a few earlier attempts at this that failed. Issue: Only the lowest common denominator of the target data models can be used effectively. Issue: How does an architecture relate to an information model. - Every formally expressed information model is technology dependent, which contradicts the goal to be technology independent. - What is the problem an information model is trying to solve? (a) industry cost reduction (b) IETF cost reduction You only get only a cost reduction if the - costs for developing the NIM - costs for learning how to use the NIM - costs for tools etc. balance the savings from having a NIM. BW: Do we need a network information model? Is this still timely work? (RS: no notes on the answer) AP: Information or data models are at different levels. SMI is at lowest level, SPPI is slightly higher, GDMO yet higher, CIM highest level. Above all that, the general to be defined information model, that should map to the listed lower level concrete models. AP: SMI and CIM are the key models. BW: What about CORBA. Security, is it the thing that causes the problem? BW: I don't think so: SNMPv3 added security to the Internet Management Framework, but still v3 is not widely implemented, deployed or used. Groups like ETSI, typhoon (an IP telephony project), ITU, do work on information modeling. Is OSI management still used? JS: It is used e.g. to manage GSM networks or SDH networks. Is SNMP used for systems management? AP: no, BW, JS: yes. There is the host resources MIB, and proprietary MIBs are used for systems management, although the big market is using proprietary protocols. JS: IETF only has limited human resources to do actual work. The IETF may reach a point where everybody is spending all his time monitoring everybody else and nobody is doing actual work anymore. Starting a IETF working group on information modeling can be seen as a political statement against DMTF/CIM. is the mailinglist for the NIM discussions. It was announced at the ietf-announce mailinglist. BW suggests to post comments on draft-durham-nim-req-00.txt to this list. Problem why cooperation DMTF and policy framework does not go well: One experience is that mapping CIM to LDAP is difficult. -- coffee break -- There is a big book on CORBA specification translations and interactions translations. (RS: I think this was mentioned by JS, no notes on the context) The mapping from SMIv2 to IDL works, but has a versioning problem. JS implemented it. The SPPI basically adds two operations (install/remove) to the SMIv2. JS: Common LDAP schemas are not widely deployed or standardized. JS: The main goal of the SMIng work is to be able to map SMIng to SMIv2, and obsoleting the need for SPPI. In addition, design decisions should be made taking into account existing mappings (e.g. SMIv2 to CORBA IDL). (Don't make them more complicated if it can be avoided.) It has not been a goal so far to define new mappings. AP: Readability and reusability of specifications work against each other. (The example of the GDMO registration tree, and references to it from MIB specs in GDMO was discussed shortly.) Requirement no. 15 is about compound data types: not mappable to SMIv2 right now. BW: similar issue was counter64. 'We' made constraints when it could be used. Maybe it is OK to add compound types even if they can't be mapped to SMIv2 or the current flavor of SNMPv3. -- lunch break -- Summary of the debate of this morning on the information models. - Defining a high level information model without taking lower level models to map to into account will not likely succeed. - The level of SMIng was moved slightly up to prevent the need for SPPI and to evolve the SNMP framework. - How to decide what goes into SMIng and what not? - Naming within SMIng: Classes versus Tables. SMIng solves the SMI part of the 64 bit integer problem. Issue: Where to limit the scope of the SMIng effort to. To SMIv2 and SPPI (lowest level) or include IDL, and or LDAP. Supporting policies in the repository could give support from the groups that define them; Opening up SMIng to include a mapping to LDAP could improve support. BW: Could you express a Policy Framework schema in SMIng? JS: SMIng was not designed for that... AP proposes to do a feasibility study to a SMIng to LDAP mapping. JS: Need an SMIng "guru" and an LDAP "guru". Potentially takes a week per person. JS: What is the purpose, technical or political? Consensus: for the better part political. JS: Are there LDAP experts in Europe? BW knows one in Norway; and maybe Harald Alvestrand. And there might be more in Scandinavia; Eric Huizer might know a few people that have this kind of knowledge. When doing the exercise of a SMIng to LDAP Schema mapping, since SMIng is not fixed yet, this would also mean revising some of the SMIng design decisions. For the feasibility study, probably FS or JS should be involved. More data models to map to? BW: WMI Web-based Management Interface (of Microsoft)? : This draft is on a MIB object dependency expression language. AP thinks its too complex, you lose more than you gain. JS: Some of the issues raised by the draft will go away by adding operations to SMIng. The draft helps to automatically generate management applications. The draft is mainly useful for boxes that have writable objects. JS: This type of extension could be supported in the form of an SMIng extension rather than being a core language feature. The SMIng already supports an extension mechanism. What is still needed is an annotation mechanism. BW: What to advise the writer of the document (dacosta)? JS: Advise to use SMIng. It solves some of the problems already (operations) and can solve the rest (by using extensions). BW: Annotations could also be used to add semantic annotations to objects. Counter value x means this, value between y and z means that, and you should take this action, and so on. Action Item: BW will send dacosta a response, mentioning the possible future of SMIng and how it addresses the issues in his draft. -- coffee break -- Agenda Item #2: SMIng AP: Could you also define SMIng in XML? JS: No, because XML uses tags, and SMIng uses keywords. ;-) JS: You can define a DTD to define the same information. You can write a backend that generates XML. However, the real purpose of such an XML representation is IMHO to use it as an exchange format because it will not be easily human readable. JS: Don't mix up representing actual instances of information in XML and describing the structure of information in XML. AP: XML is fashionable, so it might be a selling point for SMIng. XML format could be good for making modules accessible easily, because there are lots of tools (like parsers, embedded in different packages) for XML, and you don't depend on libsmi being available everywhere. Issues: Is it useful to have compound types? And are they useful even without operations that work on compound types. Do you require a mapping to SMIv2? Issue: Discriminated union types (for sparse tables) are also needed. Issue: Compound data types. Put them in right away? Consensus: Put them in at the first go, then make the mapping to a protocol that doesn't know about them an issue, or assume that the underlying protocol can ship them and make that the issue. How to get the SMIng accepted in IETF? You need tools. Tools are there, libsmi. Libsmi is getting popular. SMIng parser is currently not as fully tested as the SMIv1/SMIv2 one. Issue: Motivation for using agent caps as an example for the extension mechanism. It is useful to put in some motivating text in the document for this. The SMIng document is a large document. If you compare it to its SMIv2 counterparts including the ASN.1 definition, this is to be expected of course. Proposed additions to the document: o A section in the introduction on how to read the document, something like "If you are reader type X , you can skip these parts..." o A section that lists the differences between SMIv2 and SMIng. Some issues with SMIng: - Display hints for unsigneds (cannot be mapped back and forth to SMIv2, since SMIv2 does not support them). - Compliance groups for notifications and objects: SMIv2 has separate constructs for these, whereas SMIng does not. This gives problems if a SMIng document puts notifications and objects into the same compliance group. - IpAddress type is now deprecated, as are some other types of v2. SMIng relaxed some restrictions, e.g. putting index objects in groups. Pretty soon in the IETF, the long-term solution for 64 integer data types will be addressed and a WG started. At that point the SMIng work should be submitted to the IETF. How this will be accepted in the SNMP community in the IETF is an open question; there might be some problems there. -- coffee break -- Agenda item: Operation types in SMIng Issues: o creates and deletes clauses (constructors and destructors) o where can operations be defined (bound to single table, multiple tables or not to tables at all) o returning of results (single result, vector of results) o returning of errors (restricted to enumerations currently) o sequences of operations to get a device in a defined state. Get the state from a device, something to send it back to get back into the current state. o What are the invocation semantics of operations? At most once, exactly once, at least once. o synchronous or asynchronous operations Transport and operations: Do we need to support the invocation of operations over UDP? Lets seriously consider not supporting operations over UDP. UDP gives some problems in case of operations, including arbitrary sized responses. Second day of the meeting (March 17, 2000) ========================================== Bert Wijnen is not present today at the meeting. Announcement: JS wrote an experimental XML back-end to libsmi yesterday after dinner and beer. More work is needed to formally define this. issue: constructors and destructors. Do we need to provide special language constructs to support them? In SMIv2, the RowStatus is usually bound to a single table entry. Do operations need to be bound to data structures? Examples: traceroute, reboot system, remote ping. JS: Scalars in SMI should not have been invented; a set of scalars with a common root is a degenerated case of a table. Having scalars as a special language construct just makes the world more complex. COPS gives every 'table' its own create and destroy 'method'. Discussion on where to bind operations to. OO binds operations always to classes; in a one on one manner. Side-effects are still allowed. UML develops into the 'lingua franca' of modeling (JS) and UML has no notion of operations without objects; every operation is bound to an object class. Options for binding are - operations not bound to anything - bound to exactly one table (or group of scalars) - bound to one or more tables There is no complete consensus on where (if anywhere) to bind operations to: AP supports unbound operations, JS and others support operations bound to a single table (or group of scalars). -- coffee break (Bert-Jan leaves the meeting) -- Example of an operation: Testing an interface. operation ifTest { oid ifMIBOperations.2; arguments (ifIndex InterfaceIndex, testType Enumeration (test1(1), test2(2)); errors (ifIndexInvalid(1), ifIndexInUse(2)); results (result Enumeration (success(1), failed(2), aborted(3)); description "....."; }; The usual OID registration tree structure of a MIB specification is below, extended with a branch to locate Operations in. | +- xxxObjects | +- xxxNotification | +- xxxCompliance | +- xxxOperations Where to define operations? (a) First option to bind the operation to the ifTable: table ifTable { ... the operation definition ... }; (b) Second option is to add to the operation definition a reference that identifies the scope: operation ifTest { scope ifTable; ... the rest of the operation definition ... }; (c) Third option is to use SMIng annotations: annotation ifTableAnnotatation1 { oid .... scope ifTable; ... the operation definition ... }; Consensus: Put operations inside table definitions, and allow the annotation mechanism to add operations in separate documents to existing tables. Asynchronous example with a separate test table: table ifTestTable { ... normal table definitions ... operation runTest { oid ifMIBOperations.1; arguments (ifIndex InterfaceIndex, testType Enumeration (t1(1), t2(2)), errors ... description "... says that the result is shipped via a notification ..."; result(ifTestTableIndex Unsigned32); }; operation stopTest { ... the rest of the operation definition ... }; operation purgeTest { oid ifMIBOperations.3; arguments (ifTestIndex Unsigned32); error (invalidIndex(0)); description "..."; }; } Second example of an operation: Rebooting a system. option 1: annotation systemAnnot1 { oid snmpMIBOperations.1; scope system; operation reboot { ... }; }; option 2: operation reboot { oid snmpMIBOperations.1; arguments (when DateAndTime); errors (invalidDateAndTime(1)); ... } Reboot turns out to be a table after all. If you want to be able to schedule reboots in advance (reboot in 24 hours)), you probably also want to be able to cancel scheduled reboots. -- lunch break -- Multiple results should be supported. We need a way to indicate how many results may be returned (exactly one, 1 or more, 0 or more, ...). Enumerations are sufficient as error codes. We assume 'at most once' or better semantics for operation invocations. Strange reboot example: An operation invoker invokes the reboot operation on a device, and the device immediately reboots, before even confirming the proper reception of the operation invocation. We do not support the strange reboot example; operation invocations are confirmed. The invoker can tell that the invocation actually succeeded. Agenda point #3: SNMP architecture extensions for operations Two additional architectural function blocks: Operation Invoker (OI) and Operation Performer (OP). Access control is an issue; where to call isAccessAllowed ASI? AgentX consequences: If operations are in different subagents than the data they operate on, who calls isAccessAllowed? Agenda item on SNMP protocol operations not covered (lack of time). Action items: o JS and FS take up the action item to update SMIng spec: to add annotations as a core feature to SMIng instead of having it as an extension (as described in the DSOM '99 paper). o JS and FS: Add a rationale why agentcaps are not handled as a core feature of the language and may be better handled as an extension of the core SMIng language. o JS: Work on architecture extensions for SNMP; what goes into and what comes out of the Operation Performer (OP) and Operation Invoker (OI) blocks. Need to specify the relevant ASIs. o Implementation experience on operations would be really cool. AP: Twente will work on it; in particular SB and Bert Helthuis. o Item: Small example MIB with operations. Use this to get implementation experience. o Item: Real MIB with operations. Potential candidate: Diffserv Policy PIB, turn it into SMIng MIB with operations. o Work item: Extend SMIng parser to understand operations, extend libsmi data structures, possibly generate code stubs from that. -- meeting closed -- Ron. -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663)