Cell Relay Archive

[anouch_atm@yahoo.com (anouch)]

"Marc Wehmeyer" <marc@interquest.de> wrote in message news:<9thcj8$cba$1@guardian.f.de.gatel.net>...
> Hi, I'm new to the group and have a question that seems very easy to solve
> theoretically but hard to produce on a live network.  I've posed this
> problem to the switch manufacturer's engineers, but have grown impatient in
> waiting for a reply, and after reading the posts from some individuals on
> this board, thought you might have some insight on the solution.
> 
> First, the network layout....
> For sake of simplicity, lets say I have three ATM switches (which just
> happen to be Marconi ASX-1200's) with OC-12 netmods inter-connecting them
> all into a ring.  Port 1A1 on Switch A goes to Port 1B1 of Switch B, And
> Port 1B1 of Switch A goes to Port 1B1 of Switch C.  Switches B and C are
> connected Via ports 1A1 to each other. Edge devices provide the connectivity
> to the core switches via OC-3 interfaces.  A nice little ring, with
> alternate paths for traffic in the event of a Ditch-Witch gone ary over my
> precious fiber.
> 
> Next, the traffic over said network....
> I have three types of traffic. Mission-Critical, Priority, and Routine.
> Sounds simple, right? CBR, rt/nrtVBR, and UBR/ABR. But there's a
> catch...always is eh?  The MAJORITY of all three types of circuits are CBR.
> Why? Well, I work for the government......we have a slightly different level
> of paranoia than your average global company - we value our information
> superiority (Read security) over the costs involved, hence we have hardware
> encryption between the vast majority of these links, requiring these
> circuits not blessed with the advent of ATM-Level encryption to handle the
> encryption on the serial level...requiring..guess what..a CBR circuit that
> has a steady bitrate to maintain crypto "sync" between the ingress and
> egress points.
> 
> Now, the "problem"
> SVCs were set up on the majority of these circuits during their provisioning
> hoping to keep said technician's beeper from going off at the most
> unfortunate hour due to loss of a primary link between any two switches.
> The average traffic between Switches A, B, and C has become around
> 400mbits/s per link...that's around 400mbits/s destined from Switch A to B,
> A to C, and B to C.  Remember the OC-12 backbone links between each
> switch....max rate of somewhere near 600mbits/s.  Assuming (correctly) that
> the SVCs created a link over the direct link between one switch to the other
> instead of traveling through another switch to reach it's destination, we
> run into the problem that if one link goes down, we have about 800mbits/s
> worth of traffic trying to go down ~600mbits/s worth of bandwidth.
> 
> "Theoretical Solution"
> When provisioning these CBR SVC's, the technician has the ability to assign
> "Priorities" from 1 to 100  to each SVC.  Sample command line - SPVCC PP new
> 1 1C4 6 160 <destnsap> 6 160 <fwdupc> <backupc> PRIORITY 1
> 
> So, I create a scheme.......Mission Critical Traffic, Priority 1.  Priority
> Traffic, Priority 34.  Routine, Priority 67.  In the event of a backbone
> outage, I'm hoping my Priority 1 will PRE-EMPT everything else until all
> Priority 1 circuits have initiated their calls and then start filling in the
> available bandwidth with Priority 34, and then my Routine 67 traffic.
> 
> "Real-World Test Results"
> On my training network, I install two OC-3 links between two switches.  I
> then create two 100mbit/s SVC's, FORCING the two switches to establish them
> over seperate links.  I provision one circuit with a "Priority" of 1, and
> the other with 34.  Then I determine which link contains the "Superior"
> Priority 1, and unplug the fiber.  The result?
> 
> SVC 2, priority 34 - Status - UP
> SVC1, priority 1 - Status - DOWN
> 
> What gives?  I told the circuits at provisioning time which one I wanted to
> have priority.
> 
> Conclusion...?!
> In the Civilian sector,  if you lose your high-profile customer's links for
> an extended period of time, those customers might move on, your boss might
> blame you to save his @$$, and you get fired.
> 
> In my situation, if I lose my mission-critical circuits links for an
> extended period of time, a couple of things might occur: A carefully devised
> strategy might not succeed, HIGH-DOLLAR equipment might get destroyed, or
> worst-case people will lose their lives.  THEN I have to deal with my boss
> saving his @$$. But I don't get fired....hm.
> 
> There HAS to be a way that I can specify, even at the CBR level, which
> circuits have priority over the other.  This is ATM, right? Where QoS is the
> driving factor to squelch the LAN weenies from their vision of throwing
> bigger pipes at the problem to solve it? If it helps, this is an
> entirely-Marconi ATM core.  Yea, their stock sucks, but I'd still rather
> take a bullet in the chest than make this work with any other
> solution...especially cisco.....call me "biased".
> 
> 
> - GI in need

Hi Marc,

If I have understood your explanations, the problem is that the
connections' priority doesn't work on your Marconi switches.
Well, first of all I don't think in standard PNNI there is any
holding/setup priority support. These features exist in MPLS (with
RSVP/LDP) but not in ATM PNNI, so your Marconi switch does it in a
proprietary way. Having no idea how your switch works, I can only
suggest you another way to obtain the same result maybe with some
other side effects.

You have two 600 Mbps links. On each link you have 400 Mbps of traffic
composed of high priority traffic and low priority traffic. What you
want is in case of a link crash to reroute all your traffic to the
other one. But since the sum of all your traffic (800 Mbps) exceeds
the link bandwidth, you would like to reroute first the high priority
traffic, and then if there is any bandwidth left, to reroute as many
low priority as possible. And the problem is that the Marconi bug
prevents you to prioritize between high and low priority VCs.

My suggestion, as a workaround is to overbook your link capacity to
200% i.e. each of your link has now 1200 Mbps instead of 600 Mbps.
When a link goes down, the CAC function on the other link, having 800
Mbps unused (200Mbps real left + 600Mbps virtual as a result of
overbooking), lets you reroute ALL your connections (high as well as
low priority) from the failed link to the other one. Now you'll have
all your connections up but obviously if all the connections still
send traffic at the same rate, you'll have some bandwidth shortage
since the real bandwidth is no more than 600 Mbps.

Here, your link scheduler will do the job for you. I suppose you have
previousely configured your high priority VCs as having high priority
traffic e.g. CBR/rt-VBR and your low priority VCs mapped to low
priority traffic e.g. nrt-VBR/UBR/ABR. The result is that your
scheduler prevents your low priority VCs/traffic from using the link
since it has now more high priority traffic to serve. Actually you are
forcing some starvation i.e. there will be no traffic on some low
priority VCs even if they are rerouted and up. But you have to make
sure that precisely there is no mechanism against starvation on any of
your link schedulers. Usually, these mechanisms are to make sure that
low priority VCs will have some small percentage of bandwidth anyway
under any circumstances, so they will not starve. So turn it off !

I don't know all the side effects of this technic but one thing is
sure : you must control the amount of  high priority traffic on any of
your link. The sum of high priority traffic on the two links must not
be more than the capacity of one link. For example, out of 400 Mbps of
traffic, you can't have 350 Mbps of high priority traffic, because in
case of link failure you'll have to support 700 Mbps of high priority
traffic in a 600 Mbps link. In this case you'll have some (random)
high priority VCs refused by CAC to be established. But I suppose you
already have taken care of this!

A working example would be:
link1 and link2 : hi priority traffic=200Mbps, Low priority
traffic=200Mbps
link1 goes down
link1: 0 Mbps
link2: hi priority traffic = 200+200=400Mbps, Low priority
traffic=200Mbps
Here, all the low priority VCs on link1 will be rerouted to link2
(just as all the hi priority VCs) since the CAC has enough bandwidth
left but in reality, they will dynamically be refused (by the
scheduler) to access the link which has only 600 Mbps of real
bandwidth.

In another example, if you have 300 Mbps of hi priority traffic and
100 Mbps of low priority traffic on each link and link1 goes down,
then all the VCs from link1 will be rerouted to link2. Here, even the
link2's low priority VCs will be starved.

Hope this helps your boss' @$$
Anouch