Section 10.1. Extending OSPF
10.1. Extending OSPFNew capabilities are added to OSPF primarily through the addition of new LSAs. You have already encountered in Chapter 7 one example of an LSA that supports an optional capability: The NSSA (type 7) LSA. This chapter and the next three introduce other "extension" LSAs. 10.1.1. The OSPF Extensibility ProblemTwo characteristics of OSPF pose problems to extensibility. The first characteristic is that when an OSPF router receives an LSA of an unknown type, it drops the LSA. The influence of this behavior is seen in NSSAs, where all routers in the area must support the NSSA option and understand type 7 LSAs. In this case, the behavior is not a problem because you want all routers in the not-so-stubby area to enforce the rule that no type 5 LSAs are permitted. But there are some cases in which you want only a subset of routers, unrelated to an area or domain, to support an optional capability. For example, you might want only some of your routers to support traffic engineering or IP multicast. In such a case, you must avoid a situation in which some router in your network that does not need to support the option might nonetheless hinder the flooding of the optional LSAs. You can avoid the situation in one of two ways: Either ensure that all routers support the optional capability, regardless of whether you want them to participate in the option; or carefully design your network so that the optional LSAs never need to be flooded through nonsupportive routers. The second characteristic of OSPF that might hinder extensibility is the inclusion of IPv4 addressing semantics in the LSAs. Take, for example, the most essential LSA: the Router (type 1) LSA, which supplies most of the topological information to the SPF calculation. The format of the LSA, discussed in Chapter 5, is shown again in Figure 10.1. The Link ID and Link Data fields are both 32 bits, and usually contain a 32-bit IP address. If the OSPF network type of the link is broadcast, for instance, the Link ID field contains the IPv4 address of the DR and the Link Data field contains the IPv4 address of the originating router's interface to the link. Similar IPv4-based data is included for other network types. Figure 10.1. The information in the 32-bit Link ID and Link Data fields is, in most cases, based on some IPv4 network address. However, suppose you want OSPF to support other kinds of addresses. Specifically, what if you want to use OSPF to route IPv6, which uses 128-bit addresses? If every IPv6 network was dual stackedthat is, every router interface was assigned an IPv4 address in addition to an IPv6 addressOSPF could support IPv6 through the simple addition of new LSAs to carry the IPv6 addresses. The SPF process would continue to get its information from the type 1 LSAs, which in turn get their link information from the IPv4 addresses. But that defeats one of the objectives of IPv6, which is to overcome some of the limitations of IPv4. OSPF must be capable of routing an IPv6-only network. So the realistic solution to the problem, as discussed in Chapter 12, is a completely new version of OSPF for IPv6 in which the IPv4 address semantics are removed from the LSAs. 10.1.2. Opaque LSAsOne of the difficulties in extending OSPF is that future capabilities cannot always be anticipated. MPLS-based traffic engineering, for example, had not been conceived when OSPF was standardized. It is reasonable to expect that before OSPF reaches the end of its life it will be called upon to support still more as yet unthought-of services. Opaque LSAs[1] are intended to add flexibility to OSPF, by creating generalized LSAs that can disseminate undefined data from router to router. The data might be used by OSPF for some future capability, or it might be information inserted by some application that utilizes OSPF as a convenient transport but that is not relevant to OSPF route calculations. In this second regard Opaque LSAs serve the same purpose as the route tag fields described in Section 10.3, but with more flexibility.
"Opaque" means something you cannot see through, and this does fit one of the applications of this class of LSAs: to carry information that OSPF does not itself understand or care about. The word also means "obscure" or "difficult to define," which fits the other mission of Opaque LSAs: to support future features that we cannot presently anticipate. There are three types of Opaque LSA, differing only in their flooding scope (Figure 10.2): link-local, area, and AS. Defining these scopes provides even more flexibility in matching service requirements. Figure 10.2. The Opaque LSA. Type is the LSA type, and defines the flooding scope of the LSA:
The LSA's 32-bit Link State ID is composed of two parts:
Opaque Information is the variable-length field that carries the capability- or application-specific data. Support of Opaque LSAs is signaled between neighbors during the database exchange process by setting the O bit in the Options field (Figure 10.3) of the Database Description packets. The capability (or lack of it) is recorded in the Neighbor Options portion of the neighbor data structure. A router that supports Opaque LSAs does not flood them to neighbors that do not support the optionthat is, Opaque LSAs are not put onto the Link State Transmission list of neighbors that do not indicate support for the option. Figure 10.3. Support for Opaque LSAs is signaled between neighbors by setting the O bit in the Options field of Database Description packets. The neighbor table in Figure 10.4 shows the value of the Options field to be 0x42, or binary 01000010, indicating that the O bit is set. Figures 10.5 and 10.6 show a summary of the databases of the neighbor and the router from which the neighbor table was taken, and you can clearly observe the presence of 10 area-local Opaque LSAs.
10.1.3. The Router Information Opaque LSAAs the Options field in Figure 10.3 clearly shows, only the leftmost bit remains available for signaling future capabilities. In reality, the first and fifth bits could be redefined, as the ToS and External Attributes capabilities have never come into general acceptance. Nevertheless, the 8-bit Options field represents a limitation on future extensibility. A proposal has been made, although not yet implemented as of this writing, for a new Opaque LSA called the Router Information (RI) Opaque LSA[2] to advertise optional capabilities. The advantage of this new LSA is that no new bits in the Options field are used (just the O bit to signal support for Opaque LSAs) while providing a way to signal support for up to 32 different capabilities.
Figure 10.7 shows the format of the RI Opaque LSA. The opaque type is 4, and the LSA can have link-local, area-local, or AS scope. The LSA contains one or more TLVs that specify optional capabilities. Figure 10.7. The Router Information (RI) Opaque LSA. The first TLV carried in the RI LSA is the OSPF Router Capabilities TLV, shown in Figure 10.8. This TLV can be followed, depending on the options supported, by other TLVs carrying additional capability information. Figure 10.8. The OSPF Router Capabilities TLV. The type number of the Router Capabilities TLV is 1. The Capabilities field is a 32-bit field that functions similarly to the Options field: It comprises 32 flags indicating, when set, different optional capabilities. Table 10.2 shows what bits represent what options. Although it is reasonable to assume that OSPF will never have more than 32 different optional capabilities, the TLV format can be easily extended to support a larger capabilities field.
|
extensive Address Interface State ID 
EAN: 2147483647
Pages: 111