1 / 19

Data Modeling IETF68 - Prague

Data Modeling IETF68 - Prague. Dr. Michael Alexander Department of Information Systems Wirtschaftsuniversität Wien malexand@wu-wien.ac.at. Agenda. Use Cases Problem Statement Backward Compatibility Scope Core Secondary Non-in-scope Functional Coverage. Agenda II.

dorian-bird
Download Presentation

Data Modeling IETF68 - Prague

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data ModelingIETF68 - Prague Dr. Michael Alexander Department of Information Systems Wirtschaftsuniversität Wien malexand@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

  12. Scope: Secondary • Unique equipment/line locator • Schema for it • Registry • Alarm template registries • Protection, failover modeling (1+1, 1:n, 1:1, 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 device’s 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 … • importance of meta models/frameworks ...

  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 • Rules language, metamodel language • 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 • <draft-chisholm-netconf-model-06.txt > 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 <draft-alexan-datamod-00.txt> <draft-atarashi-ngo-consider-architecture-00.txt> <draft-chisholm-netconf-model-06.txt> <draft-okita-ngo-diffservdatamodel-00.txt> <draft-iijima-ngo-vlandatamodel-00.txt> <draft-romascanu-netconf-datatypes-01.txt>

More Related