1. Kalua DML Examples bernd.linowski@nsn.com martin.storch@nsn.com mikko.lahdensivu@nsn.com mehmet.ersue@nsn.com

2. Example for agreed RCDML requirements DHCP module in Kalua

3. DHCP example – module header DHCP DHCP example, as in http://tools.ietf.org/html/draft-presuhn-rcdml- 03#appendix-C http://example.org/ns/dhcp dhcp 1 Nokia Siemens Networks urn:ietf:params:xml:ns:netmod:base ndl http://example.com/ns/int int interfaces

4. DHCP example – classes ndl:ipAddress IP address ndl:ipAddress kalua:dateTime... ip_address

5. DHCP example – relationships shared_network parent subnet children

6. Examples for extended RCDML requirements 1.Typed extensions 2.Calculated relationships 3.Hierarchical data

7. Support for RCDML requirement: 3.3.3. Modular extension (Agreed) AugmentationTyped extension Standard base type Vendor-specific type augments Stakeholder: vendor Stakeholder: e.g. IETF Standard base type Specialized subtype 2 extends Stakeholders: IETF or vendor Stakeholder: e.g. IETF Specialized subtype 3 extends Specialized subtype 1 extends Further specialized subtype 3a extends

8. Extension mechanisms: example AugmentationTyped extension entPhysicalEntry Stakeholder: e.g. IETF entPhysicalEntry backplane extends Stakeholders: IETF or vendor Stakeholder: e.g. IETF module extends chassis extends ACME:chipset extends Augmentation does not support mutually exclusive subtypes

9. NETCONF payload example 1 Acme Chipset Nimbus 2000 acmeProducts.moduleTypes.1 0 module 0 100-A A(1.00.02) … 0007372293 true 11-10-2008T08:43:00 01-03-2005T10:20:00 1A34 true

10. Information about a particular physical entity. Arbitrary value that uniquely identifies the physical entity. kalua:integer A textual description of physical entity. kalua:string … entPhysicalIndex Defining the base class in Kalua

11. Building an extended type in Kalua entPhysicalEntry kalua:dateTime

12. Building an extended type in Kalua kalua:dateTime rfc2737:module kalua:string kalua:boolean false

13. Type extensions in a nutshell Typed extensions = 1.mutually exclusive augmentations + 2.augmentation of augmentations... applicable to any element type definition (!) Base type need not be designed for extensibility

14. SMI example with human-readable relationships wmanIfBsSsProvisionedForSfTable OBJECT-TYPE SYNTAX SEQUENCE OF WmanIfBsSsProvisionedForSfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps the MAC addresses of SSs to the service flows provisioned in wmanIfBsProvisionedSfTable." REFERENCE "Subclause 6.3.14 in IEEE Std 802.16-2004" ::= { wmanIfBsPacketCs 2 } WmanIfBsSsProvisionedForSfEntry ::= SEQUENCE { wmanIfBsSsProvMacAddress MacAddress, wmanIfBsProvSfId Unsigned32, wmanIfBsSsProvisionedForSfRowStatus RowStatus } wmanIfBsSsProvMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC address of the SS, the service flow is created with." ::= { wmanIfBsSsProvisionedForSfEntry 1 } Source: IEEE 802.16 – 2004 MAC and PHY MIB for WirelessMAN

15. Kalua model with machine-readable relationship - source - target expression: „wmanIfBsSsProvMacAddress = wmanIfBsSsMacAddress”

16. Definition of related classes A 32 bit quantity that uniquely identifies a service flow. The value of this object can be used by BS to index the wmanBsProvisionedSfTable kalua:integer The MAC address of the SS, the service flow is created with ndl:MacAddress ndl:MacAddress wmanIfBsSsMacAddress

17. Kalua: a calculated relationship $source/wmanIfBsSsProvMacAddress = $target/wmanIfBsSsMacAddress wmanIfBsSsProvisionedForSfEntry wmanIfBsSsProvisionedServiceFlow unbounded wmanIfBsRegisteredSsEntry wmanIfBsRegisteredSs 1

18. Calculated relationships in Kalua “Query” built into the model  Semantic link between elements, for navigation  Client dynamically evaluates the condition based on the data  Relationship is established when the condition is true Does not impose any referential constraint (!)  Service flow can be provisioned even when subscriber has not subscribed yet Non-intrusive  Can be added on top of existing data models

19. RCDML: Hierarchical data 3.5.6. Hierarchical Data The solution MUST support defining data in hierarchies of arbitrary depth. This enables closer modeling of data to real world relationships, such as containment.

20. Extended hierarchical data requirement Elements with more than one parent type Elements of the same type can appear in arbitrary levels of the NETCONF payload containment tree. FileSystem File contains Directory contains Example: Directory has two parents: 1. FileSystem and 2. Directory

21. Extended hierarchical data requirement Elements with more than one parent type Elements of the same type can appear in arbitrary levels of the NETCONF payload containment tree. entityMIB entPhysicalEntry contains entPhysicalTable contains Example: entPhysicalEntry has two parents: 1. entPhysicalTable and 2. entPhysicalEntry

22. Extended hierarchical data requirement Benefits  Containment relationships need not be maintained explicitly Pointer attribute entPhysicalContainedIn becomes obsolete NETCONF has natural, built-in support for hierarchically structured data  Exploit the benefits of XML NETCONF is based on XML, which allows arbitrarily deep nesting hierarchies of data Without nesting, most SNMP MIB mappings to NETCONF would consist of three levels only: 1.MIB level: container elements 2.Table level: one container for the table 3.Table entry level: most of the data