Subject: [Sigtran] SIGTRAN Interop, Day 3

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Sep 2005 12:04:05 +0200

Dear all,

SUA and M2PA issues will be sent out separately.

First issue:
draft-ietf-sigtran-rfc3332bis-04.txt states:

    Routing Key - A Routing Key describes a set of SS7 parameters and
    parameter values that uniquely define the range of signalling traffic
    to be handled by a particular Application Server. Parameters within
    the Routing Key cannot extend across more than a single Signalling
    Point Management Cluster.

and

    The format of the Routing Key parameter is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Local-RK-Identifier                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Routing Context (optional)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Traffic Mode Type (optional)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Network Appearance (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                              ...                              /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Note: The Destination Point Code, Service Indicators, and
       Originating Point Code List parameters MAY be repeated as a
       grouping within the Routing Key parameter, in the structure shown
       above.

Using the definition above there should be no multiple DPCs in the
routing key.

Second issue:
draft-ietf-sigtran-rfc3332bis-04.txt states:

       The optional ASP Identifier parameter contains a unique value that
       is locally significant among the ASPs that support an AS.

This text is not clear.

It was consensus here, that
- Every ASP has one ASP Identifier
- For every AS these values have to be unique between all ASPs in that 
AS.

Is that correct? Can the text be changed?

Third issue:
There is no limit on message sizes. Could there be a specified minimum 
message
size that can be handled by every implementation? It would also be good 
to
say how, for example, long BEAT messages are handled. Some 
implementations can not
handle, for example, 50000 byte BEAT message and send back an ERROR. 
Having this
described and having a limit which BEAT are really reflected seems to 
be helpful.

Fourth issue:
It was discussed how an ASP should react if it gets a DAVA for its own 
PC. The result
was that it should send an ERR or so.

Fifth issue:
It is not specified how you handle incorrect PPIDs. For example if an 
M3UA SG receives
a message with a PPID indicating SUA.

Best regards
Michael

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 06:26:13 -0600

Michael,

Michael Tuexen wrote:                                                              (Thu, 15 Sep 2005 12:04:05)
>     The format of the Routing Key parameter is as follows.

The statement above precludes a RK spanning SPMCs, it is allowed to span
DPCs.  If all DPCs are in the same SPMC (i.e. all SNMM message that
apply to one DPC apply to all other DPCs) then multiple DPCs can be
specified in the RK.  Although it is a sufficient condition that
different DPCs are in unique SPMCs (by definition), it is not a
necessary condition.  An SPMC can contain multiple DPCs.  An SPMC can be
considered as a set of DPCs to which all SNMM messages within the SPMC
apply.

> Is that correct? Can the text be changed?

That was the intention of the text.  ASP identifiers do not need to be
unique across AS, just within an AS.

> described and having a limit which BEAT are really reflected seems to 

I don't think that a limit should be placed, but an ERR procedure for
messages that are too long for the SGP/ASP/IPSP to handle would be good.

> was that it should send an ERR or so.

Receiving a DAVA for one's own point code from an SG is perfectly valid.

A DUNA or DRST coud only be an error.

> a message with a PPID indicating SUA.

ABORT comes to mind.  The choices are M3UA PPID or 0.  Anything else is
a mangled association.

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Sep 2005 15:21:07 +0200

Brian,

thank you very much for your answers.

I have some comments:

1. Isn't a SPMC something represented to the SS7 network as an entity.
    This implies for me that it has exactly one PC.

2. I agree with you that it is good to have a procedure to handle
    message which are too large. But it is necessary (in my opinion)
    to have a minimum size which is supported. How can you ever use
    BEAT messages if I say 4 bytes are the maximum I'm reflecting.

3. Regarding the last point. ABORT is OK or possibly sending an
    ERROR(protocol error).

Best regards
Michael

On Sep 15, 2005, at 14:26 Uhr, Brian F. G. Bidulock wrote:

>>        |                       Local-RK-Identifier                    
>>  |
>>        \                                                              
>>  \
>>        /                              ...                             
>>  /
>>        \                                                              
>>  \

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 07:47:19 -0600

Michael,

Michael Tuexen wrote:                                                              (Thu, 15 Sep 2005 15:21:07)
>     This implies for me that it has exactly one PC.

No.  SPMC is a "Signalling Point Management Cluster", accent on Management.
It is the unit by which SNMM messages have meaning.  Besides permitting
multple DPC in RK was agree by consensus long ago.  There is a short ladder
on it on the mailing list.

Just because an SPMC can contain more than one DPC does not mean that an
SG must support it.  There are adequate error messages that the SG can
return if it does not support such a routing key.  But as multiple DPC
per SPMC can be logically supported, there is no reason not to permit it
to be specified in the RK.  That was pretty much the thinking when we
changed it.  Some camps would say that RK granularity greater than a
single DPI/SI combination are not verfy useful.  Also that if an OPC is
given, that only one OPC is useful.  But the RK as it stands supports all
logical and supportable combinations.  It is up to the SG impl to decide
which it is capable of supporting and return errors for the rest.

>     BEAT messages if I say 4 bytes are the maximum I'm reflecting.

There are lots of places that an impl can place an artificial restriction
that can make it largely unusable.  Hey, how about if I set my receive
window at 64 bytes?  Or maximum inbound streams at 1.  At some point the
peer must decide that communication is not possible.

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Sep 2005 16:07:08 +0200

Brian,

see my comments inline.

Best regards
Michael

> which it is capable of supporting and return errors for the rest.
So you mean it can consist of multiple PCs, but is addressed from the
SS7 network only by one PC for management messages?
> peer must decide that communication is not possible.
a_rwnd = 64 is no problem as long as you implement the partial delivery 
API.
Performance might be. Nr. of inbound streams = 1 is covered by the ETSI 
standards.

But I think it would be good to know that an SIGTRAN implementation can 
handle
messages of size N at least. For example, nodes in the IP network are 
required
to be able to handle IP packets of a certain size...

The Info parameter has a limit, the BEAT not. SIGTRAN messages can 
become
pretty long. So it might be good to require SIGTRAN implementations to
be able to handle messages with length smaller or equal to 1024. I do 
not
care very much on the concrete number, but I think it would help 
people...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 11:42:32 -0600

Michael,

Michael Tuexen wrote:                                                              (Thu, 15 Sep 2005 16:07:08)

> SS7 network only by one PC for management messages?

The only point code in an SNMM is the Affected PC, not the Concerned PC.
The Concerned PCs are indicated by the Routing Context or Network Appearance.

When sending SCON from the ASP to the SGP, a Concerned PC parameter *is*
included in the SCON.  This is to identify to which DPC the message pertains
(and is kinda backwards in meaning).

These are not coincidences.  These messages were set up so that an AS
could have multiple point codes.

> care very much on the concrete number, but I think it would help 

Why so large?  An SS7 MTP messages under most circumstances will not exceed
270 bytes plus the overhead of an M3UA DATA message, which is about 300 bytes
or so.  Why make it larger than 300?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 28 Sep 2005 16:07:34 -0400

One comment below.

(Although this issue is already dated, still to prevent a confusion)

  Thanks,
  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Thursday, September 15, 2005 1:43 PM
> To: Michael Tuexen
> Cc: 'Sigtran'
> Subject: Re: [Sigtran] SIGTRAN Interop, Day 3
>
>
> Michael,
>
> Michael Tuexen wrote:
> > > Michael Tuexen wrote:
> > >             (Thu, 15 Sep 2005 15:21:07)
> > >> Brian,
> > >>
[TOLGA]Multiple DPC in RK is allowed only if those are alias PCs. Anything
other than that would break certain procedures of M3UA.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 28 Sep 2005 18:01:10 -0600

Tolga,

Tolga Asveren wrote:                          (Wed, 28 Sep 2005 16:07:34)
> other than that would break certain procedures of M3UA.

Which procedures are those?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Sep 2005 08:19:22 -0400

> Sent: Wednesday, September 28, 2005 8:01 PM
> To: Tolga Asveren
> Cc: 'Sigtran'
[TOLGA] -below when a speak of "multiple PC", I always mean "two PCs which
are not aliases"
	i. For a DUPU successfully to be transmitted to the correct originator
entity, RC is used. If a RK spans multiple RKs, it can't be determined which
user part will receive the corresponding notification.
	ii. The same argument applies also for SCON from SGP->ASP direction.
CencernedDPC is used only in ASP->SGP direction. For SGP->ASP case, RC is
the differentiator, and if a RK spans multiple PC, it can't be decided which
user part needs to get the notification.
	iii. The definition of SPMC is also clear in RFC. It talks about "The
complete set of Application Servers represented to the SS7 network under a
SINGLE MTP entity (Signalling Point) in one specific Network Appearance."
	iv. From operation point of view, multiple PCs in RK would be a confusion
rather than a flexibility. The main construct of MTP3 is PC and IMO
endorsing something larger than that would just cause incompatibility
issues.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Sep 2005 11:29:52 -0600

Tolga,

An "alias" point code is a point code shared by two STPs to
refer with redundancy to the Global Title Translation Function
between them.

I don't think that's what you are referring to here.

Your definition of "alias" seems to be that the point codes
belong to the same SPMC, which is a given.  It was already
stated that multiple point codes are allowed in an RK iff they
belong to the same SPMC.  If you want to call that "alias" then
fine, but I don't see the need to invent a new term.

--brian

Tolga Asveren wrote:                                                                 (Thu, 29 Sep 2005 08:19:22)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Sep 2005 13:30:56 -0400

Brian,

It is -alias PC as defined by ANSI- is what I am referring to. A RK can have
multiple DPCs only if those are alias PCs.

    Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 29, 2005 1:30 PM
> To: Tolga Asveren
> Cc: 'Sigtran'

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Sep 2005 11:56:34 -0600

Tolga,

The "alias" defined by ANSI is the shared alias PC of an STP pair.

--brian

Tolga Asveren wrote:                                                                 (Thu, 29 Sep 2005 13:30:56)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Sep 2005 13:57:11 -0400

Brian,

If "alias" concept can't be applied at endpoints, it probably won't be
applicable for AS definitons as well. I very well remember that "alias" PCs
were the argument for multiple DPC in RKs, but I don't recall a discussion
whether anybody uses that concept in endpoints -or whether it is ever usable
in such case-.

I kindly disagree with you that the concept you were explaining can be
identified as SPMC. Definition of SPMC in RFC is clear. It is associated
with a single MTP3 PC. It has nothing to do with "alias" PC, or something
similar to that. Actually for "aliasing" the crucial point is to have
"sister user parts".

IMHO, if "alias" concept is not applicable at endpoints, then no more than
one DPC should be allowed in RKs, otherwise certain procedures -like
handling DUPU, SCON- are broken.

    Tolga

> Sent: Thursday, September 29, 2005 1:57 PM
> To: Tolga Asveren
> Cc: 'Sigtran'

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Sep 2005 16:31:39 -0600

Tolga,

Tolga Asveren wrote:                        (Thu, 29 Sep 2005 13:57:11)
> whether anybody uses that concept in endpoints -or whether it is ever usable

Supporting multiple point codes for an SSP (SEP) has been common
practice in SS7 for almost 20 years now.  It is one way around
CIC limits for large switches.  It is not only usable, it is a
necessary functionality to support multiple point code switches.

> similar to that. Actually for "aliasing" the crucial point is to have

SPMC was never equal to a point code.  There would have been no
need for the term if it was just a point code.

Multiple point code switches do only have one (set of) user
part(s).  Each user part services all point codes on the switch.

> handling DUPU, SCON- are broken.

All management procedures work correctly (are transparent to
MTP) providing that all point codes belong to the same SPMC.
That is, they have the samme routing and screnning.

The behaviour is optional.  I would recommend that you don't use
it if you don't know how (neither SG nor ASP are required to any
Routing Key, for that matter).  But it is necessary to support
transparent operation to the MTP-User as described in Q.701, and
there is certainly no reason to prohibit it.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Sep 2005 09:14:40 -0400

