Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Sun, 6 Nov 2005 22:25:56 +0530

Thanx Brian for ur inputs.
However, I re-read the sections that u mentioned but I still did NOT get the
answer that I was seeking.

I will try to give an example to better explain.
Possibly, ur answers to the questions (below) could be of good help.

-----------------------|-----------------------------------------------
          AS1          |             AS2(Loadshared), AS3(Override)
-----------------------|-----------------------------------------------
         IPSP1         |           IPSP2                     IPSP3
         (AS1)         |          (AS2,AS3)                   (AS2)
-----------------------|-----------------------------------------------
|

IPSP1 serves AS1.
IPSP2 serves AS2 and AS3.
IPSP3 serves AS2.

1. In a Single Ended scenario, if the IPSP1 sends ASPAC message to the IPSP2
and IPSP3, how would IPSP1 know that IPSP2 and IPSP3 are loadshared for AS2
?

I did NOT see how this would happen, and therefore, we (Tolga and I) were
discussing that IPSP2 and IPSP3 send their respective Traffic Modes for the
various AS they are serving. Which means that ASPAC-Ack from IPSP2 must send
Routing Key of AS2 and AS3 with the Traffic Mode of AS2 and AS3.

2. If the IPSP2 sends ASPAC message to IPSP1, with multiple Routing Keys in
the same ASPAC, it should also send Traffic mode for different Routing Keys
too (AS2 and AS2).

Thanx.
shashank

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Saturday, November 05, 2005 2:11 PM
To: Prasad, Shashank S (Shashank)
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

RFC 3332 says: (Section 4.3.4.3 second paragraph)

   For the Application Servers that the ASP can be successfully
   activated, the SGP or IPSP responds with one or more ASP Active Ack
   messages, including the associated Routing Context(s) and reflecting
   any Traffic Mode Type value present in the related ASP Active
   message. The Routing Context parameter MUST be included in the ASP
   Active Ack message(s) if the received ASP Active message contained
   any Routing Contexts.  Depending on any Traffic Mode Type request in
   the ASP Active message, or local configuration data if there is no
   request, the SGP moves the ASP to the correct ASP traffic state
   within the associated Application Server(s).  Layer Management is
   informed with an M-ASP_Active indication. If the SGP or IPSP receives
   any Data messages before an ASP Active message is received, the SGP
   or IPSP MAY discard them.  By sending an ASP Active Ack message, the
   SGP or IPSP is now ready to receive and send traffic for the related
   Routing Context(s).  The ASP SHOULD NOT send Data or SSNM messages
   for the related Routing Context(s) before receiving an ASP Active Ack
   message, or it will risk message loss.

I think that this is quite clear with regard to two things:

The IPSP receiving the ASP Active message responds with regard to Traffic
Mode in the same fashion as an SGP would.

Traffic Mode included in the ASP Active Ack is simply the value from the
ASP Active message reflected back at the activating ASP.

SGPs do not have traffic modes.  Also, they do not have activation or
up/down states either.  See RFC 3332 Section 1.4.2.5:

 1.4.2.5 Message Distribution at the ASP

   The ASP must choose an SGP to direct a message to the SS7 network.
   This is accomplished by observing the Destination Point Code (and
   possibly other elements of the outgoing message such as the SLS
   value). The ASP must also take into account whether the related
   Routing Context is active or not (See Section 4.3.4.3).

   Implementation Note: Where more than one route (or SGP) is possible
   for routing to the SS7 network, the ASP could, for example, maintain
   a dynamic table of available SGP routes for the SS7 destinations,
   taking into account the SS7 destination
   availability/restricted/congestion status received from the SGP(s),
   the availability status of the individual SGPs and configuration
   changes and failover mechanisms. There is, however, no M3UA messaging
   to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive
   messaging).

   Whenever an SCTP association to an SGP exists, the SGP is assumed to
   be ready for the purposes of responding to M3UA ASPSM messages (Refer
   to Section 3).

