diff options
Diffstat (limited to 'doc/rfc/rfc4915.txt')
| -rw-r--r-- | doc/rfc/rfc4915.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4915.txt b/doc/rfc/rfc4915.txt new file mode 100644 index 0000000..760a16a --- /dev/null +++ b/doc/rfc/rfc4915.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group P. Psenak +Request for Comments: 4915 Cisco Systems +Category: Standards Track S. Mirtorabi + Force10 Networks + A. Roy + L. Nguyen + P. Pillay-Esnault + Cisco Systems + June 2007 + + + Multi-Topology (MT) Routing in OSPF + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document describes an extension to Open Shortest Path First + (OSPF) in order to define independent IP topologies called Multi- + Topologies (MTs). The Multi-Topologies extension can be used for + computing different paths for unicast traffic, multicast traffic, + different classes of service based on flexible criteria, or an in- + band network management topology. + + An optional extension to exclude selected links from the default + topology is also described. + + + + + + + + + + + + + + + +Psenak, et al. Standards Track [Page 1] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Differences between Multi-Topology and TOS-Based + Routing . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 + 2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Base MT Functional Specifications . . . . . . . . . . . . . . 4 + 3.1. MT Area Boundary . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Adjacency for MTs . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Sending OSPF Control Packets . . . . . . . . . . . . . . . 5 + 3.4. Advertising MT Adjacencies and the Corresponding IP + Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4.1. Inter-Area and External Routing . . . . . . . . . . . 5 + 3.5. Flushing MT Information . . . . . . . . . . . . . . . . . 6 + 3.6. MT SPF Computation . . . . . . . . . . . . . . . . . . . . 6 + 3.7. MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.8. Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 6 + 4. Default Topology Link Exclusion Functional Specifications . . 7 + 4.1. Exclusion of Links in the Default Topology . . . . . . . . 7 + 4.2. New Area Data Structure Parameter . . . . . . . . . . . . 7 + 4.3. Adjacency Formation with Link Exclusion Capability . . . . 8 + 4.4. OSPF Control Packets Transmission over Excluded Links . . 9 + 4.5. OSPF LSA Advertisement and SPF Computation for + Excluded Links . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Interoperability between MT-Capable and Non-MT-Capable + Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Demand Circuit Compatibility Considerations . . . . . . . 10 + 6. Migration from Non-MT-Area to MT-Area . . . . . . . . . . . . 10 + 7. MT Network Management Considerations . . . . . . . . . . . . . 11 + 7.1. Create Dedicated Management Topology to Include All + the Nodes . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.2. Extend the Default Topology to All the Nodes . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 + Appendix B. OSPF Data Formats . . . . . . . . . . . . . . . . . . 13 + B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 13 + B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 15 + B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 16 + B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 17 + B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 18 + + + + + +Psenak, et al. Standards Track [Page 2] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +1. Introduction + + OSPF uses a fixed packet format, therefore it is not easy to + introduce any backward-compatible extensions. However, the OSPF + specification [OSPF] introduced Type of Service (TOS) metric in an + earlier specification [TOS-OSPF] in order to announce a different + link cost based on TOS. TOS-based routing as described in [TOS-OSPF] + was never deployed and was subsequently deprecated. [M-ISIS] + describes a similar mechanism for ISIS. + + We propose to reuse the TOS-based metric fields. They have been + redefined and are used to advertise different topologies by + advertising separate metrics for each of them. + +1.1. Differences between Multi-Topology and TOS-Based Routing + + Multi-Topology routing differs from [TOS-OSPF] TOS-based routing in + the following ways: + + 1. With TOS routing [TOS-OSPF], the TOS or Diffserv Code Point + (DSCP) in the IP header is mapped directly to the corresponding + OSPF SPF calculation and routing table. This limits the number + and definition of the topologies to the 16 TOS values specified + in Section 12.3 of [TOS-OSPF]. With Multi-Topology routing, the + classification of what type of traffic maps to which topology is + not within the scope of this document. + + 2. With TOS routing [TOS-OSPF], traffic that is unreachable in the + routing table associated with the corresponding TOS will revert + to the TOS 0 routing table. With Multi-Topology routing, this is + optional. + + 3. With TOS routing [TOS-OSPF], individual links or prefixes could + not be excluded from a topology. If the Link State Advertisement + (LSA) options T-bit was set, all links or prefixes were either + advertised explicitly or defaulted to the TOS 0 metric. With + Multi-Topology routing, links or prefixes that are not advertised + for a specific topology do not exist in that topology. + +2. Terminology + +2.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 + [RFC-KEYWORDS]. + + + + +Psenak, et al. Standards Track [Page 3] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +2.2. Terms + + We use the following terminology in this document: + + Non-MT router + Routers that do not have the MT capability. + + MT router + Routers that have MT capability as described in this document. + + MT-ID + Renamed TOS field in LSAs to represent Multi-Topology ID. + + Default topology + Topology that is built using the TOS 0 metric (default metric). + + MT topology + Topology that is built using the corresponding MT-ID metric. + + MT + Shorthand notation for MT topology. + + MT#0 topology + Representation of TOS 0 metric in MT-ID format. + + Non-MT-Area + An area that contains only non-MT routers. + + MT-Area + An area that contains both non-MT routers and MT routers, or only + MT routers. + +3. Base MT Functional Specifications + +3.1. MT Area Boundary + + Each OSPF interface belongs to a single area, and all MTs sharing + that link need to belong to the same area. Therefore, the area + boundaries for all MTs are the same, but each MT's attachment to the + area is independent. + +3.2. Adjacency for MTs + + Each interface can be configured to belong to a set of topologies. A + single adjacency is formed with neighbors on the interface even if + the interface is configured to participate in multiple topologies. + Furthermore, adjacency formation is independent of the topologies + configured on the local interface and the neighboring router. + + + +Psenak, et al. Standards Track [Page 4] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +3.3. Sending OSPF Control Packets + + Sending OSPF control packets is unchanged from [OSPF]. 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. + +3.4. Advertising MT Adjacencies and the Corresponding IP Prefixes + + The TOS metric field is reused to advertise topology specific metric + for links and prefixes belonging to that topology. The TOS field is + redefined as MT-ID in the payload of Router, Summary, and Type-5 and + Type-7 AS-external-LSAs (see Appendix B). + + 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. + + When a router establishes a FULL adjacency over a link that belongs + to a set of MTs, it advertises the corresponding cost for each MT-ID. + + By default, all links are included in the default topology and all + advertised prefixes belonging to the default topology will use the + TOS 0 metric as in [OSPF]. + + Each MT 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 Network-LSA does not contain any MT information since the + Designated Router (DR) is shared by all MTs. Hence, there is no + change to the Network-LSA. + +3.4.1. Inter-Area and External Routing + + In Summary-LSAs and Type-5 and Type-7 AS-external-LSAs, the TOS + metric fields are redefined as MT-ID metric fields and are used to + advertise prefix and router reachability in the corresponding + topology. + + When a router originates a Summary-LSA, or Type-5 or Type-7 AS- + external-LSA that belongs to a set of MTs, it includes the + corresponding cost for each MT-ID. By default, the prefix + participates in the default topology and uses the TOS 0 metric for + the default topology, similar to standard OSPF [OSPF]. + + Setting the P-bit in Type-7 AS-external-LSA is topology independent + and pertains to all MT-ID advertised in the body of the LSA. + + + +Psenak, et al. Standards Track [Page 5] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +3.5. Flushing MT Information + + When a certain link or prefix that existed or was reachable in a + certain topology is no longer part of that topology or is unreachable + in that topology, a new version of the LSA MUST be originated + excluding metric information representing the link or prefix in that + topology. + + The MT metric in the Router-LSA can also be set to the maximum + possible metric to enable the router to become a stub in a certain + topology [STUB]. + +3.6. MT SPF Computation + + By considering MT-ID metrics in the LSAs, OSPF computes multiple + topologies and finds paths to IP prefixes for each MT independently. + A separate SPF will be computed for each MT-ID to find independent + paths to IP prefixes. + + Network-LSAs are used by all topologies during the SPF computation. + During the SPF for a given MT-ID, only the links and metrics for that + MT-ID are considered. Entries in the Router Routing table are also + MT-ID specific. + +3.7. MT-ID Values + + Since AS-External-LSAs use the high-order bit in the MT-ID field + (E-bit) for the external metric-type, only MT-IDs in the 0 to 127 + range are valid. The following MT-ID values are reserved: + + 0 - Reserved for advertising the metric associated + with the default topology (see Section 4.2) + 1 - Reserved for advertising the metric associated + with the default multicast topology + 2 - Reserved for IPv4 in-band management purposes + 3-31 - Reserved for assignments by IANA + 32-127 - Reserved for development, experimental and + proprietary features [RFC3692] + 128-255 - Invalid and SHOULD be ignored + +3.8. Forwarding in MT + + It is outside of the scope of this document to specify how the + information in various topology specific forwarding structures are + used during packet forwarding or how incoming packets are associated + with the corresponding topology. For correct operation, both + forwarding behavior and methods of associating incoming packets to a + corresponding topology must be consistently applied in the network. + + + +Psenak, et al. Standards Track [Page 6] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +4. Default Topology Link Exclusion Functional Specifications + + The Multi-Topologies imply that all the routers participate in the + default topology. However, it can be useful to exclude some links + from the default topology and reserve them for some specific classes + of traffic. + + The Multi-Topologies extension for the default topology link or + prefix exclusion is described in the following subsections. + +4.1. Exclusion of Links in the Default Topology + + OSPF does not have the notion of an unreachable link. All links can + have a maximum metric of 0xFFFF advertised in the Router-LSA. The + link exclusion capability requires routers to ignore TOS 0 metrics in + Router-LSAs in the default topology and to alternately use the MT- + ID#0 metric to advertise the metric associated with the default + topology. Hence, all routers within an area MUST agree on how the + metric for the default topology will be advertised. + + The unused T-bit is defined as the MT-bit in the option field in + order to ensure that a Multi-Topology link-excluding capable router + will only form an adjacency with another similarly configured router. + + + +---+---+---+---+---+---+---+---+ + |DN |O |DC |EA |NP |MC |E |MT | + +---+---+---+---+---+---+---+---+ + + Figure 1: OSPF Option Bits + + MT-bit: If DefaultExclusionCapability is enabled, the bit MUST + be set in Hello packets and SHOULD be set in Database + Description packet (see Section 4.2). + +4.2. New Area Data Structure Parameter + + We define a new parameter in the Area Data Structure: + + DefaultExclusionCapability + This configurable parameter ensures that all routers in an area + have this capability enabled before the default topology can be + disabled on a router link in the area without causing backward- + compatibility problems. + + When an area data structure is created, the + DefaultExclusionCapability is disabled by default. + + + + +Psenak, et al. Standards Track [Page 7] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + + If DefaultExclusionCapability is disabled: + + o The MT-bit MUST be cleared in Hello packets and SHOULD be cleared + in Database Description packets. + + o If a link participates in a non-default topology, it is + automatically included in the default topology to support backward + compatibility between MT and non-MT routers. This is accomplished + using the TOS 0 metric field as in [OSPF]. + + If DefaultExclusionCapability is enabled: + + o The MT-bit MUST be set in Hello packets and SHOULD be set in + Database Description packets. + + o The router will only accept a Hello packet if the MT-bit is set + (see Section 4.3). + + When DefaultExclusionCapability is set to enabled, a router is said + to be operating in DefaultExclusionCapability mode. + +4.3. Adjacency Formation with Link Exclusion Capability + + In order to have a smooth transition from a non-MT area to an MT- + area, an MT router with DefaultExclusionCapability disabled will form + adjacencies with non-MT routers and will include all links as part of + the default topology. + + A link may cease participating in the default topology if + DefaultExclusionCapability is set to enabled. In this state, a + router will only form adjacency with routers that set the MT-bit in + their Hello packets. This will ensure that all routers have + DefaultExclusionCapability enabled before the default topology can be + disabled on a link. + + Receiving OSPF Hello packets as defined in Section 10.5 of [OSPF] is + modified as follows: + + o If the DefaultExclusionCapability in the Area Data structure is + set to enabled, Hello packets are discarded if the received packet + does not have the MT-bit set in the Header Options. + + Receiving OSPF Database Description packets as defined in Section + 10.6 of [OSPF] is unchanged. While packet options are validated in + Hello packets, the only option checking performed for Database + Description packets is ensuring that the options do not change during + the database exchange process. + + + + +Psenak, et al. Standards Track [Page 8] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +4.4. OSPF Control Packets Transmission over Excluded Links + + If DefaultExclusionCapability is enabled, the default topology can be + disabled on an interface. Disabling the default topology on an + interface does not impact the installation of connected routes for + the interface in the default topology. It only affects what a router + advertises in its Router-LSA. + + This allows OSPF control packets to be sent and received over an + interface even if the default topology is disabled on the interface. + +4.5. OSPF LSA Advertisement and SPF Computation for Excluded Links + + When DefaultExclusionCapability is enabled and the link does not + participate in the default topology, the MT-ID#0 metric is not + advertised. The link's TOS 0 metric is ignored during the default + topology SPF computation. + + When DefaultExclusionCapability is enabled and a link participates in + the default topology, MT-ID#0 metric is used to advertise the metric + associated with the default topology. The link's TOS 0 metric is + ignored during the default topology SPF computation. + + Independent of the DefaultExclusionCapability, the TOS 0 metric is + used for Summary-LSAs and Type-5 and Type-7 AS-external-LSAs. + + o If the prefix or router does not exist in the default topology, + the TOS 0 metric is set to infinity (0xFFFFFF). + + o If the prefix or router exists in the default topology, the TOS 0 + metric is used to advertise the metric in the default topology. + + During the summary and external prefix calculation for the default + topology, the TOS 0 metric is used for Summary-LSAs and Type-5 and + Type-7 AS-external-LSAs. + +5. Interoperability between MT-Capable and Non-MT-Capable Routers + + The default metric field is mandatory in all LSAs (even when the + metric value is 0). Even when a link or prefix does not exist in the + default topology, a non-MT router will consider the zero value in the + metric field as a valid metric and consider the link or prefix as + part of the default topology. + + In order to prevent the above problem, an MT-capable router will + include all links as part of the default topology. If links need to + be removed from the default topology, an MT-capable router must be + configured in DefaultExclusionCapability mode. In this mode, routers + + + +Psenak, et al. Standards Track [Page 9] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + + will ensure that all other routers in the area are in the + DefaultExclusionCapability mode before considering the MT-ID#0 metric + in the SPF calculation. Only then can the TOS 0 metric field in + Router-LSAs be safely ignored during the default topology SPF + computation. + + Note that for any prefix or router to become reachable in a certain + topology, a contiguous path inside that topology must exist between + the calculating router and the destination prefix or router. + +5.1. Demand Circuit Compatibility Considerations + + A change to an area's DefaultExclusionCapability requires additional + processing for area neighbors that are suppressing Hello packets as + specified in "Extending OSPF to Support Demand Circuits" [DEMAND]. + When the DefaultExclusionCapability for an area is changed, Hello + suppression must be disabled for these neighbors for a period of + RouterDeadInterval seconds. This implies that Hello packets are sent + with the DC-bit clear as specified in Section 3.2.1 of [DEMAND] + during this period. After RouterDeadInterval seconds, either the + adjacency will be taken down due to rejection of Hello packets with a + conflicting MT-bit or Hello suppression will be renegotiated. + +6. Migration from Non-MT-Area to MT-Area + + Introducing MT-OSPF into a network can be done gradually to allow MT + routers and non-MT routers to participate in the default topology + while MT routers participate in other topologies. + + If there is a requirement to exclude some links from the default + topology in an area, all routers in the area MUST be in + DefaultExclusionCapability mode. In this section, we describe the + migration steps to consider while transitioning from a non-MT network + to an MT network. + + Consider a network with a backbone area and a set of non-backbone + areas functioning in standard OSPF mode. We would like to migrate to + an MT network either partially or completely. + + 1. As required, part of an area is upgraded to be MT capable. The + MT routers will interact with non-MT routers in the default + topology and participate in other topologies as required. + + 2. If a new non-backbone area is created for MT routers, it may be + configured in DefaultExclusionCapability mode since there is no + interaction required with non-MT routers. In this mode, the + default topology can be excluded on links as required. + + + + +Psenak, et al. Standards Track [Page 10] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + + 3. If there are several non-backbone areas where MT is being used, + it is desirable that the backbone area first be upgraded to be MT + capable so that inter-area routing is ensured for MT destinations + in different areas. + + 4. Gradually, the whole network can be made MT capable. + + Note that inter-area routing for the MT-area still depends on the + backbone area. Therefore, if different areas configured for a given + topology need to communicate, the backbone area also needs to be + configured for this topology. + +7. MT Network Management Considerations + + When multiple OSPF topologies exist within a domain, some of the + routers can be configured to participate in a subset of the MTs in + the network. This section discusses some of the options we have to + enable operations or the network management stations to access those + routers. + +7.1. Create Dedicated Management Topology to Include All the Nodes + + This approach is to set up a dedicated management topology or 'in- + band' management topology. This 'mgmt' topology will include all the + routers need to be managed. The computed routes in the topology will + be installed into the 'mgmt' Routing Information Base (RIB). In the + condition of the 'mgmt' topology uses a set of non-overlapping + address space with the default topology, those 'mgmt' routes can also + be optionally installed into the default RIB. The advantages of + duplicate 'mgmt' routes in both RIBs include: the network management + utilities on the system do not have to be modified to use specific + RIB other than the default RIB; the 'mgmt' topology can share the + same link with the default topology if so designed. + +7.2. Extend the Default Topology to All the Nodes + + Even in the case in which default topology is not used on some of the + nodes in the IP forwarding, we may want to extend the default + topology to those nodes for the purpose of network management. + Operators SHOULD set a high cost on the links that belong to the + extended portion of the default topology. This way, the IP data + traffic will not be forwarded through those nodes during network + topology changes. + +8. Security Considerations + + This document does not raise any security issues that are not already + covered in [OSPF]. + + + +Psenak, et al. Standards Track [Page 11] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +9. IANA Considerations + + The T-bit as defined in [TOS-OSPF] for a router's TOS capability is + redefined as the MT-bit in this document. IANA has assigned the MT- + bit as defined in Section 4.1. + + Similarly, the TOS field for Router-LSAs, Summary-LSAs, and Type-5 + and Type-7 AS-external-LSAs, as defined in [OSPF], is redefined as + MT-ID in Section 3.7. + + IANA created a new registry, "OSPF Multi-Topology ID Values", with + the assignments and registration policies listed in Section 3.7 of + this document. + +10. References + +10.1. Normative References + + [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", + RFC 1793, April 1995. + + [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) + Option", RFC 3101, January 2003. + + [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. + + [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3692] Narten, T., "Assigning Experimental and Testing + Numbers Considered Useful", RFC 3692, January 2004. + + [TOS-OSPF] Moy, J., "OSPF Version 2", RFC 1583, March 1994. + +10.2. Informative References + + [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: + Multi Topology (MT) Routing in IS-IS", Work + in Progress, October 2005. + + [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. + McPherson, "OSPF Stub Router Advertisement", + RFC 3137, June 2001. + + + + + + + + +Psenak, et al. Standards Track [Page 12] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +Appendix A. Acknowledgments + + The authors would like to thank Scott Sturgess, Alvaro Retana, David + Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their + comments on the document. Special thanks to Acee Lindem for editing + and to Tom Henderson for an extensive review during the OSPF Working + Group last call. + +Appendix B. OSPF Data Formats + + LSA content defined in [OSPF] is modified to introduce the MT-ID. + +B.1. Router-LSAs + + Router-LSAs are the Type 1 LSAs. Each router in an area originates a + router-LSA. The LSA describes the state and cost of the router's + links (i.e., interfaces) to the area. All of the router's links to + the area must be described in a single router-LSA. For details + concerning the construction of router-LSAs, see Section 12.4.1 of + [OSPF]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Psenak, et al. Standards Track [Page 13] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |*|*|*|N|W|V|E|B| 0 | # links | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | # MT-ID | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MT-ID | 0 | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MT-ID | 0 | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + Figure 2: Router-LSA Format + + + + + + + + + + + + + + + + + +Psenak, et al. Standards Track [Page 14] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +B.2. Network-LSAs + + Network-LSAs are the Type 2 LSAs. A network-LSA is originated for + each broadcast and Non-Broadcast Multi-Access (NBMA) network in the + area that supports two or more routers. The network-LSA is + originated by the network's Designated Router. The LSA describes all + routers attached to the network, including the Designated Router + itself. The LSA's Link State ID field lists the IP interface address + of the Designated Router. + + The distance from the network to all attached routers is zero. This + is why metric fields need not be specified in the network-LSA. For + details concerning the construction of network-LSAs, see Section + 12.4.2 of [OSPF]. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attached Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + Figure 3: Network-LSA Format + + Note that network-LSA does not contain any MT-ID fields as the cost + of the network to the attached routers is 0 and DR is shared by all + topologies. + + + + + + + + + + + +Psenak, et al. Standards Track [Page 15] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +B.3. Summary-LSAs + + Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by + area border routers. Summary-LSAs describe inter-area destinations. + For details concerning the construction of summary-LSAs, see Section + 12.4.3 of [OSPF]. + + Type 3 summary-LSAs are used when the destination is an IP network. + In this case the LSA's Link State ID field is an IP network number + (if necessary, the Link State ID can also have one or more of the + network's "host" bits set; see Appendix E of [OSPF] for details). + When the destination is an AS boundary router, a Type 4 summary-LSA + is used, and the Link State ID field is the AS boundary router's OSPF + Router ID. (To see why it is necessary to advertise the location of + each ASBR, consult Section 16.4 of [OSPF].) Other than the + difference in the Link State ID field, the format of Type 3 and 4 + summary-LSAs is identical. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 3 or 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MT-ID | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MT-ID | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Summary-LSA Format + + + + + + + +Psenak, et al. Standards Track [Page 16] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +B.4. AS-external-LSAs + + AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by + AS boundary routers, and describe destinations external to the AS. + For details concerning the construction of AS-external-LSAs, see + Section 12.4.3 of [OSPF]. + + AS-external-LSAs usually describe a particular external destination. + For these LSAs, the Link State ID field specifies an IP network + number (if necessary, the Link State ID can also have one or more of + the network's "host" bits set; see Appendix E of [OSPF] for details). + AS-external-LSAs are also used to describe a default route. Default + routes are used when no specific route exists to the destination. + When describing a default route, the Link State ID is always set to + DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Psenak, et al. Standards Track [Page 17] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| 0 | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | External Route Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| MT-ID | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | External Route Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| MT-ID | MT-ID metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | External Route Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: AS-External-LSA Format + +B.5. Type-7 AS-external-LSAs + + Type-7 AS-external-LSAs are originated by AS boundary routers local + to an NSSA (Not-So-Stubby Area), and describe destinations external + to the AS. The changes to Type-7 AS-external-LSAs are identical to + those for AS-external-LSAs (Appendix A.4.5 of [OSPF]). For details + concerning the construction of Type-7 AS-external-LSAs, see Section + 2.4 of [NSSA]. + + + + + +Psenak, et al. Standards Track [Page 18] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +Authors' Addresses + + Peter Psenak + Cisco Systems + Mlynske Nivy 43 + 821 09 + Bratislava + Slovakia + + EMail: ppsenak@cisco.com + + + Sina Mirtorabi + Force10 Networks + 1440 McCarthy Blvd + Milpitas, CA 95035 + USA + + EMail: sina@force10networks.com + + + Abhay Roy + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: akr@cisco.com + + + Liem Nguyen + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: lhnguyen@cisco.com + + + Padma Pillay-Esnault + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: ppe@cisco.com + + + + + +Psenak, et al. Standards Track [Page 19] + +RFC 4915 Multi-Topology (MT) Routing in OSPF June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Psenak, et al. Standards Track [Page 20] + |