Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] Proposal from Jose Morales




This problem can be easily solved by using a derivitive of IEEE 1588 where the source clock is not a prc but a cheap standalone osc. The slave clock can be a disciplined DDS. This protocol and associated circuitry operates in a similar scheme to that shown in Dirceu's previous message. Since the goal here is frequency and not time the need for delay req messages is eliminated.
Michelle and Glenn from Nortel are familiar with this technique...care to comment?

Pat


Jose Morales Barroso <jmb@LMDATA.ES>
Sent by: owner-stds-802-3-re@IEEE.ORG

11/12/2004 12:29
Please respond to
"IEEE 802.3 Residential Ethernet"<stds-802-3-re@IEEE.ORG>

To
STDS-802-3-RE@listserv.ieee.org
cc
Subject
Re: [RE] Proposal from Jose Morales





I know both protocols. They use four octets in the timestamp, but in TCP there are also the echo in a second word. The RTP protocol (RFC 3550) is used in VoIP, videoconference and others. If you use a protocol analyzer, you will see that there are many streaming (audio + video) applications that use TCP. If you need to synchronize TCP flows, it is possible to use the timestamp, and these would be the type of applications more frequent in RE (I think).
 
By the way, I propose to do Voice over Ethernet (VoE) using LLC2 with timestamps. There are VoIP, VoFRL, VToA, VoMPLS, VoADSL, but I have never seen VoE. The best place to do it could be IEEE 802.3. This (802.3 + LLC) would be far better that (802.3 + IP + UDP + RTP). It is only needed a minimum modification in SIP  protocol to support MAC addresses (6 octets) instead of IP (4 octets).
 
Jose
 
----- Original Message -----
From: Michel Ouellette
To: STDS-802-3-RE@listserv.ieee.org
Sent: Friday, November 12, 2004 8:13 PM
Subject: Re: [RE] Proposal from Jose Morales

Do you mean the RTP timestamp (which is mainly used in multimedia applications) or the TCP timestamp option (which is mainly used for round-trip time measurements and protection against TCP segment duplication)?
 
Thanks.
 
 
-----Original Message-----
From:
owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of Jose Morales Barroso
Sent:
Friday, November 12, 2004 1:48 PM
To:
STDS-802-3-RE@listserv.ieee.org
Subject:
[RE] Proposal from Jose Morales

Glenn,
 
I believe that it is very simple to use the LLC to transport timestamp, and contributes to offer compatibility with other systems like 802.11.  Also it would be possible to transport timestamp signals adapting the 802.3 MAC Control.
 
The most important thing is to maintain compatibility with TCP timestamp. Remember that today this protocol is used in many streaming multimedia applications in Internet. With the timestamp mechanism, different TCP flows could be synchronized.
 
In the Ethernet domain, the same will be done with LLC2, which offers the functionalities of TCP, but in a much more efficient way. Thus, the station clock can be used to synchronize applications that run directly on LLC/MAC and those that use TCP/IP. I describe this protocol stacks in the paper that I mention in my previous mail.
 
I agree that in EPON, the MPCP protocol can be adapted to synchronization, but it is not for PP links. Answering to your question, I think that LLC proposal may also be adaptable using 802.3ah MPCP MAC.
 
Jose Morales
 
----- Original Message -----
From: Glenn Algie
To: STDS-802-3-RE@listserv.ieee.org
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