Brian,

> necessary functionality to support multiple point code switches.
[TOLGA]The issue is not whether a network entity has multiple PCs or not.
You can have as many PCs assigned for your SSP as you want. The issue is,
whether indications for one user part can be received by another user part
or not. If it can, then I consider it "aliasing" (and probably ANSI alias
PCs at STPs is the only place where such behavior is specified in protocol
specifications (?) )

> part(s).  Each user part services all point codes on the switch.
[TOLGA] SPMC is associated with a single MTP3 PC. The need for it arises
because multiple M3UA elements need to be seen by SS7 netwrok as a single
entity. So, state from different entities need to be aggregated. The group
of elements, which are visible to SS7 network under a single PC are called
SPMC.

 ********************************
 *                              *
 *   AS1: DPC=A,     AS1: DPC=A,*
 *   SI=SCCP         SI=SCCP    *
 *  +-------+       +-------+   *
 *  |       |       |       |   *
 *  |  ASP1 |       |  ASP2 |   *
 *  |       |       |       |   *
 *  +----+--+       +---+---+   *
 ********************************
         |              |
         |              |
         |              |
      +--+--------------+--+
      |                    |
      |                    |
      |      SGP           |
      |    PC = B          |
      +--------------------+
For example, in the above figure, ASP1 and ASP2 form a SPMC. They are not
seen as independent entities from SS7 network point of view, e.g. that ASP1
is down should not cause a UPU to be sent for messages destined to
PC=A,SI=SCCP. PC=A should have a uniqie view. This is the rationale behind
the concept of SPMC and that is the reason -that we have a single logical
entity from SS7 point of view distributed on multiple physical entities- why
we need such a concept, even if it is associated with a single MTP3 PC -as
indicated also by definition of SPMC in M3UA RFC-.
> there is certainly no reason to prohibit it.
[TOLGA] Again, just to rephrase my position:
RC is the main routing construct for incoming messages at ASPs. This is true
also for messages like DUPU and SCON.

  AS with multiple DPC,
  AS=DPC=A,B  RC=1

      +--------+--------+
      |  DPC=A |  DPC=B |
      |  SCCP  |  SCCP  |
      |        |        |
      +--------+--------+
      |     ASP         |
      |    M3UA         |
      +----- -----------+
              ^
              |
              |DUPU(RC=1, Affected PC=Z)
              |
        +-----+----+
        |   SGP    |
        |   M3UA   |
        |          |
        +----------+

