DIAMETER Capabilities Update Application

For better understanding kindly go through following topic

DIAMETER Connection Establishment


Why do we need capability update procedure?

This basic question that comes in our mind that why do we need this feature in Diameter Applications. Before this feature; Issue was that if want to update/upgrade any application (Client/Server) in OPEN state (i.e. when DIAMETER connection is established) then there is no provision to tell other NODE (Peer) about updated features, We must bring the application Down (i.e. Bring the application to CLOSE state) and Bring it up again with New features. 

Because CER/CEA (Capabilities-Exchange-Request/Answer) is the only message that is used to tell application Ids supported by an APPLICATION and this message is only exchanged once; when an APPLICATION comes up. We could not exchange CER/CEA on DIAMETER established connection. If any DIAMETER connection established Node (Peer) receives this message shall treat CER/CEA as a notification that other node got restarted. It shall relinquish the already established connection and start a fresh connection. In Practical scenario restarting a system is treated as Service Outage; To Avoid service outage DIAMETER Capabilities update feature is provided.



How does DIAMETER Capabilities Update Application work?

  • It is a procedure to dynamically update capabilities of an Application (Client/Server). Application that is wanted to use this feature MUST advertise Application-Id 10 in CER/CEA (Capabilities-Exchange-Request/Answer)message. Both communicating nodes MUST support Application-Id 10.
  • An application that is going to send Capabilities-Update-Request (CUR) shall send all the Application-Ids currently supported by it (rather than sending only upgraded) on established connection. This message can not modify the security constrainapplied on established connection.
  • Receiver of CUR MUST look for intersection of supported Application-Ids received with its own Application-Ids, If there are some common applications then it shall send CUA with Result-Code set to DIAMETER_SUCCESS and shall store the values of Application-Ids else it send Result-Code set to DIAMETER_NO_COMMON_APPLICATION and should terminate transport connection, if there are some on going sessions then it may delay the termination process till completion of sessions.
  • Capabilities-Update-Request/Answer command code id 328 and Message Format is as follow:


       <CUR> ::= < Diameter Header: 328, REQ >
                { Origin-Host }
                { Origin-Realm }
             1* { Host-IP-Address }
                { Vendor-Id }
                { Product-Name }
                [ Origin-State-Id ]
              * [ Supported-Vendor-Id ]
              * [ Auth-Application-Id ]
              * [ Acct-Application-Id ]
              * [ Vendor-Specific-Application-Id ]
                [ Firmware-Revision ]
              * [ AVP ]
       <CUA> ::= < Diameter Header: 328 >
                               { Origin-Host }
                               { Origin-Realm }
                               { Result-Code }
                               [ Error-Message ]
                             * [ AVP ]
  • During the processing of CUR/CUA message Vendor-Id AVP in the Vendor-Specific- Application-Id MUST NOT be used in decision making. A Node (Peer) can not use CUR/CUA message to notify the change in its own identity i.e. Origin-Host
  • Like CER/CEA message; CUR/CUA message can not be relayed, proxied and redirected.
Your Comments /Suggestions and Questions are always welcome,  shall clarify with best of our knowledge. So feel free to put Questions.

