Subject: [Tsvwg] SCTP Parameter relationships (in RFC2960 12.*)

From: Douglas Clowes <[email-masked]>
Date: Wed, 24 Oct 2001 22:50:45 +1000

I'm confused about the difference between the SCTP instance in 12.1 and its
relationship with the SCTP association in 12.2 of RFC 2960.

My confusion arises due to the SCTP Port being in 12.1 instead of 12.2 as I
would have  thought that an instance, having many associations, would be
independent of the SCTP Port. Similarly, each SCTP association could be
related to a different SCTP Port.

I'm further confused by the description of the Address List in 12.1, as
being passed to one's peer(s) in INIT and INIT ACK chunks. I would have
thought that it was the Local Transport Address List that fitted this
description, and that the latter was a subset of the former.

Unfortunately, SCTP instance does not appear to be defined, at least not in
1.4 Key Kerms. But that sedction does define SCTP Association as the
transport addresses of the endpoints. It further defines the "transport
address" to include the "transport layer port number" which implies that
SCTP port should be moved from 12.1 to 12.2.

Could we have a definition of SCTP Instance, and the relationship between
it and SCTP Association?

Douglas Clowes

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Wed, 24 Oct 2001 08:46:37 -0500

Douglas:

A few comments on the TCB (which is what is in chapter 12).

First I think one must understand that this is an example only to
give the reader an idea of what things an implementor would put
in a TCB. Some implementations will add to this list and some
may even find creative ways of taking things out of this list
or combining in some fashion. For example the BSD/KAME SCTP kernel
version we are working on will NOT hold a list of addresses IF you
do a bind to all addresses. The only time a list of addresses is
needed is when sub-set binding is performed or during a transition
when adding a IP address (or deleting).

Now more to your points... or I will attempt to answer them anyway :>

> relationship with the SCTP association in 12.2 of RFC 2960.

When we wrote this section it was decided to divide things into multiple
parts
i.e. 

A) Things you hold no matter if you have ANY associations up or not
(this
   first section) 

B) Things that one would have only if there was an association up

and

C) Things that are specific to a destination address within an
association.

So to your query above.. I MUST keep an SCTP port number to which
I have bound my endpoint and say will be accepting associations or
even initating associations. No matter if I have an association up. In
other words the act of opening a socket and doing a bind... OR opening
a socket and doing your first assocation outward will force you to
assign a port from the sctp port space in the stack to the socket and
thus the endpoint/file descriptor (fd) etc (what ever your o/s uses
to track these things). So this fd (I think in *NIX terms here since
I have worked with it for more than 20 years.. ee-gads!) is in my
mind the instance we associate the port to. The association, when I
form one, I would associate a peers port and its addresses... 

In fact this is exactly how BSD kernels work.. the inpcb structure
does have a PORT u-short for the local port... We need to break
this model a bit to have our UDP model socket interface but that
is a different issue ...

> related to a different SCTP Port.

This was a top down thing... your port is associated with your bound 
(via bind()) file desciptor. Your peers port would appear in 12.2 being
associated with a particular association. If one wanted one could copy
it into the association structure as well... I did not .. but one could.

> description, and that the latter was a subset of the former.

You have a base set of addresses that are bound to the endpoint.
When you send a INIT (or INIT-ACK) you copy this 12.1 address list
out to tell the peer here are my addresses... Depending you may copy
this into the association since, at least in theory, if I have
bound all and start an association... if another interface card
is plugged in and ifconfig'd up the base instance (socket if you will)
will now have a DIFFERENT LIST of addresses associated with it than
the list that is on the association started prior to the card insert.
Of course the add-ip draft can fix this by adding this in.

In the kernel work we are doing we only fill in this list if you
are using sub-set binding OR you have bound all and during the
transition
between adding an IP address (i.e. sending the ASCONF) and awaiting for
the ASCONF ack. When we release it the kernel implementation will
include
all extension drafts.... but alas it is still a work in progress and
I must get back to coding if I hold any hope of getting it done
soon :>

You may want to look at the sctp reference implementation at
www.sctp.org
and in particular in

sctpstruct.h there is a 

struct SCTP

and

struct sctp_association

These follow the RFC farily closely and may alleviate your confusion
somewhat.. or maybe make it worse :> good luck...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)