RE: [RPRWG] temporal ordering requirement
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.