Subject: [Sigtran] sending ASP UP in IPSP SE

From: "Jaddu, Suresh (NSN - IN/Bangalore)" <[email-masked]>
Date: Mon, 15 Nov 2010 23:10:01 +0800

Hi All,

I think this is very old discussion, I have searched through achieves
but could not find definitive answer. In IPSP single exchange mode how
to dentine that which side sends the ASP UP message during
initialization. From the archives and also the RFC it looks like either
side can initiate the M3UA messaging but in the absence of any
predefined roles or any prior agreement how to know that which side
sends the ASP UP.  In such situations it is certainly possible that both
sides may send the ASP UP if that happens how to handle that, is it a
valid case?? (if this is valid case then what is recommended handling).

Thanks,
SJ.

---

From: Chris Benson <[email-masked]>
Date: Mon, 15 Nov 2010 11:13:42 -0800 (PST)

SJ,

The short answer is that it doesn't matter much, and all
is well if both sides try to come UP around the same time,
providing that each receiver of an ASP Up responds with
an ASP Up Ack.

The state of each IPSP is maintained by the remote (not 
local) peer M3UA layer.  When one IPSP wishes to enter 
the UP/Inactive state, it issues a ASP Up message, 
indicating that it is ready for its state to be changed.
If the receiver of the ASP Up "agrees", then it responds
with ASP Up Ack.

In the Single Exchange model, this SINGLE positive exchange 
carries the same meaning for the state of both sides.  The 
initiator is saying "I want to move to the UP/Inactive state
and you can too". The [positive] responder is saying "you are 
now in the UP/Inactive state, and I am too".

So to answer your direct question, if both sides initiate
ASP Up messages around the same time, all is well, because
the two meanings coincide (both sides want to be UP/Inactive).  
To be successful, the ASP Up message requires an ASP Up Ack
message, so both sides respond to an ASP UP message with
an ASP UP Ack, and both sides move to the UP/Inactive state.

The same argument applies to ASP Active messages etc.

This Single Exchange Model requires that there be one Routing 
Key which fully specifies traffic in both directions.

Chris Benson, Software Engineer,
Adax Inc., Berkeley, California, USA.
    [email-masked]
    +1 510 548-7047 ext. 189
    www.adax.com

On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote:

>>  Date: Mon, 15 Nov 2010 23:10:01 +0800
>>  From: "Jaddu, Suresh (NSN - IN/Bangalore)" <[email-masked]>
>>  To:  <[email-masked]>
>>  Subject: [Sigtran] sending ASP UP in IPSP SE
>>  
>>  
>>  Hi All,
>>

---

From: "SINGH, VIKRAMJEET (VIKRAMJEET)" <[email-masked]>
Date: Tue, 16 Nov 2010 12:40:35 +0530

Hi All,

AS ------------------PSP1-----------<--<<SCON-----SG (PCx)
   ------------------PSP2--------------------------

AS is configured with SG with 2 PSPs configured bwtween them.

In AS M3UA Route configuration :2 PSPs configured with SG with Remote DPC=x.

SCON is sent from SG to AS with affected PC.x on PSP1.

Query: Would SG be marked as congested  or PSP2 would be available for traffic?

-Thanks,
Vikramjeet Singh

---

From: Chris Benson <[email-masked]>
Date: Tue, 16 Nov 2010 10:57:16 -0800 (PST)

Vikramjeet,

I am not familiar with the term "PSP" in this context, so
I'll read PSP1 and PSP2 as ASP1 and ASP2.  Alternatively
they could be SGP1 and SGP2. I am sorry if my assumptions
are incorrect.

Specific reading of the M3UA RFCs suggests this:

Because the [SGP at the] SG has not sent an SCON message to all 
of the "concerned" ?SPs", it doesn't apply to all of the ?SPs.
If the ultimate SS7 destination PCx itself is congested, then 
the SG [SGPs] should sebd an SCON to all "concerned" ASPs (from 
all relevant SGPs).

>From an SGP perspective, acting on SS7 status, RFC 4666
Section 4.5.1 states in part:

   In this way, all ASPs configured to send/receive traffic 
   within a particular Network Appearance are informed.  If 
   the SGP operates within a single SS7 Network Appearance, 
   then all ASPs are informed.

But an SCON message can also be a response to a message in 
the other direction: perhaps only ASP1 sent such a message
(see RFC 4666 Section 3.4.4).

I would interpret your scenario to mean that PCx is congested 
when reached through ?SP1, and should be marked so, but no such
congestion is to be inferred for PCx reached through ?SP2.
Perhaps the reported "congestion" is at the ?SP1 interface 
or route to the SS7 network and does not apply to ?SP2.

This is just my interpretation.  With thanks, Chris Benson.