For example, in the above figure, how could ASP-M3UA decide, which user part
needs to get the indication? RC is not a differentiator between those two
user parts, because AS spans multiple RKs. Furthermore such a setup would
also force to inspect "Destination Point Code" filed in DATA messages. This
can be done but IMO it is ugly, I would prefer to keep RC the only routing
construct if possible.

Considering that neither you nor me are proposing text changes there is no
serious issue here. I just wanted to point out why I don't think multiple
PCs are allowed in an AS -except alias PCs- and what SPMC actually means.
Actually, if alias PC concept is not applicable at endpoints, IMO, multiple
DPCs are never allowed in a single RK.

    Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Sep 2005 11:41:35 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 30 Sep 2005 09:14:40)
> needs to get the indication?

Both.  In fact, all users parts, regardless of AS, in the same network
appearance could be given the indication.  The user part is unavailable,
that simple.

> RC is not a differentiator between those two user parts, because AS spans
> multiple RKs.

Doesn't matter.

> Furthermore such a setup would also force to inspect "Destination Point Code"
> filed in DATA messages. This can be done but IMO it is ugly, I would prefer
> to keep RC the only routing construct if possible.

M3UA does not need to examine DPC, it just delivers both to the
interface.  The MTP user examines the DPC.  You need am implementation
flexible enough to bind multiple PCs to one interface, but that's
implementation specific, isn't it?

