Subject: RE: [Sigtran] M3UA: ASP to SGP communication

From: "Jolan Evans" <[email-masked]>
Date: Tue, 28 Jan 2003 19:01:56 +1100

I would like to raise a few issues regarding your procedures below for
ASP to SGP routing. I know this discussion took places a while ago, but
it has taken me some time to come up to speed with the RFC as I have
been busy on other things until recently.

Please note that I have inserted "M3UA" into the subject line of the
original email.

1. Nomenclature
AsPc: Point code of an AS. In defining routing keys, the RFC uses DPC
for this term as it takes the SG's frame of reference.
RemotePc: Point code of an SS7 MTP entity with which an AS communicates
via an SG, or directly in the case of IPSP-IPSP communication. In
defining routing keys, the RFC uses OPC for this term as it takes the
SG's frame of reference again.

2. Background Assumptions
As per Brian's introduction, we assume that zero or more MTP-User's are
bound to an MTP-SAP. The MTP-SAP exists in a particular MTP-Network,
which has a particular MTP protocol variant. An SG is associated with a
single MTP-Network. A RK is defined as in the RFC, but, for clarity, is
independent of any SG and associated with a single MTP-Network. An
SgRouteSet is uniquely defined by an RK, an SG and an MTP-SAP (the RK
and SG must be both associated with the same MTP-Network) and also
specifies the network appearance for the MTP-Network to be used with the
SG and the RC of each SGP in the SG. Therefore, an SgRouteSet is
implicitly associated with a single MTP-Network. An MTP-SAP is
associated with zero or more SgRouteSet's and therefore an MTP-SAP is
associated with zero or more RKs. In contrast, it appears that Brian
assumes that an MTP-SAP can only be associated with one RK. Given this
extension, we have the following requirement.

3. Routing Keys Requirements to Support Unique SS7 Destination Status
Let RemotePcSet(Rk) be the set of RemotePc's reachable via the SG from
the ASP where the RK is defined.
Consider any two SgRouteSet's SgRsA and SgRsA which are associated with
the same MTP-SAP.
Let the routing key of SgRsA and SgRsB be RkA and RkB respectively.
If the intersection of RemotePcSet(RkA) and RemotePcSet(RkB) is non-nil
then the routing keys MUST be identical in every respect apart from
their RemotePcSet.
If this wasn't the case, an ASP could never indicate an MTP-RESUME to an
MTP-USER because an MTP-RESUME can only specify a RemotePc and no other
SS7 element. I assume here for simplicity that every MTP-User of a
MTP-SAP must be given the same MTP status (i.e. different MTP-Users of
the same MTP-SAP cannot be given different MTP-Status indications
depending on what traffic they have requested).

Here's a concrete example of why this is so. Consider an ASP with the
following routing keys:
RkA: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={A}
RkB: MTP-Network=NetworkA, RemotePcSet={X}, AsPcSet={B}
RkC: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={M}
RkD: MTP-Network=NetworkA, RemotePcSet={Y}, SiSet={N}

Assume that RkA and RkB were both active in SgpA and SgpB respectively
and are associated with the same MTP-SAP, but different SGs. Also assume
that a DAVA has been received for RemotePc=X from SgpA after a DUNA from
SgpB for the same RemotePc. We might consider generating an MTP-Resume
to all the MTP-Users of the MTP-SAP for RemotePc X. However, if an
MTP-User requests an MTP-Transfer with an AsPc of B then SgpB may not be
able to transfer it as indicated by the DUNA it sent the ASP.

The same explanation applies to RkC and RkD.

In practice this requirement probably won't cause too many headaches
because it is likely that there would be two different MTP-Users, one
using only RkA/RkC and the other using only RkB/RkD. In this case, we
can simply create two MTP-SAPs in the same MTP-Network and associate
each routing key with a different MTP-SAP. Of course, this would require
the M3UA implementation to support more than one MTP-SAP per
MTP-Network, which would be extra work obviously.

