rfc3588.txt

ietf 的dimater基本协议

   be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT
   message (graceful closure is compromised).

2.1.1.  SCTP Guidelines

   The following are guidelines for Diameter implementations that
   support SCTP:

   1. For interoperability: All Diameter nodes MUST be prepared to
      receive Diameter messages on any SCTP stream in the association.

   2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
      streams available to the association to prevent head-of-the-line
      blocking.

2.2.  Securing Diameter Messages

   Diameter clients, such as Network Access Servers (NASes) and Mobility
   Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS].
   Diameter servers MUST support TLS and IPsec.  The Diameter protocol
   MUST NOT be used without any security mechanism (TLS or IPsec).

   It is suggested that IPsec can be used primarily at the edges and in
   intra-domain traffic, such as using pre-shared keys between a NAS a
   local AAA proxy.  This also eases the requirements on the NAS to
   support certificates.  It is also suggested that inter-domain traffic
   would primarily use TLS.  See Sections 13.1 and 13.2 for more details
   on IPsec and TLS usage.

2.3.  Diameter Application Compliance

   Application Identifiers are advertised during the capabilities
   exchange phase (see Section 5.3).  For a given application,
   advertising support of an application implies that the sender
   supports all command codes, and the AVPs specified in the associated
   ABNFs, described in the specification.

   An implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs.  Please
   refer to Section 11.1.1 for details.








Calhoun, et al.             Standards Track                    [Page 21]

RFC 3588                Diameter Based Protocol           September 2003


2.4.  Application Identifiers

   Each Diameter application MUST have an IANA assigned Application
   Identifier (see Section 11.3).  The base protocol does not require an
   Application Identifier since its support is mandatory.  During the
   capabilities exchange, Diameter nodes inform their peers of locally
   supported applications.  Furthermore, all Diameter messages contain
   an Application Identifier, which is used in the message forwarding
   process.

   The following Application Identifier values are defined:

      Diameter Common Messages      0
      NASREQ                        1 [NASREQ]
      Mobile-IP                     2 [DIAMMIP]
      Diameter Base Accounting      3
      Relay                         0xffffffff

   Relay and redirect agents MUST advertise the Relay Application
   Identifier, while all other Diameter nodes MUST advertise locally
   supported applications.  The receiver of a Capabilities Exchange
   message advertising Relay service MUST assume that the sender
   supports all current and future applications.

   Diameter relay and proxy agents are responsible for finding an
   upstream server that supports the application of a particular
   message.  If none can be found, an error message is returned with the
   Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

2.5.  Connections vs. Sessions

   This section attempts to provide the reader with an understanding of
   the difference between connection and session, which are terms used
   extensively throughout this document.

   A connection is a transport level connection between two peers, used
   to send and receive Diameter messages.  A session is a logical
   concept at the application layer, and is shared between an access
   device and a server, and is identified via the Session-Id AVP












Calhoun, et al.             Standards Track                    [Page 22]

RFC 3588                Diameter Based Protocol           September 2003


          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                peer connection A   peer connection B

                   <----------------------------->
                           User session x

               Figure 1: Diameter connections and sessions

   In the example provided in Figure 1, peer connection A is established
   between the Client and its local Relay.  Peer connection B is
   established between the Relay and the Server.  User session X spans
   from the Client via the Relay to the Server.  Each "user" of a
   service causes an auth request to be sent, with a unique session
   identifier. Once accepted by the server, both the client and the
   server are aware of the session.  It is important to note that there
   is no relationship between a connection and a session, and that
   Diameter messages for multiple sessions are all multiplexed through a
   single connection.

2.6.  Peer Table

   The Diameter Peer Table is used in message forwarding, and referenced
   by the Realm Routing Table.  A Peer Table entry contains the
   following fields:

   Host identity
      Following the conventions described for the DiameterIdentity
      derived AVP data format in Section 4.4. This field contains the
      contents of the Origin-Host (Section 6.3) AVP found in the CER or
      CEA message.

   StatusT
      This is the state of the peer entry, and MUST match one of the
      values listed in Section 5.6.

   Static or Dynamic
      Specifies whether a peer entry was statically configured, or
      dynamically discovered.

   Expiration time
      Specifies the time at which dynamically discovered peer table
      entries are to be either refreshed, or expired.






