Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
David,
All due respect, I disagree with respect to your statement below. Please see
my comments below.
Thanks.
Necdet
David James wrote:
> Mike,
>
> With respect to:
>
> > an advantage of wrapping over steering is
> > that since the decision is local it can be
> > done quicker and there is a much lower
> > degree of packet loss...
>
> This is only true if the wrapped frames are not discarded
> before the distribution of new topology information,
No, you do not need the topology information to disable the TTL decrement
operation for the packets with the wrong ring ID. What you need is to pass a
single protection switching message to all nodes from the node that gets
wrapped. Consider this, a node detects a fault and determines to go into wrap
and sends a broadcast protection message to all other nodes and waits for 1ms
(processing time of a protection message: disable TTL decrement if RI does
not match) then wraps the attachment points at packet boundary. As the
protection packets have the highest priority in the transit path, all nodes
disable the TTL decrement for incorrect RI . Similarly whenever the same node
discovers the recovery of the fault, it first generates a protection message
with the appropriate recovery info and waits for 1 ms and unwraps.
No, packet loss other than the 2 times 1ms waiting time.
Anything wrong with this?
>
> which is the case with the selective-no-decrement TTL
> rules being proposed by some(:>).
>
> DVJ
>
> David V. James, PhD
> Chief Architect
> Network Processing Solutions
> Data Communications Division
> Cypress Semiconductor, Bldg #3
> 3901 North First Street
> San Jose, CA 95134-1599
> Work: +1.408.545.7560
> Cell: +1.650.954.6906
> Fax: +1.408.456.1962
> Work: djz@xxxxxxxxxxx
> Base: dvj@xxxxxxxxxxxx
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Mike Takefman
> > Sent: Monday, June 24, 2002 6:51 PM
> > To: Anoop Ghanwani
> > Cc: 'djz@xxxxxxxxxxx '; 'stds-802-17@xxxxxxxx '
> > Subject: Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
> >
> >
> >
> > Anoop,
> >
> > an advantage of wrapping over steering is
> > that since the decision is local it can be
> > done quicker and there is a much lower
> > degree of packet loss, as all of the
> > packets in flight towards the failed
> > span can be wrapped.
> >
> > Service providers have presented to the WG
> > that the lower level of packet loss in wrap
> > was a key requirement for them. The question
> > is what SLAs are relevant to service providers.
> >
> > Based on all of the input received at the WG,
> > both steer and wrap were accomdated to allow
> > vendors to meet the needs of their customers.
> >
> > cheers,
> >
> > mike
> >
> > Anoop Ghanwani wrote:
> > >
> > > > With regard to your last question / comment.
> > > > In wrapping, the adjacent nodes can react immediately if
> > > > they have the highest priority failure. Thereby
> > > > wrapping will have quicker reaction times to
> > > > steering. The need to broadcast in the wrapping
> > > > case is to support the hierarchy. If no hierarchy
> > > > was supported, then the decision could be completely
> > > > local. In this case I would still argue that a
> > > > broadcast of the event was useful for 2 reasons.
> > > > 1) The same algorithm supports steering which is
> > > > the default mode
> > > > 2) The packets that are trapped on the wrong ring
> > > > will get killed.
> > >
> > > Mike,
> > >
> > > This tells me why all nodes need to know about a
> > > failure even when wrapping. But now that all nodes
> > > need to know about the failure, why do I need
> > > wrapping?
> > >
> > > This is a serious question. In the past, I've
> > > always answered it by saying that with wrapping,
> > > only nodes local to the fault need to know about
> > > it. But if that's not the case, then I'll be
> > > stumped every time this question comes up.
> > > If steering can be done within 50 msec, is
> > > doing it any faster with wrapping worth the
> > > bandwidth overhead?
> > >
> > > -Anoop
> >
> > --
> > Michael Takefman tak@xxxxxxxxx
> > Manager of Engineering, Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-254-3399 fax: 613-254-4867
> >