[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Directory Object Model and Schema

The SDX directory schema is based on X.500/LDAP standards and the Common Information Model version 2.5 (CIM 2.5) schemas. The CIM provides definition of management information for systems, networks, applications, and services. The SDX schema extends the CIM to provide elements for modeling services; residential, enterprise, and retail customers; policies; network elements; and others.

Directory Object Model

The directory object model represents the way objects are stored in a directory. An object comprises data that is stored as entries and organized into a hierarchical structure called a directory information tree (DIT). A DIT contains a number of other trees called subtrees. Figure 8 shows the top-level objects, as well as some subordinate objects in the Users folder in the SDX directory tree as it appears in SDX Admin.


Figure 8: Directory Tree as Displayed by SDX Admin

Each entry has a number of attributes—special characteristics that provide information about the entry. An attribute can also be referred to as a property, as they are in SDX Configuration Editor.

Each entry has an attribute to specify the name for the entry. A name for an entry must be unique within a specified level in the tree hierarchy; for example, each retailer name must be unique with the Users folder, as illustrated in Figure 8.

Naming Convention for Entries

The name for an entry can be expressed as either a relative distinguished name (RDN) or a distinguished name (DN). The RDN identifies a unique entry at one level in the directory tree. Each RDN identifies an attribute type with the associated value. The following list shows sample RDNs from Figure 8:

o=umc
o=Users
retailername=virtual-SP
ou=first-region
unique-id=joe


NOTE: Do not use the "#" character in DNs. It can cause various problems.

A DN is a comma-separated sequence of hierarchical entry names in the tree, concatenated from a specified entry backward to the base, or root, of the tree structure. In contrast to the RDN, the DN for an entry is unique within the entire directory. Each entry in the directory is identified and can be located by its distinguished name (DN). The DN for subscriber Joe would be the following:

unique-id=joe, ou=first-region, retailername=virtual-SP, o=Users, o=umc

NOTE: Throughout the SRC documentation, in text we show the elements of a DN separated by comma/space pairs. We do this for readability. The SRC software and the LDAP specifications require acceptance of the space, but the space is not necessary.


A base DN is the DN of an object that serves as the starting point for a directory search. For the directory as a whole, the base DN is o=umc for a default installation of the SRC software; it is the root object of the tree. For a search of policies, the base DN is the following:

o=policies, o=umc

A bind DN is the DN of a login to the directory. This DN must be entered (like a username) with a password to log in to the directory. In the SRC software, you use the bind DN and a password when you access the directory; for example, when you start SDX Admin to view or modify the contents of the directory.

Table 6 lists some of the common DN attribute types.




Table 6: Common DN Attribute Types 
Attribute Type Abbreviation
Attribute Type Definition

cn

Common name

o

Organization name

ou

Organizational unit name (In the directory for SDX the organizational unit is typically a directory.)

uid

User ID

Directory Schema

An LDAP schema defines the content and structure of the directory tree. It determines the types of entries that can exist in the directory, the organization for entries, and the relationships between the different types of entries. The directory schema for the SRC software includes entries primarily for management configuration, network device configuration, policies, services, retailers or providers, and subscriber profiles.

Object Classes

Object classes define the different types of entries that can exist in the directory; each entry in the directory belongs to one or more object classes. An object class contains specified attributes to define the characteristics of the entry. For information about attributes, see Attributes.

The following sections provide information about the objects in the SDX directory:

Objects Representing Folders

Folders divide the DIT into logical subtrees. The content prefix of the SDX tree is o=umc. The tree is divided into subtrees, such as those for subscribers and service profiles, services, networks, and policies. Figure 9 shows the first-level folders under o=umc that are created during the setup of the directory. You can create the second-level folders by using SDX Admin.


Figure 9: First-Level Folders

The standard object classes organization and organizationalUnit divide trees into subtrees. In some cases, these objects classes do not provide all the attributes required by an entry. An auxiliary object class (an object class that supplies additional information to augment structural object classes) supplies the additional attributes. This moreInformationAuxClass can be attached to the organization object class and the organizationalUnit object class.

You use the object class organizationalUnit to create folders under first-level folders. For example, in Figure 10, the ou=east-coast folder is an organizationalUnit object.


Figure 10: Sample Retailer Folders

The DN for this folder is:

ou=east-coast, retailerName=SP, o=Users, o=umc

Subscriber Objects

The directory provides object classes for the categories of subscribers supported by the SRC software, such as:

Folders under a umcRetailer object provide a convenient way to organize groups of subscribers. These folders can use the umcSubscriber auxiliary object class.

Subscriber objects are stored under o=Users, o=umc.

Service Objects

The umcService object class models is the base class in the service hierarchy. At a high level, SRC provides object classes for services.

Services are also referred to as SSP services (for residential and enterprise users)—sspService.

Service objects are stored under o=Services, o=umc. Services can also be stored under l=<locality>, o=Scopes, o=umc.

The SRC software supports parameter substitution for services. Parameter substitution requires the attachment of the auxiliary object class parameterAuxClass to an sspService object and to a locality if the sspService object is configured within a scope.

Subscription Profile Objects

When a subscriber subscribes to a service, the SDX subscription component creates an object for the subscription profile from the object class umcServiceProfile. The umcServiceProfile subscription object is created as a subordinate (child) of the subscriber object in the tree. The SRC software supports parameter substitution for service subscriptions, which means that the auxiliary object class parameterAuxClass can be attached to an instance of sspServiceProfile.

Subscriptions are stored under entries subordinate to o=Users, o=umc.

Policy Objects

The policy information model for SRC software is based on the Policy Core Information Model (PCIM) that is mapped to the Policy Framework LDAP core schema by the IETF. The SRC software extends this model to produce a policy model that is very close to the one that routers and other network devices use. A policy group object consists of one or more policy lists, which contain one or more policy rules. A policy rule consists of policy conditions and policy actions. 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.

Policy objects are stored under o=Policies, o=umc.

We recommend that you define policies in the directory before you create service objects. Service objects reference policies. The service definition interface should provide LDAP search functionality that retrieves all available policies.

Network Device Objects

Physical network elements are modeled with the CIM Chassis object classes. The object class dlm1Chassis is used for any Juniper Networks equipment, SDX devices, and network devices in the connection path.

Some SRC components, such as the SAE, require additional information about the router, such as virtual routers or interface classifications. The SDX object class umcVirtualRouter is a structural object class that represents virtual routers on Juniper Networks routing platforms. The umcClassificationProfile is an auxiliary object class that is attached to the structural object class.

Network devices are stored in the folder o=network, o=umc. Virtual routers are stored subordinate to network devices. Figure 11 shows a sample network folder that contains a number of network devices.


Figure 11: Sample Network Folder

Congestion points in a connection path are modeled by the object class networkInterface, which is subordinate to network device objects in the directory tree. The network devices used for grouping the congestion points are stored in the folder o=AdmissionControl, o=umc.

Configuration and System Management

Some of the SDX configuration information, such as license configuration data, is stored in the directory.

The CIM object class dlm1UnitaryComputerSystem represents the hosts on which SAE and system management components, such as an SNMP server, are installed. For management components, the CIM object class dlm1UnitaryComputerSystem replaces the object class umcHost.

The dlm1UnitaryComputerSystem object class stores an IP address in the CIM attribute dlmIdentifyingDescriptions. The location (for example, POP A) is specified in dlmOtherIdentifyingInfo.

All configuration and management objects are stored under o=Management, o=umc.

Workflow and OSM Schema Elements

Workflows can be stored in the SDX directory in byte-code format. The umcWorkflow object is a structural object class that represents workflow objects. Workflows and state machines are stored under o=Workflows, o=umc. Whenever objects are locked by the object state manager, the locked objects are stored in o=Locks, o=umc.

Attributes

An attribute contains a characteristic and the values for that characteristic. Attributes for an object class can be required or optional. An attribute type provides the syntax, sorting, and comparison rules to be used for an attribute.

The following example shows the characteristics and values for the sspType attribute:

Structure Rules

DIT structure rules are rules specific to an object class; they specify the location of the object class in the DIT and a name form which identifies naming attributes for an object class. Structure rules state which object classes can be located superior (as a parent) and subordinate (as a child) to other object classes. For example, service profiles are subordinate to users. The DIT structure rules prevent the addition of entries that belong to an object class in an unsupported location in the DIT. If you try to add an entry in an unsupported location, you receive an error message.

The structure rules are used to model dependencies in the DIT. For example, structure rule (SR) 1organizationalNameFormallows the creation of the root directory o=umc.

Content Rules

A DIT content rule defines which attributes an entry for a specified object class can contain, such as:

Where to Find More Information About the Object Model and Directory Schema

The SRC software provides detailed documentation of the object model and the directory schema, including graphical representations of the schema models. See the LDAP schema documentation in the SRC software distribution in the folder /SDK/doc/ldap/ or on the Juniper Networks Web site at

http://www.juniper.net/techpubs/software/management/sdx

The documentation for the SDX object model and schema provides the following topics:

The SRC software also provides sample data files in LDIF, an easy-to-read format. The location of the LDIF files on your system depends on the directory integrated with the SRC software. Table 7 lists the location of the LDIF files for the various directories.




Table 7: Location of LDIF Files
Directory Server
Directory That Contains LDIF Files

DirX directory server

<DIRX_HOME>/customize/data

where <DIRX_HOME> is the DirX home directory

eTrust Directory

/opt/UMC/conf/etrust/sdx_ldif

Oracle Internet Directory

/opt/UMC/conf/OID

SUN ONE Directory Server

/opt/UMC/conf/iDS

For detailed information about LDAP, see the documentation for your LDAP server.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]