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

Re: [RPRWG] temporal ordering requirement




Mike Takefman wrote:

> Dave,
>
> (with my cisco hat on)
>

Mike:

You are as much of a technical participant as the rest of us are, so I
guess you don't need to keep changing hats (between Cisco & RPR) - it
messes up hair unnecessarily :-)

We're discussing here as technical individuals; and we all value your
thoughts on issues and truly appreciate your active participation.

Best regards,
Pankaj

> 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.