Subject: [Isis-wg] Protocol parameter.

From: "Sachidananda K" <[email-masked]>
Date: Tue, 21 Aug 2001 11:03:39 +0000

Hello,

I have some questions related to the parameter 
minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of 
ISO 10589.

Does this parameter corresponds to the frequency at which Link State 
Database is scanned for transmitting the LSP? That is every 
minimumBroadcastLSPTransmissionInterval duration the Link state database 
MUST be scanned for searching the LSP to be sent.

Or it corresponds to the minimum time interval that needs to be allowed 
between consecutive packets (be it of any type) on a LAN interface? that is 
suppose on a particular interface (say A) if a LSP is sent, then for the 
next minimumBroadcastLSPTransmissionInterval duration no other packets of 
any type is to be sent on this interface.

Apart from this, if the point 1 is not true, then is there any parameter 
that dictates the frequency at which the link state database is to be 
scanned for searching the LSP to be sent?

Thanking in advance for all early responses that I receive.
Sachi

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 21 Aug 2001 18:16:16 +0530

Please find my comments inline ..

> MUST be scanned for searching the LSP to be sent.

Yes. Setting the SRMflag does not cause the LSP to be transmitted
immediately. Instead the IS scans the database after every
minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted
randomly. Once this is done the SRMflag for the corresponding LSP is
cleared.

Hope this helps,
Manav Bhatia

> Thanking in advance for all early responses that I receive.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Dave Katz <[email-masked]>
Date: Tue, 21 Aug 2001 08:04:28 -0700 (PDT)

Of course, any implementation that actually scans the database looking
for things to send will probably have other intractable scaling problems
as well.

Unlike the OSPF spec, the ISIS spec provides very little implementation
guidance (a feature, I believe, as it promotes actual thinking.)

All that minimumBroadcastLSPTransmissionInterval does is ensure that
the transmission rate is controlled so you don't swamp your receivers
(as there is no flow control in the protocol.)

   X-Apparently-From: <[email-masked]>
   Reply-To: "Manav Bhatia" <[email-masked]>
   From: "Manav Bhatia" <[email-masked]>
   Cc: <[email-masked]>
   References: <[email-masked]>
   Organization: Samsung India Operations
   MIME-Version: 1.0
   Content-Type: text/plain;
	   charset="iso-8859-1"
   Content-Transfer-Encoding: 7bit
   X-Priority: 3
   X-MSMail-Priority: Normal
   X-Mailer: Microsoft Outlook Express 5.50.4133.2400
   X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
   Sender: [email-masked]
   Errors-To: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Tue, 21 Aug 2001 18:16:16 +0530

   Hope this helps,
   Manav Bhatia

---

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 21 Aug 2001 20:45:54 +0530

> for things to send will probably have other intractable scaling problems
Why so ??
Is it because .. if there is a large toplogy then scanning the entire
database will take up a lot of time .. which is not required out of a
routing protocol because of the convergence issues ..

Regards,
Manav

>    List-Unsubscribe:
<http://external.juniper.net/mailman/listinfo/isis-wg>,
>    > between consecutive packets (be it of any type) on a LAN interface?
that
>    is

---

From: Dave Katz <[email-masked]>
Date: Tue, 21 Aug 2001 08:16:24 -0700 (PDT)

Why so ??

Basically.

---

From: Aravind Ravikumar <[email-masked]>
Date: Thu, 23 Aug 2001 03:32:55 -0700 (PDT)

Hi Sachidananda,

It definitely corresponds to the minimum time interval that needs to be allowed between consecutive LSPs on a LAN interface. But what other significance this 32 millisecond interval has got depends on which of of the following two views hold good. I am not sure about which one is correct and Iam also eager to know

Approach A

          There are certain conditions that make an LSP qualified to be sent. This applies to individual LSPs on per circuit basis and is mainly related to the timing constraint minimumLSPTransmissionInterval. For a large database it is highly probable that at any given time there are LSPs in the database qualified to be send. In ideal case we would never want to hold back an LSP which is qualified to be sent any further. The speed with which we discover a ready LSP is limited by the speed with which we scan the database. Ideally we would like to continuously scan the database and discover ready LSPs as soon as possible. There is a constraint that limits the speed with which you can send the LSPs in the same LAN, even if you have found that it is ready to be transmitted. The minimumLSPbroadcast interval is the minimum interval that you should have between two LSPs sent on a particular LAN. This means that there is no use in finding out ready LSPs more frequent than this, since!
 you cannot send it more frequently. So an efficient implementation should scan the LSDB once in 32 milliseconds, even if its highly demanding

Approach B

As said in section 7.3.15.5 of ISO 10589, If we consider an individual LSP it should be kept with in the router's memory without propagating for atleast minimumLSPTransmissionInterval and no more than twice this value (between 5and 10 seconds). This can be achieved if we scan the database once in each 5 seconds. For a point to point link transmit all the selected LSPs. But in case of broadcast network, take into consideration the 32 millisecond interval between LSP transmission. Even if the router finds out that there are a number of LSPs, keep them in queue and send them separated by 32 milliseconds. The main question here is whether the interpretation that a router can keep an individual LSP between 5 and 10 second is correct or not .If we take an average of 7.5 seconds, a topology change will take more than 75 seconds to travel 10 links. This also puts restriction on scalability.But the advantage is that you need need to scan the whole database once in 5 seconds only, rathe!
r than 32ms

Aravind

  Sachidananda K <[email-masked]> wrote: Hello,

---------------------------------
Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger.

---

From: Aravind Ravikumar <[email-masked]>
Date: Tue, 28 Aug 2001 03:41:52 -0700 (PDT)

Hi Sachidananda, 
         I feel that I was wrong when I said that individual LSPs will remain in the memory for atleast minimumLSP TransmissionInterval and no more than twice that interval
LSP from a particular source shouldn't be transmitted within minimumLSP transmission interval.This means that if we take an individual LSP it will remain in memory before transmission for 0 to 5 seconds according to when the last LSP from same source was transmitted
We can achive this requirement precisely by keeping timers for individual LSPs.So as soon as  this timer expires we could transmit the LSP on the appropriate circuits.For all point to point circuit with SRM flags set it can be send imediately.For broadcast network ensure an interval of 32 milliseconds between successive transmissions on the same LAN.

Since it will be difficult to implement per LSP timer, ISO 10589(7.3.15.5) gives a relaxation to this requirement in section and says that any implementation that ensures an interval between minimumLSP TransmissionInterval and  twice that interval is OK .

We can avoid the need for individual timers and even then meet the requirement fo broadcast circuit precisely and for point to point circuit almost precisely(maximum delay of 32 millisecondsafter the LSP gets ready),if we scan the database each 32 milliseconds along with last sent timestamp.But as 10589 itself says it will be very inefficient to scan at the whole database at this rate.We are free to use any techinique which is reasonably precise and utilizes the relaxation to the exact timer requirement mentioned above

Aravind

---

From: mike shand <[email-masked]>
Date: Tue, 28 Aug 2001 11:41:41 +0100

>(as there is no flow control in the protocol.)

and randomizes the transmission order so that multiple routers on the LAN 
don't all try to send the same LSP at the same time. Note that seeing 
someone else transmit an LSP clears your SRMflag for it, so you don't need 
to bother transmitting it. This probably doesn't matter in the normal case 
of only a few routers on the LAN, but we were trying to make it scale to > 
32 routers (I can't remember why :-)

         Mike