RE: [EFM] RE: OAM Transport Proposal
Sanjeev,
I'd recommend you look at the diagrams in 802.3 again. There is a distinct
line from the top of the RS that indicates that it is considered part of the
PHY. In the past, the RS has been transparent (state-less) with the only
function of mapping from the media independent interface to the MAC serial
bit streams. By the way, the MAC service interface is at the top of the
MAC, not at the bottom.
Correct, preamble is a relic of our past. And in the past, we abused
preamble and wrote the standard to permit shortening preamble, etc. You'd
have to completely change how preamble is treated to make it something we
can use reliably.
Are you proposing defining a new 100BASE-TX-like or 1000BASE-X-like PHY that
is compatible with what is currently written in the 802.3? If you are, then
your assumption about being "tasked to define new PHYs" is completely
off-base. 802.3 prefers not having nearly identical PHYs with slightly
different variations depending on OAMinP functionality. That just won't
fly. If you want to be able to use existing PHYs, you have to be prepared
to modify them in such a manner that you don't break how they currently work
while adding in your required features.
By how to specify a reaction time, I meant that if you have to rely on using
a management interface such as MDIO/MDC, you have no control over the time
limit. Clause 28 and 37 use triggers to indicate when registers have been
updated for next page exchanges because we don't know how long it will take
the management entity to respond. We need to figure out how to specify and
where to specify OAMinP, because it is can cause a lot of problems if not
done correctly. OAMinF is much simpler in this manner as it doesn't change
the fundamental way Ethernet works, but OAMinP does, so it needs to be
better defined so we don't break the existing standard.
Cheers,
Brad
Brad Booth
IEEE P802.3ae Editor-in-Chief
bradley.booth@xxxxxxxxx <mailto:bradley.booth@xxxxxxxxx>
-----Original Message-----
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Thursday, May 02, 2002 3:44 PM
To: Booth, Bradley; 'stds-802-3-efm@ieee.org'
Subject: RE: [EFM] RE: OAM Transport Proposal
If one looks at the 802.3 ISO Open Systems Interconnection
(OSI) reference model specification RS is not seem to be
part of PHY.
RS is specified to be always a layer between MAC and PHY
adapting
to different PHY interfaces and mapping these various PHYs
(which are
completely different depending upon the underlying medium)
interfaces
(MII/GMII/XGMII/...) to MAC service interface. And these
media independent
interfaces are the only defined interconnects between PHYs
and RS; there is
no electrical interconnect defined between RS and MAC. RS
serves MAC
only through a service interface. Therefore, it may not be
correct to say that
RS is part of PHY.
I agree with that not all current PHYs guarantee to pass all
the preamble bytes
to RS, because all the PHYs are optimally designed for a
particular medium therefore used
preamble for its own purpose because it was "unused" for
their application and they could
made use of it (1000Base-X for even-odd alignment at TX,
1000Base-T for two SOPs,
100Base-T4 SOSA, SOSB, so on..). All these usage are
deviation from the original
purpose of the 010101.. sequence preamble designed to use
for clock synchronization
needed for mediums which have no carrier when there is no
frame data. So, after all
preamble is not so sacred.
Since 802.3ah is tasked to define new PHYs so I do not see
why a PHY can not be defined
to guarantee to pass a complete preamble to RS and don't see
why specifying so for a PHY
would break 802.3 spec. Correct me if I am wrong, it is not
expected for 802.3ah 1000Mbps
PHY to be compatible with 1000Base-X PHY or 100Mbps copper
PHY to be compatible
with 100Base-T PHY. So, if that is not the case what is the
big issue here?
True that the action and reaction for OAM is not defined
(regardless of transport mechanism),
and needs to be defined once it gets to its destination. But
how to specify is not seem to be
a correct question to pose. Is it that difficult to say that
if in 10ms if RS gets more than 4 RFIs
disable the transmit and set register x.x.x bit y.
Though having said all above if introducing a new sub-layer
for OAM in PHY makes it easy to
make implementations flexible, standard and inter operable
it could be a good approach too.
Although having it in RS could control the MAC operation
quicker, if need be.
Thanks,
Sanjeev
At 08:31 AM 05/02/2002 -0700, Booth, Bradley wrote:
>
>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
> > >
> >
>