Subject: Re: [Sigtran] About "draft-vk-sigtran-isp-communication-00.txt"

From: [email-masked]
Date: Tue, 5 Mar 2002 11:16:37 +0530

Hi John,

We are currently working on a new version of this draft and would release it in
April
time frame. We will add messages and clarify the procedures as much as possible.
We will also try to add handling of any error conditions.
I have tried to reply to your queries, please see comments embedded in the mail
below.

Thanks,
Vipin

John McLaine <[email-masked]> on 03/05/2002 10:10:38 AM

To:   [email-masked]
cc:    (bcc: Vipin K Gupta/HSS)

Subject:  [Sigtran] About "draft-vk-sigtran-isp-communication-00.txt"

Vipin, Kamesh
Kindly suggest/help in the following points that are
realted to
"draft-vk-sigtran-isp-communication-00.txt":

1). After reading the draft, I think the message
distribution function would be configured with a no.
of ASPs in an AS. Now all the time, whenever there is
at least one ASP ACTIVE in the AS, all DATA from User
Parts would be distributed among all these ASPs (based
on some implementation dependent algo.), no matter
what is their current state, as Non-ACTIVE ASPs can
send DATA via the Coordinating ACTIVE ASP as well.

Sir, if my above understanding is correct then please
tell me the behavior of the system when the operator
wants to remove/add some ASP from/in service of the
AS, at run time.

>>>> Consider all active ASPs serving an AS as a pool where new ASPs can be
added and
     existing ASPs can be deleted. Any ASP serving the AS is added to this pool
as soon
     as it becomes ACTIVE for the AS. Similarly the ASP is deleted from the pool
as soon
     as it attains any state other than ACTIVE. So adding deleting an ASP should
not make
     difference with regard to this system.

2) This draft also requires that all the ASPs within
one AS and all SGPs within one SG MUST support this
extension. Peasee confirm.

>>>> Yes

3) It is not mentioned in the draft that when the peer
messages should be served. I think these should be
served in AS ACTIVE state only.

>>>> ASP(s) is ACTIVE for the concerned AS, so AS is ACTIVE. We will mention
     it explicitly in the next version of draft.

4). The draft does gives no error handling text.

>>>> We will try to add the text in the next version.

5). Section: 2.3 Mis-Sequencing Problem and its
Solution; on top of Page 13:
            "While this procedure takes place all the
data arriving at SGP2 for
     associations (a) and (b) should be buffered."

        I think DATA ( that was being sent by SGP1
before failure on associations (a) and (b) ) for
associations (a) and (b)  will be sent/forwarded to
SGP2 only on the succesfull completion of the
mentioned procedure. Or should this buffering be done
at SGP1. Please make the things clear here.

>>>> It should be SGP1 instead of SGP2. After failure of associations (a) and
(b) and          before completion of the procedure (in next draft we will name
this procedure) so as to keep the user transparent of inter sp communication.
Although the time for which data shall be buffered must be chosen carefully.

6). Please confirm about Sequence Numbers:
    I think, Each ASP will maintain 'one received
sequence counter and one sent sequence counter' per
AS-SGP; where the ASP is configured to communicate
DATA with this SGP for this AS.

>>>> Correct, an SP needs to store the last SP number received on an association
and maintain a separate counter for the messages sent on that association.
Sequence number allocation can also be driven from the fact that SCTP guarantees
sequencing within a stream only (we will try to take care of multiple stream
association in next version of the draft).

7). Kndly explain ur views in the following:
    Ideally, SGPs will serve traffic for some AS only
when some ASP wants and shows it to SGP by completing
ASPM. Suppose now traffic is ACTIVE for AS1 between
SGP1 & ASP1 and between SGP1 & ASP2. Now two cases:
    (a) ASP1 becomes Non-ACTIVE in SGP1 due to some
reasons out of ASP1's control. So SGP1 can send/forwad
traffic to it by/via ASP2. - No problem here, its OK.
    (b) ASP1 becomes Non-ACTIVE in SGP1 deliberately
(say it released association deliberately). So again
SGP1 will send/forward DATA to it by/via ASP2. Here is
problem as Ideally SGP1 now should not send traffic to
ASP1 anyway, as it seems against the basic philosophy
of ASP traffic activation process (ASP UP and then ASP
ACTIVE).
And even if SGP1 don't want to send traffic to ASP1 in
such situation, how it would DECIDE that ASP has gone
down DELIBERATELY or NON_DELIBERATELY.

>>>> Traffic is for an AS and not for ASP, ASP is just an instance of UA. But
here also all the traffic from SGP1 will be forwarded to ASP2 as ASP1 is now
incapable of handling any traffic. Draft simply says that traffic belongs to an
AS and shall be handled by ASP2 as far as SGP1 is concerned. But how ASP2 treats
the received traffic is beyond the scope of this draft. It may even forward it
to ASP1.

So kindly clarify.

regards,
John.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: John McLaine <[email-masked]>
Date: Tue, 5 Mar 2002 05:55:04 -0800 (PST)

thanx sir,
but please explain 1) and 7) from MGC point of view.
when i consider sending of User Data at MGC then
doubts arise that are specified in 1) and 7).
John.
--- [email-masked] wrote:
> Subject:  [Sigtran] About
> "draft-vk-sigtran-isp-communication-00.txt"
> 
> 
> 
> 
> Vipin, Kamesh

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/