| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all, We're looking forward to seeing some of you at today's prep meeting. I just wanted to remind everyone that the primary purpose of today's meeting is to review the materials that some of us will be presenting at next week's formal meetings. I don't think we'll have too much time this afternoon to get into a lot of technical details about alternative synchronization approaches. The important thing is for us to be well prepared for next week's meetings and to have a clear definition of the the application requirements and need for 802.3 RE in general. BTW, for those of you wishing ot call in to today's meeting. A bridge number should appear on the reflector shortly. Thanks. -- Digital Entertainment Networking Pioneer Research Center USA, Inc. 101 Metro Drive, Suite 264 San Jose, CA 95110-1343 408-437-1800x203 408-437-1717 Dirceu Cavendish wrote: Folks, It is getting clear to me that we need to study various types of Synch schemes, and "run them against" the CE applications we are targeting. Otherwise, we will never be able to lock into a particular solution based on technical arguments - in which case from outsiders we would look like a group trying to standardize a particular solution, regardless the applications... Since many people believe that higher layer (application) schemes can solve the problem, we can start by showing why this isn't so... I would like to put this issue in the agenda for today's meeting, if it is OK with everyone... Rgds to all, Dirceu Cavendish NEC Labs America 10080 North Wolfe Road Suite SW3-350 Cupertino, CA 95014 Tel: 408-863-6041 Fax: 408-863-6099 -----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 2: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 --
Digital Entertainment Networking Pioneer Research Center USA, Inc. 101 Metro Drive, Suite 264 San Jose, CA 95110-1343 408-437-1800x203 408-437-1717 |