Data%20Modeling%20IETF68%20-%20Prague

1
Data ModelingIETF68 - Prague

• Dr. Michael Alexander
• Department of Information Systems
• Wirtschaftsuniversität Wien
• malexand_at_wu-wien.ac.at

2
Agenda

• Use Cases
• Problem Statement
• Backward Compatibility
• Scope
• Core
• Secondary
• Non-in-scope
• Functional Coverage

3
Agenda II

• Requirements on Others
• Approach
• Process
• Integration
• Open Items
• References

4
Use Cases

• Designing and Implementing
• Element Managers (EMSs)
• Network Managers (NMSs)
• Operations Support Systems (OSSs)
• CLIs
• Functional Coverage
• Configuration
• Alarms
• Current-historical performance
• Inventory
• Accounting management
• Security

5
Use Cases II

• Drilling-down into equipment

(C) servasoft
6
Problem Statement

• Every device, EMS, NMS, Alarm manager, inventory
  manager tends to have its
• ITS OWN DATA MODEL
• Popular access method focus
• we manage with SNMP, CLI, CORBA etc,
• NM sometimes secondary outside of carrier because
  of high cost of proper enterprise NM
• Flatness of SMI/MIBs
• Try building a multi-device EMS/NMS from it
• Behavior weakly expressed in MIBs
• Time it takes to model a new device, add
  additional release support is excessive

7
Problem Statement II

• "Although some positive sentiment was expressed
  for defining a kind of "super SMI" metalanguage
  to aid in the definition of a general API, it was
  not clear whether the current crop of supporting
  protocols had sufficient semantic commonality to
  be used in this way. The matter remains open for
  investigation."
• Vince Cerf RFC 1109 (1989)

8
Backward Compatibility

• Axiom
• Backward compatibility with MIBs SHALL be
  preserved
• Building on MIB base
• Man hours in existing MIBs ...
• Conversion of MIBSs to DM Models
• Into namespace, free form variant
• Reverse imports of DM Models into MIBs not
  feasible

9
Independence from Access Methods

• Data Models need to be independent of access
  methods
• Talking to a device via SNMP CLI NETCONF
  CORBA XML-RPC Batch Config Transfer is
  relatively insignificant in time/resources
  relative to designing-implementing-maintaining
  data models ...
• A clean data model of a 5000 managed objects
  device can be talked to in ANY of the above
  access methods provides the device has an agent
  that exposes the objects

10
Scope Core I

• Initial focus
• Must Equipment hierarchy
• Rack/ Power supplies/ shelf/ slot/ port/
  facility/ protocols/ services
• Must Base network types IP, SDH/SONET, ATM,
  Ethernet
• Proposed initial focus IP-Routing, Ethernet,
  SDH/SONET, ATM
• Proposed initial services Barebones SIP,
  Ethernet VLANs, DiffServ (as a service in the
  models)

11
Scope Core II
Layer Description
Layer VII Device/Line/Service/Protocol Instance
Layer VI Device/Line/Service/Protocol Model
Layer V Device/Line/Service/Protocol Type Meta Model derived from class model
Captures behavior, rules
Layer IV Device/Line/Service/Protocol Class Meta Model
Alarm template class model
Layer III Namespaces/Meta model
Derive from existing CLI (option?) or design anew
Constructs etc.
Alarm template meta model
Layer II Object Model (prototype methods-operations, data types)
Layer I Access Method (SNMP, CLI, Netcon, CMIP, CORBA, XML-RPC, SOAP...)
12
Scope Secondary

• Unique equipment/line locator
• Schema for it
• Registry
• Alarm template registries
• Protection, failover modeling (11, 1n, 11,
  etc.)
• Device/service/protocol models to be defined in
  the respective areas / WGs
• Needs namespace/metamodel
• Otherwise chaos results

13
NOT in Scope

• Business Support Systems (BSS)
• Workflow
• Trying to solve the remaining 20 to 100 of
  networks/services from the onset ...

14
Requirements on Others-Dependencies

• No initial requirements but of
• Netconf RPC/formalized method call (work-around
  available)
• Coarse grained operations on the devices
  protocol agent significantly reduce level of
  complexity provision_subscriber () vs. 100 Sets
  
• Consecutively elegant integration into protocol
  specifications natural
• Management gets much easier for protocol
  designers if Protocol Class Meta Model is
  available.

15
Approach Talking Points

• "80 easier to understand, 90 less time", VERY
  SIMPLE upper layer models
• Applies if you have thousands/ten thousands of
  NEs and small
• Not a monolithic model ...
• No device class/service xsds etc. without meta
  models
• Leave 100 to all-inclusive models
• Process is crucial ...
• .net example ...
• Fostering exposure of methods in NEs
• One draft rules them all does not work here
• Many folks not used to meta modeling
• Overspecify ...
• Good expressiveness necessary ...
• Good but not perfect coverage, completeness,
  correctness Iterate
• Not going to solve the world but 80 of it )
• Human readable schemata and models a key
  criterion
• Models will do some things like IP very well
• Use of 2-3 sample stacks e.g. ATM stack or
  Site-to-Site IPSec Tunnels/POS/MPLS/SONET-SDH
• Sensible abstraction, decomposition where
  necessary
• integration-produce something that fits together
  

16
Process-Cycle Time

• Complexity is significantly higher than for many
  protocols (not TCP)
• Just as much an organization and process exercise
• Expected high intial flow of changes until
  steady-state, still comperatively many changes as
  part of regular process in regular update cycle
• Device/Line/Service/Protocol Models should be
  shifted to respective areas
• Branches
• Folding of normative schema extensions into main
  as much as possible
• Allow private branches
• Allow specialization without folding
• Target time 1 year for first iteration
• Cycle time
• Device/Line/Service/Protocol Instances on
  discretion of equipment/nm vendors
• Device/Line/Service/Protocol Model initial 6
  months, steady-state 6 months
• Synced with protocols
• All meta models initial 6 months, steady-state
  8-9 months
• Object model and data types initial 6 months,
  steady-state 3-4 years or longer

17
Open Items

1. Rules language, metamodel language
2. State model inclusion and language

18
Towards a BOF

• Terminology
• In NM time gets wasted when differing
  terminologies are used ...
• Is the problem worth working on
• Is the problem defined well enough
• For a BOF
• Creating layer V models first is futile
• need to be converged
• Jumpstarting the effort
• e.g. basing it on IOS/JUNOS CLI (evaluate legal,
  practical possibility)
• MIB to XML conversion to be formalized NOW
• ltdraft-chisholm-netconf-model-06.txt gt is close
  to a Layer II object model
• Should a BOF be held at IETF69

19
References

• RFC 1155 - SMI
• RFC 1157 - SNMP
• RFC 1212 - Concise MIB Definitions
• RFC 3688 - XML Schema
• RFC 4741 - Netconf
• W3C Namespaces in XML, 1999
• W3C XML 1.0 4th Edition, 2006
• ltdraft-alexan-datamod-00.txtgt
• ltdraft-atarashi-ngo-consider-architecture-00.txtgt
• ltdraft-chisholm-netconf-model-06.txtgt
• ltdraft-okita-ngo-diffservdatamodel-00.txtgt
• ltdraft-iijima-ngo-vlandatamodel-00.txtgt
• ltdraft-romascanu-netconf-datatypes-01.txtgt