RE: [EFM] RE: OAM Transport Proposal
Comments below.
Thanks,
Brad
-----Original Message-----
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Wednesday, May 01, 2002 5:16 PM
To: Booth, Bradley; 'stds-802-3-efm@ieee.org'
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
specify
>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
standard.
There is Ten Bit Interface specified between PMD part of the
PHY
and PCS. The PCS implementation could be with MAC (embedded
GMII)
or outside MAC (exposed GMII). There is management interface
for
all the sub-layers MAC, RS, PCS and PMD. But when things are
integrated common management interfaces could be used. As in
case
PCS and Auto-negotiation are integrated with MAC they share
the MAC
management interface. So, is when RS and MAC are integrated
they
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
specifically
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
the
>determination of the cause of LF must be determined via the
management
>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
>function.
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
occurrence.
>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.
>h
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
argued.
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.
Thanks,
Sanjeev
>Cheers,
>Brad
>
> -----Original Message-----
> From: Sanjeev Mahalawat
[mailto:sanjeev@xxxxxxxxx]
> Sent: Wednesday, May 01, 2002 11:47 AM
> To: Booth, Bradley;
'stds-802-3-efm@ieee.org'
> Subject: RE: [EFM] RE: OAM Transport
Proposal
>
> Hi Brad,
>
> For instance, what is the management/service
interface
>defined in
> 1000Base-X when PCS/Auto-Negotiation part of
PHY is not
> implemented in PHY but is with MAC. What is
the
>management/service
> 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
wrote:
> >
> >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
>Ethernet.
> >
> >Cheers,
> >Brad
> >
> >-----Original Message-----
> >From: Rich Taborek
[mailto:rtaborek@xxxxxxxxxxxxx]
> >Sent: Tuesday, April 30, 2002 10:29 PM
> >Cc: 'stds-802-3-efm@ieee.org'
> >Subject: Re: [EFM] RE: OAM Transport
Proposal
> >
> >
> >
> >Brad,
> >
> >The simple Fault and Alarm conditions that
are
>expeditiously transported
> >via OAMinP should not utilize the
relatively slow MDIO/MDC
>mechanisms.
> >The management entity for OAMinP is not
significantly
>different than
> >that which carriers are used to for SONET
OAM for handling
>the same
> >conditions. I believe that the specific
management
>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
MDIO/MDC
>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
> >
>