Subject: RE: [Sigtran] ASP load sharing..

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 13:48:07 -0800

> 
> > > 
> > thanks for the pointer. Is there any mechanism for the 
> responses to go 
> > back to the same ASP ? On a distrbuted system, a request might 
> > originate from one ASP and one would expect the response to 
> go back to 
> > the same ASP. Is there anything at the SUA level to turn off load 
> > sharing so that it can be directed back to the same SCTP 
> association 
> > on which the request arrived ?
> 
> For TCAP in SUA there is the concept of the TID Label which 
> is placed in the ASPAC and tells the SG which TID ranges to 
> direct to which ASPs in Loadshare AS.  (See 4.7.3.1)  

I read it and but it never registered :-) I think this should
do the trick.

> However, this mechanism was a last minute addition and did 
> not receive sufficient discussion. As such is somewhat broken 
> for loadshare: it doesn't handle failure cases very well at 
> all and there is little to no description in the RFC as to 
> what should be done in ASP failure situations.  And of course 

I would assume that the message will still be delivered. It might
not be optimal in the AS to handle this. But at least delivering
the message seems right to me.

> this does not work with non-TCAP Class 0/1 SCCP-Users or 
> mixed CONS/CLNS SCCP-Users such as BSSAP.  For BSSAP one 
> would prefer to loadshare on components of the Complete Level 
> 3 Information.
> 
> A more general mechanism which permits the ASP to direct the 
> SG as to which loadsharing traffic flows it wishes to accept 
> are described in draft-bidulock-sigtran-loadsel-00.txt.  SUA 
> examples for a loadshare AS with load selection based on 
> Global Title are described in example in Section 5.3.  This 
> is a generic mechanism which also includes adding the Load 
> Selection parameter into the NTFY message and procedures so 
> that the remaining ASPs in the pool can assume the load of a 
> failed ASP under ASP control (rather than the SG throwing the 
> traffic at whatever ASP it wants).
> 
> Even finer control can be achieved with load grouping on top 
> of load selection as defined in draft-bidulock-sigtran-loadgrp-00.txt.
> > 
Thanks for the pointer.

> > > > 
> > > > 4) When an ASP fails, most likely it will not be able 
> to indicate to the
> > > >    SG that it failed. SCTP heartbeat may be slow to 
> discover that ASP failed.
> > > >    Is there a mechanism that can be used to indicate to 
> the SG that an ASP
> > > >    failed ?
> > > 
> > > No.
> > > 
> > Isn't this a limitation ? Don't you want to detect the ASP failures 
> > much more faster than this so that the bad ASP can be 
> reomved from the 
> > active list soon ?
> 
> It is the normal situation that the SG must detect the 
> failure of ASPs and notify the ASPs of the failure and not 
> visa versa.  This is perhaps the case because the SG, being 
> an SS7 component is expected to meet 5 or 6 9's while the ASP 
> may be less reliable.
> 
I would not make any assumptions how reliable ASP are. When an ASP
fails, you should be able to tell the SG on how it can load balance.
For example, the TID range that the old ASP was handling, needs to
be taken over by a specific ASP. Assuming that all ASP has all the state
is a bad thing. Without this it might be a bit chaotic on the AS to
get the messages to the right place.

-mohan
 
> --brian
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 15:22:41 -0700

Mohan,

Mohan Parthasarathy wrote:                                                           (Thu, 12 Dec 2002 13:48:07)
> the message seems right to me.

But to which ASP?  The point of a TID label in the first place
is that primarily one ASP maintains transaction state for a
range of transactions.  Delivering the response to an arbitrary
active ASP when the ASP responsible for that load range fails
defeats the purpose of delivering the message (or the TID label)
altogether.

> get the messages to the right place.

This is precisely what the LOADSEL draft does.  It gives control
back to the ASPs my notifying them (NTFY) when a load range
handled by an ASP fails and allows the ASPs to determine to
which ASP the failed traffic flow is diverted via a subsequent
ASPAC identifying the load range and diverting the traffic in a
focussed way.  Also, if no ASP can handle the traffic, the load
range is not activated and the SG has the information necessary
to properly reflect this within the protocol (e.g. UDTS).

--brian

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 14:42:31 -0800

> defeats the purpose of delivering the message (or the TID label)
Agreed. That's what i was trying to get at my following message..

> to properly reflect this within the protocol (e.g. UDTS).
I guess i am always looking from the ASP side :-) I know when an ASP fails.
I am just so tempted to tell SG as soon as i know it, with additional info
possibly which in this case is the TID range. Why can't we give some
control to the AS in determining failures ?

-mohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 16:11:14 -0700

Mohan,

Mohan Parthasarathy wrote:                        (Thu, 12 Dec 2002 14:42:31)
> control to the AS in determining failures ?

A minor modification to M2UA, M3UA and SUA could I believe accomplish what
you are looking for: Add ASP Id as an optional parameter to the ASP Down
message.

This would permit one ASP to execute ASP Down on the behalf of the failed
ASP.  The SG could choose to permit this behavior if it is configured to
accept it, or refuse it with Error Code "Invalid ASP Identifier".

I don't think that it is necessary for one ASP to execute ASP Inactive on
behalf of another ASP (either the ASP has failed or it can send its own
ASP Inactive).

Proposed text change would be a follows (based on SUA but applicable
to M2UA and M3UA):

--- sua-14.txt	Thu Dec 12 15:57:45 2002
+++ sua-14.mods.txt	Thu Dec 12 16:08:49 2002
@@ -2455,7 +2455,7 @@
 3.5.3 ASP Down (DOWN) 
     
    The ASP Down (DOWN) message is used to indicate to a remote SUA peer 
-   that the adaptation layer is not running. 
+   that the adaptation layer is not running on the specified ASP.

@@ -2476,13 +2476,21 @@
        0                     1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+      |            Tag = 0x0011       |             Length            | 
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+      |                        ASP Identifier                         | 
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |           Tag = 0x0004        |             Length            | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       /                          Info String                          / 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
    Parameters 
+     ASP Identifier      Optional *1
      Info String         Optional 
+
+   Note 1:  ASP Identifier is used when the ASP wishes to inform the
+            IPSP/SGP of the failure of UA layer at the specified ASP.
     
 3.5.4 ASP Down Ack (DOWN ACK) 
     
@@ -2492,15 +2500,25 @@
        0                     1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+      |            Tag = 0x0011       |             Length            | 
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+      |                        ASP Identifier                         | 
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |           Tag = 0x0004        |             Length            | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       /                          Info String                          / 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
    Parameters 
+     ASP Identifier      Optional *1
      Info String         Optional 
     
    Note: ASP DOWN ACK will always be sent to acknowledge an ASP DOWN.   
+
+   Note 1:  ASP Identifier MUST be included when the ASP Down Ack is in
+            response to an ASP Down which contained an ASP Identifier.
+	    In this case the ASP Identifier MUST be the same as the
+	    identifier used in the ASP Down.
     
 3.5.5 Heartbeat (BEAT) 
     
@@ -5346,6 +5364,19 @@
    method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive 
    carrying a negative indication.  
 
