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

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

• Bob Natale (rnatale_at_mitre.org) - IETF 70
  Vancouver December 3, 2007

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
• QA

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 OM 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
  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

5
BackgroundFrom 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
SimplifiedGenericView
7
Illustration of the Problem Space for XSDMI
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
  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

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.

10
Proposed SMI Datatypes to XSD MappingNumerical
SMI Datatypes

• ltxssimpleType name"INTEGER"gt
• ltxsrestriction base"xsint"/gt
• lt/xssimpleTypegt
• ltxssimpleType name"Integer32"gt
• ltxsrestriction base"xsint"/gt
• lt/xssimpleTypegt
• ltxssimpleType name"Unsigned32"gt
• ltxsrestriction base"xsunsignedInt"/gt
• lt/xssimpleTypegt
• ltxssimpleType name"Counter32"gt
• ltxsrestriction base"xsunsignedInt"/gt
• lt/xssimpleTypegt
• ltxssimpleType name"Gauge32"gt
• ltxsrestriction base"xsunsignedInt"/gt
• lt/xssimpleTypegt

ltxssimpleType name"TimeTicks"gt
ltxsrestriction base"xsunsignedInt"/gt lt/xssimpl
eTypegt ltxssimpleType name"Counter64"gt
ltxsrestriction base"xsunsignedLong"/gt lt/xssimp
leTypegt ltxsannotationgt ltxsdocumentationgt
Mapping of "additional" SMIv1 datatypes
from RFC 1155. lt/xsdocumentationgt
lt/xsannotationgt ltxssimpleType
name"Counter"gt ltxsrestriction
base"xsunsignedInt"/gt lt/xssimpleTypegt
ltxssimpleType name"Gauge"gt ltxsrestriction
base"xsunsignedInt"/gt lt/xssimpleTypegt
11
Proposed SMI Datatypes to XSD MappingNon-Numerica
l SMI Datatypes
ltxssimpleType name"OctetString"gt
ltxsrestriction base"xshexBinary"gt
ltxsmaxLength value"65535"/gt
lt/xsrestrictiongt lt/xssimpleTypegt ltxssimpleType
name"Opaque"gt ltxsrestriction
base"xshexBinary"/gt lt/xssimpleTypegt ltxssimple
Type name"IpAddress"gt ltxsrestriction
base"xsstring"gt ltxspattern value
"((010-90,22(0-40-9?50-5?6-9)?3-
90-9?)\.)3 (010-90,22(0-40-9?
50-5?6-9)?3-90-9?)"/gt
lt/xsrestrictiongt lt/xssimpleTypegt ltxssimpleType
name"ObjectIdentifier"gt ltxsrestriction
base"xsstring"gt ltxspattern value
"0-2(\.1-3?0-9)(\.(0(1-9\d)))0,126"/gt
lt/xsrestrictiongt lt/xssimpleTypegt
12
RecapIllustration 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
13
Recap Problem/Opportunity DescriptionRepetition
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.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

15
Thanks for your time, attention, and feedback!
Questions, Comments?
E-mail Discussionmib2rmdl_at_ietf.orgops-area_at_ietf
.org
Credits toDavid 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).