RE: [RPRWG] temporal ordering requirement
Necdet,
With all due respect, both steering and wrapping could
ensure no-out-of-order frames. I agree this is an issue of
service restore time. Not worrying about the frame-ordering,
both scheme's restore time is faster.
I understand this may/is contentious issue, and since I
have no vested interest at this point, I am not taking any
position. However, the group should be aware of transparent
bridging issues, and prior requirements of 802.
regards,
Yong.
============================================
Yongbum "Yong" Kim Direct (408)922-7502
Technical Director Mobile (408)887-1058
3151 Zanker Road Fax (408)922-7530
San Jose, CA 95134 Main (408)501-7800
ybkim@xxxxxxxxxxxx www.broadcom.com
============================================
-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
Behalf Of Necdet Uzun
Sent: Friday, March 23, 2001 4:25 PM
To: Yongbum Kim
Cc: Dave Brown; tak@xxxxxxxxx; Brown_Dave/SEMI@xxxxxxxxxx;
stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] temporal ordering requirement
Yongkim,
Just to clarify your last point, i.e., out of ordering during protection
event,
neither steering nor wrapping can totally eliminate out of ordering of
packets.
Steering can out of order packets right after protection event as well as
right after
restoration. However, wrapping without steering ensures order of packets
right after
going into wrap, though coming back from wrap may cause out of ordering.
Wrapping then steering can out of order packets in both scenarios.
The issue is not just how bad is the out of ordering of packets but also how
fast you can go into
protection mode, and how scalable the protection scheme is.
Thanks.
Necdet
Yongbum Kim wrote:
> Dear Dave,
>
> The group is in process of voting on objectives
> list @ last and next meeting -- I am hopeful that we separate
> contentious issues from agreeable ones. This issue WILL be
> discussed.
>
> That said, the issue Mike talked about, SRC-DEST must be
> delivered in order, is 802.1 requirement, which also is 802
> architecture requirement. I do not believe this is up for discussion
> (unless the group feels strongly enough to change 802 architecture).
> 802.1D Bridges, most implementations meet this requirement by not
> allowing ANY mis-ordering. 802.1Q bridges do the same within same CoS.
>
> As for mis-ordering during protection event, I look forward to
> further presentation on this matter, addressing fastest protection
> versus allowing mis-ordering, and how one is a more evil than the other.
>
> regards,
>
> Yong.
>
> ============================================
> Yongbum "Yong" Kim Direct (408)922-7502
> Technical Director Mobile (408)887-1058
> 3151 Zanker Road Fax (408)922-7530
> San Jose, CA 95134 Main (408)501-7800
> ybkim@xxxxxxxxxxxx www.broadcom.com
> ============================================
>
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
> Behalf Of Dave Brown
> Sent: Friday, March 23, 2001 10:08 AM
> To: tak@xxxxxxxxx
> Cc: Brown_Dave/SEMI@xxxxxxxxxx; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] temporal ordering requirement
>
> Mike;
>
> I was suggesting we amend our objective (or at least I think we had an
> objective) at the March Plenary, that said we would maintain temporal
> ordering on the ring on a QoS basis. This allows for per QoS queuing at
> each node, and allows for low latency traffic to enter the ring ahead of
> best effort traffic already on the ring. I thought it would be a good
> idea to expand that to a per conversation basis which would allow per
> flow queue implementations (personally I think this is excessive but why
> limit ourselves). Link aggregation 802.3ad had to define a temporal
> ordering requirement, so I thought it would be a good idea to simply use
> theirs.
>
> You bring up another point (which I have been wondering about as well)
> which is link aggregation with RPR rings. We should think about this an
> objective as well.
>
> Dave Brown
>
> tak@xxxxxxxxx wrote:
> >
> > Dave,
> >
> > (with my cisco hat on)
> >
> > 1998 802.1D shows that data frames from the same src/dst pair
> > and with the same priority should not be mis-ordered, but data
> > frames of different priorities or data frames from
> > different src/dst pairs can be re-ordered.
> >
> > I believe the advantages of allowing higher priority traffic
> > to get ahead of lower priority traffic is desirable to
> > keep latency and jitter low.
> >
> > The issue of link aggregation or its equivalent in an RPR setting
> > is a different issue and one worth discussion at some point
> > in the future.
> >
> > mike
> >
> > Dave Brown wrote:
> > >
> > > I suggest we use the same temporal ordering requirement, that link
> > > aggregation uses, for frames on an RPR ring.
> > >
> > > from 2000 802.3
> > >
> > > 1.4.94 Conversation: A set of MAC frames transmitted from one end
> > > station to another, where all of the
> > > MAC frames form an ordered sequence, and where the communicating end
> > > stations require the ordering to
> > > be maintained among the set of MAC frames exchanged. (See IEEE 802.3
> > > Clause 43.)
> > >
> > > Dave.