Subject: [AAA-WG]: transport MUSTs

From: Jari Arkko <[email-masked]>
Date: Thu, 03 May 2001 14:51:17 +0300

Hi.

I fear this may have been discussed in-depth already,
but we were reading the specs and came up with the
following:

Servers are required to support both SCTP and TCP
transports. Clients are required to support TCP.

Our question is, why do we require the latter
part? If servers are required to support both
transports, wouldn't it be sufficient to require
clients to support either TCP or SCTP?

Also, section 1.1 says that Diameter should be
transported over SCTP. How should this be
interpreted with respect to the first information
piece above. Or does this statement mean that
when multiple transports are available, SCTP
should be used?

Jari

---

From: David Frascone <[email-masked]>
Date: Thu, 3 May 2001 08:19:16 -0500

> clients to support either TCP or SCTP?

I believe the intent of that sentance was not to force clients to 
implement TCP, but to allow them to communicate even if they don't have
SCTP support.  So, I think the intent of that sentance was: clients
MUST support either TCP or SCTP.  The wording of the ID should be changed.

> when multiple transports are available, SCTP

I believe that was the intent.  SCTP is the preferred Diameter transport.

-Dave

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 07:08:55 -0700

> transports. Clients are required to support TCP.

correct, however, the actual text for clients is:

"Diameter clients MUST
support TCP, but are warned that future versions of this specification
may mandate SCTP support."

> clients to support either TCP or SCTP?

The general feeling was that requiring SCTP on embedded systems was 
difficult at the moment, but this could change in the future.

So clients should use TCP (but can, of course, use SCTP if they support it),
and servers communicate with each other using SCTP.

> when multiple transports are available, SCTP

Thanks for that. The last paragraph in section 1.1 needs to be deleted.

Thanks,

PatC

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 May 2001 17:28:22 +0300

> difficult at the moment, but this could change in the future.

Sure.. but see below

> and servers communicate with each other using SCTP.

Yeah... but this wasn't exactly the issue. The issue
from our client implementation people is: they have SCTP
and they don't want to do TCP at all. Given the
requirements that we already placed on the servers
(SCTP *and* TCP), I was proposing that it would
make sense to relax the client requirements so
that you could do either SCTP or TCP. This would
be good for the client folks who have SCTP, would
make no difference to servers, and would make no
difference to client folks who have just TCP.

Jari

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 07:31:55 -0700

> difference to client folks who have just TCP.

ok, I see your point. So the language can be changed slightly such
that it encourages the use of SCTP on clients, when they have the
stack.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 08:42:41 -0700

> that it encourages the use of SCTP on clients, when they have the

How does the following sound?

"  The base Diameter protocol is run on port TBD of both TCP [27] and
   SCTP [26] transport protocols (for interoperability test purposes
   port 1812 will be used until April 2001). Diameter clients SHOULD
   support SCTP, but MUST support TCP if SCTP is not available. future
   versions of this specification may mandate that clients support SCTP.
   Diameter servers MUST support both TCP and SCTP."

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 3 May 2001 20:26:28 +0300

>    Diameter servers MUST support both TCP and SCTP."

Very good!

Jari

---

From: David Frascone <[email-masked]>
Date: Thu, 3 May 2001 11:41:21 -0500

>    Diameter servers MUST support both TCP and SCTP."

Works for me.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 4 May 2001 08:29:43 -0700 (PDT)

> The wording in section 1.1 is inconsistent with the decision of the
> Interim meeting as well as WG consensus at IETF 50. SCTP support on the
> client is not a SHOULD. Please reread the interim meeting minutes and fix
> this. 
> 
Looks like you missed my response. This paragraph has been deleted from
section 1.1, since there is a whole section on transports that addresses the
decision made at the interim meeting. Look at -03 for more details.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 08:25:50 -0700 (PDT)

> and servers communicate with each other using SCTP.

Given the differing interpretations
it probably makes sense to clarify what transports are to be used when
both are available, and how client and servers can determine which
transports are in use. Remember, mandatory to implement does NOT imply
mandatory to use. So even if SCTP is available on a server or client, it
may not be enabled:

a. How does a client (or server) determine what transports are supported
on the other system? Is DNS SRV used for this? 

b. What happens if a server sends a message to client using SCTP and a
"port unreachable" is returned? Does the server retry using TCP?

c. What happens if a client sends a message to a server using TCP and a
"port unreachable" is returned. Does the client retry using SCTP?

> Thanks for that. The last paragraph in section 1.1 needs to be deleted.
Yup.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 08:18:35 -0700 (PDT)

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 4 May 2001 08:38:35 -0700

> mandatory to use. So even if SCTP is available on a server or client, it

This certain is correct.

> on the other system? Is DNS SRV used for this? 

That is one method, if DNS is used.

> "port unreachable" is returned. Does the client retry using SCTP?

The text states that SCTP support on servers is mandatory, but not on
clients. However, SCTP *is* supported on clients. So, I would urge the
WG to consider that SCTP is tried first, and if a connection fails, TCP
is tried. This favors SCTP, but does allow TCP only implementations to
operate.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 May 2001 22:43:04 -0700

David Frascone [mailto:[email-masked]] writes:

> >    port 1812 will be used until April 2001).

Hmm.  Seems like it's May 2001 currently; does that mean no more testing
until the real numbers are assigned?  Probably not ;-).  So how about

"  The base Diameter protocol is run on port TBD of both TCP [27] and
   SCTP [26] transport protocols (for interoperability test purposes
   port 1812 will be used until the official numbers are assigned). "

> >    Diameter clients SHOULD

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 10 May 2001 07:09:13 -0700

>    port 1812 will be used until the official numbers are assigned). "

A little behind in our e-mail :)

The following text is currently in version -03:

"The base Diameter protocol is run on port TBD of both TCP [27] and
SCTP [26] transport protocols (for interoperability test purposes
port 1812 will be used until IANA assigns a port to the protocol)."

Thanks,

PatC

---

From: David Spence <[email-masked]>
Date: Sun, 20 May 2001 17:36:12 -0700

Pat Calhoun wrote:
>... 

What do you mean "Diameter clients... MUST support TCP if SCTP is not
available"?  Does this mean that Diameter clients MAY support only SCTP and
not TCP as Jari requested?  If so, this does not accord with the conclusion
reached during the February interim meeting.  The reasons that clients were
required to support TCP were summarized in the February interim meeting
minutes from which I quote:

> 9. AAA Servers MUST support TCP & SCTP. NASes MUST support TCP,
> MAY support SCTP. The specification will state that "SCTP
> MAY be required in the future."   TCP is required on NASes
> because not all NASes have SCTP in their protocol stacks, because
> SCTP has problems getting past firewalls, and because neither
> TLS nor IPSEC is fully defined for SCTP.

In addition to these reasons, I believe we discussed the problem that an
SCTP-compliant server may, for a while yet, be run on a non-SCTP-compliant
host operating system and therefore it may not be possible to reach the
server via SCTP.

So I think that we still need to require that clients MUST support TCP.

Sorry for the late response.  I am just now catching up on some of the
threads in preparation for the May Interim meeting. :-(

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.