Re: [EFM] OAM transport...
I think we (OAM group) has some view of the Cu & PON specifics, but not
enough. There definitely needs to be some joint meetings or maybe even
some phone calls to discuss OAM/Cu and OAM/PON specific requirements.
The scheduling hasn't really permitted these types of interactions yet
and we need to do so.
I had a PON bullet in my list of questions, so now I'll add a Cu
bullet. How does the OAM transport mechanism work with the xDSL work
happening in the copper track?
But Ethernet OAM and xDSL OAM perform differnet functions. There is
nothing that prevents OAM in frames or OAM in preamble from happening
over Eth/xDSL (assuming the preamble is transmitted over the xDSL link
which I don't think is the view right now). As this is a layered
approach (ie building Ethernet over xDSL), that might be the right thing
to do from an architectural viewpoint. When one sends higher layer
services (like Ethernet) over xDSL, the managment of the higher layer
services is not part of the xDSL management layer.
However, as we are intending to build integrated hardware, we could also
put a layer between the OAM layer (wherever that ends up) and the xDSL
layer which, in effect, pulls the OAM stream onto the OC stream.
I think we need to get some time together between the groups to discuss
the options. Hugh and I need to schedule something.
- Matt
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)?
>
> -------------------------------------