MultiPop Scenario

The MultiPop scenario illustrates a configuration that involves two POPs: Montreal and Ottawa. This configuration does not provide redundancy. The NIC proxy communicates with the back office host (BackOffice), which in turn communicates with the POP hosts (MontrealHost and OttawaHost). Hosts MontrealHost and OttawaHost support equivalent hosts and agents and manage resolutions in the same way.

When host BackOffice receives a data key from the NIC proxy, the following sequence of events occurs:

  1. Host BackOffice forwards requests as follows:
    • If the request is for the Montreal POP, host BackOffice forwards the request to POP host MontrealHost.
    • If the request is for the Ottawa POP, host BackOffice forwards the request to POP host OttawaHost.
  2. Delegating tasks to other resolvers as necessary, the resolvers in the POP obtain data values that correspond to the data key request, and return them.
  3. The POP host returns the data values to host BackOffice, which returns the value to the NIC proxy.

The scenario shows three realms for this configuration:

Each realm provides a different type of resolution. The following sections provide information about these realms.

Figure 50 illustrates this configuration.

Figure 50: MultiPop Configuration

MultiPop Configuration

IP Realm

This realm accommodates the situation in which IP address pools are configured locally on each VR. The resolution process takes a subscriber’s IP address as the key and returns a reference to the SAE managing this subscriber as the value. This realm uses essentially the same resolution process as the ip realm for the OnePop scenario (see OnePop Scenario). However, some of the constraints differ.

The following agents interact with the resolvers in this realm:

When the NIC proxy sends a subscriber’s IP address to host BackOffice, the following sequence of events occurs:

  1. Host BackOffice passes the IP address to resolver ip/A1.
  2. Resolver ip/A1 obtains an IP pool for the IP address.
  3. Resolver ip/A1, based on the value of the IpPool, forwards the request to ip/B1montreal or ip/B1ottawa.
  4. Resolver ip/B1montreal or resolver ip/B1ottawa obtains a VR name for this IP pool and returns the VR name to resolver ip/A1.
  5. Resolver ip/A1 forwards the VR name to resolver ip/C1.
  6. Resolver ip/C1 obtains the SAE identity for this VR and returns the value to resolver ip/A1.
  7. Resolver ip/A1 returns the SAE reference to its host.
  8. Host BackOffice returns the SAE reference to the NIC proxy.

Figure 51 illustrates the interactions of the NIC components for this realm.

Figure 51: IP Realm for MultiPop Configuration

IP Realm for MultiPop Configuration

Shared IP Realm

This realm accommodates the situation in which IP address pools are shared by VRs in the same POP. The realm takes a subscriber’s IP address as the key and returns the corresponding SAE as the value. To see the resolution graph for this realm, see OnePop Scenario.

The following agents interact with resolvers in this realm:

When the NIC proxy sends a subscriber’s IP address to host BackOffice, the following sequence of events occurs:

  1. Host BackOffice passes the IP address to resolver sharedIp/A1.
  2. Resolver sharedIp/A1 obtains an IP pool for the IP address.
  3. Resolver sharedIp/A1, based on the value of the IP pool, forwards the request to sharedIp/B1montreal or sharedIp/B1ottawa.
  4. Resolver sharedIp/B1montreal or resolver sharedIp/B1ottawa obtains a VR name for this IP address and returns the VR name to resolver sharedIp/A1.
  5. Resolver sharedIp/A1 forwards the VR name to resolver sharedIp/C1.
  6. Resolver sharedIp/C1 obtains the SAE identity for this VR and returns the value to resolver sharedIp/A1.
  7. Resolver sharedIp/A1 passes the SAE reference to its host.
  8. Host BackOffice returns the SAE reference to the NIC proxy.

Figure 52 illustrates the interactions of the NIC components for this realm.

Figure 52: sharedIP Realm for MultiPop Configuration

sharedIP Realm for MultiPop Configuration

DN Realm

The DN realm takes the DN of an access subscriber (an access DN) as the key and returns the corresponding SAE as the value. Figure 53 shows the resolution process for this realm.

Figure 53 shows the resolution graph for this realm.

Figure 53: Resolution Graph for MultiPop dn Realm

Resolution Graph for MultiPop dn Realm

The following agents interact with resolvers in this realm:

When the NIC proxy sends an access DN to host BackOffice, the following sequence of events occurs:

  1. Host BackOffice passes the access DN to resolver dn/A1.
  2. Resolver dn/A1 obtains an enterprise DN for the access DN.
  3. Resolver dn/A1, based on the value of the enterprise DN, forwards the request to dn/B1montreal or dn/B1ottawa.
  4. Resolver dn/B1montreal or resolver dn/B1ottawa obtains a VR name for this enterprise DN and returns the VR name to resolver dn/A1.
  5. Resolver dn/A1 forwards the VR name to resolver dn/C1.
  6. Resolver dn/C1 obtains the SAE reference for this VR and returns the value to resolver dn/A1.
  7. Resolver dn/A1 passes the SAE reference to its host.
  8. Host BackOffice returns the SAE reference to the NIC proxy.

Figure 54 illustrates the interactions of the NIC components for this realm.

Figure 54: dn Realm for MultiPop Configuration

dn Realm for MultiPop Configuration

Related Documentation