RE: [RPRWG] RPR: packet sequencing between multicast and unicast
I concur with Heng on this. Actually {D,S,P} (or in absence or P, only
{D,S}) uniquely define a "stream". As long as we make sure that all packets
of a stream or in order, we should be fine. Given this unicast and multicast
naturally can not belong to one stream and so can be delinked from ordering.
Regards,
Devendra Tripathi
CoVisible Solutions 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 Raj Sharma
> Sent: Wednesday, June 20, 2001 9:51 PM
> To: 'Heng Liao'; 'stds-802-17@xxxxxxxx'
> Subject: RE: [RPRWG] RPR: packet sequencing between multicast and
> unicast
>
>
>
> Heng,
>
> I am not sure I follow your logic of why multicast packets
> can be subjected to reorder. In fact services using multicast
> are more susceptible to reorder (like streaming services).
>
> If a source X transmits to a multicast address Y with a priority P
> then according to your first statement the 3 tuple (X,Y,P) should not
> be reordered. In fact all the "listeners" on multicast address Y
> should see the packets in the same order.
>
> Maybe, I am missing something. Could you please explain more why
> reordering is good and why reordering is permissible?
>
> Thanks.
> raj
>
>
> -----Original Message-----
> From: Heng Liao [mailto:Heng_Liao@xxxxxxxxxxxxxx]
> 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.
>
>