[Dime] failover scenario

"Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com> Tue, 11 December 2012 00:39 UTC

Return-Path: <kristian.poscic@alcatel-lucent.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3C21F86FB for <dime@ietfa.amsl.com>; Mon, 10 Dec 2012 16:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.382
X-Spam-Level:
X-Spam-Status: No, score=-7.382 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyY5TqLRi9td for <dime@ietfa.amsl.com>; Mon, 10 Dec 2012 16:39:54 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9821F86FA for <dime@ietf.org>; Mon, 10 Dec 2012 16:39:48 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBB0dgwa024587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dime@ietf.org>; Tue, 11 Dec 2012 01:39:46 +0100
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 01:39:44 +0100
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 10 Dec 2012 19:39:28 -0500
From: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: failover scenario
Thread-Index: Ac3XNgVVklLO7zbqTReQ9dDlPt2SKw==
Date: Tue, 11 Dec 2012 00:39:25 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA28B4D@US70UWXCHMBA05.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: [Dime] failover scenario
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 00:39:56 -0000

Does anyone know what would be the mechanism in Base Diameter to handle the following scenario properly:


-          There are two NASes that run certain application (Gx in this case)

-          They are in standby/active mode - in other words, the NAS1 is active and has peering session with DMR-SRV. NAS2 is synched to NAS  (Gx session are synched and diameter entities are synched too - origin-host, origin-realm, possibly more AVPs...). However NAS2 is standby and therefore quiet (no peering session is established with  DMR-SRV)

-          If the NAS 1 fails, the NAS2 takes over (it detects the failure and activates itself along with application that is running on top of Base Diameter)

-          At this point, NAS2 will establish a peering session with DMR-SRV. The only difference between NAS2 and the failed NAS1 is the Host-IP-address (as AVP and also the source IP address in the transport => src IPs are not synched).

-          When the NAS2 sends CER and the peering session is established with DMR-SRV, will the DMR-SRV automatically update its routing table and see that nas.example.com is now at IP2 and not at IP1. Consequently all subsequent messages would be exchanged between NAS2 and DMR-SRV

-          All this presuppose that there are no changes on the application layer (Gx for example is completely synched between NASes) and the re-routing is handled at the Base Diameter.

-          Would this work and if not what would be the recommended approach that is compliant with Base Diameter so that the routing in DMR-SRV is updated properly?



Origin-host =                      nas.example.com
Origin-realm=                    example.com
Host-IP-Address =           IP1

---------
|NAS1 | -------------------
---------                                 |
                                                |                              --------------
                                                |-----------------| DMR-SRV|
---------                                 |                              --------------
|NAS2 |-------------------
---------

Origin-host =                      nas.example.com
Origin-realm=                    example.com
Host-IP-Address =           IP2


Thanks,
Kris