+   When an ASP detects the failure of another ASP and wishes to inform
+   the SGP of this failure, it sends an ASP Down message with the ASP
+   Identifier of the failed ASP.  The SGP MAY then act on this message
+   as though it was received from the identified ASP.  When the SGP
+   chooses to not act on this message, it MUST respone with an Error
+   ("Invalid ASP Identifier").  If the SGP chooses to act on this
+   message it MUST take the actions that it would normally take if the
+   ASP Down message was received from the specified ASP.  In addition
+   the SGP MUST respond with an ASP Down Ack message including the
+   ASP Identifier from the ASP Down to the ASP which sent the ASP
+   Down.  Also, the SGP MUST send an ASP Down Ack to the identified
+   ASP if it exists and an association exists to the identified ASP.
+
 4.3.4.3 ASP Active Procedures 
     
    Anytime after the ASP has received an ASP Up Ack message from the SGP

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 15:19:09 -0800 (PST)

Mohan,
> control to the AS in determining failures ?
[TOLGA] I think they have some control. For example
you can use override mode. Whenever a new ASP
activates itself for an AS, traffic will be diverted
to it and no more to the previously active ASP.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 15:55:39 -0800 (PST)

Brian,

Because AspID is unique per AS, I think ASPIA would be
more suitable for that purpose. In fact I think this
method would bring an advantage only for loadsharing
traffic mode, and when one ASP detects failure of
another one faster than SG.

    Tolga
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
>         0                     1                   2 
>                  3 
> +      |                        ASP Identifier      
>                   | 
>        |           Tag = 0x0004        |            
> Length            | 
>        /                          Info String       
>                   / 
>         0                     1                   2 
>                  3 
> +      |                        ASP Identifier      
>                   | 
>        |           Tag = 0x0004        |            
> Length            | 
>        /                          Info String       
>                   /

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 15:56:18 -0800

Brian,

ASP identifier usage in ASP UP may also have to be clarified to indicate
this usage. How about
taking over the TID range ? Can this be specified in the base draft itself ?
One possibility is to
include the TID range option with the ASP Down message. Your text suggests
taking it over
implicitly i guess.

> behalf of another ASP (either the ASP has failed or it can send its own
I am not sure i understand all of your concern here i.e why should this be
an optional behavior ? ASP identifier in the message can be optional and
if present why not honor it ? Please don't mistake me. I am only wondering
why it is unreasonable.

Rest of the text seems pretty okay to me.

-mohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 17:04:54 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 12 Dec 2002 15:55:39)
> another one faster than SG.

APS Id is not per AS it is per ASP.

If only the AS has failed, the ASP is still alive and can
send it own ASPIA.

True, it is most useful for for loadsharing traffic mode.
But, override with "n+m" could also make use of it.
Broadcast mode can assume the traffic of the failed ASP
without informing the SGP, so it is not useful for Broadcast
mode.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 17:12:47 -0700

Mohan,

Mohan Parthasarathy wrote:                                                           (Thu, 12 Dec 2002 15:56:18)
> this usage. How about taking over the TID range ? Can this be specified in
> the base draft itself ?

That handling is described in draft-bidulock-sigtran-loadsel-00.txt.
Do you see a problem with the loadsel draft?  Did you want to see
it advanced as an extension draft?

> One possibility is to include the TID range option with the ASP Down
> message. Your text suggests taking it over implicitly i guess.

TID range is AS specific and, therefore, cannot be included in ASPSM.
The appropriate place is in ASPTM.  If the affected ASP has not failed,
it can send its own ASPIA.  If the affected ASP has failed, ASP Down
identifying the failed ASP is appropriate so the SGP can move the ASP
to ASP-INACTIVE for all the AS (and all the TID labels) to which it
belongs.

> if present why not honor it ? Please don't mistake me. I am only wondering

If this is what you are looking for (MUST instead of MAY), that's fine with me.

--- sua-14.mods.txt	Thu Dec 12 16:08:49 2002
+++ sua-14.mods2.txt	Thu Dec 12 17:09:36 2002
@@ -5366,7 +5366,7 @@
 
    When an ASP detects the failure of another ASP and wishes to inform
    the SGP of this failure, it sends an ASP Down message with the ASP
-   Identifier of the failed ASP.  The SGP MAY then act on this message
+   Identifier of the failed ASP.  The SGP MUST then act on this message
    as though it was received from the identified ASP.  When the SGP
    chooses to not act on this message, it MUST respone with an Error
    ("Invalid ASP Identifier").  If the SGP chooses to act on this

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 16:25:53 -0800 (PST)

Brian,

What I ment was that scope for AspId is AS (sorry for
the wrong wording in my initial message), i.e. one can
have the same AspId for different AS, and because
ASPDN does not have RC as parameter, there is no way
to indicate, which ASP is really referred with that
message. Otherwise I agree that if ASP is alive but
can't serve just one AS, it can send ASPIA by itself. 
    
      Tolga

wrote:
> Tolga Asveren wrote:                                
>                                 (Thu, 12 Dec 2002
> 15:55:39)

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 16:37:22 -0800

> it advanced as an extension draft?
I am still trying to print that draft. The openss7.org seems ( or it is from
my
side) seems to have some problems. Half way through it hangs.

It seems like a useful feature. If you ask me, i would give a very
unreasonable
answer and say that the base draft should have some support for it :-) I am
not
sure how others in the WG feel about it.

> TID range is AS specific and, therefore, cannot be included in ASPSM.

Did you mean to say ASP specific ? It is part of ASP active message.

> The appropriate place is in ASPTM.  If the affected ASP has not failed,

Ok.

> to ASP-INACTIVE for all the AS (and all the TID labels) to which it
Removing it from the active list is only one step. Perhaps another message
is needed to take over the TID range. But later when ASP becomes UP,
i assume that it needs to send the TID option again.

> +++ sua-14.mods2.txt Thu Dec 12 17:09:36 2002
Sounds good to me..

-mohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 17:42:44 -0700

Tolga,

???????????????

(I still don't understand what you are trying to say.)

--brian

Tolga Asveren wrote:                                                                 (Thu, 12 Dec 2002 16:25:53)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 17:49:48 -0700

Mohan,

Mohan Parthasarathy wrote:                                                           (Thu, 12 Dec 2002 16:37:22)
> I am still trying to print that draft. The openss7.org seems ( or it is from my

Let me know off-line if you're still having problems and I will mail
them to you.

> 
> It seems like a useful feature. If you ask me, i would give a very unreasonable
> answer and say that the base draft should have some support for it :-) I am not

I think it might be better in an extension draft on the use of ASP Id.
There were a number of queries about the use of ASP Id in the first place,
so an aspid extension draft might make sense.  I'll write one if you'd like.

> Did you mean to say ASP specific ? It is part of ASP active message.

I meant AS-specific at a given ASP: i.e. it does not apply to the
ASP as a whole, but only to an AS at an ASP (as do all ASPTM messages,
but not ASPSM messages, which do apply to the ASP as a whole).

> i assume that it needs to send the TID option again.

The detecting ASP can send ASPAC for the failed TID range if it wants to
take over the traffic.

> >     ("Invalid ASP Identifier").  If the SGP chooses to act on this

Alrighty, then.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 16:58:33 -0800 (PST)

Brian,

There is ASP1, which serves AS1 and AS2. It migth have
AspID=1 for AS1 and ASPID=7 for AS2. There is also a
ASP2, which serves AS2. It has AspID=1 for AS2. Now if
ASP3 -which is serving both AS1 and AS2- sends ASPDN
to SG1 with AspID=1, how can SG1 know which ASP is
really referred to?

    Tolga
wrote:
> 16:25:53)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 18:05:47 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 12 Dec 2002 16:58:33)
> AspID=1 for AS1 and ASPID=7 for AS2.