4. ASP-SGP Routing should use SS7 Destination Availability/Restricted
Status on a per-SGP rather than a per-SG basis.

I believe your ASP-SGP procedures should be amended (I only amend the
multiple SG case as the single SG case is a special case of the former)
as follows:

Change:
"This routing information is updated by collecting DUNA/DAVA/DRST
messages received from (any of the SGP in) the SG."
To:
"This routing information is updated by collecting DUNA/DAVA/DRST
information on a per-(SGP,destination) basis. An SG is considered to be
available and unrestricted for a particular destination if any SGP in it
is available and unrestricted for that destination. Otherwise if this is
not he case, then an SG is considered to be restricted for a particular
destination if there is at least one SGP in the SG restricted for that
destination. Otherwise if this is not the case, the SG is considered to
be prohibited for that destination."

The RFC is not particular clear on this point. In section 1.4.1 para 3
it states that "MTP3 routeset, SPMC and remote AS/ASP states of each SGP
SHOULD be coordinated across all the SGPs". However, this uses "SHOULD"
which implies it is only recommended and it also doesn't specifically
state that SS7 destination availability, restriction and congestion
status ("SS7 destination status" for short) should be coordinated across
all SGPs. I don't think that "MTP3 routeset" necessarily implies SS7
destination status. Also, in section 1.3.2.5 1.4.2.5 it suggests in
should be on a per-SGP basis. Section 4.5.2.2 uses the word "SG" but
also uses the term "affected route(s)". Section 1.3.2.5 and section
1.4.2.5 suggest the word "route" refers to an SGP and not an SG. Hence,
given the ambiguity of section 4.5.2.2 I think that route can be
considered to refer to an SGP.

A configuration where per-SGP SS7 destination status is necessary is as
follows. Consider an SEP SG which has two SGP's acting as a redundant
pair. Each SGP has it's own link set to a particular STP. While in
section 1.4.1 para 3 it states that "Rerouting of traffic between the
SGPs MAY also be supported", it uses "MAY" and hence this is optional.
If one link set fails but not the other, one SGP will be able to reach
the SS7 network but not the other if rerouting between SGPs is not
supported or the rerouting link has also failed. Hence, it would be
possible for one SGP to send a DUNA for a particular destination but not
the other.

Your feedback would be appreciated.

Jolan.

--
Jolan Evans
Open Telecommunications
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian F. G. Bidulock
Sent: Tuesday, 8 October 2002 17:47
To: Srikanth Yandapalli
Cc: [email-masked]
Subject: Re: [Sigtran] ASP to SGP communication

Srikanth,

Srikanth Yandapalli wrote:               (Tue, 08 Oct 2002 12:03:52)
> 
>    I am late entrant to this group.I am quite sure all this should
have
>    been discussed and I am sorry about this.

Welcome.

> 
>    In the context of a single ASP in communication with multiple SGPs,
>    how should the routing of a MTP_DATA_REQ take place at the ASP?

I assume you are talking about M3UA?  As we are dealing with 5 or more
UAs
now, in the future it would be helpful to add M3UA (or whichever) to the
subject line.

> 
>    approach 1:
> 
>    We may find out the  RK and find out the SGP list that the RK is
>    active on and choose one SGP for sending the message based
>    on congestion level and also whether we have received any DRST
>    message from any of the SGPs.

This approach is applicable to multiple SGs, but not to multiple SGPs
within a
single SG.

>    approach 2:
> 
>    An SGP can also be viewed as providing route to a set of DPCs
>    and the routing can be based on the DPC for the message alone.
>    This approach is reduces the complexity but adds a situation
>    where the RK may not be active on that association. And also is
>    is mandatory to send RC on this association and if so what could
>    the SGP make out of the RC?

RC should be coordinated and the same across multiple SGPs within an SG.

> 
>    Is there a preferred approach to this issue?
> 

Typically, the logic can be something like this: (but there are several
other
schools of thought):

