----- Original Message -----
Sent: Friday, November
12, 2004 3:17 PM
Subject: Re: [RE]
Proposal from Jose Morales
Jose,
1. Can you describe your definition of
synchronization. Are you referring to time synchronization, frequency
synchronization and/or phase synchronization, or something other form of
synchronization?
In an isochronous system,
all the clocks of the stations "runs" at the same speed. It is very
different in the plesiochronous (like PDH) or synchronous (like SDH) systems.
The term "timestamp" means time synch.
2. Can you provide numbers that explain your following
statement: "High quality synchronization services that provides all
stations with a low jitter house clock".
I copied the phrase from
the objectives of RE (for that reason it is between commas).
In RE, the Ethernet domain can be extended about 2 km (it is a LAN, not a WAN).
The speed of light in copper/fiber is 200.000 km/s. If the network is not
congested (if it is in congestion nothing will work) the delay introduced by
the switches in the timestamps is very low. Then, all the stations will have
its clocks running isochronously at the same speed. The variation produced by
jitter, can be compensated in the receivers discarding the timestamps that
arrive delayed. Sending 20 per second, the synchronization can be very precise,
depending on the precision of the station's clock.
3. Can you also share the applications/services for RE
and their performance levels (in terms of required accuracy/stability, ppm/ppb,
etc.) and the network impairments you think that could affect the performance
levels.
In my previous response
to Glenn Algie I have made reference to the applications based on TCP/IP and
LLC/MAC. The last ones allow much greater efficiency, in special in the
servers. The key of the good operation in the network is to avoid the
congestion. The LLC2 protocol will be controlled from the network nodes to
avoid congestion. This can't be done with TCP, that also collaborates with the
SS/CA, but only end to end.
4. Can you describe the use of the timestamp, how it
is generated, transported and applied.
The master clock copies
the 32 bits of its clock in the timestamp field, then send it via MAC control
or LLC1 frames in broad/multicast. The station adjust its clock to the
value received. As the frames are going to have delay variations, it is
necessary to apply some type of adjustment (PLL) based on the received values
to minimize the jitter.
Thanks
- Michel
-----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 5: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