No, it cannot.  ASP Id identifies an ASP to an SGP.  It
is the same for all AS served by that ASP and should be
the same for all SGP that make up an SG.

> There is also a ASP2, which serves AS2. It has AspID=1
> for AS2.

If ASP2 also tries to identify itself as ASPID=1 to the
same SGP, it's ASP Up will fail.

> Now if

Because ASP Id is unique to the ASP an has nothing to
do with AS.  So when you put an ASP Id in ASP Down, it
always uniquely identifies an ASP to an SGP.

--brian

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 17:10:12 -0800

Tolga,

> to it and no more to the previously active ASP.
I thought about this. I don't know how it works when there is more than one
ASP
and by default they are sharing the load. When one of them fails, if one of
the active
ASPs sends a override message, what does it mean ? Does it take over for the
other active ASPs also ?

-mohan

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 17:25:14 -0800 (PST)

Brian,

3.5.1 says "The optional ASP Identifier parameter
contains a unique value that is locally significant
among the ASPs that support an AS." Based on that I
would assume it should be possible that the same ASP
has different AspIDs for different AS. But of course
it is strange that AspID is given in ASPUP, which is
not a per AS message, which limits an ASP again with
one AspID, for all AS it serves. If AspID is
significant among the ASPs that support an AS, I would
expect it to be a parameter of ASPAC. Otherwise
especially with dynamic registration scenarios, it is
easy to have some problems or to end up with AspId
significant globally.

     Tolga 
wrote:
> 16:58:33)

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 17:30:26 -0800 (PST)

Mohan,
--- Mohan Parthasarathy <[email-masked]>
wrote:
> Tolga,
> 
> > Mohan,
> > > I guess i am always looking from the ASP side
> :-) I
> > > know when an ASP fails.
> > > I am just so tempted to tell SG as soon as i
> know
> > > it, with additional info
> > > possibly which in this case is the TID range.
> Why
> > > can't we give some
[TOLGA] For override mode, there is only one ACTIVE
ASP. Whenever another ASP sends ASPAC, previously
ACTIVE ASP becomes INACTIVE.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 18:37:28 -0700

Tolga,

Just because it is significant within an AS does not mean
that it is only non-unique outside the scope of an AS.

--brian

Tolga Asveren wrote:                          (Thu, 12 Dec 2002 17:25:14)

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 17:38:52 -0800

Brian,

> The detecting ASP can send ASPAC for the failed TID range if it wants to
Sure. But what happens when the failed ASP comes back UP, does it still
own the TID range ?

-mohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 18:41:16 -0700

Tolga,

Tolga's correct: we go rid of "n+m" sparing in Override mode.
It is now just "1+m".

--brian

Tolga Asveren wrote:                           (Thu, 12 Dec 2002 17:30:26)

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 17:48:05 -0800 (PST)

Brian,

In fact unless one gurantees that an ASP is not going
to use dynamic registration, AspID becomes globally
significant. And in any case, I think the explanation
in 3.5.1 (for M3UA) for AspID is not very clear.
BTW, I think I have an example, which is valid but
will make use of ASPDN to tell about failure of
another ASP problematic:
ASP1 serves AS1 has AspID=1
ASP2 serves AS1, AS2  has AspID=2 for both of them
ASP3 serves AS2  has AspID=1
(I think this should be valid according to M3UA RFC,
because SG knows that ASP1 and ASP3 are serving
different AS, it should allow both of them to have the
same AspID)
Now ASP2 sends ASPDN(AspID=1) to SG. How can SG know,
whether this is for ASP1 or for ASP3?

   Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 18:55:03 -0700

Mohan,

Mohan Parthasarathy wrote:                                                           (Thu, 12 Dec 2002 17:38:52)
> Sure. But what happens when the failed ASP comes back UP, does it still

Well, it is not expained in SUA, but IMO, no, becaue the SGP on receipt
of the ASP DN (ASP Id) move the ASP to the ASP-INACTIVE state for the AS
making it lose ownership of its TID label.  If the failed ASP comes up
and tries to activate for the same TID label, what happens is not specified.
Probably either the SGP would refuse it (although there is no specific Error
Code) or it would accept it an loadshare between the two.  This is just
another place where SUA labels are poorly specified.

The LOADSEL draft provides the error code "Invalid Load Selector" which
could even be augmented by "Non-Unique Load Selector" if necessary.  Also
it is clearer from Section 4.1.5 of the load selection draft what to do:

  "If the Load Selectors included in an ASPAC message contains invalid
   information or indicates an unsupported Load Selector, or a Load
   Selector parameter required by the SGP is missing, the SGP replies to
   the ASPAC message with an ERR("Invalid/Unsupported/Missing Load
   Selector") message and takes no further action with regard to AS or
   ASP state."

We could easily add duplicate to the loadsel draft.

Anyway, the recovering ASP should know from the ASP which detected its
failure that the load has been assumed by that ASP.  If the SGP returns
and error, at least it knows to go an check.  It could be possible to
put the ASP Id of the owning ASP in the Error diagnostic thus telling
the recovering ASP where to look.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 19:01:20 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 12 Dec 2002 17:48:05)
> whether this is for ASP1 or for ASP3?

No, because ASP Id was always intended to uniquely identify
the ASP.  This is to handle dynamic port allocation and
multiple ASPs connecting from the same IP address.

When ASP3 goes ASPUP (AspID=1), the SGP is fully within its
rights to return Error("Invalid ASP Identifier") as described
in section 3.8.1.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 19:05:46 -0700

Mohan,

As another note, what you are looking for can be more closely controlled
using the LOADGRP draft.  Within a load selector, the LOADGRP extension
allows you to specify the behavior within the load group much like an AS.

With load grouping, you could describe the load group for the TID range
as Override (in which case the recovering ASP will take all of the traffic
back), or loadshare or broadcast (where the recovering ASP will share the
traffic).

Take a look at draft-bidulock-loadgrp-00.txt.

--brian

Brian F. G. Bidulock wrote:                                                          (Thu, 12 Dec 2002 18:55:03)

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 18:09:42 -0800 (PST)

Brian,
wrote:
> 17:48:05)
[TOLGA] I also think so, but in a discussion a few
months ago, consensus was that AspID is unique among
ASPs serving an AS is enough from protocol point of
view (if my memory serves me right, I think you
convinced me on that saying that a more strict AspId
allocation -globally significant- is a configuration
option but not mandatory from protocol point of view
because from protocol point of view, its main use is
for NTFY("ASP Failure"), which has RC inside- :) )
So, if it is stated in IG that AspId has global
meaning, I have no problem. Otherwise, I still think
using ASPDN to report about other ASPs might be
problematic.
> rights to return Error("Invalid ASP Identifier") as
[TOLGA] Based on the current 3.5.1 I still think that
the example I gave is correct, but as I said, I am not
advocating that AspID should not have global meaning.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Dec 2002 18:29:41 -0800

