Re: [HSSG] fault signalling
Mikael/Steve-
My (legacy) analog voice provider will not send "the man in the van" to my
house unless I have "proved" that my service doesn't work. They turn it off
and on ("up and "down") in the central office and assume that the dedicated
pair (well, maybe channel) works until proven otherwise. On the other hand
the proof test is simple enough for the customer. Plug an RJ-11 phone into
the demarc.
My cable provider, on the other hand, insists on sending someone into my
house even for service that shouldn't require it. That is because their
cable pant is (a) not point to point (b) a mess and (c) requires test
equipment not normally owend by the customer.
For end customers in Ethernet case, one would hope that the demarcation
device will be a bridge or router that has two agents in it. One on the
provider side and one on the customer side. Each agent should be able to do
loopback tests and report statistics from a MIB that both can see (Whether
the customer can cope with this or other means are required is another
issue). This will be based on the assumption that communication (internal
to the silicon) just between the 2 halves and across the demarcation
barrier will be orders of magnitude more reliable than anything else. This
equipment only needs very limited link status capability (e.g. link loss,
far-end fault). It can do all the rest in the data domain above the PHY and
maybe even above the MAC.
In the carrier environment (single or inter-carrier) which I think is what
we have been talking about, it has been the tradition (SONET derived) to
put more diagnostic stuff in at a lower level.
Where we are going to run into problems is at the hybrid issue. If Ethernet
thinks it is specc'ng a single span and carriers are doing something else
(e.g. dumb or dumber repeaters) then the Ethernet model won't provide
trouble isolation to a span (ie between any 2 active pieces of equipment),
only to what it sees as a link segment (ie Ethernet MDI to Ethernet MDI).
I don't see how 802.3 can be expected to do anything more.
ITU could possibly do more in terms of information embedding and ask for
whatever it does to be incorporated into the 802.3 signalling.
Geoff
At 12:42 PM 9/18/2007 , Mikael Abrahamsson wrote:
>On Tue, 18 Sep 2007, Trowbridge, Stephen J (Steve) wrote:
>
>>I was just thinking about the reasonableness of your installation
>>scenario ...
>>
>>If I order analog voice service from Qwest, Qwest sends somebody to my
>>house to verify the connectivity to their central office and turn up the
>>service.
>
>My Telco won't do that. They will just take for granted that the copper
>pair works.
>
>>If I order cable modem service from Comcast (6 Mbit/s), Comcast sends
>>someone to my house to verify connectivity to their network, do
>>extensive checks on my cabling at home (how I have my splitters
>>configured, making sure that everything except the cable modem jack is
>>filtered so that I don't leak anything back into their Cable TV
>>distribution network, and that the service works).
>
>My telco won't do that. They will send a description on how to connect the
>modem in the package they will send you, containing splitter, modem and
>cable. It's very unusual that they will send anyone to my home, and if
>they do (because I can't get it working) and it's my fault, they'll charge
>me at least $100 for sending an engineer.
>
>>Is it realistic to think that for a bleeding edge service at over 15,000
>>times the bandwidth of any service I have to my house, that this will
>>occur by letting the customer install and connect their own equipment
>>over an unverified run of dark fiber and I expect to turn up that
>>service from one end of the fiber at the service provider POP without
>>sending anyone to the customer premises?
>
>I don't understand your analogy. Do you really expect 100GE to be a
>technology used to the customer premesis?
>
>I know how we turn up everything from 1GE to OC768. We expect to connect
>equipment at each end of the dark fiber and check attenuation and RX
>optical levels so they're within parameters, and then we ping a million
>packets and check for CRC errors, if it works error free, we start using
>it for live traffic. Engineer in the field will in the best of cases have
>a optical level meter, most often he does not, he will definately not have
>an OTDR. We then contiously monitor error rates on the interface.
>
>I don't understand your way of doing business, it sounds hugely expensive
>opex-wise, and even then you think that having management in the devices
>is a too costly proposal?
>
>I just don't get it. First management is (too) costly to include in 100GE,
>then as an alterantive the proposal is to spend man-hours using very
>expensive testing equipment to test the connection before it's used to
>turn-up the service? I'd rather spend that money on OAM, my guess is that
>it'll be cheaper in the long run.
>
>--
>Mikael Abrahamsson email: swmike@swm.pp.se