|
Open Diameter Software Architecture |
|
|
|
|
Written by Hemanshu Patel
|
|
Friday, 28 December 2007 |
|
Page 2 of 4 Peer with IO Objects The peer objects are instances of diameter peer information as known to the local diameter entity. These instances are generated based on the locally configure peer table. Currently, there is no support for dynamically learned peers but the model allows itself to accommodate such feature. In addition to peer information, the IO objects are class abstractions to underlying transports. These transports are defined in [RFC3588] as system specific transports (any of the required or optional transport) that must be used with diameter. The base IO objects defines a specific asynchronous behavior that each of the underlying transport must support. During initialization, instances of the Peer IO objects are created and asynchronous connection attempts to the known peers are made. The result of this connection attempt will be passed on the a Peer FSM object associated with this IO object. The IO object also exposes send and receive functions to the Peer FSM to provide generic IO services to a connected peer. Peer FSM Objects A Peer FSM object implements the peer state machine as described in Sec. 5.6 of [RFC3588]. It strictly follows all state transition procedures including election. Since this object is also contained within an AAA_Job, all state transitions are thread safe and atomic from an external point of view. To facilitate election, each FSM object has references to two (2) Peer IO objects. One for an initiator and one for a responder. Initiator objects are IO objects that has successfully completed an asynchronous connection attempt to a peer. Responder objects are IO objects that has been created by an IO acceptor factory as described below. During election, both of these IO objects maybe active until the result of the election deactivate one of them. Deactivation will result in deletion of the IO object. Session Delivery Objects The session delivery objects are responsible for delivering all incomming AAAMessage to a specific AAA session. The messages that the Peer FSM Objects have deemed to be incomming session messages are consumed by this object. The session delivery object determines the AAASession object that the message belongs to by querying the message's session id AVP. The delivery object searches the local session database for a matching session. If no matching session is found, the delivery object will lookup a matching session factory object that has an application id matching the application id of the message. If there is a registered session factory, then the delivery object will ask the factory to create a new session and delivery the message to the newly created session. If non of these lookup's are successful, the session delivery object will silently discard the message. As with FSM objects, the session delivery objects are derived from AAA_Job hence they are thread independent. Session FSM Object The session FSM objects are responsible for implementing the authorization and accounting state machine as described in Diameter User Session, Sec 8. of [RFC3588]. The user sessions are all based on AAASession objects defined in the Open Diameter API. Dervied objects specializing in client/server authorization sessions and client/server accounting sessions also exists in the API definitions. As discussed in the API, session ojbects allows users to registering event handlers on a per-session basis. The session FSM object is the holder of all registered event handers for a particular session. The implementation is straight forward and follows Sec 8. of [RFC3588] consistenly. This object is the consumer of all AAAMessage that passed through the session delivery object. After some perfoming pre-processing on each message to update it's internal state, the Session FSM object will eventually pass all non-base protocol session messages to registered event handlers. As with the Peer FSM objects, this object also derives from AAA_Job and hence it is thread safe. As of this writing, the session objects are still in thier original linear implementation (i.e. only switch statements are used for state transition) and has not been migrated to the the Open Diameter Framework FSM.
|
Diameter Protocol 