Brian,

It is not clear to me as to why the ASP identifier cant' be specified in ASP
active message.
i.e what is the advantage in having two such states one active and other one
UP. Similarly
inactive and DOWN ? I am not sure whether this is explained in the draft.

thanks
mohan

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Tolga Asveren" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 12, 2002 5:05 PM
Subject: Re: [Sigtran] ASP load sharing..

> Tolga Asveren wrote:
(Thu, 12 Dec 2002 16:58:33)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 19:40:29 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 12 Dec 2002 18:09:42)
> using ASPDN to report about other ASPs might be

A little late: RFC 3331 says in section 3.3.2.1:

Note:   The ASP Identifier MUST be used where the SGP cannot 
        identify the ASP by pre-configured address/port number
        information (e.g, where an ASP is resident on a Host using
        dynamic address/port number assignment).

Pardon if RFC 3332 missed this note.

Besides, the Routing Context is optional in the Notify message
and there is no statement saying when it MUST be included.  It is
quite possible to send a Notify("ASP Failure") with an ASP Id
and without any Routing Context parameters.  This, of course,
would require that the ASP Id is unique outside the scope of the
AS.

That said, the ASP Id parameter does not have to be unique outside
the scope of the AS if the SGP does not require it.  Any of these
other uses logically requires it to be unique outside the scope of
the AS.

As the note in RFC 3331 is clear, the ASP Identifier must be unique
across ASPs connecting where the SGP cannot determine from the IP
addresses involved which ASP is connecting (NAT, other things).
This is regardless of which AS the ASPs are later configured for
or wish to activate for.

So the just of the previous conversation on this was: if your SGP
is restricted in behavior to avoid these situations where it must
be globally unique and can otherwise permit this, then fine.  If the
SGP cannot handle non-unique ASP Ids it is welcome, as I said, to
respond with Error("Invalid ASP Identifier").  Also, if the ASP does
not identify itself with an ASP Id in ASP Up, it is the SG that
configures the ASP Id used in these messages.  So again, why wouldn't
the SGP make these unique anyway?

In your example, if ASP3 even sends ASPAC for AS1, the SGP will have
to reject it based on a non-unique ASP Id.  What's it going to put
in the Error message?  Invalid Routing Context?

Sure, put in the IG that ASP Id must uniquely identify the ASP to
the SGP.  That is the only way to satisfy all the uses of ASP Id.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Dec 2002 19:43:17 -0700

Mohan,

It is not necessary in the ASP AC message because the SGP already knows
what ASP is on the other end of the SCTP association before ASP Active
can be issued.  That is, the ASP Id is implied by the SCTP association
upon which the ASP Active message arrives (and if you have the goofy
arrangement Tolga is talking about, also by considering the RC in the
ASP Active.)

--brian

Mohan Parthasarathy wrote:                                                           (Thu, 12 Dec 2002 18:29:41)
> active message.  i.e what is the advantage in having two such states one
> active and other one UP. Similarly inactive and DOWN ? I am not sure whether
> this is explained in the draft.
> 
> thanks
> mohan
>

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Dec 2002 19:08:30 -0800 (PST)

Brian,
wrote:
> 18:09:42)
[TOLGA] I hope this can be added to M3UA IG.
> would require that the ASP Id is unique outside the
[TOLGA] In fact the definition in 3.5.1 + AspId in
ASPUP forces an ASP to have the same AspID for all AS
it serves, but of course this does not mean that AspId
is global. Still for NTFY("ASP Failure") with no RC,
it will be applicable for all AS ASP is configured
for(based on 4.3.4.5) and because ASP will have the
same AspID for all the AS it serves, I wouldn't expect
a problem.
> other uses logically requires it to be unique
[TOLGA] Yes, but my point is, to be able to use ASPDN
to report failure of other ASPs without problems for
all configurations, I believe AspID should be global.
So, if this procedure is added, IMO also this note
should be added.
> in the Error message?  Invalid Routing Context?
[TOLGA]If ASP3 is configured also for AS1 on SG, then
I would expect SG to reply with Error("Invalid ASP
Identifier") to ASPUP(AspID=1) from ASP3. If ASP3 is
not configured for AS1 on SG, then I would expect SG
to reply with Error("Invalid RC") to ASPAC with
unconfigured RC from ASP3.

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 13 Dec 2002 11:21:29 -0600 (CST)

Brian,Mohan,

comment in-line

-Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

> +++ sua-14.mods2.txt	Thu Dec 12 17:09:36 2002

[samuel]
state of failed ASP is ASP_ACTIVE in SGP(because of SGP is unaware of 
this failure).
Now neighbour ASP identifies the failure and  sends
ASP-DOWN(with failed ASP ID) to SGP.
Suppose before sending ASP_DOWN message if failed ASP comes up and sends
ASP_UP message to SGP,  SGP also sends (as per section 4.3.4.1 of sua)
ASP Up Ack and ERROR message with "Unexpected Message" and ASP state is
changed to ASP_INACTIVE in all relevant Application Servers.

Now SGP receives ASP-DOWN(with failed ASPID) from neighbour ASP in
ASP_ACTIVE state and state will be changed to ASP_DOWN at SGP.

So at SGP -> failed ASP(but now in-service) is in ASP_DOWN
   at ASP -> failed ASP(but now in-service) is in ASP_INACT

 Obviously ASP will try to send ASP-ACT to SGP but SGP is in ASP_DOWN
 state, so Will it reject the message ? and What will happen to this
 ASP ?
 
 -Samuel

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 13 Dec 2002 10:02:00 -0800 (PST)

Samuel,

> changed to ASP_INACTIVE in all relevant Application
[TOLGA] When the failed ASP comes up, first it should
establish the SCTP association. This will put ASP to
DOWN state on SG.
>  state, so Will it reject the message ? and What
[TOLGA] Such a race condition might happen, but IMO
quite unlikely. I would expect SG to tear down SCTP
association to the ASP, after receiving ASPDN for it
from another ASP. So, eventually even for the scenario
you mentionm, ASP will be aware that SCTP association
is lost and will try to reestablish it.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 13 Dec 2002 10:45:20 -0800

> ACTIVE ASP becomes INACTIVE.
So, override is not a useful mode when you have more than
two ASPs. It is not obvious reading the draft though.

-mohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 12:21:15 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                   (Fri, 13 Dec 2002 11:21:29)
> >     ("Invalid ASP Identifier").  If the SGP chooses to act on this
   message it MUST take the actions that it would normally take if the
   ASP Down message was received from the specified ASP.  In addition
   the SGP MUST respond with an ASP Down Ack message including the
   ASP Identifier from the ASP Down to the ASP which sent the ASP
   Down.  Also, the SGP MUST send an ASP Down Ack to the identified
   ASP if it exists and an association exists to the identified ASP.

Perhaps you were not looking at these last six lines above

>  state, so Will it reject the message ? and What will happen to this

No, the ASP will not try to send ASP Active, because of the last two lines
above: "Also, the SGP MUST send an ASP Down Ack to the identified ASP if
it exists and an association exists to the identified ASP"

This is what we call the "unsolicited ASP Down Ack" procedure.  It is in
Section 4.2.4.2:

  "If the ASP receives an ASP Down Ack without having sent an ASP Down
   message, the ASP should now consider itself as in the ASP-DOWN state.
   If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state,
   the ASP should then initiate procedures to return itself to its
   previous state."

Requiring the SG to send ASP Down Ack to the affected ASP if an association
exists to it, ensures that it is indeed in the ASP Down state, and acts as
a race-breaker.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 12:26:49 -0700

Mohan,

Mohan Parthasarathy wrote:                        (Fri, 13 Dec 2002 10:45:20)
> two ASPs. It is not obvious reading the draft though.

The original documents had "n+m" sparing in override mode,
which was why the document might sound somewhat like it allows
it (although it doesn't anymore).

It was later that, we discovered that "n+m" (n>1) sparing
in override was just "n+m" loadshare anyway, and restricted
override to the "1+m" case.

--brian

---

From: Andrew Booth <[email-masked]>
Date: Fri, 13 Dec 2002 14:27:54 -0500

Hi Mohan,

What do you think of this approach to using override mode with multiple 
ASPs (assuming the SG supports the confuguration of routing keys of the 
appropriate granularity):

Suppose that there are two ASPs representing SCCP User X, and that they 
want to break the TIDs into two subsets C1 and C2.
Preconfigure routing contexts RC1, RC2, and RC3 as follows:

# This RC is used to loadshare messages that are not TCAP responses.
RC 100:
Traffic Mode Type: Loadshare
Routing Key:  This routing key pertains to all SCCP messages to SCCP 
User X and whose TCAP portion contains no destination TID.

# These RC's are used to get responses back to particular ASPs.
RC 1:
Traffic Mode Type: Override
Routing Key: This routing key pertains to all SCCP messages to SCCP User 
X and whose TCAP portion contains a destination TID from subset C1

RC 2:
Traffic Mode Type: Override
Routing Key: This routing key pertains to all SCCP messages to SCCP User 
X and whose TCAP portion contains a destination TID from subset C2

Each ASP goes active for RC 100, ASP 1 goes active for RC 1 and inactive 
for RC 2.  ASP 2 goes active for RC 2 and inactive for RC 1.  I think 
this provides the desired message routing, where begins get loadshared 
and responses go to the appropriate ASP.

If one ASP goes down then the usual Notify procedures can be used to 
allow the alternate ASP to take over the traffic for the failed ASP if 
it wants to.  The choice of how to handle ASP failures is left with the 
ASPs.

The only issues that I see with this approach are:
1) The SG must support the confuguration of such routing keys, which is 
not mandated by SUA.
2) What should be done with messages that have a destination TID that no 
ASP is interested in?  The logical choice would be to have a TCAP layer 
abort the dialogue.  An alternative might be to use a UDTS message, but 
this doesn't seem appropriate since the message has already been 
delivered to the SCCP User Part.

