Re: [RE] Categories of RE development
David, Interesting points. Comments below.
Bill
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of David V James
Sent: Wednesday, November 24, 2004 6:04 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: [RE] Categories of RE development
All,
In recent discussions with others, I have been trying to scope and categorize the problems associated with
802.3 Study Group Residential Ethernet.
The following is a first pass summary, with an attempt to identify the distinct categories of work. The intent of this is to allow folks to focus on distinct areas, while maintaining a consistent view of the whole.
This is still a rough draft, but I thought it helpful to distribute this before the Thanksgiving vacation.
Credit is due to several others, that stimulated my thoughts. They have not reviewed this content and thus could not be safely listed as supporters/conspirators.
A) Vocabulary. A few commonly used terms.
I have an historical bias but no strong preferences.
1) What should we call a sender of isochronous data?
* talker
[WMS] * other _source___________
2) What should we call a receiver of isochronous data?
* listener
* sink
[WMS] * other __destination___________
B) Using these terms, a crude breakdown of tasks could be:
1) Device discovery. How does a listener discover the talker?
For example, how does the TV discover tuners, cable box,
etc.?
Notes: This is probably out of scope, since this work
is more device-centric and being done by multiple
non-802 groups.
[WMS]Out of scope for 802 standards. Handled by UPnP, Rendezvous, etc.
2) Admission control. How is the bandwidth allocated?
a) The bridges between the talker and listener are set
to forward desired traffic, up to a specified bandwidth
limit. If not possible, due to limited bridge forwarding
tag entries, a rejection is indicated.
b) The cumulative specified bandwidths for each link are
ensured to not exceed the capacity of the link. If not
possible, without exceeding the link capacity, a rejection
is indicated.
Notes: This could possibly be a variant of GMRP, based on
the GARP protocols defined in 802.1D. A distinction is
that only paths between listeners and one talker are
required (a many-to-many group allocation would be inefficient).
[WMS] Bandwidth is not a fixed quantity. Throughput for a 100 Mbps link will be far less for 64 byte frames than 1500 byte frames.
3) Clock synchronization. How are clocks synchronized?
This involves two tasks, although they most likely share
many of the same state machines and frame transmissions.
a) Clock master selection. The clock-master station is
selected from among the multiple candidates. This
would be done with an STP like precedence specifier
(weight plus MAC-48 tie-breaker).
b) Adjacent sync. On point-to-point links, the link-local
clock-slave synchronizes its clock to the link-local
clock-master station.
c) Bridge sync. With "magic", the bridge synchronizes
its bridge-local clock-master ports to the selected
clock-slave port.
Notes: The details of this are really a link-level spec,
although some constraints on the timing of bridge-sync
"magic" may be necessary.
4) Transmission gating. How are isochronous frames gated?
Some proposals have indicated gating pending traffic
at the start of each 125us interval.
Note: This is really a form of "micro" admission control.
However, calling this "gating" may be less confusing.
Note: The simplest solution would be to place the same
timing constraints on stations and bridge gating, which
could imply "reclocking" to avoid cumulative jitter.
5) Formats. Formats of a few things need definition:
a) Frames. The format depends on a few things:
How should an isochronous frame be distinguished?
* Distinct multicast address?
* Distinct type/length code?
What is an isochronous channel number?
* Allocated from a central pool?
* A {mac,port} concatenation, where:
mac identifies the talker
port is a subconnection within the talker
[WMS] How is "port" identified in a MAC frame? Would looking inside be layer bleeding?
What forms of time stamps are necessary?
* End transmission time?
* Link transmission time?
* Sync marks within the data?
b) Service interface. What service interfaces
primitives/parameters are required?
* Clock synchronization
* Timed delivery
Thoughts? What has been missed? What should be added?
[WMS] What about policing (Making sure sources obey their contract)?
[WMS] Is traffic shaping required for VBR? Leaky bucket?
DVJ
David V. James
dvj@alum.mit.edu