Subject: [AAA-WG]: Issue #67: How to deal with CER and CEA in the case of SCTP

From: Tony Johansson <[email-masked]>
Date: Wed, 06 Jun 2001 11:46:21 -0700

All,

Here is one more issue....

/Tony

Issue 67:  How to deal with CER and CEA in the case of SCTP
Submitter name: Tony Johansson
Submitter email address: [email-masked]
Date first submitted: 2001-06-06
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 8.0
Rationale/Explanation of issue:

The text defined in 8.0 is obviously based on the TCP case (even though
its not explicitly  stated) and there is no case described that covers
the SCTP case.

So, when we now have changed the DRI to CER and CEA, who will issue the
CER in the SCTP case? To my understanding, the SCTP protocol can't tell
the upper layer, which one of the the peers that first initiated the
connection request in the case that both peers issued a connection
establishment request almost at the same time. The SCTP protocol is a
peer-to-peer protocol, so this type of issue is resolved by various
mechanisms in the SCTP protocol itself. The upper layer is guaranteed to
always get one connection between the peers. So the I-connection and
R-connection, which are need in the TCP case doesn't make sense for SCTP
case and the problem right now is that the CER and CEA is based on the
I-xx and R-xx (which is determined from indications from the TCP
transport layer).

IMHO, I suggest that we go back and use something like the DRI. Because
as soon as we have one single transport connection established it
doesn't really matter, which peer that issues its capability exchange
message first. This would make the capability exchange flow independent
from specific indications from the transport layer which may or may not
be present depending on the transport layer in use.

Comments...

---

From: Tony Johansson <[email-masked]>
Date: Wed, 20 Jun 2001 15:30:25 -0700

All,

The new text in section 8.0 Peer Sate Machine supports both the behavior of
SCTP and TCP under the condition that the port on which a connection is
initiated MUST NOT be the port Diameter listens for incoming connections.

Form all of the previous mail discussions I think we all agree that this is
the correct assumption in the TCP case, but what about SCTP? In the SCTP
case you can use the same port to initiate connections as well as listening
for incoming connections. Under these circumstances, the normal operation of
SCTP will guarantee you only get one transport layer connection, even if
both sides start to initiate the connection at the same time, and there is
no need for the I- and R- connection functionality currently defined in the
state machine. The drawback in this situation is that SCTP may not be able
to tell you whether or not you are deemed the initiator- it ONLY guarantees
that you get ONE connection. So, to allow SCTP to use the same port, would
unfortunately require some additional handling of the CER and CEA :(,
because as soon as the transport connection is established both peers may
ending up issuing CER.

I'm not sure how far we should go on this issue. I don't have any problems
to reject and close this issue #67 if I'm the only one who sees any utility
in allowing incoming and outgoing SCTP connection requests to use the same
port.

However, if we do see some advantages in this, we only need some additional
text that deals with the case that a peer receives a CER instead of an CEA,
like the following.

In the case Diameter is configured over SCTP to initiate and listen for
connection requests on the same port, SCTP will not make use of the I- and
R- states defined in the state machine. Under these circumstances, in the
event that two peers attempt to connect at the same time, SCTP will
automatically resolve the connection requests into a single connection, and
both peers may issue CER.  When both peers send the CER and then receive the
CER from the other peer instead of a CEA, it MUST in these cases treat the
received CER as a CEA.

Comments, please.

/Tony