Single SG case: (multiple SGs is more complicated)

  MTP-TRANSFER request is issued by an MTP-User.  The MTP-User is bound
to an
  MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.  There is a pool
of
  SGPs on an SG for which the AS/RC/RK is active.  The AS may have
received
  MTP-PAUSE/RESUME/STATUS indications from the SG and may choose to
honor that
  information or not.  If the ASP chooses not to honor this information
it can
  blindly send messages to the SGP and rely upon a DUNA/SCON response
from the
  SGP later.

  Selection of an SGP within an SG is based on the traffic mode for the
SGP.
  This traffic mode is not managed by M3UA, however, M3UA provides for
  distribution of traffic over SGP based on any of the methods described
for
  ASPs (active/standby, load-share, broadcast).  A typical method is
  load-share based on SLS.  In this scheme, using the SLS in the
MTP-TRANSFER
  request, the ASP selects load-shares traffic over the available SGP.

Multiple SG case:

  In the more complicated multiple SG case, the ASP must first select an
SG
  before it selects an SGP within the SG.  The ASP must maintain some
  additional routing information to be able to properly select an SG.
This
  routing information is updated by collecting DUNA/DAVA/DRST messages
  received from (any of the SGP in) the SG.  To select the outgoing SG,
the
  ASP must examine the destination of the MTP-TRANSFER request.

  (If the SG has no SGP active for the AS/RC/RK, all destinations can be
  considered prohibited).

  If the destination is available and unrestricted for several SGs, the
ASP
  should select an SG on a load-sharing basis (based on SLS) and then
select
  an active SGP within the SG on the basis of the traffic mode for the
SG.

  If some SG are restricted for the specified destination (based on
received
  DRST messages from the SG), the ASP should load-share across the
available
  unrestricted SGs.  If all SGs are restricted for a given destination,
the
  ASP should load-share across the available SGs and ignore the
restricted
  status.
  
  If some SG are prohibited for the specified destination (based on
received
  DUNA messages from the SG), the ASP should load-share across the
available
  non-prohibited SGs.  If all SGs are prohibited for a given destination
(or
  no SGP is active for the AS/RC/RK in any SG), the ASP should respond
to the
  MTP-User with an MTP-PAUSE in accordance with the style of the
MTP-User
  interface (ITU-T and ANSI differ here).

Properly selecting SGs requires that the ASP maintain the DUNA/DAVA/DRST
information for each destination received from any SGP in an SG, on a
per-SG
basis.  This is the same as MTP Level 3 ROUTE status.  However, SCON
information should only be maintained on a per-destination basis (and
not
per-SG).  This is the same as MTP Level 3 ROUTESET status.

Note that, in general, it is a bad idea to consider congestion (SCON)
when
selecting an SG.  SCON does not necessarily indicate congestion at an SG
or on
a path to an SG, but indicates congestion at the affected destination or
somewhere (perhaps distant) in the SS7 network.  SCON is
ROUTESET-specific
(applies to the destination), whereas DUNA/DAVA/DRST is ROUTE-specific
(applies to the destination and path).  SCON should only be used to
determine
whether a message should be dropped completely and an MTP-STATUS
returned to
the MTP-User according to the style of the MTP-User interface (ITU-T and
ANSI
differ here again).

So, to summarize:  on behalf of the AS/RC/RK/MTP-User, the ASP
determines
whether to send a message based on SCON received for the specified
destination, then selects an SG based on DUNA/DAVA/DRST received for the
specified destination and load-shares based on SLS across the eligible
SGs.
Once an SG is selected, an active SGP (active for the AS/RC/RK) is
selected
within the SG based on the traffic mode of the SG (active/standby,
load-share,
broadcast: but typically load-share on SLS).

As I said, there are other schools of thought, but that is my
understanding.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Jan 2003 01:52:58 -0700

Jolan,

You are a litte of track: please see comments below...

Jolan Evans wrote:                                                                   (Tue, 28 Jan 2003 19:01:56)
> associated with zero or more RKs.

