Re: [HSSG] fault signalling
Mikael-
SONET stuff has a built-in notion of turn-up and turn-down.
There is no such built-in notion within Ethernet.
So one of the assumptions tends to be that you need to qualify your media
before you plug it into Ethernet and when you do you expect it to work.
This is one of the reasons that Ethernet designs have more margin built
into them than traditional carrier gear. The margins are for multi-vendor
interoperability and external testing allowances
It might be reasonable to have some such notion of turn-up within
Ethernet PHYs that are intended for carrier/provider use and to also have
test access to the PHYs so that links can be tested in place when they
are "turned down". However, nothing like this exists anywhere
in the current 802.3 standard.
All of this "can be done". All it takes is the will of the
group to do it, the willingness to take the cost hit and the agreement on
how to do it. When it is all done, the Ethernet links will have a lower
capex advantage wrt SONET gear but will have (hopefully) improved
opex.
Unlike SONET, none of this is a given nor taken for granted in Ethernet.
It will have to pushed into the process. I would not expect universal
support.
what I'm asking is for a communication channel
where it can tell the other end what's going on.
We also have no notion of a "Message Wire"
Best regards,
Geoff
At 11:19 AM 9/18/2007 , Mikael Abrahamsson wrote:
On Tue, 18 Sep 2007, Geoff Thompson
wrote:
Mikael-
You need to be careful about the level of complexity that you are asking
for. Each item can e a significant expense. After all, there is only one
important question that has to be answered for a single hop system. That
would be "Do I need to put a repairman at the other end of the
link?"
The more important question in that context (when you lose a link)
usually becomes (a) do I need to send a repairman to the far end
equipment or do I need to send a cable crew to find a break and (b) can I
tell the difference between the two without going through the step of
sending a technician to the far equipment?
In my view, it is perfectly reasonable to use test equipment on the fiber
to make determination (b). After all, the link is down so there is no
reason not to move the fiber to a piece of test equipment. If it is a WDM
fiber, then you will hopefully know if the loss is all of the wavelengths
or some subset.
Let's try to give this another dimension. A common scenario for us is the
following:
We have equipment in two different data centers, at each side of a city.
Turnup of a patch involves at least three parties to do patching (each
end hosting provider, might involve our engineer at each end to do
patching, and then the dark fiber provider). The person responsible for
the turnup is in another country, trying to coordinate all this. Going
between the sites might involve a 2 hour drive in city traffic, typically
we only have a single engineer doing each end.
Now, if one end has too much attenuation due to dirty patch, this is
extremely helpful to know without doing that two hour drive. Yes, this
can be solved by doing one end first and so on, and it's typically done
so, but in some cases we'll discover that one party hasn't done their
part etc, and the remote end is done first.
So basically, there is real cost (man hours) that can be reduced in both
initial and maintenance phase by having proper management. We're today
paying the OC192 vs 10GE premium to accomplish this for DWDM, because
there it's extra helpful, but without DOM we might do the same even for
dark fiber (DOM does help quite a lot, at least when both ends are
reachable).
Are there any calculations on cost for what I'm proposing, so it can be
put into perspective? I don't see us using 100GE without DOM anyway, so
the information I would like to have via OAM is actually available to the
unit in my scenario, what I'm asking is for a communication channel where
it can tell the other end what's going on.
--
Mikael Abrahamsson email:
swmike@swm.pp.se