Kalua DML Examples

Example for agreed RCDML requirements DHCP module in Kalua

DHCP example – module header DHCP DHCP example, as in 03#appendix-C dhcp 1 Nokia Siemens Networks urn:ietf:params:xml:ns:netmod:base ndl int interfaces

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

DHCP example – relationships shared_network parent subnet children

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

Support for RCDML requirement: 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

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

NETCONF payload example 1 Acme Chipset Nimbus 2000 acmeProducts.moduleTypes.1 0 module A A( ) … true T08:43: T10:20:00 1A34 true

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

Building an extended type in Kalua entPhysicalEntry kalua:dateTime

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

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

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 in IEEE Std " ::= { 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 – 2004 MAC and PHY MIB for WirelessMAN

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

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

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

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

RCDML: Hierarchical data 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.

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

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

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