> DPCs are never allowed in a single RK.

I think you need now to point out one procedure where it is problem:-
because you have not yet.

You seem to focus on user parts (SI codes), and yet SS7 (and M3UA)
permit binding the MTP/MTP-User interface on an entire point code (see
Q.700, Q.701, Q.704).  Each user part has its own availability
procedures (e.g., UPT of ISUP).

As historically you disagreed with RK at PC granularity it is not
supprising that you cannot agree with multiple PCs.  But, please, do
provide an example where either is a problem.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Sep 2005 13:47:01 -0400

Brian,

> Sent: Friday, September 30, 2005 1:42 PM
> To: Tolga Asveren
> Cc: 'Sigtran'
[TOLGA]Sorry, this is not how SS7 works. Only the originator of the message
to the unavailable user part should receive the indication. This is clear in
specifications. Otherwise user part unavailability could be broadcasted as
well like PC availability/unavailability by MTP3, but it isn't.
> > RC is not a differentiator between those two user parts,
[TOLGA]It matters if you want to behave inline with SS7 specs.
> implementation specific, isn't it?
[TOLGA]This does not make sense to me. A user part is supposed to receive
only messages which are intended for its own PC. To inspect destination PC
is to be done by MTP3 -discrimination functionality of MTP3-. I also
disagree that this is implementation dependent. If you want to be compliant
with specs the behavior is clear.
> because you have not yet.
[TOLGA]You try to address the problems I mentioned by not being compliant
with specs. Please see above, you send indications to user parts, which are
not supposed to receive them. If this is what you want fine, but this is
obviously not how SS7 works.
> procedures (e.g., UPT of ISUP).
[TOLGA]I don't have problem with that, as long as each user part receives,
what it is supposed to receive -and that you have UPT in ISUP does not mean
that you don't have UPU in MTP3-.
> provide an example where either is a problem.
[TOLGA]I don't have any issue with that right now -actually I have concerns
about certain configuration with sub-PC RKs when multiple SGs are utilized
but this is beside the point and can be left as configuration problem-.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Sep 2005 12:21:44 -0600

