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

RE: [EFM] Re: OAM Transport Proposal






Hi Brad,

You interpretation of the intent of the term "pervasive access" in my
presentation is correct. The management entity has the same, unspecified, direct
access to the MAC, MAC Control and RS State Machines and Functions.

I would also like to comment on the your point about speeding up OAMinP by using
state machines in the RS. In the case of an implementation where the optional
MDC/MDIO is the only management interface to the PHY layers below the RS, I
believe that there is some information that is sent by OAMinP, such as the
signal state, that will not be available in the RS. In this particular case the
information will have to written to the RS by the management entity after it is
polled through the MDC/MDIO hence preventing state machine speed up for that
information. Further, as I believe the standard allows for the optional MDC/MDIO
to be the only management interface to the PHY layers below the RS, I think the
minimum response time specification (if included) for information that is not
available in the RS would have to allow for this polling delay. Alternatively of
course, further changes to the interfaces could be made.

Best regards,
   David Law







"Booth, Bradley" <bradley.booth@xxxxxxxxx> on 24/04/2002 17:45:03

Sent by:  "Booth, Bradley" <bradley.booth@xxxxxxxxx>


To:   stds-802-3-efm@ieee.org
cc:    (David Law/GB/3Com)
Subject:  RE: [EFM] Re: OAM Transport Proposal





Just a few comments below:

Thanks,
Brad

          -----Original Message-----
          From:     Matt Squire [mailto:mattsquire@xxxxxxx]
          Sent:     Tuesday, April 23, 2002 10:29 PM
          To:  stds-802-3-efm@ieee.org
          Subject:  [EFM] Re: OAM Transport Proposal


          Another attempt to address multiple questions at one time.

          1) MDIO slowing preamble down.  The intent is that the any
bit handling
          of the preamble is done below the MDIO interface.  One of
the reasons,
          for me anyway, to keep the use of preamble to communicating
a few very
          specific states was for this point exactly.  Trying to
communicate real
          'data' would be slowed down by getting the data from the
MDIO
          interface.  The assumption is that the RS is enhanced to
hold a small
          number of state variables which can be communicated via the
preamble
          without turning into management frames over MDIO.

          BJB> Using the RS for the preamble will bypass the need for
use of the MDIO.  I just want to be sure that we do clarify that "pervasive
access" does not mean instantaneous or high-speed access.  I believe David
Law's term "pervasive" means that the MAC, MAC Control and RS all have the
same direct access to the MIBs rather than via MDIO.  The management entity
would have the same speed of access to the MAC Control MIB data as it would
to the RS MIB data.  Therefore, the only way the RS can be more responsive
than MAC Control is if there are state machines in the RS to handle OAMinP
without management intervention.


          3) Null/Dummy frames screwing up MIBS.  Yes semantics of the
undersized
          frames variable will have to change to say something like
"except for
          null/dummy frames which are counted by ...".   But I think
things can be
          defined in a way thats backward compatible. This, along with
only using
          those frames when the other side supports it, should have
the effect of
          MIB compatibility.

          BJB> I get the feeling that there are a lot of people that
would rather live without this feature.


          4) Clauses effected.  We did a preliminary examination of
the clauses
          that needed to be addressed by the proposal.  The following
is the list
          as I see it.
            - Clause 30 (Management).  New MIB objects, enhanced
locally and also
          enhanced to include peer info.
            - Clause 31 (MAC Control).  Add OAM section, fraem
formats, protocol
          operation, bla bla bla
            - Annex 43B.  Add OAM types to slow protocols list, maybe
change slow
          protocol definition, etc.
            - Clauses 22 & 45.  New PHY monitoring registers for
things like RX
          power, signal-to-noise ration, etc.
            - Annex 30A & 30B.  New OIDs for managed objects.
            - Clause (new).  OAM preamble byte format, use,
description, etc.
            - Clause 22 & 35 (RS/MII, RS/GMII) - Dummy/null frame
generation,
          inclusion of preamble transport capability.
          The preamble specific changes are the latter two.  Please
point out if
          we're missing some clause changes somewhere.  This list does
not reflect
          which clause changes are significant and which are minor.

          BJB> Do you have a list of clause editors to perform these
modifications?



          - Matt