Subject: Diameter SCTP-vs-TCP Transport Issues

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 18 Jan 2001 17:05:21 -0500

Here are some Diameter transport issues.  I'm not sure if this is
better targeted as comments on the "AAA Problem Statements" or the
"DIAMETER Base Protocol (18-Alpha 1)" draft.

It's been stated that the AAA Solutions paper and the Diameter base
document need to address and specify the transport mappings, e.g.
which end initiates a connection, re-establishing dropped
connections, whether long idle connections may be dropped.

Here are some issues to include on this list, if not already there:

It looks like Diameter may be transported over TCP rather than SCTP.
If so:

1. Because of the firewall problem (firewalls on the path between
two Diameter peers may not recognize the new SCTP protocol type in
the IP header, and may discard the SCTP packets), is it a valid
notion for a NAS or AAA Server to attempt an SCTP connection to a
Diameter peer, and to fall back to TCP upon failure; the thought
being that the firewall is hosing SCTP packets or that the peer's
SCTP service is not running?

2. Where the Diameter specification relies on the more robust SCTP
transport layer, compensations need to be made for features that
SCTP provides that TCP does not provide.  As one tiny example, SCTP
provides a heartbeat; so the Diameter ULP might try to set up TCP to
run its keepalive timer.  The Diameter specification needs to
indicate the places where it needs to drive certain transports
in a specific manner.

3. The DRI carries multiple IP addresses associated with the sender,
I assume for SCTP's multi-homed host support.  Since Diameter/TCP
peers will communicate using a single IP address at each end, would
a DRI for a TCP peer eliminate these unusable alternate addresses?
Or is there some unstated notion that these alternate peer IP
addresses would somehow be used over TCP transports?