Bad assumption.  An MTP-SAP is assocated with one RK.  This is the
1:1:1 rule between AS:RK:RC.

> In contrast, it appears that Brian

RKs do not have to be defined at ASPs, just MTP-SAPs.

> Consider any two SgRouteSet's SgRsA and SgRsA which are associated with

I think you mean SgRsA and SgRsB <---.

> then the routing keys MUST be identical in every respect apart from

RkA and RkB must be identical or they cannot be associated with the
same MTP-SAP.  See 1:1:1 rule above.

> depending on what traffic they have requested).

The AS can deliver whatever MTP-STATUS indications it cares to.  If
there are SI values represented by the MTP-SAP, it is normally the
MTP-User's responsibility to sort out the MTP-STATUS indications.

> and are associated with the same MTP-SAP, but different SGs.

To be associated with the same MTP-SAP, RkA and RkB must be identical,
which implies that AsPcSetA and AsPcSetB are also identical.

> Also assume that a DAVA has been received for RemotePc=X from SgpA after a
> DUNA from SgpB for the same RemotePc. We might consider generating an
> MTP-Resume to all the MTP-Users of the MTP-SAP for RemotePc X. However, if
> an MTP-User requests an MTP-Transfer with an AsPc of B then SgpB may not be

This is not a problem because AsPc A must be identical to AsPc B.  Also,
you do not seem to realize that DAVA and DUNA are specific to the SG.
A DUNA received from one SG does not indicate that the affected destination
is also unavailable via the other SG.  It takes a DUNA from both SGs
to indicate that the affected destination is inaccessible.

> The same explanation applies to RkC and RkD.

For RkC and RkD to be associated with the same MTP-SAP requires that
they are identical according to the 1:1:1 rule above.

> using only RkA/RkC and the other using only RkB/RkD.

In fact there must be two different MTP-SAPs (and necessarily different
MTP-Users from the perspective of the SG) for RkA/RkC to tbe different
from RkB/RkD.

> In this case, we can simply create two MTP-SAPs in the same MTP-Network and
> associate each routing key with a different MTP-SAP. Of course, this would
> require the M3UA implementation to support more than one MTP-SAP per

It is not extra work.  M3UA not only supports this but requires it.
An MTP-SAP is an AS.  Having multiple AS (whether in a single network
or not) is fundamental to the SIGTRAN model.

> Status on a per-SGP rather than a per-SG basis.

Wrong.  ASPSM/ASPTM is per-SGP.  SSNM is per-SG.

> considered to refer to an SGP.

Each SGP in an SG offers identical connectivity to the SS7 network.
This means that a destination which is inaccessible to one SGP is
inaccessible to all, congested, restricted, accessible, etc.

> possible for one SGP to send a DUNA for a particular destination but not

This is addressed.  The SGP has suffered a complete failure (it is unable
to process traffic) and can simply drop its associations to the ASPs.
DUNA is incorrect here: the destination is still accessible from the SG.
One SGP has simply broken it's contract (providing identical connectivity
to the SS7 network as other SGP in the SG) and must be placed out of 
service.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Jan 2003 22:27:48 -0700

Jolan,

More comments below....

Jolan Evans wrote:                                                                   (Thu, 30 Jan 2003 14:27:28)
> See my comments below...
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, 28 January 2003 19:53
> > To: Jolan Evans
> > Cc: Sigtran
> > Subject: Re: [Sigtran] M3UA: ASP to SGP communication
> > 
> > Jolan,
> > 
> Ok, I neglected to state the circumstances and in particular the network
> topologies which drove me to make these assumptions, and in particular,
> the 1:many association between MTP-SAP:RK. Nonetheless, I can't find
> statements in the RFC to support your statement that an "MTP-SAP is
> assocated with one RK" and hence I would have to call this an assumption
> also. However, I stand corrected if this is not the case.

Secion 1.2 Terminology: Application Server:

  "... Note that there is a 1:1 relationship between an AS and a
  Routing Key".

