Subject: RE: [Sigtran] M3UA notify message

From: <[email-masked]>
Date: Wed, 22 Feb 2006 19:48:41 +0530

Nitin,
Refer to section "1.4.1 Signalling Point Code Representation". It
clearly says:
"Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.  Rerouting of traffic between the SGPs MAY also be supported.:
"
Since SGP2 will know what SGP1 has, it will send notifications to ASP.
 
Regards,
 
Prabind

-----Original Message-----
From: nitin [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 7:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify message

hi ,
I think i had not explained my questions clearly . I am trying to
explain
them again .

Please have a look at the diagram :-

-----------                 -----------
SGP1                         SGP2
---|--------                ----|--------
    |                                  |
    |                                  |
    |                                  |
    |                                  |
    |                                  |
------------               ----------
ASP1                        ASP2
------------               -----------

In this diagram, SGP1 and SGP2 are both part of SG1. ASP1 and ASP2 are
part
of AS1.

ASP1 has made sctp associatiion with SGP1 only .
ASP2 has made sctp association with  SGP2 only.
AS is in override mode.

ASP1 is INACTIVE at SGP1 and ASP2 is INACTIVE at SGP2.

1. Now, if ASP1 sends ASP ACTIVE message to SGP1 . will SGP2 be sending
notify for AS ACTIVE to ASP2.

2. If yes, now suppose ASP2 sends ACTIVE to SGP2 .
    Should Alternate ASP active notify be given to ASP1.
    If yes , in earlier discussions we have observed that Notify should
be
done per SGP and not SG.

3. To add further ,   ASPSM, ASPTM, SSNM/SPMC ,notify messages be
considered
per SG  or per SGP.

4. The question 4 that i had written in previous mail , i am explaining
again.
In that question I was not very clear in saying that n+k was for SGP or
SG.

Actually what i want to ask is that ..............n+k is per SG or per
SGP.

For example :- suppose 2+1 architecture is there . Now SG has two SGP's
and
AS has two ASP's.
ASP1 is active on SGP1 and ASP2 is active on SGP2.
Since in this case total number of active ASP's is two , we should
consider
AS to be active at SG.

                OR
suppose ASP1 and ASP2 are both active on SGP1 but none of them is on
SGP2.
So in that case also
the number of ASP's active is two. Should we consider AS active at SG in
this case .

Which of the above two cases is valid or both.

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email-masked]>
To: "nitin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 22, 2006 5:19 PM
Subject: Re: [Sigtran] M3UA notify message

> nitin,
>
> nitin wrote:                                   (Wed, 22 Feb 2006
17:28:49)
> > Hi,
> > if this is the case, then what will happen when(4 cases given below
are
> > different from each other) :-
> > 1. AS(consisting of ASP1 and ASP2) is active at SG (consisting of
SGP1
and
> > SGP2) since ASP1 has done ASP active at SGP1. AS is in override mode
and
now
> > ASP2 sends ASP active message to SGP2 , now what will happen. Should
SGP1
> > send alternate ASP active notify to ASP1 and mark ASP2 as active.
But if
> > such is the case , ASP2 has not yet formed the association with
SGP1.
>
> SGP2 sends it.
>
> > 2. should the SS7 traffic of SGP2 be routed through SGP1 since
AS(load
share
> > mode) is active(ASP1 has done active at SGP1) and SGP2 has already
sent
the
> > notify for AS active to ASP2.
>
> Yes.
>
> > 3. If  AS is in loadshare mode (rest of the configuration same as in
1)
.
> > Now when ASP2 sends active to SGP2 , should notify be sent again to
the
> > ASP2.
>
> What Notify?
>
> > 4. In n+k architecture should this n be taken for SG or this is for
SGP.
I
> > mean to say AS should become active at SG (when it is active at n
SGP's
,
> > supposing single ASP of AS is active at each of n SGP)or (should n
ASP's
be
> > active at any SGP) or (n ASP's should be active only no matter where
and
how
> > they are).
>
> n+k refers to ASPs (and possibly IPSPs), not SGPs.
>
> >
> > There was an earlier mail (copied below) , in which SGP2 sends
notify
again
> > to ASP which should not happen if we are going according to the
current
> > scenario.
>
> The extra Notify is redundant (but not forbidden).
>
> --brian
>
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date:
2/21/2006

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 09:10:52 -0500

