 |
Click title to get back to main page of DiameterRA
What are Diameter Agents?
Additionaly to server and client RFC 3588 intriduces also realy,redirect, proxy and translation agents.
Diameter agents can perform numerous tasks:
- load balancing
- centralizing request dispatching
- value based pre-processing of messages
- etc.
Agents must maintain transaction state for failover purposes. Upon forwarding request, its Hop-By-Hop identifier is saved and replaced with new value. When matching response arrives Hop-By-Hop identifier is restored to value before switch. When matching answer arrives request state is released.
 Stateless agent is one that only maintains transaction state. Transaction is request/response pair.
A stateful agent is one that maintains session state information; by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered
active either until it is notified otherwise, or by expiration. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP.
Maintaining state by agents can be useful in some scenarios:
- protocol translation ( RADIUS <=> Diameter )
- Limiting resources authorized to a particular user
- Per user or transaction auditing
Relay Agent
Relay agents are responsible for sending messages to apriopriate hosts. They relay on values found is messages, for instance destination realm, etc.
Routing decisions are performed with use of list of supported realms and known peers. This is known as the Realm Routing Table.
Relay agents MAY be used to aggregate requests from multiple Network Access Servers from one region. It allows to create NASes without knowledge which they shouldnt contain ( netowrk structure ).
Moreover Relays simplify Diameter server configuration, which would change every time NAS would be added, deleted or modified.
Relay agent modifies only routing portion of message and leaves other parts of messages intact.
On the graph NAS needs to do something for suzie@example.com. Looks up its routing table and decides that this request has to be passed to relay. Relay agents makes its own lookup in routing table and sends request to apriopriate server. Server identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an
answer, which is routed back to NAS using saved transaction state.
relay MUST NOT maintain session state, but MUST maintain transaction.
since relays do not provide any application level processing they have to advertise itself with application they will relay!!!
Proxy
Proxy agents similarly to relays, route diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement.
Because of this proxies are required to maintain state of their down streem peers (e.g., access devices) to enforce resource usage, provide admission control, and provisioning.
Usages:
- call control centers
- access ISPs
Proxies that are meant to limit resources MUST maintain session state.
All proxies MUST maintain transaction state.
Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support.
Redirect Agent
This type is the simples one. It is used in scenarios where centralized routing managment is needed. Since redirect agent returns only answer to requests.
Redirect agents dont maintain session nor transaction state!!!
Translation
Transaltion agent provides transaltion service between Diameter and other protocol ( RADIUS, TACAS+ ).
Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace.
Translation agents MUST be session stateful and MUST maintain transaction state.
Translation agents MUST only advertise their locally supported applications ( since these are only ones that can be translated ).
-- Main.baranowb - 08 Jun 2006
|