[Dime] RFC6737 and Relay nodes

Gerasimos Dimitriadis <dimeg@intracom.gr> Wed, 15 May 2013 10:29 UTC

Message-ID: <51936368.2060206@intracom.gr>
Date: Wed, 15 May 2013 13:28:56 +0300
From: Gerasimos Dimitriadis <dimeg@intracom.gr>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Dime] RFC6737 and Relay nodes
Precedence: list

Hi all,

I'd like to ask you a question on Capabilities Update when 'relay' nodes 
are concerned. Specifically, I want to ask whether 'relay' nodes need to 
advertise the Capabilities Update App Id (10) alongside 0xffffffff 
towards adjacent diameter nodes or not.

Consider a case where proxy agent A is connected to relay agent B, and A 
wants to update its supported applications.

If B has not advertised 10 in the initial CER / CEA exchange (alongside 
0xffffffff), how can A know if B implements RFC6737? Should A try a 
Capabilities Update nevertheless and, in case that RFC 6737 is not 
implemented, just get a DIAMETER_APPLICATION_UNSUPPORTED error back?

The above issue could be fixed if the Capabilities Update App Id is sent 
alongside 0xffffffff in the initial capabilities exchange handshake, but 
it feels a little bit strange, since 0xffffffff implies 'all applications'.

Thank you and BRs,
Gerasimos

[Dime] RFC6737 and Relay nodes Gerasimos Dimitriadis