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