From: John Underhill (stepnwlf@magma.ca)
Date: Sun Jun 08 2003 - 20:54:24 GMT-3
As the pipe gets full, it dials a second bri, creating the MP bundle, the
dialer load-threshold is the criteria it uses to determine when an MP should
be created, and additional lines brought into the bundle, (say, in the case
of a PRI). When the flow falls below the defined threshold the bundle is
dissasembled and the secondary bri is left idle. After the idle-timeout is
reached, it drops the bri.
From the rfc:
http://www.ietf.org/rfc/rfc1717.txt
Implementations concerned about either wasting bandwidth or per packet costs
are not required to send null fragments and may elect to defer sending them
until a timer expires, with the marginally increased possibility of
lengthier stalls in the receiver. The receiver SHOULD implement some type
of link idle timer to guard against indefinite stalls.
----- Original Message -----
From: "Daniel Cisco Group Study" <danielcgs@imc.net.au>
To: "John Underhill" <stepnwlf@magma.ca>; "Daniel Cisco Group Study"
<danielcgs@imc.net.au>; <ccielab@groupstudy.com>
Sent: Sunday, June 08, 2003 7:11 PM
Subject: RE: Dialer Load Threshold - When does it come back down???
> I don't think so. In ppp multilink environment, packets are fragmented
across multiple B channels. It would be highly unlikely that any B channels
would be quite, while others are busy.
>
> Daniel
>
>
> -----Original Message-----
> From: John Underhill [mailto:stepnwlf@magma.ca]
> Sent: Monday, 9 June 2003 01:56
> To: Daniel Cisco Group Study; ccielab@groupstudy.com
> Subject: Re: Dialer Load Threshold - When does it come back down???
>
>
> Doesn't this depend on the dialer idle-timeout setting? If any one of the
> cumulative links is idle beyond the defined time it will drop, and redial
if
> the load threshold is reached again..
>
> ----- Original Message -----
> From: "Daniel Cisco Group Study" <danielcgs@imc.net.au>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, June 08, 2003 2:36 AM
> Subject: Dialer Load Threshold - When does it come back down???
>
>
> > This whole issue is very unclear in my mind. The docos say the
following:
> >
> > "When the cumulative load of all UP links (a number n) exceeds the load
> threshold the dialer adds an extra link and when the cumulative load of
all
> UP links minus one (n - 1) is at or below load threshold then the dialer
can
> bring down that one link. The dialer will make additional calls or drop
> links as necessary but will never interrupt an existing call to another
> destination"
> >
> > I would like to work on a couple of examples with those who are
> interested.
> >
> > (1) Say I use the following:
> >
> > int bri 0
> > ppp multilink
> > dialer load-threshold 64 either
> >
> > I think that we would all agree that the 2nd B channel comes up when the
> load in either direction on the active (1st) B channel reaches 16kbps.
(64k
> x [64/255]).
> >
> > Now, when does it come back down ???? The doco tries to explain it, but
> its all very muddy in my mind.... I don't know what its trying to say.
> >
> >
> > (2) Let's take this one step further.
> > We have an E1 PRI service (30 channels + 1D) - placing calls to the same
> destination:
> >
> > int s0/0:15
> > ppp multilink
> > dialer load-threshold 64 either
> >
> > We would agree that if we already have 5 B channels up, the 6th one
comes
> up when the combined bandwidth of all 5 B channels is 80k (5 x 64 x
> [64/255]). Correct ?????
> >
> > Now we have 6 B channels for a combined total available bandwidth of
384k.
> When does one of the B channels drop?
> >
> > Daniel
> >
> >
> >
> >
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> > This footnote also confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> > www.mimesweeper.com
> > **********************************************************************
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> www.mimesweeper.com
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:55 GMT-3