Subject: RE: [Sigtran] SG view of the ASP

From: "Munnaluru, Krishna" <[email-masked]>
Date: Thu, 9 Feb 2006 13:51:56 -0600

The ASP is currently sending the ASP UP message with the same ASP Id to
both SGPs. 

As per the SG guys suggestion we temporarily changed the ASP trafficmode
in the ASP ACTIVE message to loadsharing and this problem goes away. But
we see another problem.

The administrator on the ASP side decides to take down the SCTP
association with SGP2. The ASP sends ASP DOWN message to the SGP2. Then
the SGP2 responds with ASP DOWN ACK. So far everything looks good. But
then immediately the SGP1 sends a NOTIFY with the status=ASP Failure and
includes the Routing Context value. Why is the SGP1 sending this NOTIFY
and what is the expected behavior of the ASP upon receiving the NOTIFY
from the SGP1? The SG is sending the NOTIFY because it treats the ASP as
two separate ASPs and so it thinks that it is notifying to the other
ASP.

I think it came down to the way SG was designed - "The SG treating each
association as a separate ASP as supposed to just one ASP with two
associations".  Is this the general way a SG behaves (or designed)?
Should it not treat an ASP as just one rather than two?

Please provide some input so that I can confirm my understanding of the
M3UA protocol.

Thanks,
Krishna

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, February 09, 2006 12:21 PM
To: Munnaluru, Krishna
Cc: [email-masked]
Subject: Re: [Sigtran] SG view of the ASP

Krishna,

I suppose you could try adding ASP Id to the ASP Up message and see
if the SG recognizes the ASP as one.

However, as Ille suggests, perhaps the problem is the SG's traffic
mode (rather than the AS's traffic mode).

If the SG really believes that the ASP is two distinct ASPs, it should
be sending a NOTIFY("Alternate ASP Active") from SGP1.  If it does not,
IMO it is just a bug, so, perhaps the SG does not truly support Active/
Standby mode.

--brian

Munnaluru, Krishna wrote:                    (Thu, 09 Feb 2006 11:34:46)
> Brian,
> 
> This is how it is affecting my expected behavior.
> 
> Note: Currently I have only one ASP but in future I intend to add a
> standby ASP. Hence I use the trafficmode=override in the messages.
Also
> the desired behavior is that the ASP to laodshare the traffic going to
> the SG among the two SGPs.
> 
> The problem showed up during the following scenario:
> 
> The ASP comes up, establishes associations and sends ASP UP message
> (ASPIdentifier = 10007) to both SGPs for which the SGPs respond with
ASP
> UP ACK. 
> 
> The ASP sends ASP ACTIVE (trafficmode=override) with a routing context
> for the AS to the SGP1 and the SGP1 responds with ASP ACTIVE ACK. The
> status on the SG shows that the AS is active on SGP1 and inactive on
> SGP2.
> 
> Later the ASP sends ASP ACTIVE (trafficmode=override) with the same
> routing context to the SGP2 and the SGP2 responds with ASP ACTIVE ACK.
> The status on the SG shows that the AS is active on SGP2 and inactive
on
> SGP1. I was expecting the AS to be active on both SGPs since the ASP
had
> sent ASP ACTIVE to both SGPs.  This was not what I was expecting.
> 
> The explanation given by the Third party SG team is that since they
> treat association from SGP1 to ASP as one ASP (ASP1) and the
association
> from SGP2 to ASP as a separate ASP (ASP2), they are over writing the
> status when the SGP2 received the ASP ACTIVE message from the ASP.
They
> suggest that I put the trafficmode=loadshare and that would solve the
> problem.  So I am really confused.
> 
> Hope this helps.
> 
> Thanks,
> Krishna
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Feb 2006 15:11:46 -0500

Krishna,

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Munnaluru, Krishna
> Sent: Thursday, February 09, 2006 2:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] SG view of the ASP
>
>
[TOLGA]I think the correct interpretation should be "Each SGP treats each
association as a separate ASP" and "ASP/SGP procedures are executed on each
SGP independently". For the scenario you described, I wouldn't expect SGP1
to send NTFY, because it did not loose connection  to ASP1, i.e. ASP1 is
still ACTIVE from SGP1 point of view, and SGP1 does not have any alternative
ASP in UP state.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Feb 2006 13:39:17 -0700

Krishna,

Munnaluru, Krishna wrote:                    (Thu, 09 Feb 2006 13:51:56)
> Should it not treat an ASP as just one rather than two?

In the override case, did the SG send NTFY("Alternate ASP Active") when
SGP1 marked the ASP ASP Inactive?  If not, the SG is not behaving consistent
with the view that there are two ASPs.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 10 Feb 2006 03:49:07 -0600 (CST)

