Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] protection messages





Leon,

I'm fine with using separate messages.  Someone else had
raised the issue of bandwidth overhead which is why I
suggested piggybacking it on to the Type B fairness 
messages.

I totally agree that we need to have a good explanation 
for the use of Type B's.  Since sending of Type B messages 
has been mandatory from the time the fairness section was 
voted in by the WG, I assume most folks were OK with it a 
few months ago and should still be OK with it.  (Unless 
they weren't paying attention back then - which can happen
when things are moving so fast!)

-Anoop

> -----Original Message-----
> From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
> Sent: Tuesday, May 28, 2002 11:19 AM
> To: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] protection messages
> 
> 
> 
> I think it is better to have special messages rather than piggy back
> unrelated features one over the other. I think that the issue 
> of Type B
> messages must be carefully studied, and I wouldn't like to 
> see an argument
> of the type: We need Type B because it is used for protection.
> 
> The Backoff mechanism does reduce dramatically the amount of 
> processing
> required, since after a very short period the protection 
> messages rate is
> reduced to once per second.
> Leon
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Tuesday, May 28, 2002 5:50 PM
> To: 'Mike Takefman'; jan.van.ruymbeke@xxxxxxxxxxx
> Cc: Anoop Ghanwani; dzhu@xxxxxxxxx; nuzun@xxxxxxxxx; 
> stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] protection messages
> 
> 
> 
> 
> Wow...there's been a lot of discussion on this thread
> over the weekend!
> 
> Anyway, reliable delivery of protection messages is a 
> bigger issue for networks with steering than it is for
> wrapping as noted by Mike.
> 
> We also have to make sure that every station know when
> a protection occurs preferably within 50 msec, but
> even after that it must know (and sooner the better), and
> so I don't quite agree with Leon's argument.
> 
> And getting back to overhead: if bandwidth overhead
> is such a big deal, then why not piggyback the information
> on Type B fairness messages which are being sent anyway?
> Hardware/software can be easily designed to support this.
> If overhead is not a big deal, then why can't we just send
> them as separate messages but at a constant rate?
> 
> The exponential back-off protocol specified currently
> gives us the worst of both worlds.  It has the high
> processing overhead that Mike is concerned at the time
> immediately following the change in protection status,
> and yet it isn't quite as robust as we need it to be.
> 
> -Anoop
> 
> 
> > -----Original Message-----
> > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > Sent: Tuesday, May 28, 2002 4:56 AM
> > To: jan.van.ruymbeke@xxxxxxxxxxx
> > Cc: anoop@xxxxxxxxxxxxxx; dzhu@xxxxxxxxx; nuzun@xxxxxxxxx;
> > stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] protection messages
> > 
> > 
> > Jan,
> > 
> > A certain company (whom I work for) can easily hit the
> > 50 ms time even for large rings with a message based
> > scheme. Of course since we do wrapping, the messages
> > only have to flow between the two adjacent nodes 
> > to protect the ring.
> > 
> > That being said, I am sure the companies who have
> > implemented steering will assure you that they can 
> > hit 50 ms as well. 
> > 
> > Do you have actual proof that it cannot be done, 
> > because that would be quite interesting to see.
> > 
> > mike
> > 
> > jan.van.ruymbeke@xxxxxxxxxxx wrote:
> > > 
> > > Hello,
> > > By accident I had a similar discussion about ATM OAM 
> > (I.610) with SDH people.  The situation is similar and so is 
> > the solution :
> > > -forget 50 ms restoration if you rely only on packet messages;
> > > -use physical layer indications (LOS, AIS, ...)
> > > 
> > > regards
> > > Jan Van Ruymbeke
> > > Belgacom Advanced Networks & Systems / Network Innovation & 
> > Strategy / Strategy Architecture & Economics of Core network.
> > > Koning Albert II laan 27, 1030 Brussel, Belgium
> > > 
> > > T:    32 2 202 45 80
> > > GSM:  32 476 28 70 25
> > > 
> > > -----Original Message-----
> > > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > > Sent: 27 May 2002 21:27
> > > To: Anoop Ghanwani
> > > Cc: 'Daniel Zhu'; 'Necdet Uzun'; 'stds-802-17@xxxxxxxx'
> > > Subject: Re: [RPRWG] protection messages
> > > 
> > > Only partially joking, many reliable protocols run over
> > > ethernet networks.
> > > 
> > > I agree that we need to reliably have 50 ms reaction
> > > times to faults. It is not clear to me that sending protection
> > > information every 10ms in non fault conditions is a good
> > > idea.
> > > 
> > > cheers,
> > > 
> > > mike
> > > 
> > > Anoop Ghanwani wrote:
> > > >
> > > > Mike,
> > > >
> > > > CSMA/CD is non-deterministic.  Anyway, I assume you were
> > > > joking (hence the chuckle?).
> > > >
> > > > -Anoop
> > > >
> > > > > -----Original Message-----
> > > > > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > > > > Sent: Friday, May 24, 2002 12:47 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: 'Daniel Zhu'; 'Necdet Uzun'; 'stds-802-17@xxxxxxxx'
> > > > > Subject: Re: [RPRWG] protection messages
> > > > >
> > > > >
> > > > > CSMA-CD comes to mind.
> > > > >
> > > > > he he he,
> > > > >
> > > > > mike
> > > > >
> > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > Daniel,
> > > > > >
> > > > > > The exponential backoff is what I don't like.  I would
> > > > > > rather see it sent at a steady rate, or just transmitted
> > > > > > reliably so that there is no constant refresh.
> > > > > >
> > > > > > Are there any protocols that use a similar exponential
> > > > > > backoff to guarantee timely delivery?
> > > > > >
> > > > > > -Anoop
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Daniel Zhu [mailto:dzhu@xxxxxxxxx]
> > > > > > > Sent: Friday, May 24, 2002 11:19 AM
> > > > > > > To: Anoop Ghanwani
> > > > > > > Cc: 'Necdet Uzun'; 'stds-802-17@xxxxxxxx'
> > > > > > > Subject: Re: [RPRWG] protection messages
> > > > > > >
> > > > > > >
> > > > > > > Anoop,
> > > > > > >
> > > > > > > I believe, in the current RPR draft, protection 
> message will
> > > > > > > be broadcast periodically every 1 second in steady state.
> > > > > > > During period of changes, protection message will be sent
> > > > > > > much more frequently with a back off scheme up to 
> 1 second.
> > > > > > >
> > > > > > > Is there something missing here?
> > > > > > >
> > > > > > > Daniel
> > > > > > >
> > > > > > > Anoop Ghanwani wrote:
> > > > > > >
> > > > > > > > Necdet,
> > > > > > > >
> > > > > > > > Thanks for pointing this out.  Per the current draft,
> > > > > > > > Type B's aren't sent that often (1/10-th the rate of
> > > > > > > > Type A's) and so it's possible that they can be
> > > > > > > > sourced in software.
> > > > > > > >
> > > > > > > > Anyway, let's assume for now that we absolutely had
> > > > > > > > to keep protection and fairness separate.  How would
> > > > > > > > you recommend that we address the issue of timely
> > > > > > > > delivery of the protection notification message?
> > > > > > > >
> > > > > > > > I see only 2 possibilties:
> > > > > > > >
> > > > > > > > - Periodic link status broadcasts (regardless of whether
> > > > > > > >   the link is up or not).
> > > > > > > >
> > > > > > > > - Hop-by-hop reliable broadcast when the link status
> > > > > > > >   changes.
> > > > > > > >
> > > > > > > > I'm OK with either.  Can you think of any other ways
> > > > > > > > to do this?
> > > > > > > >
> > > > > > > > -Anoop
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> > > > > > > > > Sent: Thursday, May 23, 2002 7:13 PM
> > > > > > > > > To: Anoop Ghanwani
> > > > > > > > > Cc: 'stds-802-17@xxxxxxxx'
> > > > > > > > > Subject: Re: [RPRWG] protection messages
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Anoop,
> > > > > > > > >
> > > > > > > > > Type B fairness message is generated by Fairness
> > > > > Control Unit (in
> > > > > > > > > hardware) and sent to client, whereas 
> > protection messages are
> > > > > > > > > generated
> > > > > > > > > MAC control unit (which is implemented in 
> software) and
> > > > > > > multicast to
> > > > > > > > > other MACs' control units. Combining them is the worst
> > > > > > > that can happen
> > > > > > > > > (HW vs SW, microsecond time frame vs millisecond time
> > > > > frame etc.)
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > >
> > > > > > > > > Necdet
> > > > > > > > >
> > > > > > > > > Anoop Ghanwani wrote:
> > > > > > > > >
> > > > > > > > > > I had a comment that expressed concern about 
> > the delivery
> > > > > > > > > > of protection notification messages.
> > > > > > > > > >
> > > > > > > > > > The way things are defined in D0.2, the messages are
> > > > > > > > > > neither reliable nor periodic.  There are no
> > > > > > > > > > acknowledgments, so we are never sure that all nodes
> > > > > > > > > > have seen the protection notification message.
> > > > > > > > > > Sending special protection messages periodically
> > > > > > > > > > increases the overhead (but even that is not 
> > specified).
> > > > > > > > > > Why can't we piggyback the protection notification
> > > > > > > > > > onto Type B fairness messages since they 
> are required
> > > > > > > > > > to be sent frequently in any case (typically more
> > > > > > > > > > frequently than 1 msec)?
> > > > > > > > > >
> > > > > > > > > > The ad hoc's response to my comment says 
> that Type B's
> > > > > > > > > > are optional.  This is not true.  Sending of 
> > both Type A
> > > > > > > > > > and Type B messages is mandatory per D0.2 and 
> > there have
> > > > > > > > > > been no comments to change that behavior.
> > > > > > > > > >
> > > > > > > > > > -Anoop
> > > > > > > > > > --
> > > > > > > > > > Anoop Ghanwani - Lantern Communications - 
> 408-521-6707
> > > > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > 
> > > --
> > > 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
> > > 
> > > **** DISCLAIMER ****
> > > "This e-mail and any attachments thereto may contain information
> > > which is confidential and/or protected by intellectual property
> > > rights and are intended for the sole use of the 
> > recipient(s) named above.
> > > Any use of the information contained herein (including, but 
> > not limited to,
> > > total or partial reproduction, communication or 
> > distribution in any form)
> > > by persons other than the designated recipient(s) is prohibited.
> > > If you have received this e-mail in error, please notify 
> > the sender either
> > > by telephone or by e-mail and delete the material from 
> any computer.
> > > Thank you for your cooperation."
> > 
> > -- 
> > 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
> > 
>