On Tue, 16 Nov 2010, SINGH, VIKRAMJEET (VIKRAMJEET) wrote:

>>  Date: Tue, 16 Nov 2010 12:40:35 +0530
>>  From: "SINGH, VIKRAMJEET (VIKRAMJEET)" <[email-masked]>
>>  To: "[email-masked]" <[email-masked]>
>>  Subject: [Sigtran] Does AS marks entire SG congested,
>>      when SCON is received on one of two PSPs configured with SG.
>>  
>>  
>>  
>>  Hi All,
>>  
>>  _______________________________________________
>>  Sigtran mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/sigtran
>>

---

From: Sunderjeet Singh <[email-masked]>
Date: Tue, 16 Nov 2010 17:12:25 -0400

As a simplification, can't the role of M3UA client be given to the end that
initiated SCTP association ?
Since SCTP client behaviour in IPSP communication should be configured
anyways, giving the same end
M3UA client fn would be pretty straight. So unless there are compelling
reasons to keep the ASPUP intiator open
for IPSP-SE case, this approach could generate a simpler implementation.

Sunderjeet, Tech Mgr
Aricent Technologies (Holdings) Ltd

---

From: Chris Benson <[email-masked]>
Date: Tue, 16 Nov 2010 13:38:26 -0800 (PST)

Sunderjeet,

One might consider a case where one side is ready, but the
other side is not.  There is the notion of Management Lockout
in M3UA (fourth paragraph of RFC 4666 Section 4.3.4.1).

In this case it might be the "server" who was not initially
ready, and did not respond to the client's ASP Up with an
ASP Up Ack.  Later, when this "server" becomes ready, it can 
initiate and indicate state change by sending its own ASP Up 
message.

Either side can initiate this and similar state changes at
any time, e.g. in response to local management actions.
Your suggested simplification would lose such a capability.

With best regards, from Chris Benson.

On Tue, 16 Nov 2010, Sunderjeet Singh wrote:

>>  Date: Tue, 16 Nov 2010 17:12:25 -0400
>>  From: Sunderjeet Singh <[email-masked]>
>>  To: Chris Benson <[email-masked]>
>>  Cc: "Jaddu, Suresh (NSN - IN/Bangalore)" <[email-masked]>,
>>      <[email-masked]>
>>  Subject: Re: [Sigtran] sending ASP UP in IPSP SE
>>

---

From: Sunderjeet Singh <[email-masked]>
Date: Wed, 17 Nov 2010 11:20:54 -0400

Chris,

Management lockout of server and client retrying of server connectivity are
typical
of any client-server communication. It is always the client which is
expected to initiate
a connection by virtue of its role. Lockouts are special cases and there are
ways to deal
with it.

I see little value in keeping the SE ASP*M message exchanges open which
otherwise could
be easily fixed.

regards
Sunderjeet

On Tue, Nov 16, 2010 at 5:38 PM, Chris Benson <[email-masked]> wrote:

> >>  > >>  From: "Jaddu, Suresh (NSN - IN/Bangalore)" <[email-masked]
> >
> >>  > >>  To:  <[email-masked]>
> >>  > >>  sends the ASP UP.  In such situations it is certainly possible
> that
> >>  > both

---

From: Chris Benson <[email-masked]>
Date: Fri, 19 Nov 2010 11:03:25 -0800 (PST)

Sunderjeet,

Perhaps I should phrase my response differently:

Regardless of possible merits of your suggestion, M3UA is a well 
established protocol (RFC since 2002), and my description is how 
it *is* implemented and MUST be implemented for interoperability.

Even the client and server roles (which apply to initiating 
and responding connections, not the negotiation of UP/Active 
states) have been relegated to a lesser consideration in 
M3UA ASP/SGP mode, with either side permitted to establish 
connections.  After that (as described in RFC 4666 Section
5.6.1), there is no client/server distinction between the
IPSP peers.

Without evaluating your suggestion, it should be noted that
"hundreds" of M3UA implementations follow the RFCs, with
either side initiating IPSP SE ASP*M state change procedures.

I was trying to suggest a rationale for the decision that
was already made in this regard long ago (in SIGTRAN years).
Regardless of rationale, the protocol is already implemented 
whereby either side MAY initiate state change procedures.

My personal view is that this doesn't cause any significant 
problem in the area you describe, and will not be changed.

RFC 4666 Section 1.6.3 describes that the M3UA management
layer may issue an M-ASP_UP request (etc.) to the local
ASP [meaning ASP or IPSP].  This doesn't consider which
side initiated the connection.

Please consider my response a statement of how M3UA is 
implemented, rather than an evaluation of your suggestion.

Best regards, from Chris Benson.

On Wed, 17 Nov 2010, Sunderjeet Singh wrote:

>>  Date: Wed, 17 Nov 2010 11:20:54 -0400
>>  Cc:  <[email-masked]>

---

From: Евгений Фокин <[email-masked]>
Date: Sat, 20 Nov 2010 21:04:48 +0300

> Key which fully specifies traffic in both directions.
Chris, does it mean that in Single Exchange Model requires only one 
Routing Key?
Is it correct if in Single Exchange Model are two or more Routing Keys 
which fully specifies traffic in both directions?

-- 
Regards

     Evgenij

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 20 Nov 2010 15:02:14 -0700

??????????????,

?????????????? ?????????? wrote:                            (Sat, 20 Nov 2010 21:04:48)
> which fully specifies traffic in both directions?

SE specifies both directions of traffic with one AS/RC/RK.

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Mon, 22 Nov 2010 13:57:12 +0100

Hello All,

we had this discussion ages ago, and as far as I remember our conclusion was
that in the SE IPSP to IPSP scenario one has two ASes - one on each side.
They have symmetric RKs and a same value of the RC.

BR //Ilie

On Sat, Nov 20, 2010 at 11:02 PM, Brian F. G. Bidulock <[email-masked]
> wrote:

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Nov 2010 08:03:36 -0700

Ilie,

Ilie Glib wrote:                                                                          (Mon, 22 Nov 2010 13:57:12)
> 
>    we had this discussion ages ago, and as far as I remember our
>    conclusion was that in the SE IPSP to IPSP scenario one has two ASes -
>    one on each side. They have symmetric RKs and a same value of the RC.

No.  One AS, one RC, one RK, describing both directions of traffic.

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Tue, 23 Nov 2010 10:50:26 +0100

And how would they automatically register?

Which SPC would would be DPC and which OPC in the RK?

-- 
Ilie

---

From: Ilie Glib <[email-masked]>
Date: Tue, 23 Nov 2010 10:55:37 +0100

Hello Brian, et al.

here is a copy of an old mail. Enjoy it

BR //Ilie

---------- Forwarded message ----------
From: Ilie Glib <[email-masked]>
Date: Tue, Dec 6, 2005 at 5:11 PM
Subject: Re: [Sigtran] AS, RK , RC concepts in SE model
To: [email-masked], Ilie Glib <[email-masked]>, Tolga
Asveren <[email-masked]>, [email-masked]

Brian,

perfect, I was exactly after this statement.

Now, we have consensus.

Thank you very much indeed.

Ilie

On 12/6/05, Brian F. G. Bidulock <[email-masked]> wrote:
> Ilie,
>
> An AS is a User (MTP-User, SCCP-User).  In a peer-to-peer signalling
> relation without relay or transfer, there are two Users, however,
> there is only one signalling relation.  Each end has an address.
> the pair of addresses defines the signalling relation.  A signalling
> relation is an RK, and an RC.
>
> As Tolga puts it well, at one IPSP, there is a 1:1:1 relationship
> between an AS (local concept) and RC and an RK.  Same at the other.
> The RCs are the same and the RK's are symmetric (both define the
> signalling relation from the view at only one end).  If you know
> one RK you know the other.  Each end defines an AS (without relay)
> and both form one signalling relation.
>
> --brian
>
>
> Ilie Glib wrote:
 (Tue, 06 Dec 2005 15:49:36)