Few comments inline.

  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. *******

> Please provide some input so that I can confirm my understanding of the
It seems to be a problem with SG's implementation. following are the
drawbacks with the SG you are using.

1.SG views two physical ASPs, eventhough you have one physical ASP.
  In override traffic mode,as per your mail an ASP has registered with
  two SGPs(SGP1 and SGP2) using the same ASP id in the ASP_UP message
  then ASP sends ACTIVE message to SGP1 so whole AS becomes active at SG.
  
  When SGP2 receives ACTIVE message, SGP1 sends NTFY(ALT_ASP_ACT) with
  the same ASP id. This is not a correct behaviour of handling override 
  traffic mode. If the complete physical ASP goes down, then
  alternate(standby) ASP should be able to send ACTIVE message but you can
  not achieve this with your current configuration. 
 
2.NTFY messages ALT_ASP_ACTIVE and ASP_FAILURE have ASP id but the same
  ASP id is used in other SGPs.

--Samuel

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 10 Feb 2006 11:40:53 -0500

All,

There seems to be a consensus on the list that an SG with 2 SGPs should be aware that there is one physical ASP with 2
SCTP associations (one to SGP1 and one to SGP2), and not assume that there are 2 ASPs. The consensus also seems to be
that the method of informing the SG should be via the ASP Id param in the ASPUP msg.

I am OK with this consensus, but if we want to adopt this consensus we must update the spec in regard to the definition
of the ASP Id param. It currently says:

<snip>
   ASP Identifier: 32-bit unsigned integer

      The optional ASP Identifier parameter contains a unique value that
      is locally significant among the ASPs that support an AS.  The SGP
      should save the ASP Identifier to be used, if necessary, with the
      Notify message (see Section 3.8.2).
<snip>

This description is misleading, in that it implies that the only use for the ASP Id is in the NTFY msg. In fact, this is
the ONLY use described in the entire spec for the ASP Id param.

I suggest the following text for this param:

<snip>
   ASP Identifier: 32-bit unsigned integer

      The optional ASP Identifier parameter contains a unique value that
      is locally significant among the ASPs that support an AS.

      This parameter identifies the physical ASP that is using this SCTP
      association, in the case where an ASP is using more than one
      association to communicate with the SG.

      The SGP should save the ASP Identifier to be used, if necessary,
      with the Notify message (see Section 3.8.2).
<snip>

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Samuel Dur D. Jeyaseelan
Sent: Friday, February 10, 2006 4:49 AM
To: [email-masked]
Subject: RE: [Sigtran] SG view of the ASP

Few comments inline.

--Samuel

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 11:34:13 -0500

I agree that a clarification could be useful. What about the following:

       This parameter identifies the physical ASP that is using this SCTP
       association when the SCTP endpoint address used by ASP is dynamic,
	 e.g. where ASP is using an ephemeral SCTP port.

All ASPAC/ASPUP etc... procedures are considering ASP and SGP as signaling
peers. I don't see why we should try to change the signaling semantics for
ASPSM/ASPTM to apply between ASP and SG rather than between ASP and SGP.

    thanks,
    tolga
> Behalf Of Barry Nagelberg
> Sent: Friday, February 10, 2006 11:41 AM
> To: [email-masked]
> There seems to be a consensus on the list that an SG with 2 SGPs
> should be aware that there is one physical ASP with 2
> SCTP associations (one to SGP1 and one to SGP2), and not assume
> that there are 2 ASPs. The consensus also seems to be
> I am OK with this consensus, but if we want to adopt this
> consensus we must update the spec in regard to the definition
> This description is misleading, in that it implies that the only
> use for the ASP Id is in the NTFY msg. In fact, this is

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 10 Feb 2006 12:28:15 -0500

Tolga,

Thanks, but I prefer the text that I offered - the case that we're discussing has nothing to do with dynamic SCTP
addresses.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Tolga Asveren
Sent: Friday, February 10, 2006 11:34 AM
To: [email-masked]
Subject: RE: [Sigtran] SG view of the ASP

    thanks,
    tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 12:18:09 -0500

Barry,

The fundamental problem in the case Krishna presented is that SG rather than
SGP is seen as the signaling peer for ASPTM/ASPSM, which is not correct. I
don't think we should have a change to legitimize such a misinterpretation
of the M3UA specification. The text you proposed speaks about SG as a peer
for ASPSM, wich is not correct. The concept of SG comes into play only for
SSNM.

Actually I was suprised that the use of AspId for dynamic SCTP addresses is
not already there, because it has been discussed many times in this mailing
list.

    Tolga

