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

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)?
> 
> -------------------------------------