tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6733

 
 
 

Diameter Base Protocol

Part 3 of 5, p. 58 to 87
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
5.  Diameter Peers

   This section describes how Diameter nodes establish connections and
   communicate with peers.

5.1.  Peer Connections

   Connections between diameter peers are established using their valid
   DiameterIdentity.  A Diameter node initiating a connection to a peer
   MUST know the peer's DiameterIdentity.  Methods for discovering a
   Diameter peer can be found in Section 5.2.

   Although a Diameter node may have many possible peers with which it
   is able to communicate, it may not be economical to have an
   established connection to all of them.  At a minimum, a Diameter node
   SHOULD have an established connection with two peers per realm, known
   as the primary and secondary peers.  Of course, a node MAY have
   additional connections, if it is deemed necessary.  Typically, all
   messages for a realm are sent to the primary peer but, in the event
   that failover procedures are invoked, any pending requests are sent
   to the secondary peer.  However, implementations are free to load
   balance requests between a set of peers.

   Note that a given peer MAY act as a primary for a given realm while
   acting as a secondary for another realm.

   When a peer is deemed suspect, which could occur for various reasons,
   including not receiving a DWA within an allotted time frame, no new
   requests should be forwarded to the peer, but failover procedures are
   invoked.  When an active peer is moved to this mode, additional
   connections SHOULD be established to ensure that the necessary number
   of active connections exists.

   There are two ways that a peer is removed from the suspect peer list:

   1.  The peer is no longer reachable, causing the transport connection
       to be shut down.  The peer is moved to the closed state.

   2.  Three watchdog messages are exchanged with accepted round-trip
       times, and the connection to the peer is considered stabilized.

   In the event the peer being removed is either the primary or
   secondary, an alternate peer SHOULD replace the deleted peer and
   assume the role of either primary or secondary.

Top      Up      ToC       Page 59 
5.2.  Diameter Peer Discovery

   Allowing for dynamic Diameter agent discovery makes possible simpler
   and more robust deployment of Diameter services.  In order to promote
   interoperable implementations of Diameter peer discovery, the
   following mechanisms (manual configuration and DNS) are described.
   These are based on existing IETF standards.  Both mechanisms MUST be
   supported by all Diameter implementations; either MAY be used.

   There are two cases where Diameter peer discovery may be performed.
   The first is when a Diameter client needs to discover a first-hop
   Diameter agent.  The second case is when a Diameter agent needs to
   discover another agent for further handling of a Diameter operation.
   In both cases, the following 'search order' is recommended:

   1.  The Diameter implementation consults its list of statically
       (manually) configured Diameter agent locations.  These will be
       used if they exist and respond.

   2.  The Diameter implementation performs a NAPTR query for a server
       in a particular realm.  The Diameter implementation has to know,
       in advance, in which realm to look for a Diameter agent.  This
       could be deduced, for example, from the 'realm' in an NAI on
       which a Diameter implementation needed to perform a Diameter
       operation.

       The NAPTR usage in Diameter follows the S-NAPTR DDDS application
       [RFC3958] in which the SERVICE field includes tags for the
       desired application and supported application protocol.  The
       application service tag for a Diameter application is 'aaa' and
       the supported application protocol tags are 'diameter.tcp',
       'diameter.sctp', 'diameter.dtls', or 'diameter.tls.tcp'
       [RFC6408].

       The client can follow the resolution process defined by the
       S-NAPTR DDDS [RFC3958] application to find a matching SRV, A, or
       AAAA record of a suitable peer.  The domain suffixes in the NAPTR
       replacement field SHOULD match the domain of the original query.
       An example can be found in Appendix B.

   3.  If no NAPTR records are found, the requester directly queries for
       one of the following SRV records: for Diameter over TCP, use
       "_diameter._tcp.realm"; for Diameter over TLS, use
       "_diameters._tcp.realm"; for Diameter over SCTP, use
       "_diameter._sctp.realm"; for Diameter over DTLS, use
       "_diameters._sctp.realm".  If SRV records are found, then the
       requester can perform address record query (A RR's and/or AAAA

Top      Up      ToC       Page 60 
       RR's) for the target hostname specified in the SRV records
       following the rules given in [RFC2782].  If no SRV records are
       found, the requester gives up.

   If the server is using a site certificate, the domain name in the
   NAPTR query and the domain name in the replacement field MUST both be
   valid based on the site certificate handed out by the server in the
   TLS/TCP and DTLS/SCTP or Internet Key Exchange Protocol (IKE)
   exchange.  Similarly, the domain name in the SRV query and the domain
   name in the target in the SRV record MUST both be valid based on the
   same site certificate.  Otherwise, an attacker could modify the DNS
   records to contain replacement values in a different domain, and the
   client could not validate whether this was the desired behavior or
   the result of an attack.

   Also, the Diameter peer MUST check to make sure that the discovered
   peers are authorized to act in its role.  Authentication via IKE or
   TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not
   sufficient to conclude this.  For example, a web server may have
   obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs
   may be included in the DNS, but this does not imply that it is
   authorized to act as a Diameter server.

   Authorization can be achieved, for example, by the configuration of a
   Diameter server Certification Authority (CA).  The server CA issues a
   certificate to the Diameter server, which includes an Object
   Identifier (OID) to indicate the subject is a Diameter server in the
   Extended Key Usage extension [RFC5280].  This certificate is then
   used during TLS/TCP, DTLS/SCTP, or IKE security negotiation.
   However, note that, at the time of writing, no Diameter server
   Certification Authorities exist.

   A dynamically discovered peer causes an entry in the peer table (see
   Section 2.6) to be created.  Note that entries created via DNS MUST
   expire (or be refreshed) within the DNS Time to Live (TTL).  If a
   peer is discovered outside of the local realm, a routing table entry
   (see Section 2.7) for the peer's realm is created.  The routing table
   entry's expiration MUST match the peer's expiration value.

5.3.  Capabilities Exchange

   When two Diameter peers establish a transport connection, they MUST
   exchange the Capabilities Exchange messages, as specified in the peer
   state machine (see Section 5.6).  This message allows the discovery
   of a peer's identity and its capabilities (protocol version number,
   the identifiers of supported Diameter applications, security
   mechanisms, etc.).

