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
> > >
> >
>