From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Tue Oct 04 2005 - 17:14:18 GMT-3
Thanks for the reply Victor, however it makes me think that my first post was not clear enough.
I do not need examples of these technologies. I also do not think that one configuration example covers all the things listed, as they are (with one exception) mutually exclusive.
I was looking for additional suggestions on how prioritization of voice is configured on frame DLCIs.
One thing I did not list (that I think may be off the exam now as dial peers are not included) is the VoFR option when voice is encapsulated cirectly on to a DLCI with a different CID value, so that voice packets larger than the fragmentation size are not fragmented.
Chris
Victor Cappuccio <cvictor@protokolgroup.com> wrote:
A good example of this would be
!
map-class frame-relay frts_R6
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
no frame-relay adaptive-shaping
frame-relay fair-queue
frame-relay fragment 80 (CIR / 800)
frame-relay ip rtp priority 16384 16383 48 (Maybe you can use a
service-policy to match voice traffic using NBAR)
An example appliend to a Multipoint FR Interface would be..
interface Serial4/0
ip address 136.10.100.6 255.255.255.224
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay map ip 136.10.100.2 601 broadcast
frame-relay map ip 136.10.100.5 601 broadcast
frame-relay map ip 136.10.100.6 601
frame-relay interface-dlci 601
class frts_R6
no frame-relay inverse-arp
This Example is very detallied in IPExpert WB7 Lab 36!
HTH
Victor
PS: Cris Thanks for the Shape Average Link
Chris Lewis wrote:
>All:
>
>I am aware of the following options for prioritizing voice traffic over a frame relay DLCI. Does this look complete, or can anyone add to it?
>
>1. Creating a separate high priority queue on the interface
>This requires FRF.12 (fragment in the map-class).Data packets larger than the packet size specified in the frame-relay fragment command are first enqueued to a WFQ subqueue, whereas the smaller packest go to the high priority queue. They are then dequeued and fragmented. After fragmentation, the first segment is transmitted. The remaining segments wait for the next available transmission time for that VC, as determined by the shaping algorithm. At this point, small voice packets and fragmented data packets are interleaved from other PVCs. With this interface level queueing mechanism, small data packest also get in to the priority queue on the interface if they are smaller than the fragment size.
>2. This can be enhanced by adding frame-relay ip rtp priority. KNown as VoIPoFR, this classifies VoIP packets by matching on the RTP UDP port range defined in a Frame Relay map-class. All RTP traffic within this port range is enqueued to a priority queue for the VC. In addition, voice packets go into the high priority queue at the interface level. All other packets go into the non-priority queue at the interface level.
>3. The generic form of using MQC to identify voice traffic, then using a policy-map to give this traffic priority treatment and applying the service-policy to a class for the DLCI
>4. PIPQ configured on the interface using the interface-queue priority command and assigning a complete DLCI to the priority queue in its map-class, this of course requires one to dedicate voice to a specific DLCI.
>5. Using PPP to fragment and interleave, which is pretty much like F=plain FRF.12 and assumes that packet size is enough of a differentiator to separate voice and data packets.
>
>Chris
>
>
>---------------------------------
>Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3