Re: [Mter] Any news?
Didier Colle <didier.colle@intec.UGent.be> Wed, 15 March 2006 12:51 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJVT6-0008OV-8L; Wed, 15 Mar 2006 07:51:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJVT4-0008Nf-PK for mter@ietf.org; Wed, 15 Mar 2006 07:51:10 -0500
Received: from cypress.ugent.be ([157.193.49.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJVT2-00085Z-Ak for mter@ietf.org; Wed, 15 Mar 2006 07:51:10 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by cypress.UGent.be (Postfix) with ESMTP id 72526382610; Wed, 15 Mar 2006 13:51:07 +0100 (CET)
Received: from cypress.UGent.be ([127.0.0.1]) by localhost (gibbon.UGent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24272-04; Wed, 15 Mar 2006 13:51:03 +0100 (CET)
Received: from plinius.intec.ugent.be (plinius.intec2.rug.ac.be [157.193.214.4]) by cypress.UGent.be (Postfix) with ESMTP id 41CE738260A; Wed, 15 Mar 2006 13:51:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by plinius.intec.ugent.be (Postfix) with ESMTP id 24ECABD58; Wed, 15 Mar 2006 13:51:04 +0100 (CET)
Received: from [157.193.214.109] (andersen2.intec.ugent.be [157.193.214.109]) by plinius.intec.ugent.be (Postfix) with ESMTP id 0BFBFBD56; Wed, 15 Mar 2006 13:51:04 +0100 (CET)
Message-ID: <44180DB6.80607@intec.UGent.be>
Date: Wed, 15 Mar 2006 13:51:02 +0100
From: Didier Colle <didier.colle@intec.UGent.be>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Diego Caviglia <Diego.Caviglia@marconi.com>
Subject: Re: [Mter] Any news?
References: <OF3F9BE37D.B0C9B639-ONC1257132.003CDF1C-C1257132.003F03D9@uk.marconicomms.com>
In-Reply-To: <OF3F9BE37D.B0C9B639-ONC1257132.003CDF1C-C1257132.003F03D9@uk.marconicomms.com>
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
Cc: mter@ietf.org
X-BeenThere: mter@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-TEchnology Recovery <mter.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mter>
List-Post: <mailto:mter@ietf.org>
List-Help: <mailto:mter-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=subscribe>
Errors-To: mter-bounces@ietf.org
Dear Diego, [CUT] >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) > >a<--------->b<--------->c<------->D<--------->E<---------->F<---------->G<-------->h<---------->i<-------->z > >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 [CUT] -- Didier Colle Ghent University - IMEC - IBBT Department of Information Technology (INTEC) Gaston Crommenlaan 8 bus 201, B-9050 LEDEBERG Email: didier.colle@intec.UGent.be MSN: didiercolle@hotmail.com Skype: didiercolle Tel. +32 9 331 4970 Fax. +32 9 331 4899 WWW: www.ibcn.intec.UGent.be _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter
- [Mter] Any news? Diego Caviglia
- RE: [Mter] Any news? LE ROUX Jean-Louis RD-CORE-LAN
- RE: [Mter] Any news? Diego Caviglia
- Re: [Mter] Any news? Didier Colle
- Re: [Mter] Any news? Diego Caviglia