> Sent: Friday, February 10, 2006 12:28 PM
> To: [email-masked]
> Thanks, but I prefer the text that I offered - the case that
> we're discussing has nothing to do with dynamic SCTP
> addresses.
>
> Barry Nagelberg
> Adax, Inc.
>

---

From: Ilie Glib <[email-masked]>
Date: Fri, 10 Feb 2006 18:38:38 +0100

Hello Tolga,

First sentence

>       is locally significant among the ASPs that support an AS.

looks confusing because of "AS" at the end. ASP_UP can be sent before
any knowledge about ASes is available in SG. Therefore ASP ID shall
have SG or SGP uniqueness scope. I would prefer SGP scope, to fit the
IPSP-IPSP traffic case best.

In case of IPSP-IPSP, all remote SUA peers of an IPSP shall have
different ASP_IDs.

Regards

Ilie

--
Ilie

---

From: Ilie Glib <[email-masked]>
Date: Fri, 10 Feb 2006 18:43:29 +0100

Hello All,

SUA RFC has the following note. It looks OK to me, and it explains one
of the reasons for ASP-IDs.

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

The other reason is NTFY.

The spec shall cover both

Regards

Ilie

--
Ilie

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 12:41:17 -0500

Ilie,

> From: Ilie Glib [mailto:[email-masked]]
> Sent: Friday, February 10, 2006 12:39 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]I think the idea was to coordinate the ASP-Id among ASPs serving a
specific AS in a way -which is impelementation dependent-, where each ASP is
assigned a unique ASP-Id. Once this is done on ASP side, I don't see why
knowledge about SG side is necessary but I may be missing something.

---

From: Ilie Glib <[email-masked]>
Date: Fri, 10 Feb 2006 19:19:13 +0100

Tolga,

I do not like mentioning of any ASes, because it may look like it is
allowed to have multiple associations from an ASP (ASP_ID) towards the
same SGP, provided that each association serves different ASes.

Regards

Ilie

--
Ilie

---

From: Chris Benson <[email-masked]>
Date: Fri, 10 Feb 2006 10:22:08 -0800 (PST)

> knowledge about SG side is necessary but I may be missing something.

But ... if an ASP-UP is sent before any knowledge about ASes 
is available in the SG, then how can the SG (in the discuused 
secnario represented by two SGPs) differentiate between:
(a)  only one remote ASP (sending ASP-UP to both SGPs), and 
(b) another AS-side configuration of two independent ASPs 
which happen to have the same numeric ASP ID but [are going to] 
belong to different ASes?

With thanks, from Chris Benson.

---

From: Chris Benson <[email-masked]>
Date: Fri, 10 Feb 2006 10:28:23 -0800 (PST)

> same SGP, provided that each association serves different ASes.

... like in Figure 5 of RFC 3332?

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 13:16:02 -0500

Chris,

> Behalf Of Chris Benson
> Sent: Friday, February 10, 2006 1:28 PM
> To: Tolga Asveren; [email-masked]
[TOLGA]I don't see multiple associations from an ASP to the same SGP in
Figure5 of RFC3332.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 13:18:46 -0500

Ilie,

> Sent: Friday, February 10, 2006 1:19 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Not mentioning about AS would require *all* ASPs interacting with the
SG to have a unique id in the whole ASP set. Considering that those ASPs
could be operated by different organizations, this may not be practical.
OTOH, I believe to expect ASPs serving a specific AS to be assigned a unique
Id among themselves is not a unrealistic expectation.

Other than that, I understand your concern and I agree that multiple
associations between the saem ASP and SGP are not a good thing.

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 10 Feb 2006 13:58:36 -0500

Tolga,

There is no misinterpretation. The problem presented by Krishna is _precisely_ 2 ASPs connecting to the same SG.

If the word "SG" in my suggested text makes you uncomfortable, though, then please change it to "SGP". It's the same
problem - there is no prohibition in the spec against multiple associations between an ASP and an SGP.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Tolga Asveren
Sent: Friday, February 10, 2006 12:18 PM
To: [email-masked]
Subject: RE: [Sigtran] SG view of the ASP

Barry,

    Tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 13:47:06 -0500

Chris,

> Sent: Friday, February 10, 2006 1:22 PM
> To: [email-masked]
[TOLGA]Let's consider the following case: single SGP, two ASPs, each of them
are serving different AS and happen to be assigned the saem ASP-Id.

      AS1            AS2
      Id=1           Id=1
   +------+      +-------+
   | ASP1 |      |  ASP2 |
   +---+--+      +---+---+
       |             |
 ***************************
 * +---+-------------+---+ *
 * |        SGP1         | * SG1
 * +---------------------+ *
 ***************************

