RE: Here's a new idea:
For every soapbox there is yet another.
Both 802.3 and EIA/TIA TR-41/42 Standards groups have been preaching for
well over 5 years that all RJ-45 installations of "generic cabling" should
be star wired and terminate all 4 pair in a single RJ-45.
This was done for several reasons:
1) To make the cabling plant generic (i.e. application independent)
2) To provide a uniform platform for future applications
3) To provide a well characterized transmission environment
Customers who did not do this were at risk of losing the capabilities of a
generic cabling plant. In particular for number 2 the future applications
are (at this time and from my point of view) 1000BASE-T and DTE Power.
As for splitting 4 pair to 2 outlets, that works fine for 10BASE-T. It is a
bad idea in terms of a 100BASE-T transmission system. The crosstalk from a
10BASE-T into some of the older implementations of 100BASE-T can be disruptive.
As to your assertion that the 2 pair split-out represents "many" and STP
Type 1 & 2 installations represent "Lots"...
Sorry but we need better information than that. How about some quanitative
input as to number of installations that are real-live candidates for
DTE-Power applications and the percentage of the installed base that they
At 03:29 PM 5/1/00 -0500, James M. Polk wrote:
I believe there will be a greater impact on *not* engineering this on the
Signaling pairs. Both 10 and 100 Ethernet utilize only two pairs, not 4
pairs. So a minimum implementation of Ethernet is pairs 2&3, and nothing
knows the wiser. Having power on those signaling pairs satisfies this
minimum implementation. Any other implementation should ask the following
How many customer sites have split off their 4 pair cabling for an
additional station? Many
How much STP Type 1 and Type 2 is there installed? Lots
The cost of re-cabling these sites is significantly greater than the cost
of the new equipment for VoIP and other such implementations that will
utilize this NEW power capability.
This will prevent the adoption of this committee's effort to whole customer
sites at a time -- which I've never thought was a good philosophy, but
seems to be what's going on here, IMO. This seems like a very exclusionary
position, not inclusionary (which is how a standard should be).
At 12:39 PM 5/1/2000 -0700, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>It occurs to me that the detection method is irrelevant to
>1000BASE-T operation as the link will not be up at the time
>of operation. However, the issue at hand is whether you can
>inject power at a mid-span in a way that is compatible with
>1000BASE-T signalling requirements.
>There have been some votes on this subject and my recollection
>is certainly not the best thing to rely upon, but I recall
>that 10/100T is a MUST while 1000BASE-T is a WANT.
>Using pins 4,5 and 7,8 minimize the potential impact on 10/100T
>but would likely have an impact on 1000BASE-T.
>There are studies underway to understand just how much these
>impacts are and whether they will exclude 1000BASE-T operation.
>_________ _/ ___________ Daniel Dove Principal Engineer __
>_______ _/ ________ dan_dove@xxxxxx LAN PHY Technology __
>_____ _/ ______ Hewlett-Packard Company __
>____ _/_/_/ _/_/_/ _____ Workgroup Networks Division __
>____ _/ _/ _/ _/ _____ 8000 Foothills Blvd. MS 5555 __
>_____ _/ _/ _/_/_/ ______ Roseville, CA 95747-5555 __
>______ _/ ________ Phone: 916 785 4187 __
>_______ _/ _________ Fax : 916 785 1815 __
>__________ _/ __________________________________________________________
>From: James M. Polk [mailto:jmpolk@xxxxxxxxx]
>Sent: Monday, May 01, 2000 10:11 AM
>To: Bob Bell; tal@xxxxxxxxxxxxxx; stds-802-3-pwrviamdi@xxxxxxxx
>Subject: Re: Here's a new idea:
>It's Monday, so forgive this clarification, but are you asking Tal to test
>his scheme on the signaling pairs of a 10/100BASE connection as well as pins
>4/5/7/8 on a 1000BASE-T connection? If not, I'd be curious if Tal could do
>this; if so.... then I'm being redundant again redundant again......
>At 10:18 AM 5/1/2000 -0600, Bob Bell wrote:
>>One of the objectives the group stated was to test for powerablity on the
>>same wires as the power would be provided. In addition, it is desirable
>>that the powering and thus the testing be done in such a manner that the
>>signal carrying capability of the wire pairs not be compromised (this it to
>>allow it to work with 1000BaseT. Could your scheme meet these two
>>At 02:27 4/30/2000, Tal Weiss wrote:
>>>Since this is my first contribution to the forum and I'm not sure that
>>>email forwarding system works, I'll be brief.
>>>I read the different discovery process approaches and I want to offer
>>>something completely different!
>>>All of the proposals in the forum are analog by nature, and lack in
>>>I was able to construct a digital "power-identity-chip", costing less than
>>>1$, to be implemented inside the powered-IP-phone. This was done using
>>>The chip is powered remotely from the switch using 5 Volts (a simple 5K
>>>pull-up resistor does the trick).
>>>The power-enabled-switch polls the line for "power-identity-chip" (this
>>>be done across wires 4,5 or 7,8) and when a phone is attached the chip is
>>>found (CRC protected communication, of course).
>>>This chip then tells the switch what it's power requirements are!
>>>which wires, power, MAC address and so on...)
>>>The power-enabled-switch then applies the correct power using the correct
>>>This approach has been tested in the lab and works using different cabling
>>>schemes from more than 200 meters!
>>>No false alarms and no misses.
>>>I know this is different than all the other approaches mentioned above,
>>>it works so well I couldn't resist sharing.
>>>If more information is needed I'll be glad to supply it!
>>>23 Hasivim St.
>>>Petah-Tikva 49170, Israel
>>>Fax : 972-3-9210757
>>Cisco Systems Inc.
>"At the end of the day... the most committed win!"
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and Standards
>Enterprise Voice Business Unit
"At the end of the day... the most committed win!"
James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit