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

RE: [EFM] OAM transport...




Matt,

Please take a look at the presentation that I made in St. Louis last 
year.  You will find a proposed OAM frame format that would be common to 
both the optical and copper implementations.  The Bit Insertion method on 
page 4 is the type of OAM insertion that is being referred to here.

I am looking forward to discussing it with you face to face.

Thank you,
Roy Bynum


At 03:56 PM 2/3/2002 +0100, Steven.Haas@xxxxxxxxxxxx wrote:

>Matt,
>
>It seems that the proposals from the copper track are not being fed in to 
>your OAM track.
>
>Almost all of the discussions on copper baseline proposals have referenced 
>existing xDSL standards. Some of the issues you raise have answers in the 
>xDSL standards that are referenced in the copper proposals. It looks as if 
>a joint copper-OAM session or discussion is needed to align since the OAM 
>transport mechanism in xDSL is over a special management channel that is 
>not in the preamble and is not in the Ethernet frames. This channel (OC 
>for operation channel) uses part of the transport frame and is designed to 
>support all of the physical layer OAM functions. This mechanism is well 
>defined, implemented in all xDSL devices, consumes a pre-defined bandwidth 
>and is "EFM ready" so for the copper track, all we have to do is add any 
>new EFM-oriented messages required in addition to the existing physical 
>layer ones. If the OAM group is able to define a set of functions that 
>need to be performed at the physical layer, the channel is already in place.
>
>Of course, I am assuming that we re-use work done for existing VDSL 
>standards (or any other xDSL). If not, everything you write is an open 
>question.
>
>Best regards,
>Steven
>
>
>PS: For reference, slide 17 on my presentation 
>http://www.ieee802.org/3/efm/public/jan02/haas_2_0102.pdf. shows the 
>reference model for VDSL with the operation channel function highlighted. 
>The presentation from Michael Beck of Alcatel also referenced "standard" 
>xDSL" management techiques in 
>http://www.ieee802.org/3/efm/public/jan02/beck_1_0102.pdf.
>  ___________________________________
>
>   Steven Haas
>   Infineon Technologies Savan
>   6 Hagavish St.
>   Poleg Industrial Park
>   Netanya, Israel
>
>   Email: steven.haas@xxxxxxxxxxxx <mailto:steven.haas@xxxxxxxxxxxx>
>   Tel:   +972-9-8924186 (direct)
>   Tel:   +972-9-8924100 (switchboard)
>   Fax:   +972-9-8659544
>   Mobile:+972-54-892186
>   ___________________________________
>
>
>-----Original Message-----
>From: Matt Squire [mailto:mattsquire@xxxxxxx]
>Sent: Sunday, February 03, 2002 3:06 AM
>To: stds-802-3-efm@ieee.org
>Subject: [EFM] OAM transport...
>
>
>
>
>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)?
>
>-------------------------------------