Physical Resource Modeling with Complex Types ( draft-linowski-netmod-yang-abstract-03.txt )

1. Physical Resource Modelingwith Complex Types(draft-linowski-netmod-yang-abstract-03.txt) IETF #78, Maastricht O&M Area Open Meeting bernd.linowski.ext@nsn.com mehmet.ersue@nsn.com s.kuryla@jacobs-university.de

2. Complex Types and Typed Instance Identifiers • Set of extension statements for YANG • Motivation • Language abstractions to improve model extensibility and reuse • Top-down modeling: first abstract entities and then concrete refinements • Type-safe modeling to force correct usage of language constructs • Alignment with other SDO's resource models for lossless mapping • Language improvements: • Recursive data structures of arbitrary depth • Self-contained type definitions with rich inner-structure • Concept refinements to avoid e.g. huge choice-statements with complex branches

3. Physical Resources Model Class Inheritance RecursiveContainment Typed, Location-Agnostic References Source: NSN Unified Data Model

4. Physical Entities UDM Hardware fromEntity MIB

5. Physical Resources Modeled with Complex Types module udmcore { namespace "urn:com:nsn:udmcore"; prefix "udm"; import yang-types {prefix "yt";} import complex-types {prefix "ct"; } ct:complex-type Resource { // … ct:abstract true; leaf version {type string;} // ... } ct:complex-type PhysicalResource { ct:extends Resource; ct:abstract true; // ... leaf serialNumber {type string;} } // … } Complete example in Appendix B of draft-linowski-netmod-yang-abstract-03

6. Modeling Class Inheritance Defining Classes ct:complex-type Hardware { ct:extends PhysicalResource; ct:abstract true; // ... } ct:complex-type ManagedHardware { ct:extends Hardware;leaf additionalinfo {type string;} leaf physicalAlarmReportingEnabled {type boolean;} // ... } // … Inheritance

7. Modeling type-safe, location agnostic relationships ct:complex-type Hardware { ct:extends PhysicalResource; // ... leaf-list physicalLink { type instance-identifier { ct:instance-type PhysicalLink; } } // ... } ct:complex-type PhysicalLink { ct:extends PhysicalResource; // ... leaf-list hardware { type instance-identifier { ct:instance-type Hardware; } } } Relationship Modeling

8. Modeling recursive containment ct:complex-type Equipment { ct:extends ManagedHardware; leaf installStatus {type int32;} // ... leaf vendorName {type string;} leaf dateOfLastService { //… } leaf interchangeability {type string;} leaf identificationCode {type string;} ct:instance-list equipment { ct:instance-type Equipment; } } Recursive containment

9. Hardware Entities as Physical Resources module hardware-entities { // ... import complex-types {prefix "ct";} import udmcore {prefix "uc";} grouping PhysicalEntityProperties { // ... leaf mfgDate {type yt:date-and-time; } leaf-list uris {type string; } } ct:complex-type HWModule { ct:extends uc:Equipment; description "Complex type representing module entries (entPhysicalClass = module(9)) in entPhysicalTable"; uses PhysicalEntityProperties; } // … ct:complex-type Backplane { ct:extends uc:Equipment; description "Complex type representing backplane entries (entPhysicalClass = backplane(4)) in entPhysicalTable"; uses PhysicalEntityProperties; } Complete example in Appendix B of draft-linowski-netmod-yang-abstract-03

10. Thank You! Questions?