1 / 11

UNUM: NETMOD Unified Model

UNUM: NETMOD Unified Model. Martin Swany U. Delaware. Direction. Chairs asked for: presentations on "first takes" and "outlines" on how such documents could/should look Charter calls for “…a set of core YANG data models ”

winda
Download Presentation

UNUM: NETMOD Unified Model

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. UNUM: NETMOD Unified Model Martin Swany U. Delaware

  2. Direction • Chairs asked for: presentations on "first takes" and "outlines" on how such documents could/should look • Charter calls for “…a set of core YANG data models” • Presumablymodels of networkelementsandcharacteristicsthatcanbereusedandextended • draft-ietf-netmod-arch-10 saysabout YANG • Adding "features" and replacing "third normal form" with a natural data hierarchy should reduce complexity.

  3. Brief Background • perfSONAR is a web services based network measurement and monitoring system • Efforts in the Grid Forum • Widely used in R&E networks • We developed a network topology schema • Initially to codify and reuse measurement “subjects” • Capture the relationship among those elements • Eventually extended to support dynamic virtual “circuit” allocation in Internet2, ESnet, GEANT, etc. • Now investigating it for resource description and allocation in GENI

  4. Network Description Schema • YANG seems to be a solution to many of the problems that we have had with Relax NG • I started working with YANG recently to produce a revised version of the perfSONAR topology schema (called UNIS)

  5. Schema Approach • Define basic network elements: node, port, link, etc. • Reuse element names, vary the namespace for layer-specific properties • Also serves as the basis for other extensions (vendor or domain-specific) • Example: ethernet:interface and ip:interface have distinct attributes (and potentially distinct counters) • Multiple ip:interface atop single ethernet:interface • Two ways to look at it: • Separate but related elements • “Outer join” to create single entity with attributes from both namespaces

  6. Existing Core Model • Network Object (abstract base class) • Has Identifier, Lifetime, is the target of a Relation • Node • Port (Interface) • Link • Service • Groups: Network, Path, Domain

  7. Additions to the Model • Rule • Models routes, but other policy as well • N-tuple of all matchable header fields: (src/dst IP, src/dst MAC addr, etc.) followed by an action (send to output port, IP next hop, increment counter, drop, etc.) • Very illustrative of how we need to reduce things to their most basic components, but preserve the ability to refer to them in shorter, more familiar forms

  8. Model Relationships Node Lifetime Relation Location Link Port Service Rule Location Group * 1 * *

  9. Groups Topology Path Group Domain Network

  10. Issues • This model is broader then the current NETMOD mandate • If we can apply the broader model without impacting the current NETMOD needs, then good • We have to balance between over-specification, which slows and complicates this effort, and overly-narrow design decisions, which can make expansion more difficult later • Can this work serve as a starting point for the NETMOD general models?

  11. Issues - Modeling • How to join basic elements, create views • How best to manage inheritance (if at all?)

More Related