Prabind,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 9:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA notify message
>
>
> Nitin,
[TOLGA]This section refers to aggragating the unique SPMC view and
supporting the implementation dependent internal routing functionality.
State machines are kept per SGP.

4.3 AS and ASP/IPSP State Maintenance

   The M3UA layer on the SGP maintains the state of each remote ASP, in
   each Application Server that the ASP is configured to receive
   traffic, as input to the M3UA message distribution function.
   Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
   layer in an IPSP maintains the state of remote IPSPs.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 12:20:26 -0700

Tolga,

The concensus, to which you agreed, was that each SGP maintains
its own ASP state, but that AS state is shared across the SGP
making up an SG.  That is, when notification of AS state is given,
it is consistent for all SGP in the SG.

If this were not the case, each SGP would form its own SG.  Part
of the fundamental purpose of an SG is to coordinate AS state,
both towards the SS7 network and towards the ASPs serving an AS.

This is, indeed, as Nitin indicates, reflected in section 1.4.1.

See the thread "[M3UA] AS state maching sharing between SGPs" from
May of 2001 for reference.

Therefore, when the AS state changes (on this SG-wide basis), all
ASPs attached to all SGP in the SG are notified.  This is why I
say that ASP2 is notified by SGP2 in the original question.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 09:10:52)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 22 Feb 2006 15:05:34 -0500

Brian,

The AS state is just the combinatorial sum of the ASP states.

So I don't think that it makes sense to say that "each SGP maintains its own ASP state, but that AS state is shared
across the SGPs making up an SG" - this falls apart as soon as the ASP states differ on the SGPs.

Futhermore, "ASP state" doesn't exist in a vaccuum. Each ASP has a separate state in each AS to which it belongs. So I
think that the management of both AS and ASP states must be done at the same level - either at the SG or the SGP level.

So the next logical question is: "At which level"? I think that we have a big problem here. There are conflicting
answers in the RFC (draft-ietf-sigtran-rfc3332bis-06.doc). I think that we urgently need to get rid of these
contradictions.

Those in favor of maintenance at the SG level can point to the following:

>From section 1.4.1
<snip>
   Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.
<snip>

Those in favor of maintenance at the SGP level can point to the following:

<snip>
1.3.2.4 Support for the Management of SCTP Associations between the SGP
and ASPs.

   The M3UA layer at the SGP maintains the availability state of all
   configured remote ASPs, to manage the SCTP Associations and the
   traffic between the M3UA peers.
<snip>

<snip>

<snip>

<snip>
4.3.2 AS States

   The state of the AS is maintained in the M3UA layer on the SGPs.
<snip>

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, February 22, 2006 2:20 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify message

Tolga,

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 14:44:56 -0500

Brian,

> it is consistent for all SGP in the SG.
[TOLGA]I agree with the first part but disagree with the second part. Notify
procedures seem to be between ASP/SGP based on what it stands in the RFC. It
is true that SG needs to form a uniqie view of SPMC for the AS but I
wouldn't think this corresponds to following SGP/ASP procedures on a SG-wide
basis. I consider Notify procedures as part of the SGP/ASP relationship
based on 4.3.4.5.
> both towards the SS7 network and towards the ASPs serving an AS.
[TOLGA]I don't agree exactly with the last statement about SG coordinating
AS state towards ASPs. SG just aggregates the SPMC state towards SS7
network. Each SGP maintains its own relationship with ASPs. It is true that
SGPs, which are  part of the same SG probably would be aware of each others
ASP states and would have an internal mechanism to route messages between
themselves but this kind of state sharing is not maintaining a single AS
state in terms of following ASP/SGP procedures described in the
specification.
> say that ASP2 is notified by SGP2 in the original question.
[TOLGA]I think different. 4.3.4.5 Notify procedures speaks of ASP/ASP states
which is kept on SGPs. It also makes sense, because it is the ASP state
which is kept in SGP, is changing and is affecting whether traffic could be
sent/received via that SGP. that NTFY are advisory makes the situation less
drastic, but IMO changing NTFY for the state change on another SGP is less
than perfect.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:11:02 -0700

