RE: [EFM] RE: OAM Transport Proposal
Comment are in line...
Thanks,
Sanjeev
At 02:54 PM 05/02/2002 -0700, Booth, Bradley wrote:
>
>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.
SM:-With your recommendation if I look at the diagrams, it reminds me
those fine print adds and when I bump into those the provider
of those adds recommends me to look at them. :)
Anyway, if I look at these figures there are two parallel stacks with
one with OSI Reference on top and the other with LAN CSMA/CD
Layers on top. The last box of OSI stack called "Physical" has
very fine dotted lines covering RS. But when I look at the LAN CSMA/CD
stack there is word "PHY" that with solid line brace includes only
PCS, PMA and PMD layers and does not include RS. What do you believe?
"Physical" with fine dotted lines or "PHY" with solid line brace? OK, one could
say if you mention OSI believe "Physical" and if you mention LAN CSMA/CD
believe "PHY".
I had thought all along the discussion is about "PHY" (abbreviation for
Physical Layer Device) not "Physical" because "PHY" the word everyone
is referring including current exchanges. And also this is under LAN CSMA/CD
layer stack and so that is more relevant here. Therefore, I still think that purpose of
RS is not to be with "PHY" but be with MAC in order for MAC to connect to
different "PHY"s with different standard interconnects in LAN CSMA/CD stack.
And make MAC behave in media independent way.
>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.
SM:-But there is no restriction to make it stateful. Is there any?
>By the way, the MAC service interface is at the top of the
>MAC, not at the bottom.
>
SM:-I am not sure what are you referring here. If you are infereing from
my reference of interface between RS and MAC then I guess you
mis-interpreted it. Here what I meant was the service primitive between
MAC and RS which RS uses to service the MAC.
>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.
SM:-I am not sure if it needs to be completely changed but yes, modifications needs
to be made and could be made.
>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.
SM:-You completely mis-interpreted what I said. Let me say little explicitly,
802.3ah is most probably developing new copper and fiber PHYs those
will not be compatible with the existing PHYs those run at the same
speed for the corresponding medium. Is it not the case? If it is, then
those could be specified to guarantee the passing the whole preamble
to RS.
>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.
SM:-This was not my intent but since you have mentioned I would comment little
explicitly that changing current relevant PHYs like 1000Base-X (which is more
relevant here) to not change the preamble size does not break neither implementations
nor specifications. I would ask for a favour to point me out in standard which says
in 1000Base-X the PCS at TX should shrink the preamble to meet even-odd alignment.
This is not for rhetoric, I have not come across this in the spec therefore asking.
The 8-byte preamble is sub-set of a functionality that could handle shrinked
preambles would surely could handle full 8-byte preamble, later is the easier case.
There is nothing here I want to make fly.
>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.
SM:-There are two components of this whole fast link management. One is fast
notification to destination and fast action on these notification at destination
to repair the problem and minimize the damage.
Once acted/repaired on these notification the second part is to report to the management
entity about it. The first part is time critical the second part is not so.
SM:-But I have to say that this MDC/MDIO is a good shot in the arms of the people those
want to use it when needed. :). As the link speeds are testing the physical limits
but the management entity interface speed of these links some how manages to be in previous
century. :)
>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.
SM:-Give you an example, increase the clock speed of MDC/MDIO interface
to 50Mhz if not more. It will decrease the latency and specify that management
entity polls this register within 10ms and acts upon within 20ms.
>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.
SM:-Yes, it is important to make sure that things are done correctly specially
when one is dealing with specification like 802.3.
>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.
>
SM:-There no contest to this comment of yours that if something could be
solved in simple manner sure no need to make it complex. But what is
simple is also the one of points of the debate. Each coin has two sides.
SM:-Not that not shrinking preamble necessarily breaks anything,
I do not believe all these statements like "doing in frames does not
break existing standard". I wish the frame world is that simple slam dunk.
>
>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
> > > >
> > >
> >
>