RE: [RPRWG] RPR: packet sequencing between multicast andunicast
Unknown flooding is generally treated as somewhat exception and so may not
be optimized for. As a consequence design may allow for bigger penality to
maintain ordering in unknow packet cases.
Regards,
Devendra Tripathi
CoVisible Solutions Inc.
(formerly VidyaWeb, Inc)
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of William Dai
> Sent: Thursday, June 21, 2001 1:36 PM
> To: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RPR: packet sequencing between multicast andunicast
>
>
>
> What about unknown flooding vs. unicast ?
>
> You need to deal with the same complexity anyway if you
> are serious about ordering issue, unless you don't support
> 802.1D transparent bridging of RPR.
>
>
> William Dai
>
>
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Heng Liao
> Sent: Wednesday, June 20, 2001 11:30 AM
> To: 'stds-802-17@xxxxxxxx'
> Subject: [RPRWG] RPR: packet sequencing between multicast and unicast
>
>
>
> Hi all,
>
> Ethernet multicast: according to 802.1D, packet ordering is based on the
> 3-tuple <source MAC address, destination MAC address, priority>. All
> packets received by a bridge that can be identified by a given tuple must
> not be misordered by the bridge when the packet is retransmitted. There is
> no particular distinction between multicast destination addresses and
> unicast destination addresses. Thus it is permissible to
> arbitrarily reorder
> multicasts with respect to unicasts from the same source, subject
> of course
> to the usual limitations of protocol timers.
>
> For RPR, it would be nice to allow arbitrarily reorder multicasts with
> respect to unicast in a similar way. This can significantly reduce the
> implementation cost of multicast. Basically, it relaxes the requirement of
> instantaneous packet replication (multicast packet needs to be put into
> receive queue and transit queue at the same time). This may be
> easy to do in
> some implementations, it may also be very hard to do in others.
>
>
> - Heng Liao
> PMC-Sierra, Inc.
>
>
>
>
>