12.2. Interdomain Control Requirements
There are several reasons why a large network may be partitioned into domains. In each application, there are specific requirements on signaling and routing across interdomain interfaces. In this section, we explore these issues.
12.2.1. Scalability
As networks grow, the scalability of the control plane becomes an issue. Specifically, the complexity of transmission, storage, and processing of routing information increases with the size of the network. It therefore becomes necessary to partition a carrier's network into multiple domains between which the flow of routing information is limited in some fashion. This reduces the amount of information exchanged across the network, and reduces the convergence time of routing protocols within a domain. Thus, for scalability, the internal topology and resource information of a domain is abstracted when sent outside, while the overall interdomain topology and resource information is made available to allow diverse path computation. Note that the general domain capabilities as well as reachability of destinations across domains need to be shared as completely as possible.
Current IP routing protocols provide for scalability by allowing topological partitioning (see Chapter 5). An example is OSPF's multiple area capability (see Chapter 9). Consider Figure 9-5 again, which depicts the use of OSPF areas for routing scalability. The figure shows three OSPF areas. The backbone area (area 0) has special properties, and all the other areas must be attached to it. Note that the traffic between these OSPF areas must traverse the backbone area. Also note that an Area Border Router (ABR) must be a member of two areas, that is, its own area and the backbone area. Only reachability information, and not topology information, is exchanged between areas (including the backbone area). This results in a significant reduction in information transferred between areas and hence promotes scalability. The lack of topology information exchange across areas, however, means that sufficient information is not available to perform diverse route calculations.
12.2.2. Intervendor Interoperability
An important application of the optical control plane is the promotion of interoperability between vendors. From a carrier's perspective, the use of domains can provide a clean way to isolate “clouds” of equipment belonging to different vendors, with a well-defined interface between the domains for interoperability. This is shown in Figure 12-2. In this case, two specific requirements arise:
The protocols used between the domains for signaling and routing must be independent of any protocols used within the domains, and
The internal operation of a domain must be hidden from entities in other domains.
Figure 12-2. Intracarrier Intervendor Routing Domains
These requirements arise because vendors typically develop routing and management methods independently, often using proprietary mechanisms. Creating vendor-specific domains allows the accommodation of these differences, while allowing standardized communication across interdomain interfaces. For example, the routing entity in each domain shown in Figure 12-2 could obtain the internal topology and resource information by participating in a routing protocol like OSPF, by querying the domain's management system, or by simply having the required information manually configured into it.
With reference to Figure 12-2, the following scenarios are possible:
A proprietary distributed routing protocol is implemented in each domain.
As is the case with a number of existing installations, a management-system-based (centralized) topology/resource discovery and routing schemes are implemented in both domains.
Centralized routing is implemented in one domain while distributed routing is used in the other.
The two requirements listed earlier capture interoperability needs in all these three cases.
A similar interoperability scenario comes up in the IP world when considering routing between different Internet service providers (ISPs). An ISP typically uses either the IS-IS or the OSPF protocol for routing within its own network. Although similar in function (both are link state routing protocols), these protocols do not interoperate. When ISPs establish peering agreements, that is, agree to carry traffic from each other, they use another protocol, BGP, which is neutral to the internal routing protocol running in each ISP's domain. This situation is illustrated in Figure 12-3.
Figure 12-3. BGP Example
12.2.3. Administrative Partitioning
A slightly different but interesting application of the domain concept occurs when a carrier has multiple administrative domains under the purview of independent business units (BUs). This is illustrated in Figure 12-4.
Figure 12-4. Administrative Partitioning
Different BUs may represent independently administered cost centers. Being autonomous entities, BUs may allow only limited information sharing between networks run by each other. For instance, topology may be exchanged without detailed resource usage information. This scenario illustrates another form of limited information sharing; namely, complete sharing of topology while restricting the disclosure of resource availability information.
12.2.4. Deployment and Operations Considerations
The domain concept allows heterogeneous control methods to coexist in a large network, while permitting interoperability via a standard interdomain interface. An alternative to this approach is to have a single standardized protocol (e.g., OSPF), with its own scaling mechanism (e.g., OSPF areas), running in all the nodes. The problem with such an idea becomes apparent, when we consider it in the context of a large optical network. In essence, the same protocol needs to be implemented in different types of nodes (perhaps from different vendors) in a truly interoperable manner. This may not be feasible if some nodes are simply not designed to operate under a distributed control plane. With others, this may require a major software upgrade. In short, this is not a practical proposition. On the other hand, with the domain approach new protocols run between domains and not between each node in a domain. This allows the existing functionality of nodes within a domain to be maintained and does not require a carrier to “revamp” all the nodes within the domain.
From an operations perspective, it is desirable to limit the interactions between nodes across domain boundaries. In particular, signaling and routing generate a variety of information flows. Too much information flowing can cause problems, as in “signaling storms” encountered in telephone networks or “route flapping” in IP networks. One approach to monitoring, suppressing, and possibly preventing such disruptive phenomena is to let entities representing an entire domain rather than individual nodes exchange information, as shown in Figure 12-2.
A domain's routing entity (Figure 12-2) could apply flooding and summarization mechanisms as if it is a switching system. The functions of the routing entity could include (a) exchanging reachability information (i.e., which NEs can be directly reached from this domain), (b) verification of domain connectivity (i.e., understanding how a domain is directly connected to other domains), (c) exchanging summarized domain topology information, and (d) exchanging topology information concerning other domains.