Re: [Tsvwg] End point and association Address conflict

Hi Qiaobing,

see my comments below.

Best regards
Michael

On Monday, April 29, 2002, at 07:40 PM, Qiaobing Xie wrote:

> Hi, Michael,
>
> I think two simple rules will be sufficient. Let me use an example to
> illustrate them.
>
> Assume we have the following endpoints and associations in place:
>
> on local host         on remote host(s)
> A1: E1 <-----------------> E3
> A2: E1 <---------------------> E4
> A3: E2 <-------------------------> E5
>
> Rule 1: whenever adding an SCTP transport to a local endpoint, make sure
> this same transport is NOT already present in other existing endpoints
> (e.g., you don't want to add one of E1's transport to E2).
>
> Rule 2: when adding a transport to a local endpoint that has
> associations to multiple peers (ie, a fan-out config), one MUST send an
> add-ip ASCONF to each of those peers. And the new transport can only be
> used until ALL the peers ack successfully. If anyone of the peers denies
> the add-ip then you can't add it. So, if you add a new transport to E1
> above, you have to send ASCONF to both E3 and E4 and have to get a
> positive ack from both of them.
>
I do NOT like this rule. How do you handle the case if E3 and E4 support 
AddIP, but
E5 does not. Do you say that you can not add an address to E1 because 
one of the peers
does not support AddIP? for deployment this means that AddIP only be 
used if all
implementations support this...
Why not add it to E1, but it is not allowed to be used as a source 
address for A5.
> -Qiaobing
>
> Tuexen Michael wrote:
>>
>> Dear all,
>>
>> looking at the discussion it seems that we have only one restriction
>> for add-IP:
>>
>> Consider the set E of all SCTP end points at a host. Partition
>> E = E_1 union E_2 union ... E_65535
>> into disjoint sets E_P of all end points having port P.
>>
>> When adding an IP-address to multiple end points, all of these
>> end points MUST belong to different E_P.
>>
>> This means that an SCTP implementation has to choose from all end 
>> points
>> having the same port on end point to which the add IP procedure is 
>> applied.
>>
>> Another point:
>> Consider two associations
>> A1: E1 <-> E2  (The SCTP implementation of E2 is AddIP capable.)
>> A2: E1 <-> E3  (The SCTP implementation of E3 is not AddIP capable.)
>>
>> Now you add an IP address to E1 and get E1'. So A1 is now E1' <-> E2.
>> Then we consider A2 also as A2 : E1' <-> E3, but the stack will never
>> use the added address. Is this correct usage of terminology?
>>
>> Best regards
>> Michael
>>
>> Michael Tuexen    Tel.:   +49 89 722 47210
>> Siemens AG        Fax:    +49 89 722 48212
>> ICN WN CC SE 7    E-mail: Michael.Tuexen@icn.siemens.de
>>
>>> -----Original Message-----
>>> From: Qiaobing Xie [SMTP:qxie1@email.mot.com]
>>> Sent: Friday, April 26, 2002 2:45 AM
>>> To:   Ivan.Arias-Rodriguez@nokia.com
>>> Cc:   randall@stewart.chicago.il.us; s_balani@trillium.com; Qiaobing 
>>> Xie; mo_khan@trillium.com; tsvwg@ietf.org
>>> Subject:      Re: [Tsvwg] End point and association Address conflict
>>>
>>> Ivan.Arias-Rodriguez@nokia.com wrote:
>>> ....
>>>>         Now I have another doubt... Imagine that we have an endpoint
>>>> E1 with addresses IPa, IPb and port 1. We have an association A1
>>>> that only uses IPa, whose peer is IPz and port 65535. Thus the
>>>> association A1 can be represented as [(IPa; Port1), (IPz; Port 
>>>> 65535)].
>>>> What happens now if we receive an INIT from IPz/65535 directed to 
>>>> IPb/1?
>>>>
>>>>         As IPb is not being used in A1, we should answer with an
>>>> INIT ACK as in a normal establishment of an association. However,
>>>> when you receive an INIT chunk, you include all the addresses of the 
>>>> endpoint
>>>                                       ^^^^^^^^^^^^^
>>> Here your "..include all the addr..." directly violated the "under no
>>> circumstance can an SCTP transport address ever be present in more 
>>> than
>>> one SCTP endpoint" rule (see last the paragraph, page 23 of the SCTP
>>> book).
>>>
>>>         E1               E2
>>> A1 = [(IPa; Port1), (IPz; Port 65535)]
>>>
>>>         E3                 E2
>>> A2 = [(IPa, IPb; Port1), (IPz; Port 65535)]
>>>
>>> And you have IPa/Port1 present in both E1 and E3 (they are TWO 
>>> different
>>> endpoints by definition!). This is prohibited by the SCTP association
>>> definition.
>>>
>>> -Qiaobing
>>>
>>>> in the INIT ACK chunk... But we have to be careful, because in
>>>> this case, when receiving the COOKIE ECHO, we have two options:
>>>
>>>
>>> _______________________________________________
>>> tsvwg mailing list
>>> tsvwg@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>>
Michael.Tuexen@micmac.franken.de

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg