Internet DRAFT - draft-balay-parker-mesh
draft-balay-parker-mesh
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:40:26 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 07 Jun 1999 09:00:00 GMT
ETag: "2e7d6a-341f-375b8a10"
Accept-Ranges: bytes
Content-Length: 13343
Connection: close
Content-Type: text/plain
Internet-Draft ISIS Mesh Groups Rajesh Balay
Mesh Groups for IS-IS Torrent Networks, Inc.
<draft-balay-parker-mesh-00.txt> Jeff Parker
Thu Jun 3 17:35:58 EDT 1999 Nexabit Networks, Inc.
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
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.
Copyright Notice
Expires December 1999 [Page 1]
Internet-Draft ISIS Mesh Groups June 1999
Copyright (C) The Internet Society (1997). All Rights
Reserved.
Expires December 1999 [Page 2]
Internet-Draft ISIS Mesh Groups June 1999
Abstract
This document describes a mechanism to reduce redundant packet
transmissions for the IS-IS Routing protocol, as described in
RFC 1142 [1], when it is used to construct routing tables for
IP networks, as described in RFC 1195 [2]. The described
mechanism can be used to reduce the flooding of Link State
PDUs (LSPs) in IS-IS topologies with fully meshed routers.
Table of Contents
1. Overview............................................. 4
2. Definitions.of.Mesh.Groups........................... 6
3. Other.ways.to.use.this.mechanism..................... 7
4. Potential.Problems.with.mesh.groups.................. 7
5. Acknowledgments...................................... 8
6. References........................................... 8
7. Security.Considerations.............................. 8
8. Authors'.Address..................................... 8
9. Full Copyright Statement............................. 9
Expires December 1999 [Page 3]
Internet-Draft ISIS Mesh Groups June 1999
1. Overview
This document is provided to the IETF working group on IS-IS.
Some organizations attach multiple routers in an ATM mesh.
Each router is connected to many others via point to point
circuits. In the example below, assume that each of the four
routers is connected to each of the other three with a point
to point link, and assume we are running IS-IS over each link.
When we get a new Link State Protocol Data Unit (LSP), we
store it, and prepare to flood it out every port except the
source port. This is done by setting SRM (Send Routing
Message) bits held in the local copy of the LSP: there is an
SRM for each circuit. IS-IS then periodically selects a LSP to
send out a port: this acts to space out the dispersal of LSPs.
+----------+ +----------+
| | I12 I21 | |
| Router 1 | ------------------------------ | Router 2 |
| | | |
+----------+ +----------+
I13 | \ I14 I23 / | I24
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| . |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
I31 | / I32 I41 \ | I42
+----------+ +----------+
| | | |
| Router 3 | ------------------------------ | Router 4 |
| | I34 I43 | |
+----------+ +----------+
Figure 1.
Expires December 1999 [Page 4]
Internet-Draft ISIS Mesh Groups June 1999
When Router1 regenerates an LSP, it will flood the LSP through
the network by marking the SRM bits on the LSP for the
interfaces I12, I14, and I13. In due course, it will send out
the LSP on each interface.
If Router2 runs the protocol described in [1]. when it
receives Router1's LSP it should set the SRM bits on ports I23
and I24, and flood the LSP to Router3 and Router4. However,
these routers will get the LSP directly from Router1. In a
full mesh of N routers, the standard algorithm results in N-2
extra transmissions of each LSP, a waste of time and effort,
with little gain in reliability.
Mesh groups are used to reduce this unneeded traffic. A mesh
group is defined as a collection of interfaces in a network.
At an Intermediate System, an LSP received on an interface
which belongs to a mesh group is not flooded out other
interfaces that belong to the same mesh group.
However, each LSP is available for transmission. In the
figure above, the receipt of a PSNPacket from Router3 with an
out-of date sequence number for Router1's LSP will force
Router2 to set the SRM bit on interface I23 for the new
version of the LSP.
Expires December 1999 [Page 5]
Internet-Draft ISIS Mesh Groups June 1999
2. Definitions of Mesh Groups
Each interface has two new variables: meshGroupEnabled, which
is in state {inactive, blocked, or set} and an integer
variable meshGroup, which is examined if the value of
meshGroupEnabled is 'set'.
The original algorithm upon receipt of an LSP sets the SRMs
for all circuits, as follows:
RxLsp(port in, LinkStatePacket LSP)
{
for all ports 'out'
if (in != out)
set lsp.srm[level, out];
}
When using mesh groups, this would be modified as follows:
when a packet is received, set SRM bit on all ports that are
not blocked and are not in the same (non-null) meshgroup. We
use the SSN bits to mark circuits that will be notified about
a new LSP via a PSNP (Partial Sequence Numbers PDU).
RxLsp(port in, LinkStatePacket LSP)
{
for all ports 'out'
{
if ((in != out) && (out.meshGroupEnabled != blocked))
{
if ((out.meshGroupEnabled == inactive)
|| (in.meshGroupEnabled == inactive)
|| (in.meshgroup != out.meshgroup))
{
set lsp.srm[level, out];
}
else
{
set lsp.ssn[level, out];
}
}
}
}
We only modify the our behavior on the receipt of LSPs. LSPs
that we create are marked to go out all ports, whatever the
Expires December 1999 [Page 6]
Internet-Draft ISIS Mesh Groups June 1999
combination of mesh groups.
Expires December 1999 [Page 7]
Internet-Draft ISIS Mesh Groups June 1999
3. Other ways to use this mechanism
One intermediate system in a fully meshed network could be
used to distribute all routes. All interfaces not on the
designated Intermediate System, or connected to the designated
Intermediate System, are marked "blocked". As a result, all
LSPs flow to the designated Intermediate System, which then
paces the redistribution to other systems.
Expires December 1999 [Page 8]
Internet-Draft ISIS Mesh Groups June 1999
4. Potential Problems with mesh groups
Mesh groups significantly reduce the redundant flooding of
LSPs in a fully connected mesh of routers. However, some
concerns which relate to the point-point protocol behavior
exist. IS-IS protocol behavior is to send a Complete Sequence
Number PDU (CSNP) over a point-point interface once an
adjacency is established. A router on processing the received
CSNP initiates Partial Sequence Number PDUs (PSNPs) [1,
section 7.3.15.2] for all the LSPs which it is missing. This
mechanism helps in synchronizing the database with the
adjacent router. If these CSNPs are lost, routers may take
longer time to synchronize their databases. However, the use
of SSN and PSNPs produce synchronization in due time.
If the configuration of a port does not match the underlying
topology, then LSPs will not be sent in a timely fashion,
which may lead to routing loops or black holes.
Expires December 1999 [Page 9]
Internet-Draft ISIS Mesh Groups June 1999
5. Acknowledgments
XXX names, if any
6. References
[1] Oran, D., Editor, "OSI IS-IS Intra-domain Routing
Protocol", RFC 1142, February 1990
[2] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990
7. Security Considerations
This proposal does not change any information that is
exchanged on circuits. Inappropriate setings of mesh group
variables, or "blocking" an interface will prevent routers
from seeing the network. However, for intruders that can
modify router settings, there are many other more direct ways
to disable a router.
This document raises no new security issues for IS-IS.
8. Authors' Address
Jeff Parker
Nexabit Networks, Inc.
200 Nickerson Road,
Marlborough, MA 01752
email: jparker@nexabit.com
Rajesh Balay
Torrent Networking Technologies
(An Ericsson Company)
3000 Aerial Center Pkwy, Suite 140
email: balay@torrentnet.com
Expires December 1999 [Page 10]
Internet-Draft ISIS Mesh Groups June 1999
9. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Expires December 1999 [Page 11]