Top      Up      ToC       Page 61 
   The receiver only issues commands to its peers that have advertised
   support for the Diameter application that defines the command.  A
   Diameter node MUST cache the supported Application Ids in order to
   ensure that unrecognized commands and/or AVPs are not unnecessarily
   sent to a peer.

   A receiver of a Capabilities-Exchange-Request (CER) message that does
   not have any applications in common with the sender MUST return a
   Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
   DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport
   layer connection.  Note that receiving a CER or CEA from a peer
   advertising itself as a relay (see Section 2.4) MUST be interpreted
   as having common applications with the peer.

   The receiver of the Capabilities-Exchange-Request (CER) MUST
   determine common applications by computing the intersection of its
   own set of supported Application Ids against all of the
   Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and
   Vendor-Specific-Application-Id) present in the CER.  The value of the
   Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
   during computation.  The sender of the Capabilities-Exchange-Answer
   (CEA) SHOULD include all of its supported applications as a hint to
   the receiver regarding all of its application capabilities.

   Diameter implementations SHOULD first attempt to establish a TLS/TCP
   and DTLS/SCTP connection prior to the CER/CEA exchange.  This
   protects the capabilities information of both peers.  To support
   older Diameter implementations that do not fully conform to this
   document, the transport security MAY still be negotiated via an
   Inband-Security AVP.  In this case, the receiver of a Capabilities-
   Exchange-Request (CER) message that does not have any security
   mechanisms in common with the sender MUST return a Capabilities-
   Exchange-Answer (CEA) with the Result-Code AVP set to
   DIAMETER_NO_COMMON_SECURITY and SHOULD disconnect the transport layer
   connection.

   CERs received from unknown peers MAY be silently discarded, or a CEA
   MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
   In both cases, the transport connection is closed.  If the local
   policy permits receiving CERs from unknown hosts, a successful CEA
   MAY be returned.  If a CER from an unknown peer is answered with a
   successful CEA, the lifetime of the peer entry is equal to the
   lifetime of the transport connection.  In case of a transport
   failure, all the pending transactions destined to the unknown peer
   can be discarded.

   The CER and CEA messages MUST NOT be proxied, redirected, or relayed.

Top      Up      ToC       Page 62 
   Since the CER/CEA messages cannot be proxied, it is still possible
   that an upstream agent will receive a message for which it has no
   available peers to handle the application that corresponds to the
   Command Code.  In such instances, the 'E' bit is set in the answer
   message (Section 7) with the Result-Code AVP set to
   DIAMETER_UNABLE_TO_DELIVER to inform the downstream agent to take
   action (e.g., re-routing request to an alternate peer).

   With the exception of the Capabilities-Exchange-Request message, a
   message of type Request that includes the Auth-Application-Id or
   Acct-Application-Id AVPs, or a message with an application-specific
   Command Code MAY only be forwarded to a host that has explicitly
   advertised support for the application (or has advertised the Relay
   Application Id).

5.3.1.  Capabilities-Exchange-Request

   The Capabilities-Exchange-Request (CER), indicated by the Command
   Code set to 257 and the Command Flags' 'R' bit set, is sent to
   exchange local capabilities.  Upon detection of a transport failure,
   this message MUST NOT be sent to an alternate peer.

   When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
   which allow for connections to span multiple interfaces and multiple
   IP addresses, the Capabilities-Exchange-Request message MUST contain
   one Host-IP-Address AVP for each potential IP address that MAY be
   locally used when transmitting Diameter messages.

      Message Format

         <CER> ::= < Diameter Header: 257, REQ >
                   { Origin-Host }
                   { Origin-Realm }
                1* { Host-IP-Address }
                   { Vendor-Id }
                   { Product-Name }
                   [ Origin-State-Id ]
                 * [ Supported-Vendor-Id ]
                 * [ Auth-Application-Id ]
                 * [ Inband-Security-Id ]
                 * [ Acct-Application-Id ]
                 * [ Vendor-Specific-Application-Id ]
                   [ Firmware-Revision ]
                 * [ AVP ]

Top      Up      ToC       Page 63 
5.3.2.  Capabilities-Exchange-Answer

   The Capabilities-Exchange-Answer (CEA), indicated by the Command Code
   set to 257 and the Command Flags' 'R' bit cleared, is sent in
   response to a CER message.

   When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
   which allow connections to span multiple interfaces, hence, multiple
   IP addresses, the Capabilities-Exchange-Answer message MUST contain
   one Host-IP-Address AVP for each potential IP address that MAY be
   locally used when transmitting Diameter messages.

   Message Format

         <CEA> ::= < Diameter Header: 257 >
                   { Result-Code }
                   { Origin-Host }
                   { Origin-Realm }
                1* { Host-IP-Address }
                   { Vendor-Id }
                   { Product-Name }
                   [ Origin-State-Id ]
                   [ Error-Message ]
                   [ Failed-AVP ]
                 * [ Supported-Vendor-Id ]
                 * [ Auth-Application-Id ]
                 * [ Inband-Security-Id ]
                 * [ Acct-Application-Id ]
                 * [ Vendor-Specific-Application-Id ]
                   [ Firmware-Revision ]
                 * [ AVP ]

5.3.3.  Vendor-Id AVP

   The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
   the IANA "SMI Network Management Private Enterprise Codes"
   [ENTERPRISE] value assigned to the Diameter Software vendor.  It is
   envisioned that the combination of the Vendor-Id, Product-Name
   (Section 5.3.7), and Firmware-Revision (Section 5.3.4) AVPs may
   provide useful debugging information.

   A Vendor-Id value of zero in the CER or CEA message is reserved and
   indicates that this field is ignored.

Top      Up      ToC       Page 64 
5.3.4.  Firmware-Revision AVP

   The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
   used to inform a Diameter peer of the firmware revision of the
   issuing device.

   For devices that do not have a firmware revision (general-purpose
   computers running Diameter software modules, for instance), the
   revision of the Diameter software module may be reported instead.

5.3.5.  Host-IP-Address AVP

   The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
   to inform a Diameter peer of the sender's IP address.  All source
   addresses that a Diameter node expects to use with SCTP [RFC4960] or
   DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
   including a Host-IP-Address AVP for each address.

5.3.6.  Supported-Vendor-Id AVP

   The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
   contains the IANA "SMI Network Management Private Enterprise Codes"
   [ENTERPRISE] value assigned to a vendor other than the device vendor
   but including the application vendor.  This is used in the CER and
   CEA messages in order to inform the peer that the sender supports (a
   subset of) the Vendor-Specific AVPs defined by the vendor identified
   in this AVP.  The value of this AVP MUST NOT be set to zero.
   Multiple instances of this AVP containing the same value SHOULD NOT
   be sent.

