Re: [RE] Proposal from Jose Morales
Glenn,
I know that "Both the OLT and the ONU have 32-bit counters that increment every
16 ns.
These counters provide a local time stamp. When either device transmits an
MPCPDU, it maps its counter value into the timestamp field." Remember that I was
in the Balloting Sponsors of 802.3ah and I have revised the 680 pages of the
document.
From my point of view, there are two reasons to prefer LLC or 802.3 Control to
transport the clock timestamps:
- The MPCP timestamps transport counters for the operation of OLT and ONU. Those
devices are no terminals where the applications run, and in my proposal, the
master clock must be in a terminal to send the timestamps to the rest of
terminals to synchronize its clocks.
- If they were even possible to use it to synchronize the clocks, would do the
EPON operation different to rest of Ethernet configurations, adding an
unnecessary complexity to the system.
Anyway, I only want to contribute with my humble opinion, based in my
experience, that does not have to be the best solution.
Jose
Glenn Algie wrote:
> Jose the MPCP signal suite contains timestamps in all 6 control signals. I
> just don't like reinventing the wheel.I don't think appropriate to send
> timestamp as part of bearer flow for doing this isochronous MAC option.
>
> -----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
>