OSPFv3: One New LSA Might Make a Big Difference

When OSPFv3 was developed to support IPv6, the opportunity presented itself to apply lessons learned from the older OSPFv2. One of the resulting changes to OSPFv3 can improve its scalability in some situations. Specifically, IP addressing semantics have been removed from OSPFv3 Router (Type 1) and Network (Type 2) LSAs.

Type 1 LSAs are the most fundamental of the OSPF LSAs: They facilitate the core link state functions of information flooding and link state database construction. When a router detects a neighbor state change it floods a new Type 1 LSA to the other routers in the area, triggering a new SPF calculation in the routers to account for the topology change.

(Type 2 LSAs are a sort of specialized Type 1, representing broadcast networks as logical nodes on the shortest path tree. However, the scaling problem I’m getting to does not usually apply to Type 2 LSAs, so I’ll focus the remainder of the discussion just on Type 1s.)

The problem with OSPFv2 is that it gives Type 1 (and 2) LSAs a second job: They advertise the originating router’s attached IPv4 prefixes. So when a prefix is added to the router or an existing prefix is deleted or its metric is changed, the router floods a new Type 1 LSA to advertise the prefix change.

But because of the Type 1’s first and most important responsibility, when the router floods a new Type 1 LSA to advertise a simple prefix change the LSA triggers an SPF calculation in all the other routers in the area.

Such an SPF run is unnecessary: The topology has not changed, and the other routers only need to update their databases to indicate the added, deleted, or changed prefix attached to the originator.

This is usually not a problem; within most OSPF areas prefixes are not added or removed frequently enough for the resulting SPF runs to have a noticeable impact.

But in large single-area topologies with lots of access devices – such as service provider PEs or remote access servers – the level of prefix activity could indeed cause unacceptable Type 1 LSA floods and SPF activity.

There are several design solutions to control this problem by “hiding” the prefix fluctuations from the wider OSPF domain or by just not allowing the prefixes into OSPF at all. However, while you can design around this kind of scaling problem it would be better if the protocol did not present the problem in the first place.

That’s where OSPFv3 comes in. This version of OSPF removes the address semantics from the Types 1 and 2 LSAs, leaving the LSAs to fulfill only their fundamental mission of providing the topology elements for calculating shortest path trees. OSPFv3 uses a new Intra-Area-Prefix (Type 0x2009) LSA to advertise connected prefixes; when an OSPFv3 router receives one of these LSAs, it simply updates its databases to reflect the advertised prefix change relevant to the LSA’s originator – a Partial Route Calculation (PRC) – rather than triggering a full SPF run. OSPFv2 can perform PRCs only from Types 3, 4, 5, and 7 LSAs, whose sole purpose is to advertise prefixes.

Unfortunately, OSPFv3 implementations currently support only IPv6 and are not backwards compatible with OSPFv2. There is an Internet-draft to add support for address families, which would add IPv4 support, but so far the draft has not been implemented by the major router vendors.

I do hope that it is at least on their roadmaps, because even after rollout it will take a while for networks to migrate to OSPFv3 throughout their networks and kill off OSPFv2. But when that happens, network operators will find themselves with a nicer, more modern IGP.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)