Calhoun, et al.             Standards Track                    [Page 23]

RFC 3588                Diameter Based Protocol           September 2003


   TLS Enabled
      Specifies whether TLS is to be used when communicating with the
      peer.

   Additional security information, when needed (e.g., keys,
   certificates)

2.7.  Realm-Based Routing Table

   All Realm-Based routing lookups are performed against what is
   commonly known as the Realm Routing Table (see Section 12).  A Realm
   Routing Table Entry contains the following fields:

   Realm Name
      This is the field that is typically used as a primary key in the
      routing table lookups.  Note that some implementations perform
      their lookups based on longest-match-from-the-right on the realm
      rather than requiring an exact match.

   Application Identifier
      An application is identified by a vendor id and an application id.
      For all IETF standards track Diameter applications, the vendor id
      is zero.  A route entry can have a different destination based on
      the application identification AVP of the message.  This field
      MUST be used as a secondary key field in routing table lookups.

   Local Action
      The Local Action field is used to identify how a message should be
      treated.  The following actions are supported:

      1. LOCAL - Diameter messages that resolve to a route entry with
         the Local Action set to Local can be satisfied locally, and do
         not need to be routed to another server.

      2. RELAY - All Diameter messages that fall within this category
         MUST be routed to a next hop server, without modifying any
         non-routing AVPs.  See Section 6.1.8 for relaying guidelines

      3. PROXY - All Diameter messages that fall within this category
         MUST be routed to a next hop server.  The local server MAY
         apply its local policies to the message by including new AVPs
         to the message prior to routing.  See Section 6.1.8 for
         proxying guidelines.

      4. REDIRECT - Diameter messages that fall within this category
         MUST have the identity of the home Diameter server(s) appended,
         and returned to the sender of the message.  See Section 6.1.7
         for redirect guidelines.



Calhoun, et al.             Standards Track                    [Page 24]

RFC 3588                Diameter Based Protocol           September 2003


   Server Identifier
      One or more servers the message is to be routed to.  These servers
      MUST also be present in the Peer table. When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      server(s) the message must be routed to.  When the Local Action
      field is set to REDIRECT, this field contains the identity of one
      or more servers the message should be redirected to.

   Static or Dynamic
      Specifies whether a route entry was statically configured, or
      dynamically discovered.

   Expiration time
      Specifies the time which a dynamically discovered route table
      entry expires.

   It is important to note that Diameter agents MUST support at least
   one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
   Agents do not need to support all modes of operation in order to
   conform with the protocol specification, but MUST follow the protocol
   compliance guidelines in Section 2.  Relay agents MUST NOT reorder
   AVPs, and proxies MUST NOT reorder AVPs.

   The routing table MAY include a default entry that MUST be used for
   any requests not matching any of the other entries.  The routing
   table MAY consist of only such an entry.

   When a request is routed, the target server MUST have advertised the
   Application Identifier (see Section 2.4) for the given message, or
   have advertised itself as a relay or proxy agent.  Otherwise, an
   error is returned with the Result-Code AVP set to
   DIAMETER_UNABLE_TO_DELIVER.

2.8.  Role of Diameter Agents

   In addition to client and servers, the Diameter protocol introduces
   relay, proxy, redirect, and translation agents, each of which is
   defined in Section 1.3.  These Diameter agents are useful for several
   reasons:

   -  They can distribute administration of systems to a configurable
      grouping, including the maintenance of security associations.

   -  They can be used for concentration of requests from an number of
      co-located or distributed NAS equipment sets to a set of like user
      groups.

   -  They can do value-added processing to the requests or responses.



Calhoun, et al.             Standards Track                    [Page 25]

RFC 3588                Diameter Based Protocol           September 2003


   -  They can be used for load balancing.

   -  A complex network will have multiple authentication sources, they
      can sort requests and forward