Subject: [Dime] [DIME] number of transport connections among two Diameter peers

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 17 Oct 2013 15:13:14 +0000

Hello Diameter experts and funs,

I have a question on the interpretation of the highlighted red text in following paragraph from RFC 6733 section 2.1 "Transport":

   A given Diameter instance of the peer state machine MUST NOT use more
   than one transport connection to communicate with a given peer,
   unless multiple instances exist on the peer, in which, case a
   separate connection per process is allowed.

My interpretation is that it refers to the possibility for two Diam. peers (each of them identified by its "valid" DiameterIdentity -as set in section 5.1-) to establish more than one transport connections (i.e. several TCP connections or several SCTP associations -e.g. the "initiator/client" using different TCP/SCTP source ports for each of them-).

In line with this, also CER/CEA, DWR/DWA and DPR/DPA procedures must be managed per established TCP conn/SCTP assoc (as set in section 5.6) ... but (Diameter) Application specific request and answers can be sent from one peer to the other using whatever transport connection established among them (for the shared/common supported Application-Ids, of course).

Could you confirm this is the shared understanding?

A part from that, in that case, I got the following question:  is it mandated that responses are sent through the same transport connection from where the (related) request-command was received?

Thanks a lot in advance
/MCruz

---

From: <[email-masked]>
Date: Thu, 17 Oct 2013 15:56:12 +0000

Dear Maria Cruz,

The interpretation is that ONE instance is uniquely identified by ONE Diameter Identity and between two diameter instances ONLY ONE transport connection can be established.
Multiple diameter instances can be collocated in the same "peer" (actually "peer" is misused here, should be "node"), each diameter instance being identified by a unique Diameter identity.

It is the reason why CER, DWR and DPR are not sent to a specific Destination-Host. It is implicit that the diameter identity is the one identified by the transport connection in the peer table.

It is acknowledged that there are some existing implementations in the field that are not following the statement given in the RFC6733 and allow multiple connections between two diameter identities. These implementations are not compliant with the RFC and iIt is therefore up to theses implementations to carefully maintain the peer tables, the state machines and use the CER/CEA, DWR/DWA and DPR/DPA. And to accommodate the fact that a node compliant with the RFC6733 will only accept one transport connection with a given diameter identity.

For your last question: "is it mandated that responses are sent through the same transport connection from where the (related) request-command was received? ", the answer is "yes" if the implementation is compliant with the RFC6733. It is implicit because the answer is forwarded back using the transport connection on which the request was received. And as only one transport connection is in place, there is no question.

My Best Regards,

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : jeudi 17 octobre 2013 17:13
À : [email-masked]
Objet : [Dime] [DIME] number of transport connections among two Diameter peers

Thanks a lot in advance
/MCruz

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.