5.3.7.  Product-Name AVP

   The Product-Name AVP (AVP Code 269) is of type UTF8String and
   contains the vendor-assigned name for the product.  The Product-Name
   AVP SHOULD remain constant across firmware revisions for the same
   product.

5.4.  Disconnecting Peer Connections

   When a Diameter node disconnects one of its transport connections,
   its peer cannot know the reason for the disconnect and will most
   likely assume that a connectivity problem occurred or that the peer
   has rebooted.  In these cases, the peer may periodically attempt to
   reconnect, as stated in Section 2.1.  In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic

Top      Up      ToC       Page 65 
   connection request would not be welcomed.  The Disconnection-Reason
   AVP contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

   The Disconnect-Peer-Request message is used by a Diameter node to
   inform its peer of its intent to disconnect the transport layer and
   that the peer shouldn't reconnect unless it has a valid reason to do
   so (e.g., message to be forwarded).  Upon receipt of the message, the
   Disconnect-Peer-Answer message is returned, which SHOULD contain an
   error if messages have recently been forwarded, and are likely in
   flight, which would otherwise cause a race condition.

   The receiver of the Disconnect-Peer-Answer message initiates the
   transport disconnect.  The sender of the Disconnect-Peer-Answer
   message should be able to detect the transport closure and clean up
   the connection.

5.4.1.  Disconnect-Peer-Request

   The Disconnect-Peer-Request (DPR), indicated by the Command Code set
   to 282 and the Command Flags' 'R' bit set, is sent to a peer to
   inform it of its intentions to shut down the transport connection.
   Upon detection of a transport failure, this message MUST NOT be sent
   to an alternate peer.

      Message Format

         <DPR>  ::= < Diameter Header: 282, REQ >
                    { Origin-Host }
                    { Origin-Realm }
                    { Disconnect-Cause }
                  * [ AVP ]

5.4.2.   Disconnect-Peer-Answer

   The Disconnect-Peer-Answer (DPA), indicated by the Command Code set
   to 282 and the Command Flags' 'R' bit cleared, is sent as a response
   to the Disconnect-Peer-Request message.  Upon receipt of this
   message, the transport connection is shut down.

Top      Up      ToC       Page 66 
      Message Format

         <DPA>  ::= < Diameter Header: 282 >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ Error-Message ]
                    [ Failed-AVP ]
                  * [ AVP ]


5.4.3.   Disconnect-Cause AVP

   The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated.  A
   Diameter node MUST include this AVP in the Disconnect-Peer-Request
   message to inform the peer of the reason for its intention to shut
   down the transport connection.  The following values are supported:

      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.

      BUSY                              1
         The peer's internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.

      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The peer has determined that it does not see a need for the
         transport connection to exist, since it does not expect any
         messages to be exchanged in the near future.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

5.5.  Transport Failure Detection

   Given the nature of the Diameter protocol, it is recommended that
   transport failures be detected as soon as possible.  Detecting such
   failures will minimize the occurrence of messages sent to unavailable
   agents, resulting in unnecessary delays, and will provide better
   failover performance.  The Device-Watchdog-Request and Device-
   Watchdog-Answer messages, defined in this section, are used to pro-
   actively detect transport failures.

Top      Up      ToC       Page 67 
5.5.1.  Device-Watchdog-Request

   The Device-Watchdog-Request (DWR), indicated by the Command Code set
   to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
   traffic has been exchanged between two peers (see Section 5.5.3).
   Upon detection of a transport failure, this message MUST NOT be sent
   to an alternate peer.

      Message Format

         <DWR>  ::= < Diameter Header: 280, REQ >
                    { Origin-Host }
                    { Origin-Realm }
                    [ Origin-State-Id ]
                  * [ AVP ]

5.5.2.  Device-Watchdog-Answer

   The Device-Watchdog-Answer (DWA), indicated by the Command Code set
   to 280 and the Command Flags' 'R' bit cleared, is sent as a response
   to the Device-Watchdog-Request message.

      Message Format

         <DWA>  ::= < Diameter Header: 280 >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ Error-Message ]
                    [ Failed-AVP ]
                    [ Origin-State-Id ]
                  * [ AVP ]

5.5.3.   Transport Failure Algorithm

   The transport failure algorithm is defined in [RFC3539].  All
   Diameter implementations MUST support the algorithm defined in that
   specification in order to be compliant to the Diameter base protocol.

5.5.4.  Failover and Failback Procedures

   In the event that a transport failure is detected with a peer, it is
   necessary for all pending request messages to be forwarded to an
   alternate agent, if possible.  This is commonly referred to as
   "failover".

Top      Up      ToC       Page 68 
   In order for a Diameter node to perform failover procedures, it is
   necessary for the node to maintain a pending message queue for a
   given peer.  When an answer message is received, the corresponding
   request is removed from the queue.  The Hop-by-Hop Identifier field
   is used to match the answer with the queued request.

   When a transport failure is detected, if possible, all messages in
   the queue are sent to an alternate agent with the T flag set.  On
   booting a Diameter client or agent, the T flag is also set on any
   remaining records in non-volatile storage that are still waiting to
   be transmitted.  An example of a case where it is not possible to
   forward the message to an alternate server is when the message has a
   fixed destination, and the unavailable peer is the message's final
   destination (see Destination-Host AVP).  Such an error requires that
   the agent return an answer message with the 'E' bit set and the
   Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

   It is important to note that multiple identical requests or answers
   MAY be received as a result of a failover.  The End-to-End Identifier
   field in the Diameter header along with the Origin-Host AVP MUST be
   used to identify duplicate messages.

   As described in Section 2.1, a connection request should be
   periodically attempted with the failed peer in order to re-establish
   the transport connection.  Once a connection has been successfully
   established, messages can once again be forwarded to the peer.  This
   is commonly referred to as "failback".

