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

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.