Subject: multiple associations between SGP and ASP

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Oct 2001 13:44:37 -0700

Hi  Brian

Are multiple associations between single SGP and ASP 
instance supported by the M3UA draft ? If yes, how ASP
takes care or distributing the traffic to same SGP
through multiple associations ? 
Does ASP send ASP Up/Down/Act/Inact on each association separately ?

thanx in advance
Umesh

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 12:55 PM
To: sigtran
Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
separat e

Hi Umesh,

Regarding multiple associations between multiple M3UA entities, I don't
favor this approach but as far as I know it is allowed in the draft. I think
with ASPTM messages, you can use those associations as you want.
And apart from this, with SCTP one has multihoming feature against
interface-failures.
Now for implementing high-redundancy in an implementation dependent way,
interaction among SGPs is already implementation dependent. But as long as
the relationship between ASP-SG is concerned, it should be defined in the
draft, otherwise how can an ASP know, what to expect from a SG consisting of
multiple SGPs?

      Tolga

> -----Original Message-----
> From: Vats, Umesh [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 3:43 PM
> To: sigtran
> Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> separat e
> 
> 
> Hi  Tolga
> 
> As per my understanding till now , between one SGP and ASP, only
> one association can exist. An SGP may have associations
> with multiple ASPs. If multiple associations between single
> SGP and single ASP can exist, then how will these association 
> be managed ? Will ASP send data to SGP on different associations 
> in loadsharing manner or how ?
> 
> Regarding your comment below :
> I favor SGP concept, because it can hide SG-side host failures -not
> interface failures- from ASP side to some extent.
> 
> Hiding host side failures should be prime motive of the
> developer. I agree with that. What I want to emphasise is 
> that this should be left to the implementation. If we
> want high reliability/fault-tolerance/high-availability,
> we can implement it in our own implementation dependent way.
> The problem is happening because the M3UA draft touches the
> distribution related logic but doesn't define it completely.
> This results in too many unanswered issues.
> 
> Umesh 
> 
> 
> -----Original Message-----
> From: Asveren, Tolga [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 11:54 AM
> To: sigtran
> Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> separat e
> 
> 
> Hi Umesh,
> 
> I think there is a difference between your and mine 
> interpretation of the
> draft. As far as I know multiple SCTP associations between 
> M3UA entities is
> possible. I favor SGP concept, because it can hide SG-side 
> host failures
> -not interface failures- from ASP side to some extent.
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Vats, Umesh [mailto:[email-masked]]
> > Sent: Thursday, October 18, 2001 2:45 PM
> > To: sigtran
> > Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> > separat e
> > 
> > 
> > Hi  Tolga
> > 
> > The problem with current draft is that it allows only one 
> > association between a pair of SGP and ASP. Today if we have 
> > an SG with just one SGP, a single point of failure between SG 
> > and ASP results (only one SCTP board handles one association. 
> > If this board  fails, the connectivity between SG and ASP
> > breaks). 
> > 
> > To take care  of this, M3UA draft tells that ASP can connect
> > with multiple  SGPs through separate associations. 
> > 
> > If instead, multiple associations between SG-ASP pairs were
> > possible, then one could easily implement an SG with one 
> > SGP(with SGP distributed in an implementation dependent way)
> > and multiple associations for each ASP as shown in figure below : 
> >              
> >              -------------------------               -------- 
> >              | Single SGP distributed|---------------|      |
> >              | in implementaion      |---------------| ASP  |  
> >              |  dependent way        |               |      |
> >              -------------------------               --------
> > 
> >                                                      
> > Then M3UA protocol will become real simple. 
> > 
> > regards
> > Umesh Vats
> >            
> > 
> > 
> > -----Original Message-----
> > From: Asveren, Tolga [mailto:[email-masked]]
> > Sent: Thursday, October 18, 2001 10:17 AM
> > To: sigtran
> > Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> > separat e
> > 
> > 
> > Hi Umesh,
> > 
> > Just to make clear, I think SGP concept is usefull, when 
> they share AS
> > states. Here the discussion is more about how to handle the 
> > messages, per SG
> > or per SGP. I think the draft is not forcing anybody to 
> implement SGs
> > consisting of multiple SGs. If one wants, one can have always 
> > SGs consisting
> > of single SGPs. 
> > 
> >    Tolga
> > 
> > > -----Original Message-----
> > > From: Vats, Umesh [mailto:[email-masked]]
> > > Sent: Thursday, October 18, 2001 12:19 PM
> > > To: sigtran
> > > Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> > > separat e
> > > 
> > > 
> > > Hi   
> > > 
> > > I have some basic doubt about multiple SGPs.
> > > 
> > > M3UA draft says that an SG can have multiple SGPs.
> > > These SGPs will need to share some state (how toshare is
> > > implementation dependent). For some procedures, event from
> > > one SGP is to be interpreted as representative of whole
> > > SG e.g SSNM messages. For some procedures, each SGP 
> > > responds individually .....
> > > 
> > > All this is making M3UA and our life real complicated here.
> > > 
> > > Why don't we view SG as one instance i.e. comprising of just 
> > > one SGP. If ASPs want, they can have multiple associations 
> > > with same SG. How exactly an SG is made fault-tolerant or
> > > distributed (SG running on multiple hosts) should be left
> > > completely to the implementation. Mixing of the 
> fault-tolerant and 
> > > distributed architectures without detailed description about 
> > > handling of all the scenarios is causing much trouble.
> > > 
> > > For legacy SS7 protocols( e.g TCAP,SCCP,MTP3 etc) ITU has just 
> > > specified protocol with one instance of the process. This has
> > > made implementing these quite easier (everything is covered in
> > > detail). But  telcos are running these in fault/tolerant 
> as well as
> > > distributed manner using their own implementations. 
> > > 
> > > Implementing  distributed  MTP3 is easier than M3UA with multiple 
> > > instances(e.g multiple SGPs) because M3UA discusses somethings
> > > about distribution but leaves too many questions and doubts
> > > unanswered.
> > > 
> > > regards
> > > Umesh Vats
> > > 
> > >  
> > > -----Original Message-----
> > > From: Asveren, Tolga [mailto:[email-masked]]
> > > Sent: Thursday, October 18, 2001 6:16 AM
> > > To: sigtran
> > > Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> > > separat e
> > > 
> > > 
> > > Brian (and the others),
> > > 
> > > Let me summarize what I currently understand from the draft 
> > > and after some
> > > message exchange on the forum:
> > > SGPs of a SG are a single entity from MTP3 point of view. But 
> > > except SSNM
> > > they are acting individually in M3UA domain. According to 
> > me, the most
> > > impirtant feature of SGP concept was, that SGPs are 
> sharing AS state
> > > information among themselves. So, even if they send NTFYs 
> > > individually, when
> > > they are going to send it is coordinated between SGPs forming 
> > > a logical SG.
> > > I only disagree with Brian's statement that "NTFY notifies of 
> > > a particular
> > > SGP's view of the AS and ASP state". I interprete NTFY as a 
> > > notification of
> > > the global AS state. If there is a one SGP SG, of course, 
> > > this will be the
> > > local view of this SGP but otherwise it will be the combined 
> > > vieew of the
> > > SGPs in the SG. So, even if NTFY is sent by all of the SGPs, 
> > > it will contain
> > > the same AS state.
> > > 
> > > Just before draft9, there was a consensus on having SSNM per 
> > > SG, instead of
> > > per SGP. But now, this does not sound to me totallt right, 
> > > because, SGPs are
> > > forming a unique entity in M3UA domain or not. But everything 
> > > else than SSNM
> > > is still per SGP. What is the reason behind that? I think, 
> > > important point
> > > is to decide, being active/inactive for a routing key is an 
> > > attribute of an
> > > association or of a M3UA entity. IMHO, it is an attribute of 
> > > an M3UA entity.
> > > So, if SGPs are forming a single M3UA entity, why not to have 
> > > ASPTM per SG,
> > > instead of SGP? But I also have to say, I don't see any 
> significant
> > > improvement with this approach (just not to send some 
> > > messages multiple
> > > times but I think they will be a very small percentage of the 
> > > whole message
> > > exchange between ASP and SGP) and the disadvantage is that it will
> > > complicate ASP. Because now ASP needs to know which SGPs are 
> > > belonging to
> > > the same SG. Here the important thing is that the advantage 
> > > and disadvantage
> > > is the same for SSNM.!
> > >  I don't see any other benefit than not to send SSNM multiple 
> > > times, which
> > > contains the same information, from different SGPs, when we 
> > > make it per SG.
> > > And it brings the same complication to ASP side. Extra 
> > > configuration and
> > > implementation. If SSNM is per SGP, then ASP does not need to 
> > > know, which
> > > SGPs are belonging to the same SG. 
> > > 
> > > So, one can ask, if we return also SSNM back to per SGP, what 
> > > is the meaning
> > > of to have SGPs instead of just SGs (or SGs with one SGPs). 
> > > Like said at the
> > > beginning of the message, it is that they are sharing AS 
> > > state information
> > > among themselves. So, although they will send separate NTFYs, 
> > > it will have
> > > the global information, and this is again important to make 
> > > logic at ASP
> > > more simple. If this change is done, then we don't need to 
> > > say that SGPs are
> > > forming a single M3UA entity, just they are sharing AS state 
> > > information.
> > > 
> > >      Tolga
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, October 17, 2001 6:42 PM
> > > > To: sigtran
> > > > Cc: [email-masked]
> > > > Subject: Re: m3ua v09 :NOTIFY message once fro SG or 
> for every SGP
> > > > separat e
> > > > 
> > > > 
> > > > Tolga,
> > > > 
> > > > NTFY notifies of a particular SGP's view of the AS and ASP
> > > > state.  A particular ASP can be in different states with
> > > > different SGPs.  An ASP cannot be UP to an SGP unless it
> > > > has an association to the SGP and has performed ASP UP
> > > > procedures with the SGP.
> > > > 
> > > > Therefore, NTFY is per SGP.
> > > > 
> > > > --brian
> > > > 
> > > > Asveren, Tolga wrote:                                    
> > > > (Wed, 17 Oct 2001 14:54:18)
> > > > > Brian,
> > > > > 
> > > > > What about NTFY? Per SG or per SGP?
> > > > > 
> > > > > Tolga
> > > > > 
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > > 
> > > > 
> > > > ---
> > > > You are currently subscribed to sigtran as: 
> [email-masked]
> > > > To unsubscribe send a blank email to 
> > > > [email-masked]
> > > > 
> > > 
> > > 
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> > > [email-masked]
> > > 
> > > 
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to 
> > > [email-masked]
> > > 
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 17:20:46 -0500

Umesh,

Vats, Umesh wrote:                            (Thu, 18 Oct 2001 13:44:37)
> Does ASP send ASP Up/Down/Act/Inact on each association separately ?

Although I don't think that it is explicitly prohibited (or allowed) in the
draft, the WG did go to some pains over the discussion of ASP Id and dynamic
registration to ensure that it was possible to detect and enforce one SCTP
association per SGP/ASP in an implementation.

Because an SGP and ASP are defined as SCTP endpoints (IP+port) there cannot be
more than one SCTP association between them.

There was concern, however, that an ASP that performs dynamic port assignment
might attempt to associate with an SGP twice (using a different port
assignment on each attempt) and that might result in two SCTP associations
between the same SGP/ASP pair.  The ASP Id in the ASP Up permits the SGP to
detect when an ASP has formed multiple associations to it (when it receives
ASP Up for the same ASP Id on the second association) and refuse the second
ASP Up with ERR("Invalid ASP Identifier").  If dynamic assigment is used and
the SGP requires the ability to detect duplicate associations from the same
ASP, and the ASP does not provide ASP Id in the ASP Up, the SGP can give it a
push with ERR("ASP Identifier Required").

ASPs can also be statically assigned IP+port numbers and the SGP identifies
the ASP from the IP+port number connecting.

A mix is also permitted where the SGP listens on a well-known port number and
the ASP uses static assignment, or the SGP listens on statically assigned port
numbers, but the ASPs use dynamic port assignment.

Now, on the SG side, either the SG is listening on IP+well- known-port number
for the UA or the SG is listening on statically provisioned IP+port number,
each corresponding to an SGP.

Some discussions in the working group on the SGP listening on the well-known
port number have indicated a concensus that if an ASP is connecting to the SGP
on the well-known port number that each association will yield a different
SGP.  (SGP is not a "host".  SGP is a "process".)  This is in fitting with
there being only one association between ASP/SGP pair.

Now, most of the discussions on this thread have been whether the SGP share a
large amount of state information or not.  Certainly SGP which are on the same
host can easily share state information via shared-memory or other IPC.
However, the ability of SGP on different hosts to share state information
between them is highly dependent upon the implemenation (distribtued)
architecture.  To avoid restricting distributed implementation architectures,
an implementation must be permitted to limit the amout of state sharing
between SGP.  In the distributed architecture there is also the sitation where
hosts within the architecture may become partitioned due to failures and the
platform should still be able to function.  Just because two SGP lose
communication between themselves is no reason to bring down the entire SG.  It
will be hard to cost-effectively meet carrier-class reliability if the SG
platform fails whenever two SGP lose communications.

For every SGP there are three potential sources of state information
concerning AS: the local view (stored state), the shared view (from other
SGP), and the remove view (from the ASP).

Now, in the monolithic implementation, the local view and shared view can be
the same.  That is, SGP (processes) within the monolithic (albeit
fault-tolerant) host share state information.  This is permitted.

In the distributed implementaion, the local view and the shared view might
differ (particularly if SGP become partitioned).  In the distribute
implementation, it is important that only the local view be synchronized with
the remote view.

ASPSM procedures are focussed at synchronizing the remove view at the ASP
concerning AS state with the SGP's local view in support of distributed
implementations.

Much of this confusion has to do with SCTP's inability to provide redunancy
over multiple hosts.  Unfortunately, the SIGTRAN UAs have had to solve this
problem themselves.  It does add complexity to the UA, but only because SCTP
does not address the problem.  It was agreed in the WG that this common
capability of providing redunancy across hosts would not be address in a
single draft, but would be addressed repeatedly in each UA.  The editors of
M2UA, M3UA and SUA, however, have done a fantasitc job of aligning the common
ASP management procedures into a single set of mechanisms that just happens
to be repeated in each UA draft.

When an ASP connects to an SGP it either identifies itself with an ASP Id in
the ASP Up, by the IP+port combination of either side of the connection, or
the SGP needs to consider it as an ASP which is independent from all other
ASPs.  That is, if the SGP cannot identify the ASP but is willing to permit it
to go up, it must consider it as a ASP separate from all others.

When an ASP connects to an SGP, either it knows the identity of the SGP to
which it is connecting from configuration information, or it must consider the
SGP that it is connecting to as independent from other SGP instances to which
it has connected.

An SGP is not required to permit multiple connections to it from the same ASP
(it can refuse the association, refuse ASP Up, drop the association, send
error messages, ...).

Because the ASP is given no SGP Identifier (one does not exist in the draft)
it would be wise to consider SGP instances which cannot be discriminated as
independent SGP processes from the point of view of state sharing.

If an SGP Identifier was provided to the ASP (i.e, and SGP Id optionally
returned in the ASP Up Ack), then it would be possible to fully support
multiple associations between an ASP and an SGP.  Otherwise, the SGP must
have statically provisioned IP+port numbers.

There is no (interoperable) facility in the UAs for distributing messages
from an ASP to an SGP over multiple associations to the same SGP.  It is,
however, possible to treat this SGP as two different SGPs (that live and
die and change state together).  Then the normal ASPSM/TM procedures apply.

So I suppose that the drafts are really set up to have one association
between an SGP and ASP pair, however, what you consider an independent SGP
is up to the implementation.  For interoperability, the ASP needs to treat
the SGP at the other end of each association as an independent SGP.  Whether
that is the same "process" or not, and whether that "process" is on the same
host or not, is up to the implementation.  This permits an interoperable ASP
to view any SG architecture as a collection of independent SGPs at the other
end of an association.  Rather than worrying about which SGPs live and die
together.

--brian

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

---

---

From: [email-masked]
Date: Sun, 21 Oct 2001 00:32:03 +0530

Hi Brain,
See comments below.

> more than one SCTP association between them.

If this is true,  Then why is it in physical model of signalling transport
given in draft -7 shows two
SCTP connections for every ASP in host3 and host4.

> numbers, but the ASPs use dynamic port assignment.

If SGP listens on a well known port number, then can multiple SGP's exist on
the same
host which has only one IP address. I think this is not possible, since SGP
is acting as a
server and at any one time only one Process can listen on one particular
port.

If possible, then assume two SGP's (SGP1 and SGP2) are listening on the same
port number,
then to which SGP the incoming SCTP connection request from ASP belongs too?

Is my query valid????

Rgds
Venkatesh B

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 20 Oct 2001 14:30:37 -0500

Venkatesh,

Please see comments below...

[email-masked] wrote:                  (Sun, 21 Oct 2001 00:32:03)
> > > Are multiple associations between single SGP and ASP instance
> > > supported by the M3UA draft ? If yes, how ASP takes care or
> > > distributing the traffic to same SGP through multiple associations
> > > ?  Does ASP send ASP Up/Down/Act/Inact on each association
> > > separately ?
> > >
> > > thanx in advance
> > > Umesh
> > >
> >
> > Although I don't think that it is explicitly prohibited (or allowed)
> > in the draft, the WG did go to some pains over the discussion of ASP
> > Id and dynamic registration to ensure that it was possible to detect
> > and enforce one SCTP association per SGP/ASP in an implementation.
> >
> > Because an SGP and ASP are defined as SCTP endpoints (IP+port) there
> > cannot be more than one SCTP association between them.
> 
> If this is true,  Then why is it in physical model of signalling
> transport given in draft -7 shows two SCTP connections for every ASP
> in host3 and host4.

I think you misunderstand: There cannot be more than one association
between any given pair of SCTP endpoints.  Figure 1 Physical Model in
Draft 7 shows no more than one SCTP association between any pair of
ASP/SGP.

> >
> > There was concern, however, that an ASP that performs dynamic port
> > assignment might attempt to associate with an SGP twice (using a
> > different port assignment on each attempt) and that might result in
> > two SCTP associations between the same SGP/ASP pair.  The ASP Id in
> > the ASP Up permits the SGP to detect when an ASP has formed multiple
> > associations to it (when it receives ASP Up for the same ASP Id on
> > the second association) and refuse the second ASP Up with
> > ERR("Invalid ASP Identifier").  If dynamic assigment is used and the
> > SGP requires the ability to detect duplicate associations from the
> > same ASP, and the ASP does not provide ASP Id in the ASP Up, the SGP
> > can give it a push with ERR("ASP Identifier Required").
> >
> > ASPs can also be statically assigned IP+port numbers and the SGP
> > identifies the ASP from the IP+port number connecting.
> >
> > A mix is also permitted where the SGP listens on a well-known port
> > number and the ASP uses static assignment, or the SGP listens on
> > statically assigned port numbers, but the ASPs use dynamic port
> > assignment.
> 
> If SGP listens on a well known port number, then can multiple SGP's
> exist on the same host which has only one IP address. I think this is
> not possible, since SGP is acting as a server and at any one time only
> one Process can listen on one particular port.

That is not true, it is very possible.  Perhaps you should read
some about programming interfaces such as sockets or STREAMS.  When
a process listens on a port, it can still spawn new LWP or HWP to
service a connection when it accepts it.  SCTP is no different that
TCP in this respect.  Each spawed accepting process can be a different
SGP instance.

> If possible, then assume two SGP's (SGP1 and SGP2) are listening on
> the same port number, then to which SGP the incoming SCTP connection
> request from ASP belongs too?

There is no need to distinguish between SGP instances in this case
because they are identical, but distinct.  So, for example, if ASP1
connects twice to the well-known port (it requires different local
port numbers to do this), it gets two different copies of SGP.

> Is my query valid????

I think that you should learn a bit more about socket programming
and how to spawn server processes on well-known port numbers.
httpd does this all day long.  HTTP clients are never worried about
which "copy" of the HTTP server is serving them.

--brian

> 
> Rgds
> Venkatesh B
> 
> 
> >
> > Now, on the SG side, either the SG is listening on IP+well-
> > known-port number for the UA or the SG is listening on statically
> > provisioned IP+port number, each corresponding to an SGP.
> >
> > Some discussions in the working group on the SGP listening on the
> > well-known port number have indicated a concensus that if an ASP is
> > connecting to the SGP on the well-known port number that each
> > association will yield a different SGP.  (SGP is not a "host".  SGP
> > is a "process".)  This is in fitting with there being only one
> > association between ASP/SGP pair.
> >
> > Now, most of the discussions on this thread have been whether the
> > SGP share a large amount of state information or not.  Certainly SGP
> > which are on the same host can easily share state information via
> > shared-memory or other IPC.  However, the ability of SGP on
> > different hosts to share state information between them is highly
> > dependent upon the implemenation (distribtued) architecture.  To
> > avoid restricting distributed implementation architectures, an
> > implementation must be permitted to limit the amout of state sharing
> > between SGP.  In the distributed architecture there is also the
> > sitation where hosts within the architecture may become partitioned
> > due to failures and the platform should still be able to function.
> > Just because two SGP lose communication between themselves is no
> > reason to bring down the entire SG.  It will be hard to
> > cost-effectively meet carrier-class reliability if the SG platform
> > fails whenever two SGP lose communications.
> >
> > concerning AS: the local view (stored state), the shared view (from
> > other SGP), and the remove view (from the ASP).
> >
> > Now, in the monolithic implementation, the local view and shared
> > view can be the same.  That is, SGP (processes) within the
> > monolithic (albeit fault-tolerant) host share state information.
> > This is permitted.
> >
> > In the distributed implementaion, the local view and the shared view
> > might differ (particularly if SGP become partitioned).  In the
> > distribute implementation, it is important that only the local view
> > be synchronized with the remote view.
> >
> > ASPSM procedures are focussed at synchronizing the remove view at
> > the ASP concerning AS state with the SGP's local view in support of
> > distributed implementations.
> >
> > Much of this confusion has to do with SCTP's inability to provide
> > redunancy over multiple hosts.  Unfortunately, the SIGTRAN UAs have
> > had to solve this problem themselves.  It does add complexity to the
> > UA, but only because SCTP does not address the problem.  It was
> > agreed in the WG that this common capability of providing redunancy
> > across hosts would not be address in a single draft, but would be
> > addressed repeatedly in each UA.  The editors of M2UA, M3UA and SUA,
> > however, have done a fantasitc job of aligning the common ASP
> > management procedures into a single set of mechanisms that just
> > happens to be repeated in each UA draft.
> >
> > When an ASP connects to an SGP it either identifies itself with an
> > ASP Id in the ASP Up, by the IP+port combination of either side of
> > the connection, or the SGP needs to consider it as an ASP which is
> > independent from all other ASPs.  That is, if the SGP cannot
> > identify the ASP but is willing to permit it to go up, it must
> > consider it as a ASP separate from all others.
> >
> > When an ASP connects to an SGP, either it knows the identity of the
> > SGP to which it is connecting from configuration information, or it
> > must consider the SGP that it is connecting to as independent from
> > other SGP instances to which it has connected.
> >
> > An SGP is not required to permit multiple connections to it from the
> > same ASP (it can refuse the association, refuse ASP Up, drop the
> > association, send error messages, ...).
> >
> > Because the ASP is given no SGP Identifier (one does not exist in
> > the draft) it would be wise to consider SGP instances which cannot
> > be discriminated as independent SGP processes from the point of view
> > of state sharing.
> >
> > If an SGP Identifier was provided to the ASP (i.e, and SGP Id
> > optionally returned in the ASP Up Ack), then it would be possible to
> > fully support multiple associations between an ASP and an SGP.
> > Otherwise, the SGP must have statically provisioned IP+port numbers.
> >
> > There is no (interoperable) facility in the UAs for distributing
> > messages from an ASP to an SGP over multiple associations to the
> > same SGP.  It is, however, possible to treat this SGP as two
> > different SGPs (that live and die and change state together).  Then
> > the normal ASPSM/TM procedures apply.
> >
> > So I suppose that the drafts are really set up to have one
> > association between an SGP and ASP pair, however, what you consider
> > an independent SGP is up to the implementation.  For
> > interoperability, the ASP needs to treat the SGP at the other end of
> > each association as an independent SGP.  Whether that is the same
> > "process" or not, and whether that "process" is on the same host or
> > not, is up to the implementation.  This permits an interoperable ASP
> > to view any SG architecture as a collection of independent SGPs at
> > the other end of an association.  Rather than worrying about which
> > SGPs live and die together.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >

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

---