10/100/1000 "4578" power
JR,
Perhaps I did not understand your question fully...
However, the attached schematic is one possibility for 10/100/1000 with power on the
legacy "spare pairs". (we should just call them forty five seventy eight)
For 10/100 versions, the transformers shown on pins 4,5 & 7,8 would become tapped inductors,
or resistors, or even shorts.
- Rick Brooks
At 10:57 AM 05/12/2000 -0700, you wrote:
>
>
>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
>>>
>
>
1000baseT_block.pdf