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

RE: [EFM] Re: OAM Transport Proposal




David,

Good point.  I had overlooked the fact that in 802.3z, the signal detect
does not go above the PCS.  Therefore, if we required signal detect for an
alarm indication in OAMinP, we'd either have to adjust the response time
accordingly for the MDIO/MDC access or add another signal to the GMII.
Thanks again for pointing that out.

Cheers,
Brad

		-----Original Message-----
		From:	David Law [mailto:David_Law@xxxxxxxxxxxx]
		Sent:	Wednesday, April 24, 2002 1:31 PM
		To:	Booth, Bradley
		Cc:	stds-802-3-efm@ieee.org
		Subject:	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