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

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jun 2002 17:57:34 -0400

Joe,

No, tt can't. The reason for more than one DPC in dynamic registeration case
was to support alias point codes.

  Tolga

> -----Original Message-----
> From: Wung, Joseph [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 5:41 PM
> To: Tolga Asveren
> Subject: routing key span across more than one dpc
>
>
> Tolga,
>
> While I'm waiting for IETF to fix my mail problem, can I
> ask you the question I tried to post earlier.  The question
> is that can a Routing Key span more than one DPC?
>
> The definition of Routing Key in the Terminology section of
> M3UA draft 12 implies no.  But, the format of Routing Key
> on page 45 does allow more than one DPC in it.  Can you
> help me out here?  You can answer my question by cc to
> sigtran if you want.
>
> Thanks,
> Joe
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 5:37 PM
> To: Wung, Joseph
> Subject: RE: [Sigtran] Re: Doubt of M3UA SCON message
>
>
> Joe,
>
> Normally subscribing should be enough, no other procedures are necessary.
> Dod you subscribe today? If so, I would say, you wait 1-2 days
> and retry. If
> still it does not work, then you might try to complain abou thtis to
> [email-masked] .
>
> Sorry, that is all I know.
>
>     Tolga
>
> > -----Original Message-----
> > From: Wung, Joseph [mailto:[email-masked]]
> > Sent: Thursday, June 06, 2002 5:16 PM
> > To: Tolga Asveren
> > Subject: RE: [Sigtran] Re: Doubt of M3UA SCON message
> >
> >
> > Tolga,
> >
> > I recently subsrcibed to Sigtran and saw you guys
> > communicating with one another without problems.  It seems
> > that I can't post a question to Sigtran by sending a mail
> > to [email-masked], but I can only reply to others'.  Is
> > there anything I have missed doing?
> >
> > Thanks,
> > Joe
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Thursday, June 06, 2002 9:53 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] Re: Doubt of M3UA SCON message
> >
> >
> > Joe,
> >
> > > -----Original Message-----
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Wung, Joseph
> > > Sent: Thursday, June 06, 2002 9:29 AM
> > > To: [email-masked]; fangjishang
> > > Cc: [email-masked]
> > > Subject: RE: [Sigtran] Re: Doubt of M3UA SCON message
> > >
> > >
> > > 1) How would the ASP in this case detect congestion that was casued by
> > >    messages sent from a distant PC?  Shouldn't the congestion in this
> > >    direction be detected by the SGP instead?
> > [TOLGA] I think this point is discussible. Is congestion of ASP level3
> > congestion or just user part congestion? For user part
> > congestion, as far as
> > I can remember, no procedures are defined.
> > >
> > > 2) If the SGP is to send TFC in this case, can the STP it
> connects to be
> > > able
> > >    to handle the TFC from a non-STP node?  In SS7, TFC always
> originates
> > > from
> > >    the STP, so the STP does not expect TFC coming from a non-STP node.
> > [TOLGA] SGP can work in STP mode or SEP mode. And again as far as I
> > remember, even if it is seen as SEP, for ANSI96 TFC can be generated for
> > signalling point congestion. But as I indicated above, whether
> > congestion of
> > ASP should be interpreted as signalling point congestion or not
> is another
> > issue.
> > >
> > > Joe
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, June 06, 2002 12:00 AM
> > > To: fangjishang
> > > Cc: [email-masked]
> > > Subject: [Sigtran] Re: Doubt of M3UA SCON message
> > >
> > >
> > > fangjishang,
> > >
> > > On Thu, 06 Jun 2002, fangjishang wrote:
> > >
> > > >
> > > >    Dear Brian,
> > > >
> > > >      I have a doubt in implementing the SCON message at ASP side.
> > > >
> > > >      According to description in draft12, we have to fill
> > Concerned DPC
> > > >    field and Affected DPCs when we send SCON from ASP to SGP.
> > > >
> > > >    Pls refer the case as shown in the diagram below,
> > > >
> > > >                                                    AS1 :
> > Signalling PC =
> > > >    1
> > > >                                                  _______
> > > >                                  |--------------|       |
> > > >        |-----|                   |              | ASP1  |
> > > >        | SGP |-------------------|              |_______|
> > > >        |-----|                   |              ________
> > > >                                  |             |        |
> > > >                                  |_____________|   ASP1 |
> > > >                                                |________|
> > > >                                                    AS2 :
> > Signalling PC =
> > > >    2
> > > >
> > > >    When the ASP1 is congested, we should send SCON from ASP1
> > to SGP. My
> > > >    doubt is:
> > > >    <1>If ASP1 is operating in 2 diff AS (say AS1 and AS2), what
> > > should we
> > > >    fill in "affected DPC list" and "Concerned DPC" parameter
> > ? As per my
> > > >    understanding, Affected DPC is 1 and 2(OPCs of AS1 & AS2).
> > Concerned
> > > >    DPC is either 1 or 2. Is it correct ? If this is so, what
> > is the need
> > > >    of "Concerned DPC" in SCON message ?
> > >
> > > No, Concerned PC is the distant PC in the SS7 network which sent a
> > > message that caused the congestion.
> > >
> > > >
> > > >    <2> If SGP receives the SCON from ASP, what is the action
> > to be taken
> > > >    related to Concerned DPC ? what is the significance of
> > > "Concerned DPC"
> > > >    in SCON sent from ASP to SGP ?
> > >
> > > The SG might want to send TFC to the Concerned PC (DPC) with the
> > > Affected PC as the OPC.  But that is implementation dependent.
> > >
> > > --brian
> > >
> > > >
> > > >
> > > >    Thanks and regards.
> > > >    -Jesy
> > >
> > > --
> > > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> > >                         ¦ Therefore  all  progress  depends on the ¦
> > >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Wung, Joseph" <[email-masked]>
Date: Fri, 7 Jun 2002 12:23:57 -0400

Ken,

I agree with Tolga.  The OPC here refers to the remote PCs.
An RK should be able to handle more than one remote PC.
The issue here is the DPC, i.e., local PC.

Joe

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Friday, June 07, 2002 10:55 AM
To: [email-masked]
Subject: RE: [Sigtran] routing key span across more than one dpc

Ken,

Why this limitation for OPC list? I thought alias point code explanation
should apply for DPC case.

  Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ken Morneault
> Sent: Friday, June 07, 2002 10:33 AM
> To: Wung, Joseph; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] routing key span across more than one dpc
>
>
>
>
> Joe,
>
> The M3UA Implementors Guide clarifies the text to
> indicate an OPC list is only valid for alias point code.
> (see Section 3.8).
>
> Regards,
>
> Ken
>
> At 09:10 AM 6/7/2002 -0400, Wung, Joseph wrote:
> >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."
> >
> >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)               |
> >>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >Brian F. G. Bidulock
> >[email-masked]
> >http://www.openss7.org/