Before Diameter, system administrators had to manually configure the Network Access Server with the location of its AAA server, so that when a user came in, the device could send a request to the correct address. Such configuration efforts could, however, be tedious for a complex network deployment. One notable enhancement in Diameter is its peer discovery capability. Besides manual configuration, which must be supported by all Diameter nodes, two options -- SRVLOC and DNS -- may be supported for dynamic peer discovery. The concept here is that it is required for Diameter server, or Diameter agent, to broadcast which applications they support, along with the provided security level.
Diameter clients can then depend on the desired Diameter application, security level, and realm info to look up suitable first-hop Diameter nodes to which they can forward Diameter messages.
For a Diameter node, the discovered peer location as well as routing configuration will be stored locally using two Diameter tables:
Peer Table. A Peer Table is mainly used to store the host address of known Diameter nodes. Other information, like whether a Diameter node was looked up dynamically, its status, and security-related information of that node, is also included in this table.
Peer Routing Table. There are four important columns of this table requiring extra attention for message routing. The first two are the Realm Name and Application Name, which act as the selection criteria for message routing. The third is the action to be taken for the target message, which could be PROXY, RELAY, REDIRECT, or LOCAL. LOCAL means the message should be processed locally instead of forwarding to other nodes.
The last one is a reference to an entry in the Peer Table, used to determine the actual host address of the destination. Note that a Peer Routing Table will always contain a default entry for messages not meeting the routing criteria.
| |
After an appropriate peer has been discovered, the next step is to establish a connection with that peer. A connection is a physical link between two Diameter nodes. It is mandatory for the Diameter protocol to run over either TCP or SCTP. Compared with UDP, used in RADIUS, these two protocols provide more reliable transportation, which is critical for applications exchanging accounting-related information.
Given that Diameter is basically a peer-to-peer architecture; there could be more than one connection established for a particular node. Diameter protocol explicitly defines that a Diameter node must establish a connection with two peers per realm at a minimum, which act as primary and secondary contacts. Of course, additional connections could be established when necessary.
Compared with a connection, a session is a logical connection between two Diameter nodes, and can cross multiple connections. A session is actually the concept of a sequence of activities within a timeframe, and refers to the interactions between a Diameter client and a Diameter server in a given period. Each session in Diameter is associated with a client-generated Session-Id that is globally and eternally unique. The Session-Id is then used to identify a particular session during further communication.
Figure 6 shows the concept of a connection and session:
Figure 6. Session and connection in Diameter
Like most client-server communication models, a Diameter session starts by issuing a request message from the client to the server. In Diameter context, a Diameter client will send an auth-request message containing a unique Session-Id to a Diameter server (or a Diameter proxy if message forwarding is required). Note that the AVPs to be used for authentication and authorization are application-specific, and that they are not defined in the base protocol.
After accepting the auth-request message, the Diameter server may include an Authorization-Lifetime AVP in the response messaging. This AVP is used to indicate the amount of time in seconds that the Diameter client needs to be re-authorized. After the timeout and acceptable Auth-Grace-Period have passed, the Diameter server will remove the session from its session list and release all resources allocated for the session.
During the session, a Diameter server might initiate a re-authentication or re-authorization request. With prepaid service, this type of request is used to check whether the user is still engaging the service, and if not, the server removes the session to avoid further charging.
Also, the Origin-State-Id AVP is used for the inference of exceptional session closure. The sender of a request will include this AVP, and because it is required for the value of this AVP to be monotonically increased, the receiver of the request can easily infer that the previous session was closed, either because the access device was abnormally shutdown or because of some other exceptional situation. The request receiver can then remove the session from its list, free the resources, and possibly notify its upper stream Diameter servers if it acts as a proxy server.
Session termination messages are only used in the context of authentication and authorization, and only when the session state was maintained. For accounting services, an accounting stop message is used instead.
A session termination message can be initiated by either the Diameter client or the Diameter server. When a session is deemed to be closed, the Diameter client sends a Session-Termination-Request message to the Diameter server. The Termination-Clause AVP is included in this request telling the Diameter server the reason why the session should be closed. Alternately, if the Diameter server detects that the session should be closed -- perhaps because the user runs out of credit or just for administrative purposes -- the Diameter server sends an Abort-Session-Request message to the Diameter client. However, depending upon different policy or usage scenarios, the Diameter client might decide not to close the session even when receiving a session termination message from the server, and let the user keep using its service.
| |
Authentication and Authorization
As we mentioned, the Diameter protocol isn't bound to a specific application running on top of it. It focuses on general message exchanging features. Because authentication and authorization mechanisms vary among applications, the Diameter base protocol doesn't define command codes and AVPs specific to authentication and authorization. It is the responsibility of Diameter applications to define their own messages and corresponding attributes based on the application's characteristics.
For example, the AA-Request message is used to carry authentication and authorization information in the NAS application, while in the SIP application (see Resources) the message is called User-Authorization-Request.
Unlike authentication and authorization, the behavior and message to be exchanged for accounting is clearly defined. Accounting in Diameter essentially follows a server directed model, which means the device that generates accounting records follows the direction of an authorization server.
Based on the user profile or any business condition, a Diameter server informs the corresponding Diameter client as to what behavior is expected, such as how often the accounting record should be sent from client to server, or if the accounting record should be generated continuously within an accounting session.
Generally speaking, depending on the service to be provided, there are two kinds of accounting records: For one-time invocation-based services, the EVENT_RECORD is used. However, if the service will be provided in a measurable period, the accounting record types START_RECORD, INTERIM_RECORD, and STOP_RECORD could be used to mark the start, update, and end of a session.
To prevent duplicated accounting records, each accounting message is associated with a Session-Id AVP along with an Accounting-Record-Number AVP. As this combination can uniquely identify an accounting record, a Diameter node acting as a Diameter agent can use this information to detect duplicated accounting messages being sent to the Diameter server, thereby avoiding unnecessary processing for the Diameter server. This situation might come from temporary network problems or client shutdowns. Also, it is required that the Diameter client keep a local cache of outgoing accounting messages until an acknowledgement message arrives.
No comments:
Post a Comment