Directory Schema for SRC Software
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
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 5 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 6, 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 7 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.
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, and user 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 6 lists the location of the LDIF files for the various directories.
For detailed information about LDAP, see the documentation for your LDAP server.