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

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