Subject: [AAA-WG]: clarification on Session connection vs. peer connection

From: Yiwen Jiang <[email-masked]>
Date: Thu, 26 Jul 2001 09:16:34 -0400

Hi Pat,

I would like to ask a very fundamental (and possibily classified as stupid
:) question regarding the session and peer connection.

It is my understanding, that the session and peer connections are used for
separate purposes: The session connection is used only between a Diameter
client and a Diameter server to perform application related requests to the
Diameter server. Every time a session is initiated by a Diameter client, a
TCP connection is initiated to the Diameter server. (So there can be > 1 TCP
connections between a Diameter client and Diameter server). If this Diameter
server is not the home server, it will relay/proxy this request to a
connecting server via peer-to-peer connections. In fact, the peer-to-peer
connection is only used between peers to perform message relay/proxy
services as well as fail over situations.

Diameter ----------------> Diameter -----------------> Diameter
Client			   Server 1				 Server 2

	   session connection		peer connection

Is there any instances that the session based requests actually is initiated
from a Diameter server to another Diameter server, without any action of the
Diameter client? (I don't think so, but if you could confirm this, it would
be great!) I would assume that  a Diameter client is a separate application
from a Diameter server even if they can be run on the same machine?

Thank you very much for your help!

Yiwen

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 07:45:20 -0700

> :) question regarding the session and peer connection.

Let's see what I can do.

> Diameter server.

I think that it is important to note that there is a huge distinction between
a connection and a session. Let's consider the following diagram:

 +--------+            +-------+           +--------+
 | Client |            | Relay |           | Server |
 +--------+            +-------+           +--------+
           <---------->        <---------->
           Connection A        Connection B

           <------------------------------>
                       Session x

In the above example, Connection A is established between the Client and
its local Relay. This connection is essentially a transport level connection,
but we have some messages that are sent over that link for announcements
and keepalive purposes (CER/CEA and DWR/DWA, respectively). You can think
of a connection as a means to send messages to a peer.

A session, on the other hand, is an application level thing. It is virtual,
meaning that there is nothing at the transport layer that refers to a 
session. It is purely a Diameter thing. 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.
To close the session, the client must sent a session termination message,
or the server can initiate a session to be terminated as well, using a
server-initiated message.

> Every time a session is initiated by a Diameter client, a
> connections between a Diameter client and Diameter server). 

If you use the logic above, then you'll realize that all sessions are
"multiplexed" through a single connection. In fact, the protocol states that
there should only be a single connection between two peers.

> If this Diameter

Well, peer-to-peer connections are used to transmit messages. An implementation
MAY wish to process the message locally, relay or proxy the message to a
peer. When a connection is suspicious, another peer is used. So, there should
always be multiple possible peers, but it isn't necessary to have a
nailed up transport connection with all peers.

> from a Diameter server even if they can be run on the same machine?

Yes, they could run on the same machine. It is also possible for a server
to contact a server, but that would be a strange case. The one that comes to
mind is an authorization server that sends a separate request to an
authentication server. Server 1 is the authorization server, and when it
receives the answer from server 2, it sends back the successful response to
the client. Now, this is a strange case, and isn't the typical deployment,
so if you find this confusing, please disregard it.

However, here's an example of the above. Server 1 is a Diameter server,
and server 2 is a secureID server. Server 1 receives an EAP request, and
forwards the secureID auth messages to server 2. Since current SecureID
servers don't support Diameter, this isn't a real example, but is provided
for illustrative purposes.

> Thank you very much for your help!

Well, I hope I did help,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Thu, 26 Jul 2001 19:03:43 +0200

I think something close to the above would be great somewhere early in the 
draft (somewhere in section 1 or 2), to clarify the notions of connections, 
sessions (though I'm not sure sessions is actually the right name here), 
peers, nodes, etc. Some additional definitions in 1.3 of the above concepts 
might not hurt either :-)

BTW, I think this clearly reflects what I've been muttering about for a 
while about separating protocol from application-level stuff eheheh ;->

Nasty-Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com