Tolga,

I think you need to look at that mail thread, where you agreed
to the opposite when the RFC was formed.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 14:44:56)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 14:54:42 -0500

Barry,

> From: Barry Nagelberg [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 3:06 PM
> To: [email-masked]
> So I don't think that it makes sense to say that "each SGP
> maintains its own ASP state, but that AS state is shared
> Futhermore, "ASP state" doesn't exist in a vaccuum. Each ASP has
> a separate state in each AS to which it belongs. So I
> think that the management of both AS and ASP states must be done
> at the same level - either at the SG or the SGP level.
>
> So the next logical question is: "At which level"? I think that
> we have a big problem here. There are conflicting
> answers in the RFC (draft-ietf-sigtran-rfc3332bis-06.doc). I
> think that we urgently need to get rid of these
> contradictions.
>
[TOLGA]This section is about Signalling Point Code Representation. To give
the SG-wide unique view for the SPMC, one needs to coordinate AS/ASP states,
but IMO this does not mean running a single ASP/AS state machine from M3UA
procedures point of view, e.g. AS:PC=1-1-1, and there are two SGPs in the
SG. Unless AS is INACTIVE in both of them, SPMC will be AVAILABLE but each
SGP is running its own ASP state machine and following M3UA procedures
independently. The result of a such coordination could be considered as the
"global ASP state" but I think it shouldn't affect M3UA procedures between
SGP and ASP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:22:51 -0700

Barry,

Barry Nagelberg wrote:                                               (Wed, 22 Feb 2006 15:05:34)
>    traffic between the M3UA peers.

The above says ASP state, not AS state.

>    traffic, as input to the M3UA message distribution function.

The above says ASP state, not AS state.

>    The state of the AS is maintained in the M3UA layer on the SGPs.

And so it does, but that AS state should be coordinated across SGP
as stated in 1.4.1.

See the thread "AS state machine sharing between SGPs".  It was agreed
that AS state is coordinated across SGP in an SG per 1.4.1.  Many diagrams
were drawn and much discussion led up to this.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:23:41 -0700

Tolga,

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 14:54:42)
> "global ASP state" but I think it shouldn't affect M3UA procedures between

Read the thread "AS state machine sharing between SGPs".

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 15:11:16 -0500

Brian,

I think RFC is the consensus, not the mailing threads from several years ago
and I believe RFc is pretty clear about this issue.

   Thanks,
   Tolga

> Sent: Wednesday, February 22, 2006 3:11 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 15:18:48 -0500

Just to supplement my view with a section from RFC: 

4.3.2 AS States

   The state of the AS is maintained in the M3UA layer on the SGPs.  The
   state of an AS changes due to events. These events include:
      * ASP state transitions
      * Recovery timer triggers

   Thanks,
   Tolga

> From: Tolga Asveren [mailto:[email-masked]]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:41:43 -0700

Tolga,

Obviously the RFC is not so clear or we would not be discussing it.

Where the RFC is unclear or contradictatory, it is normal to look
back to the consensus on the mailing list at the time that a specific
issue such as this was resolved.

The agreement was as in section 1.4.1 that AS state (not just SPMC view)
SHOULD be coordinated across the SGP making up an SG.  An on that point
the RFC is clear in section 1.4.1.

The later statement that the AS state is maintained in the M3UA layer
at the SGP is just an error resulting from the s/SG/SGP/g that Greg
did on the document about M3UA 07.  It should, of course, say that
the AS state is maintained in the M3UA layer at the SG.

And it is this to which you agreed in the mail thread from years ago.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:11:16)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:43:05 -0700

Tolga,