See also RFC 3332 Appendix A.2.2:

 A.2.2 Signalling Gateway Redundancy

   Signalling Gateways may also be distributed over multiple hosts.
   Much like the AS model, SGs may comprise one or more SG Processes
   (SGPs), distributed over one or more hosts, using an active/backup or
   a loadsharing model.  Should an SGP lose all or partial SS7
   connectivity and other SGPs exist, the SGP may terminate the SCTP
   associations to the concerned ASPs.

   It is therefore possible for an ASP to route signalling messages
   destined to the SS7 network using more than one SGP.  In this model,
   a Signalling Gateway is deployed as a cluster of hosts acting as a
   single SG.  A primary/backup redundancy model is possible, where the
   unavailability of the SCTP association to a primary SGP could be used
   to reroute affected traffic to an alternate SGP.  A loadsharing model
   is possible, where the signalling messages are loadshared between
   multiple SGPs.  A broadcast model is also possible, where signalling
   messages are sent to each active SGP in the SG. The distribution of
   the MTP3-user messages over the SGPs should be done in such a way to
   minimize message missequencing, as required by the SS7 User Parts.

   It may also be possible for an ASP to use more than one SG to access
   a specific SS7 end point, in a model that resembles an SS7 STP mated
   pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic
   loadshared between them.  Other models are also possible, subject to
   the limitations of the local SS7 network provisioning guidelines.

   From the perspective of the M3UA layer at an ASP, a particular SG is
   capable of transferring traffic to a provisioned SS7 destination X if
   an SCTP association with at least one SGP of the SG is established,
   the SGP has returned an acknowledgement to the ASP to indicate that
   the ASP is actively handling traffic for that destination X, the SGP
   has not indicated that the destination X is inaccessible and the SGP
   has not indicated MTP Restart.  When an ASP is configured to use
   multiple SGPs for transferring traffic to the SS7 network, the ASP
   must maintain knowledge of the current capability of the SGPs to
   handle traffic to destinations of interest.  This information is
   crucial to the overall reliability of the service, for active/backup,
   loadsharing and broadcast models, in the event of failures, recovery
   and maintenance activities.  The ASP M3UA may also use this
   information for congestion avoidance purposes.  The distribution of
   the MTP3-user messages over the SGPs should be done in such a way to
   minimize message missequencing, as required by the SS7 User Parts.

I think these passages are quite clear.

--brian