> 
> Without further ado, here is one of the network topologies in which our
> ASP M3UA must operate. NB This is defined by our customers so we can't
> change it.
> 
> We must communicate with a number of SGs, for simplicity let's just say
> 2 as that's all that I need to illustrate my point. Likewise, it's not
> important how many SGP's they each have, so for simplicity let's assume
> that each SG has just one. Here is the network to which the ASP is
> connected:
> 
> MtpNetworkA: Protocol=ITU 92
> 
> MtpSapA: Network=MtpNetworkA

An MTP-SAP cannot be defined as an entire network (even just for SS7),
and there is no reason to do so.

> 
> SgA: Network=MtpNetworkA
> SgB: Network=MtpNetworkA
> 
> SgpA: Sg=SgA, etc
> SgpB: Sg=SgB, etc
> 
> RkA: Network=MtpNetworkA, AsPcSet={PcA, PcB}, RemotePcSet={PcW, PcX}
> RkA: Network=MtpNetworkA, AsPcSet={PcC, PcD}, RemotePcSet={PcY, PcZ}

I think you mean RkB on this last entry?

Also, the only way you can have multiple point codes in the AsPcSet
is if the point codes are "aliases" for the same signalling point.
In which case, the accessibility, for example, from PcA to PcW is
identical to the accesssibility from PcB to PcW.

> 
> SgRouteSetA: Sap=MtpSapA, RoutingKey=RkA, Sg=SgA, NetworkAppearance=0,
> SgpSet={(SgpA, Rc=0)}
> SgRouteSetB: Sap=MtpSapA, RoutingKey=RkB, Sg=SgB, NetworkAppearance=0,
> SgpSet={(SgpB, Rc=0)}

Again you try to have one AS serving multiple Routing Keys.  This violates
the 1:1 rule.  Because you have two RKs, you have two AS (and at least
two MTP-SAPs).

> 
> In this model, when the ASP-ACTIVE ACK is received for RkA (RkB), the
> ASP will audit the state of the RemotePcSet of RkA (RkB) at SgpA (SgpB).
> Ie the RemotePcSet of a routing key determine which remote PCs should
> have their status audited at a particular SG (I'll ignore the issue of
> whether it is SG or SGP for now).
> 
> I'm not clear how this would be translated to your model. As I see it,
> there is a problem because an MTP-SAP is only allowed to have one RK but
> the MTP-User of the SAP wants to talk with 2 different SGs, each with
> their own routing keys.

It is not my model.

Because you have two AS, there is not problem.  AS-A audits remote
desinations on RkA, AS-B audits remote destinations on RkB.

> 
> I can see 2 obvious ways to translate this configuration into your
> model: Either define just one RK or define two MTP-SAPs.

It is not my model.

But, you are required to define two AS because of the 1:1 rule.  How
many MTP-SAPs you have at the ASP is implementation dependent.

> 
> However, if there is one RK then we can no longer rely upon the
> RemotePcSet of the RK to determine the set of remote PCs of which the
> status should be audited when an ASP goes active with an SGP. This seems
> awkward and would seemingly require the RemotePcSet to be an attribute
> of the SgRouteSet.
> 
> If there are two MTP-SAPs then we are burdening the MTP-USER which must
> now aggregate traffic and destination status from two different
> MTP-SAPs. As far as I'm aware, in plain old MTP3 an MTP-USER can happily
> talk via just one MTP-SAP to two different STPs which have routesets to
> a different set of remote PCs.

For this situation, you do not need to burden the MTP-User.  It is the
M3UA layer at the ASP which is burdened.  In the multiple SG scenario,
the M3UA layer at the ASP is responsible for understanding which AS
correspond to which MTP-SAPs, and handling routing, and determining when
to send an MTP-User an MTP-PAUSE or RESUME based on DUNA and DAVA received
from each of the various SG.

So, in effect, although you require two AS, how many MTP-SAPs you have
at the ASP is implementation dependent.