This is just an error resulting from s/SG/SGP/g that Greg did for
M3UA 08.  If you consult the mail list, the concensus upholds the
statements for coordinating AS state within the SG as stated in
section 1.4.1.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:18:48)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 22 Feb 2006 15:47:07 -0500

Tolga,

You are wrong. Section 1.4.1 is not only about SPMC. 

It specifically says "SPMC and remote AS/ASP states of each SGP SHOULD be coordinated across all the SGPs."

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Wednesday, February 22, 2006 2:55 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA notify message

Barry,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:45:59 -0700

Barry,

Look at the mail thread.

--brian

Barry Nagelberg wrote:                                               (Wed, 22 Feb 2006 15:47:07)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 15:25:50 -0500

Brian,

> Sent: Wednesday, February 22, 2006 3:42 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Coordinating ASP/AS states to create the unique SPMC view is
something different than using that coordinated state for M3UA ASP/SGP
procedures on each SGP. Otherwise I am not claiming that coordination is not
necessary.
> the AS state is maintained in the M3UA layer at the SG.
[TOLGA]I disagree with your this statement.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:47:07 -0700

Tolga,

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:25:50)
> [TOLGA]I disagree with your this statement.

Read the mail thread, where you agreed.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 15:28:21 -0500

Barry,

Let me retry to explain my position:

Coordination of AS/ASP is necessary to create the unique SPMC view. This
does not mean that the coordinated state should be used for M3UA procedures
on each SGP. Each SGP should maintain its own staet machine from ASP/SGP
procedures point of view.

    Tolga

> Sent: Wednesday, February 22, 2006 3:47 PM
> To: [email-masked]
> It specifically says "SPMC and remote AS/ASP states of each SGP
> SHOULD be coordinated across all the SGPs."
>
> Barry Nagelberg
> Adax, Inc.
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 13:50:19 -0700

Tolga,

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:28:21)
> procedures point of view.

Your statements conflict with the consensus that went into
the RFC as upheld by the mailing list discussion on the matter.

--brian

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 22 Feb 2006 15:58:07 -0500

Tolga,

I understood your explanation the first time, and I disagree with it twice :<)

Section 1.4.1 is currently very clear. It says the opposite of your explanation. If you would like to clarify this
section, then please propose alternate text to the mailing list. Your last email below sounds like a good starting
point.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Wednesday, February 22, 2006 3:28 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA notify message

Barry,

    Tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 15:36:22 -0500

Brian,

Please show where in the specification it says that ASPTM/ASPSM relationship
is between ASP and SG?

   Thanks,
   Tolga

> Sent: Wednesday, February 22, 2006 3:50 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 16:19:08 -0700

Tolga,

The coordinated AS state is used for Notify procedures (M3UA procedures)
at an SGP per 1.4.1.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:36:22)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 16:25:37 -0700

Tolga,

BTW it is used for sending SNMM from an SGP: another M3UA procedure at an SGP.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 18:10:02 -0500

Yes, SSNM will be sent per SG.

BTW, my messages from a few hours ago started just to arrive, not in the
order I sent them.

   Tolga

> Sent: Wednesday, February 22, 2006 6:26 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 18:34:00 -0700

Tolga,

By an SGP, making it an "M3UA procedure on each SGP".

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 18:10:02)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 20:23:07 -0500

Brian,

As long as it is not an ASPSM/ASPTM procedure, it is fine. I probably was
not careful when using the term "M3UA procedures" because it includes pretty
much everything.

BTW, I still wouldn't call it "M3UA procedure on each SGP", because SSNM is
not sent independently by each SGP when status of a destination in SS7
network changes. It is supposed to be sent only once, but this is besides
the point for this thread.

In any case, it is good that there is finally consensus regarding that
ASPSM/ASPTM procedures and associated state machines being independent on
each SGP.

  Tolga

> Sent: Wednesday, February 22, 2006 8:34 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 22:09:00 -0700

Tolga,

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 20:23:07)
> the point for this thread.

That too is not correct.  It is permitted for each SGP to send the SSNM.

> ASPSM/ASPTM procedures and associated state machines being independent on

Except for AS state (which is not associated with the SGP, but the SG).

--brian

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