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

Re: [RE] Grand master identifier



Arthur,

Notes embedded below ...


On 5/2/05 3:36 AM, "Arthur Marris" <arthurm@cadence.com> wrote:

> David,
>    I am not an STP expert but my understanding is that spanning tree is
> used by bridges to find out which of their ports are connected to other
> bridges. The protocol then determines a root bridge and shuts down
> redundant links to make sure there are no network loops. As I understand
> it the MAC address is for the bridge rather than the end station. I
> don't think the end stations are involved in STP.

Thanks. I think that is understood. Dave is talking about using the same
ideas used in STP to establish which node is the grand master for
time-of-day (the ultimate source of time stamping for streaming data). I
don't think he means to actually use the STP mechanism itself.
> 
>    I am not sure whether you are inviting general feedback on your
> working paper but I have some concerns. It assumes that there will be
> access control, bandwidth allocation and time slots for transmission.

Well, I don't think anyone that is proposing a "bridge-oriented" method for
providing RE QoS is thinking about "time slots" (although the 802.3-based
PHY and EPON-like proposals have time slots ... but Dave's paper isn't based
on that). Bandwidth reservations and access control, yes ...

>    Is bandwidth allocation really necessary to meet RE requirements?
> Over-provisioning and best-effort (with class of service) may be
> adequate. You can get a lot of data through a conventional gigabit
> switch with very low latencies. The RE traffic can be given a higher
> priority and so not be held up by less urgent traffic.

I think admission control is needed. In an unmanaged layer 2 environment
there is no way to *guarantee* that the streaming QoS parameters can be met
... you can only say "probably". With GigE and a fully bridge-based
environment with class of service you can get to a pretty good "probably"..
but you can't get to the "it will always work" QoS that the wonderful BER of
Ethernet promises. On the other hand, a simple admission control system and
simple pacing mechanism can get you there, even with an FE-only network.

>    With access control what happens if access is denied? My assumption
> is that a user connecting to a RE network would prefer best-effort
> service to no service at all if there is no spare bandwidth to be
> allocated. If you decide you need to support best-effort as a fallback
> then you need buffers in your end stations and the reason for using time
> slots goes away.

Your assumption is only correct if the service the consumer is subscribing
to *is* a best-effort service. Right now, consumers expect that when they
select a channel, or a CD, or a DVD they will get it *perfectly*. Cable
companies get lots of calls if a stream is substandard for any reason. The
general procedure to select a stream on a CE-oriented network would be
something like:

1) Hit the "directory" or "guide" button on your remote control
2) Find the content you want (note that the content entries might be labeled
with "not currently available" or "low quality only" or not even present
depending on the state of the path to the source).
3) Hit the "play" button.

Once the consumer hits that "play" button, the endpoints and network need to
make a contract to deliver the content with the QoS expected by the
consumer. So, in the case you describe where there is no guaranteed
bandwidth available, you *may* present an alternative method (such as the
"low quality" tag). This may be perfectly OK. If, on the other hand, the
consumer wants to see the HD movie with full quality, they can yell at their
kid to stop watching the movie that is causing the network link of interest
to saturate.


> 
> Arthur.
> 
> -----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: 29 April 2005 22:20
> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
> Subject: [RE] Grand master identifier
> 
> All,
> 
> I was starting to update a group-contribution working paper,
> when a couple of questions arose. For reference, these questions
> are with respect to:
>   http://www.ieee802.org/3/re_study/material/index.html
>   Subclause 5.2.
> 
> We assume that the grand master is selected by picking one
> of the clock-master capable stations. To do this, IDs need
> to be distributed externally (between bridges and stations)
> as well as internally (between bridge ports).
> 
> To avoid invention, we assume the existing STP identifier
> format should be used (why be different?). The format, not
> the actual values; an grand master could be different from
> the STP root.
> 
> My original assumption was that the precedence value,
> transmitted between stations, consists of:
>   16 bits -- system
>   48 bits -- MAC address
>   16 bits -- port
> 
> Having started to write things in more detail, it seems
> like the port information need only be used within a
> bridge, and need never appear on Ethernet.
> 
> Pardon my asking, but the appropriate 802.1 documents are
> not that easy for me to read. Am I correct in my recent
> thoughts, that the port portion of this identifier is
> only used within the bridge, and never appears on the outside?
> 
> DVJ
> 

-- 
---------------------------------------------------------------
         Michael D. Johas Teener ‹ mikejt@broadcom.com
office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845
http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
---------------------------------------------------------------