Object Classes
Each object class is derived from the abstract object class top where the values of the attribute type objectClass describe the kind of object that an entry represents. The objectClass attribute is present in every entry with at least two values; one entry is "top".
The dlm1ManagedElement is an abstract class that provides a common superclass, or top of the inheritance tree, for nonassociation classes in the Common Information Model (CIM) schema. It includes the attributes dlmCaption and dlmDescription.
To support naming in the LDAP mapping of the core Distributed Management Task Force (DMTF) schema, the attribute orderedCimKeys is defined to provide the relative distinguished name (RDN) for directory implementations.
The Juniper Networks management products make use of the Directory Information Tree (DIT) containments (that is, the hierarchy of the tree for associations) and uses single attribute values for naming attributes. This means, whenever orderedCimKeys is used as a naming attribute, the RDN looks like orderedCimKeys=ERX01. This example depicts the RDN of an edge router chassis.
The dlm1ManagedSystemElement is the base class for the system element hierarchy. Any distinguishable component of a system is a candidate for inclusion in this class. Examples of this are software components, such as files, devices, disk drives and controllers, and physical components, such as chips and cards.
Object Class Tables
Object class tables are provided in the subdirectory objectClasses in HTML format. This directory is located on your SDX software CD in the folder SDK/doc/ldap.
A hyperlinked table that contains attribute types and related objects is provided in the HTML file sdxSchemaIndex. This table is also located in the folder SDK/doc/ldap.
Object Representing Folders
Folders divide the directory information tree into logical subtrees. The content prefix of the UMC tree is o=umc. The tree is divided into subtrees for subscribers and service profiles, services, networks, policies, workflows, authentication profiles for equipment registration for DHCP users, and authentication for persistent login for DHCP users.
The object class organizationalUnit is used for creating folders under the first level of folders; that is,
ou=<2nd-level folder-name>,retailerName=<retailer-ID>,o=Users, o=umcThe first-level folders under o=umc are created during the setup of the directory. The second-level folders are created with the SDX Admin component.
The standard object classes organization and organizationalUnit divide trees into subtrees. The SDX components expect additional parameters in some cases that are not part of the object classes. This additional information is part of an auxiliary class, called moreInformationAuxClass, that can be attached to organization and or organizationalUnit.
Subscriber Objects
There are several types of subscribers:
The folders underneath the Retailer object can be marked as umcSubscribers. This provides a better grouping mechanism for Service Selection Portal (SSP) services.
Service Template Objects
Service templates consist of service-specific information. UMC supports four kinds of high-level services:
- RADIUS services (PPP and DHCP broadband services)
- Access services (leased line for enterprises)
- SSP service (for residential and enterprise users)
- Outsourced services (for retail provider)
All service templates are stored under o=Services,o=umc. SSP services can be stored under l=<locality>,o=Scopes,o=umc as well.
The SDX application supports parameter substitution for the SSP services, as well as for the instance, indicating the scope of an sspService, which is realized by using the object class locality. The parameter substitution requires the attachment of the object class parameterAuxClass to locality and sspService.
We recommend that the policies, state machines, and workflows be defined and created in the directory before the service template creation, since references to these objects are done at that time. The service definition interface should provide LDAP search functionality that retrieves all available policies, state machines, and workflows.
Subscription Profile Objects
When a subscriber (that is, either residential, retailer, enterprise, site or access) subscribes to an offered service that is modeled by the service template objects, the UMC subscription component creates a subscription profile called the umcServiceProfile. The umcServiceProfile subscription is created as a subordinate of the subscriber object in the tree. The SDX application supports parameter substitution for SSP service subscriptions, which means that the auxiliary object class parameterAuxClass can be attached to an instance of sspServiceProfile.
Policy Objects
The Policy Information model for SDX software is based on the Policy Core Information Model (PCIM) that is mapped to the Policy Framework LDAP core schema in IETF. SDX software extends this model to be very close to the Policy model the router uses. A policy group object consists of one or more policy lists which contain one or more policy rules. A policy rule consists of policy actions and policy conditions. The objects policy group, policy list, and policy rules are mapped to structural object classes. Each of these classes is derived from the object class policy.
Network-Device Objects
The physical aspect of network elements is modelled with CIM classes. As a result, the object class dlm1Chassis is used for any Juniper Networks equipment as well as any network devices that are part of the connection path. There might be congestions points along that connection path. Those connection points are modeled by the object class networkInterface, which are subordinates of the network-device objects within the directory tree.
The SSP requires information about the logical aspects of the router, such as virtual routers or interface classifications. These aspects are modelled by the UMC class umcVirtualRouter. Objects from the type umcVirtualRouter are children of the entry. The umcClassificationProfile is an auxiliary object class that is attached to the entry. Those network devices are used for grouping the virtual routers within the tree and are stored in the folder o=network,o=umc.
The network devices used for grouping the congestion points are stored in the folder o=AdmissionControl,o=umc.
Workflow and OSM Schema Elements
Workflows can be stored in the UMC directory in bytecode format. Workflows and state-machines are stored in the o=Workflows,o=umc tree. Whenever objects are locked by the OSM, the locked objects are stored in o=Locks,o=umc.
Configuration and System Management
Parts of the SSP configuration are stored in the directory. Besides the configuration itself, the license strings of the SAE are stored in the directory as well.
The agent and console discovery in the system management component of UMC needs to obtain information about where to send traps, and about the list of agents that the system management console must deal with.
All configuration and management objects are stored in the DIT subtree with the base o=Management,o=umc.
The CIM class dlm1UnitaryComputerSystem represents the computer systems where SAE and SM components are installed. The object class umcHost is therefore replaced by the CIM class dlm1UnitaryComputerSystem, where the IP address is kept in the CIM attribute dlmIdentifyingDescriptions. The location (for example, POP A) is specified in dlmOtherIdentifyingInfo.