One document matched: draft-ietf-isis-wg-multi-topology-05.txt
Differences from draft-ietf-isis-wg-multi-topology-04.txt
Network Working Group Tony Przygienda (Xebeo)
Internet Draft Naiming Shen (Redback)
<draft-ietf-isis-wg-multi-topology-05.txt> Nischal Sheth (Juniper)
October 2002
Expires: April 2003
M-ISIS: Multi Topology (MT) Routing in IS-IS
1. Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
This draft describes an optional mechanism within ISIS used today
by many ISPs for IGP routing within their clouds. This draft
describes how to run within a single ISIS domain a set of
independent IP topologies that we call Multi-Topologies (MTs).
This MT extension can be used for variety of purposes such as an
in-band management network ``on top'' of the original IGP topology,
maintain separate IGP routing domains for isolated multicast or
IPv6 islands within the backbone, or force a subset of an address
space to follow a different topology.
3. Specification of Requirements
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 [RFC2119].
Przygienda, Shen, Sheth Expires April 2003 [Page 1]
Internet Draft M-ISIS October 2002
4. Introduction
Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a
backwards-compatible manner necessitates several extensions to the
packet encoding and additional SPF procedures. The problem can
be partitioned into forming of adjacencies, and advertising of
prefixes and reachable intermediate systems within each topology.
Having put all the necessary additional information in place, it
must be properly used by MT capable SPF computation. The following
sections describe each of the problems separately. To simplify the
text, ``standard'' ISIS topology is defined to be MT ID #0 (zero).
5. Maintaining MT Adjacencies
Each adjacency formed MUST be classified as belonging to a set of
MTs on the interface. This is achieved by adding a new TLV into
IIH packets that advertises which topologies the interface belongs
to. If MT #0 is the only MT on the interface, it is optional to
advertise it in the new TLV. Thus not including such a TLV in the
IIH implies MT ID #0 capability only. Through this exchange of MT
capabilities, a router is able to advertise the IS TLVs in LSPs
with common MT set over those adjacencies.
As a simplifying side-effect, boundaries between levels will be the
same for all MTs.
In the case of adjacency contains multiple MTs on an interface, and
if there exists overlapping IP address space among the topologies,
additional mechanism MAY be used to resolve the topology identity of
the incoming IP packets on the interface.
5.1. Forming Adjacencies on Point-to-Point Interfaces
Adjacencies on point-to-point interfaces are formed as usual with
ISIS routers not implementing MT extensions. If local router does
not participate in certain MTs, it will not advertise those MTIDs
in it's IIHs and thus will not include that neighbor within it's
topology based LSPs. On the other hand, if a MTID is not
detected in remote side's IIHs, the local router MUST NOT include
that neighbor within it's MT LSPs. The local router SHOULD NOT form
adjacency if they don't have at least one common MT set over the
interface.
5.2. Forming Adjacencies on Broadcast Interfaces
On a LAN, all the routers on the LAN which implement the MT
extension MAY advertise their MT capability TLV in their IIHs.
If there is at least one adjacency on the LAN interface which
belongs to this MT, the MT capable router MUST include according
MT IS Reachable TLV in its LSP, otherwise it MAY include this MT
Przygienda, Shen, Sheth Expires April 2003 [Page 2]
Internet Draft M-ISIS October 2002
IS Reachable TLV in it's LSP if the LAN interface participates in
this MT set.
Two Routers on a LAN SHALL always establish adjacency regardless
whether they have common MT set or not. This is to ensure all
the routers on the LAN can correctly elect the same DIS. The IS
SHOULD NOT include the MT IS TLV in its LSP if none of the
adjacencies on the LAN contains this MT.
The DIS, CSNP and PSNP functions are not changed by MT extension.
6. Advertising MT Reachable Intermediate Systems in LSPs
A router MUST include within its LSPs in the Reachable Intermediate
Systems TLVs only adjacent nodes that are participating in the
according topology and advertise such TLVs only if it participates
itself in the according topology. Standard Reachable Intermediate
Systems TLV is acting here as MT ID #0 equivalent of the newly
introduced MT Reachable Intermediate Systems TLV. A router MUST
announce the MT IS TLV when there is at least one adjacency on the
interface that belongs to this MT, otherwise it MAY announce the MT
IS TLV of an adjacency for a given MT if this interface participates
in the LAN.
Since it is not possible to prevent a router that does not understand
MT extensions from being responsible for generation of the according
pseudo-node, it is not possible either to introduce special TLVs in
the pseudo-node LSPs nor run distinct DIS elections per MT.
Therefore, a generated pseudo-node LSP by DIS MUST contain in its
IS Reachable TLV all nodes on the LAN as usual regardless of their
MT capabilities. In other words, there is no change to the
pseudo-node LSP construction.
7. MTs and Overload, Partition and Attached Bits
As stated earlier, all MTs share the same set of L1-L2 boundaries
and NETs. However, a router could for each of the MTs become
potentially partitioned, overloaded and attached independently.
To prevent unnecessary complexity, MT extensions does not support
partition repair.
Attached bit and overload bit are part of the MT TLV being
distributed within a node's LSP fragment zero. Since each adjacency
can belong to different MTs, it is possible that some MTs are L2
attached, and others are not on the same router. The overload
bit in the MT TLV can be used to signal the topology being
overloaded. A MT based system is considered being overloaded if
either the overload bit in the MT is set or the overload bit of
the LSP is set.
Przygienda, Shen, Sheth Expires April 2003 [Page 3]
Internet Draft M-ISIS October 2002
8. Advertising MT Specific IP Prefixes
Each of the MTs commands its own address space so a new TLV is
necessary for prefixes stored in MTs other than MT ID #0. To
make the encoding less confusing when same prefixes are present in
multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV
in TE extensions, a new TLV is introduced for that purpose that
closely follows TE encoding [LS01].
9. MT SPF Computation
Each MT MUST run its own instance of the decision process.
The LSP overload bit and pseudo-node LSPs are used by all
topologies during computation. Each topology MAY have it's
attached bit and overload bit set in the MT TLV. Reverse
connectivity check within SPF MUST follow the according MT to
assure the bi-directional reachability within the same MT.
The results of each computation SHOULD be stored in a separate RIB
in normal cases, otherwise overlapping addresses in different
topologies could lead to undesirable routing behavior such as
forwarding loops. The forwarding logic and configuration need to
ensure the same MT is traversed from the source to the destination
for packets. The nexthops derived from the MT SPF MUST belong to
the adjacencies conforming to the same MT for correct forwarding.
It is recommended for the administrators to ensure consistent
configuration of all routers in the domain to prevent undesirable
forwarding behavior.
10. LSP Flooding
The LSP flooding mechanism is not changed by this MT extension.
An implementation MAY have the option to use additional MT
information in the LSP and on the adjacency to reduce some of the
unnecessary LSP flooding over the point-to-point links. If a
receiving interface and an outgoing interface don't share any
common MT set, the implementation MAY have the option not to flood
this LSP out on that interface. Since the fragment zero LSP
contains the MTID, the MT capability of any LSP can be identified.
If the LSP and the adjacencies of an outgoing interface do not
share any common MT capability, the implementation MAY have the
option not to flood this LSP out on that interface. An
implementation MAY want to have the operators to control those
optimization base on network topology and environment to ensure
the LSP flooding reliability. For the neighbors have the Generic
MT SPF enabled, this flooding optimization SHOULD NOT be used
over the links to those neighbors.
Przygienda, Shen, Sheth Expires April 2003 [Page 4]
Internet Draft M-ISIS October 2002
When there is an adjacency MT set change over an point-to-point
link and the adjacency is in UP state, both sides SHOULD force an
exchange of one set of CSNPs over that link.
11. Packet Encoding
Three new TLVs are added to support MT extensions. One of them is
common for the LSPs and IIHs. Encoding of Intermediate System TLV
and IPv4 Reachable Prefixes is tied to traffic engineering
extensions [LS01] to simplify the implementation effort. The main
reasons we choose using new TLVs instead of using sub-TLVs inside
existing TLV type-22 and type-135 are: In many cases,
multi-topologies are non-congruent, using sub-TLV approach will
not save LSP space; Many sub-TLVs are already being used in TLV
type-22, and many more are being proposed while there is a maximum
limit on the TLV size, from the existing TLVs; If traffic
engineering or some other applications are being applied per
topology level later, the new TLVs can automatically inherit the
same attributes already defined for the ``standard'' IPv4 topology
without going through long standard process to redefine them per
topology.
11.1. Multi-Topology TLV
TLV number of this TLV is 229. It contains one or more MTs
the router is participating in the following structure:
x CODE - 229
x LENGTH - total length of the value field, it should be 2
times the number of MT components.
x VALUE - one or more 2-byte MT components, structured
as follows:
No. of Octets
+--------------------------------+
|O |A |R |R | MT ID | 2
+--------------------------------+
Bit O represents the OVERLOAD bit for the MT (only valid
in LSP fragment zero for MTs other than ID #0, otherwise
should be set to 0 on transmission and ignored on receipt.)
Bit A represents the ATTACH bit for the MT (only valid
in LSP fragment zero for MTs other than ID #0, otherwise
should be set to 0 on transmission and ignored on receipt.)
Bits R are reserved, should be set to 0 on transmission
and ignored on receipt.
MT ID is a 12-bit field containing the ID of the topology
being announced.
Przygienda, Shen, Sheth Expires April 2003 [Page 5]
Internet Draft M-ISIS October 2002
This MT TLV can advertise up to 127 MTs and it can occur multiple
times if needed within IIHs and LSP fragment zero. The result MT
set should be the union of all the MT TLV occurrence in the packet.
Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack
of MT TLV in hellos and fragment zero LSP MUST be interpreted as
participation of the advertising interface or router in
MT ID #0 only. If a router advertises MT TLV, it has to advertise
all the MTs it participates in, specifically including topology
ID #0 also.
11.2. MT Intermediate Systems TLV
TLV number of this TLV is 222. It is aligned with extended IS
reachability TLV type 22 beside an additional two bytes in front at
the beginning of the TLV.
x CODE - 222
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of extended IS
reachability TLV, structured as follows:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
Bits R are reserved, should be set to 0 on transmission
and ignored on receipt.
MT ID is a 12-bit field containing the ID of the topology
being announced.
After the 2-byte MT membership format, the MT IS content is
in the same format as extended IS TLV, type 22 [LS01]. It
can contain up to 23 neighbors of the same MT if no sub-TLVs
are used.
This TLV can occur multiple times.
11.3. Multi-Topology Reachable IPv4 Prefixes TLV
TLV number of this TLV is 235. It is aligned with extended IS
reachability TLV type 135 beside an additional two bytes in front.
Przygienda, Shen, Sheth Expires April 2003 [Page 6]
Internet Draft M-ISIS October 2002
x CODE - 235
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of extended
extended IP reachability TLV, structured as follows:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
Bits R are reserved, should be set to 0 on transmission
and ignored on receipt.
MT ID is a 12-bit field containing the ID of the topology
being announced.
After the 2-byte MT membership format, the MT IPv4 content
is in the same format as extended IP reachability TLV,
type 135 [LS01].
This TLV can occur multiple times.
11.4. Multi-Topology Reachable IPv6 Prefixes TLV
TLV number of this TLV is 237. It is aligned with IPv6 Reachability
TLV type 236 beside an additional two bytes in front.
x CODE - 237
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of IPv6
Reachability TLV, structured as follows:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
Przygienda, Shen, Sheth Expires April 2003 [Page 7]
Internet Draft M-ISIS October 2002
Bits R are reserved, should be set to 0 on transmission
and ignored on receipt.
MT ID is a 12-bit field containing the ID of the topology
being announced.
After the 2-byte MT membership format, the MT IPv6 context
is in the same format as IPv6 Reachability TLV,
type 236 [H01].
This TLV can occur multiple times.
11.5. Reserved MT ID Values
Certain MT topologies are assigned to serve pre-determined purposes:
- MT ID #0: Equivalent to the ``standard'' topology.
- MT ID #1: Reserved for in-band management purposes.
- MT ID #2: Reserved for IPv6 routing topology.
- MT ID #3: Reserved for IPv4 multicast routing topology.
- MT ID #4: Reserved for IPv6 multicast routing topology.
- MT ID #5-#3995: Reserved for IETF consensus.
- MT ID #3996-#4095: Reserved for development, experimental and
proprietary features.
12. MT IP Forwarding Considerations
Using MT extension for ISIS routing can result in multiple RIBs
on the system. The implementation and configuration MUST make
sure the IP packets are only traversed through the nodes and links
intended for the topologies and applications. In this section we
list some of the known considerations for IP forwarding in various
MT scenario. Certain deployment scenarios presented here
imply different trade-offs in terms of deployment difficulties
and advantages obtained.
12.1. Each MT belong to a distinct address family
In this case, each MT related routes are installed into a
separate RIB. Multiple topologies can share the same ISIS interface
on detecting the incoming packet address family. As an example,
IPv4 and IPv6 can share the same interface without any further
considerations under MT ISIS.
12.2. Some MTs belong to the same address family
12.2.1. Each interface belongs to one and only one MT
In this case, MTs can be used to forward packets from the
same address family, even with overlapping addresses. Since the
MTs have their dedicated interfaces, and those interfaces can be
Przygienda, Shen, Sheth Expires April 2003 [Page 8]
Internet Draft M-ISIS October 2002
associated with certain MT RIBs and FIBs.
12.2.2. Multiple MTs share an interface with overlapping addresses
Some additional mechanism is needed to select the correct RIBs
for the incoming IP packets to determine the correct RIB to make
a forwarding decision. For example, if the topologies are
QoS partitioned, then the DSCP bits in the IP packet header can
be utilized to make the decision. Some IP header or even packet
data information may be checked to make the forwarding table
selection, such as source IP address in the header can be used
to determine the desired forwarding behavior.
12.2.3. Multiple MTs share an interface with non-overlapping addresses
When there is no overlap in the address space among all the MTs,
strictly speaking the destination address space classifies the
topology a packet belongs to. It is possible to install routes
from different MTs into a shared RIB. As an example of such a
deployment, a special ISIS topology can be setup for certain
EBGP nexthop addresses.
12.3 Some MTs are not used for forwarding purpose
MT in ISIS may be used even if the resulting RIB is not used for
forwarding purposes. As an example, multicast RPF check can be
performed on a different RIB than the standard unicast RIB albeit
an entirely different RIB is used for the multicast forwarding.
However, an incoming packet must be still clearly identified as
belonging to a unique topology.
13. MT Network Management Considerations
When multiple ISIS 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.
13.1. Create dedicated management topology to include all the nodes
This approach is to setup 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' RIB.
The configuration can optionally redistribute the routes in 'mgmt'
RIB into the default or 'normal'. This assumes the 'mgmt' topology
uses a set of non-overlapping address space with the default
topology. As long as the nexthops of the routes are kept the same,
Przygienda, Shen, Sheth Expires April 2003 [Page 9]
Internet Draft M-ISIS October 2002
checking either RIBs will work for the network management purpose.
The advantages of duplicate 'mgmt' routes in both RIBs include:
the network management utilities on the system does 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.
13.2. Extend the default topology to all the nodes
Even in the case 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 high cost on the links which 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.
14. Acknowledgments
The authors would like to thank Andrew Partan, Dino Farinacci,
Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,
and Mike Shand for the discussion, their review, comments and
contributions to this draft.
15. Security Consideration
ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known. The authentication
procedure for ISIS PDUs is the same regardless of MT information
inside the ISIS PDUs.
16. Normative References
[ISO10589] ISO. Intermediate System to Intermediate System Routing
Exchange Protocol for Use in Conjunction with the Protocol
for Providing the Connectionless-Mode Network Service.
ISO 10589, 1992.
[RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and
Dual Environments. RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LS01] T. Li and H. Smit. IS-IS Extensions for Traffic
Engineering. draft-ietf-isis-traffic-04.txt, August 2001
(work in progress)
Przygienda, Shen, Sheth Expires April 2003 [Page 10]
Internet Draft M-ISIS October 2002
[H01] C. Hopps. Routing IPv6 with IS-IS.
draft-ietf-isis-ipv6-02.txt, April 2001
(work in progress)
17. Authors' Addresses
Tony Przygienda
Xebeo
One Cragwood Road
South Plainfield, NJ 07080
Phone: (908) 222 4225
prz@xebeo.com
Naiming Shen
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
naiming@redback.com
Nischal Sheth
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
nsheth@juniper.net
Przygienda, Shen, Sheth Expires April 2003 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 10:49:47 |