Subject: RE: [Sigtran] routing key span across more than one dpc

From: "Wung, Joseph" <[email-masked]>
Date: Fri, 7 Jun 2002 09:10:55 -0400

Brain,

My understanding about SPMC is that it can contain no
more than one single DPC by definition as quoted below.  
Becase of this, RKs are not permitted to span a DPC period.

But, the format of RK on page 45 does allow multiple DPCs
in one key.  Tolga replied earlier about them possilbly 
being used for alias PCs.  Don't see how alias will be
used in this regard.

Thanks,
Joe

"Signalling Point Management Cluster (SPMC) - The complete set of 
Application Servers represented to the SS7 network under a single MTP 
entity (Signalling Point) in one specific Network Appearance."

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, June 06, 2002 7:43 PM
To: Wung, Joseph
Cc: [email-masked]
Subject: Re: [Sigtran] routing key span across more than one dpc

Joseph,

Short answer:  Yes, if the DPC belong to the same SPMC.  No,
if they do not.  RKs are not permitted to span SPMC.

--brian

Wung, Joseph wrote:                                         (Thu, 06 Jun
2002 15:34:14)
> Question:
> 
> 	Can a Routing Key span across more than one DPC?
> 
> The answer should be no from the Terminology section of
> M3UA draft 12 as quoted here:
> 
> "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."
> 
> But, the format of the Routing Key parameter does allow more
> than one DPC in it as seen below.  Can someone explain this?
> 
> Thanks,
> Joe
> 
> 
>     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                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Traffic Mode Type (optional)                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Network Appearance (optional)                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Service Indicators (optional)                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Originating Point Code List (optional)           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Circuit Range List (optional)               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                              ...                              /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Service Indicators (optional)                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Originating Point Code List (optional)           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Circuit Range List (optional)               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Jun 2002 12:40:00 -0500

Wung,,

Wung, Joseph wrote:                          (Fri, 07 Jun 2002 09:10:55)
> Becase of this, RKs are not permitted to span a DPC period.

That is not true.  Any number of alias point codes can be
in the same SPMC.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Jun 2002 13:05:50 -0500

Joseph,

> Becase of this, RKs are not permitted to span a DPC period.

The quoted passage talks of MTP entity (not point code).
One MTP entity (from a management view) can have more than
one point code.  This is been discussed and agreed quite
some time ago.

> being used for alias PCs.  Don't see how alias will be

Alias point codes assigned to SP (and multiple point codes
assigned to SP) all belong to the same SPMC and are candidates
for the DPC list.  Even still, this restriction is not completely
enforced.  If your implementation can devise a way to make sense
out of RKs with multiple DPC not belonging to the same SPMC, I
don't believe there is anything in the RFC stopping you from
doing so.  You should expect problems with interworking of SSNM
messages, which presuppose the no more than one SPMC per RK
relationship.

--brian

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