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.