Tolga,

Tolga Asveren wrote:                              (Fri, 30 Sep 2005 13:47:01)
> well like PC availability/unavailability by MTP3, but it isn't.

Point to where.  I see where Q.704 says that if an MTP User binds to an entire
SI that the MTP User is on its own visa vi user part availability, but I don't
see where it says that UPU cannot be send to all concerned users in an MTP-STATUS.

> with specs the behavior is clear.

In our last discussion you though it wasn't so important to stick to the
letter of the MTP/MTP-User interface.  Now you do.

Well, although the specs define an MTP-SAP, it does not say that one
implementation interface cannot have multiple MTP-SAPs.  So that's not a
problem either.

> with specs.

Done.  Are there any procedures in M3UA that you think will not work.

> Please see above, you send indications to user parts, which are

I think I understand how SS7 works, by now.

> that you don't have UPU in MTP3-.

When the MTP-SAP is for all SI values, MTP is not required to deliver
MTP-STATUS(UPU) at all.  Read the specs.

> but this is beside the point and can be left as configuration problem-.

And yet you keep coming back to UPU.  SS7 specs permit binding the
MTP-SAP to an entire point code, in which case the MTP-User, so bound,
is on its own regarding user part availability.  This is the case for
PC granularity and is equally applicable to multiple PC granularity.

For me, the RC identifies the MTP/MTP-User interface, and whether that
interface has one or multiple MTP-SAPs bound is of no moment, regardless
of their granularity.

Do you have any other examples of what you believe to be problems?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Sep 2005 14:19:03 -0400

Brian,

> Sent: Friday, September 30, 2005 2:22 PM
> To: Tolga Asveren
> Cc: 'Sigtran'
[TOLGA] To summarize for the final time the problem -I really do apologize
from the members of the list for so many messages but this will be my final
post on this thread, I think now it is clear to everybody what my and
Brian's opinion/arguments  are -
If you follow MTP3 specification it is very clear to see. Message
discrimination functionality will decide whether a message is intended for
own PC or node. If yes, message distribution logic will decide for the
correct user part. Because UPU is sent to the originator of the message, it
never will be received by user parts belonging to another PC.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Sep 2005 14:15:56 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 30 Sep 2005 14:19:03)
> never will be received by user parts belonging to another PC.

