Re: [RE] Grand master identifier
John,
It depends on how you measure cost.
I assume that any RE device will support IP- in fact, I would recommend
against any networked device ignoring that requirement. This means that
the devices will also support DHCP and DNS. Furthermore I would
recommend that most devices will also support either TCP or UDP and that
any key device will support HTTP. Given those assumptions, incremental
requirement to support RSVP will be no more than 10's of kbytes of
codespace. A reasonably implemented and appropriately scaled device
(whether end station or hub) should be able to support a standard method
for provisioning at NO INCREMENTAL COST. I would like to see an analysis
disproving this that also demonstrates why a new standard would not
incur equivalent overheads. Remember that the argument that nobody
builds it today is equally applicable to anything new that is proposed.
Regarding your comments - it is absolutely true that no mechanism exists
in 802.3 for either of those requirements. This is because both of those
requirements are met (or otherwise) by the bridge and the system
behavior. Nothing in the definition of a PHY or a fullduplex MAC will
help to meet those requirements (with the exception of PHY latency that
is under discussion in 10GBASE-T). It is entirely specious to suggest
that anything defined at a higher layer (than 802.3) will be too
expensive or not interoperable. There are many things that are very
cheap indeed and interoperate perfectly that are not defined by 802.3 -
although I would recommend against any physical layer network interface
defined by anyone else :-)
Hugh (speaking for myself, and not representative of the views of ITU-T :-)
John Gildred wrote:
> Hi Hugh:
>
> I am not aware of any low cost standardized methods for provisioning,
> admission control, policing and QoS which work together to satisfy
> the requirements of RE. The consumer electronics definition of low
> cost is NO INCREMENTAL COST.
>
> My understanding of the 2 most basic RE requirements:
> 1. We need a low cost way to ensure that the traffic for one
> application does not interfere with the timely delivery of all
> traffic for another application.
> 2. We need a low cost way to ensure a very low max latency (250 usec
> per hop) for all traffic of a specific application.
>
> My comments on current mechanisms for this in 802.3:
> A. There is no mechanism in 802.3 to ensure requirement #2 will be
> met in every case, across various implementations.
> -Overprovisioning cannot provide such a guarantee as more
> applications are added to the network.
> -There is no admission control system for 802.1D priorities.
> Of course, higher layer protocols (Layer 3+) could be used for
> admission control, but at considerable cost and added risk to
> interoperability.
> B. There is no mechanism in 802.3 to ensure requirement #2 will be
> met in every case, across various implementations.
>
>