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

RE: [EFM] OAM transport...




Steven

The answer (imho) is that OAM messages are being specified as transport
agnostic, and the current thinking is that the transport must also be
agnostic to the specific PHY.

Speaking for myself I think having the transport specific to particular EFM
PHYs is more logical. This does not violate the 'one problem, one solution'
axiom.

There is a transport problem for copper (limited bandwidth), a problem for
EPON (shared bandwidth and access control), and a problem for EFM p2p. There
is also a generic problem for legacy PHYs.

Interesting, isn't it, that the DSL transport is not mixed with pay load.

Best regards

Bob



-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
Steven.Haas@infineon.com
Sent: 03 February 2002 14:56
To: mattsquire@acm.org; stds-802-3-efm@ieee.org
Subject: RE: [EFM] OAM transport...



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@infineon.com <mailto:steven.haas@infineon.com>
  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@acm.org]
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)?

-------------------------------------