|
All,
Mick provided comments on the scope for the
draft timing/synch PAR. I have prepared a revised version that
incorporates his comments, with several minor changes, and Michael has posted it
at:
The minor modifications I made are (refer to the 2
sentences for the scope in Mick's email, attached below):
- in the first sentence, I added the
word "concepts" after 1588; this is so that people would not assume we are using
1588 in its exact form as is with no changes (e.g., so people will not
think we
have decided to use the one-way
messaging with less frequent two-way messaging scheme in 1588, as opposed
to the possibility of pure two-way messaging)
- in the first sentence, I
changed audio and video to "time sensitive"
- in the 2nd sentence, I added
the phrase "during normal operation and" after the words "... maintenance of
synchronized time"
The only change to the revised
draft PAR is in the scope VG; the rest is the same as the previous posted
version.
I would like to discuss this in the
call this week. Any comments are welcome.
Thanks.
Best regards,
Geoff
-----------------------------------------------------
Geoffrey M. Garner
Samsung (Consultant)
----- Original Message -----
Sent: Monday, November 07, 2005 12:31 PM
Subject: Re: Possible PARs (with content, this
time!)
Geoff,
I am replying without the benefit of the original to hand. However I was
thinking of the Scope as something like the following ...
"This standard will specify the use of IEEE 1588 in the context of IEEE
Stds 802.1D and 802.1Q with particular reference to meeting the
synchronization requirements for audio and video applications across
Bridged and Virtual Bridged Local Area Networks."
Someting as short as that. Of course the above is just my understanding of
matching the problem statement, but I think it is clear that 802.1 (with the
inclusion of the ResE folks) is uniquely qualified to specify the above.
To the above might be added as single statement about the grandmaster
redundancy problem.
"It specifies the protocol and procedures used to ensure maintenance of
synchronized time following addition, removal, or failure of network components
and network reconfiguration."
Mick
Mick,
Thank you for your comments on the timing/synch
draft PAR. I gather that you reviewed the initial, text version I had
prepared. Since then I prepared a VG form, as I was told that it is
customary to prepare the initial draft PAR in the form of VGs to present to
the WG. The draft VGs were discussed in the ResE call last week (Oct.
26), and I received a number of comments. I then incorporated the
comments. The revision is posted in the ResE area, at
I began thinking about your comments in the next
to last paragraph of your email. I can add a reference to 1588 in the
first bullet item of the scope. For your items (1) - (3) that follow, it
is not clear to me how to add this and still keep the scope concise (as
it is a fair amount of material). Do you have any suggestions on how to
specifically word this (i.e., specific text) to keep the scope concise.
If so, I can prepare a revised version before the November meeting (if you
have suggested text, could you also copy the 802 ResE exploder so that
those who participated in the discussions so far can also give their opinions
before I prepare the new draft). However, I can wait to discuss this at
the meeting if that would be better.
I also prepared a draft 5 criteria, in VG
form. The latest posted version is available at:
However, this was discussed in the ResE call this
week (Nov. 2), and I have sent Michael the revision with the comments from the
call incorporated. I don't think it is posted yet.
Thanks.
Best regards,
Geoff
------------------------------------------------
Geoffrey M. Garner
Samsung (Consultant)
----- Original Message -----
Sent: Wednesday, November 02, 2005 6:19
PM
Subject: RE: Possible PARs (with
content, this time!)
Michael,
I'm sorry I have
been unable to respond and have been much taken up with family issues, and
will continue to be right up to the meeting. My first reactionis, as Paul
says, these need to be much much shorter. 5 lines in 12 point Courier max.
That doesn't mean to say that you shouldn't have a long version for working
group reference, just that we need a very short version for the PAR proper.
You may want to look at some recent PARs in the docs2005 public documents
folder on the 802.1 website.
Another
procedural point is that the contents of the scope clause ought to be close
to a cut and paste of the initial part of the final scope clause in the
standard. This is because RevCom, the committee that finally procedurally
approves a proposed standard after all the ballots are done likes to ensure
that the scope of the proposed draft really does fit the scope of the PAR
that was approved. I think it is easiest to make this point using an
example.
Here is
the Scope in the PAR for MAcsec (P802.1AE):
"Scope of Proposed Project:
The scope of this project is to
specify provision of connectionless user data confidentiality,
frame
data integrity, and data origin
authenticity by media access independent protocols and entities
that
operate transparently to MAC
Clients**. Key management and the establishment of secure
associations is outside the scope but
will be referenced by this project. **As specified in IEEE
Standards 802, 802.2, 802.1D,
802.1Q, and 802.1X."
Here is the beginning of the Scope clause for
P802.1AE as it went to sponsor ballot:
"1.2 Scope
The scope of this standard is to specify
provision of connectionless user data confidentiality, frame data
integrity, and data origin authenticity by
media access independent protocols and entities that operate
transparently to MAC Clients.
NOTE-The MAC Clients are as specified in IEEE
Standards 802, 802.2, 802.1D, 802.1Q, and 802.1X.
To this end it
a) Specifies
......"
You get the idea.
This all being said I think you may be able to trim
what you have already fairly easily.
In addition to these items (Scope, Purpose, Reason)
for the PAR form you need (this is an 802 rule not an overall IEEE rule) to
put together a set of the 5 criteria. I am sure many of you are already
familiar with the style of these for 802.3, and there are (again) specific
examples in the .1 docs2005 directory.
At a higher level I think the PAR for the timing
and sync can be fairly clearly developed. Perhaps a little more imaginative
study of GSRP versus "RSVP-lite" (whateve that could be taken to mean) is
going to be required to convince people that we can't start by chopping RSVP
down to size (I am not saying this is a technical point of view by the
way).
In the PAR for timing and sync I think it would be
useful to consider the role IEEE 1588 plays in this, and in particular to
consider whether there should not be a firm reference to IEEE 1588 even in
the first sentence or two of the scope. The role of 1588 in this will become
apparent in answering 5 Criteria questions anyway, so it is as well to play
it up as to conceal it at the top -level. That then focuses on the value
that the proposed adds to IEEE 1588 - in terms of making it useful in the
context of bridge local area networks. This then expands into thoughts
aboput how 1588 is applied (1) to the bridge architecture (2) to timing
considerations related to the 802.3 MAC, or probably more likely to a timing
reference point as close as possible to an arbitrary MAC (3) to the issues
we discussed in the San Jose interim about having a proper grandmaster
redundancy and distribution scheme (similar to spanning tree or
other).
While it would be good to realize some alignment
with 802.11 I would very much caution that admission control and admission
control choices in advanced .11 network discussions are likely to be very
much dominated by consideration that don't apply to this project, and that
we could easily find the whole thing derailed by a massive increase in
scope, without actually meeting anyone's needs, or indeed achieving any
better conceptual alignment. I would sum it up in ancient map maker's terms
"there be dragons".
Mick
The
ResE group (have to pick a better name! AV802?) has been thinking about PAR
content over the past two weeks, and here are some examples. We'd
really like to get some input from you two, if possible
...
BTW, some of the CE firms working with 802.11 are looking at
their current QoS proposals and wondering if the admission control system
that we are working on might apply to their A/Ps as well. Maybe there is a
possibility to get the wireless people to work together with 802.1
(finally!).
--
---------------------------------------------------------------
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
---------------------------------------------------------------
|