Sample Uses of Structure Rules

This page shows how to use structure rules to create the following sample subtrees:

Sample Subscriber Subtree

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. SR 7 and SR 8—sspServiceProfileNameForm and umcRadiusPersonNameForm—allow these object creations.

Enterprise customers are created at the same level as residential customers. This level is subordinate to the second-level folder. SR 30—umcEnterpriseNameForm—provides this functionality. Site objects can be created underneath any enterprise object, as governed by SR 31—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 SR 32—umcAccessServiceProfileNameForm. SR 7 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 SR 8—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). SR 2—personNameForm—and SR 38—groupOfUniqueNameForm—govern this feature.

The following figure depicts a possible structure in the subscriber subtree.


Sample Services, Scopes, and Network Subtrees

All the umcServices objects, which include umcAccessService, sspService, umcRadiusService, umcOutsourceService, and umcMutexGroup objects, containing mutually exclusive SSP services are organized underneath the o=Services, o=umc object, which was created with SR 3. SRs 11, 12, 21, 24, and 15 govern the creation of these objects.

The scopes subtree contains locality objects governed by SR 22—localityNameForm. These objects represent scopes that have an association with virtual routers. SR 12—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 SR 9—chassisNameForm. Virtual routers are placed underneath these network elements by applying SR 10—umcVirtualRouterNameForm.

The following figure depicts the structure in the services, scopes, and network subtrees.


Sample Policies, Parameters, and Cache Profiles Subtrees

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

Besides the second-level folders governed by SR 4, many folders represented by the organizationalUnit object can be created by applying SR 19—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 and is controlled by SR 23—policyGroupNameForm. Policy groups contain policy lists, which have policy rules as subordinates. SR 27—policyListNameForm—and SR 28—policyRuleNameForm—allow the creation of those objects.

Global parameters are stored in umcGlobalParameter objects, which are subordinates of the o=Parameters, o=Users entry. SR 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. SR 13— cachedAuthProfileNameForm—controls the addition of those objects under the first-level folder.

The following figure depicts the subtrees for policies, parameters, and cache profiles.


Sample Workflow and Locked Objects Subtrees

The workflow and state-machine entries exist in the folder o=Workflow,o=umc. They are governed by SR 16—umcWorkFlowNameForm—and SR 17—umcStateNameForm.

Transaction locks are stored in the o=Locks, o=umc folder and are governed by SR 37umcTransactionLockNameForm. 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. SRs 5, 6, 7, 8, 25, 30, 31 and 32 allow these additions.

The following figure depicts the workflow and locked objects subtrees.


Sample Management, Servers, and Operators 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 SRs 4 and 19. Licenses are stored underneath ou=Licenses, o=Management, o=umc by applying structure rule SR 26umcLicenseNameForm. 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 SAE, POM, and others. SR 20umcConfigurationNameFormgoverns this structure.

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

All operators, operator groups, and SDX components are stored in the operators' subtree. SR 2 takes care of the creation of operators and components, whereas SR 38groupOfUniqueNameForm—allows the creation of groups.

The following figure depicts the management, servers, and operators subtrees.