Distributed Installation on Solaris Platforms
Figure 18 shows a more complicated setup that distributes the SRC components among several machines in several locations, while still providing reliability and scalability.
In the back office, there are:
- A master directory server running on dedicated hardware
- SDX Admin and Policy Editor running on as many other machines as desired
- A pair of network information collector (NIC) hosts running NIC resolvers
- A Web application server with a portal (a residential portal, an enterprise portal, or an Advanced Services Gateway application)
- Non-SRC components of the service provider's OSS, which are integrated with the SRC components through the master directory as LDAP clients
In the POPs there are primary and backup hosts that contain identical SAE, RADIUS, directory servers, and NIC hosts. The NIC hosts contain a resolver, directory agent, and SAE agent, and they communicate with the NIC hosts in the back office using Common Object Request Broker Architecture (CORBA). SAE, RADIUS, and directory server components within the hosts communicate through LDAP.
Clients of the NIC host need to determine which remote SAE is managing the subscriber sessions that they need to operate on. The NIC system collects and stores this information. At startup, the SAE stores its CORBA object reference in the directory. The NIC system collects this SAE reference, along with the keys to subscriber sessions (IP addresses and LDAP DNs of the subscriber profiles in the directory) managed by the SAE. Web applications can locate the SAE for a particular subscriber by querying the NIC system.
![]()
Master Directory and Directory Shadows
The master directory contains all the directory data and handles all update requests, either locally through LDAP or remotely through the Directory Service Protocol (DSP) for X.500 directories, such as DirX, or through equivalent protocols for other directory types.
The information in the master directory is copied to shadow directories in the service provider's point of presence (POP). The system uses Directory Information Shadowing Protocol (DISP) for data transfer for X.500 directories, such as DirX, and equivalent protocols for other directory transfers. This type of distribution puts the directory information for SAEs and RADIUS servers physically close to the servers. A highly reliable LAN connects the hosts and provides good performance.
It is not necessary to include all information in the directory shadows. For instance, only information relevant to a particular POP, such as the information for the subscribers who can actually connect there, may be included. Also, updates generated from an SAE in a particular POP, such as cached logins, may be mastered locally and not propagated to the directory master in the back office. Finally, attributes not relevant to SAE and RADIUS operation—for instance, the subscriber's address—may be filtered from replication to the directory shadows in the POPs.
Scalability
This setup can be scaled incrementally by replicating the pattern found in the POP as the subscriber base grows.
Reliability
To avoid a single point of failure in the POPs, the RADIUS, SAE, directory servers, and NIC hosts are installed on identical primary and backup hardware. If the primary host fails, the router switches over to the backup host. Also, the SAE and RADIUS servers (as LDAP clients) and NIC hosts can be configured to switch over to the directory server in the backup host in the POP or to the master directory in the back office. You can configure one or more backup servers for a number of primary servers; such redundancy distributes the load of the routers across several hosts and reduces failover time by limiting the number of subscribers handled by any one host.
This setup avoids service outages in the case of any single network, server, or software failure. Existing subscribers are even unaffected by long periods of disconnection between their POP and the back office. The directory server protocols ensure that all information is properly distributed regardless of the pattern of intermittent connectivity between the sites. Since relatively static directory information is cached locally in the directory shadow in the POP, very high transaction rates for SAE and the RADIUS server are achieved.
Simplified Management and Security
Additional benefits of this setup at the POP are simplified management because of the use of identical hardware and software, and an added level of security because the SAE, RADIUS, the directory, and NIC hosts are all on the same machine.
Regionalized Installation
Figure 19 extends the scheme shown in the last section with an additional layer of directory replication for very large service providers who partition their organization into regions with regional data centers.
A single back office still houses the master directory, some centralized management servers and clients, and a pair of NIC hosts. There are also still primary and backup hosts at the POP, with SAE and RADIUS servers and NIC hosts with a resolver, a directory agent, and an SAE agent.
In this case, there is also a middle layer of regional data centers that house the first level of replication from the master directory in the back office. The regional data centers may also contain a complete set of SRC components and other OSS management components integrated with the local directory. If the local directory fails, these regional components can switch over to the master directory in the back office and switch back once the local failure is corrected. Also, directory administrative controls can be defined to limit the access of regional management operators to an appropriate scope according to the service provider's policies.
![]()