5.6.  Peer State Machine

   This section contains a finite state machine that MUST be observed by
   all Diameter implementations.  Each Diameter node MUST follow the
   state machine described below when communicating with each peer.
   Multiple actions are separated by commas, and may continue on
   succeeding lines, as space requires.  Similarly, state and next state
   may also span multiple lines, as space requires.

   This state machine is closely coupled with the state machine
   described in [RFC3539], which is used to open, close, failover,
   probe, and reopen transport connections.  In particular, note that
   [RFC3539] requires the use of watchdog messages to probe connections.
   For Diameter, DWR and DWA messages are to be used.

   The I- prefix is used to represent the initiator (connecting)
   connection, while the R- prefix is used to represent the responder
   (listening) connection.  The lack of a prefix indicates that the
   event or action is the same regardless of the connection on which the
   event occurred.

Top      Up      ToC       Page 69 
   The stable states that a state machine may be in are Closed, I-Open,
   and R-Open; all other states are intermediate.  Note that I-Open and
   R-Open are equivalent except for whether the initiator or responder
   transport connection is used for communication.

   A CER message is always sent on the initiating connection immediately
   after the connection request is successfully completed.  In the case
   of an election, one of the two connections will shut down.  The
   responder connection will survive if the Origin-Host of the local
   Diameter entity is higher than that of the peer; the initiator
   connection will survive if the peer's Origin-Host is higher.  All
   subsequent messages are sent on the surviving connection.  Note that
   the results of an election on one peer are guaranteed to be the
   inverse of the results on the other.

   For TLS/TCP and DTLS/SCTP usage, a TLS/TCP and DTLS/SCTP handshake
   SHOULD begin when both ends are in the closed state prior to any
   Diameter message exchanges.  The TLS/TCP and DTLS/SCTP connection
   SHOULD be established before sending any CER or CEA message to secure
   and protect the capabilities information of both peers.  The TLS/TCP
   and DTLS/SCTP connection SHOULD be disconnected when the state
   machine moves to the closed state.  When connecting to responders
   that do not conform to this document (i.e., older Diameter
   implementations that are not prepared to received TLS/TCP and DTLS/
   SCTP connections in the closed state), the initial TLS/TCP and DTLS/
   SCTP connection attempt will fail.  The initiator MAY then attempt to
   connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP
   handshake when both ends are in the open state.  If the handshake is
   successful, all further messages will be sent via TLS/TCP and DTLS/
   SCTP.  If the handshake fails, both ends move to the closed state.

   The state machine constrains only the behavior of a Diameter
   implementation as seen by Diameter peers through events on the wire.

   Any implementation that produces equivalent results is considered
   compliant.

Top      Up      ToC       Page 70 
      state            event              action         next state
      -----------------------------------------------------------------
      Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
                       R-Conn-CER       R-Accept,        R-Open
                                        Process-CER,
                                        R-Snd-CEA

      Wait-Conn-Ack    I-Rcv-Conn-Ack   I-Snd-CER        Wait-I-CEA
                       I-Rcv-Conn-Nack  Cleanup          Closed
                       R-Conn-CER       R-Accept,        Wait-Conn-Ack/
                                        Process-CER      Elect
                       Timeout          Error            Closed

      Wait-I-CEA       I-Rcv-CEA        Process-CEA      I-Open
                       R-Conn-CER       R-Accept,        Wait-Returns
                                        Process-CER,
                                        Elect
                       I-Peer-Disc      I-Disc           Closed
                       I-Rcv-Non-CEA    Error            Closed
                       Timeout          Error            Closed

      Wait-Conn-Ack/   I-Rcv-Conn-Ack   I-Snd-CER,Elect  Wait-Returns
      Elect            I-Rcv-Conn-Nack  R-Snd-CEA        R-Open
                       R-Peer-Disc      R-Disc           Wait-Conn-Ack
                       R-Conn-CER       R-Reject         Wait-Conn-Ack/
                                                         Elect
                       Timeout          Error            Closed

      Wait-Returns     Win-Election     I-Disc,R-Snd-CEA R-Open
                       I-Peer-Disc      I-Disc,          R-Open
                                        R-Snd-CEA
                       I-Rcv-CEA        R-Disc           I-Open
                       R-Peer-Disc      R-Disc           Wait-I-CEA
                       R-Conn-CER       R-Reject         Wait-Returns
                       Timeout          Error            Closed

      R-Open           Send-Message     R-Snd-Message    R-Open
                       R-Rcv-Message    Process          R-Open
                       R-Rcv-DWR        Process-DWR,     R-Open
                                        R-Snd-DWA
                       R-Rcv-DWA        Process-DWA      R-Open
                       R-Conn-CER       R-Reject         R-Open
                       Stop             R-Snd-DPR        Closing
                       R-Rcv-DPR        R-Snd-DPA        Closing
                       R-Peer-Disc      R-Disc           Closed

Top      Up      ToC       Page 71 
      I-Open           Send-Message     I-Snd-Message    I-Open
                       I-Rcv-Message    Process          I-Open
                       I-Rcv-DWR        Process-DWR,     I-Open
                                        I-Snd-DWA
                       I-Rcv-DWA        Process-DWA      I-Open
                       R-Conn-CER       R-Reject         I-Open
                       Stop             I-Snd-DPR        Closing
                       I-Rcv-DPR        I-Snd-DPA        Closing
                       I-Peer-Disc      I-Disc           Closed

      Closing          I-Rcv-DPA        I-Disc           Closed
                       R-Rcv-DPA        R-Disc           Closed
                       Timeout          Error            Closed
                       I-Peer-Disc      I-Disc           Closed
                       R-Peer-Disc      R-Disc           Closed

5.6.1.  Incoming Connections

   When a connection request is received from a Diameter peer, it is
   not, in the general case, possible to know the identity of that peer
   until a CER is received from it.  This is because host and port
   determine the identity of a Diameter peer; the source port of an
   incoming connection is arbitrary.  Upon receipt of a CER, the
   identity of the connecting peer can be uniquely determined from the
   Origin-Host.

   For this reason, a Diameter peer must employ logic separate from the
   state machine to receive connection requests, accept them, and await
   the CER.  Once the CER arrives on a new connection, the Origin-Host
   that identifies the peer is used to locate the state machine
   associated with that peer, and the new connection and CER are passed
   to the state machine as an R-Conn-CER event.

   The logic that handles incoming connections SHOULD close and discard
   the connection if any message other than a CER arrives or if an
   implementation-defined timeout occurs prior to receipt of CER.

   Because handling of incoming connections up to and including receipt
   of a CER requires logic, separate from that of any individual state
   machine associated with a particular peer, it is described separately
   in this section rather than in the state machine above.

