Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
how can Data get priority over voice in PP7400
- Thread starter leomavv
- Start date
Sorry about the delay answering you. Yes you can get a Frame Relay (FR) service to remain up in the situation you describe. The easiest way is probably to adjust the Maximum percentage of both trunks that voice (Path Oriented Routing Service, or PORS, including BTDS) traffic can take on that trunk. If you have a 2Mbps trunk with, say a 1Mbps FR DLCI but enough voice etc traffic to 'bump' this DLCI, then set the attribute MaxReservedBwOut under the TRK/xxx PA component to something less than 50% (default). This maximum limit is the percentage of bandwidth that PORS traffic can take on that trunk - leaving DPRS (Dynamic Packet Routing Service) traffic such as FR and control traffic like IPIFR/IPIVC to take up the rest. Just make sure that the percentage you set, when subtracted from 100% leaves enough bandwidth for your FR DLCI.
Hope that helps. I'm happy to discuss further if I've made incorrect assumptions about your connections or the situation you describe.
Hope that helps. I'm happy to discuss further if I've made incorrect assumptions about your connections or the situation you describe.
- Thread starter
- #3
In 'normal' use, the PORS limit set in the "trk pa maxresevedbwout" (mrbwout) WILL restrict the PORS traffic reservations to 70%. Note, though that this is NOT operationally enforced - the passport does not monitor over, say, each 1 second interval that only 70% of traffic is PORS traffic! The key word in the first sentence above is "reservations" - you must make sure that your PORS traffic streams (voice services, BTDS's etc) have their "PLC requiredtx(/rx)bandwidth" configured correctly. For instance, on a 1Mbps link, if you configured your Frame Relay connection (at, say 256kbps CIR and 0bps EIR) and then also configured 30 BTDS services at 100kbps each (obviously way too many to all be supported over this one 1Mbps trunk), what would happen? If your mrbwout is 70% AND you've correctly configured your BTDS's requiredtxbandwidth (and rx) at 100kbps, then:
1) Your frame relay would initally be running...
2) The first of the BTDS services would reserve 100kbps across the trunk from the 700kbps (70% of 1000kbps) and begin service, still leaving enough bandwidth for the FR...
3) The second, third, fourth, etc up to the seventh BTDS would reserve more bandwidth from the PORS allocation of (initially) 700kbps, and each would begin running, still leaving the FR up...
4) The eighth (and following) BTDS/s would try to reserve 100kbps of PORS bandwidth, and fail, because none is left from the 70% allocated, so the subsequent BTDS services would not come up. The FR and the first 7 BTDS's would function correctly.
Now consider the above scenario with only a slight difference where you INCORRECTLY set the requiredtxbandwidth to, say, 10kbps (instead of 100kbps)! Going through the timeline again:
1) Your frame relay would initally be running...
2) The first of the BTDS services would reserve 10kbps across the trunk from the 700kbps and begin service *AT 100kbps* - even though you only 'reserved' 10kbps! This still leaves enough bandwidth for the FR...
3) The second, third, etc up to ALL 30 (!) of your BTDS services would successfully reserve 10kbps each of PORS bandwidth, and all would be admitted across the trunk and your Frame Relay service would STILL NOT GET BUMPED! Obviously, though, since each of the 30 BTDS's is actually trying to pass 100kbps (=3Mbps of traffic) across the 1Mbps link, ALL services including FR would run very badly due to the extreme congestion.
The point of these two scenarios is to demonstrate that you can 'fool' the bandwidth allocation mechanisms of PORS services so that you can deliberately oversubscribe, or undersubscribe, if you wish. If you get the bandwidth reservation right, you should be able to set your mrbwout so that you never accidentally bump FR services etc.
So to directly answer your question, if you set the 'requiredtx(/rx)bandwidth' correctly for your PORS services, then you should NOT be able to use the extra 30%. Trunks with mixed PORS and DPRS traffic are usually engineered so that you cater for all of the PORS traffic you may need, and leave the rest for DPRS, not the other way around.
Sorry about the really long reply :-( Have fun!
1) Your frame relay would initally be running...
2) The first of the BTDS services would reserve 100kbps across the trunk from the 700kbps (70% of 1000kbps) and begin service, still leaving enough bandwidth for the FR...
3) The second, third, fourth, etc up to the seventh BTDS would reserve more bandwidth from the PORS allocation of (initially) 700kbps, and each would begin running, still leaving the FR up...
4) The eighth (and following) BTDS/s would try to reserve 100kbps of PORS bandwidth, and fail, because none is left from the 70% allocated, so the subsequent BTDS services would not come up. The FR and the first 7 BTDS's would function correctly.
Now consider the above scenario with only a slight difference where you INCORRECTLY set the requiredtxbandwidth to, say, 10kbps (instead of 100kbps)! Going through the timeline again:
1) Your frame relay would initally be running...
2) The first of the BTDS services would reserve 10kbps across the trunk from the 700kbps and begin service *AT 100kbps* - even though you only 'reserved' 10kbps! This still leaves enough bandwidth for the FR...
3) The second, third, etc up to ALL 30 (!) of your BTDS services would successfully reserve 10kbps each of PORS bandwidth, and all would be admitted across the trunk and your Frame Relay service would STILL NOT GET BUMPED! Obviously, though, since each of the 30 BTDS's is actually trying to pass 100kbps (=3Mbps of traffic) across the 1Mbps link, ALL services including FR would run very badly due to the extreme congestion.
The point of these two scenarios is to demonstrate that you can 'fool' the bandwidth allocation mechanisms of PORS services so that you can deliberately oversubscribe, or undersubscribe, if you wish. If you get the bandwidth reservation right, you should be able to set your mrbwout so that you never accidentally bump FR services etc.
So to directly answer your question, if you set the 'requiredtx(/rx)bandwidth' correctly for your PORS services, then you should NOT be able to use the extra 30%. Trunks with mixed PORS and DPRS traffic are usually engineered so that you cater for all of the PORS traffic you may need, and leave the rest for DPRS, not the other way around.
Sorry about the really long reply :-( Have fun!
Cheeseontoast
Technical User
When setting up the following use the following.
BTDS @ 44 BTDS CS + 13% Tx, Rx BW on PLC
BTDS @ 84 BTDS cs + 8% Tx, Rx Bw on Plc
At 64K Call Assume 74K Tx, Rx BW on Plc (Auto Assigned)
At 8K Call Assume 14K Tx, Rx BW on Plc (auto Assigned)
These differ slightly on Tx or Rx.
to limit the voice calls allocated to the Trk limit either the PA Max Res BW, or the number or Rx VSR Svs components on the remote component.
Or use ATM with VCI and VPI trunks are per service category.
Cheese
BTDS @ 44 BTDS CS + 13% Tx, Rx BW on PLC
BTDS @ 84 BTDS cs + 8% Tx, Rx Bw on Plc
At 64K Call Assume 74K Tx, Rx BW on Plc (Auto Assigned)
At 8K Call Assume 14K Tx, Rx BW on Plc (auto Assigned)
These differ slightly on Tx or Rx.
to limit the voice calls allocated to the Trk limit either the PA Max Res BW, or the number or Rx VSR Svs components on the remote component.
Or use ATM with VCI and VPI trunks are per service category.
Cheese
- Thread starter
- #6
Hi cheese,
What I got formyour reply is if I use g729at8 compression then too in at the time user is conversating the banwidth used will be 14K. if we consider less while engineering then there will be trouble when all the channels are used.
and second thing I got is if we set Maxreserve BW to 70% I will only be able to use 700KB out of 1 MB link and rest 300KB will be used by data. and also otherwise i.e data will only be able to use 300Kbs also if there is bandwidth free in 700Kb.
MAvvy
What I got formyour reply is if I use g729at8 compression then too in at the time user is conversating the banwidth used will be 14K. if we consider less while engineering then there will be trouble when all the channels are used.
and second thing I got is if we set Maxreserve BW to 70% I will only be able to use 700KB out of 1 MB link and rest 300KB will be used by data. and also otherwise i.e data will only be able to use 300Kbs also if there is bandwidth free in 700Kb.
MAvvy
Cheeseontoast
Technical User
Yep that right it has to do with the Pors overhead. The user may see a BW of 8k but cell switching PORS requires more this. It true of any DPRS traffic. As I said use the values of BW I quoted for trunk planning and you wont go far wrong but remember that a pors voice request attempt to set up 74K @ 64K and as such if there were 128K available BW then only 1 call would set up. Its not well documented in the NTP's.
If you using BTDS increase the cell size to economize on overhead but be careful when putting more than 70% BTDS on trk.
Also data can use any available BW and is not restricted to the amount left by the PA. If its there data can use it dynamically.
Limit Voice by cutting down VSR svs components or the PA component.
Bye
If you using BTDS increase the cell size to economize on overhead but be careful when putting more than 70% BTDS on trk.
Also data can use any available BW and is not restricted to the amount left by the PA. If its there data can use it dynamically.
Limit Voice by cutting down VSR svs components or the PA component.
Bye
- Status
Similar threads
- Locked
- Question
- Locked
- Question
