RE: [Fwd: [EFM] OAM transport...]
Matt,
If one or more company has intellectual property for either approach,
each company is required to agree to license on fair, reasonable,
reciprocal and non-discriminatory terms, any patent claims it owns
covering such technology.
Martin
-----Original Message-----
From: Matt Squire [mailto:mattsquire@xxxxxxx]
Sent: Saturday, February 09, 2002 3:43 PM
To: stds-802-3-efm@ieee.org
Subject: [Fwd: [EFM] OAM transport...]
I've been asked by a couple people to ask another question of the
proponents of the any of the OAM transport mechanisms:
11) Can you comment on any intellectual property considerations of which
the group should be informed?
Thanks.
- Matt
Matt Squire wrote:
>
> I'm sending this note out on the main EFM list rather than the EFM OAM
> list in hopes of getting feedback from a wider audience. In the OAM
> group, we have to decide on a method for transporting OAM data between
> the stations on a link. There are several proposals that have been
put
> forth for OAM transport. At the last meeting, two proposals were
active
>
> Proposal 1. Transport OAM bits in regular Ethernet frames at the MAC
> control layer. This proposal is described in
> http://www.ieee802.org/3/efm/public/jan02/gentry_1_0102.pdf.
>
> Proposal 2. Transport OAM bits in the Ethernet preamble at the
> reconcilliation sublayer. This proposal is described in
> http://www.ieee802.org/3/efm/public/jan02/suzuki_2_0102.pdf.
>
> Other proposals have been mentioned but have not been active in the
past
> two meetings.
>
> We need to choose a baseline transport mechanism at or by the March
> meeting. In order to meet this goal, we really need to hammer on the
> alternatives so that there is a common understanding of the tradeoffs
> between the options, and maybe, just maybe, a clear winner will
emerge.
> Thats probably unlikely at this phase, but we at least need a more
open
> analysis of the pros and cons.
>
> In an attempt to facilitate some comparisons, below I list some
criteria
> on which I think the alternatives might differ. These are criteria
that
> have been mentioned by other people in the past. I'm not sure if its
a
> complete set, but at least its a start. I've asked the backers of
each
> proposal to compare the alternatives and to document the comparison to
> the list, hopefully using the criteria/questions below (supplemented
> anywhere that they think I missed something).
>
> So here's my set of questions/criteria by which I plan to evaluate the
> proposals. Feel free to develop/ask your own questions of the
> proposals, and of course to weight each criteria according to your own
> beliefs about what things are more important than others.
>
> I'd appreciate some feedback from the authors on these questions. I
> believe that many members in the audience need a better and public
> analysis of the pros and cons to vote intelligently on the transport
> options.
>
> And to the wider audidence - we need a broad public analysis of the
> proposals, so please weigh in on things for good or bad.
>
> Thanks.
>
> - Matt
>
> ------------------
>
> 1) Standardization complexity - How much do we have to change/write in
> the 802.3 specification to support this transport mechanism? Being
that
> I'm personally very lazy, less is better. Which clauses would be
> effected and to what extent in each clause?
>
> 2) Implementation complexity. Again, back to me being lazy, how much
> work is it to implement the transport mechanism? What functional
blocks
> in the 802.3 spec need to be changed? How much new silicon/software
is
> needed for an implementation (relative to the alternate proposal(s))?
> What is the component level backward compatibility (ie how much
existing
> hardware can I use)?
>
> 3) Bandwidth transparency. What is the effect on user data with
respect
> to the OAM transport (ie delay/bandwidth implications of adding OAM to
a
> link)? Why is this acceptable?
>
> 4) Applicablity to non-EFM PHYs/MACs. EFM will be defining new PHYs
> over which we know OAM will operate. Can the OAM transport mechanism
be
> applied to other (non-EFM) PHYs? For example, people are using some
1G
> fiber solutions for access now. Can the OAM transport mechanism be
> applied to the current 'first mile' solutions? Should it apply to
> current 'first mile' solutions or to other applications of Etherent?
>
> 5) Security. We've had some detailed discussions at the meetings on
> security and threats in the access market. How are threats such as
> denial of service or theft of service addressed by the OAM transport?
> Should these issues be addressed?
>
> 6) Responsiveness. What is the comparative responsiveness of the
> transport mechanism? What kind of responsiveness is necessary for the
> problem?
>
> 7) Data rate. Is the data rate for OAM transport fixed, variable,
> configurable, or what? What data rate is necessary to support OAM
> function?
>
> 8) Market acceptance. What do you view the market requirements for an
> OAM transport mechanism are, and why does this transport suffice?
>
> 9) Standards acceptance and ethernetishness. Some claims have been
made
> that some techniques are more 'Ethernetish' than others - which to me
> means that the transport fits within the meaning of Ethernet better -
so
> what are the main attributes of Ethernet and does this proposal fit
> better within them than others?
>
> 10) PON. The P2P OAM is relatively straightforward. Are there any
PON
> implementation specifics that need to be addressed? How does the OAM
> data rate change on a p2mp link, for example. Are there new/other
> security threats? Is there, and should there be, any relationship to
> the PON control protocol(s) (currently MPCP)?
>
> -------------------------------------