150 likes | 289 Views
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.
E N D
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 (rnatale@mitre.org) - IETF 70 – Vancouver – December 3, 2007
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 Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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. Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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 informationenables 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 Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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 Natale - IETF 70 - Vancouver - Ops Area Open Meeting
Mgmt Protocol Messages SOA/WS Mgmt Protocol SNMP ManagedEntity MgmtEndpoint SNMPManager MgmtService SNMPAgent Manager InfoModel SMI ??? Simplified SNMP View Simplified SOA/WS View DataModel MIB ??? Decisionsaboutsupportedartifactsneeded here. ProposedIETF O&Mwork Standardized Conversion Methodology Illustration of the Problem Space forMIB2RMDL SimplifiedGenericView Natale - IETF 70 - Vancouver - Ops Area Open Meeting
XML-based Mgmt Protocol SOA/WS Mgmt Protocol SNMP SNMP MgmtEndpoint MgmtEndpoint SNMPManager SNMPManager MgmtService MgmtService SNMPAgent SNMPAgent XSD XSD SMI SMI ??? This is thetarget XSDMIsolution. Simplified SNMP View Simplified SNMP View Simplified XML Mgmt View Simplified SOA/WS View XML XML MIB MIB ??? Artifactssupported here will drive the non-IETF conversion. Simple XML solution ProposedIETF O&Mwork ProposedIETF O&Mwork IETFStandardConversionMethodology Non-IETFConversionMethodology IETF Standard Conversion Methodology Illustration of the Problem Space for XSDMI Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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 coverselect (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 Natale - IETF 70 - Vancouver - Ops Area Open Meeting
Sec. 3 (re-ordered) ofdraft-li-natale-smi-datatypes-in-xsd-00.txt 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. Natale - IETF 70 - Vancouver - Ops Area Open Meeting
From Sec. 4 of draft-li-natale-smi-datatypes-in-xsd-00.txt(ditto next slide) 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> Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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. 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> Natale - IETF 70 - Vancouver - Ops Area Open Meeting
ResModel XML-basedManager MgmtEndpoint - 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). MIB2RMDL SNMPAgent RMDL- SNMPProxy MIB SNMPManager Solid lines indicate the native mgmt protocol paths Dashed lines indicate proxied mgmt protocol paths Quirky lines indicate once-only conversion paths Recap:Illustration of the Target Environment Blue indicates XML-based mgmt components Green indicates SNMP mgmt components Red indicates intermediary mgmt components SNMP Manager component not required Multiple instances of all components possible Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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). Natale - IETF 70 - Vancouver - Ops Area Open Meeting
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.txtis 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 Natale - IETF 70 - Vancouver - Ops Area Open Meeting
Thanks for your time, attention, and feedback! Questions, Comments? E-mail Discussion:mib2rmdl@ietf.orgops-area@ietf.org Credits to:David HarringtonYan LiDan RomascanuAndy BiermanJuergen SchoenwaelderMark EllisonRandy PreshunDon EbrightMark WeitzelSteve JermanAnd to many others who have contributed (knowingly or not :) to this effort thus far (any omissions are purely unintentional). Natale - IETF 70 - Vancouver - Ops Area Open Meeting