Both ASPs send ASPUP with AspId=1. SGP1 is unable to identify the ASPs yet.
If identifying ASPs in that stage is necessary, I agree that ASP-Id should
be unique among all ASPs interacting with the SG, not only among the ones
serving the same AS -unless I am missing something again-.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 13:56:50 -0500

Barry,

I think some passage similar to what we have for SUA is most appropriate,
because it covers the generic use of ASP-Id for ASP identifying purposes.

Please also have a look to "Multiple SCTP associations" thread, starting
1/10/2006, where the issue of multiple associations between signaling peers
is discussed.

   Thanks,
   Tolga

> Sent: Friday, February 10, 2006 1:59 PM
> To: [email-masked]
> There is no misinterpretation. The problem presented by Krishna
> is _precisely_ 2 ASPs connecting to the same SG.
>
> If the word "SG" in my suggested text makes you uncomfortable,
> though, then please change it to "SGP". It's the same

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Feb 2006 14:28:27 -0500

As far as I understand, the scenario presented by Krishna should follow the
following  flow:

  ASP1             SGP1       SGP2
   |                |           |
   |---ASPAC(RC1)-->|           |
   |                |           |
   |<-ASPAC-ACK(RC1)|           |
   |                |           |
   |<-NTFY(AS1 ACT)-|           |
   |                |           |
   |           ASP1 is now      |
   |           ACTIVE for AS1   |
   |                |           |
   |           AS1 is now       |
   |             ACTIVE         |
   |                |           |
   |-------ASPAC(RC1|---------->|
   |                |           |
   |<------ASPAC-ACK(RC1)-------|
   |                |           |
   |<------NTFY(AS1 ACTIVE)-----|
   |                |           |
   |                |         ASP1 is now
   |                |         ACTIVE for AS1
   |                |           |
   |                |          AS1 is now
   |                |          ACTIVE
   |---ASPIA(RC1)-->|           |
   |                |           |
   |<-ASPIA-ACK(RC1)|           |
   |                |           |
   |<-NTFY(AS1 INACT)           |
   |                |           |
   |             ASP1 is now    |
   |             INACTIVE for   |
   |             AS1|           |
   |                |           |
   |             AS1 is now     |
   |             INACTIVE       |
   |

Based on the following passage in his message:

"The explanation given by the Third party SG team is that since they
treat association from SGP1 to ASP as one ASP (ASP1) and the association
from SGP2 to ASP as a separate ASP (ASP2), they are over writing the
status when the SGP2 received the ASP ACTIVE message from the ASP. They
suggest that I put the trafficmode=loadshare and that would solve the
problem.  So I am really confused."

I believe the problem is that SG executes SGP semantics as behaving as a
single distributed SGP, but this will cause interoperability problems
because an ASP would expect each SGP peer to execute these procedures
separetly and independently. Please note that ASP will see each remote SCTP
endpoint as a different SGP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Feb 2006 13:29:16 -0700

Ilie,

It is also in RFC 3331:

   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).

Also, the following statement is in all three (including rfc3057bis):

      ASP Identifier Required                0xe
      Invalid ASP Identifier                 0xf

   The "ASP Identifier Required" is sent by a SGP in response to an
   ASPUP message which does not contain an ASP Identifier parameter when
   the SGP requires one.  The ASP SHOULD resend the ASPUP message with
   an ASP Identifier.

   The "Invalid ASP Identifier" is sent by a SGP in response to an ASPUP
   message with an invalid (i.e. non-unique) ASP Identifier.

--brian

Ilie Glib wrote:                              (Fri, 10 Feb 2006 18:43:29)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Feb 2006 13:41:45 -0700

Barry,

Barry Nagelberg wrote:                                               (Fri, 10 Feb 2006 11:40:53)
>       This parameter identifies the physical ASP that is using this SCTP

ASPs are not necessarily "physical".  In fact, the ASPs that the ASP
Identifier was also intended to distinguish are simply processes on
the same host (i.e, SCTP transport endpoint).

>       with the Notify message (see Section 3.8.2).

I would prefer that the note from RFC 3331 and RFC 3868 be added instead
of your text.

Your text has two prolems as I see it: it is not required that an ASP
provide an ASP Identifier when it forms more than one SCTP association
with an SG.  An ASP only needs to provide an ASP Identifier in two
situations: 

 1) when other ASPs in the AS wish to receive identification of a failed
    ASP with the NTFY("ASP Failure") or identification of a overriding
    ASP with the NTFY("Alternate ASP Active"); and,

 2) when the SGP cannot otherwise distinguish between connecting ASPs
    (e.g. when ASP are using dynamically allocated port numbers from
    the same host.)

IMO your proposed text does not clarify either situation.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/