Thoughts?
Andrew

Mohan Parthasarathy wrote:

>>>>[TOLGA] I think they have some control. For
>>>>        
>>>>
>>>example
>>>      
>>>
>>>>activates itself for an AS, traffic will be
>>>>        
>>>>
>>>diverted
>>>      
>>>
>>>>Yahoo! Mail Plus - Powerful. Affordable. Sign up
>>>>        
>>>>
>>>now.
>>>      
>>>

-- 
Andrew Booth
Software Developer
Signaling Systems Group
Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 13 Dec 2002 11:30:16 -0800 (PST)

Mohan,
wrote:
> > > I thought about this. I don't know how it works
> when
> > > there is more than one
> > > ASP
> > > and by default they are sharing the load. When
> one
> > > of them fails, if one of
> > > the active
> > > ASPs sends a override message, what does it mean
> ?
> > > Does it take over for the
> > > other active ASPs also ?
[TOLGA] It is also usefull for 1+n scenarios, not just
for 1+1. The key point is that you only have one
ACTIVE ASP for override mode, and this is explained
pretty clear in "ASP Active Procedures" section for
both M3UA and SUA (for both of them section 4.3.4.3 )

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 13:08:21 -0700

Andrew,

Comments below....

Andrew Booth wrote:                                                                 (Fri, 13 Dec 2002 14:27:54)
> User X and whose TCAP portion contains no destination TID.

How to do you specify "no destination TID" to the SGP?  TID labels
do not allow you to preconfigure them at the SGP, if you want to
use them, they must be included in the ASP Active message.  In fact
all the ASPs active for an AS can receive "no destination TID".
Section 4.7.3.1 says

	"Messages not containing a destination (or "responding") TID, i.e.
	Query, Begin, Unidirectional, are loadshared amoung the available
	ASPs.  Any scheme permitting a fair load distribution amoung the ASPs
	is allowed (e.g. round robin).

	When a destination TID is present, the SG extracts the label and
	selects the ASP that corresponds to it.

	If an ASP is not available, the SG may generate (X)UDTS "routing
	failure", if the return option is used."

So, the only thing you can do here is not include a TID label when
RC 100 goes ASP Active.

> and responses go to the appropriate ASP.

As per section 4.7.3.1 above, there is no need to go to this extent to
get "no TID" messages load shared.  It is provided for in the use of
the TID label.

> it wants to.  The choice of how to handle ASP failures is left with the 

As it is for a single RC.  The SGP will notify ASP Failure for a failed
ASP to all active ASPs in the AS.  The only thing the SGP doesn't do is
tell the ASP "which" TID label failed, nor does it indicate that the
label range is "pending".  According to 4.7.3.1 it moves directly to
discard and return causes.

> 1) The SG must support the confuguration of such routing keys, which is 

Already built in: see Section 4.7.3.1.

> ASP is interested in?

Already built in: see Section 4.7.3.1.

> The logical choice would be to have a TCAP layer 

Has it?

Check out the loadsel and loadgrp draft.  These do the things that TID label
are capable of doing but have a proper set of Error, Notify, ASP Active and
ASP Inactive procedures associated with them.

--brian

---

From: Andrew Booth <[email-masked]>
Date: Fri, 13 Dec 2002 16:34:38 -0500

Hi Brian,

Comments below...

>So, the only thing you can do here is not include a TID label when
I think the question of how you configure an SGP is outside the scope of 
SUA :p
Seriously though, I'm under the impression that an SG implementation may 
support the configuration of routing keys of any granularity, even if 
such a routing key could not be configured using the existing SUA 
dynamic registration procedures.  In my email, one of the stated 
assumptions was:
       "assuming the SG supports the configuration of routing keys of 
the appropriate granularity"

And why would you want to make such an assumption?  As an example of how 
override mode might be useful in handling the situation that Mohan 
presented.  I think that if you make the above assumption then Mohan's 
stated problem is fairly well handled within the existing SUA draft, 
including the handling of most failure scenarios.  It might even be 
better handled that if you use regular loadshare with TID Labels.

>ASP Inactive procedures associated with them.
I'll take a look.

Thanks,
Andrew

-- 
Andrew Booth
Software Developer
Signaling Systems Group
Performance Technologies
613-237-4344

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 15:45:43 -0700