5.6.2.  Events

   Transitions and actions in the automaton are caused by events.  In
   this section, we will ignore the I- and R- prefixes, since the actual
   event would be identical, but it would occur on one of two possible
   connections.

Top      Up      ToC       Page 72 
   Start          The Diameter application has signaled that a
                  connection should be initiated with the peer.

   R-Conn-CER     An acknowledgement is received stating that the
                  transport connection has been established, and the
                  associated CER has arrived.

   Rcv-Conn-Ack   A positive acknowledgement is received confirming that
                  the transport connection is established.

   Rcv-Conn-Nack  A negative acknowledgement was received stating that
                  the transport connection was not established.

   Timeout        An application-defined timer has expired while waiting
                  for some event.

   Rcv-CER        A CER message from the peer was received.

   Rcv-CEA        A CEA message from the peer was received.

   Rcv-Non-CEA    A message, other than a CEA, from the peer was
                  received.

   Peer-Disc      A disconnection indication from the peer was received.

   Rcv-DPR        A DPR message from the peer was received.

   Rcv-DPA        A DPA message from the peer was received.

   Win-Election   An election was held, and the local node was the
                  winner.

   Send-Message   A message is to be sent.

   Rcv-Message    A message other than CER, CEA, DPR, DPA, DWR, or DWA
                  was received.

   Stop           The Diameter application has signaled that a
                  connection should be terminated (e.g., on system
                  shutdown).

5.6.3.  Actions

   Actions in the automaton are caused by events and typically indicate
   the transmission of packets and/or an action to be taken on the
   connection.  In this section, we will ignore the I- and R- prefixes,
   since the actual action would be identical, but it would occur on one
   of two possible connections.

Top      Up      ToC       Page 73 
   Snd-Conn-Req   A transport connection is initiated with the peer.

   Accept         The incoming connection associated with the R-Conn-CER
                  is accepted as the responder connection.

   Reject         The incoming connection associated with the R-Conn-CER
                  is disconnected.

   Process-CER    The CER associated with the R-Conn-CER is processed.

   Snd-CER        A CER message is sent to the peer.

   Snd-CEA        A CEA message is sent to the peer.

   Cleanup        If necessary, the connection is shut down, and any
                  local resources are freed.

   Error          The transport layer connection is disconnected,
                  either politely or abortively, in response to
                  an error condition.  Local resources are freed.

   Process-CEA    A received CEA is processed.

   Snd-DPR        A DPR message is sent to the peer.

   Snd-DPA        A DPA message is sent to the peer.

   Disc           The transport layer connection is disconnected,
                  and local resources are freed.

   Elect          An election occurs (see Section 5.6.4 for more
                  information).

   Snd-Message    A message is sent.

   Snd-DWR        A DWR message is sent.

   Snd-DWA        A DWA message is sent.

   Process-DWR    The DWR message is serviced.

   Process-DWA    The DWA message is serviced.

   Process        A message is serviced.

Top      Up      ToC       Page 74 
5.6.4.  The Election Process

   The election is performed on the responder.  The responder compares
   the Origin-Host received in the CER with its own Origin-Host as two
   streams of octets.  If the local Origin-Host lexicographically
   succeeds the received Origin-Host, a Win-Election event is issued
   locally.  Diameter identities are in ASCII form; therefore, the
   lexical comparison is consistent with DNS case insensitivity, where
   octets that fall in the ASCII range 'a' through 'z' MUST compare
   equally to their uppercase counterparts between 'A' and 'Z'.  See
   Appendix D for interactions between the Diameter protocol and
   Internationalized Domain Name (IDNs).

   The winner of the election MUST close the connection it initiated.
   Historically, maintaining the responder side of a connection was more
   efficient than maintaining the initiator side.  However, current
   practices makes this distinction irrelevant.

6.  Diameter Message Processing

   This section describes how Diameter requests and answers are created
   and processed.

6.1.  Diameter Request Routing Overview

   A request is sent towards its final destination using one of the
   following three combinations of the Destination-Realm and
   Destination-Host AVPs:

   o  A request that is not able to be proxied (such as a CER) MUST NOT
      contain either Destination-Realm or Destination-Host AVPs.

   o  A request that needs to be sent to a home server serving a
      specific realm, but not to a specific server (such as the first
      request of a series of round trips), MUST contain a Destination-
      Realm AVP but MUST NOT contain a Destination-Host AVP.  For
      Diameter clients, the value of the Destination-Realm AVP MAY be
      extracted from the User-Name AVP, or other methods.

   o  Otherwise, a request that needs to be sent to a specific home
      server among those serving a given realm MUST contain both the
      Destination-Realm and Destination-Host AVPs.

   The Destination-Host AVP is used as described above when the
   destination of the request is fixed, which includes:

   o  Authentication requests that span multiple round trips.

Top      Up      ToC       Page 75 
   o  A Diameter message that uses a security mechanism that makes use
      of a pre-established session key shared between the source and the
      final destination of the message.

   o  Server-initiated messages that MUST be received by a specific
      Diameter client (e.g., access device), such as the Abort-Session-
      Request message, which is used to request that a particular user's
      session be terminated.

   Note that an agent can only forward a request to a host described in
   the Destination-Host AVP if the host in question is included in its
   peer table (see Section 2.6).  Otherwise, the request is routed based
   on the Destination-Realm only (see Section 6.1.6).

   When a message is received, the message is processed in the following
   order:

   o  If the message is destined for the local host, the procedures
      listed in Section 6.1.4 are followed.

   o  If the message is intended for a Diameter peer with whom the local
      host is able to directly communicate, the procedures listed in
      Section 6.1.5 are followed.  This is known as "Request
      Forwarding".

   o  The procedure listed in Section 6.1.6 is followed, which is known
      as "Request Routing".

   o  If none of the above are successful, an answer is returned with
      the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the 'E'
      bit set.

   For routing of Diameter messages to work within an administrative
   domain, all Diameter nodes within the realm MUST be peers.

   The overview contained in this section (6.1) is intended to provide
   general guidelines to Diameter developers.  Implementations are free
   to use different methods than the ones described here as long as they
   conform to the requirements specified in Sections 6.1.1 through
   6.1.9.  See Section 7 for more details on error handling.

6.1.1.  Originating a Request

   When creating a request, in addition to any other procedures
   described in the application definition for that specific request,
   the following procedures MUST be followed:

