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

RE: [EFM] RE: OAM Transport Proposal

Comments below.


		-----Original Message-----
		From:	Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
		Sent:	Wednesday, May 01, 2002 5:16 PM
		To:	Booth, Bradley; ''
		Subject:	RE: [EFM] RE: OAM Transport Proposal

		At 12:01 PM 05/01/2002 -0700, Booth, Bradley wrote:
		>In 1000BASE-X, the PCS/Auto-negotiation is always part of
the PHY.  If you
		>implement it in a MAC device, then that portion of the PHY
logic is in the
		>MAC device.  You cannot assume that everyone will implement
the management
		>and service interfaces in the same manner.  802.3 does not
		>implementations; 802.3 specifies what characteristics must
be exhibited by a
		>conformant device.  How that conformant device is build and
sublayers are
		>partitioned is implementation specific.

		There is nothing implementation specific here and is all
		There is Ten Bit Interface specified between PMD part of the
		and PCS. The PCS implementation could be with MAC (embedded
		or outside MAC (exposed GMII). There is management interface
		all the sub-layers MAC, RS, PCS and PMD. But when things are
		integrated common management interfaces could be used. As in
		PCS and Auto-negotiation are integrated with MAC they share
the MAC
		management interface. So, is when RS and MAC are integrated
		share the same management interface.

BJB> The TBI is specified between the PMA and PCS, and is an optional
instantiation of the PMA service interface.  The standard only specifies a
management interface (MDIO/MDC) for the PHY.  In this case, the PCS and AN
(auto-negotiation) portions of the PHY are the only sublayers that require
management interaction.  The problem is you keep mentioning ways that this
can be implemented.  I fully understand all the possible ways to implement
this, but the standard is written with specific boundaries and interactions
across those boundaries to permit a wide range of implementations.  Yes,
when all things are integrated, a common management interface could be used,
but that is assuming that all things are integrated.  You may choose to do
it that way; whereas, someone else may not.  We cannot write the standard
based on your implementation or someone else's, we can only write it in a
way that permits everyone to implement it however they wish, as long as they
are compliant with the standard.

		By the way I could not find anywhere in Clause 37 that
		says Auto-negotiation must be in PHY, I must be missing
something here.  

BJB> The pointer to the fact that AN is in the PHY is not in Clause 37.  It
is in Clause 34 (34.1.2, third paragraph to be exact).

		>As for RF/LF, those only exist in 10GbE which uses ordered
sets inserted
		>into the IPG.  The RF is generated based upon LF input, but
		>determination of the cause of LF must be determined via the
		>interface to the PHY sublayers.

		I dont think local PHY has any idea about why a RF came from
the remote station.
		It has no idea that the receive side laser of the remote
partner is broken and
		I dont think PHY interprets RFs. Only RS interprets and
terminates RFs.
		Correct me if I am wrong. And this is being brought only to
draw a parallel, though
		RF/LF are 10GE specific. 

BJB> By the OSI reference model that we use throughout 802.3, the RS is part
of the PHY.

		>You're misinterpreting "broken".  Broken is having OAMinP
that either has no
		>way of acting on alarms or indications, and has no way of
communicating with
		>a management entity to perform these functions.

		I disagree with that there is no way for RS to communicate
with management entity.
		As far as acting on alarms is concerned it could be as
simple as disable the
		transmit to just pass the information to management entity
and both are possible
		(could be more complicated if wished).

BJB> I mistyped and the "and" should have an "or".  Yes, the RS can
communicate with the management entity, and this is a viable way of having
the management handle alarms, etc.  There are a couple of issues related to
getting the full preamble passed to the RS (as this is not required in
802.3) and with the fact that we cannot assume that the interface to the RS
is any better or faster than the management interface (via MDIO/MDC) to the
PHY.  In other words, how do you get the preamble to the RS and how do you
specify a reaction time?

		> RF/LF uses a state diagram
		>to react to incoming LFs and generate RFs.  Because this is
performed in the
		>RS, the function is considered to have pervasive
communication with the
		>management entity.  If the management entity wishes to
diagnose the cause of
		>the LF, it uses the management interface to the PHY to
perform this

		PHY could give reasons for LF but can not for RFs.

BJB> In 10GbE, the PHY doesn't give reasons for the RF as it is the remote
terminals problem and needs to be solved by the remote terminal.

		>These functions have no time dependence on their
		>Auto-negotiation works in almost a similar way, the
parameters are passed to
		>the PHY, the auto-negotiation state machine handles the
communication and
		>exchange of data (sometimes with management entity
involvement), and when
		>it's done, makes the information available to the
management entity.  I
		>don't see this level of detail being provided for OAMinP
while also
		>addressing the other concerns related to using preamble.
Can this be done?
		>Sure, but the current OAMinP proposal needs a lot of
modifications to make
		>it viable for specifying in 802.3.

		Agree here and more work needs to be done and presented. 
		But the level of details for OAM, its bits and behavior, its
state-machines etc.. 
		are not specific to how they are transported. In my opinion,
these could be separate
		issues but you may be right here. Like Auto-negotiation
state-machines (which could be 
		impelmented in PHY as well as in management entity) where
these are implemented could be

BJB> There are a number of issues that need to be addressed.  Some are
easier than others.  Things that require modifications to the current
behaviour of 802.3, I would consider very major changes.  I know that the
original proposal had the handling of OAMinP in the RS, but the passing of
preamble to the RS is not guaranteed.  If the OAMinP is handled in the PHY
like AN, then the proposal has to specify how that new sublayer would react
to alarms and indications so that interaction with the management entity
would be minimized.  I believe that these details are very important to iron
out because they will help us specify something that can be implemented by
everyone and that can be interoperable.


		>		-----Original Message-----
		>		From:	Sanjeev Mahalawat
		>		Sent:	Wednesday, May 01, 2002 11:47 AM
		>		To:	Booth, Bradley;
		>		Subject:	RE: [EFM] RE: OAM Transport
		>		Hi Brad,
		>		For instance, what is the management/service
		>defined in 
		>		1000Base-X when PCS/Auto-Negotiation part of
PHY is not 
		>		implemented in PHY but is with MAC. What is
		>		interface defined for RF/LF sequence
terminating in RS?
		>		Is it broken within the context of Ethernet?
		>		Thanks,
		>		Sanjeev 
		>		At 02:11 AM 05/01/2002 -0700, Booth, Bradley
		>		>
		>		>Rich,
		>		>
		>		>This is the sticking point.  802.3
specifies service
		>interfaces and a PHY
		>		>management interface.  To assume that EFM
is going to do
		>any management of
		>		>the link without using either of these
interfaces implies
		>that the OAM must
		>		>be handled inside the PHY.  If OAMinP is
not handling its
		>OAM messages
		>		>either in the PHY or via a service
interface or PHY
		>management interface,
		>		>then I think this is "broken" within the
context of
		>		>
		>		>Cheers,
		>		>Brad
		>		>
		>		>-----Original Message-----
		>		>From: Rich Taborek
		>		>Sent: Tuesday, April 30, 2002 10:29 PM
		>		>Cc: ''
		>		>Subject: Re: [EFM] RE: OAM Transport
		>		>
		>		>
		>		>
		>		>Brad,
		>		>
		>		>The simple Fault and Alarm conditions that
		>expeditiously transported
		>		>via OAMinP should not utilize the
relatively slow MDIO/MDC
		>		>The management entity for OAMinP is not
		>different than
		>		>that which carriers are used to for SONET
OAM for handling
		>the same
		>		>conditions. I believe that the specific
		>interface is out of
		>		>IEEE P802.3ah scope.
		>		>
		>		>Best Regards,
		>		>Rich
		>		>
		>		>--
		>		>
		>		>"Booth, Bradley" wrote:
		>		>> 
		>		>> Matt,
		>		>> 
		>		>> A management frame I described is that
defined in Clause
		>22 as a MDIO/MDC
		>		>> communication.  If the preamble is
filtered by the PHY,
		>then there has to
		>		>be
		>		>> some way to pass this preamble OAM
information to the
		>management entity.
		>		>In
		>		>> 802.3, this is done via MDIO/MDC (or
management frames).
		>A management
		>		>frame
		>		>> takes over 25 us to be passed across the
		>interface.  Unless the
		>		>> intention is to have the PHY handle all
OAM in preamble
		>without management
		>		>> entity intervention, then the response to
the OAM in
		>preamble will be
		>		>> hampered by the MDIO/MDC interface.
		>		>> 
		>		>> Cheers,
		>		>> Brad
		>		>