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

Structure Rules

The directory information tree (DIT) structure rules state which classes of object can be subordinate to other classes of an object in the DIT. For example, it is sensible to have service profiles subordinate to users. The DIT structure rules stop entries of the wrong (structural) object class from being put into an inappropriate place in the DIT. If you try to make an inappropriate entry, you will get an error message.

The structure rules are important to model dependencies.Structure Rule Sr1—organizationalNameForm—allows the creation of the root directory o=umc, which is the content prefix of the UMC directory.

Structure Rule Sr2—personNameForm—allows the umcAdmin directory under:

Structure Rule Sr3—organizationalNameForm—allows the creation of one organization layer under the root, which is used to separate the tree into two or more subtrees, holding specific information. The SDX application expects the following folders under o=umc:

Structure Rule Sr4—organizationalUnitNameForm—allows the creation of second-level folders that are represented by organizationalUnit objects. These folders are used to separate information based on some logic. The second-level folders are allowed in the servers, management, policies, and operators' subtrees. This structure provides for a more flexible way to distribute or replicate the directory in a granular way. It also makes it easier to define access controls. These folders are also used in the subscriber subtree underneath the retailer object when the superior rule is identical to structure rule Sr6.

Structure Rule Sr6—umcRetailerNameForm—allows retailer objects to be created under the subscriber subtree (see structure rule Sr3).

Structure Rule Sr5—umcUserNameForm—defines the creation of umcUser objects, which are derived from the inetOrgPerson object class. These users are created under the second-level folders, which are defined in structure rule Sr4. In addition, the concept of user groups for households is introduced. As a result, umcUser objects can be created as subordinates to an existing umcUser object. Structure rule Sr29 allows the creation of a second-level user. Because only retailers can subscribe to outsourced services, umcOutsourcingServiceProfiles must be subordinate to retailer objects, which are controlled by structure rule Sr25.

Residential subscribers are allowed to subscribe to RADIUS and SSP services. The subscription process therefore creates objects from the types umcRadiusPerson and sspServiceProfile as children of the user object. Structure rules Sr7 and Sr8—sspServiceProfileNameForm and umcRadiusPersonNameForm objects—allow these object creations.

Enterprise customers are created at the same level as residential customers. This level is subordinate to the second-level folder. Structure rule Sr30—umcEnterpriseNameForm—provides this functionality. Site objects can be created underneath any enterprise object, as governed by structure rule Sr31—umcSiteNameForm. Both enterprises and sites can have accesses, such as leased lines. As a result, umcAccessServiceProfiles are subordinates of enterprises and sites, which are controlled by structure rule Sr32—umcAccessServiceProfileNameForm. Structure rule Sr7 allows the creation of SSP service profiles underneath any umcEnterprise, umcSite, and umcAccessServiceProfile object. In addition, any umcSubscriber for enterprise services (that is, umcEnterprise, umcSite, and umcAccessServiceProfile) is allowed to subscribe to RADIUS services. The creation of the umcRadiusPerson objects, which is the result of those subscriptions, is governed by structure rule Sr8—umcRadiusPersonNameForm. Enterprise operators are users (represented by the object class person) who are allowed to manage some aspects of enterprise services (SSPServiceProfiles) according to their access rights. These operators are grouped into operator groups (groupOfUniqueName objects). Structure rule Sr2—personNameForm— and structure rule Sr38—groupOfUniqueNameForm—govern this feature.

Figure 1 depicts a possible structure in the subscriber subtree.


Figure 1: DIT structure in the subscriber subtree

All the umcServices objects, which include umcAccessService, sspService, umcRadiusService, umcOutsourceService, and umcMutexGroup objects, containing mutually exclusive sspservices are organized underneath the o=Services,o=umc object, which was created by applying structural rule Sr3. Structure rules Sr11, Sr12, Sr21, Sr24, and Sr15 govern the creation of these objects.