29 comments:

  1. Is it mandatory that all the Diameter nodes should support this handling? If a diameter node does not support, may I know what is the expected behavior? Should it send DIAMETER_COMMAND_UNSUPPORTED (3001) to the peer node?

    ReplyDelete
    Replies
    1. Hi Vijay,

      Whether or not; CUR/CUA is supported by a Node, is highlighted in CER/CEA message. CER/CEA is the first message exchanged b/w two nodes.

      If both node supports Application-ID 4 in CER/CEA as common application then they can send CUR/CUA message.
      otherwise Node shall not understand the command code. your error code is correct.

      Delete
    2. This comment has been removed by the author.

      Delete
    3. Hi Ajay,

      You have told if both node supports App ID 4, in CER/CEA as common then they can send CUR/CUA .. But in the top it is mentioned as App ID 10.

      "Application that is wanted to use this feature MUST advertise Application-Id 10 in CER/CEA (Capabilities-Exchange-Request/Answer)message. Both communicating nodes MUST support Application-Id 10.".. I am confused. I am a started for Diameter protocol pls correct me if my question is invalid

      Delete
    4. You are talking for Auth-Application id or application id? because as i am checking auth application id 4 is coming in CER msg but CUR and CUA is not coming can you clarify why it is happening ?

      Delete
    5. Hi

      For CUR; node must advertise Application ID as 10.

      It is not necessary that if a node supports CUR must send CUR immediately after CER; CUR shall be sent if there is change in capabilities of node at the run time.

      Hope it suffice you.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. I am Starter to Diameter Protocol, can some one help me with the difference between Origin Host and Origin Realm?

    ReplyDelete
    Replies
    1. Origin host is a particular machine/node in a domain.
      Realm specifies the domain e.g. gmail.com.
      So, to specify a unique node in a network, both origin host and origin realm is required. e.g.

      machine1@gmail.com which specifies that this message is originated by machine1 of gmail domain.
      Hope this will clarify your doubt.

      Delete
    2. Yep just a point to add ,Origin-Host can be unique session-id/client name

      Delete
  4. Hi ,
    The below thing and the above post is contradicting can you please elaborate for CER and CUR for App id 10

    There are two nodes Node-A and Node-B where Node-A supports App-1 and App-2 while Node-B supports App-1 only. These nodes shall exchange their common Application ID “App-1” in CER/CEA message. Now Node-B is to be upgraded where it can also support App-2 so there is no need to break the diameter/transport connection to tell Node-A about “App-2”. Here in this case Node-B shall trigger the CER with supported applications “App-1” and “App-2” with Auth-Application-Id set to 10.

    ReplyDelete
    Replies
    1. HI Krishna,

      We hope following points shall help you.

      1) Node-A shall publish 3 application Ids viz. App-1, App-2, 10. Similarly Node-B shall publish App-1, 10. Common application IDs in CER/CEA shall be App-1,10.

      2)Node-B shall advertise App-2 by sending CUR containing App-1 and App-2.


      Thanks for your query.

      Happy to help you again.
      Team-Diameter

      Delete
  5. Can CUR message be initiated by SERVER peer too ? ?

    ReplyDelete
    Replies
    1. Hi Jai Dembla,

      CUR can be initiated by any Node (Client or Server) because capabilities up-gradation can take place in any application whether it is client or server.

      We hope it suffice your query.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  6. Team,
    can CER/CEA message be relayed, proxied or redirected.?

    ReplyDelete
    Replies
    1. Hi

      NO, we can't relay,proxy or redirect CER/CEA and DWR/DWA.

      Thanks for your query.
      Happy to help you again
      Team-Diameter

      Delete
  7. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Hi Prashant,

      Following links shall help you for detailed information.

      1) For Functioning of Relay, Proxy and Redirects

      http://diameter-protocol.blogspot.in/2012/07/diameter-agents.html

      2) Example of Redirect Agent
      http://diameter-protocol.blogspot.in/2012/07/message-processing-at-redirect-agent.html

      3) Example of Message flow from Relay and Proxy

      http://diameter-protocol.blogspot.in/2011/05/diameter-message-structure-and-message.html


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  8. does any has link or doc where i can read complete diameter call flow messages ( CCR, CCA, CCR-T) etc. i can't find in here.?

    ReplyDelete
  9. from below( point 1,2), both are working on some messages i.e. routing messages.
    Diameter relay only routes while proxy can route , also it can change message and AVP format, my question which message actually are beeing routed and changes here.? as you said before that CER/CEA, DWR/DWA can't be routed or proxied, then which messages are getting routed and modified by Diameter relay and diameter proxy agents respectively.




    1) Diameter Relay
    It is used to rout the message to other diameter node with the help of routing information received in message such as Destination-Realm, Destination -Host. Relay can accept the request with multiple networks.
    Relay must not change message format and avps except the routing avps. Relay must advertise its Application Identifier (0xffffffff).

    2)Diameter Proxy
    Diameter Proxy does all that relay does. Moreover proxy can change message and avp format if required to apply some policies.

    ReplyDelete
    Replies
    1. Hi Prashant,

      There are many message that can be proxied such as AIR, ULR on S6a interface.

      Similarly there could be many case where one can use proxy such as suppose you want to conceal identity of a node when message goes out of its realm then proxy shall change the origin-host AVP and keep a mapping so that when answer comes shall be forwarded to right node.

      Thanks for your query.
      Happy to help you again.
      Dinesh

      Delete
  10. thanks Dinesh,
    can you explain a bit AIR, ULR messages and about S6a interface?

    ReplyDelete
    Replies
    1. Hi Prashant

      Following link shall help you.
      http://diameter-protocol.blogspot.in/2012/07/s6as6d.html

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  11. Dear Team Diameter,

    Appreciate your work for simplifying the flows of protocol. Can you let me know what all diameter messages are being communicated between AF and PCRF in a 3GPP LTE network..??

    Thanks in Advance

    ReplyDelete
  12. Dear Antriksh,

    Thanks for your appreciation. we are working on PCRF Part.


    Happy to help you again.
    Team Diameter

    ReplyDelete
    Replies
    1. Dear Team,

      Okay. pls share me once Done.


      Delete
    2. Following Messages are communicated between AF and PCRF:
      1. RAR/RAA (PCRF to the AF)
      2. AAR/AAA (AF to the PCRF)
      3. ASR/ASA (PCRF to the AF)
      4. STR/STA (AF to the PCRF)

      Delete
  13. I have a question regarding Diameter, can you please answer this ?
    Let us consider one server sent one diameter request to the host1.com.Can i receive a response from another host say host2.com for that particular request. Is this a valid scenario ?

    ReplyDelete
    Replies
    1. Response shall follow the same path that request has traversed.

      Delete