Subject: RE: [Sigtran] M3UA notify message

From: <[email-masked]>
Date: Thu, 23 Feb 2006 12:11:45 +0530

Brain,
Thanks, Yes I agree on this and my reference to section 1.4.1 to nitin
was based on similar lines.

However I propose if we can put few examples of SSNM/ASPTM/ASPSM in the
rfc with multiple SGPs handling a AS, it would clear a lot of doubts for
most people.
 
Regards,
 
Prabind

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 11:34 AM
To: PRABIND CHAUBEY (WT01 - Voice & Next Generation Networks)
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify message

Prabind,

You are correct, there is a case where the ASP state is shared across
the SGPs making up an SG: in the Override traffic mode AS it is
necessary to share which ASP is "Active" and which is "Standby" as only
one ASP can be Active for the AS.

This is also a case where state transitions directly associated with
ASPTM/ASPSM message procedures must be considered on an SG-wide basis,
contrary to Tolga's previous statements on this thread.

It is possible, but perhaps less important to interoperability, that an
SG could coordinate the ASP state for ASPs in a Loadshare or Broadcast
AS.  That is, when loadsharing, the selection algorithm at an SGP could
consider the availability of ASPs to other SGPs to more equally
distribute traffic.  For Broadcast mode AS, consideration of ASP state
across the SGP could provide a more optimal broadcast of traffic (i.e.
without sending multiple messages to or missing completely an ASP).

For the case of SSNM, it is possible (but not required) for the SG to
avoid sending duplicate SSNM messagese to any given ASP.  By considering
the ASP state on an SG-wide basis, it is possible to ensure that only
one SSNM message is sent to an ASP (via only one SGP).

The override and SSNM cases were given consideration in the original
thread that led to the wording 1.4.1.  The others were not so much.

Therefore, I agree that the statement in 1.4.1 should not be ammended.

--brian

[email-masked] wrote:                (Thu, 23 Feb 2006
09:50:04)
> 
> I am still concerned about this statement from Tolga:
> 
> " 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."
> 
> If multiple SGPs are serving a single AS, then shouldn't the ASP
states
> also be shared across the related SGPs?
> Else if I am wrong then the following statement in section 1.4.1
should
> be amended to share the AS states only.
> " 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."
> 
> Tolga, further considering the sahring of ASP states then, in the case
> of the interoperability issue (as you depicted), the rfc says that if
an
> ASP is already inactive the ASP-UP message would still be respnded by
an
> ack.
> 
> I think the things become simpler if we consider sharing of ASP states
> of a particular AS across all SGPs serving that AS.
>  
> 
> Regards,
>  
> Prabind
>  

-- 
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, 23 Feb 2006 00:36:42 -0700

prabind.chaubey,

[email-masked] wrote:                           (Thu, 23 Feb 2006 12:11:45)
> rfc with multiple SGPs handling a AS, it would clear a lot of doubts for

I agree.  There is not even a single example with multiple SGP in the
RFC.  However, since the last IG for M3UA is long gone, it will likely
be necessary to start a second IG for M3UA.  Another possible would be
to start a test case or examples document of its own for M3UA.

--brian

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