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

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 09:00:05 -0700

On Thu, Jul 26, 2001 at 11:22:14AM -0400, Yiwen Jiang wrote:
> Hi Pat,
> 
> Thanks very much for the mail... Just a few more questions.
> 
> > 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.
> So, in this picture, do you mean that client, relay, and server are all
> classified as Diameter peers? I guess this is one of the confusion I have.

Yes, a peer is a Diameter node that one is communicating directly with.

> If Connection A is a peer-to-peer connection, then that implies that the
> relay can actually initiate a connection to the client? but when would this
> be the case? Isn't clients always initiate connection requests? 

It is possible for a relay to initiate a connection, since it may not know
that its peer is a client. It is for this reason that we went out of our
way to ensure that the peer state machine was designed to not allow
multiple transport connections between two peers.

> Does this mean, for example, a NASREQ client will start up, and before it
> does anything, it will try to establish a peer-to-peer connection to an
> imediate Diameter server before it can handle any user requests?

that is correct.

> Also, does this mean, that before the client start session x, it must start
> a peer to peer connection first to the relay ?

yes, but this is the same as your previous question (unless I misunderstood
the previous question).

> 	In Section 8.1, at the end
> of the state machine, it indicated a "Discon" as a new state in case of a
> few event, including the receiving of the ASR. But at the disconnect state,
> (the last line), it indicated cleanup. Are you referring to disconnect the
> peer connection? Or it must be the session "logical" disconnect then?

No, the peer state machine is section 5.6, and has no relationship with
the session state machine in 8.1. Disconnecting (or cleaning up) a session
in no way implies that it affects the peer connection.

> > > 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 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.
> Yes. But I didn't realize that a Diameter client is classified as a "peer"
> here... (contradictory terms in my mind, but maybe that is just my English.
> :)

The reason why we consider these peers is because server-initiated messages
are allowed. In the RADIUS world, this isn't allowed, so clients and
servers are fundamentally different. In Diameter, although they each have
separate functions, each can initiate connections and messages.

> > 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.
> So is the difference between Diameter client and Diameter server only on who
> initiates sessions ??

No. The main difference is that the server has access to the user database,
and processes auth requests. The client doesn't, and processes auth answers.
However, the client can process other types of request messages (e.g. abort
session requests).

Hope this is clearer,

PatC

---

From: Yiwen Jiang <[email-masked]>
Date: Thu, 26 Jul 2001 11:22:14 -0400

Hi Pat,

a peer to peer connection first to the relay ? 	In Section 8.1, at the end

> 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.
Got it.

> 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.
I see.
 
> > 
> > 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?
> 

> 
> 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.
Yes. I understand what you mean.