In the non-multiple SG scenario (or where access is via a pair of SG
acting a an STP pair), the AS nicely maps 1:1 to an MTP-SAP.

> 
> Most of your remaining comments on my original items 2 and 3 are on the
> basis that one cannot assume a 1-many MTP-SAP:RK relationship. I won't
> reply to such comments as the real issue is the assumption itself.

You cannot have a 1:many AS:RK relationship.  How many AS you map into
an MTP-SAP is the implementation's business.

But your statement that the remainder of my comments are based on this
is untrue.  SSNM on a per-SGP basis is false and was ruled out in the
design of the protocol.  This has nothing to do with multiple RKs for
an MTP-SAP.

--brian

> I don't know what you mean by "whatever MTP-STATUS indications it cares
> to" but ITU Q.701 Table 1 shows that MTP-PAUSE and MTP-RESUME only
> contain the affected DPC. A lot of MTP-user software has been written on
> this assumption so we can't afford to change this.
> 
> > 
> > >
> > > Also assume that a DAVA has been received for RemotePc=X from SgpA
> after
> > a
> > > MTP-Resume to all the MTP-Users of the MTP-SAP for RemotePc X.
> However,
> > if
> > > an MTP-User requests an MTP-Transfer with an AsPc of B then SgpB may
> not
> > be
> > > In this case, we can simply create two MTP-SAPs in the same
> MTP-Network
> > and
> RFC section 1.4.1 para 3 makes it clear that the static configuration of
> the connectivity of the SGPs must be identical, but it doesn't make it
> clear that the SGPs should be designed to ensure identical connectivity
> at runtime. In particular I am referring to the statement "Rerouting of
> traffic between the MAY also be supported". If rerouting isn't supported
> amongst the SGPs of an SG (either in the SGP's M3UA or within an MTP3
> stack distributed between the SGPs) then I don't see how the SGPs can be
> expected to have identical connectivity in the event of a single point
> of failure.
> 
> Hence, I think that statements mirroring what you have said should be in
> the implementor's guide. Otherwise, without reading these emails, other
> people may be confused as to whether DAVA/DUNA/DRST destination status
> should be kept on a per-SG or a per-SGP basis.
> 
> > 
> > >

---

From: "Jolan Evans" <[email-masked]>
Date: Thu, 30 Jan 2003 14:27:28 +1100

See my comments below...

SgA: Network=MtpNetworkA
SgB: Network=MtpNetworkA

SgpA: Sg=SgA, etc
SgpB: Sg=SgB, etc

after
However,
not
MTP-Network

---

From: "Jolan Evans" <[email-masked]>
Date: Thu, 30 Jan 2003 18:53:54 +1100

More comments below...

--
Jolan Evans

Open Telecommunications