Top      Up      ToC       Page 76 
   o  the Command Code is set to the appropriate value;

   o  the 'R' bit is set;

   o  the End-to-End Identifier is set to a locally unique value;

   o  the Origin-Host and Origin-Realm AVPs MUST be set to the
      appropriate values, used to identify the source of the message;
      and

   o  the Destination-Host and Destination-Realm AVPs MUST be set to the
      appropriate values, as described in Section 6.1.

6.1.2.  Sending a Request

   When sending a request, originated either locally or as the result of
   a forwarding or routing operation, the following procedures SHOULD be
   followed:

   o  The Hop-by-Hop Identifier SHOULD be set to a locally unique value.

   o  The message SHOULD be saved in the list of pending requests.

   Other actions to perform on the message based on the particular role
   the agent is playing are described in the following sections.

6.1.3.  Receiving Requests

   A relay or proxy agent MUST check for forwarding loops when receiving
   requests.  A loop is detected if the server finds its own identity in
   a Route-Record AVP.  When such an event occurs, the agent MUST answer
   with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

6.1.4.  Processing Local Requests

   A request is known to be for local consumption when one of the
   following conditions occurs:

   o  The Destination-Host AVP contains the local host's identity;

   o  The Destination-Host AVP is not present, the Destination-Realm AVP
      contains a realm the server is configured to process locally, and
      the Diameter application is locally supported; or

   o  Both the Destination-Host and the Destination-Realm are not
      present.

Top      Up      ToC       Page 77 
   When a request is locally processed, the rules in Section 6.2 should
   be used to generate the corresponding answer.

6.1.5.  Request Forwarding

   Request forwarding is done using the Diameter peer table.  The
   Diameter peer table contains all of the peers with which the local
   node is able to directly communicate.

   When a request is received, and the host encoded in the Destination-
   Host AVP is one that is present in the peer table, the message SHOULD
   be forwarded to the peer.

6.1.6.  Request Routing

   Diameter request message routing is done via realms and Application
   Ids. A Diameter message that may be forwarded by Diameter agents
   (proxies, redirect agents, or relay agents) MUST include the target
   realm in the Destination-Realm AVP.  Request routing SHOULD rely on
   the Destination-Realm AVP and the Application Id present in the
   request message header to aid in the routing decision.  The realm MAY
   be retrieved from the User-Name AVP, which is in the form of a
   Network Access Identifier (NAI).  The realm portion of the NAI is
   inserted in the Destination-Realm AVP.

   Diameter agents MAY have a list of locally supported realms and
   applications, and they MAY have a list of externally supported realms
   and applications.  When a request is received that includes a realm
   and/or application that is not locally supported, the message is
   routed to the peer configured in the routing table (see Section 2.7).

   Realm names and Application Ids are the minimum supported routing
   criteria, additional information may be needed to support redirect
   semantics.

6.1.7.  Predictive Loop Avoidance

   Before forwarding or routing a request, Diameter agents, in addition
   to performing the processing described in Section 6.1.3, SHOULD check
   for the presence of a candidate route's peer identity in any of the
   Route-Record AVPs.  In the event of the agent detecting the presence
   of a candidate route's peer identity in a Route-Record AVP, the agent
   MUST ignore such a route for the Diameter request message and attempt
   alternate routes if any exist.  In case all the candidate routes are
   eliminated by the above criteria, the agent SHOULD return a
   DIAMETER_UNABLE_TO_DELIVER message.

Top      Up      ToC       Page 78 
6.1.8.  Redirecting Requests

   When a redirect agent receives a request whose routing entry is set
   to REDIRECT, it MUST reply with an answer message with the 'E' bit
   set, while maintaining the Hop-by-Hop Identifier in the header, and
   include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.  Each of
   the servers associated with the routing entry are added in a separate
   Redirect-Host AVP.

                     +------------------+
                     |     Diameter     |
                     |  Redirect Agent  |
                     +------------------+
                      ^    |    2. command + 'E' bit
       1. Request     |    |    Result-Code =
      joe@example.com |    |    DIAMETER_REDIRECT_INDICATION +
                      |    |    Redirect-Host AVP(s)
                      |    v
                  +-------------+  3. Request  +-------------+
                  | example.com |------------->| example.net |
                  |    Relay    |              |   Diameter  |
                  |    Agent    |<-------------|    Server   |
                  +-------------+  4. Answer   +-------------+

                     Figure 5: Diameter Redirect Agent

   The receiver of an answer message with the 'E' bit set and the
   Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the Hop-by-
   Hop Identifier in the Diameter header to identify the request in the
   pending message queue (see Section 5.5.4) that is to be redirected.
   If no transport connection exists with the new peer, one is created,
   and the request is sent directly to it.

   Multiple Redirect-Host AVPs are allowed.  The receiver of the answer
   message with the 'E' bit set selects exactly one of these hosts as
   the destination of the redirected message.

   When the Redirect-Host-Usage AVP included in the answer message has a
   non-zero value, a route entry for the redirect indications is created
   and cached by the receiver.  The redirect usage for such a route
   entry is set by the value of Redirect-Host-Usage AVP and the lifetime
   of the cached route entry is set by Redirect-Max-Cache-Time AVP
   value.

   It is possible that multiple redirect indications can create multiple
   cached route entries differing only in their redirect usage and the
   peer to forward messages to.  As an example, two(2) route entries
   that are created by two(2) redirect indications results in two(2)

Top      Up      ToC       Page 79 
   cached routes for the same realm and Application Id.  However, one
   has a redirect usage of ALL_SESSION, where matching requests will be
   forwarded to one peer; the other has a redirect usage of ALL_REALM,
   where request are forwarded to another peer.  Therefore, an incoming
   request that matches the realm and Application Id of both routes will
   need additional resolution.  In such a case, a routing precedence
   rule MUST be used against the redirect usage value to resolve the
   contention.  The precedence rule can be found in Section 6.13.

