Re: [Mter] Any news?

Didier Colle <> Wed, 15 March 2006 12:51 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FJVT6-0008OV-8L; Wed, 15 Mar 2006 07:51:12 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1FJVT4-0008Nf-PK for; Wed, 15 Mar 2006 07:51:10 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1FJVT2-00085Z-Ak for; Wed, 15 Mar 2006 07:51:10 -0500
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 72526382610; Wed, 15 Mar 2006 13:51:07 +0100 (CET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 24272-04; Wed, 15 Mar 2006 13:51:03 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 41CE738260A; Wed, 15 Mar 2006 13:51:03 +0100 (CET)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24ECABD58; Wed, 15 Mar 2006 13:51:04 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTP id 0BFBFBD56; Wed, 15 Mar 2006 13:51:04 +0100 (CET)
Message-ID: <>
Date: Wed, 15 Mar 2006 13:51:02 +0100
From: Didier Colle <>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Diego Caviglia <>
Subject: Re: [Mter] Any news?
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS snapshot-20020222
X-Virus-Scanned: by UGent DICT
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-TEchnology Recovery <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Dear Diego,


>Section 6.1 quotes AIS as possible mechanism to detect failures.
>Is the following possible issue in the scope of MTER (actually is a
>partitioning problem rather that a layer problem)
>Caps letters indicates GMPLS capable nodes while the low caps are legacy
>SDH/SONET nodes.
>One can say that D, E, F, G is the backbone network while a, b, c and h, i,
>z are two access network.
>A network operator wants to set up a trail fom a to z, we can see that
>trail made by three pieces:
>1)    a<----->D
>2)    D<----->G
>3)    G<----->z
>Pieces 1 and 3 are set-up via NMS and are not under the control of the
>GMPLS while piece 2 is an e2e restored circuit.
>If the AIS is used as trigger for the GMPLS restoration a failure in either
>piece 1 or 2 (that injects AIS along all the trail) can trigger the e2e
>GMPLS recovery scheme.  Given that the failure is not recoverable inside
>the piece 2, the risk is that restoration never ends.
You are right this is an issue. However, I believe the typical solution 
to overcome this problem is establishing a tandem connection in each of 
the three segments and making use of the sublayer supervision function 
in order to allow detecting whether the failure occured ON or UPSTREAM 
OF the tandem connection.
For example: when a failure occurs in segment 1 (thus a<---->D) then D 
will translate the the AU_AIS into a IncAIS (N-bytes in the path 
overhead of the tandem connection D->G). G will detect this IncAIS and 
will simply generate AIS downstream. However, when segment 2 fails (thus 
D<--->G), then G may receive an AU_AIS (and not a IncAIS) implying that 
it has to trigger the GMPLS P&R.

Kind regards,



Didier Colle
Ghent University - IMEC - IBBT
Department of Information Technology (INTEC)
Gaston Crommenlaan 8 bus 201, B-9050 LEDEBERG
Skype: didiercolle
Tel. +32 9 331 4970
Fax. +32 9 331 4899

MTER mailing list