RE: [EFM] RE: OAM Transport Proposal
Sanjeev,
Comments below.
Thanks,
Brad
-----Original Message-----
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Thursday, May 02, 2002 8:38 PM
To: Booth, Bradley; 'stds-802-3-efm@ieee.org'
Subject: 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.
BJB> I was using PHY in the sense of the Physical layer. Not PHY in the
sense of the PCS, PMA & PMD. Now I understand where you're coming from.
>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?
BJB> There are no restrictions on the RS other than the preferences of those
in the Working Group.
>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.
BJB> With the current baseline, modifications would be required.
>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.
BJB> This was nicely addressed by Kevin's email about PMDs versus PHYs.
>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.
BJB> Yep, that's the way I see it too.
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. :)
BJB> No argument there. That's the fun of building on a living document.
:-)
>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.
BJB> Another one of those things that are unlikely to change. If you need
fast reaction time, do it in a state machine. :-)