Prasad, Shashank S (Shashank) wrote:            (Sat, 05 Nov 2005 12:24:04)
> Tolga,
> I agree with ur point. In a Single Ended exchange, the Traffic Mode in the
> ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending
> ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each
> other.
> 
> Some more important points:
> The ASPAC message can have multiple (n)  Routing Contexts.
> And therefore the Traffic Mode sent in the ASP-Ack must also have the
> Traffic Mode per Routing Context.
> 
> Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u
> agree ?
> 
> 
> 
> However, there is still a catch.
> The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages.
> At present, M3UA has left to the implementators on how to interpret
Traffic
> Modes of each other, in case, the peers do NOT exchange Traffic Modes.
> 
> I was therefore suggesting that we could have M3UA suggest a default
> implementation of Traffic Mode, and rather NOT leave to the
implementation.
> And I suggested Override, because, I would always believe that whenever a
> node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our
> discussion), without any Traffic Mode (since it is Optional), it shall
> interpret that the peer intends to use this ASP for its communication.
> 
> 
> At the same time, we ALSO have ur suggestion about IPSPs sending their
> respective Traffic modes in ASPAC-Ack messages.
> 
> 
> shashank
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: Saturday, November 05, 2005 1:42 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> 
> 
> Shashank,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Prasad, Shashank S (Shashank)
> > Sent: Friday, November 04, 2005 2:08 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Reply embedded.
> >
> > shashank
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Tolga Asveren
> > Sent: Friday, November 04, 2005 10:09 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Shashank,
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Prasad, Shashank S (Shashank)
> > > Sent: Friday, November 04, 2005 11:07 AM
> > > To: 'Tolga Asveren'; [email-masked]
> > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > >
> > >
> > > Oh OK !
> > > Looks like, it could potentially happen that NodeB can limit itself to
> > > sending traffic for PS1 on only one of associations also, rather
> > > than both.
> > > However, IPSP1 has really to "listen" at both the associations.
> > > Is that correct ?
> > [TOLGA]Yes. Please also note that it is the M3UA-User which controls
this
> > behavior on Node-B, i.e. this is not loadhsaring on M3UA level
> > but one layer
> > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When
> > they receive a
> > message from their user, they will send it to IPSP1.
> >
> > [SHASHANK] OK, I get ur point related to the role of M3UA User.
> >
> >
> >
> >
> > >
> > > A couple of more questions that now comes up:
> > > 1. In a single ended scenario, how could have IPSP1 (at NodeA)
> > determined
> > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent
> > from IPSP1 to
> > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration)
> > [TOLGA]Through local configuration, please note Traffic Mode parameter
is
> > optional. OTOH, I think that it could be an idea to modify the protocol
a
> > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending
side
> > about traffic mode on the peer side in case it is necessary.
> > >
> >
> > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to
> > inform ASPAC
> > sending side
> > about traffic mode on the peer side in case it is necessary. That
> > will help
> > a
> > great deal in the single exchange scenarios to exchange the Traffic
Modes.
> > At present, the M3UA protocol does NOT say anything explicitly on this.
> >
> > Alternatively, the protocol could also define a default Traffic Mode
> > explicitly (possibly Override). And in case the peers do NOT exchange
> > the Traffic mode, the default Traffic Mode (as specified in the specs)
can
> > be used.
> >
> > Now that we understand the need, do u think that this could be taken up
> > further ?
> [TOLGA]I am not sure whether it is a good idea to declare a default
traffic
> mode but allowing both sides to use Traffic Mode parameter makes sense to
> me. Similar concept could be applied for SGPs as well, i.e. they declare
> their traffic mode with Traffic Mode in ASPAC-ACK -actually this in
> practicall life is probably less useful-. Any other opinions about this
> issue? It looks like a useful feature to me to use Traffic Mode in both
> directions.
> >
> >
> > > 2. In a single exchange scenario, isn't it needed to have the peer ASs
> > > having the same Traffic Mode ?
> > [TOLGA]I believe what you mean as "AS traffic mode" is traffic
> > mode of peer
> > IPSPs in the context of an AS. As far as I can see different traffic
modes
> > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE
> > simultaneously at both sides.
> > >
> > [SHASHANK] I agree with the answer to my second question.
> >
> > > shashank
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Tolga Asveren
> > > Sent: Friday, November 04, 2005 8:51 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > >
> > >
> > > This is implementation/traffic type dependent and is not something
> > > standardized by M3UA.
> > >
> > > > -----Original Message-----
> > > > From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> > > > Sent: Friday, November 04, 2005 10:28 AM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > > >
> > > >
> > > > Thanx Tolga. U are right in understanding my question.
> > > >
> > > > Followup Question:
> > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine
at
> > > > NodeB, if the traffic to IPSP1 is
> > > > to be sent via IPSP2 or IPSP3 ?
> > > >
> > > >
> > > > shashank
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > > > Behalf Of Tolga Asveren
> > > > Sent: Friday, November 04, 2005 8:13 PM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > > >
> > > >
> > > > Shashank,
> > > >
> > > > As far as I understand your question:
> > > >
> > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC
> > > > for this RK
> > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing
> > > > mode. You are
> > > > wondering whether IPSP1 will receive traffic from both IPSP2
> > and IPSP3.
> > > >
> > > > Yes, it can, but I wouldn't call it traffic being loadshared to
> > > > IPSP1. IPSP2
> > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of
> > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because
> > traffic from a
> > > > single source is distrubuted to multiple peers.
> > > >
> > > >    Tolga
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > > > > Behalf Of Prasad, Shashank S (Shashank)
> > > > > Sent: Friday, November 04, 2005 9:48 AM
> > > > > To: [email-masked]'
> > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > > > >
> > > > >
> > > > > Hi,
> > > > > I had a specific question related to a specific scenario
> > > explained below
> > > > > (Single Exchange scenario)
> > > > >
> > > > > NodeA supports 1 PS with 1 IPSP
> > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode.
> > > > >
> > > > >
> > > > > There are two associations between NodeA and NodeB.
> > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB).
> > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).
> > > > >
> > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2
> > > on NodeB,
> > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means
> > > > > that IPSP2 and
> > > > > IPSP3,
> > > > > serving a loadshared PS2, are essentially telling NodeA to
> > > > > loadshare all the
> > > > > traffic
> > > > > for PS2, between IPSP2 and IPSP3.
> > > > >
> > > > > The above concepts are also illustrated below....(I have
> > purposefully
> > > > > avoided AS-ACTIVE notification)
> > > > >
> > > > >
> > > > >
> > > > >          NodeA                   <------------NodeB------------>
> > > > >
> > > > >          PS1-IPSP1               PS2-IPSP2
PS2-IPSP3
> > > > >           |                        |                          |
> > > > >           |<-----ASP Up------------|                          |
> > > > >           |-------ASP Up Ack------>| (Assoc #1)               |
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |<--------------------ASP Up------------------------|
> > > > (Assoc #2)
> > > > >           |----------------------------ASP Up Ack------------>|
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |<--ASP Active(Ldshr)----|                          |
> > > > >           |------ASP Active Ack--->|                          |
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |<--------------------ASP Active(Ldshr)-------------|
> > > > >           |----------------------------ASP Up Ack------------>|
> > > > >           |                        |                          |
> > > > >           |                        |                          |
> > > > >           |---NOTIFY(AS-ACTIVE)--->|                          |
> > > > >           |--------------------------NOTIFY(AS-ACTIVE)------->|
> > > > >           |                        |                          |
> > > > >
> > > > >
> > > > >
> > > > > Questions:
> > > > > Assuming a single exchange scenario, would the traffic towards
> > > > > PS1 on NodeA,
> > > > >
> > > > > be also loadshared across 2 associations ?
> > > > >
> > > > > I thought it would and hence another follow-up question:
> > > > > It looks like a loadshared peer (NodeB in our case) with
> > > > multiple IPSPs,
> > > > > is putting a constraint on the NodeA, to ALSO be ready to
> > > > receive data on
> > > > > multiple associations and possibly loadshared. Is this a fair
> > > > > understanding
> > > > > ?
> > > > >
> > > > >
> > > > > shashank
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
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: Sun, 6 Nov 2005 12:37:58 -0700

Prasad,,

Prasad, Shashank S (Shashank) wrote:                                               (Sun, 06 Nov 2005 22:25:56)
> Possibly, ur answers to the questions (below) could be of good help.

In SE, one IPSP acts as ASP, the other as SGP.  If you want a loadshared AS
at IPSP2 it will have to send the ASPAC.

IPSPs receiving ASPAC act as an SGP (as stated in the passages).  For distribution
of messages over SGP, see 1.4.2.5 and A.2.2.

--brian

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