Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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