Existing and future SNMP MIBs represent a tremendous source of network management value, both as...

Existing and future SNMP MIBs represent a tremendous source of network management value, both as data models and – when realized via SNMP agents -- as instrumented management capabilities.

XML-based management applications need XML-based access to SNMP MIBs as data models and as enablers of the management instrumentation supported by SNMP agents.

Multiple independent approaches to representing MIBs in XML have been devised – each with appreciable value and success.

However, a standard methodology is necessary to ensure interoperability and accuracy – and the IETF is the right group to undertake this effort.

Development of an IETF Standard Methodology for Converting SNMP MIBs to XML Documents via XSD

Bob Natale ([email protected]) - IETF 70 – Vancouver – December 3, 2007

3-December-2007 Natale - IETF 70 - Vancouver - Ops Area Open Meeting

2

Agenda

Problem/Opportunity Description Expected Beneficiaries & Benefits Background (Prague, Chicago, Vancouver) Illustration of Technical Approach Planned Deliverables Datatypes Requirements and Mappings Problem/Opportunity Recap Next Steps Q&A


3

Problem /Opportunity Description Emerging generation of XML-based management solutions

face some major near-term limitations: Lack of standardized “resource models”, esp. for node and

network management. Little desire among those solution providers to incorporate

SNMP directly into their products. Strong desire among network operators (and service

consumers) for a unified management solution, emanating from the service management perspective.

The existing (and future) body of SNMP MIBs is an unequalled set of proven data models for node, network, and application management.

Managed object instrumentation supported by those SNMP MIBs can be made more readily accessible to XML-based management solutions at relatively little cost and with substantial benefit to all stakeholders.

A fair amount of related work in mapping SNMP MIBs to XML has already been done by IETF contributors, and several related efforts are already underway in the IETF O&M Area.


4

Expected Beneficiaries & Benefits Network Operators:

More unified management solutions from the service layer Fewer distinct management tools to purchase, integrate, operate,

and maintain Fewer distinct data sources to correlate and validate Result = More timely, complete, accurate network information

enables improved service delivery at reduced cost Network Users:

Improved service performance at (possibly) lower cost due tobenefits realized by Network Operators.

XML-based Management Solution Providers: More appealing products to offer No need to reinvent the wheel with respect to SNMP MIB data

models or instrumentation SNMP Managed Equipment Providers:

Broader market for existing products w/o code changes SNMP Management Solution Providers:

Supply MIB to XML conversion/validation tools Supply XML/SNMP proxy solution Eventually supply XML-based instrumentation in existing SNMP-

managed equipment


5

Background:From MIB2RMDL to XSDMI IETF-68/Prague - MIB2RMDL (Natale):

Addressed the full conversion problem: MIB to XML via XSD XML to “Resource Model” (e.g., SML, RMD, etc.) Gateway to SNMP-based instrumentation

IETF-69/Chicago – XSDMI (Harrington/Li): Focused on MIB to XML via XSD Leveraged pre-existing IETF work MIB2RMDL effort aligned with XSDMI

IETF-70/Vancouver (combined team): draft-li-natale-smi-datatypes-in-xsd-00.txt XML-oriented “consumer” groups asking for alignment in

the March 2008 time frame


6

Illustration of the Problem Space forMIB2RMDL

ManagerManaged

Entity

Mgmt Protocol Messages

InfoModel

DataModel

SimplifiedGeneric

View

SNMPManager

SNMPAgent

SNMP

SMI

MIB

Simplified SNMP View

MgmtService

MgmtEndpoint

SOA/WS Mgmt Protocol

???

???

Simplified SOA/WS View

Decisionsabout

supportedartifactsneeded here.

Standardized Conversion Methodology

ProposedIETF O&M

work


7

Illustration of the Problem Space for XSDMI

SNMPManager

SNMPAgent

SNMP

SMI

MIB


MgmtService

MgmtEndpoint

SOA/WS Mgmt Protocol

???

???

Simplified SOA/WS View

Artifactssupported here will drive the non-IETF

conversion.

IETFStandard

ConversionMethodology

ProposedIETF O&M

work XSD

XML

Non-IETFConversion

Methodology

SNMPManager

SNMPAgent

SNMP

SMI

MIB


MgmtService

MgmtEndpoint

XML-based Mgmt Protocol

XSD

XML

Simplified XML Mgmt View

IETF Standard Conversion Methodology

ProposedIETF O&M

work

Simple XML solution

This is thetarget XSDMI

solution.


8

MIB to XML via XSD Deliverables Documents:

SNMP SMI Datatypes in XSD RFC 2578 and RFC 1155

SNMP Textual Conventions in XSD RFC 2579 and select (TBD) other IETF TCs Optional: Follow-on additional document(s) to cover

select (TBD) non-core TCs SNMP MIB Structure in XSD

Working from libsmi as a starting point

Tools (Optional): Downloadable/online MIB to XML conversion utilities

Similar to XML2RFC Reference implementations

MIB to XML XML to SNMP Gateway


9

Requirements for SMI to XSD MappingObjectives: Fidelity and Parsimony

R1. All SMI datatypes MUST have a corresponding XSD datatype. R2. In case of conflicting requirements between SMIv1 and SMIv2,