> Sent: Thursday, 30 January 2003 16:28
> To: Jolan Evans
> Cc: 'Sigtran'
> > > > I would like to raise a few issues regarding your procedures
below
> > for
> > > > ASP to SGP routing. I know this discussion took places a while
ago,
> > but
> > > > AsPc: Point code of an AS. In defining routing keys, the RFC
uses
> > DPC
> > > > defining routing keys, the RFC uses OPC for this term as it
takes
> > > > As per Brian's introduction, we assume that zero or more
MTP-User's
> > are
> > > > single MTP-Network. A RK is defined as in the RFC, but, for
clarity,
> > is
> > > > SgRouteSet is uniquely defined by an RK, an SG and an MTP-SAP
(the
> > RK
> > > > specifies the network appearance for the MTP-Network to be used
with
> > > > associated with zero or more SgRouteSet's and therefore an
MTP-SAP
> > is

You seem to be misreading what I have written. I've never said anything
to contradict that there is a 1:1 relationship between an AS and a RK.
My assumption is that there is a 1:many relationship between  RK's (or
AS's) and MTP-SAPs. I quote myself: "an MTP-SAP is associated with zero
or more RKs".

Your assumption is that there is a 1:1 relationship between RK's (or
AS's) and MTP-SAP's. I quote you: "An MTP-SAP is assocated with one RK".

Both of these statements are assumptions as far as the RFC is concerned
because the RFC makes no mention of an MTP-SAP entity (it only defines
an MTP-User).

> and there is no reason to do so.

Again, as the RFC doesn't define an MTP-SAP, I'm free to define it.

> I think you mean RkB on this last entry?

Yes, a typo.

> identical to the accesssibility from PcB to PcW.

Fair enough.

> the 1:1 rule.  Because you have two RKs, you have two AS (and at least

No, you appear to have misread what I have written. The one MTP-SAP (not
the same as an AS) has two RKs (or AS's).

> desinations on RkA, AS-B audits remote destinations on RkB.

Again, you appear to have misread what I have written. The one MTP-SAP
(not the same as an AS) has two RKs (or AS's).

> many MTP-SAPs you have at the ASP is implementation dependent.

Now we seem to be in agreement! To keep our MTP-Users simple, our
implementation will allow the one MTP-SAP to be associated with both
AS's, and as you state, the number of MTP-SAPs is implementation
dependent.

> from each of the various SG.

Sorry, but I don't understand how the MTP-User is not burdened. If there
are two MTP-SAPs upon which the MTP-User can receive MTP-Resume,
presumably the MTP-User will have to keep track of which one is
accessible for a particular remote PC and then send traffic on an
MTP-SAP in which the destination is accessible.

> acting a an STP pair), the AS nicely maps 1:1 to an MTP-SAP.

Agreed.

> design of the protocol.  This has nothing to do with multiple RKs for

You appear to have missed the "items 2 and 3" qualification. SSNM on a
per-SGP basis was in item 4.

> > > > assumes that an MTP-SAP can only be associated with one RK.
Given
> > this
> > > > Let RemotePcSet(Rk) be the set of RemotePc's reachable via the
SG
> > from
> > > > Consider any two SgRouteSet's SgRsA and SgRsA which are
associated
> > with
> > > > If this wasn't the case, an ASP could never indicate an
MTP-RESUME
> > to an
> > > > MTP-USER because an MTP-RESUME can only specify a RemotePc and
no
> > > > MTP-SAP must be given the same MTP status (i.e. different
MTP-Users
> > > > Here's a concrete example of why this is so. Consider an ASP
with
> > > > DUNA from SgpB for the same RemotePc. We might consider
generating
> > an
> > > > because it is likely that there would be two different
MTP-Users,
> > one
> > > > associate each routing key with a different MTP-SAP. Of course,
this
> > > would
> > > > I believe your ASP-SGP procedures should be amended (I only
amend
> > > > information on a per-(SGP,destination) basis. An SG is
considered to
> > be
> > > > available and unrestricted for a particular destination if any
SGP
> > in it
> > > > destination if there is at least one SGP in the SG restricted
for
> > that
> > > > destination. Otherwise if this is not the case, the SG is
considered
> > to
> > > > The RFC is not particular clear on this point. In section 1.4.1
para
> > 3
> > > > it states that "MTP3 routeset, SPMC and remote AS/ASP states of
each
> > SGP
> > > > status ("SS7 destination status" for short) should be
coordinated
> > across
> > > > A configuration where per-SGP SS7 destination status is
necessary is
> > as
> > > > section 1.4.1 para 3 it states that "Rerouting of traffic
between
> > > > possible for one SGP to send a DUNA for a particular destination
but
> > > DUNA is incorrect here: the destination is still accessible from
the
> > > > >    In the context of a single ASP in communication with
multiple
> > SGPs,
> > > > I assume you are talking about M3UA?  As we are dealing with 5
or
> > more
> > > > UAs
> > > > now, in the future it would be helpful to add M3UA (or
whichever) to
> > the
> > > > subject line.
> > > >
> > > > >
> > > > >    approach 1:
> > > > >
> > > > >    We may find out the  RK and find out the SGP list that the
RK
> > is
> > > > RC should be coordinated and the same across multiple SGPs
within an
> > > >   MTP-TRANSFER request is issued by an MTP-User.  The MTP-User
is
> > bound
> > > > to an
> > > >   MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.  There
is a
> > pool
> > > >   Selection of an SGP within an SG is based on the traffic mode
for
> > the
> > > > SGP.
> > > >   This traffic mode is not managed by M3UA, however, M3UA
provides
> > > >   request, the ASP selects load-shares traffic over the
available
> > > >   additional routing information to be able to properly select
an
> > > >   received from (any of the SGP in) the SG.  To select the
outgoing
> > SG,
> > > >   (If the SG has no SGP active for the AS/RC/RK, all
destinations
> > can be
> > > >   considered prohibited).
> > > >
> > > >   If the destination is available and unrestricted for several
SGs,
> > > >   an active SGP within the SG on the basis of the traffic mode
for
> > > > information for each destination received from any SGP in an SG,
on
> > > > selecting an SG.  SCON does not necessarily indicate congestion
at
> > an SG
> > > > the MTP-User according to the style of the MTP-User interface
(ITU-T
> > > > destination, then selects an SG based on DUNA/DAVA/DRST received
for

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jan 2003 03:16:07 -0700

Jolan,

Jolan Evans wrote:                                                                   (Thu, 30 Jan 2003 18:53:54)
> AS's) and MTP-SAP's. I quote you: "An MTP-SAP is assocated with one RK".

Normally.  You need multiple network appearances for it to be otherwise.
(An AS and an RK cannot span network appearances.)

Nevetheless, there is no problem with the RFC model, as the RFC uses
the concept of an Application Server which is limited to a single SPMC
and a single network appearance.

Define your MTP-SAPs how you like, it does not invalidate the RFC model.

> because the RFC makes no mention of an MTP-SAP entity (it only defines

The RFC deos not define an MTP-User: the SS7 specifications define an
MTP-User.

> Again, as the RFC doesn't define an MTP-SAP, I'm free to define it.

Go right ahead.  But don't say that there is a problem with SSNM messages
which are referenced to the AS.  If you want your MTP-SAPs to span
network appearances, you will need to have mutliple AS per MTP-SAP.

> the same as an AS) has two RKs (or AS's).

So what?  M3UA messages are only sent referenced on AS, not on MTP-SAP.

> (not the same as an AS) has two RKs (or AS's).

So what?  Define your MTP-SAPs how you like.  But, M3UA messages are
sent to the AS, not the MTP-SAP.

> AS's, and as you state, the number of MTP-SAPs is implementation

But it is only necessary to do so if you have more than one network
apperance for an MTP-SAP.  For most cases, the MTP-SAP and the AS
are the same entity.

> MTP-SAP in which the destination is accessible.

MTP-Users as defined in the SS7 specifications do not have multiple
MTP-SAPs based on remote point codes.  The MTP-SAP is based on local
point code only.  The MTP-User as defined in the SS7 specifications can
only have one MTP-SAP in this circumstance.  Therefore, M3UA at the ASP
must interwork multiple AS into one MTP-SAP.  The MTP-User is not
burdended.

> > acting a an STP pair), the AS nicely maps 1:1 to an MTP-SAP.

So what is your problem?  The RFC model works fine.

> per-SGP basis was in item 4.

Sorry, see below...

> > > this assumption so we can't afford to change this.

I did not say anything different.

> > > expected to have identical connectivity in the event of a single

It is the SGP's responsibility to remove itself from service if it
suffers a partial failure.  It can drop the SS7 association (which is
stated in the RFC), or it can send unsolicited ASPIA Ack, which according
to the ASP Inactive procedures will require to the ASP to consider itself in
the ASP Inactive state for the AS and allow it to attempt to reactivate
(which can be denied).

> > > should be kept on a per-SG or a per-SGP basis.

IMO, it is clear from sections 4.5.1 and 4.5.2 of the RFC.

--brian