Capability Negotiation

The basic motive of this process is to KNOW about the other node to which a node intended to communicate before establishing the connection, ie. whether other node contains the applications for which node wants to communicate. 

Technically speaking, It is the process where two diameter peer exchange their identity and its capabilities (such as protocol version number, supported diameter applications, security mechanism etc.). Peer share their capabilities by CER/CEA Message (Capability-Exchange-Request/Capability-Exchange-Answer).

If one peer sends a CER message to another Peer and receiver does not have support for 

 
1) any common application then it must return the CEA with Result-Code Avp set toDIAMETER_NO_COMMON_APPLICATION and should disconnect the transport layer connection.

2)no common security mechanism then it must return the CEA with Result-Code Avp set to DIAMETER_NO_COMMON_SECURITY and should disconnect the transport layer connection. (Only maintained to have backward compatibility Because in latest release Transport Level security is establish before diameter connection so CER/CEA message is also comes under TLS/DTLS for more Info Click Here)

3)If CER is received from any unknown peer then receiver should discard the message, or send the CEA with the Result-Code Avp set to DIAMETER_UNKNOWN_PEER.
 

If the local implementation policy permits to receive CER from unknown hosts,a successful CEA MAY be returned, and the life time of the peer entry in PEER-Table is equal to the lifetime of the transport connection. If in any case transport connection fails then all the pending transactions destined to the unknown peer can be discarded.

The CER and CEA messages MUST NOT be proxied, redirected or relayed. Since CER/CEA messages can not be proxied, but still it is possible that proxy will receive a CER message and proxy does not have any peer to handle the application requested in CER, in this case proxy set the E bit in CEA and set the Result-Code Avp to DIAMETER_UNABLE_TO_DELIVER, sends back to CER generator peer.

For Example:- consider two nodes A and B and Node-A contains three applications X,Y,Z and two security mechanism s1 and s2 while Node-B contains two applications A,X and s1 security mechanism. Now Node-A will send CER to Node-B. Node -B will process the request and will create and send the CEA showing success and the common application i.e. X and s1 security mechanism. Now Node-A become aware of the fact that it can communicate for X application and s1 security mechanism.

Probable CER And CEA would be:-

      ________          CER                     ________

     | Node-A | ------------------------------>| Node-B |

     |________| <------------------------------|________|

                                          CEA 

               

<CER> ::= < Diameter Header: 257, REQ >                          <CEA> ::= < Diameter Header: 257 >
    { Origin-Host }                                               { Result-Code =SUCCESS}
    { Origin-Realm }                                              { Origin-Host }

    { Host-IP-Address }                                           { Origin-Realm }
    { Vendor-Id }                                                 { Host-IP-Address }  
    { Product-Name }                                              { Vendor-Id } 
    [ Inband-Security-Id =s1 ]                                    { Product-Name } 
    [ Inband-Security-Id =s2]                                     [ Inband-Security-Id =s1 ]   

    [ Vendor-Specific-Application-Id =X]                          [ Vendor-Specific-Application-Id =X]
    [ Vendor-Specific-Application-Id =Y] 
    [ Vendor-Specific-Application-Id =Z]  
 

                 CER/CEA Message Exchange