6.1.9.  Relaying and Proxying Requests

   A relay or proxy agent MUST append a Route-Record AVP to all requests
   forwarded.  The AVP contains the identity of the peer from which the
   request was received.

   The Hop-by-Hop Identifier in the request is saved and replaced with a
   locally unique value.  The source of the request is also saved, which
   includes the IP address, port, and protocol.

   A relay or proxy agent MAY include the Proxy-Info AVP in requests if
   it requires access to any local state information when the
   corresponding response is received.  The Proxy-Info AVP has security
   implications as state information is distributed to other entities.
   As such, it is RECOMMENDED that the content of the Proxy-Info AVP be
   protected with cryptographic mechanisms, for example, by using a
   keyed message digest such as HMAC-SHA1 [RFC2104].  Such a mechanism,
   however, requires the management of keys, although only locally at
   the Diameter server.  Still, a full description of the management of
   the keys used to protect the Proxy-Info AVP is beyond the scope of
   this document.  Below is a list of common recommendations:

   o  The keys should be generated securely following the randomness
      recommendations in [RFC4086].

   o  The keys and cryptographic protection algorithms should be at
      least 128 bits in strength.

   o  The keys should not be used for any other purpose than generating
      and verifying instances of the Proxy-Info AVP.

   o  The keys should be changed regularly.

   o  The keys should be changed if the AVP format or cryptographic
      protection algorithms change.

   The message is then forwarded to the next hop, as identified in the
   routing table.

Top      Up      ToC       Page 80 
   Figure 6 provides an example of message routing using the procedures
   listed in these sections.

       (Origin-Host=nas.example.net)    (Origin-Host=nas.example.net)
       (Origin-Realm=example.net)       (Origin-Realm=example.net)
       (Destination-Realm=example.com)  (Destination-Realm=example.com)
                                        (Route-Record=nas.example.net)
      +------+      ------>      +------+      ------>      +------+
      |      |     (Request)     |      |      (Request)    |      |
      | NAS  +-------------------+ DRL  +-------------------+ HMS  |
      |      |                   |      |                   |      |
      +------+     <------       +------+     <------       +------+
     example.net    (Answer)   example.net     (Answer)   example.com
          (Origin-Host=hms.example.com)   (Origin-Host=hms.example.com)
          (Origin-Realm=example.com)      (Origin-Realm=example.com)

                  Figure 6: Routing of Diameter messages

   Relay and proxy agents are not required to perform full inspection of
   incoming messages.  At a minimum, validation of the message header
   and relevant routing AVPs has to be done when relaying messages.
   Proxy agents may optionally perform more in-depth message validation
   for applications in which it is interested.

6.2.  Diameter Answer Processing

   When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:

   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.

   o  The local host's identity is encoded in the Origin-Host AVP.

   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.

   o  The Result-Code AVP is added with its value indicating success or
      failure.

   o  If the Session-Id is present in the request, it MUST be included
      in the answer.

   o  Any Proxy-Info AVPs in the request MUST be added to the answer
      message, in the same order they were present in the request.

Top      Up      ToC       Page 81 
   o  The 'P' bit is set to the same value as the one in the request.

   o  The same End-to-End identifier in the request is used in the
      answer.

   Note that the error messages (see Section 7) are also subjected to
   the above processing rules.

6.2.1.   Processing Received Answers

   A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
   answer received against the list of pending requests.  The
   corresponding message should be removed from the list of pending
   requests.  It SHOULD ignore answers received that do not match a
   known Hop-by-Hop Identifier.

6.2.2.  Relaying and Proxying Answers

   If the answer is for a request that was proxied or relayed, the agent
   MUST restore the original value of the Diameter header's Hop-by-Hop
   Identifier field.

   If the last Proxy-Info AVP in the message is targeted to the local
   Diameter server, the AVP MUST be removed before the answer is
   forwarded.

   If a relay or proxy agent receives an answer with a Result-Code AVP
   indicating a failure, it MUST NOT modify the contents of the AVP.
   Any additional local errors detected SHOULD be logged but not
   reflected in the Result-Code AVP.  If the agent receives an answer
   message with a Result-Code AVP indicating success, and it wishes to
   modify the AVP to indicate an error, it MUST modify the Result-Code
   AVP to contain the appropriate error in the message destined towards
   the access device as well as include the Error-Reporting-Host AVP; it
   MUST also issue an STR on behalf of the access device towards the
   Diameter server.

   The agent MUST then send the answer to the host that it received the
   original request from.

6.3.  Origin-Host AVP

   The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
   it MUST be present in all Diameter messages.  This AVP identifies the
   endpoint that originated the Diameter message.  Relay agents MUST NOT
   modify this AVP.

Top      Up      ToC       Page 82 
   The value of the Origin-Host AVP is guaranteed to be unique within a
   single host.

   Note that the Origin-Host AVP may resolve to more than one address as
   the Diameter peer may support more than one address.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

6.4.  Origin-Realm AVP

   The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.
   This AVP contains the Realm of the originator of any Diameter message
   and MUST be present in all messages.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

6.5.  Destination-Host AVP

   The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
   This AVP MUST be present in all unsolicited agent initiated messages,
   MAY be present in request messages, and MUST NOT be present in answer
   messages.

   The absence of the Destination-Host AVP will cause a message to be
   sent to any Diameter server supporting the application within the
   realm specified in Destination-Realm AVP.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

6.6.  Destination-Realm AVP

   The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity
   and contains the realm to which the message is to be routed.  The
   Destination-Realm AVP MUST NOT be present in answer messages.
   Diameter clients insert the realm portion of the User-Name AVP.
   Diameter servers initiating a request message use the value of the
   Origin-Realm AVP from a previous message received from the intended
   target host (unless it is known a priori).  When present, the
   Destination-Realm AVP is used to perform message routing decisions.

   The CCF for a request message that includes the Destination-Realm AVP
   SHOULD list the Destination-Realm AVP as a required AVP (an AVP
   indicated as {AVP}); otherwise, the message is inherently a non-
   routable message.

Top      Up      ToC       Page 83 
   This AVP SHOULD be placed as close to the Diameter header as
   possible.

6.7.  Routing AVPs

   The AVPs defined in this section are Diameter AVPs used for routing
   purposes.  These AVPs change as Diameter messages are processed by
   agents.

6.7.1.  Route-Record AVP

   The Route-Record AVP (AVP Code 282) is of type DiameterIdentity.  The
   identity added in this AVP MUST be the same as the one received in
   the Origin-Host of the Capabilities Exchange message.

6.7.2.  Proxy-Info AVP

   The Proxy-Info AVP (AVP Code 284) is of type Grouped.  This AVP
   contains the identity and local state information of the Diameter
   node that creates and adds it to a message.  The Grouped Data field
   has the following CCF grammar:

         Proxy-Info ::= < AVP Header: 284 >
                        { Proxy-Host }
                        { Proxy-State }
                      * [ AVP ]

6.7.3.  Proxy-Host AVP

   The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity.  This
   AVP contains the identity of the host that added the Proxy-Info AVP.

