Re: headless chicken
Osamu,
The headless chicken... I mean a "stand-alone PHY", is clearly allowed in
Ethernet because it is an implementation. So long at the Ethernet PHY is
compliant to it's PHY specifications. However, the question remains as to what
specifications allow you to do with this it. For example, the Isolate bit is
applicable to the GMII. Whether it will be applicable to the XGMII and/or XAUI
and/or XBI is an open issue.
After reading your responses, my gut feel is that the Ethernet standard
specifies how a MAC converses with its one associated PHY. If the MAC or PHY
fails, the standard also specifies the reporting mechanism and specific reports
made. When a MAC and its associated PHY is put into service, the standard
specifies how the link is made operational. It seems that this issue focuses on
events between the time an Ethernet link between two devices fails and the same
or other link between the same two devices is put into service again. Please
correct me if I am mistaken about the scenario you are addressing in this issue.
On the outside chance that I nailed the scenario correctly, I believe that the
issue is not an Ethernet standards issue, it is rather an implementation issue.
Best Regards,
Rich
--
Osamu ISHIDA wrote:
>
> Rich,
>
> Sorry for my late response to your 'headless chicken' fable.
> I needed almost a week to cook it well; please enjoy my seasoning. :-)
>
> Once again, be sure that we are not discussing the general
> requirement to the PHY. My concern is whether the specific
> implementation 'stand-alone PHY' could be allowed in the Ethernet
> standard or not. I hope the answer is 'yes', but if not, please
> let me know your issues.
>
> As I understand, PHY can be working stand-alone when the Control
> register bit 0.10 (Isolate) has been set 1 (electrically Isolate
> PHY from GMII). In Clause 22 (22.2.4.1.6), it is noted that the
> standard neither requires nor assumes any specific behavior at the
> MDI resulting from PHY 'Isolate'.
>
> As for 'headless chicken', please find my comments below.
>
> At 2:20 PM -0700 00.6.15, Rich Taborek wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02723.html
> > Osamu ISHIDA wrote:
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02657.html
> >> At 10:43 PM -0700 00.6.10, Rich Taborek wrote:
> >> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02652.html
> >> > It seems that there are a couple of issues within this thread:
>
> >> > 2) Separate operation of the 10 GbE MAC and PHY;
>
> >> > For issue (2) I don't recommend separating the operation of the Ethernet MAC and
> >> > PHY. The operational state of the MAC should match that of it's associated PHY.
> >> > Device management should coordinate layer operation stated to ensure
> >> > consistency. If the PHY goes down, the link, including the MAC should be shut
> >> > down. This means that an Ethernet PHY should not remain operational if its
> >> > associated MAC, or XAUI, or XGMII is broke.
> >>
> >> I know that my implementation is NOT a traditional Ethernet way.
> >> Also I never say that 802.3ae should operate MAC and PHY separately.
> >> I just want to know what might be the problem if I or some other Carrier
> >> guys should implement them separately.
> >>
> >> In my sense, Ethernet MAC and PHY are Computer Application Software and OS.
> >> The first part of your description is correct; if the Windows 95 (PHY)
> >> goes down, your PowerPoint (MAC) should be shut down. However, why Win95 (PHY)
> >> should not remain operational if its associated PowerPoint (MAC) is broke?
> >> Is it because Microsoft?
> >>
> >> What I want to have here is more robust implementation like Linux PHY.
> >> I don't say all the 802.3ae should be Linux. I think Win95 & PowerPoint
> >> is worth for the most part of the users.
> >>
> >> What I want to know here is what would happen if we try to implement
> >> PowerPoint on the Linux OS :-). Is it impossible?
> >
> > The OS/Application analogy is not applicable because of the level of integration
> > typically associated with Ethernet MAC/PHY elements. At 10 Gbps, all physical
> > elements containing the MAC and PHY will likely be managed, ensuring that the
> > left hand knows what the right hand is doing. Using another analogy, a dead MAC
> > and an operating PHY is analogous to a headless chicken. Would you trust a
> > headless chicken? I'd shoot the chicken.
>
> I agree with you that many inexpensive MAC/PHY can be modeled with
> your headless chicken analogy; a dead MAC (head) generates no CLK
> and hence PHY (chicken body) had better be shot out.
>
> However in the 40km serial PHY, I think you do not necessarily shoot
> the headless chicken since it may still be able to run on the track
> with his own clock for SERDES. Using another analogy, a serial PHY
> attached to MAC via XAUI is analogous to a taxi. The chicken (MAC
> with XAUI) can take a taxi (PCS,PMA,PMD) for 40 km trip. The chicken
> will not drive the car by himself but order a taxi driver to go.
> Even if the chicken lose his head, I think we don't need to shoot
> the taxi driver. He know how to drive his car safely while he will
> not be ordered anything. Yes, what he should do is just lighting up
> the 'Vacancy' (Break Link) until he catches another passenger,
> or until the chicken get another fresh (re-booted) head. :-).
>
> In my sense, 40+km optics is a deluxe limousine and hence I like
> to have an obedient professional driver rather than driving it by
> myself.
>
> Best Regards,
> Osamu
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com