Andrew,

Andrew Booth wrote:                                                                 (Fri, 13 Dec 2002 16:34:38)
> I think the question of how you configure an SGP is outside the scope of 

Not when it comes to ASPs: then it is in scope.  SUA (well, all UAs)
speaks often to the configuration data at the SGP and what to do when
it exists or does not exits.

> the appropriate granularity"

TID label is not a Routing Key.  Why do you think that the parameter
does not appear in the Routing Key parameter of REG REQ?  It is a
load sharing descriptor, not a routing key.

Sure, technically I suppose the SG could use whatever it wants for
a routing key (Goededic Location for that matter), but there is also
no requirement on an SG to support every interpretation of a Routing
Key.  It is probably reasonable that primary SCCP parameters needed
by SCCP to find its user (GTT, SSN, DLR) can be expected.  Transaction
ID cannot.

> better handled that if you use regular loadshare with TID Labels.

You have another problem here: non-unique Routing Keys.  A message
with no TID overlaps between RC100 and RC1 and RC2 according to section
4.7.3.1.  Really the SGP is within its rights to refuse to accept
configuration of RC1 and RC2 after RC100 because it has a non-unique
Routing Key match for non-TID bearing messages.

	"Routing Keys are mutually exclusive in the sense that
	 a received SS7 signalling message cannot be directed to
	 more than on Routing Key."

--brian

---

From: Andrew Booth <[email-masked]>
Date: Fri, 13 Dec 2002 18:23:12 -0500

Hi Brian,

In the example I gave the ASPs just need to be provisioned regarding 
what subset of OTIDs they should use when initiating a query.  The SG 
needs more sophisticated configuration.

I don't think there's any problem with unique routing.  The reason for 
specifying in RC 100 that the message not contain a DTID is precisely to 
avoid routing key conflicts.  A given TCAP message either has a DTID or 
it doesn't.  If it does then RC 1 or RC 2 might apply, but RC100 cannot; 
if it doesn't then RC100 (only) applies.

Thoughts?
Andrew

>by SCCP to find its user (GTT, SSN, DLR) can be expected.  Transaction
I agree that not every SG implementation can be expected to provide such 
routing keys.

-- 
Andrew Booth
Software Developer
Signaling Systems Group
Performance Technologies
613-237-4344

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 19:01:53 -0700

Andrew,

Ok.  Let's get back into it.  There was much discussion on this topic at WG LC
on SUA, but here we go again:

TID Labels are not even needed unless there are multiple SGs acting as STPs.

This is because it is quite possible for an SEP SG to always route messages
for the same transaction to the same ASP.  The SG either identifies the ASP
when the transaction begins from the ASP (and remembers the Originating TID,
routing all responses back to the same ASP), or the SG loadshares over
available ASP when the transaction begins from the network and obtains the
responding ASP TID by looking for the network Originating TID in the responses
from the ASP.  It can then ensure that all the messages in the transaction go
to the same ASP.

This is not the problem that TID label was meant to address.  A single SG or
an SG acting as SEP can handle this transparently to the ASP (the ASP just
gets all the messages for the same transaction as part of the loadsharing
algorithm) without ever involving the kind of complexity in routing keys and
associating multiple RCs as you describe.

What TID label (and DRN label) was added in a half-baked attempt to handle was
the situation where there are multiple SGs acting as STPs.  In this situation
(for both CLTS and COTS), the SG does not (necessarily) see all of the
messages belonging to the same transaction or SCCP connection.  Some messages
need to route via the other SG/STP for proper loadsharing for CL and for CO
where coupling of connection sections is not performed at the STP.  For this
the SG/STP either needs a mechanism for the ASP to tell the SGP of which TIDs
and DRNs belong to it.  Two proposals were put forth.  A registration
mechanism whereby the ASP would register its ownership of TIDs and DRN on a
TID and DRN basis (the RKMM was proposed for this), and the label mechanism
(using ASPTM) that you half-see in sua-14.

We were discussing these approaches when the label approach was crammed into
SUA at WG LC without sufficient inspection.  It remained one of the many
issues to be "addressed later in an extension draft".  Well, there has been an
extension draft on the table for almost a year now: it is the loadsel and
loadgrp drafts.  There is also a sessid (session id) draft to handle
connection oriented.

There is also the TUA draft which handles transactions properly.  It is just
as foolish to attempt to handle TCAP transaction over SUA as it is to attempt
to process all but the simplest of SCCP over M3UA (GSM-A interface is about as
far as I would go with M3UA).

Now, look at the deficiencies in the error mechanism with multiple SGs acting
as STPs (the only place where TID label is really required):

When an ASP connection is lost between ASP1 and SG1 but not between ASP1 and
SG2, the ASP knows that it can route transaction messages which were normally
routed to SG1 via SG2.  SG2 knows that it can route transaction messages
within the label to ASP1.  But SG1 figures that ASP1 is dead and tells ASP2
and ASP3 about it.  Half the transactions start failing, even though there is
a viable connection between ASP1 and SG2.  Now, supposedly SG1 could start
routing this SCCP user traffic over C-links to SG2, however there is no SCCP
management for this (it would have to be performed with a cludge to MTP3) and
there is no way for the SG to know that ASP1 has not also failed to SG2 making
the rerouting of messages pointless (and possibly dangerous to the STPs
involved).

Note that in this case, half of the existing transaction fail which is not
even acceptable in terms of SIGTRAN requirements.  It must be possible to
sustain all stable calls and transactions.  So TID label is inherently flawed
in this respect.

When an ASP fails (say ASP1) connection is lost to SG1 and SG2.  Both SG1 and
SG2 notify ASP2 and ASP3 of the failure (but of course ASP2 and ASP3 do not
necessarily know which TID range the ASP1 was responsible for and the SGs
don't tell them).  Even assuming that the ASPs share transaction state (as
they are recommended to do) and that one can identify the TID label range,
while ASP1 continues to be failed, the SGs are permitted to return (X)UTDS as
described for TID label, of course resulting in the failure of all
transactions sending messages during the interval that it takes another ASP to
assume the label range.  And there is the cumbersome problems of determing
which ASP is handling which labels after multiple failures.

The loadsel and loadgrp draft solves to a large extent both problems.  When
ASP1 is only isolated from SG1, SG1 takes the action proscribed in the load
group (switches over to another ASP ready to deal with the traffic [maybe even
just route it back to ASP1]).  The second problem, where ASP1 fails, is
addressed by permitting the SGP to pend on the load selection and notify the
ASPs in the AS that it is doing so, permitting another ASP timer to pick up
the load.

I don't think that some complicated structure of SG-speciifc routing keys in a
cumbersome arrangement can to a better job than the loadsel and loadgrp
proposals.  Such a arrangement would surely not be interoperable unless
described in some IETF document, and the loadsel and loadgrp drafts already
serve that purpose.

Those are my thoughts.

--brian

Andrew Booth wrote:                           (Fri, 13 Dec 2002 18:23:12)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sat, 14 Dec 2002 00:52:50 -0600 (CST)

Tolga,Brian,

If an ASP failure has been deducted by neighbour ASP
with the help of Heartbeat procedure after timer
2*T(beat) expiry then your new modification holds
good.Because after confirming the failure(timer 
expiry), neighbour ASP sends ASP-DONW to SG.

