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:

• General Rules
• Rules for Directory Access
• Rules to Manage Subscriber Objects
• Rules for DHCP Profiles
• Service Rules
• Policy Rules
• Rules for Global Parameters
• Subscription Rules
• Rules for Network Objects
• Rules for Congestion Points
• License Rules
• Workflow Application Rules
• Other 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:

• o=Users, o=umc—Contains subscriber information (including service profiles)
• o=Services, o=umc—Contains service information
• o=Scopes, o=umc—Contains scopes that define a group of virtual routers and value-added services (also called SSP services)
• o=Policies, o=umc—Contains policy information
• o=Parameters, o=umc—Contains global parameter information
• o=Network, o=umc—Contains network information
• o=AuthCache, o=umc—Contains cached information for DHCP subscribers who log in to an SAE (typically through a Web portal) and register their equipment
• o=UserProfileCache, o=umc—Contains cached information for subscribers who are logged in to the SAE
• o=Workflows, o=umc—Contains workflow and state machine objects
• o=Locks, o=umc—Contains objects that are locked by transactions
• o=Servers, o=umc—Contains SAE server information
• o=Management, o=umc—Contains configuration and system management information
• o=Operators, o=umc—Contains operators (who can have different rights), operator groups, and SDX components

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:

• o=umc—Contains the root directory (structure rule 1 is the superior structure rule)
• o=operators, o=umc—Contains second-level organizations
• ou=components, o=operators, o=umc—Contains SDX components (structure rule 4 is the superior structure rule) that are stored in the folder
• cn=EntMgrX, enterpriseName=EntX, ou=Location, retailerName=Retailer, o=Users, o=umc—Contains enterprise operators
• Other operating entities (structure rule 3 is the superior structure rule)

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
• Enterprise
• Router

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
• Service Management Services
• Persistent Sessions for Value-Added Services
• Outsourced Services
• Service Schedules

Types of Services

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

• Access services—Provide subscriber access to the Internet or a specified provider’s Web site.
• Value-added services—Supplement a basic service offering provided to subscribers. The supplemental services typically carry a fee.
• RADIUS services—Provide RADIUS authentication and authorization for subscribers.

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:

• Policy folders—Organize policy groups.
• Policy groups—Hold policy lists. You associate policy groups with a service or with an interface. The SAE sends the information in a policy group to the router, and the router uses the information to create policies that it attaches to router interfaces.

Structure rule 23 (policyGroupNameForm) allows policy groups to be created in the Policies subtree (o=Policies, o=umc).

• Policy lists—Organize policy rules. You can create policy lists for JUNOS routing platforms or for JUNOSe routers. JUNOSe routers and JUNOS routing platforms support different policy rules in a policy list.

Structure rule 27 (policyListNameForm) allows policy lists to be created subordinate to policy groups.

• Policy rules—Organize the conditions and actions that comprise the policy rule. Policy rules consist of conditions that you use to match traffic and actions that specify the action to take. In JUNOS terminology, a policy rule is the same as a term.

Structure rule 28 (policyRuleNameForm) allows policy rules to be created subordinate to the policy lists.

• Conditions—Define match conditions or classifiers that a packet or packet flow must contain; for example, packet direction, network protocol, application protocol, source and destination networks, packet length, forwarding class, and source and destination class.

Structure rule 50 (policyRuleConditionAssocNameForm) allows policy conditions associated with a rule to be created subordinate to the rule.

• Actions—Define the action that a router or CMTS device takes on packets that match the specified conditions.

Structure rule 49 (policyRuleActionAssocNameForm) allows policy actions associated with a rule to be created subordinate to the rule.

• Drop profiles—Specify conditions under which packets can be dropped. Structure rule 51 (dropProfileNameForm) allows dropProfile objects to be created subordinate to schedulers.

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:

• Structure rule 34 (umcTrapNameForm)—Allows SNMP trap objects to be created subordinate to second-level folders.
• Structure rule 37 (umcTransactionLockNameForm)—Allows lock objects (umcTransactionLock) to be created in the Locks subtree (o=Locks, o=umc).
• Structure rule 39 (umcUrlNameForm)—Allows umcUrl objects with umcHost as the naming attribute to be created subordinate to an organizational unit.
• Structure rule 55 (applicationManagerGroupNameForm)—Allows applicationManagerGroup objects with name as the naming attribute to be created in the Network subtree (o=Network, o=umc).
• Structure rule 56 (policyDecisionPointNameForm) allows policy decision points to be created in the Network subtree (o=Network, o=umc). Policy decision points specify that the policy engine make decisions about the deployment of policies on the router or the CMTS device.