SMIv2 MUST take precedence. R3. The XSD datatype specified for a given SMI datatype MUST be

able to represent all valid values for that SMI datatype. R4. The XSD datatype specified for a given SMI datatype MUST

represent any special encoding rules associated with that SMI datatype.

R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype.

R6. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements.

R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most direct from the perspective of readability by humans. Sec. 3 (re-ordered) of

draft-li-natale-smi-datatypes-in-xsd-00.txt


10

Proposed SMI Datatypes to XSD MappingNumerical SMI Datatypes

<xs:simpleType name="INTEGER"> <xs:restriction base="xs:int"/></xs:simpleType>

<xs:simpleType name="Integer32"> <xs:restriction base="xs:int"/></xs:simpleType>

<xs:simpleType name="Unsigned32"> <xs:restriction base="xs:unsignedInt"/></xs:simpleType>

<xs:simpleType name="Counter32"> <xs:restriction base="xs:unsignedInt"/></xs:simpleType>

<xs:simpleType name="Gauge32"> <xs:restriction base="xs:unsignedInt"/></xs:simpleType>

<xs:simpleType name="TimeTicks"> <xs:restriction base="xs:unsignedInt"/></xs:simpleType>

<xs:simpleType name="Counter64"> <xs:restriction base="xs:unsignedLong"/></xs:simpleType>

<xs:annotation> <xs:documentation> Mapping of "additional" SMIv1 datatypes from RFC

1155. </xs:documentation> </xs:annotation>

<xs:simpleType name="Counter"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>

<xs:simpleType name="Gauge"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>

From Sec. 4 of draft-li-natale-smi-datatypes-in-xsd-00.txt(ditto next slide)


11

Proposed SMI Datatypes to XSD MappingNon-Numerical SMI Datatypes

<xs:simpleType name="OctetString"> <xs:restriction base="xs:hexBinary"> <xs:maxLength value="65535"/> </xs:restriction></xs:simpleType>

<xs:simpleType name="Opaque"> <xs:restriction base="xs:hexBinary"/></xs:simpleType>

<xs:simpleType name="IpAddress"> <xs:restriction base="xs:string"> <xs:pattern value= "((0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)\.){3} (0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)"/> </xs:restriction></xs:simpleType>

<xs:simpleType name="ObjectIdentifier"> <xs:restriction base="xs:string"> <xs:pattern value= "[0-2](\.[1-3]?[0-9])(\.(0|([1-9]\d*))){0,126}"/> </xs:restriction></xs:simpleType>

Recommendations for simpler patterns for “IpAddress” and “ObjectIdentifier” which are consistent with the mapping

requirements will be enthusiastically welcomed.

Note that theSMIv2 “BITS” constructremains to be mapped.


12

Recap:Illustration of the Target Environment

SNMP Manager component not requiredMultiple instances of all components possible

Blue indicates XML-based mgmt componentsGreen indicates SNMP mgmt components Red indicates intermediary mgmt components

Solid lines indicate the native mgmt protocol pathsDashed lines indicate proxied mgmt protocol pathsQuirky lines indicate once-only conversion paths

SNMPManager

SNMPAgent

XML-basedManager

MgmtEndpoint

RMDL- SNMPProxy

MIB2

RMDL

ResModel

MIB

- When XML/XSD is the Resource Model used by the XML-based Manager, the RMDL to SNMP Proxy is direct.

- When a different Resource Model is used by the XML-based Manager, an additional conversion step (specified outside the IETF) is required (in each direction).


13

Recap: Problem/Opportunity Description“Repetition is the key to learning” – Jeff Case

The XML-based management solutions provider community lacks a critical mass of standardized data models in appropriate formats to deliver acceptable solutions to the (waiting) operator and user communities.

The existing body of IETF SNMP MIBs can fill a major portion of that gap very quickly if they are converted to appropriate XML-based “resource model” artifacts.

The IETF should take the lead in standardizing the methodology for converting SNMP MIBs to XML-based resource model artifacts.

The IETF might also consider making reference implementation tools freely available (in a manner similar to xml2rfc).


14

Next Steps

Achieve consensus on SMI datatypes to XSD mapping draft: draft-li-natale-smi-datatypes-in-xsd-00.txt -01 update to be posted following Vancouver

Identify core set of TCs and publish Core TC to XSD mapping draft: draft-romascanu-netconf-datatypes-02.txt

is a primary source Define IETF-standard MIB to XML structure and

publish mapping draft: libsmi/smidump XML output tool is a primary source:

draft-li-mib-convert-00.txt Output from XML option of

http://www.ibr.cs.tu-bs.de/projects/libsmi/smidump.html Refine and publish all drafts as Proposed

Standard RFCs


15

Thanks for your time, attention, and feedback!

Questions, Comments?E-mail Discussion:[email protected]@ietf.org

Credits to:

David HarringtonYan Li

Dan RomascanuAndy Bierman

Juergen SchoenwaelderMark Ellison

Randy PreshunDon EbrightMark WeitzelSteve Jerman

And to many others who have contributed (knowingly or not :) to this effort thus far (any omissions are purely unintentional).

Existing and future SNMP MIBs represent a tremendous source of network management value, both as...

Documents

Transcript of Existing and future SNMP MIBs represent a tremendous source of network management value, both as...