The scopes subtree contains locality objects governed by structure rule Sr22—localityNameForm. These objects represent scopes that have an association with virtual routers. Structure rule Sr12—sspServiceNameForm allows the creation of sspService objects as subordinates of those scope objects.

The network elements, represented by dlm1Chassis objects, are kept directly below the network subtree o=Network,o=umc due to structure rule Sr9—chassisNameForm. Virtual routers are placed underneath these network elements by applying structure rule Sr10—umcVirtualRouterNameForm.

Figure 2 depicts the structure in the services, scopes, and network subtrees.


Figure 2: DIT structure in the services, scopes, and network subtrees

The cached authentication profiles can also be added as children of the object o=AuthCache,o=umc, which is created by Sr3.

Besides the second-level folders governed by structure rule Sr4, many folders represented by the organizationalUnit object can be created by applying structure rule Sr19—organizationalUnitNameForm. Any of those folders, as well as the entry o=Policies,o=umc, are called policyFolder. Each policyFolder can contain a policy group, which is represented by the policyGroup object, controlled by structure rule Sr23—policyGroupNameForm. Policy groups contain policy lists that have policy rules as subordinates. Structure rules Sr27—policyListNameForm—and Sr28—policyRuleNameForm—allow the creation of those objects.

Global parameters are stored in umcGlobalParameter objects, which are subordinates of the o=Parameters,o=Users entry. Structure rule Sr33—umcGlobalParameterNameForm—allows the creation of those objects.

The SAE caches user profiles and authentications by writing objects from type cachedAuthenticationProfile into the directory where the user profiles are placed into the folder o=UserProfileCache. The authentications are stored underneath o=AuthCache,o=umc. Structure rule Sr13— cachedAuthProfileNameForm—controls the addition of those objects under the first-level folder.

Figure 3 depicts the subtrees for policies, parameters, and cache profiles.


Figure 3: DIT structure for policies, parameters, and cache profiles

The workflow and state-machine entries exist in the folder o=Workflow,o=umc. They are governed by structure rules Sr16—umcWorkFlowNameForm—and Sr17—umcStateNameForm.

Transaction locks are stored in the o=Locks,o=umc folder and are governed by structure rule Sr37—umcTransactionLockNameForm. The object state machine component can lock objects from type umcSubscriber, umcRetailer, and umcServiceProfile during the transaction state of those objects by creating entries that are subordinates of the transaction lock entry. These are residential users, retailers, enterprise users, users, sites, accesses, RADIUS profiles, outsourced service profiles, and SSP service profiles. Structure rules Sr5, Sr6, Sr7, Sr8, Sr25, Sr30, Sr31 and Sr32 allow these additions.

Figure 4 depicts the workflow and locked objects subtrees.


Figure 4: DIT structure in the workflows and locked objects subtrees

All management and configuration objects are created underneath o=Management,o=umc. This folder is organized by up to four layers of organizationalUnit objects by applying structure rules Sr4 and Sr19. Licenses are stored underneath ou=Licenses,o=Management,o=umc by applying structure rule Sr26—umcLicenseNameForm. The configuration objects are placed as children of objects ou=<application-name>,ou=configuration, o=Management,o=umc, where <application-name> specifies a UMC application such as SSP, POM, and others. Structure rule Sr20— umcConfigurationNameForm—governs this structure.

The SAE writes its administration URL into the folder ou=sspadminurl, o=servers,o=umc during startup and deletes it during shutdown. Structure rule Sr39—umcUrlNameForm—allows the addition of that kind of entry.

All operators, operator groups, and SDX components are stored in the operators' subtree. Structure rule Sr2 takes care of the creation of operators and components, whereas structure rule Sr38—groupOfUniqueNameForm—allows the creation of groups.

Figure 5 depicts the management, servers, and operators subtrees.


Figure 5: DIT structure in the management, servers, and operators' subtrees
[Contents] [Prev] [Next] [Index] [Report an Error]