-----
Original Message -----
Sent:Friday,
November 12, 20043: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, 20045: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