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.
![]()
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
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:
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.
Organizational unit name (In the directory for SDX the organizational unit is typically a directory.)
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
- Subscriber Objects
- Service Objects
- Subscription Profile Objects
- Policy Objects
- Network Device Objects
- Configuration and System Management
- Workflow and OSM Schema Elements
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.
![]()
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.
![]()
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:
- Residential users—umcUser
- Enterprises—umcEnterprise
- Sites—umcSite
- Retailers—umcRetailer
- Routers—umcRouterSubscriber
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.
![]()
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:
- Description—Specifies the provider type (content provider or Internet service provider or others).
- Object identifier—1.3.12.2.1107.1.3.101.10.4.35
- Attribute syntax—Directory String
- Equality matching rule—Case Ignore Match
- Multivalued—False
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) 1—organizationalNameForm—allows 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:
- Mandatory attributes that an entry must contain
- Optional attributes that an entry can contain
- Auxiliary object classes that can be associated with the object class
- Optional attributes from the structural and auxiliary object class definitions that an entry must not contain
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:
- Attribute types—Lists the attributes types and the associated object classes that appear in the directory.
- Object classes—Provides a link to the directory that contains HTML files that describe each object class. You can also view a list of object classes from the Attribute Types page.
- Content rules—Lists and describes the content rules for structural object classes and the associated auxiliary classes.
- Structure rules—Lists and describes the structure rules for the schema and provides examples of how structure rules are used.
- Name forms—Provides a link to the directory that contains HTML files that describe each name form. You can also view a list of name forms from the structure rules page.
- Schema models—Provides links to graphical representations of the schema models for network, operator, policy, services, user, and workflow in GIF and PDF formats.
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.
For detailed information about LDAP, see the documentation for your LDAP server.