Re: [RE] Proposal from Jose Morales
Dirceu Cavendish,
Its a bit hard to prove something "doesn't" work, particularly
if statistical (vs worst case) numbers are assumed by
the proponent of an alternative.
I experienced this in p802.17, where you could always find
a set of statistics to justify any proposal.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Dirceu Cavendish
>> Sent: Friday, November 12, 2004 9:46 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Proposal from Jose Morales
>>
>>
>> Folks,
>>
>> It is getting clear to me that we need to study various types of Synch
>> schemes, and "run them against" the CE applications we are targeting.
>> Otherwise, we will never be able to lock into a particular solution
>> based on technical arguments - in which case from outsiders we would
>> look like a group trying to standardize a particular solution,
>> regardless the applications...
>>
>> Since many people believe that higher layer (application) schemes can
>> solve the problem, we can start by showing why this isn't so... I would
>> like to put this issue in the agenda for today's meeting, if it is OK
>> with everyone...
>>
>> Rgds to all,
>>
>> Dirceu Cavendish
>> NEC Labs America
>> 10080 North Wolfe Road Suite SW3-350
>> Cupertino, CA 95014
>> Tel: 408-863-6041 Fax: 408-863-6099
>>
>>
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
>> On Behalf Of Jose Morales
>> Sent: Friday, November 12, 2004 2:38 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: [RE] Proposal from Jose Morales
>>
>> All,
>>
>> Dear friends, I would like to propose the following solution:
>>
>> In order to obtain an isochronous network, we can use the following
>> strategies:
>> - Synchronize at physical/802.3 level.
>> This implies to modify all the network elements (switches), and
>> to use
>> new equipment in all the network.
>> - Synchronize at MAC/802.3 level. It can be origin of
>> incompatibilities.
>> - Synchronize in LLC/802.3 level .
>> The perfect place to do this, because it is is transparent to all
>> 802.3
>> network,
>> and will work also over 802.11, 802.15, 802.16, etc.
>>
>> For the synchronization of the network, could be used a technique
>> equivalent to
>> the one employed in 802.5, where all the stations have capacity to do
>> the synch
>> master, but only the active monitor does it, and all the others
>> synchronize with
>> him. Also I suppose that you know the mechanism which guarantees that
>> there is
>> always only one master synch, that would be the station with the lower
>> value in
>> the MAC address.
>>
>> The system that I propose is very simple: The synch master station
>> sends
>> periodically (for example each 20 or 100 milliseconds) a broadcast or
>> multicast
>> 802.3 frame, containing one 802.2 that transports the time stamp (the
>> value of
>> the real time clock). All the isochronous stations can synchronize their
>> clock,
>> compensating the very small jitter that it would take place in the
>> transmission
>> of the consecutive frames.
>>
>> The frame will look like this:
>> (The SAP=27 and 28, as far as I know, are not used in any other
>> application)
>>
>> |DA=Broad/Multicast | SA | LENGTH |
>> |DSAP=27|SSAP=27|UI(03)| TIMESTAMP|
>> |PAD|FCS|
>>
>> Once synchronized all the stations, the isochronous traffic could be
>> sent in
>> multicast with LLC type 1 protocol or in unicast with LLC type 2
>> protocol,
>> including in each frame the time stamp.
>>
>> LLC2 protocol has many advantages, like the error and flow control
>> (end-to-end),
>> the identification of streams by means of P/F bit and that it would
>> make
>> possible the congestion management. Remember that TCP protocol also have
>> the
>> timestamp option, with 4 octes. It will be very useful to define the
>> same size
>> here.
>>
>> The frame LLC2 will look like this:
>>
>> |DA| SA | LENGTH |
>> |DSAP=28|SSAP=28| INFO|N(R)|P/F|N(S)|TIMESTAMP (4 octets)|DATA|FCS|
>>
>>
>> With the system I propose, we have "High quality synchronization
>> services that
>> provides all stations with a low jitter house clock". Now it is only
>> necessary a
>> 802.3 switch that guarantees that "isochronous services can use up to
>> 75% of the
>> link bandwidth, while the remaining is always available to best-effort
>> traffic"
>> and "assign resources for isochronous services".
>>
>> This system is exactly the one that I propose in the manuscript
>> "Universal
>> Ethernet Telecommunications Service: The Convergence of Internet,
>> Broadband and
>> Telephone networks on the IEEE 802 standards". I have sent it to the
>> IEEE
>> Communications Magazine and now is "Under Review", reason why I cannot
>> pass it
>> to the reflector.
>>
>> Comments?
>>
>> Jose Morales Barroso, Ph.D.
>> jmb@ieee.org
>>