If any other method(i think no other method) which 
finds the ASP failure without timer expiry may not 
be a good method and it may cause misunderstanding 
between SGP and ASP.This is what i wanted to clarify.

-Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Dec 2002 00:26:41 -0700

Samuel,

ASP-ASP communciation an protocols are outside the scope of the UAs.  This is
particularly true because there are many architectural approaches that can be
taken between ASPs.  Certainly heartbeat is not the only (and often, in my
experience, not the best) way to indicate failure between ASPs, whether they
be processes on the same host or separate hosts.

Some examples that come to mind are synchronized error-checking I/O buses (the
typical hot-standby of switch front-ends), two out of three vote (another
typical switching front-end approach), watchdog timers, atomic synchornization
based on reliable broadcast, leader-follower, or other coordinated system (bus
level) fault detection and recovery.

The yester-year approach of two big UNIX hosts exchanging application-level
heartbeats, was infamous for its unsatisfactory failure detection and recovery
response times, normally resulting in an undesirably large number of failed
calls/transactions.  (Typical failure detection and recover times on the order
of 10 seconds, where some of the approaches above can both detect and recover
on the order of milliseconds).

However, no UA requires nor prohibits (nor should it require or prohibit) any
given approach between ASPs.  The only mention is in the requirements,
framework and applicability documents which state that for carrier class
operation, the arrangement should not lose stable calls or transactions.

This is achieved not by trying to place a requirement on the ASP, but to allow
the SGP (as the RFCs do) to place the AS in AS-PENDING state, inform all
available ASPs in the ASP-INACTIVE state for the AS, and allow the inactive
ASPs sufficient time to assume the load.  In an SS7 node, time-controlled
procedures at Level 3 are permitted 1 to 2 seconds of witholding traffic in
this manner, so it seems reasonable that a network operators would set T(r) to
some values like 1-2 seconds.  So, unless perhaps you have a yester-year
system with recovery intervals of 10 seconds, it should be very easy for
another ASP to assume the load within these kinds of intervals.  If not, the
SG will be forced to discard some traffic because the ASP is the weak link in
the chain.

Certainly a time expiry is not necessary if the detecting ASP understands a
number of things about the failing ASP and the specific ASP architecuture.
The objective here was not to have ASPs interoperating with ASPs (intra-node),
but to have ASPs interoperating with SGPs (inter-node).

--brian

Samuel Dur D. Jeyaseelan wrote:                  (Sat, 14 Dec 2002 00:52:50)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sat, 14 Dec 2002 04:03:47 -0600 (CST)

Brian,

> be processes on the same host or separate hosts.

[samuel] But RFC does not provide any message other than heartbeat.
> but to have ASPs interoperating with SGPs (inter-node).
[samuel] yes agreed , but we can not say that ASP is dummy just because
it works as a client,take the example of 'equalization of database'
Will you achieve this with the help of SG or an ASP can equilize its
database with its mate ASP directly ?

-Samuel

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 14 Dec 2002 08:00:36 -0800 (PST)

Samuel,
--- "Samuel Dur D. Jeyaseelan"
> [samuel] But RFC does not provide any message other
[TOLGA] The heartbeat you are mentioning is the M3UA
message between SG and ASP. When using SCTP, IMO there
is not so much need for it to detect failures. How you
detect failure of an ASP from another one is totally
implementation dependent.
> database with its mate ASP directly ?
[TOLGA] IMO the proposed method assumes that an ASP
will detect failure of a mate ASP significantly faster
then a SG can detect it -which IMO is logical for most
of the cases-. If so, at least for now the method
sounds reasonable to me. I think, if one does not have
such a system(for example where SG can detect failure
in a similar time with ASP), then there is no need for
it.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Dec 2002 12:53:18 -0700

Samuel,

Section A.2.1:

   "In the process of failover, it is recommended that in the case of
    ASPs supporting call processing, stable calls do not fail.  It is
    possible that calls in "transition" may fail, although measures of
    communication between the ASPs involved can be used to mitigate this.
    For example, the two ASPs may share call state via shared memory, or
    may use an ASP to ASP protocol to pass call state information. Any
    ASP-to-ASP protocol to support this function is outside the scope of
    this document."

It is not objective of the RFC to provide mechanisms to allow ASPs to
equalize their databases.  The SGP/ASP protocols should not preclude this
from being possible, but it does not need to directly support ASP-to-ASP
communication via the SG to accomplish this either.

--brian

Samuel Dur D. Jeyaseelan wrote:                   (Sat, 14 Dec 2002 04:03:47)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 20 Dec 2002 01:14:45 -0600 (CST)

Brian and others,

These are the points concluded with the subject "Re: [Sigtran] ASP load
sharing."