> > Hello Tolga, Brian,
> >
> > Thank you very much indeed for your clarifications. It  is hard for me
> > to understand how on earth a concept of a sink (AS) has evolved to a
> > concept of two sinks. Anyway,
> > - is this view largely accepted by the SIGTRAN community?
> > - Will other adaptation layers (say SUA) follow this model?
> >
> > I would expect a separate draft/RFC that describes this model, one
> > draft per xxUA. As far as I understood a new WI is planned for M3UA
> > (for SG to SG), will it cover this model? How about other xxUAs?
> >
> > Thank you in advance
> >
> > Ilie
> >
> > On 12/6/05, Tolga Asveren <[email-masked]> wrote:
> > > Ilie,
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > > > Behalf Of Ilie Glib
> > > > Sent: Tuesday, December 06, 2005 6:10 AM
> > > > To: [email-masked]; Ilie Glib; [email-masked]
> > > > Subject: Re: [Sigtran] AS, RK , RC concepts in SE model
> > > >
> > > >
> > > > Hello Brian,
> > > >
> > > > in my view this is a considerable change of AS concept. In SIGTRAN
an
> > > > AS is an application server sitting behind its ASPs/IPSPs. Now you
say
> > > > an AS is a bidirectional signalling relation and not an Application
> > > > Server.
> > > [TOLGA]Two points related with this:
> > > - From M3UA stack point of view, an AS is a signaling realtionship for
> > > SGP/ASP/IPSP cases. It is true that AS is not only a M3UA stack but
the
> > > functional areas of M3UA specification deal only with M3UA stack
behavior.
> > > If you look from architectural perspective, I would say that an AS
consists
> > > of multiple ASPs -with M3UA stack, SS7 User Parts and Application
logic-,
> > > rather than AS sits behind ASPs/IPSPs.
> > >
> > > - From modeling point of view, 1:1 relationship between AS and RK
still
> > > holds for SE-IPSP. One can think that two ends of an SE-IPSP
relationship
> > > are different AS using the same RK. On each IPSP you still have the
1:1
> > > relationship between AS and RK, because you care only about your local
AS
> > > definiton -it defines traffic at both ends-.
> > > >
> > > > The same goes for RK,  RK1 cannot be the same as RK2, because
Routing
> > > > Key defines where messages go, it defines routing.
> > > [TOLGA]For SE-IPSP RK defines traffic at both ends. Still you have
your
> > > "local" RK to guide you for routing decisions. Obviously two sides
need to
> > > use the same RC so that messages are exchanged properly.
> > > >
> > > > In my view the concept of Application Server cannot be dependent on
> > > > the exchange model used. How can we make the main SIGTRAN concept
> > > > dependent on the communication model?
> > > [TOLGA]It isn't.
> > > >
> > > > Any other opinions?
> > > >
> > > > Regards
> > > >
> > > > Ilie
> > > >
> > > > On 12/6/05, Brian F. G. Bidulock <[email-masked]> wrote:
> > > > > Ilie,
> > > > >
> > > > > For SE AS1==AS2 (and RK1==RK2).
> > > > >
> > > > > For DE AS1!=AS2 (and RK1!=RK2).
> > > > >
> > > > > You need double the AS, RC and RKs in DE as you do in SE.
> > > > >
> > > > > Because they can't relay, IPSPs only need 1 AS betwixt them.
> > > > >
> > > > > --brian
> > > > >
> > > > > Ilie Glib wrote:                              (Tue, 06 Dec 2005
> > > > 11:40:47)
> > > > > > Hello Folks,
> > > > > >
> > > > > > According to the current definition of AS and RK there is 1:1
> > > > > > relationship between them. The AS is an Application Server that
> > > > > > process traffic routed according to the routing key, that is it
> > > > > > process traffic that comes from unidirectional signalling
relations,
> > > > > > it does not process traffic that goes in the opposite direction,
it
> > > > > > generates traffic in the opposite direction.
> > > > > >
> > > > > > For example
> > > > > > The RK1=(OPC=2-200, DPC=2-100) is different from RK2=(OPC=2-100,
> > > > > > DPC=2-200). Each RK defines its own AS, in this case AS1, which
> > > > > > corresponds to RK1, sits in 2-200 signalling point and AS2,
which
> > > > > > corresponds to RK2, is in 2-100, and each AS has its own RK.
> > > > > >
> > > > > > Could you please clarify
> > > > > >
> > > > > > Q1: What is correct 1) or 2)
> > > > > > 1) In the described above configuration it is one AS =
> > > > AS1=AS2, or otherwise
> > > > > > 2) AS1 and AS2 are different ASes
> > > > > >
> > > > > > I assume 2) is correct. Then Routing Context RC1 corresponding
to RK1
> > > > > > is assigned in AS2 and Routing Context RC2 corresponding to RK2
is
> > > > > > assigned in AS1. RC1 and RC2 are different but may be the same
by
> > > > > > chance.
> > > > > >
> > > > > > Routing Context parameter is mandatory in SUA traffic messages.
> > > > > >
> > > > > > In case of SE model could you please clarify
> > > > > >
> > > > > > Q2: What Routing Context values will be used in traffic messages
> > > > > > between AS1 and AS2?
> > > > > > Q3: Does it depend on the direction of the message?
> > > > > >
> > > > > > Q4: When RC1 is used and when RC2?
> > > > > >
> > > > > > Q5: what RC shall be used by response messages?
> > > > > >
> > > > > >
> > > > > > Thank you in advance
> > > > > >
> > > > > > Ilie
> > > > > >
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > >
> > > >
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > >
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

-- 
Ilie

On Tue, Nov 23, 2010 at 10:50 AM, Ilie Glib <[email-masked]>wrote:

>   On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bidulock <
> [email-masked]> wrote:
>
>> Ilie,
>>
>> Ilie Glib wrote:

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Nov 2010 08:55:03 -0700

Ilie,

Ilie Glib wrote:                                                      (Tue, 23 Nov 2010 10:55:37)
>    > and both form one signalling relation.

Yup.  One AS, one RC, one RK (symmetric).

--brian

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