Hogwash.  On both counts.

Read Q.704/2.4.1:

  "The destination point code field of the received message is examined
   by the discrimination function in order to [sic] determine whether or
   not it is destined to the receiving signalling point."

Read Q.701/3.2.3:

  "Message discrimination is the process which, upon receipt of a
   message at a signalling point, determines whether or not the point is
   the destination point of that message.  This decision is based on
   analysis of the destinaion code in the routing label in the message.
   If the signalling point is the destination point, the message is
   delivered to the message distribution function.  If it is not the
   destination point, and the signalling point has the transfer
   capability, the message is delivered to the routing function for
   further transfer on a signalling link."

Nowhere does it say that the destination point cannot have more than one
point code.

Read Q.704/11.2.7.2 (User Part availability control):

 "11.2.7.2.  When the originating signalling point's Message Transfer
 Part receives a User Part Unavailable message, it:

  a) informs the management process[5],

  b) sends an indication (MTP-STATUS with parameters identifying the
     signalling point containing the unavailable User Part, aw well as
     the cause "unequipped remote user" if no such user exists, or
     "inaccessible remote user" if the user exists but the MTP cannot
     currently distribute the message to it) to the local user
     designated in the message, if it is available.

  Note that the MTP does not maintain status information regarding the
  availability of the remote User Part."

What it does not say is that it is distributed to the local user by
destination point code.  It is distributed to the local user by SI
value.  In the case where the MTP-User is bound to an entire point code,
it receives MTP-STATUS for all SI values.

Read Q.701/4.2 (User location in system structure):

 "A potential user of the transport service is typically included in the
  system structure by provision of a separate User Part.  This requires
  allocation of a service indicator code, the specification of which is
  part of both the Message Transport Part and User Part concerned.

  As an alternative, a potential user may be catered for, together with
  other similar users, by an already existing or new User Part.  In such
  a case the discrimination of messages belonging to this potential user
  and the other similar users is an internal matter within the User Part
  concerned.  It then follows that all messages belonging to such a User
  Part are necessarily handled, e.g. as regards routing, in a uniform
  manner by the Message Transfer Part."

Which provides for User Parts that consist of mutiple SI values (and
point codes: note above that discrimination is on the basis of point
codes).

Read Q.700/5.2.1 (Point codes)

  "The DPC will always be determined and inserted in the routing label
   by the level 4 MTP "User".  This will alsog generally be the same for
   the OPC but it is possible that since the OPC might be constant it
   could be inserted by the MTP."

Which allows MTP Users with multiple point codes to specify their
originating point code.  Also the reason why the DATA message contains
the Originating Point Code, which would otherwise be redundant
information.  (If an RC cannot have multiple point codes then there is
would be no need to specify OPC in DATA, it would be a constant
associated with the RC).

We agreed by concensus many moons ago that RC could be as large as, but
no larger than NA.  NA has many point codes.  This was so that RC could
be included in all messages.

RC cannot be larger than an NA, because it would not be possible to
distinguish management messages from two network appearances.

Besides the final rfc3332bis permits it.  It was item 3.7 in the IGs.
The item predates release of the RFC.  The only question is why the
term "alias point code" was used without definition.

Although the SS7 specifications do not talk about alias point codes
(except in the ANSI STP GTT function case), it is common practice of SS7
implementations to permit an adjacent signalling point (the one at the
immediate other end of a signalling link) to have multiple point codes.
Primarily in support of the multiple point code switch arrangement.
This is given special designation at an STP so that the STP knows that
when the links are down, there are several point codes that have become
inaccessible via those links, regardless of the fact that they are
A-links.

So for M3UA purposes, it would be sufficient to say that these point
codes must live and die together (i.e. they are assigned to the same
node), and that they have the same routing and screening, and that they
distribute to the same user parts.

--brian

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