From: Scott Morris (swm@emanon.com)
Date: Tue Nov 01 2005 - 11:51:37 GMT-3
That's just the typical design yes. Reality may differ though. While voice
samples are 10ms each, standard VoIP has two samples per packet (20ms worth)
@ 50pps. You can change that to have 3 samples (@ 33pps) as well, but
that's well beyond the scope of the R&S CCIE lab.
Just stick with 1/8 for data and 1/100 for voice, and you'll be good!
Scott
-----Original Message-----
From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
Sent: Tuesday, November 01, 2005 9:09 AM
To: swm@emanon.com; Imal kalutotage; Ralph
Cc: ccielab@groupstudy.com
Subject: RE: RE: Re: Frame-Relay fragmentation
Thanks for the info, Scott. So, it appears that when voice is involved, we
would use the timing slice of 100 (as opposed to the default for data of 8),
giving us a Tc of 10ms (as opposed to 125mS for data), correct?
Therefore, if the requirement was for voice and data and we needed to do
fragmentation.....given a line rate of 512k with 256k CIR.....
256000/100 = 2560bits/sec
2560/8 = 320 fragment size
Am I thinking this right?
Also, what about the original question. What if the requirement states that
voice remains unfragmented.....does the above calculation automatically do
this?
Dave Schulz, CCDP, CCNP, CCSP
Project Manager / TAC Supervisor
Data Processing Sciences Corporation
10810 Kenwood Road
Cincinnati, Ohio 45242
Phone - (513) 791-7100 ext.7411
Fax - (513) 791-4676
Email: dschulz@dpsciences.com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Tuesday, November 01, 2005 12:30 AM
To: 'Imal kalutotage'; 'Ralph'
Cc: Schulz, Dave; ccielab@groupstudy.com
Subject: RE: RE: Re: Frame-Relay fragmentation
Fragment size is not necessarily tied to the Bc. Let me back up a bit
here... It's not tied to Bc in as much as a particular calculation that you
will do. It should be taken into account mathematically because it doesn't
make any sense to have a large burst but small fragment size.
However, since you fragment based on the latency issues you may experience
(serialization delay as a predictable one) and want to make things smaller
so that your voice traffic has a fair chance on the line, then it would
stand to reason that your calculation be based on the serialization speed
with regards to a timing of a packet rather than the exact size.
At least that's how FRF12 takes things into account. It looks for a packet
size that you want. A good guideline (you can always check with the various
voice design guides) is 80 bytes per 64K line speed. So if you have a 128K
line, your fragment size would be 160. If you have a 512K line, it would be
640.
At the same time, when you are calculating your shaping stuff, since we're
doing this with voice in mind, it would stand to reason that you pick 10ms
as your sample size, and therefore if shaping to 64K your Bc would be 640
bits (fragment size is in bytes, so while the numbers are the same here,
they don't really have a lot to do with each other).
Typically, you do not fragment on links that have speeds above 768K.
The
reason isn't that serialization delay disappears, but more because it'll
take you more time to process through the fragmentation then it would to get
the stuff out on the line anyway.
Regardless of this logic, if the lab gives you specific values, you do
whatever they want! :)
I hope this has cleared things up a little bit and not added to the
confusion.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Imal
kalutotage
Sent: Tuesday, November 01, 2005 12:17 AM
To: Ralph
Cc: DSchulz@dpsciences.com; ccielab@groupstudy.com
Subject: Re: RE: Re: Frame-Relay fragmentation
Hi,
can somebody tell me how to calculate fragment size from the Bc..
Cheers
imal
On 11/1/05, Ralph <Mandela@myrealbox.com> wrote:
>
> Dave,
>
> The CiscoPress Book "IP Quality of Service" by Srinivas Vegesna, Has a
> good explanation and case study on frame-relay fragmentation. IMHO, I
> think this book does a good job explaining a lot of QoS topics.
>
> Ralph
>
> -----Original Message-----
> From: "Schulz, Dave" <DSchulz@dpsciences.com>
> To: "Ralph" <Mandela@myrealbox.com>
> Date: Mon, 31 Oct 2005 21:59:53 -0500
> Subject: RE: Re: Frame-Relay fragmentation
>
> Thanks for the great info, Ralph. Do you have any recommendations on
> the technical details of fragmentation. The doc CD is somewhat limited
> on this subject. Yes, fragmentation is fair game. Even though voice is
> not a part of the R&S exam, surely having the router/switch prepared
> for this, would be a viable test option.
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com
>
>
> -----Original Message-----
> From: Ralph [mailto:Mandela@myrealbox.com]
> Sent: Monday, October 31, 2005 7:36 PM
> Cc: Schulz, Dave; ccielab@groupstudy.com
> Subject: Re: Re: Frame-Relay fragmentation
>
> Dave:
>
> Using a Tc of 10ms is good for voice latency. Calculate the fragment
> size from the Bc value. If its greater than the average size of VOIP
> packets, VOIP should be transmitted unfragmented.
>
> HTH
> Ralph
>
> -----Original Message-----
> From: "Ralph" <Mandela@myrealbox.com>
> To: DSchulz@dpsciences.com
> Date: Mon, 31 Oct 2005 18:48:24 -0500
> Subject: Re: Frame-Relay fragmentation
>
> Hello Dave:
>
> FRF.12 does not discriminate betweeen voice and data. Particularly if
> it's VOIP (layer 3)and fragmentation being layer 2. If the fragment
> size is less than the average size of the VOIP packets they will all
> be fragmented. If the VOIP packets are less than the fragment size,
> just like any other type packet, they will be transmitted without
> being fragmented.
>
> On the other hand, FRF.11C does discriminate between voice and data.
> It does not fragment voice packets regardless of what fragmentation
> size is configured. But if I can recollect properly, FRF.11C is used
> only on DLCIs configured for VoFR, (layer 2). However, this form of
> fragmentation is not recommended for VOIP.
>
> As for the configuration of FRF.12, all you really need is the
> map-class frame-relay fragment command. It's also commonly used with
> the map-class frame-relay fair queue command; Probably can also be
> used with the map-class priority-group command - not very certain.
> After all fragmentation actually occurs at the TxQ.
>
> With Voice not being tested anymore in the Lab, do you think frame
> relay fragmentation is still something to be concerned with?
>
> HTH
> Ralph.
>
>
>
>
>
>
> -----Original Message-----
> From: "Schulz, Dave" <DSchulz@dpsciences.com>
> To: <ccielab@groupstudy.com>
> Date: Mon, 31 Oct 2005 17:04:56 -0500
> Subject: Frame-Relay fragmentation
>
> I was working through the doc CD, where it stated something about the
> FRF.12 inherently allows all voice traffic to pass-through
> unfragmented, while fragmenting the data packets to the specific
> length. So, can I assume that if a lab states to fragment all packets
> above 53 bytes (the default), and allow voice to be
> unfragmented....then you may simply configure "frame-relay fragment"
> command under the specific frame map-class or interface, along with
> the frame-relay traffic-shaping interface command?
>
> I almost want to believe that priority queuing is needed, but am
> confused on which way to go here (sometimes we make things more
> complicated then they really are). Thoughts?
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com >
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:04 GMT-3