Multi-Topology (MT) Routing in OSPF
Extracted elements (25)
MT routing reuses the deprecated TOS metric fields from [TOS-OSPF] rather than introducing new fields, since those fields were never deployed and are available for repurposing. The TOS field is redefined as MT-ID in Router, Summary, and AS-external LSAs.
The MT-bit in OSPF options is used specifically to gate adjacency formation when DefaultExclusionCapability is enabled, ensuring that no router can exclude a link from the default topology until all neighbors in the area support the feature — preventing black holes from non-MT routers silently accepting zero metrics.
Unlike TOS-based routing where unreachable destinations fall back to TOS 0, MT routing makes fallback optional. Also, links/prefixes not advertised for a specific topology simply do not exist in that topology, rather than defaulting to TOS 0 metric.
An MT router with DefaultExclusionCapability disabled will form adjacencies with non-MT routers and include all links as part of the default topology, enabling gradual migration from non-MT to MT networks.
Non-MT routers interpret a zero TOS 0 metric field as a valid metric and will consider links as part of the default topology even if the MT router intends them otherwise. To safely exclude links from the default topology, all routers in the area must be in DefaultExclusionCapability mode.
When an area's DefaultExclusionCapability changes, Hello suppression for demand circuit neighbors must be disabled for RouterDeadInterval seconds with the DC-bit cleared, after which either the adjacency is taken down due to MT-bit conflicts or Hello suppression is renegotiated.
All routers within an area MUST agree on how the metric for the default topology will be advertised. When DefaultExclusionCapability is enabled, routers ignore TOS 0 metrics in Router-LSAs and instead use the MT-ID#0 metric for the default topology.
For inter-area routing in MT topologies to work across areas, the backbone area also needs to be configured for the same topology. Inter-area routing for an MT-area still depends on the backbone area.
For OSPF control packets sent to the remote end of a virtual link, the transit area path MUST be composed of links participating in the default topology and the OSPF control packets MUST be forwarded using the default topology.
If the prefix or router does not exist in the default topology in Summary-LSAs or AS-external-LSAs, the TOS 0 metric MUST be set to infinity (0xFFFFFF). The TOS 0 metric is always used for Summary-LSAs and Type-5/7 LSAs independent of DefaultExclusionCapability.
MT-ID metrics in LSAs SHOULD be in ascending order of MT-ID. If an MT-ID exists in an LSA or router link multiple times, the metric in the first MT-ID instance MUST be used.
MT-ID values 128-255 are invalid and SHOULD be ignored. Only MT-IDs in the 0 to 127 range are valid because AS-External-LSAs use the high-order bit in the MT-ID field (E-bit) for the external metric-type.
When a certain link or prefix that existed in a topology is no longer part of that topology, a new version of the LSA MUST be originated excluding metric information representing the link or prefix in that topology.
When DefaultExclusionCapability is disabled, the MT-bit MUST be cleared in Hello packets and SHOULD be cleared in Database Description packets, and all links participating in non-default topologies are automatically included in the default topology.
When DefaultExclusionCapability is enabled, the MT-bit MUST be set in Hello packets and the router will only accept a Hello packet if the MT-bit is set, ensuring all routers in the area have this capability before default topology exclusion is used.
A separate SPF is computed for each MT-ID to find independent paths to IP prefixes. Network-LSAs are used by all topologies during SPF, but during SPF for a given MT-ID only the links and metrics for that MT-ID are considered.
Network-LSAs do not contain any MT information since the Designated Router is shared by all topologies and the distance from network to attached routers is zero. There is no change to the Network-LSA format.
The DefaultExclusionCapability is a new configurable parameter in the Area Data Structure. When enabled, all routers in the area must have this capability before a link can be excluded from the default topology. It is disabled by default when an area data structure is created.
The MT-ID field replaces the TOS field in Router-LSAs, Summary-LSAs, and Type-5 and Type-7 AS-external-LSAs. Each MT topology has its own MT-ID metric field; when a link is not part of a given MT, the corresponding MT-ID metric is excluded from the LSA.
The unused T-bit in the OSPF Options field is redefined as the MT-bit. When DefaultExclusionCapability is enabled, the MT-bit MUST be set in Hello packets and SHOULD be set in Database Description packets.
IANA created a new registry 'OSPF Multi-Topology ID Values'. Reserved values: 0 (default topology metric), 1 (default multicast topology), 2 (IPv4 in-band management), 3-31 (IANA assignments), 32-127 (experimental/proprietary per RFC3692), 128-255 (invalid, SHOULD be ignored). Only MT-IDs 0-127 are valid since AS-External-LSAs use the high-order bit (E-bit) for external metric-type.
This document does not raise any security issues beyond those already covered in OSPF (RFC 2328). No new security mechanisms are introduced.
AS-external-LSA (Type 5) format adds per-MT-ID entries after the base metric block, each consisting of E-bit and MT-ID (8 bits combined), MT-ID metric (24 bits), Forwarding address (32 bits), and External Route Tag (32 bits).
Router-LSA (Type 1) format adds a '# MT-ID' field (8 bits) after the link Type field, followed by per-MT-ID entries each consisting of MT-ID (8 bits), a zero byte, and MT-ID metric (16 bits). The base metric field remains unchanged.
Summary-LSA (Type 3/4) format adds MT-ID metric entries after the base metric: each entry contains MT-ID (8 bits) and MT-ID metric (24 bits), allowing per-topology prefix reachability advertisement.