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