1.An ASP can detect neighbour ASPs failure and indicate SG
about this failure.(but this is out of UA's scope)

2.ASP-INACT - message modified to have ASP-ID as a new field

3.ASP-DOWN  -message modified to have ASP-ID as a new field.

4.Port number and IP address can not be used to identify the
ASP because an ASP is resident on a Host using dynamic address/port
number assignment

5.Only ASP-ID discussion is pending - see below.

See the question what tolga has asked and what answer you have given.

You mean to say ASP-ID must uniquely identify an ASP to SG.
So all ASP-IDs are unique in SG.Even if an ASP is a member
of two ASs , APS-IDs are not same.If it is same then ASP-DOWN
message can not be sent to SG(on behalf of failed ASP) because
ASP-DOWN does not have RC.So ASP-ID must be unique in SG.

Suppose say a new ASP1 is coming , How does ASP1 know that which
all ASP-IDs are used and which all ASP-IDs are not used?

(this question was already asked by Chak but your is

"By saying in the IG that the ASP Id must uniquely identify
and ASP to an SG."

I could not make out anything from your answer)

 .OR.

Will ASP1 keep sending ASP-UP to SG till he finds unique ASP-ID?

(IMO,this will not be a good method.)

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Dec 2002 00:56:01 -0700

Samuel,

Please see comments below:

Samuel Dur D. Jeyaseelan wrote:                       (Fri, 20 Dec 2002 01:14:45)
> 2.ASP-INACT - message modified to have ASP-ID as a new field

Disagree.  If the ASP has supposedly only failed for a particular
AS (and is still ASPUP with the SG) then that ASP can send its
own ASP Inactive.  Leave ASP Id out of the ASPTM messages, it
is only applicable to ASPSM.

> ASP because an ASP is resident on a Host using dynamic address/port

"might be resident"

> all ASP-IDs are used and which all ASP-IDs are not used?

An ASP Id that uniquely identifies each ASP to the SG will need
to be provisioned, and an ASP that wishes to use this ASP Down
procedure on behalf of another ASP will have to be provisioned
with that ASP's ASP Id, or otherwise discover that ASP's Id from
that ASP itself, or a management system, using some exchange
outside the scope of the UA.

> (IMO,this will not be a good method.)

There is no mechanism defined for ASP to dynamically allocating
or otherwise "discover" an ASP Id from the SG.  Currently ASP Ids
must be provisioned on the ASP, and either provided to the SG in
ASP Up or provisioned on the SG as well.

Having the SG dynamically assign an ASP Id to an ASP would require
a completely new registration procedure which is probably of little
merit.  Also, such a mechanism would be difficult to impossible.
If the SG cannot identify an ASP by IP address and port (the case
where ASP Id is used in ASP Up), it cannot possibly know whether
it has previously assigned a different ASP Id to the same ASP.

It is best to let the ASPs connecting to an SG allocate their own
ASP Ids amoungst themselves, and report those ids to the SG in
the ASP Up.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 20 Dec 2002 02:54:00 -0600 (CST)

Brian,

> is only applicable to ASPSM.

Ok accepted because ASP1 and ASP2 have the same RC.
 
> ASP Ids amoungst themselves, and report those ids to the SG in

Disagree,it is too difficult to implement because How one ASP(HLR)
will know IP address+Port number of other ASP(MGC or ALR ..),
and what will be protocol used between ASPs....

I suggest the following methods.

1.When SG reveives ASP-UP , it should check whether ASP-ID is already
existing or not.IF IT  ALREADY EXIST THEN SGP MUST GIVE AN UNIQUE
ASP-ID through ASP-UP ACK to the ASP.

Note: Currently ASP-UP ACK does not have ASP-ID, so ASP-ID MUST BE
ADDED as an new field.

2.When SG reveives ASP-UP,IF ASP ID ALREADY EXIST THEN MUST GIVE ALL
ASP-ID(from his table) THROUGH AN ERROR message to ASP.

ASP will assign a new ASP-ID after seeing all ASP-IDS.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Dec 2002 03:04:31 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                 (Fri, 20 Dec 2002 02:54:00)

[snip]
> ASP will assign a new ASP-ID after seeing all ASP-IDS.

ASPs in an AS as an MGC must share call state.  ASPs in an AS as an
HLR must share transaction state.  While they are pasing call state
and transaction state back and forth, they can tell each other of
their ASP Id.

Also, if an ASP cannot determine the ASP Id of another ASP, how will
it put ASP Id in ASP Down for that ASP when it detects that ASP's
failure?  The SG cannot tell any ASP which ASP belongs to which Id,
because it just doesn't know.  The SG can only determine ASP Id from
fixed provisioning, or the ASP Id that was provided by the ASP in the
ASP Up message.

Dishing up unique IDs will accomplish nothing, as it is not possible
to tell one ASP which other ids belongs to which other ASPs, so an
ASP will have to determine this from the other ASPs or from management,
anyways, which is what I stated in the first place.

Sorry but your procedure will not work for the intended purpose of
putting ASP Id in ASP Down.

--brian

---

From: "PSK Chakravarthi" <[email-masked]>
Date: Fri, 20 Dec 2002 17:18:12 +0530

Brian,

Samuel is not talking about an ASP which need to send ASP down for another
ASP.
SGP may control 'n' number of ASPs.

ASP1 (AS1, AS2)
ASP2 (AS1,AS2,AS3)

ASP3 (AS4,AS5)
ASP4 (AS4, AS5)

So in this case ASP3/ASP4 are not having any relation with ASP1/ASP2.
In this case there will not be any communication between ASP1/ASP2 to
ASP3/ASP4.
So how ASP3/ASP4 will know ASP ID assigned by ASP1/ASP2 (vice versa)?

I think in this case you are suggesting to have a provisionable database
(Management) at an ASP regarding the ASP IDs which are already consumed.
Will it not create some race conditions?

Thanks
Chak

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Dec 2002 04:57:49 -0700

PSK,

For the case of "ASP Failure" where ASP Id is not provide in ASP Up,
the SG must be provisioned with the ASP Ids (where else is it to
get them from?).  Where the ASP provides an ASP Id in ASP Up, it must
uniquely identify the ASP to the SGP, which is the same requirement
as for ASP Down.

So, either ASP Id is provisioned at the SGP (in which case the ASP Id
can be different for each AS that the ASP is involved), or the ASP
provides it in the ASP Up (in which case that ASP Id is the same for
this ASP in all AS in which it is involved).

That's how things work the in the RFC now.

PSK Chakravarthi wrote:                         (Fri, 20 Dec 2002 17:18:12)
> So how ASP3/ASP4 will know ASP ID assigned by ASP1/ASP2 (vice versa)?

They will have to know from somewhere other than the SG, because the
SG has no way to identify ASP1 and ASP2 to ASP3 and ASP4.  It can only
identify them by their ASP Ids.  What use is it for the SG to say to
ASP1 that ASP Id 0xa3463258 is ASP Id 0xa3463258?

> Will it not create some race conditions?

I don't think you understand how it works now in the RFC.

When an ASP sends ASP Up, if the SG can identify the ASP from IP and
port number or some other means outside of the UA, then it can associate
a static ASP Id with that ASP.  If the SG cannot identify the ASP from
IP and port number or some other means, the ASP needs to provide its
ASP Id in the ASP Up message.  If that ASP Id is alread used by an
ASP (possibly the same ASP) in another association, the SG returns an
error.  If the ASP Id is required by the SG, but not in the ASP Up
message, the SG returns an error.  If the ASP Id is unused (for any
other association) and it stores that value and uses it to identify
the ASP in "ASP Failure" and other messages that contain ASP Id.

In this way the SG does not necessarily know which ASP is which, it
just uses the provideed ASP Id to identify the ASP at the other end
of a given association.  AS really have nothing to do with it, unless
you want to make the situation more complicated than necessary.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 21 Dec 2002 16:01:02 -0800 (PST)

Brian,
> That's how things work the in the RFC now.
[TOLGA] I still would think, if one wants to use ASPDN
to report about other ASPs failures, then even for
provision on SGP case, it should have only one AspID,
so different AspIDs for different AS should not
happen.
> ASP1 that ASP Id 0xa3463258 is ASP Id 0xa3463258?
[TOLGA] In fact if dynamic registration is not used
(i.e. SGP knows by configuration, which ASP is serving
which AS), one might survive still with AspIDs, which
are not globally unique, but only unique among the
ASPs, which are serving the same set of AS. Because
when ASPDN with AspID is received by SGP, it knows by
configuration which AS set this ASP is serving, and so
can try to match the received AspID with the ASPs,
serving the same AS set. But I also would think, this
is very open to configuration errors, when adding a
new ASP to an AS. And having said all of that, I would
think using globally unique AspIDs, shouldn't be very
difficult, given the fact when AspID is really
necessary in ASPUP (dynamic address/port case) it
already needs to be globally unique, so that SGP can
determine, which ASP it is, sending this ASPUP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 21 Dec 2002 18:31:41 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 21 Dec 2002 16:01:02)
> so different AspIDs for different AS should not

There is nothing precluding an ASP from having one
ASP Id for ASP Down usage, and other ASP Ids
in each AS to which it belongs.

But, where ASP Id does not uniquely identify the
ASP to the SG it complicates matters for no purpose.

> determine, which ASP it is, sending this ASPUP. 

The question was how one ASP determines the ASP Id of
another ASP (perhaps one for which it wants to report
failure with ASP Down); not how the SGP determines
ASP Id.

The point is that the SGP has no way of identifying
one ASP to another ASP, except with ASP Id.

--brian