RE: Dan- Again (response)
You guys keep getting on Roger, but you still haven't articulated a
solution for providing power for 1000BASE-T links. If I open the latest
version of the 802.3 specification published by the IEEE, there aren't any
unused pairs.
JR
At 06:29 PM 5/11/00 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>
>Roger,
>
>I have to confess. I am getting confused. In your earlier post you
>suggested using 12,36 for switches and 45,78 for mid-spans, then
>when I raised the question of whether you were conceding that it was
>better to use 45,78 for mid-span, you went back to stating that we
>have not shown 12,36 in the mid-span to be a problem which suggests
>that you are moving away from the earlier position.
>
>Your justification that some customers have only two pairs is valid,
>but it has been decided to be insufficient to gain consensus in the
>committee. Continuing to raise it is unlikely to turn the tide of
>support for a 4-pair solution.
>
>If we are to have a solution, I believe it should be only ONE solution
>that works in either the hub/switch, mid-span, or desktop-wall-wart
>applications.
>
>While I can appreciate your desire that the committee approve a solution
>that supports Cisco's recently introduced product implementations, the
>simple fact is that when you rush a solution out in advance of the
>standards, you take a risk that your solution will not be compatible.
>
>This has been proven time and again. I can think of many proprietary
>solutions that were functional, but were not standardizable due to
>implementation constraints that were favorable to their designers, but
>not to the industry as a whole. This is a natural outgrowth of the limited
>review that proprietary specs receive.
>
>Using the data pairs and a differential detection scheme seem to be at odds
>with the objectives of our committee because they add risk and complexity to
>the "must support 10/100T" and "must support mid-span
>insertion" objectives.
>
>I have yet to see how someone would suggest that you can send differential
>signals from a mid-span location down only one half
>of the link and determine whether it is ready to accept power. How do you
>isolate the other half of the link to prevent it from interfering with your
>differential response?
>
>In contrast, it seems intuitively obvious that one can inject a
>DC common-mode voltage onto one end of the link and evaluate the I/V
>characteristics that the load represents. Since it it DC, it will be easy to
>filter to reject noise emissions and induction.
>
>But lets not rely on one person's intuition, I wholeheartedly agree that
>scientific measurement and analysis are the best method for deciding our
>direction.
>
>Best regards,
>
>Dan Dove
>HP ProCurve Networks
>
>> From: R karam [mailto:rkaram@xxxxxxxxx]
>> Sent: Thursday, May 11, 2000 2:54 PM
>> To: stds-802-3-pwrviamdi@xxxxxxxx
>> Subject: Dan- Again
>>
>>
>>
>> Hi Dan
>> thank's for your input and
>> here is my 2c on this.
>>
>> >>
>> >> Thank you for asking- I am encouraged.
>> >>
>> >> Cisco's proposal has the following A, B sections.
>> >>
>> >> A- Use the Signal pair 1,2 and 3,6 to deliver power on a
>> new switch.
>> >> B- Use unused pair (4,5 and 7,8 ) to deliver power for mid-span.
>> >
>> >Intuitively, this seems to add complexity and I can not fathom
>> >why we would want to use different pairs depending on the
>> >location of the power insertion. Given our objective of
>> detecting power on
>> >the same pairs that it is inserted, this would require
>> twice the amount of
>> >DTE-detection circuits and raise the issue of how to deal
>> with switch vs
>> >mid-span insertion conflicts (ie: The switch sends
>> Fat-Link-Pulses down
>> >12,36 and gets confirmation to send power while the
>> mid-span sends its
>> >signals down 45,78 and gets confirmation on its pairs).
>> This sounds like
>> >un-necessary complexity.
>> >
>>
>> Dan, a bunch of things here,
>>
>>
>>
>> 1- we have yet to prove that going with the signal-pair (1,2
>> and 3,6) in Mid
>> span is a problem. We all think that it is risky based
>> on common sense.
>> and chances are it could be. Fine and dandy for
>> exisiting switches at
>> customer sites, we are not about to have them removed as
>> some people claim.
>>
>>
>> 2- why the signal pair, and why NO complexity:
>>
>> a- there will be some customers with 2-pairs only, may be x%
>> but there will be some.
>> and telling them look Mr customer, you did not follow the
>> IEEE rules so
>> now you have to pay does not sound like a valid reason
>> to him and sounds like
>> a punishment to me.....
>>
>> b- When I think about what it takes to do this standard, I
>> envision a low entropy spec
>> where the scheme should be simple, clean and does not
>> require heavy duty
>> PHY-like level of intensity. after all some pulses
>> will flag a DTE (phone say), you turn
>> power on, making sure that nothing will be fried ( &
>> transient protection....).
>>
>> c- many little reasons come to mind so here is a Top 10 list:
>>
>> So if we are selling a NEW switch,
>>
>> 1- the intelligence for power and management can be in
>> the switch
>> 2- the customer does what he always did, just plug and play
>> 3- less boxes and headaches at the patch panel
>> 4- I as the wire-side engineer know that my circuitry is
>> sitting behind
>> 2000 volts of isolation, esd protected, and very
>> possibly inside the phy
>> leaving me with a single Monitor-part at maximum and
>> possibly little silicon if I had
>> my way here at the wire-side! to do the JOB.
>>
>> I am talking about zero circuitry on the board (
>> probably) for detection and a few
>> parts for power delivery. (transient protection and a
>> power monitor)
>>
>> 5- the minute you require a lot of intelligence to be on
>> the wire side and start to
>> think too much silicon, and at low voltage, you will
>> enter into what could be a silicon
>> headaches in the field due to latch-up and transients.
>>
>> 6- I hear everyone- there will be some us who want to
>> fry eggs off the ethernet cable,
>> charge batteries, but this differential scheme is
>> begging to be used for ethernet-
>> networking enviornment where these phy vendors that
>> we all beat up daily, who learned
>> so much over so many years the hard way, delivering
>> some really challenging solutions
>> can be of help to us (and this is not to vote for
>> any of them).
>>
>> I hear you, this is not optimal for the Egg cooker, but
>> accomodating the egg cooker request,
>> to me is the added complexity. The majority of us are
>> doing 10/100/1000 Ethernet
>> So let's see both sides for a change.
>>
>> 7- Gigabit Again 1000BT <> (not equal) to 1000BT, and it
>> is either 1000BT/100TX /10BT
>> or at least 1000/100, while seeing each other can be
>> fun every 2 month, brushing
>> this aside as un-necessary at this point may not the
>> best approach here, since 1000BT
>> makes signal pairs out of the 4-pairs in the cable,
>> once we solve the signal- pair
>> issues we may be in for an addendum to the spec (if we
>> elect not to tackle it now)
>> and we will not have to revisit this in 2 years.
>>
>> 8- To this point, I am the optimistic one and feel good
>> about this, what would be interesting is if
>> we all get in with an open mind and possibly improve
>> it, it may get us somewhere, years and
>> years of PHY, Magnetic, and RJ45 experience on our part
>> and the vendors' can be put to make
>> such an approach a reality with minimum extra space
>> needed on the switch (due to density) this will prove
>> to be a blessing. How much room are we left with at
>> the RJ45 with high port count boxes,
>> The phy will have to be there, so shove as much into it
>> as we can.
>>
>> 9- Say we run into a situation where more power has to be
>> delivered, and it is impeded by
>> the Connector or wire, then having access to the 2
>> signal pairs is a blessing.
>> possibly allowing a power hungry device to be built.
>>
>> 10- Again, drumming up the phy story, should this prove
>> doable, and at this point I think
>> that it is, then designing Detection into the phy
>> might prove to be a good option that
>> is there for anyone to reach for. We can look into
>> this, it may be as simple as using
>> 2 switches to use along with the POWER monitor
>> circuitry existing on the unused pairs-
>> plus the phy detection and there you get 2 schemes in
>> one. Also If the DTE is built
>> to accomodate a single approach that could prove
>> enough, but the added flexibility may
>> be 2-3 parts away. So long that we try to keep an open mind.
>>
>>
>>
>> These reasons are coming from myself and some of the issues that
>> were raised at last meeting. Of Course Larry's approach
>> and yours have merit,
>> and your ideas possibly have advantages in some ways, let's
>> look at each approach, at measurements,
>> and transients protection and see where this leads us to...
>> I want you to know that I have
>> toyed with the single ended approach, where common mode
>> pulses are sent in/out of RJ45,
>> and worried about noise, EMI and silicon on the wire issues.
>>
>> Thank's
>> roger
>>
>>
>>
>>
>> >If you are conceding that using the unused pairs for
>> mid-span is a better
>> >alternative than using the data pairs, please explain to me
>> why we should
>> >use the data pairs for switch-based power insertion.
>>
>> Dan,
>>
>> >
>> >Simplicity, and consistency would argue that we should just
>> apply power in
>> >the unused pairs at both locations and reduce the number of
>> alternatives by
>> >half.
>> >
>> >Regards,
>> >
>> >Dan Dove
>> >HP ProCurve Networks
>>