Summary of Structure Rules

Structure rules for the directory information tree (DIT) state which object classes can be subordinate to other object classes in the DIT. Structure rules model dependencies in the schema and ensure that new entries appear in the appropriate place in the tree.

The structure rules can be grouped into the following categories:

You can also view sample uses of structure rules.

General Rules

The SDX schema contains a number of structure rules that govern the overall structure of the directory, such as the root directory, first-level entries, and locations at which folders can be added.

Root Directory

Structure rule 1 (organizationNameForm) allows the root directory (that is content prefix or namespace) o=umc to be created.

First-Level Folders

Structure rule 3 (organizationNameForm) allows one organization layer to be created subordinate to the root directory. This layer separates the tree into subtrees, each of which holds a specific type of information. The SDX application expects the following folders subordinate to o=umc:

Second-Level Folders

Structure rule 4 (organizationalUnitNameForm) allows second-level folders that are represented by organizationalUnit objects to be created. These folders logically separate information. The second-level folders can be added in the Servers, Management, Policies, and Operators subtrees.

Second-level folders provide some flexibility when you distribute or replicate the directory. Structure rule 4 also makes it easier to define access controls. In addition, Second-level folders are used in the Subscriber subtree, which is subordinate to the retailer object when the superior rule is identical to structure rule 6 (umcRetailerNameForm).

General Objects Within Folders

Structure rule 19 (organizationalUnitNameForm) allows organizationalUnits objects to be created subordinate to other organizationalUnits, enterprise subscribers, and site subscribers.

Structure rule 20 (umcConfigurationNameForm) allows configuration objects to be created subordinate to organizationalUnits and to other configuration objects.

Structure rule 35 (umcComponentNameForm) allows umcComponent objects to be created subordinate to second level folders; and structure rule 36 (umcComponentNameForm) allows umcComponent objects to be created subordinate to other (umcComponent) objects.

Structure rule 38 (groupOfUniqueNamesNameForm) allows group objects to be created subordinate to organizations, organizationalUnits, and retailer, enterprise, site, and access subscribers.

Rules for Directory Access

Structure rule 2 (personNameForm) allows a person object, such as cn=umcAdmin entry, to be subordinate to:

Enterprise operators are users (represented by the object class person) who manage some aspects of enterprise services (SSPServiceProfiles) as specified by their access rights. These operators are grouped into operator groups (groupOfUniqueName objects). Enterprise operators can be subordinates of umcEnterprise, umcSite, and umcAccessServiceProfile objects, where structure rules 30 (umcEnterpriseNameForm), 31 (umcSiteNameForm), and 32 (umcAccessServiceProfileNF) are superior structure rules.

Rules to Manage Subscriber Objects

The SDX subscriber model provides support for the following types of subscribers:

Residential Subscribers

Residential subscribers are individuals or members of a household who subscribe to services through a retail service provider. The object type umcUser (derived from inetOrgPerson) represents residential subscribers.

Structure rule 5 (umcUserNameForm) allows umcUser objects to be created subordinate to the second-level folders. Because a household can contain a group of subscribers, structure rule 29 (umcUsrNameForm) allows umcUser objects to be created subordinate to an existing umcUser object.

Residential subscribers can be created subordinate to a retailer (umcRetailer). Structure rule 6 (umcRetailerNameForm) allows retailer objects to be created in the Subscriber subtree (o=Users, o=umc).

Enterprise Subscribers

An enterprise subscriber represents an organization. The object class umcEnterprise represents enterprise subscribers. An enterprise subscriber can include several site subscribers that have the object class umcSite. Enterprises and sites contain access subscribers; an access represents a layer 2 connection between a device at a customer’s physical location and a router that gives the enterprise subscribers access to the Internet and, in some cases, to a VPN.

Structure rule 30 (umcEnterpriseNameForm) allows enterprise subscribers to be created at the same level as residential customers—a level that is subordinate to a second-level folder. Site objects can be created subordinate to any enterprise object, as specified by structure rule 31 (umcSiteNameForm).

Both enterprises and sites can have accesses, such as leased lines. As such, umcAccessServiceProfiles are subordinates of enterprises and sites, which are controlled by structure rule 32 (umcAccessServiceProfileNameForm).

Router Subscribers

A router subscriber is an SDX-managed router that is used to activate services. It is used primarily to provide integration with an application that can activate and deactivate port-mirroring policies.

Structure rule 53 (umcRouterSubscriberNameForm) allows router subscriber objects (umcRouterSubscriber) to be created subordinate to subscriber folders, enterprises, and sites.

Rules for DHCP Profiles

Profiles of subscribers who connect to the network through DHCP can be stored with or without a MAC address. Subscribers who have profiles that include a MAC address can automatically obtain an authenticated IP address when logging in to the demo Service Selection Portal.

Structure rule 46 (dhcpProfileNameForm) allows DHCP profiles with macAddress as naming attribute to be created subordinate to cached authentication profiles; structure rule 47 (dhcpProfileName2Form) allows DHCP profiles that do not include a MAC address to be created subordinate to cached authentication profiles.

Structure rule 13 (authProfileNameForm) allows cached authentication profiles with macAddress as the naming attribute to be created subordinate to an organizational layer. Structure rule 40 (authProfile2NameForm) allows cached authentication profiles that do not include a MAC address to be created subordinate to an organizational layer.

Service Rules

The schema provides rules to manage and organize services:

Types of Services

The SDX software lets you manage the following types of services:

Structure rule 11 (umcAccessServiceNameForm) for access services, structure rule 12 (sspServiceNameForm) for value-added services, and structure rule 21 (umcRadiusServiceNameForm) for RADIUS services allow the services to be created in the Services subtree (o=Services, o=umc).

Access service profiles have the object class umcAccessServiceProfile. Structure rule 7 (sspServiceProfileNameForm) allows the creation of value-added service profiles subordinate to any umcEnterprise, umcSite, and umcAccessServiceProfile object.

Service Management Services

Mutex groups and service scopes provide a way to manage a group of services. Mutex groups define a set of services that are mutually exclusive—services that the SAE cannot simultaneously activate for a particular subscriber. Service scopes are collections of services and mutex groups, and optionally define parameter substitutions for scope-associated services.

Structure rule 15 (umcMutexNameForm) allows mutex groups to be created in the Services subtree (o=Services, o=umc) and in the Scopes subtree (o=Scopes, o=umc). Structure rule 22 (localityNameForm) allows service scopes to be created in the Scopes subtree. After a scope is created, mutex groups and value-added services can be added to a scope.

Persistent Sessions for Value-Added Services

Normal value-added services that do not require authentication can also be configured to support persistent sessions. A persistent session for a service starts when a subscriber logs in to a portal, and remains active until logout. If the subscriber loses the connection to the network, the SAE restores the service when the subscriber reconnects. Structure rule 41 (persistentServiceNameForm) allows profiles for persistent services to be stored subordinate to an organizational unit.

Outsourced Services

An outsourced service is a service that wholesalers sell to retailers and that retailers in turn sell to their customers. An outsourced service has the object class umcOutsourceService.

Structure rule 24 (umcOutsourcingServiceNameForm) allows access outsourcing service objects to be created in the Services subtree (o=Services, o=umc). Because only retailers can subscribe to outsourced services, umcOutsourcingServiceProfiles must be subordinate to retailer objects, which are controlled by structure rule 25 (umcOutsourcingServiceProfileNameForm).

Service Schedules

Service schedules specify the times to activate, deactivate, or disable (deny access to) a service. Service schedules can be applied only to services that do not require subscriber authentication.

Structure rule 45 (serviceScheduleNameForm) allows service schedule objects to be created subordinate to an organizational unit, or to an enterprise, retailer, site, scope, subscriber, or access service. Structure rule 54 (subscriberScheduleNameForm) allows a subscriber schedule (subscriberSchedule object) to be created subordinate to subscriber folders, enterprises, sites, router subscribers, and access services.

Policy Rules

The SDX policy model includes the following types of objects:

Rules for Global Parameters

Global parameters are parameters that are available to any policy. Global parameters are stored in the subtree o=Parameters, o=umc, as specified by structure rule 33 (umcGlobalParameterNameForm).

Subscription Rules

Residential subscribers and enterprise subscribers can subscribe to specified services.

Structure rules 7 (sspServiceProfileNameForm) and 8 (umcRadiusPersonNameForm) allow subscription objects to be created. Residential subscribers can subscribe to RADIUS and value-added services. The subscription process creates umcRadiusPerson objects and sspServiceProfile objects subordinate to the subscriber object.

Structure rule 7 also allows a service profile for a value-added service to be created subordinate to a umcEnterprise, umcSite, and umcAccessServiceProfile object. A subscriber to enterprise services (that is, umcEnterprise, umcSite, and umcAccessServiceProfile) can subscribe to RADIUS services, as specified by structure rule 8.

Any umcSubscriber object for enterprise services (that is, umcEnterprise, umcSite, and umcAccessServiceProfile) is allowed to subscribe to RADIUS services. These subscriptions create umcRadiusPerson objects as specified by structure rule 8 (umcRadiusPersonNameForm).

Rules for Network Objects

A number of structure rules control where objects representing hardware components can be added to the directory.

Structure rule 9 (DMTF-ChassisNameForm) allows objects representing JUNOSe routers (dlm1Chassis) to be created in the Network subtree (o=Network, o=umc).

Structure rule 10 (umcVirtualRouterNameForm) allows virtual router objects (umcVirtualRouter) to be created subordinate to JUNOSe (dlm1Chassis) objects.

Structure rule 18 (DMTF-UnitaryComputerSystemNameForm) allows computer systems to be created subordinate to an organizational layer.

Structure rule 44 (networkInterfaceNameForm) allows interfaces with interfaceName as the naming attribute to be created subordinate to JUNOSe (dlm1Chassis) objects.

Rules for Congestion Points

The SDX software lets you manage congestion points on the network. Structure rule 48 (congestionPointNameForm) allows cached congestionPoint objects to be created subordinate to organizations. Structure rule 52 (congestionPointProfileNameForm) allows congestion point profile objects to be created subordinate to network interfaces, network devices, and folders.

License Rules

Objects that contain configuration information for the SDX license are stored in the directory.

Structure rules 26 (umcLicenseNameForm) and 42 (umcLicenseStateNameForm) allow license objects to be created subordinate to an organizational unit. Structure rule 43 (umcLicenseErxNameForm) allows JUNOSe license objects to be created subordinate to an organizational unit.

Workflow Application Rules

The workflow application in the SDX application library is a component that performs a specified set of tasks. The tasks can be work items or other workflows.

Structure rule 16 (umcWorkflowNameForm) allows workflow objects to be created in the Workflows subtree (o=Workflows, o=umc). Structure rule 17 (umcStateMachineNameForm) allows state machine objects (umcStateMachine) to be created in the Workflows subtree. State machines represent a specified set of transitions to manage the life cycle of a service.

Other Rules

The SDX schema also includes the following miscellaneous structure rules: