----- Original Message -----
Sent: Friday, November 12, 2004 4:57
PM
Subject: Re: [RE] Proposal from Jose
Morales
Jose, I disagree on the 802.3 MAC issue you mention. I agree
with you on the disruptive PHY level impacts and I don't want to go there as
well.
Why not leverage/adapt the now existing 802.3 MAC Control
signals that were just added to annex as part of 802.3ah?
The "MPCP" control protocol can be "adapted" for full duplex
isochronous ability.
Defining the adaptations to MPCP for RES-E should be an
objective for the PAR.
You may find your LLC proposal may be adaptable using
802.3ah MPCP MAC control signals. I would like to hear your
response.
Cheers,
Glenn Algie
-----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