6.7.4.  Proxy-State AVP

   The Proxy-State AVP (AVP Code 33) is of type OctetString.  It
   contains state information that would otherwise be stored at the
   Diameter entity that created it.  As such, this AVP MUST be treated
   as opaque data by other Diameter entities.

6.8.  Auth-Application-Id AVP

   The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
   is used in order to advertise support of the Authentication and
   Authorization portion of an application (see Section 2.4).  If
   present in a message other than CER and CEA, the value of the Auth-
   Application-Id AVP MUST match the Application Id present in the
   Diameter message header.

Top      Up      ToC       Page 84 
6.9.  Acct-Application-Id AVP

   The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
   is used in order to advertise support of the accounting portion of an
   application (see Section 2.4).  If present in a message other than
   CER and CEA, the value of the Acct-Application-Id AVP MUST match the
   Application Id present in the Diameter message header.

6.10.  Inband-Security-Id AVP

   The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
   is used in order to advertise support of the security portion of the
   application.  The use of this AVP in CER and CEA messages is NOT
   RECOMMENDED.  Instead, discovery of a Diameter entity's security
   capabilities can be done either through static configuration or via
   Diameter Peer Discovery as described in Section 5.2.

   The following values are supported:


   NO_INBAND_SECURITY 0

      This peer does not support TLS/TCP and DTLS/SCTP.  This is the
      default value, if the AVP is omitted.

   TLS 1

      This node supports TLS/TCP [RFC5246] and DTLS/SCTP [RFC6083]
      security.

6.11.  Vendor-Specific-Application-Id AVP

   The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
   Grouped and is used to advertise support of a vendor-specific
   Diameter application.  Exactly one instance of either Auth-
   Application-Id or Acct-Application-Id AVP MUST be present.  The
   Application Id carried by either Auth-Application-Id or Acct-
   Application-Id AVP MUST comply with vendor-specific Application Id
   assignment described in Section 11.3.  It MUST also match the
   Application Id present in the Diameter header except when used in a
   CER or CEA message.

   The Vendor-Id AVP is an informational AVP pertaining to the vendor
   who may have authorship of the vendor-specific Diameter application.
   It MUST NOT be used as a means of defining a completely separate
   vendor-specific Application Id space.

Top      Up      ToC       Page 85 
   The Vendor-Specific-Application-Id AVP SHOULD be placed as close to
   the Diameter header as possible.

      AVP Format

      <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                           { Vendor-Id }
                                           [ Auth-Application-Id ]
                                           [ Acct-Application-Id ]

   A Vendor-Specific-Application-Id AVP MUST contain exactly one of
   either Auth-Application-Id or Acct-Application-Id.  If a Vendor-
   Specific-Application-Id is received without one of these two AVPs,
   then the recipient SHOULD issue an answer with a Result-Code set to
   DIAMETER_MISSING_AVP.  The answer SHOULD also include a Failed-AVP,
   which MUST contain an example of an Auth-Application-Id AVP and an
   Acct-Application-Id AVP.

   If a Vendor-Specific-Application-Id is received that contains both
   Auth-Application-Id and Acct-Application-Id, then the recipient MUST
   issue an answer with Result-Code set to
   DIAMETER_AVP_OCCURS_TOO_MANY_TIMES.  The answer MUST also include a
   Failed-AVP, which MUST contain the received Auth-Application-Id AVP
   and Acct-Application-Id AVP.

6.12.  Redirect-Host AVP

   The Redirect-Host AVP (AVP Code 292) is of type DiameterURI.  One or
   more instances of this AVP MUST be present if the answer message's
   'E' bit is set and the Result-Code AVP is set to
   DIAMETER_REDIRECT_INDICATION.

   Upon receiving the above, the receiving Diameter node SHOULD forward
   the request directly to one of the hosts identified in these AVPs.
   The server contained in the selected Redirect-Host AVP SHOULD be used
   for all messages matching the criteria set by the Redirect-Host-Usage
   AVP.

6.13.  Redirect-Host-Usage AVP

   The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
   This AVP MAY be present in answer messages whose 'E' bit is set and
   the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.

   When present, this AVP provides hints about how the routing entry
   resulting from the Redirect-Host is to be used.  The following values
   are supported:

Top      Up      ToC       Page 86 
   DONT_CACHE 0

      The host specified in the Redirect-Host AVP SHOULD NOT be cached.
      This is the default value.

   ALL_SESSION 1

      All messages within the same session, as defined by the same value
      of the Session-ID AVP SHOULD be sent to the host specified in the
      Redirect-Host AVP.

   ALL_REALM 2

      All messages destined for the realm requested SHOULD be sent to
      the host specified in the Redirect-Host AVP.

   REALM_AND_APPLICATION 3

      All messages for the application requested to the realm specified
      SHOULD be sent to the host specified in the Redirect-Host AVP.

   ALL_APPLICATION 4

      All messages for the application requested SHOULD be sent to the
      host specified in the Redirect-Host AVP.

   ALL_HOST 5

      All messages that would be sent to the host that generated the
      Redirect-Host SHOULD be sent to the host specified in the
      Redirect-Host AVP.

   ALL_USER 6

      All messages for the user requested SHOULD be sent to the host
      specified in the Redirect-Host AVP.

   When multiple cached routes are created by redirect indications and
   they differ only in redirect usage and peers to forward requests to
   (see Section 6.1.8), a precedence rule MUST be applied to the
   redirect usage values of the cached routes during normal routing to
   resolve contentions that may occur.  The precedence rule is the order
   that dictate which redirect usage should be considered before any
   other as they appear.  The order is as follows:

Top      Up      ToC       Page 87 
   1.  ALL_SESSION

   2.  ALL_USER

   3.  REALM_AND_APPLICATION

   4.  ALL_REALM

   5.  ALL_APPLICATION

   6.  ALL_HOST

6.14.  Redirect-Max-Cache-Time AVP

   The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
   This AVP MUST be present in answer messages whose 'E' bit is set,
   whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and
   whose Redirect-Host-Usage AVP set to a non-zero value.

   This AVP contains the maximum number of seconds the peer and route
   table entries, created as a result of the Redirect-Host, SHOULD be
   cached.  Note that once a host is no longer reachable, any associated
   cache, peer, and routing table entries MUST be deleted.



(page 87 continued on part 4)

Next RFC Part