draft-ietf-ospf-mt-04.txt   draft-ietf-ospf-mt-05.txt 
Network Working Group P. Psenak Network Working Group P. Psenak
Internet-Draft S. Mirtorabi Internet-Draft S. Mirtorabi
Expires: October 22, 2005 A. Roy Expires: July 16, 2006 A. Roy
L. Nguyen L. Nguyen
P. Pillay-Esnault P. Pillay-Esnault
Cisco Systems Cisco Systems
April 20, 2005 January 12, 2006
Multi-Topology (MT) Routing in OSPF Multi-Topology (MT) Routing in OSPF
draft-ietf-ospf-mt-04.txt draft-ietf-ospf-mt-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2005. This Internet-Draft will expire on July 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This draft describes an extension to OSPF in order to define This draft describes an extension to OSPF in order to define
independent IP topologies called Multi-Topologies (MTs). The MT independent IP topologies called Multi-Topologies (MTs). The MT
extension can be used for computing different paths for unicast extension can be used for computing different paths for unicast
traffic, multicast traffic, different classes of service based on traffic, multicast traffic, different classes of service based on
flexible criteria, or an in-band network management topology. flexible criteria, or an in-band network management topology.
[M-ISIS] describes a similar mechanism for ISIS. [M-ISIS] describes a similar mechanism for ISIS.
skipping to change at page 2, line 34 skipping to change at page 2, line 34
IP Prefixes . . . . . . . . . . . . . . . . . . . . . 6 IP Prefixes . . . . . . . . . . . . . . . . . . . . . 6
3.4.2 Inter-Area and External Routing . . . . . . . . . . . 7 3.4.2 Inter-Area and External Routing . . . . . . . . . . . 7
3.5 Flushing MT Information . . . . . . . . . . . . . . . . . 7 3.5 Flushing MT Information . . . . . . . . . . . . . . . . . 7
3.6 MT SPF Computation . . . . . . . . . . . . . . . . . . . . 7 3.6 MT SPF Computation . . . . . . . . . . . . . . . . . . . . 7
3.7 MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 8 3.7 MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 8 3.8 Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 8
4. Default Topology Link Exclusion Functional Specifications . . 9 4. Default Topology Link Exclusion Functional Specifications . . 9
4.1 Exclusion of Links in the Default Topology . . . . . . . . 9 4.1 Exclusion of Links in the Default Topology . . . . . . . . 9
4.2 New Area Data Structure Parameter . . . . . . . . . . . . 9 4.2 New Area Data Structure Parameter . . . . . . . . . . . . 9
4.3 Adjacency Formation with Link Exclusion Capability . . . . 10 4.3 Adjacency Formation with Link Exclusion Capability . . . . 10
4.4 OSPF Control Packets Transmission Over Excluded Links . . 10 4.4 OSPF Control Packets Transmission Over Excluded Links . . 11
4.5 OSPF LSA Advertisement and SPF Computation for 4.5 OSPF LSA Advertisement and SPF Computation for
Excluded Links . . . . . . . . . . . . . . . . . . . . . . 11 Excluded Links . . . . . . . . . . . . . . . . . . . . . . 11
5. Interoperability between MT Capable and Non-MT Capable 5. Interoperability between MT Capable and Non-MT Capable
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Demand Circuit Compatibility Considerations . . . . . . . 12
6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13 6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16
9.2 Informative References . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
B. OSPF data formats . . . . . . . . . . . . . . . . . . . . . . 19 B. OSPF data formats . . . . . . . . . . . . . . . . . . . . . . 19
B.1 Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 B.1 Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 9, line 33 skipping to change at page 9, line 33
metric for default topology will be advertised. metric for default topology will be advertised.
The unused T-bit is defined as the MT-bit in the option field in The unused T-bit is defined as the MT-bit in the option field in
order to assure that a multi-topology link-excluding capable router order to assure that a multi-topology link-excluding capable router
will only form an adjacency with another similarly configured router. will only form an adjacency with another similarly configured router.
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|DN |O |DC |EA |NP |MC |E |MT | |DN |O |DC |EA |NP |MC |E |MT |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
MT-bit: This bit MUST be set in the Hello packet only if MT-bit: This bit MUST be set in Hello and Database Description
DefaultExclusionCapability is enabled (see Section 4.2) packets only if DefaultExclusionCapability is enabled
(see Section 4.2)
4.2 New Area Data Structure Parameter 4.2 New Area Data Structure Parameter
We define a new parameter in the Area Data Structure: We define a new parameter in the Area Data Structure:
DefaultExclusionCapability DefaultExclusionCapability
This configurable parameter ensures that all routers in an area This configurable parameter ensures that all routers in an area
have this capability enabled before the default topology can be have this capability enabled before the default topology can be
disabled on a router link in the area without causing backward disabled on a router link in the area without causing backward
compatibility problems. compatibility problems.
When an area data structure is created the DefaultExclusionCapability When an area data structure is created the DefaultExclusionCapability
is disabled by default. is disabled by default.
If DefaultExclusionCapability is disabled: If DefaultExclusionCapability is disabled:
o The MT-bit MUST be cleared in Hello packets. o The MT-bit MUST be cleared in Hello and Database Description
packets.
o If a link participates in a non-default topology, it is o If a link participates in a non-default topology, it is
automatically included in the default topology to support backward automatically included in the default topology to support backward
compatibility between MT and non-MT routers. This is accomplished compatibility between MT and non-MT routers. This is accomplished
through advertisement via the TOS0 metric field the same as in through advertisement via the TOS0 metric field the same as in
standard OSPF [OSPF]. standard OSPF [OSPF].
If DefaultExclusionCapability is enabled: If DefaultExclusionCapability is enabled:
o The MT-bit MUST be set in Hello packets o The MT-bit MUST be set in Hello and Database Description packets
o The router will only accept a Hello if the MT-bit is set (see o The router will only accept a Hello or Database Description packet
Section 4.3) if the MT-bit is set (see Section 4.3)
When DefaultExclusionCapability is set to enabled a router is said to When DefaultExclusionCapability is set to enabled a router is said to
be operating in DefaultExclusionCapability mode. be operating in DefaultExclusionCapability mode.
4.3 Adjacency Formation with Link Exclusion Capability 4.3 Adjacency Formation with Link Exclusion Capability
In order to have a smooth transition from a non-MT area to an MT- In order to have a smooth transition from a non-MT area to an MT-
area, an MT router with DefaultExclusionCapability disabled will form area, an MT router with DefaultExclusionCapability disabled will form
adjacencies with non-MT routers and will include all links as part of adjacencies with non-MT routers and will include all links as part of
default topology. default topology.
A link may cease participating in default topology if A link may cease participating in default topology if
DefaultExclusionCapability is set to enabled. In this state, a DefaultExclusionCapability is set to enabled. In this state, a
router will only form adjacency with routers that set the MT-bit in router will only form adjacency with routers that set the MT-bit in
their Hello packets. This will ensure that all routers have their Hello and Database Description packets. This will ensure that
DefaultExclusionCapability enabled before the default topology can be all routers have DefaultExclusionCapability enabled before the
disabled on a link. default topology can be disabled on a link.
Receiving OSPF Hello packets as defined in section 10.5 of [OSPF] is Receiving OSPF Hello packets as defined in section 10.5 of [OSPF] is
modified as follows: modified as follows:
o If the DefaultExclusionCapability of the Area Data structure is o If the DefaultExclusionCapability in the Area Data structure is
set to enabled, the Hello packets are discarded if the the set to enabled, Hello packets are discarded if the the received
received Hello packet does not have the MT-bit in the hello packet does not have the MT-bit set in the header options.
options set.
Receiving OSPF Database Description packets as defined in section
10.6 of [OSPF] is modified as follows:
If the DefaultExclusionCapability in the Area Data structure is
set to enabled, Database Description packets are discarded if the
the received packet does not have the MT-bit set in the header
options. The neighbor state is not modified to allow a window of
RouterDeadInterval seconds where the neighbor's
DefaultExclusionCapability may be upgraded.
4.4 OSPF Control Packets Transmission Over Excluded Links 4.4 OSPF Control Packets Transmission Over Excluded Links
If DefaultExclusionCapability is enabled, the default topology can be If DefaultExclusionCapability is enabled, the default topology can be
disabled on an interface. Disabling the default topology on an disabled on an interface. Disabling the default topology on an
interface does not impact the installation of connected routes for interface does not impact the installation of connected routes for
the interface in the default topology. It only affects what a router the interface in the default topology. It only affects what a router
advertises in its Router-LSA. advertises in its Router-LSA.
This allows OSPF control packets to be sent and received over an This allows OSPF control packets to be sent and received over an
skipping to change at page 13, line 5 skipping to change at page 12, line 27
routers will assure that all other routers in the area are in the routers will assure that all other routers in the area are in the
DefaultExclusionCapability mode before considering the MT-ID#0 metric DefaultExclusionCapability mode before considering the MT-ID#0 metric
in the SPF calculation. Only then can the TOS0 metric field in in the SPF calculation. Only then can the TOS0 metric field in
Router LSAs be safely ignored during the default topology SPF Router LSAs be safely ignored during the default topology SPF
computation. computation.
Note that for any prefix or router to become reachable in a certain Note that for any prefix or router to become reachable in a certain
topology, a contiguous path inside that topology must exist between topology, a contiguous path inside that topology must exist between
the calculating router and the destination prefix or router. 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 hellos 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 hellos with a
conflicting MT-bit or hello suppression will be renegotiated.
6. Migration from non-MT-Area to MT-area 6. Migration from non-MT-Area to MT-area
Introducing MT-OSPF into a network can be done gradually to allow MT Introducing MT-OSPF into a network can be done gradually to allow MT
routers and non-MT routers to participate in the default topology routers and non-MT routers to participate in the default topology
while MT routers participate in other topologies. while MT routers participate in other topologies.
If there is a requirement to exclude some links from the default If there is a requirement to exclude some links from the default
topology in an area, all routers in the area MUST be in topology in an area, all routers in the area MUST be in
DefaultExclusionCapability mode. In this section we describe the DefaultExclusionCapability mode. In this section we describe the
migration steps to consider while transitioning from a non-MT network migration steps to consider while transitioning from a non-MT network
skipping to change at page 16, line 9 skipping to change at page 16, line 9
The T-bit as defined in [RFC1583] for a router's TOS capability is The T-bit as defined in [RFC1583] for a router's TOS capability is
redefined as the MT-bit in this document. Similarly, the TOS field redefined as the MT-bit in this document. Similarly, the TOS field
for Router-LSAs, Summary-LSAs, NSSA-LSAs, and AS-External LSAs as for Router-LSAs, Summary-LSAs, NSSA-LSAs, and AS-External LSAs as
defined in [OSPF] is redefined as MT-ID in this document. defined in [OSPF] is redefined as MT-ID in this document.
9. References 9. References
9.1 Normative References 9.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", [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
skipping to change at page 23, line 41 skipping to change at page 23, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 16 change blocks. 
20 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/