Subject: test

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 3 Aug 2001 09:28:08 -0700

From: Dan Brendes <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Mon, 30 Jul 2001 17:39:22 -0400
Subject: Re: M3UA07: Network Appearance
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: domino2.nc.tekelec.com [198.89.40.41]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I was under the impression that the purpose of the network appearance was to
be able to differentiate a point code in some network (such as an ITUN point
code of 100 in an Italian national network) from some other instance of that
point code in a different network.  By including the network appearance as
optional parameters in Data and DUNA/DAVA/etc messages it provides a way to
distinguish the Italian ITUN pc = 100 from the German ITUN pc =100, and so
on.  Thats all it is.  Nothing more.

The network appearance is a locally administered value at the SG that must
be shared with the ASP(s) only for those situations where the SG is
connected to multiple networks.

Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:
[email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC) Subject:  Re:
M3UA07: Network Appearance

Brian,

I see an SG as receiving many SS7 links from the network and packaging the
SS7 user for delivery into the IP network.  I really don't care what type of
links they are as it shouldn't matter.

A SG receives an SS7 message and relays it to some node in the IP network.

Jeff

"Brian F. G. Bidulock" wrote:
>
> Jeff,
>
> If the SG is connected to the network with A-links, E-links or
> F-links, you cannot look at it as an STP.  Restricting M3UA to
> an STP model would rule out many non-quasi-associated (F-link
> connected) networks in places such as Europe.
>
> --Brian
>
> Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> > Klaus,
> >
> > I agree with you that the discussions are getting increasingly
> > confusing.  This multiple networks business is getting increasingly
> > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > connects to multiple networks with no problems, so this must not be the
> > problem trying to be solved.
> >
> > Given the above thought, I go to the next thought which is that perhaps
> > an attempt is being made to make the SG(STP) appear as if it belongs to
> > different networks rather than just one.  In such a case, the SG(STP)
> > would need to have a multiple unique point code for identifying itself,
> > one for each network that it belongs to.  In such a case, if I'm
> > forwarding a message to some other element such as an ASP, then I would
> > need something like an NA to represent each SS7 network to the ASPs.
> > Doing this though would be a pain in the .... thought processs.
> >
> > Jeff
> >
> >
> > "Gradischnig, Klaus" wrote:
> > >
> > > All:
> > >
> > > I am getting increasingly confused by this discussion on NA. However,
just
> > > looking at its definition in M3UA08 alone would be enough to do the
job:
> > >
> > > "Network Appearance - The Network Appearance uniquely identifies an
SS7
> > > entity (Point Code) into an SS7 network, as presented by the SG.  It
is
> > > used for the purposes of logically separating the signalling traffic
> > > between the SG and the Application Server Processes over a common SCTP
> > > association.  This partitioning is necessary where an SG is logically
> > > partitioned to appear as end node elements in multiple separate SS7
> > >                                               ^^^^^^^^^^^^^^^^^^^^^
> > > networks, in which case there is a separate network appearance for
each
> > > ^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > point code in the SS7 networks.  It is also necessary when an SG is
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [KDG] This clearly says to me that I need an NA if and only if I have
> > > multiple networks. In this case I need an NA for every point code,
however.
> > > Why I would need this in the case of multiple networks only beats me.
[KDG]
> > >
> > > configured as an STP hosting multiple point codes, or when configured
> > > as multiple end nodes within the same network, in which case each
point
> > > code is a separate network appearance.between the SG and the
> > > Application Server Processes over a common SCTP Association.  An
> > > example is where an SG is logically partitioned to appear as an
element
> > > in four separate national SS7 networks.  A Network Appearance
> > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > protocol type/variant/version used within a separate SS7 network.
> > >
> > > [KDG] In contrast, this last sentence now tells me that I need one and
only
> > > one
> > > NA for each network. This is at least something I understand and it
> > > corresponds
> > > to NA's original definition. [KDG]"
> > >
> > > And while I can see where Brian's example below is coming from, I
can't
> > > except his arguments:
> > > In the general case OPC specific screening cannot be handled by MTP
> > > network/route management functions and therefore OPC specific routing
cannot
> > > be supported without restrictions to either connectivity or network
> > > management functionality. The example might start making sense if the
SG
> > > considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> > > different routing tables in the SG. In this case the SG may have to
have
> > > distinct point codes in these "separate" networks, provided then
"separate"
> > > networks are actually interconnected (seems not to be the case in this
> > > example, though).
> > > In any case, I fully support John's and Barry's view that NA
identifies a
> > > network (albeit from an SG internal view) and not an SPMC.
> > >
> > > I am -- on an abstract level -- rather concerned about the unnecessary
> > > complexity which has been introduced into m3ua and I have some
indication
> > > that a number of operators and manufacturers share this view. How much
of
> > > m3ua's functionality has actually been tested in Sophia? It seems to
me that
> > > without some extensive testing in a real or emulated SS7 network
environment
> > > going for last call is premature.
> > >
> > > Klaus
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: July 30, 2001 1:09 PM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > >
> > > >
> > > > John,
> > > >
> > > > Please see response inline...
> > > >
> > > > John Schantz wrote:                               (Mon, 30
> > > > Jul 2001 09:24:56)
> > > > > Brian,
> > > > >
> > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > single network
> > > > > appearance is needed per network connection.
> > > > >
> > > > >     More comments below.
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > > > Routing Context") that to cover all configurations, a
> > > > Network Appearance
> > > > > valud is required per primary point code and network id,
> > > > and that this
> > > > > proposal was a natural extension of that fact.  Consider
> > > > the case below:
> > > > >
> > > > > [John] NO.
> > > > >
> > > >
> > > >
> > > >                            200.1.4    __________
> > > >                              ___     /          \     ___
> > > >                             /   \   |            |   /   \
> > > >                            | SEP |__|____________|__| SEP |  AS1
> > > >                             \___/   |            |   \___/
> > > >                            //       |            |
> > > >                           / |       | Signalling |  5.255.3
> > > >                          / /        |   Gateway  |
> > > >                         /  |        |            |
> > > >                        /  /         |            |
> > > >                _____  /   |         |            |
> > > >               |     |/   /          |            |
> > > >          -----| STP |____|__________|______      |
> > > >              /|_____|   /           |      \___  |  5.255.4
> > > >             /    |      |           |          \_|_   ___
> > > >          \ /     |     /            |            | \ /   \
> > > >           X      |     |            |            |  | SEP |  AS2
> > > >          / \     |    /             |           _|_/ \___/
> > > >             \  __|__ /              |       ___/ |
> > > >              \|     |_______________|______/     |       5.255.5
> > > >          -----| STP |               |            |       (alias)
> > > >               |_____|               |            |
> > > >                                     |            |
> > > >                                      \__________/
> > > >
> > > >
> > > > >
> > > > > The signalling gateway needs two different Network Appearance
> > > > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > the alias
> > > > > point code 5.255.5 because they are both treated as the
> > > > same from an SS7
> > > > > newtork management view.
> > > > >
> > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > figure above, NO
> > > > > network appearance is needed at all.  What do you think the
> > > > point code is
> > > > > for??????  You seem to proposing that the network
> > > > appearance replace the
> > > > > point code for routing, NO.
> > > >
> > > > John, say I have one ASP serving two ASs and each AS serves
> > > > and entire SEP in
> > > > the diagram as labelled.  They are served over 1 association
> > > > to an ASP which
> > > > is configured and active for both ASs.  When the F-link fails
> > > > from the SG to
> > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > Without something
> > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > AS2 will also
> > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > 200.1.4 via
> > > > the STPs.
> > > >
> > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > traffic from AS1
> > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > may throw these
> > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > only point codes
> > > > allowed in the OPC on messages on the A-links.
> > > >
> > > > So, again, there are two choices:  Make Network Appearance an
> > > > identifier
> > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
servers
> > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > >
> > > > >
> > > > > Now, in general, a rational basis for assigning Network
> > > > Apearance Id's
> > > > > is to use the Network Id and Point Code of the node (the
> > > > node *is* the
> > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > the SG sends
> > > > > concerning the SPMC will be properly distinguish.
> > > > >
> > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > affected point
> > > > > code is all that is needed.
> > > > >
> > > > > Note that if the proposed assignment of Network Appearances is
used,
> > > > > the SCON message no longer requires a Concerned Point Code
parameter
> > > > > when the SPMC is signalling congestion to the SG.  It need only
use
> > > > > the Network Appearance.
> > > > >
> > > > > [John] NO.
> > > > >
> > > > > The definition of a Network Appearance becomes
> > > > (effectively): "An unique
> > > > > identifier indicating the Signalling Point Management
> > > > Cluster (SPMC) to
> > > > > which Signalling Network Management Messages apply."
> > > > >
> > > > > [John]  NO.
> > > > >
> > > > > --Brian
> > > > >
> > > > >
> > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > 2001 13:37:00)
> > > > > > Brian,
> > > > > >
> > > > > >   Why the need to include a concerned PC at all, the PC would be
> > > > > > redundant to the one in the DPC.  Why not let the network
> > > > appearance
> > > > > > parameter be equal to the Network ID (all 32 bits).  Then
Network
> > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > separate out the
> > > > > > traffic into networks in both directions SG->AS and
> > > > AS->SG(-> and beyond).
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > To: sigtran
> > > > > > Cc: Greg Sidebottom
> > > > > > Subject: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
Appearance
> > > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > > representing a large number of point codes, I would like to
> > > > > > propose the following refinement to the Network Appearance
> > > > > > Parameter:
> > > > > >
> > > > > > (This is in fitting with the definition that a "Network
Appearance
> > > > > uniquely
> > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > >
> > > > > > The format of the Network Appearance 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
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >    |  Network Id   |            Concerned Point Code
> > > >          |
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > >
> > > > > >    The Network Identifier identifies the network in which
> > > > the Concerned
> > > > > >    Point Code can be considered unique, and distinguishes
> > > > this Concerned
> > > > > >    Point Code from an identical point code in any another
network.
> > > > > >    A Network Identifier identifying a specific
> > > > adminsitrative domain for
> > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > global to all
> > > > > >    SGPs in an SG.
> > > > > >
> > > > > > Concerned Point Code:
> > > > > >
> > > > > >    The Concerned Point Code identifies a point code within the
> > > > > >    administrative domain as indicated by the Network
> > > > Identifier.  The
> > > > > >    Concerned Point Code is the one point code of a
> > > > Signalling Point
> > > > > >    Management Cluster (SPMC) which needs to receive
> > > > updates concerning
> > > > > >    the accessibility/restriction/congestion status of
> > > > routesets from the
> > > > > >    SPMC.
> > > > > >
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > > --
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > > >
> > > > --
> > > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
>
> Content-Description: footer
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
> --
> 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]

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\Jeff.Copley13.vcf"

---
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 14:48:38 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

YES, I totally agree.  It is not something that is assigned per point code
as the new definition for network appearance states.

John

-----Original Message-----
From: Dan Brendes [mailto:[email-masked]] Sent: Monday, July 30,
2001 4:39 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

I was under the impression that the purpose of the network appearance was to
be
able to differentiate a point code in some network (such as an ITUN point
code
of 100 in an Italian national network) from some other instance of that
point
code in a different network.  By including the network appearance as
optional
parameters in Data and DUNA/DAVA/etc messages it provides a way to
distinguish
the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
all it
is.  Nothing more.

The network appearance is a locally administered value at the SG that must
be
shared with the ASP(s) only for those situations where the SG is connected
to
multiple networks.

Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:
[email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC) Subject:  Re:
M3UA07: Network Appearance

Brian,

I see an SG as receiving many SS7 links from the network and packaging the
SS7 user for delivery into the IP network.  I really don't care what type of
links they are as it shouldn't matter.

A SG receives an SS7 message and relays it to some node in the IP network.

Jeff

"Brian F. G. Bidulock" wrote:
>
> Jeff,
>
> If the SG is connected to the network with A-links, E-links or
> F-links, you cannot look at it as an STP.  Restricting M3UA to
> an STP model would rule out many non-quasi-associated (F-link
> connected) networks in places such as Europe.
>
> --Brian
>
> Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> > Klaus,
> >
> > I agree with you that the discussions are getting increasingly
> > confusing.  This multiple networks business is getting increasingly
> > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > connects to multiple networks with no problems, so this must not be the
> > problem trying to be solved.
> >
> > Given the above thought, I go to the next thought which is that perhaps
> > an attempt is being made to make the SG(STP) appear as if it belongs to
> > different networks rather than just one.  In such a case, the SG(STP)
> > would need to have a multiple unique point code for identifying itself,
> > one for each network that it belongs to.  In such a case, if I'm
> > forwarding a message to some other element such as an ASP, then I would
> > need something like an NA to represent each SS7 network to the ASPs.
> > Doing this though would be a pain in the .... thought processs.
> >
> > Jeff
> >
> >
> > "Gradischnig, Klaus" wrote:
> > >
> > > All:
> > >
> > > I am getting increasingly confused by this discussion on NA. However,
just
> > > looking at its definition in M3UA08 alone would be enough to do the
job:
> > >
> > > "Network Appearance - The Network Appearance uniquely identifies an
SS7
> > > entity (Point Code) into an SS7 network, as presented by the SG.  It
is
> > > used for the purposes of logically separating the signalling traffic
> > > between the SG and the Application Server Processes over a common SCTP
> > > association.  This partitioning is necessary where an SG is logically
> > > partitioned to appear as end node elements in multiple separate SS7
> > >                                               ^^^^^^^^^^^^^^^^^^^^^
> > > networks, in which case there is a separate network appearance for
each
> > > ^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > point code in the SS7 networks.  It is also necessary when an SG is
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [KDG] This clearly says to me that I need an NA if and only if I have
> > > multiple networks. In this case I need an NA for every point code,
however.
> > > Why I would need this in the case of multiple networks only beats me.
[KDG]
> > >
> > > configured as an STP hosting multiple point codes, or when configured
> > > as multiple end nodes within the same network, in which case each
point
> > > code is a separate network appearance.between the SG and the
> > > Application Server Processes over a common SCTP Association.  An
> > > example is where an SG is logically partitioned to appear as an
element
> > > in four separate national SS7 networks.  A Network Appearance
> > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > protocol type/variant/version used within a separate SS7 network.
> > >
> > > [KDG] In contrast, this last sentence now tells me that I need one and
only
> > > one
> > > NA for each network. This is at least something I understand and it
> > > corresponds
> > > to NA's original definition. [KDG]"
> > >
> > > And while I can see where Brian's example below is coming from, I
can't
> > > except his arguments:
> > > In the general case OPC specific screening cannot be handled by MTP
> > > network/route management functions and therefore OPC specific routing
cannot
> > > be supported without restrictions to either connectivity or network
> > > management functionality. The example might start making sense if the
SG
> > > considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> > > different routing tables in the SG. In this case the SG may have to
have
> > > distinct point codes in these "separate" networks, provided then
"separate"
> > > networks are actually interconnected (seems not to be the case in this
> > > example, though).
> > > In any case, I fully support John's and Barry's view that NA
identifies a
> > > network (albeit from an SG internal view) and not an SPMC.
> > >
> > > I am -- on an abstract level -- rather concerned about the unnecessary
> > > complexity which has been introduced into m3ua and I have some
indication
> > > that a number of operators and manufacturers share this view. How much
of
> > > m3ua's functionality has actually been tested in Sophia? It seems to
me
that
> > > without some extensive testing in a real or emulated SS7 network
environment
> > > going for last call is premature.
> > >
> > > Klaus
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: July 30, 2001 1:09 PM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > >
> > > >
> > > > John,
> > > >
> > > > Please see response inline...
> > > >
> > > > John Schantz wrote:                               (Mon, 30
> > > > Jul 2001 09:24:56)
> > > > > Brian,
> > > > >
> > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > single network
> > > > > appearance is needed per network connection.
> > > > >
> > > > >     More comments below.
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > > > Routing Context") that to cover all configurations, a
> > > > Network Appearance
> > > > > valud is required per primary point code and network id,
> > > > and that this
> > > > > proposal was a natural extension of that fact.  Consider
> > > > the case below:
> > > > >
> > > > > [John] NO.
> > > > >
> > > >
> > > >
> > > >                            200.1.4    __________
> > > >                              ___     /          \     ___
> > > >                             /   \   |            |   /   \
> > > >                            | SEP |__|____________|__| SEP |  AS1
> > > >                             \___/   |            |   \___/
> > > >                            //       |            |
> > > >                           / |       | Signalling |  5.255.3
> > > >                          / /        |   Gateway  |
> > > >                         /  |        |            |
> > > >                        /  /         |            |
> > > >                _____  /   |         |            |
> > > >               |     |/   /          |            |
> > > >          -----| STP |____|__________|______      |
> > > >              /|_____|   /           |      \___  |  5.255.4
> > > >             /    |      |           |          \_|_   ___
> > > >          \ /     |     /            |            | \ /   \
> > > >           X      |     |            |            |  | SEP |  AS2
> > > >          / \     |    /             |           _|_/ \___/
> > > >             \  __|__ /              |       ___/ |
> > > >              \|     |_______________|______/     |       5.255.5
> > > >          -----| STP |               |            |       (alias)
> > > >               |_____|               |            |
> > > >                                     |            |
> > > >                                      \__________/
> > > >
> > > >
> > > > >
> > > > > The signalling gateway needs two different Network Appearance
> > > > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > the alias
> > > > > point code 5.255.5 because they are both treated as the
> > > > same from an SS7
> > > > > newtork management view.
> > > > >
> > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > figure above, NO
> > > > > network appearance is needed at all.  What do you think the
> > > > point code is
> > > > > for??????  You seem to proposing that the network
> > > > appearance replace the
> > > > > point code for routing, NO.
> > > >
> > > > John, say I have one ASP serving two ASs and each AS serves
> > > > and entire SEP in
> > > > the diagram as labelled.  They are served over 1 association
> > > > to an ASP which
> > > > is configured and active for both ASs.  When the F-link fails
> > > > from the SG to
> > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > Without something
> > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > AS2 will also
> > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > 200.1.4 via
> > > > the STPs.
> > > >
> > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > traffic from AS1
> > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > may throw these
> > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > only point codes
> > > > allowed in the OPC on messages on the A-links.
> > > >
> > > > So, again, there are two choices:  Make Network Appearance an
> > > > identifier
> > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
servers
> > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > >
> > > > >
> > > > > Now, in general, a rational basis for assigning Network
> > > > Apearance Id's
> > > > > is to use the Network Id and Point Code of the node (the
> > > > node *is* the
> > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > the SG sends
> > > > > concerning the SPMC will be properly distinguish.
> > > > >
> > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > affected point
> > > > > code is all that is needed.
> > > > >
> > > > > Note that if the proposed assignment of Network Appearances is
used,
> > > > > the SCON message no longer requires a Concerned Point Code
parameter
> > > > > when the SPMC is signalling congestion to the SG.  It need only
use
> > > > > the Network Appearance.
> > > > >
> > > > > [John] NO.
> > > > >
> > > > > The definition of a Network Appearance becomes
> > > > (effectively): "An unique
> > > > > identifier indicating the Signalling Point Management
> > > > Cluster (SPMC) to
> > > > > which Signalling Network Management Messages apply."
> > > > >
> > > > > [John]  NO.
> > > > >
> > > > > --Brian
> > > > >
> > > > >
> > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > 2001 13:37:00)
> > > > > > Brian,
> > > > > >
> > > > > >   Why the need to include a concerned PC at all, the PC would be
> > > > > > redundant to the one in the DPC.  Why not let the network
> > > > appearance
> > > > > > parameter be equal to the Network ID (all 32 bits).  Then
Network
> > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > separate out the
> > > > > > traffic into networks in both directions SG->AS and
> > > > AS->SG(-> and beyond).
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > To: sigtran
> > > > > > Cc: Greg Sidebottom
> > > > > > Subject: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
Appearance
> > > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > > representing a large number of point codes, I would like to
> > > > > > propose the following refinement to the Network Appearance
> > > > > > Parameter:
> > > > > >
> > > > > > (This is in fitting with the definition that a "Network
Appearance
> > > > > uniquely
> > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > >
> > > > > > The format of the Network Appearance 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
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >    |  Network Id   |            Concerned Point Code
> > > >          |
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > >
> > > > > >    The Network Identifier identifies the network in which
> > > > the Concerned
> > > > > >    Point Code can be considered unique, and distinguishes
> > > > this Concerned
> > > > > >    Point Code from an identical point code in any another
network.
> > > > > >    A Network Identifier identifying a specific
> > > > adminsitrative domain for
> > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > global to all
> > > > > >    SGPs in an SG.
> > > > > >
> > > > > > Concerned Point Code:
> > > > > >
> > > > > >    The Concerned Point Code identifies a point code within the
> > > > > >    administrative domain as indicated by the Network
> > > > Identifier.  The
> > > > > >    Concerned Point Code is the one point code of a
> > > > Signalling Point
> > > > > >    Management Cluster (SPMC) which needs to receive
> > > > updates concerning
> > > > > >    the accessibility/restriction/congestion status of
> > > > routesets from the
> > > > > >    SPMC.
> > > > > >
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > > --
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > > >
> > > > --
> > > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
>
> Content-Description: footer
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
>
> --
> 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]
To: "sigtran" <[email-masked]>
Date: Mon, 30 Jul 2001 15:05:27 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: RE: M3UA07: Network Appearance
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hmm, that's also what I remember from Sigtran discussions, albeit more than
6 months ago.  Is this being overloaded perhaps?

Cheers,

Lyndon 
--

On Mon, 30 Jul 2001 14:48:38   Schantz, John wrote:
>YES, I totally agree.  It is not something that is assigned per point code
>as the new definition for network appearance states.
>
>John
>
>-----Original Message-----
>From: Dan Brendes [mailto:[email-masked]]
>Sent: Monday, July 30, 2001 4:39 PM
>To: sigtran
>Subject: Re: M3UA07: Network Appearance
>
>
>
>
>I was under the impression that the purpose of the network appearance was
to
>be
>able to differentiate a point code in some network (such as an ITUN point
>code
>of 100 in an Italian national network) from some other instance of that
>point
>code in a different network.  By including the network appearance as
>optional
>parameters in Data and DUNA/DAVA/etc messages it provides a way to
>distinguish
>the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
>all it
>is.  Nothing more.
>
>The network appearance is a locally administered value at the SG that must
>be
>shared with the ASP(s) only for those situations where the SG is connected
>to
>multiple networks.
>
>
>
>
>
>
>Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
>
>Please respond to [email-masked]
>
>To:   "sigtran" <[email-masked]>
>cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
>Subject:  Re: M3UA07: Network Appearance
>
>
>
>
>Brian,
>
>I see an SG as receiving many SS7 links from the network and packaging
>the SS7 user for delivery into the IP network.  I really don't care what
>type of links they are as it shouldn't matter.
>
>A SG receives an SS7 message and relays it to some node in the IP
>network.
>
>Jeff
>
>"Brian F. G. Bidulock" wrote:
>>
>> Jeff,
>>
>> If the SG is connected to the network with A-links, E-links or
>> F-links, you cannot look at it as an STP.  Restricting M3UA to
>> an STP model would rule out many non-quasi-associated (F-link
>> connected) networks in places such as Europe.
>>
>> --Brian
>>
>> Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
>> > Klaus,
>> >
>> > I agree with you that the discussions are getting increasingly
>> > confusing.  This multiple networks business is getting increasingly
>> > confusing.  I look at the SS7 side of an SG like an STP.  An STP
>> > connects to multiple networks with no problems, so this must not be the
>> > problem trying to be solved.
>> >
>> > Given the above thought, I go to the next thought which is that perhaps
>> > an attempt is being made to make the SG(STP) appear as if it belongs to
>> > different networks rather than just one.  In such a case, the SG(STP)
>> > would need to have a multiple unique point code for identifying itself,
>> > one for each network that it belongs to.  In such a case, if I'm
>> > forwarding a message to some other element such as an ASP, then I would
>> > need something like an NA to represent each SS7 network to the ASPs.
>> > Doing this though would be a pain in the .... thought processs.
>> >
>> > Jeff
>> >
>> >
>> > "Gradischnig, Klaus" wrote:
>> > >
>> > > All:
>> > >
>> > > I am getting increasingly confused by this discussion on NA. However,
>just
>> > > looking at its definition in M3UA08 alone would be enough to do the
>job:
>> > >
>> > > "Network Appearance - The Network Appearance uniquely identifies an
>SS7
>> > > entity (Point Code) into an SS7 network, as presented by the SG.  It
>is
>> > > used for the purposes of logically separating the signalling traffic
>> > > between the SG and the Application Server Processes over a common
SCTP
>> > > association.  This partitioning is necessary where an SG is logically
>> > > partitioned to appear as end node elements in multiple separate SS7
>> > >                                               ^^^^^^^^^^^^^^^^^^^^^
>> > > networks, in which case there is a separate network appearance for
>each
>> > > ^^^^^^^^
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > point code in the SS7 networks.  It is also necessary when an SG is
>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > [KDG] This clearly says to me that I need an NA if and only if I have
>> > > multiple networks. In this case I need an NA for every point code,
>however.
>> > > Why I would need this in the case of multiple networks only beats me.
>[KDG]
>> > >
>> > > configured as an STP hosting multiple point codes, or when configured
>> > > as multiple end nodes within the same network, in which case each
>point
>> > > code is a separate network appearance.between the SG and the
>> > > Application Server Processes over a common SCTP Association.  An
>> > > example is where an SG is logically partitioned to appear as an
>element
>> > > in four separate national SS7 networks.  A Network Appearance
>> > >                                          ^^^^^^^^^^^^^^^^^^^^
>> > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > protocol type/variant/version used within a separate SS7 network.
>> > >
>> > > [KDG] In contrast, this last sentence now tells me that I need one
and
>only
>> > > one
>> > > NA for each network. This is at least something I understand and it
>> > > corresponds
>> > > to NA's original definition. [KDG]"
>> > >
>> > > And while I can see where Brian's example below is coming from, I
>can't
>> > > except his arguments:
>> > > In the general case OPC specific screening cannot be handled by MTP
>> > > network/route management functions and therefore OPC specific routing
>cannot
>> > > be supported without restrictions to either connectivity or network
>> > > management functionality. The example might start making sense if the
>SG
>> > > considered 5.255.3 and 5.255.4 to belong to "separate" networks using
>> > > different routing tables in the SG. In this case the SG may have to
>have
>> > > distinct point codes in these "separate" networks, provided then
>"separate"
>> > > networks are actually interconnected (seems not to be the case in
this
>> > > example, though).
>> > > In any case, I fully support John's and Barry's view that NA
>identifies a
>> > > network (albeit from an SG internal view) and not an SPMC.
>> > >
>> > > I am -- on an abstract level -- rather concerned about the
unnecessary
>> > > complexity which has been introduced into m3ua and I have some
>indication
>> > > that a number of operators and manufacturers share this view. How
much
>of
>> > > m3ua's functionality has actually been tested in Sophia? It seems to
>me
>that
>> > > without some extensive testing in a real or emulated SS7 network
>environment
>> > > going for last call is premature.
>> > >
>> > > Klaus
>> > >
>> > > > -----Original Message-----
>> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > Sent: July 30, 2001 1:09 PM
>> > > > To: sigtran
>> > > > Subject: Re: M3UA07: Network Appearance
>> > > >
>> > > >
>> > > > John,
>> > > >
>> > > > Please see response inline...
>> > > >
>> > > > John Schantz wrote:                               (Mon, 30
>> > > > Jul 2001 09:24:56)
>> > > > > Brian,
>> > > > >
>> > > > >     NO, see response to "M3UA: Routing Context".  Only a
>> > > > single network
>> > > > > appearance is needed per network connection.
>> > > > >
>> > > > >     More comments below.
>> > > > >
>> > > > > John
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > Sent: Saturday, July 28, 2001 8:08 AM
>> > > > > To: sigtran
>> > > > > Subject: Re: M3UA07: Network Appearance
>> > > > >
>> > > > >
>> > > > > John,
>> > > > >
>> > > > > Perhaps now you can see (from our discussion on the thread "M3UA:
>> > > > > Routing Context") that to cover all configurations, a
>> > > > Network Appearance
>> > > > > valud is required per primary point code and network id,
>> > > > and that this
>> > > > > proposal was a natural extension of that fact.  Consider
>> > > > the case below:
>> > > > >
>> > > > > [John] NO.
>> > > > >
>> > > >
>> > > >
>> > > >                            200.1.4    __________
>> > > >                              ___     /          \     ___
>> > > >                             /   \   |            |   /   \
>> > > >                            | SEP |__|____________|__| SEP |  AS1
>> > > >                             \___/   |            |   \___/
>> > > >                            //       |            |
>> > > >                           / |       | Signalling |  5.255.3
>> > > >                          / /        |   Gateway  |
>> > > >                         /  |        |            |
>> > > >                        /  /         |            |
>> > > >                _____  /   |         |            |
>> > > >               |     |/   /          |            |
>> > > >          -----| STP |____|__________|______      |
>> > > >              /|_____|   /           |      \___  |  5.255.4
>> > > >             /    |      |           |          \_|_   ___
>> > > >          \ /     |     /            |            | \ /   \
>> > > >           X      |     |            |            |  | SEP |  AS2
>> > > >          / \     |    /             |           _|_/ \___/
>> > > >             \  __|__ /              |       ___/ |
>> > > >              \|     |_______________|______/     |       5.255.5
>> > > >          -----| STP |               |            |       (alias)
>> > > >               |_____|               |            |
>> > > >                                     |            |
>> > > >                                      \__________/
>> > > >
>> > > >
>> > > > >
>> > > > > The signalling gateway needs two different Network Appearance
>> > > > > parameters: one per SPMC.  The bottom SPMC needs only one Network
>> > > > > Appearance to cover both the primary point code 5.255.4 and
>> > > > the alias
>> > > > > point code 5.255.5 because they are both treated as the
>> > > > same from an SS7
>> > > > > newtork management view.
>> > > > >
>> > > > > [John]  NO.  Since a SINGLE network connection is in the
>> > > > figure above, NO
>> > > > > network appearance is needed at all.  What do you think the
>> > > > point code is
>> > > > > for??????  You seem to proposing that the network
>> > > > appearance replace the
>> > > > > point code for routing, NO.
>> > > >
>> > > > John, say I have one ASP serving two ASs and each AS serves
>> > > > and entire SEP in
>> > > > the diagram as labelled.  They are served over 1 association
>> > > > to an ASP which
>> > > > is configured and active for both ASs.  When the F-link fails
>> > > > from the SG to
>> > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
>> > > > Without something
>> > > > (Routing Context/Network Appearance) to distinguish the DUNA,
>> > > > AS2 will also
>> > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
>> > > > 200.1.4 via
>> > > > the STPs.
>> > > >
>> > > > If the SG does not send DUNA(200.1.4) but attempts to route
>> > > > traffic from AS1
>> > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
>> > > > may throw these
>> > > > messages in the garbage because 5.255.4 and 5.255.5 are the
>> > > > only point codes
>> > > > allowed in the OPC on messages on the A-links.
>> > > >
>> > > > So, again, there are two choices:  Make Network Appearance an
>> > > > identifier
>> > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
>servers
>> > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
>> > > >
>> > > > >
>> > > > > Now, in general, a rational basis for assigning Network
>> > > > Apearance Id's
>> > > > > is to use the Network Id and Point Code of the node (the
>> > > > node *is* the
>> > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
>> > > > the SG sends
>> > > > > concerning the SPMC will be properly distinguish.
>> > > > >
>> > > > > [John]  NO.  A single network appearance (== network ID) +
>> > > > affected point
>> > > > > code is all that is needed.
>> > > > >
>> > > > > Note that if the proposed assignment of Network Appearances is
>used,
>> > > > > the SCON message no longer requires a Concerned Point Code
>parameter
>> > > > > when the SPMC is signalling congestion to the SG.  It need only
>use
>> > > > > the Network Appearance.
>> > > > >
>> > > > > [John] NO.
>> > > > >
>> > > > > The definition of a Network Appearance becomes
>> > > > (effectively): "An unique
>> > > > > identifier indicating the Signalling Point Management
>> > > > Cluster (SPMC) to
>> > > > > which Signalling Network Management Messages apply."
>> > > > >
>> > > > > [John]  NO.
>> > > > >
>> > > > > --Brian
>> > > > >
>> > > > >
>> > > > > Schantz, John wrote:                         (Mon, 23 Jul
>> > > > 2001 13:37:00)
>> > > > > > Brian,
>> > > > > >
>> > > > > >   Why the need to include a concerned PC at all, the PC would
be
>> > > > > > redundant to the one in the DPC.  Why not let the network
>> > > > appearance
>> > > > > > parameter be equal to the Network ID (all 32 bits).  Then
>Network
>> > > > > > Appearance(Network ID) + DPC will be unique and it will
>> > > > separate out the
>> > > > > > traffic into networks in both directions SG->AS and
>> > > > AS->SG(-> and beyond).
>> > > > > >
>> > > > > > John
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > > Sent: Monday, July 23, 2001 6:41 AM
>> > > > > > To: sigtran
>> > > > > > Cc: Greg Sidebottom
>> > > > > > Subject: M3UA07: Network Appearance
>> > > > > >
>> > > > > >
>> > > > > > Greg,
>> > > > > >
>> > > > > > When an SG is has multiple point codes serving ASPs which are
>> > > > > > active in multiple SPMCs, it becomes necessary to label each
>> > > > > > SPMC with a unique Network Appearance parameter to demultiplex
>> > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
>Appearance
>> > > > > > assignment is necessary for each SPMC and the adminstration of
>> > > > > > these assignments could get quite tedious for an SGP/ASP pool
>> > > > > > representing a large number of point codes, I would like to
>> > > > > > propose the following refinement to the Network Appearance
>> > > > > > Parameter:
>> > > > > >
>> > > > > > (This is in fitting with the definition that a "Network
>Appearance
>> > > > > uniquely
>> > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
>> > > > > >
>> > > > > > The format of the Network Appearance 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
>> > > > > >
>> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > >    |  Network Id   |            Concerned Point Code
>> > > >          |
>> > > > > >
>> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > >
>> > > > > > Network Identifier: 8-bit (unsigned integer)
>> > > > > >
>> > > > > >    The Network Identifier identifies the network in which
>> > > > the Concerned
>> > > > > >    Point Code can be considered unique, and distinguishes
>> > > > this Concerned
>> > > > > >    Point Code from an identical point code in any another
>network.
>> > > > > >    A Network Identifier identifying a specific
>> > > > adminsitrative domain for
>> > > > > >    the assignment of SS7 Signalling Point Codes MUST be
>> > > > global to all
>> > > > > >    SGPs in an SG.
>> > > > > >
>> > > > > > Concerned Point Code:
>> > > > > >
>> > > > > >    The Concerned Point Code identifies a point code within the
>> > > > > >    administrative domain as indicated by the Network
>> > > > Identifier.  The
>> > > > > >    Concerned Point Code is the one point code of a
>> > > > Signalling Point
>> > > > > >    Management Cluster (SPMC) which needs to receive
>> > > > updates concerning
>> > > > > >    the accessibility/restriction/congestion status of
>> > > > routesets from the
>> > > > > >    SPMC.
>> > > > > >
>> > > > > >
>> > > > > > Comments?
>> > > > > >
>> > > > > > --
>> > > > > > 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]
>> > > > >
>> > > > > --
>> > > > > 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]
>> > > >
>> > > > --
>> > > > 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]
>> Content-Description: Card for Jeff Copley
>> > begin:vcard
>> > n:Copley;Jeff
>> > tel;work:972.519.3758
>> > x-mozilla-html:FALSE
>> > org:Alcatel USA, Inc.
>> > version:2.1
>> > email;internet:[email-masked]
>> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
>NSGAP;Plano;Texas;75075-5813;USA
>> > x-mozilla-cpt:;20864
>> > fn:Jeff Copley
>> > end:vcard
>> >
>> >
>> >
>>
>> Content-Description: footer
>> > ---
>> > You are currently subscribed to sigtran as: [email-masked]
>> > To unsubscribe send a blank email to
>[email-masked]
>>
>> --
>> 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: nglaude <[email-masked]>
Subject: Re: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 18:14:31 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: femail37.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.254.60.31]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

Wow - what a thread to read!  For background information, the change in the
Network Appearance definition originally came in as proposal from Norm
Glaude and the rationale was provided in a thread that started in
December/January.   (Allow me as Editor to release a little frustration -
Where the hell was everybody then! - HA!, now I feel a little better!)

Anyway, I believe it was mostly to align the SUA and M3UA NA definitions but
there were some other reasons provided.  I haven't seen Norm on the list
recently - I hope he can be prodded to participate in this thread as this
change was quite important to him in discussions in San Diego and
Minneapolis.

Cheers,

  Greg

----- Original Message -----
From: "Schantz, John" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 30, 2001 5:48 PM
Subject: RE: M3UA07: Network Appearance

> YES, I totally agree.  It is not something that is assigned per point code
> as the new definition for network appearance states.
>
> John
>
> -----Original Message-----
> From: Dan Brendes [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 4:39 PM
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
>
>
>
>
> I was under the impression that the purpose of the network appearance was
to
> be
> able to differentiate a point code in some network (such as an ITUN point
> code
> of 100 in an Italian national network) from some other instance of that
> point
> code in a different network.  By including the network appearance as
> optional
> parameters in Data and DUNA/DAVA/etc messages it provides a way to
> distinguish
> the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
> all it
> is.  Nothing more.
>
> The network appearance is a locally administered value at the SG that must
> be
> shared with the ASP(s) only for those situations where the SG is connected
> to
> multiple networks.
>
>
>
>
>
>
> Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
>
> Please respond to [email-masked]
>
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> Subject:  Re: M3UA07: Network Appearance
>
>
>
>
> Brian,
>
> I see an SG as receiving many SS7 links from the network and packaging
> the SS7 user for delivery into the IP network.  I really don't care what
> type of links they are as it shouldn't matter.
>
> A SG receives an SS7 message and relays it to some node in the IP
> network.
>
> Jeff
>
> "Brian F. G. Bidulock" wrote:
> >
> > Jeff,
> >
> > If the SG is connected to the network with A-links, E-links or
> > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > an STP model would rule out many non-quasi-associated (F-link
> > connected) networks in places such as Europe.
> >
> > --Brian
> >
> > Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> > > Klaus,
> > >
> > > I agree with you that the discussions are getting increasingly
> > > confusing.  This multiple networks business is getting increasingly
> > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > connects to multiple networks with no problems, so this must not be
the
> > > problem trying to be solved.
> > >
> > > Given the above thought, I go to the next thought which is that
perhaps
> > > an attempt is being made to make the SG(STP) appear as if it belongs
to
> > > different networks rather than just one.  In such a case, the SG(STP)
> > > would need to have a multiple unique point code for identifying
itself,
> > > one for each network that it belongs to.  In such a case, if I'm
> > > forwarding a message to some other element such as an ASP, then I
would
> > > need something like an NA to represent each SS7 network to the ASPs.
> > > Doing this though would be a pain in the .... thought processs.
> > >
> > > Jeff
> > >
> > >
> > > "Gradischnig, Klaus" wrote:
> > > >
> > > > All:
> > > >
> > > > I am getting increasingly confused by this discussion on NA.
However,
> just
> > > > looking at its definition in M3UA08 alone would be enough to do the
> job:
> > > >
> > > > "Network Appearance - The Network Appearance uniquely identifies an
> SS7
> > > > entity (Point Code) into an SS7 network, as presented by the SG.  It
> is
> > > > used for the purposes of logically separating the signalling traffic
> > > > between the SG and the Application Server Processes over a common
SCTP
> > > > association.  This partitioning is necessary where an SG is
logically
> > > > partitioned to appear as end node elements in multiple separate SS7
> > > >                                               ^^^^^^^^^^^^^^^^^^^^^
> > > > networks, in which case there is a separate network appearance for
> each
> > > > ^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > point code in the SS7 networks.  It is also necessary when an SG is
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > [KDG] This clearly says to me that I need an NA if and only if I
have
> > > > multiple networks. In this case I need an NA for every point code,
> however.
> > > > Why I would need this in the case of multiple networks only beats
me.
> [KDG]
> > > >
> > > > configured as an STP hosting multiple point codes, or when
configured
> > > > as multiple end nodes within the same network, in which case each
> point
> > > > code is a separate network appearance.between the SG and the
> > > > Application Server Processes over a common SCTP Association.  An
> > > > example is where an SG is logically partitioned to appear as an
> element
> > > > in four separate national SS7 networks.  A Network Appearance
> > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > protocol type/variant/version used within a separate SS7 network.
> > > >
> > > > [KDG] In contrast, this last sentence now tells me that I need one
and
> only
> > > > one
> > > > NA for each network. This is at least something I understand and it
> > > > corresponds
> > > > to NA's original definition. [KDG]"
> > > >
> > > > And while I can see where Brian's example below is coming from, I
> can't
> > > > except his arguments:
> > > > In the general case OPC specific screening cannot be handled by MTP
> > > > network/route management functions and therefore OPC specific
routing
> cannot
> > > > be supported without restrictions to either connectivity or network
> > > > management functionality. The example might start making sense if
the
> SG
> > > > considered 5.255.3 and 5.255.4 to belong to "separate" networks
using
> > > > different routing tables in the SG. In this case the SG may have to
> have
> > > > distinct point codes in these "separate" networks, provided then
> "separate"
> > > > networks are actually interconnected (seems not to be the case in
this
> > > > example, though).
> > > > In any case, I fully support John's and Barry's view that NA
> identifies a
> > > > network (albeit from an SG internal view) and not an SPMC.
> > > >
> > > > I am -- on an abstract level -- rather concerned about the
unnecessary
> > > > complexity which has been introduced into m3ua and I have some
> indication
> > > > that a number of operators and manufacturers share this view. How
much
> of
> > > > m3ua's functionality has actually been tested in Sophia? It seems to
> me
> that
> > > > without some extensive testing in a real or emulated SS7 network
> environment
> > > > going for last call is premature.
> > > >
> > > > Klaus
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: July 30, 2001 1:09 PM
> > > > > To: sigtran
> > > > > Subject: Re: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > > Please see response inline...
> > > > >
> > > > > John Schantz wrote:                               (Mon, 30
> > > > > Jul 2001 09:24:56)
> > > > > > Brian,
> > > > > >
> > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > single network
> > > > > > appearance is needed per network connection.
> > > > > >
> > > > > >     More comments below.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Perhaps now you can see (from our discussion on the thread
"M3UA:
> > > > > > Routing Context") that to cover all configurations, a
> > > > > Network Appearance
> > > > > > valud is required per primary point code and network id,
> > > > > and that this
> > > > > > proposal was a natural extension of that fact.  Consider
> > > > > the case below:
> > > > > >
> > > > > > [John] NO.
> > > > > >
> > > > >
> > > > >
> > > > >                            200.1.4    __________
> > > > >                              ___     /          \     ___
> > > > >                             /   \   |            |   /   \
> > > > >                            | SEP |__|____________|__| SEP |  AS1
> > > > >                             \___/   |            |   \___/
> > > > >                            //       |            |
> > > > >                           / |       | Signalling |  5.255.3
> > > > >                          / /        |   Gateway  |
> > > > >                         /  |        |            |
> > > > >                        /  /         |            |
> > > > >                _____  /   |         |            |
> > > > >               |     |/   /          |            |
> > > > >          -----| STP |____|__________|______      |
> > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > >             /    |      |           |          \_|_   ___
> > > > >          \ /     |     /            |            | \ /   \
> > > > >           X      |     |            |            |  | SEP |  AS2
> > > > >          / \     |    /             |           _|_/ \___/
> > > > >             \  __|__ /              |       ___/ |
> > > > >              \|     |_______________|______/     |       5.255.5
> > > > >          -----| STP |               |            |       (alias)
> > > > >               |_____|               |            |
> > > > >                                     |            |
> > > > >                                      \__________/
> > > > >
> > > > >
> > > > > >
> > > > > > The signalling gateway needs two different Network Appearance
> > > > > > parameters: one per SPMC.  The bottom SPMC needs only one
Network
> > > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > > the alias
> > > > > > point code 5.255.5 because they are both treated as the
> > > > > same from an SS7
> > > > > > newtork management view.
> > > > > >
> > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > figure above, NO
> > > > > > network appearance is needed at all.  What do you think the
> > > > > point code is
> > > > > > for??????  You seem to proposing that the network
> > > > > appearance replace the
> > > > > > point code for routing, NO.
> > > > >
> > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > and entire SEP in
> > > > > the diagram as labelled.  They are served over 1 association
> > > > > to an ASP which
> > > > > is configured and active for both ASs.  When the F-link fails
> > > > > from the SG to
> > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > Without something
> > > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > > AS2 will also
> > > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > > 200.1.4 via
> > > > > the STPs.
> > > > >
> > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > traffic from AS1
> > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > may throw these
> > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > only point codes
> > > > > allowed in the OPC on messages on the A-links.
> > > > >
> > > > > So, again, there are two choices:  Make Network Appearance an
> > > > > identifier
> > > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
> servers
> > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > >
> > > > > >
> > > > > > Now, in general, a rational basis for assigning Network
> > > > > Apearance Id's
> > > > > > is to use the Network Id and Point Code of the node (the
> > > > > node *is* the
> > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > the SG sends
> > > > > > concerning the SPMC will be properly distinguish.
> > > > > >
> > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > affected point
> > > > > > code is all that is needed.
> > > > > >
> > > > > > Note that if the proposed assignment of Network Appearances is
> used,
> > > > > > the SCON message no longer requires a Concerned Point Code
> parameter
> > > > > > when the SPMC is signalling congestion to the SG.  It need only
> use
> > > > > > the Network Appearance.
> > > > > >
> > > > > > [John] NO.
> > > > > >
> > > > > > The definition of a Network Appearance becomes
> > > > > (effectively): "An unique
> > > > > > identifier indicating the Signalling Point Management
> > > > > Cluster (SPMC) to
> > > > > > which Signalling Network Management Messages apply."
> > > > > >
> > > > > > [John]  NO.
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > >
> > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > 2001 13:37:00)
> > > > > > > Brian,
> > > > > > >
> > > > > > >   Why the need to include a concerned PC at all, the PC would
be
> > > > > > > redundant to the one in the DPC.  Why not let the network
> > > > > appearance
> > > > > > > parameter be equal to the Network ID (all 32 bits).  Then
> Network
> > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > separate out the
> > > > > > > traffic into networks in both directions SG->AS and
> > > > > AS->SG(-> and beyond).
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > To: sigtran
> > > > > > > Cc: Greg Sidebottom
> > > > > > > Subject: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > Greg,
> > > > > > >
> > > > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
> Appearance
> > > > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > > > representing a large number of point codes, I would like to
> > > > > > > propose the following refinement to the Network Appearance
> > > > > > > Parameter:
> > > > > > >
> > > > > > > (This is in fitting with the definition that a "Network
> Appearance
> > > > > > uniquely
> > > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > > >
> > > > > > > The format of the Network Appearance 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
> > > > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > >    |  Network Id   |            Concerned Point Code
> > > > >          |
> > > > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > >
> > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > >
> > > > > > >    The Network Identifier identifies the network in which
> > > > > the Concerned
> > > > > > >    Point Code can be considered unique, and distinguishes
> > > > > this Concerned
> > > > > > >    Point Code from an identical point code in any another
> network.
> > > > > > >    A Network Identifier identifying a specific
> > > > > adminsitrative domain for
> > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > global to all
> > > > > > >    SGPs in an SG.
> > > > > > >
> > > > > > > Concerned Point Code:
> > > > > > >
> > > > > > >    The Concerned Point Code identifies a point code within the
> > > > > > >    administrative domain as indicated by the Network
> > > > > Identifier.  The
> > > > > > >    Concerned Point Code is the one point code of a
> > > > > Signalling Point
> > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > updates concerning
> > > > > > >    the accessibility/restriction/congestion status of
> > > > > routesets from the
> > > > > > >    SPMC.
> > > > > > >
> > > > > > >
> > > > > > > Comments?
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > > >
> > > > > > --
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > Content-Description: Card for Jeff Copley
> > > begin:vcard
> > > n:Copley;Jeff
> > > tel;work:972.519.3758
> > > x-mozilla-html:FALSE
> > > org:Alcatel USA, Inc.
> > > version:2.1
> > > email;internet:[email-masked]
> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> NSGAP;Plano;Texas;75075-5813;USA
> > > x-mozilla-cpt:;20864
> > > fn:Jeff Copley
> > > end:vcard
> > >
> > >
> > >
> >
> > Content-Description: footer
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> [email-masked]
> >
> > --
> > 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]
Date: Mon, 30 Jul 2001 17:36:30 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Yes, from the two old threads on Network Appearance it appears that Norm was
wanting Network Appearance to be SPMC Id (for the same reasons from the just
of it).  And Joyce even suggested making the Network Appearance be
(NetID<<24|PC).

Norm defined it as Network Appearance "in" any network, not the Network
Appearance "of" a network.  This equates to SPMC Id, which is sufficient for
all cases of management messages.

I like Joyce's proposal (which I spontaneously regenerated).

--Brian

Greg Sidebottom wrote:                           (Mon, 30 Jul 2001 18:14:31)
> Greetings,
> 
> Wow - what a thread to read!  For background information, the change in
the
> Network Appearance definition originally came in as proposal from Norm
> Glaude and the rationale was provided in a thread that started in
> December/January.   (Allow me as Editor to release a little frustration -
> Where the hell was everybody then! - HA!, now I feel a little better!)
> 
> Anyway, I believe it was mostly to align the SUA and M3UA NA definitions
but
> there were some other reasons provided.  I haven't seen Norm on the list
> recently - I hope he can be prodded to participate in this thread as this
> change was quite important to him in discussions in San Diego and
> Minneapolis.
> 
> Cheers,
> 
>   Greg
> 
> 
> ----- Original Message -----
> From: "Schantz, John" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 30, 2001 5:48 PM
> Subject: RE: M3UA07: Network Appearance
> 
> 
> > YES, I totally agree.  It is not something that is assigned per point
code
> > as the new definition for network appearance states.
> >
> > John
> >
> > -----Original Message-----
> > From: Dan Brendes [mailto:[email-masked]]
> > Sent: Monday, July 30, 2001 4:39 PM
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> >
> >
> >
> >
> > I was under the impression that the purpose of the network appearance
was
> to
> > be
> > able to differentiate a point code in some network (such as an ITUN
point
> > code
> > of 100 in an Italian national network) from some other instance of that
> > point
> > code in a different network.  By including the network appearance as
> > optional
> > parameters in Data and DUNA/DAVA/etc messages it provides a way to
> > distinguish
> > the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.
Thats
> > all it
> > is.  Nothing more.
> >
> > The network appearance is a locally administered value at the SG that
must
> > be
> > shared with the ASP(s) only for those situations where the SG is
connected
> > to
> > multiple networks.
> >
> >
> >
> >
> >
> >
> > Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
> >
> > Please respond to [email-masked]
> >
> > To:   "sigtran" <[email-masked]>
> > cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> > Subject:  Re: M3UA07: Network Appearance
> >
> >
> >
> >
> > Brian,
> >
> > I see an SG as receiving many SS7 links from the network and packaging
> > the SS7 user for delivery into the IP network.  I really don't care what
> > type of links they are as it shouldn't matter.
> >
> > A SG receives an SS7 message and relays it to some node in the IP
> > network.
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jeff,
> > >
> > > If the SG is connected to the network with A-links, E-links or
> > > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > > an STP model would rule out many non-quasi-associated (F-link
> > > connected) networks in places such as Europe.
> > >
> > > --Brian
> > >
> > > Jeff Copley wrote:                           (Mon, 30 Jul 2001
14:59:22)
> > > > Klaus,
> > > >
> > > > I agree with you that the discussions are getting increasingly
> > > > confusing.  This multiple networks business is getting increasingly
> > > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > > connects to multiple networks with no problems, so this must not be
> the
> > > > problem trying to be solved.
> > > >
> > > > Given the above thought, I go to the next thought which is that
> perhaps
> > > > an attempt is being made to make the SG(STP) appear as if it belongs
> to
> > > > different networks rather than just one.  In such a case, the
SG(STP)
> > > > would need to have a multiple unique point code for identifying
> itself,
> > > > one for each network that it belongs to.  In such a case, if I'm
> > > > forwarding a message to some other element such as an ASP, then I
> would
> > > > need something like an NA to represent each SS7 network to the ASPs.
> > > > Doing this though would be a pain in the .... thought processs.
> > > >
> > > > Jeff
> > > >
> > > >
> > > > "Gradischnig, Klaus" wrote:
> > > > >
> > > > > All:
> > > > >
> > > > > I am getting increasingly confused by this discussion on NA.
> However,
> > just
> > > > > looking at its definition in M3UA08 alone would be enough to do
the
> > job:
> > > > >
> > > > > "Network Appearance - The Network Appearance uniquely identifies
an
> > SS7
> > > > > entity (Point Code) into an SS7 network, as presented by the SG.
It
> > is
> > > > > used for the purposes of logically separating the signalling
traffic
> > > > > between the SG and the Application Server Processes over a common
> SCTP
> > > > > association.  This partitioning is necessary where an SG is
> logically
> > > > > partitioned to appear as end node elements in multiple separate
SS7
^^^^^^^^^^^^^^^^^^^^^
> > > > > networks, in which case there is a separate network appearance for
> > each
> > > > > ^^^^^^^^
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > point code in the SS7 networks.  It is also necessary when an SG
is
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > [KDG] This clearly says to me that I need an NA if and only if I
> have
> > > > > multiple networks. In this case I need an NA for every point code,
> > however.
> > > > > Why I would need this in the case of multiple networks only beats
> me.
> > [KDG]
> > > > >
> > > > > configured as an STP hosting multiple point codes, or when
> configured
> > > > > as multiple end nodes within the same network, in which case each
> > point
> > > > > code is a separate network appearance.between the SG and the
> > > > > Application Server Processes over a common SCTP Association.  An
> > > > > example is where an SG is logically partitioned to appear as an
> > element
> > > > > in four separate national SS7 networks.  A Network Appearance
> > > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > > implicitly defines the SS7 Point Code(s), Network Indicator and
MTP3
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > protocol type/variant/version used within a separate SS7 network.
> > > > >
> > > > > [KDG] In contrast, this last sentence now tells me that I need one
> and
> > only
> > > > > one
> > > > > NA for each network. This is at least something I understand and
it
> > > > > corresponds
> > > > > to NA's original definition. [KDG]"
> > > > >
> > > > > And while I can see where Brian's example below is coming from, I
> > can't
> > > > > except his arguments:
> > > > > In the general case OPC specific screening cannot be handled by
MTP
> > > > > network/route management functions and therefore OPC specific
> routing
> > cannot
> > > > > be supported without restrictions to either connectivity or
network
> > > > > management functionality. The example might start making sense if
> the
> > SG
> > > > > considered 5.255.3 and 5.255.4 to belong to "separate" networks
> using
> > > > > different routing tables in the SG. In this case the SG may have
to
> > have
> > > > > distinct point codes in these "separate" networks, provided then
> > "separate"
> > > > > networks are actually interconnected (seems not to be the case in
> this
> > > > > example, though).
> > > > > In any case, I fully support John's and Barry's view that NA
> > identifies a
> > > > > network (albeit from an SG internal view) and not an SPMC.
> > > > >
> > > > > I am -- on an abstract level -- rather concerned about the
> unnecessary
> > > > > complexity which has been introduced into m3ua and I have some
> > indication
> > > > > that a number of operators and manufacturers share this view. How
> much
> > of
> > > > > m3ua's functionality has actually been tested in Sophia? It seems
to
> > me
> > that
> > > > > without some extensive testing in a real or emulated SS7 network
> > environment
> > > > > going for last call is premature.
> > > > >
> > > > > Klaus
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: July 30, 2001 1:09 PM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Please see response inline...
> > > > > >
> > > > > > John Schantz wrote:                               (Mon, 30
> > > > > > Jul 2001 09:24:56)
> > > > > > > Brian,
> > > > > > >
> > > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > > single network
> > > > > > > appearance is needed per network connection.
> > > > > > >
> > > > > > >     More comments below.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Perhaps now you can see (from our discussion on the thread
> "M3UA:
> > > > > > > Routing Context") that to cover all configurations, a
> > > > > > Network Appearance
> > > > > > > valud is required per primary point code and network id,
> > > > > > and that this
> > > > > > > proposal was a natural extension of that fact.  Consider
> > > > > > the case below:
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >                            200.1.4    __________
> > > > > >                              ___     /          \     ___
> > > > > >                             /   \   |            |   /   \
> > > > > >                            | SEP |__|____________|__| SEP |  AS1
> > > > > >                             \___/   |            |   \___/
> > > > > >                            //       |            |
> > > > > >                           / |       | Signalling |  5.255.3
> > > > > >                          / /        |   Gateway  |
> > > > > >                         /  |        |            |
> > > > > >                        /  /         |            |
> > > > > >                _____  /   |         |            |
> > > > > >               |     |/   /          |            |
> > > > > >          -----| STP |____|__________|______      |
> > > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > > >             /    |      |           |          \_|_   ___
> > > > > >          \ /     |     /            |            | \ /   \
> > > > > >           X      |     |            |            |  | SEP |  AS2
> > > > > >          / \     |    /             |           _|_/ \___/
> > > > > >             \  __|__ /              |       ___/ |
> > > > > >              \|     |_______________|______/     |       5.255.5
> > > > > >          -----| STP |               |            |       (alias)
> > > > > >               |_____|               |            |
> > > > > >                                     |            |
> > > > > >                                      \__________/
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > The signalling gateway needs two different Network Appearance
> > > > > > > parameters: one per SPMC.  The bottom SPMC needs only one
> Network
> > > > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > > > the alias
> > > > > > > point code 5.255.5 because they are both treated as the
> > > > > > same from an SS7
> > > > > > > newtork management view.
> > > > > > >
> > > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > > figure above, NO
> > > > > > > network appearance is needed at all.  What do you think the
> > > > > > point code is
> > > > > > > for??????  You seem to proposing that the network
> > > > > > appearance replace the
> > > > > > > point code for routing, NO.
> > > > > >
> > > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > > and entire SEP in
> > > > > > the diagram as labelled.  They are served over 1 association
> > > > > > to an ASP which
> > > > > > is configured and active for both ASs.  When the F-link fails
> > > > > > from the SG to
> > > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > > Without something
> > > > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > > > AS2 will also
> > > > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > > > 200.1.4 via
> > > > > > the STPs.
> > > > > >
> > > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > > traffic from AS1
> > > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > > may throw these
> > > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > > only point codes
> > > > > > allowed in the OPC on messages on the A-links.
> > > > > >
> > > > > > So, again, there are two choices:  Make Network Appearance an
> > > > > > identifier
> > > > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
> > servers
> > > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > > >
> > > > > > >
> > > > > > > Now, in general, a rational basis for assigning Network
> > > > > > Apearance Id's
> > > > > > > is to use the Network Id and Point Code of the node (the
> > > > > > node *is* the
> > > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > > the SG sends
> > > > > > > concerning the SPMC will be properly distinguish.
> > > > > > >
> > > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > > affected point
> > > > > > > code is all that is needed.
> > > > > > >
> > > > > > > Note that if the proposed assignment of Network Appearances is
> > used,
> > > > > > > the SCON message no longer requires a Concerned Point Code
> > parameter
> > > > > > > when the SPMC is signalling congestion to the SG.  It need
only
> > use
> > > > > > > the Network Appearance.
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > > > The definition of a Network Appearance becomes
> > > > > > (effectively): "An unique
> > > > > > > identifier indicating the Signalling Point Management
> > > > > > Cluster (SPMC) to
> > > > > > > which Signalling Network Management Messages apply."
> > > > > > >
> > > > > > > [John]  NO.
> > > > > > >
> > > > > > > --Brian
> > > > > > >
> > > > > > >
> > > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > > 2001 13:37:00)
> > > > > > > > Brian,
> > > > > > > >
> > > > > > > >   Why the need to include a concerned PC at all, the PC
would
> be
> > > > > > > > redundant to the one in the DPC.  Why not let the network
> > > > > > appearance
> > > > > > > > parameter be equal to the Network ID (all 32 bits).  Then
> > Network
> > > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > > separate out the
> > > > > > > > traffic into networks in both directions SG->AS and
> > > > > > AS->SG(-> and beyond).
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > > To: sigtran
> > > > > > > > Cc: Greg Sidebottom
> > > > > > > > Subject: M3UA07: Network Appearance
> > > > > > > >
> > > > > > > >
> > > > > > > > Greg,
> > > > > > > >
> > > > > > > > When an SG is has multiple point codes serving ASPs which
are
> > > > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > > > SPMC with a unique Network Appearance parameter to
demultiplex
> > > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
> > Appearance
> > > > > > > > assignment is necessary for each SPMC and the adminstration
of
> > > > > > > > these assignments could get quite tedious for an SGP/ASP
pool
> > > > > > > > representing a large number of point codes, I would like to
> > > > > > > > propose the following refinement to the Network Appearance
> > > > > > > > Parameter:
> > > > > > > >
> > > > > > > > (This is in fitting with the definition that a "Network
> > Appearance
> > > > > > > uniquely
> > > > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > > > >
> > > > > > > > The format of the Network Appearance 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
> > > > > > > >
> > > > > >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >    |  Network Id   |            Concerned Point Code
> > > > > >          |
> > > > > > > >
> > > > > >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >
> > > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > > >
> > > > > > > >    The Network Identifier identifies the network in which
> > > > > > the Concerned
> > > > > > > >    Point Code can be considered unique, and distinguishes
> > > > > > this Concerned
> > > > > > > >    Point Code from an identical point code in any another
> > network.
> > > > > > > >    A Network Identifier identifying a specific
> > > > > > adminsitrative domain for
> > > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > > global to all
> > > > > > > >    SGPs in an SG.
> > > > > > > >
> > > > > > > > Concerned Point Code:
> > > > > > > >
> > > > > > > >    The Concerned Point Code identifies a point code within
the
> > > > > > > >    administrative domain as indicated by the Network
> > > > > > Identifier.  The
> > > > > > > >    Concerned Point Code is the one point code of a
> > > > > > Signalling Point
> > > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > > updates concerning
> > > > > > > >    the accessibility/restriction/congestion status of
> > > > > > routesets from the
> > > > > > > >    SPMC.
> > > > > > > >
> > > > > > > >
> > > > > > > > Comments?
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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]
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > > >
> > > > > > --
> > > > > > 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]
> > > Content-Description: Card for Jeff Copley
> > > > begin:vcard
> > > > n:Copley;Jeff
> > > > tel;work:972.519.3758
> > > > x-mozilla-html:FALSE
> > > > org:Alcatel USA, Inc.
> > > > version:2.1
> > > > email;internet:[email-masked]
> > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > NSGAP;Plano;Texas;75075-5813;USA
> > > > x-mozilla-cpt:;20864
> > > > fn:Jeff Copley
> > > > end:vcard
> > > >
> > > >
> > > >
> > >
> > > Content-Description: footer
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
> > [email-masked]
> > >
> > > --
> > > 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]

-- 
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]
To: "sigtran" <[email-masked]>
Date: Mon, 30 Jul 2001 15:46:52 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: M3UA07: Network Appearance
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ouch, you're right, this goes back to January (when the emails were still
being properly archived).  You can track the email from Norm at
http://standards.nortelnetworks.com.

Cheers,

Lyndon 
--

On Mon, 30 Jul 2001 18:14:31   Greg Sidebottom wrote:
>Greetings,
>
>Wow - what a thread to read!  For background information, the change in the
>Network Appearance definition originally came in as proposal from Norm
>Glaude and the rationale was provided in a thread that started in
>December/January.   (Allow me as Editor to release a little frustration -
>Where the hell was everybody then! - HA!, now I feel a little better!)
>
>Anyway, I believe it was mostly to align the SUA and M3UA NA definitions
but
>there were some other reasons provided.  I haven't seen Norm on the list
>recently - I hope he can be prodded to participate in this thread as this
>change was quite important to him in discussions in San Diego and
>Minneapolis.
>
>Cheers,
>
>  Greg
>
>
>----- Original Message -----
>From: "Schantz, John" <[email-masked]>
>To: "sigtran" <[email-masked]>
>Sent: Monday, July 30, 2001 5:48 PM
>Subject: RE: M3UA07: Network Appearance
>
>
>> YES, I totally agree.  It is not something that is assigned per point
code
>> as the new definition for network appearance states.
>>
>> John
>>
>> -----Original Message-----
>> From: Dan Brendes [mailto:[email-masked]]
>> Sent: Monday, July 30, 2001 4:39 PM
>> To: sigtran
>> Subject: Re: M3UA07: Network Appearance
>>
>>
>>
>>
>> I was under the impression that the purpose of the network appearance was
>to
>> be
>> able to differentiate a point code in some network (such as an ITUN point
>> code
>> of 100 in an Italian national network) from some other instance of that
>> point
>> code in a different network.  By including the network appearance as
>> optional
>> parameters in Data and DUNA/DAVA/etc messages it provides a way to
>> distinguish
>> the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
>> all it
>> is.  Nothing more.
>>
>> The network appearance is a locally administered value at the SG that
must
>> be
>> shared with the ASP(s) only for those situations where the SG is
connected
>> to
>> multiple networks.
>>
>>
>>
>>
>>
>>
>> Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
>>
>> Please respond to [email-masked]
>>
>> To:   "sigtran" <[email-masked]>
>> cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
>> Subject:  Re: M3UA07: Network Appearance
>>
>>
>>
>>
>> Brian,
>>
>> I see an SG as receiving many SS7 links from the network and packaging
>> the SS7 user for delivery into the IP network.  I really don't care what
>> type of links they are as it shouldn't matter.
>>
>> A SG receives an SS7 message and relays it to some node in the IP
>> network.
>>
>> Jeff
>>
>> "Brian F. G. Bidulock" wrote:
>> >
>> > Jeff,
>> >
>> > If the SG is connected to the network with A-links, E-links or
>> > F-links, you cannot look at it as an STP.  Restricting M3UA to
>> > an STP model would rule out many non-quasi-associated (F-link
>> > connected) networks in places such as Europe.
>> >
>> > --Brian
>> >
>> > Jeff Copley wrote:                           (Mon, 30 Jul 2001
14:59:22)
>> > > Klaus,
>> > >
>> > > I agree with you that the discussions are getting increasingly
>> > > confusing.  This multiple networks business is getting increasingly
>> > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
>> > > connects to multiple networks with no problems, so this must not be
>the
>> > > problem trying to be solved.
>> > >
>> > > Given the above thought, I go to the next thought which is that
>perhaps
>> > > an attempt is being made to make the SG(STP) appear as if it belongs
>to
>> > > different networks rather than just one.  In such a case, the SG(STP)
>> > > would need to have a multiple unique point code for identifying
>itself,
>> > > one for each network that it belongs to.  In such a case, if I'm
>> > > forwarding a message to some other element such as an ASP, then I
>would
>> > > need something like an NA to represent each SS7 network to the ASPs.
>> > > Doing this though would be a pain in the .... thought processs.
>> > >
>> > > Jeff
>> > >
>> > >
>> > > "Gradischnig, Klaus" wrote:
>> > > >
>> > > > All:
>> > > >
>> > > > I am getting increasingly confused by this discussion on NA.
>However,
>> just
>> > > > looking at its definition in M3UA08 alone would be enough to do the
>> job:
>> > > >
>> > > > "Network Appearance - The Network Appearance uniquely identifies an
>> SS7
>> > > > entity (Point Code) into an SS7 network, as presented by the SG.
It
>> is
>> > > > used for the purposes of logically separating the signalling
traffic
>> > > > between the SG and the Application Server Processes over a common
>SCTP
>> > > > association.  This partitioning is necessary where an SG is
>logically
>> > > > partitioned to appear as end node elements in multiple separate SS7
>> > > >                                               ^^^^^^^^^^^^^^^^^^^^^
>> > > > networks, in which case there is a separate network appearance for
>> each
>> > > > ^^^^^^^^
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > point code in the SS7 networks.  It is also necessary when an SG is
>> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > [KDG] This clearly says to me that I need an NA if and only if I
>have
>> > > > multiple networks. In this case I need an NA for every point code,
>> however.
>> > > > Why I would need this in the case of multiple networks only beats
>me.
>> [KDG]
>> > > >
>> > > > configured as an STP hosting multiple point codes, or when
>configured
>> > > > as multiple end nodes within the same network, in which case each
>> point
>> > > > code is a separate network appearance.between the SG and the
>> > > > Application Server Processes over a common SCTP Association.  An
>> > > > example is where an SG is logically partitioned to appear as an
>> element
>> > > > in four separate national SS7 networks.  A Network Appearance
>> > > >                                          ^^^^^^^^^^^^^^^^^^^^
>> > > > implicitly defines the SS7 Point Code(s), Network Indicator and
MTP3
>> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > protocol type/variant/version used within a separate SS7 network.
>> > > >
>> > > > [KDG] In contrast, this last sentence now tells me that I need one
>and
>> only
>> > > > one
>> > > > NA for each network. This is at least something I understand and it
>> > > > corresponds
>> > > > to NA's original definition. [KDG]"
>> > > >
>> > > > And while I can see where Brian's example below is coming from, I
>> can't
>> > > > except his arguments:
>> > > > In the general case OPC specific screening cannot be handled by MTP
>> > > > network/route management functions and therefore OPC specific
>routing
>> cannot
>> > > > be supported without restrictions to either connectivity or network
>> > > > management functionality. The example might start making sense if
>the
>> SG
>> > > > considered 5.255.3 and 5.255.4 to belong to "separate" networks
>using
>> > > > different routing tables in the SG. In this case the SG may have to
>> have
>> > > > distinct point codes in these "separate" networks, provided then
>> "separate"
>> > > > networks are actually interconnected (seems not to be the case in
>this
>> > > > example, though).
>> > > > In any case, I fully support John's and Barry's view that NA
>> identifies a
>> > > > network (albeit from an SG internal view) and not an SPMC.
>> > > >
>> > > > I am -- on an abstract level -- rather concerned about the
>unnecessary
>> > > > complexity which has been introduced into m3ua and I have some
>> indication
>> > > > that a number of operators and manufacturers share this view. How
>much
>> of
>> > > > m3ua's functionality has actually been tested in Sophia? It seems
to
>> me
>> that
>> > > > without some extensive testing in a real or emulated SS7 network
>> environment
>> > > > going for last call is premature.
>> > > >
>> > > > Klaus
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > Sent: July 30, 2001 1:09 PM
>> > > > > To: sigtran
>> > > > > Subject: Re: M3UA07: Network Appearance
>> > > > >
>> > > > >
>> > > > > John,
>> > > > >
>> > > > > Please see response inline...
>> > > > >
>> > > > > John Schantz wrote:                               (Mon, 30
>> > > > > Jul 2001 09:24:56)
>> > > > > > Brian,
>> > > > > >
>> > > > > >     NO, see response to "M3UA: Routing Context".  Only a
>> > > > > single network
>> > > > > > appearance is needed per network connection.
>> > > > > >
>> > > > > >     More comments below.
>> > > > > >
>> > > > > > John
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > > Sent: Saturday, July 28, 2001 8:08 AM
>> > > > > > To: sigtran
>> > > > > > Subject: Re: M3UA07: Network Appearance
>> > > > > >
>> > > > > >
>> > > > > > John,
>> > > > > >
>> > > > > > Perhaps now you can see (from our discussion on the thread
>"M3UA:
>> > > > > > Routing Context") that to cover all configurations, a
>> > > > > Network Appearance
>> > > > > > valud is required per primary point code and network id,
>> > > > > and that this
>> > > > > > proposal was a natural extension of that fact.  Consider
>> > > > > the case below:
>> > > > > >
>> > > > > > [John] NO.
>> > > > > >
>> > > > >
>> > > > >
>> > > > >                            200.1.4    __________
>> > > > >                              ___     /          \     ___
>> > > > >                             /   \   |            |   /   \
>> > > > >                            | SEP |__|____________|__| SEP |  AS1
>> > > > >                             \___/   |            |   \___/
>> > > > >                            //       |            |
>> > > > >                           / |       | Signalling |  5.255.3
>> > > > >                          / /        |   Gateway  |
>> > > > >                         /  |        |            |
>> > > > >                        /  /         |            |
>> > > > >                _____  /   |         |            |
>> > > > >               |     |/   /          |            |
>> > > > >          -----| STP |____|__________|______      |
>> > > > >              /|_____|   /           |      \___  |  5.255.4
>> > > > >             /    |      |           |          \_|_   ___
>> > > > >          \ /     |     /            |            | \ /   \
>> > > > >           X      |     |            |            |  | SEP |  AS2
>> > > > >          / \     |    /             |           _|_/ \___/
>> > > > >             \  __|__ /              |       ___/ |
>> > > > >              \|     |_______________|______/     |       5.255.5
>> > > > >          -----| STP |               |            |       (alias)
>> > > > >               |_____|               |            |
>> > > > >                                     |            |
>> > > > >                                      \__________/
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > The signalling gateway needs two different Network Appearance
>> > > > > > parameters: one per SPMC.  The bottom SPMC needs only one
>Network
>> > > > > > Appearance to cover both the primary point code 5.255.4 and
>> > > > > the alias
>> > > > > > point code 5.255.5 because they are both treated as the
>> > > > > same from an SS7
>> > > > > > newtork management view.
>> > > > > >
>> > > > > > [John]  NO.  Since a SINGLE network connection is in the
>> > > > > figure above, NO
>> > > > > > network appearance is needed at all.  What do you think the
>> > > > > point code is
>> > > > > > for??????  You seem to proposing that the network
>> > > > > appearance replace the
>> > > > > > point code for routing, NO.
>> > > > >
>> > > > > John, say I have one ASP serving two ASs and each AS serves
>> > > > > and entire SEP in
>> > > > > the diagram as labelled.  They are served over 1 association
>> > > > > to an ASP which
>> > > > > is configured and active for both ASs.  When the F-link fails
>> > > > > from the SG to
>> > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
>> > > > > Without something
>> > > > > (Routing Context/Network Appearance) to distinguish the DUNA,
>> > > > > AS2 will also
>> > > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
>> > > > > 200.1.4 via
>> > > > > the STPs.
>> > > > >
>> > > > > If the SG does not send DUNA(200.1.4) but attempts to route
>> > > > > traffic from AS1
>> > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
>> > > > > may throw these
>> > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
>> > > > > only point codes
>> > > > > allowed in the OPC on messages on the A-links.
>> > > > >
>> > > > > So, again, there are two choices:  Make Network Appearance an
>> > > > > identifier
>> > > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
>> servers
>> > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
>> > > > >
>> > > > > >
>> > > > > > Now, in general, a rational basis for assigning Network
>> > > > > Apearance Id's
>> > > > > > is to use the Network Id and Point Code of the node (the
>> > > > > node *is* the
>> > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
>> > > > > the SG sends
>> > > > > > concerning the SPMC will be properly distinguish.
>> > > > > >
>> > > > > > [John]  NO.  A single network appearance (== network ID) +
>> > > > > affected point
>> > > > > > code is all that is needed.
>> > > > > >
>> > > > > > Note that if the proposed assignment of Network Appearances is
>> used,
>> > > > > > the SCON message no longer requires a Concerned Point Code
>> parameter
>> > > > > > when the SPMC is signalling congestion to the SG.  It need only
>> use
>> > > > > > the Network Appearance.
>> > > > > >
>> > > > > > [John] NO.
>> > > > > >
>> > > > > > The definition of a Network Appearance becomes
>> > > > > (effectively): "An unique
>> > > > > > identifier indicating the Signalling Point Management
>> > > > > Cluster (SPMC) to
>> > > > > > which Signalling Network Management Messages apply."
>> > > > > >
>> > > > > > [John]  NO.
>> > > > > >
>> > > > > > --Brian
>> > > > > >
>> > > > > >
>> > > > > > Schantz, John wrote:                         (Mon, 23 Jul
>> > > > > 2001 13:37:00)
>> > > > > > > Brian,
>> > > > > > >
>> > > > > > >   Why the need to include a concerned PC at all, the PC would
>be
>> > > > > > > redundant to the one in the DPC.  Why not let the network
>> > > > > appearance
>> > > > > > > parameter be equal to the Network ID (all 32 bits).  Then
>> Network
>> > > > > > > Appearance(Network ID) + DPC will be unique and it will
>> > > > > separate out the
>> > > > > > > traffic into networks in both directions SG->AS and
>> > > > > AS->SG(-> and beyond).
>> > > > > > >
>> > > > > > > John
>> > > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > > > Sent: Monday, July 23, 2001 6:41 AM
>> > > > > > > To: sigtran
>> > > > > > > Cc: Greg Sidebottom
>> > > > > > > Subject: M3UA07: Network Appearance
>> > > > > > >
>> > > > > > >
>> > > > > > > Greg,
>> > > > > > >
>> > > > > > > When an SG is has multiple point codes serving ASPs which are
>> > > > > > > active in multiple SPMCs, it becomes necessary to label each
>> > > > > > > SPMC with a unique Network Appearance parameter to
demultiplex
>> > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
>> Appearance
>> > > > > > > assignment is necessary for each SPMC and the adminstration
of
>> > > > > > > these assignments could get quite tedious for an SGP/ASP pool
>> > > > > > > representing a large number of point codes, I would like to
>> > > > > > > propose the following refinement to the Network Appearance
>> > > > > > > Parameter:
>> > > > > > >
>> > > > > > > (This is in fitting with the definition that a "Network
>> Appearance
>> > > > > > uniquely
>> > > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
>> > > > > > >
>> > > > > > > The format of the Network Appearance 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
>> > > > > > >
>> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > > >    |  Network Id   |            Concerned Point Code
>> > > > >          |
>> > > > > > >
>> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > > >
>> > > > > > > Network Identifier: 8-bit (unsigned integer)
>> > > > > > >
>> > > > > > >    The Network Identifier identifies the network in which
>> > > > > the Concerned
>> > > > > > >    Point Code can be considered unique, and distinguishes
>> > > > > this Concerned
>> > > > > > >    Point Code from an identical point code in any another
>> network.
>> > > > > > >    A Network Identifier identifying a specific
>> > > > > adminsitrative domain for
>> > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
>> > > > > global to all
>> > > > > > >    SGPs in an SG.
>> > > > > > >
>> > > > > > > Concerned Point Code:
>> > > > > > >
>> > > > > > >    The Concerned Point Code identifies a point code within
the
>> > > > > > >    administrative domain as indicated by the Network
>> > > > > Identifier.  The
>> > > > > > >    Concerned Point Code is the one point code of a
>> > > > > Signalling Point
>> > > > > > >    Management Cluster (SPMC) which needs to receive
>> > > > > updates concerning
>> > > > > > >    the accessibility/restriction/congestion status of
>> > > > > routesets from the
>> > > > > > >    SPMC.
>> > > > > > >
>> > > > > > >
>> > > > > > > Comments?
>> > > > > > >
>> > > > > > > --
>> > > > > > > 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]
>> > > > > >
>> > > > > > --
>> > > > > > 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]
>> > > > >
>> > > > > --
>> > > > > 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]
>> > Content-Description: Card for Jeff Copley
>> > > begin:vcard
>> > > n:Copley;Jeff
>> > > tel;work:972.519.3758
>> > > x-mozilla-html:FALSE
>> > > org:Alcatel USA, Inc.
>> > > version:2.1
>> > > email;internet:[email-masked]
>> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
>> NSGAP;Plano;Texas;75075-5813;USA
>> > > x-mozilla-cpt:;20864
>> > > fn:Jeff Copley
>> > > end:vcard
>> > >
>> > >
>> > >
>> >
>> > Content-Description: footer
>> > > ---
>> > > You are currently subscribed to sigtran as: [email-masked]
>> > > To unsubscribe send a blank email to
>> [email-masked]
>> >
>> > --
>> > 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 15:55:32 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

But this doesn't make it right.  John

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]] Sent: Monday, July 30,
2001 5:47 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Ouch, you're right, this goes back to January (when the emails were still
being properly archived).  You can track the email from Norm at
http://standards.nortelnetworks.com.

Cheers,

Lyndon 
--

On Mon, 30 Jul 2001 18:14:31   Greg Sidebottom wrote:
>Greetings,
>
>Wow - what a thread to read!  For background information, the change in the
>Network Appearance definition originally came in as proposal from Norm
>Glaude and the rationale was provided in a thread that started in
>December/January.   (Allow me as Editor to release a little frustration -
>Where the hell was everybody then! - HA!, now I feel a little better!)
>
>Anyway, I believe it was mostly to align the SUA and M3UA NA definitions
but
>there were some other reasons provided.  I haven't seen Norm on the list
>recently - I hope he can be prodded to participate in this thread as this
>change was quite important to him in discussions in San Diego and
>Minneapolis.
>
>Cheers,
>
>  Greg
>
>
>----- Original Message -----
>From: "Schantz, John" <[email-masked]>
>To: "sigtran" <[email-masked]>
>Sent: Monday, July 30, 2001 5:48 PM
>Subject: RE: M3UA07: Network Appearance
>
>
>> YES, I totally agree.  It is not something that is assigned per point
code
>> as the new definition for network appearance states.
>>
>> John
>>
>> -----Original Message-----
>> From: Dan Brendes [mailto:[email-masked]]
>> Sent: Monday, July 30, 2001 4:39 PM
>> To: sigtran
>> Subject: Re: M3UA07: Network Appearance
>>
>>
>>
>>
>> I was under the impression that the purpose of the network appearance was
>to
>> be
>> able to differentiate a point code in some network (such as an ITUN point
>> code
>> of 100 in an Italian national network) from some other instance of that
>> point
>> code in a different network.  By including the network appearance as
>> optional
>> parameters in Data and DUNA/DAVA/etc messages it provides a way to
>> distinguish
>> the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
>> all it
>> is.  Nothing more.
>>
>> The network appearance is a locally administered value at the SG that
must
>> be
>> shared with the ASP(s) only for those situations where the SG is
connected
>> to
>> multiple networks.
>>
>>
>>
>>
>>
>>
>> Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
>>
>> Please respond to [email-masked]
>>
>> To:   "sigtran" <[email-masked]>
>> cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
>> Subject:  Re: M3UA07: Network Appearance
>>
>>
>>
>>
>> Brian,
>>
>> I see an SG as receiving many SS7 links from the network and packaging
>> the SS7 user for delivery into the IP network.  I really don't care what
>> type of links they are as it shouldn't matter.
>>
>> A SG receives an SS7 message and relays it to some node in the IP
>> network.
>>
>> Jeff
>>
>> "Brian F. G. Bidulock" wrote:
>> >
>> > Jeff,
>> >
>> > If the SG is connected to the network with A-links, E-links or
>> > F-links, you cannot look at it as an STP.  Restricting M3UA to
>> > an STP model would rule out many non-quasi-associated (F-link
>> > connected) networks in places such as Europe.
>> >
>> > --Brian
>> >
>> > Jeff Copley wrote:                           (Mon, 30 Jul 2001
14:59:22)
>> > > Klaus,
>> > >
>> > > I agree with you that the discussions are getting increasingly
>> > > confusing.  This multiple networks business is getting increasingly
>> > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
>> > > connects to multiple networks with no problems, so this must not be
>the
>> > > problem trying to be solved.
>> > >
>> > > Given the above thought, I go to the next thought which is that
>perhaps
>> > > an attempt is being made to make the SG(STP) appear as if it belongs
>to
>> > > different networks rather than just one.  In such a case, the SG(STP)
>> > > would need to have a multiple unique point code for identifying
>itself,
>> > > one for each network that it belongs to.  In such a case, if I'm
>> > > forwarding a message to some other element such as an ASP, then I
>would
>> > > need something like an NA to represent each SS7 network to the ASPs.
>> > > Doing this though would be a pain in the .... thought processs.
>> > >
>> > > Jeff
>> > >
>> > >
>> > > "Gradischnig, Klaus" wrote:
>> > > >
>> > > > All:
>> > > >
>> > > > I am getting increasingly confused by this discussion on NA.
>However,
>> just
>> > > > looking at its definition in M3UA08 alone would be enough to do the
>> job:
>> > > >
>> > > > "Network Appearance - The Network Appearance uniquely identifies an
>> SS7
>> > > > entity (Point Code) into an SS7 network, as presented by the SG.
It
>> is
>> > > > used for the purposes of logically separating the signalling
traffic
>> > > > between the SG and the Application Server Processes over a common
>SCTP
>> > > > association.  This partitioning is necessary where an SG is
>logically
>> > > > partitioned to appear as end node elements in multiple separate SS7
>> > > >                                               ^^^^^^^^^^^^^^^^^^^^^
>> > > > networks, in which case there is a separate network appearance for
>> each
>> > > > ^^^^^^^^
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > point code in the SS7 networks.  It is also necessary when an SG is
>> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > [KDG] This clearly says to me that I need an NA if and only if I
>have
>> > > > multiple networks. In this case I need an NA for every point code,
>> however.
>> > > > Why I would need this in the case of multiple networks only beats
>me.
>> [KDG]
>> > > >
>> > > > configured as an STP hosting multiple point codes, or when
>configured
>> > > > as multiple end nodes within the same network, in which case each
>> point
>> > > > code is a separate network appearance.between the SG and the
>> > > > Application Server Processes over a common SCTP Association.  An
>> > > > example is where an SG is logically partitioned to appear as an
>> element
>> > > > in four separate national SS7 networks.  A Network Appearance
>> > > >                                          ^^^^^^^^^^^^^^^^^^^^
>> > > > implicitly defines the SS7 Point Code(s), Network Indicator and
MTP3
>> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > > protocol type/variant/version used within a separate SS7 network.
>> > > >
>> > > > [KDG] In contrast, this last sentence now tells me that I need one
>and
>> only
>> > > > one
>> > > > NA for each network. This is at least something I understand and it
>> > > > corresponds
>> > > > to NA's original definition. [KDG]"
>> > > >
>> > > > And while I can see where Brian's example below is coming from, I
>> can't
>> > > > except his arguments:
>> > > > In the general case OPC specific screening cannot be handled by MTP
>> > > > network/route management functions and therefore OPC specific
>routing
>> cannot
>> > > > be supported without restrictions to either connectivity or network
>> > > > management functionality. The example might start making sense if
>the
>> SG
>> > > > considered 5.255.3 and 5.255.4 to belong to "separate" networks
>using
>> > > > different routing tables in the SG. In this case the SG may have to
>> have
>> > > > distinct point codes in these "separate" networks, provided then
>> "separate"
>> > > > networks are actually interconnected (seems not to be the case in
>this
>> > > > example, though).
>> > > > In any case, I fully support John's and Barry's view that NA
>> identifies a
>> > > > network (albeit from an SG internal view) and not an SPMC.
>> > > >
>> > > > I am -- on an abstract level -- rather concerned about the
>unnecessary
>> > > > complexity which has been introduced into m3ua and I have some
>> indication
>> > > > that a number of operators and manufacturers share this view. How
>much
>> of
>> > > > m3ua's functionality has actually been tested in Sophia? It seems
to
>> me
>> that
>> > > > without some extensive testing in a real or emulated SS7 network
>> environment
>> > > > going for last call is premature.
>> > > >
>> > > > Klaus
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > Sent: July 30, 2001 1:09 PM
>> > > > > To: sigtran
>> > > > > Subject: Re: M3UA07: Network Appearance
>> > > > >
>> > > > >
>> > > > > John,
>> > > > >
>> > > > > Please see response inline...
>> > > > >
>> > > > > John Schantz wrote:                               (Mon, 30
>> > > > > Jul 2001 09:24:56)
>> > > > > > Brian,
>> > > > > >
>> > > > > >     NO, see response to "M3UA: Routing Context".  Only a
>> > > > > single network
>> > > > > > appearance is needed per network connection.
>> > > > > >
>> > > > > >     More comments below.
>> > > > > >
>> > > > > > John
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > > Sent: Saturday, July 28, 2001 8:08 AM
>> > > > > > To: sigtran
>> > > > > > Subject: Re: M3UA07: Network Appearance
>> > > > > >
>> > > > > >
>> > > > > > John,
>> > > > > >
>> > > > > > Perhaps now you can see (from our discussion on the thread
>"M3UA:
>> > > > > > Routing Context") that to cover all configurations, a
>> > > > > Network Appearance
>> > > > > > valud is required per primary point code and network id,
>> > > > > and that this
>> > > > > > proposal was a natural extension of that fact.  Consider
>> > > > > the case below:
>> > > > > >
>> > > > > > [John] NO.
>> > > > > >
>> > > > >
>> > > > >
>> > > > >                            200.1.4    __________
>> > > > >                              ___     /          \     ___
>> > > > >                             /   \   |            |   /   \
>> > > > >                            | SEP |__|____________|__| SEP |  AS1
>> > > > >                             \___/   |            |   \___/
>> > > > >                            //       |            |
>> > > > >                           / |       | Signalling |  5.255.3
>> > > > >                          / /        |   Gateway  |
>> > > > >                         /  |        |            |
>> > > > >                        /  /         |            |
>> > > > >                _____  /   |         |            |
>> > > > >               |     |/   /          |            |
>> > > > >          -----| STP |____|__________|______      |
>> > > > >              /|_____|   /           |      \___  |  5.255.4
>> > > > >             /    |      |           |          \_|_   ___
>> > > > >          \ /     |     /            |            | \ /   \
>> > > > >           X      |     |            |            |  | SEP |  AS2
>> > > > >          / \     |    /             |           _|_/ \___/
>> > > > >             \  __|__ /              |       ___/ |
>> > > > >              \|     |_______________|______/     |       5.255.5
>> > > > >          -----| STP |               |            |       (alias)
>> > > > >               |_____|               |            |
>> > > > >                                     |            |
>> > > > >                                      \__________/
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > The signalling gateway needs two different Network Appearance
>> > > > > > parameters: one per SPMC.  The bottom SPMC needs only one
>Network
>> > > > > > Appearance to cover both the primary point code 5.255.4 and
>> > > > > the alias
>> > > > > > point code 5.255.5 because they are both treated as the
>> > > > > same from an SS7
>> > > > > > newtork management view.
>> > > > > >
>> > > > > > [John]  NO.  Since a SINGLE network connection is in the
>> > > > > figure above, NO
>> > > > > > network appearance is needed at all.  What do you think the
>> > > > > point code is
>> > > > > > for??????  You seem to proposing that the network
>> > > > > appearance replace the
>> > > > > > point code for routing, NO.
>> > > > >
>> > > > > John, say I have one ASP serving two ASs and each AS serves
>> > > > > and entire SEP in
>> > > > > the diagram as labelled.  They are served over 1 association
>> > > > > to an ASP which
>> > > > > is configured and active for both ASs.  When the F-link fails
>> > > > > from the SG to
>> > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
>> > > > > Without something
>> > > > > (Routing Context/Network Appearance) to distinguish the DUNA,
>> > > > > AS2 will also
>> > > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
>> > > > > 200.1.4 via
>> > > > > the STPs.
>> > > > >
>> > > > > If the SG does not send DUNA(200.1.4) but attempts to route
>> > > > > traffic from AS1
>> > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
>> > > > > may throw these
>> > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
>> > > > > only point codes
>> > > > > allowed in the OPC on messages on the A-links.
>> > > > >
>> > > > > So, again, there are two choices:  Make Network Appearance an
>> > > > > identifier
>> > > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
>> servers
>> > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
>> > > > >
>> > > > > >
>> > > > > > Now, in general, a rational basis for assigning Network
>> > > > > Apearance Id's
>> > > > > > is to use the Network Id and Point Code of the node (the
>> > > > > node *is* the
>> > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
>> > > > > the SG sends
>> > > > > > concerning the SPMC will be properly distinguish.
>> > > > > >
>> > > > > > [John]  NO.  A single network appearance (== network ID) +
>> > > > > affected point
>> > > > > > code is all that is needed.
>> > > > > >
>> > > > > > Note that if the proposed assignment of Network Appearances is
>> used,
>> > > > > > the SCON message no longer requires a Concerned Point Code
>> parameter
>> > > > > > when the SPMC is signalling congestion to the SG.  It need only
>> use
>> > > > > > the Network Appearance.
>> > > > > >
>> > > > > > [John] NO.
>> > > > > >
>> > > > > > The definition of a Network Appearance becomes
>> > > > > (effectively): "An unique
>> > > > > > identifier indicating the Signalling Point Management
>> > > > > Cluster (SPMC) to
>> > > > > > which Signalling Network Management Messages apply."
>> > > > > >
>> > > > > > [John]  NO.
>> > > > > >
>> > > > > > --Brian
>> > > > > >
>> > > > > >
>> > > > > > Schantz, John wrote:                         (Mon, 23 Jul
>> > > > > 2001 13:37:00)
>> > > > > > > Brian,
>> > > > > > >
>> > > > > > >   Why the need to include a concerned PC at all, the PC would
>be
>> > > > > > > redundant to the one in the DPC.  Why not let the network
>> > > > > appearance
>> > > > > > > parameter be equal to the Network ID (all 32 bits).  Then
>> Network
>> > > > > > > Appearance(Network ID) + DPC will be unique and it will
>> > > > > separate out the
>> > > > > > > traffic into networks in both directions SG->AS and
>> > > > > AS->SG(-> and beyond).
>> > > > > > >
>> > > > > > > John
>> > > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > > > > > > Sent: Monday, July 23, 2001 6:41 AM
>> > > > > > > To: sigtran
>> > > > > > > Cc: Greg Sidebottom
>> > > > > > > Subject: M3UA07: Network Appearance
>> > > > > > >
>> > > > > > >
>> > > > > > > Greg,
>> > > > > > >
>> > > > > > > When an SG is has multiple point codes serving ASPs which are
>> > > > > > > active in multiple SPMCs, it becomes necessary to label each
>> > > > > > > SPMC with a unique Network Appearance parameter to
demultiplex
>> > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
>> Appearance
>> > > > > > > assignment is necessary for each SPMC and the adminstration
of
>> > > > > > > these assignments could get quite tedious for an SGP/ASP pool
>> > > > > > > representing a large number of point codes, I would like to
>> > > > > > > propose the following refinement to the Network Appearance
>> > > > > > > Parameter:
>> > > > > > >
>> > > > > > > (This is in fitting with the definition that a "Network
>> Appearance
>> > > > > > uniquely
>> > > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
>> > > > > > >
>> > > > > > > The format of the Network Appearance 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
>> > > > > > >
>> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > > >    |  Network Id   |            Concerned Point Code
>> > > > >          |
>> > > > > > >
>> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > > > > > >
>> > > > > > > Network Identifier: 8-bit (unsigned integer)
>> > > > > > >
>> > > > > > >    The Network Identifier identifies the network in which
>> > > > > the Concerned
>> > > > > > >    Point Code can be considered unique, and distinguishes
>> > > > > this Concerned
>> > > > > > >    Point Code from an identical point code in any another
>> network.
>> > > > > > >    A Network Identifier identifying a specific
>> > > > > adminsitrative domain for
>> > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
>> > > > > global to all
>> > > > > > >    SGPs in an SG.
>> > > > > > >
>> > > > > > > Concerned Point Code:
>> > > > > > >
>> > > > > > >    The Concerned Point Code identifies a point code within
the
>> > > > > > >    administrative domain as indicated by the Network
>> > > > > Identifier.  The
>> > > > > > >    Concerned Point Code is the one point code of a
>> > > > > Signalling Point
>> > > > > > >    Management Cluster (SPMC) which needs to receive
>> > > > > updates concerning
>> > > > > > >    the accessibility/restriction/congestion status of
>> > > > > routesets from the
>> > > > > > >    SPMC.
>> > > > > > >
>> > > > > > >
>> > > > > > > Comments?
>> > > > > > >
>> > > > > > > --
>> > > > > > > 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]
>> > > > > >
>> > > > > > --
>> > > > > > 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]
>> > > > >
>> > > > > --
>> > > > > 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]
>> > Content-Description: Card for Jeff Copley
>> > > begin:vcard
>> > > n:Copley;Jeff
>> > > tel;work:972.519.3758
>> > > x-mozilla-html:FALSE
>> > > org:Alcatel USA, Inc.
>> > > version:2.1
>> > > email;internet:[email-masked]
>> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
>> NSGAP;Plano;Texas;75075-5813;USA
>> > > x-mozilla-cpt:;20864
>> > > fn:Jeff Copley
>> > > end:vcard
>> > >
>> > >
>> > >
>> >
>> > Content-Description: footer
>> > > ---
>> > > You are currently subscribed to sigtran as: [email-masked]
>> > > To unsubscribe send a blank email to
>> [email-masked]
>> >
>> > --
>> > 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Mon, 30 Jul 2001 22:20:13 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: femail25.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail25.sdc1.sfba.home.com [24.254.60.15]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery ..

Well, philosophically speaking, saying that RK parameters "should in general
not include any upper layer's parameters" and then supporting CIC for M3UA
as an exception, makes the whole statement meaningless to me  2;^)   Why is
CIC an exception and SSN is not?

As for TCAP TRID for an SUA RK I fear to tread here because I haven't been
following the SUA developments in SUA as I should.  But I currently don't
see why you couldn't allow Application Servers to divide up the TRID space.
There might be some application for that, but if not I won't cry if SUA
doesn't have it.  SGs don't have to have this in the REG/DEREG procedures if
they want to try it - these are optional procedures so there's really
nothing stopping an SG from trying out any kind of RK they can dream up.
IMHO RKs aren't restricted by what can or can't be populated in a REG
message.

Cheers,

   Greg

----- Original Message -----
From: "Verwimp Gery" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 30, 2001 11:43 AM
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.

Hi Greg,

I second that. Using TCAP transaction ID in SUA wouldn't be wise either.
With the exception of the CIC, RK parameters should in general not include
any of the upper layer's parameters (SSN, GT for M3UA; TID etc. for SUA).

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: maandag 30
juli 2001 17:17
To: sigtran
Cc: Greg Sidebottom
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

--
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 ¦

---
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 00:47:44 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: femail45.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.254.60.39]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Responses below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "Greg Sidebottom" <[email-masked]>
Sent: Monday, July 30, 2001 11:17 AM
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

[Greg] I'll try and remember but this is from a while ago.  I think there
are valid cases where an MGC supports both ISUP and TCAP (lets say for CCBS
or the CLASS equivalent service).  While I'd agree that SUA is probably a
better choice for the SCCP/TCAP traffic, the SG needs M3UA for the ISUP
traffic already and it seems a lot of overhead to also support SUA and
another SCTP association just for the TCAP traffic.  So a RK could be used
to direct SCCP traffic for this service to an active MGC.  I assume that
SCCP management is not perfect but it is probably not used completely anyway
for these end-node to end-node services because SCCP management will
probably not be concerned about the subsystem state of all the possible CCBS
peers (or support traffic Mix procedures or SOR/SOG for that matter).  I'm
not sure why OMAP SRVT would be an issue yet.  In any case, for the SSN RK
cases I've seen discussed, OMAP SRVT could be ignored as it wasn't used in
the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks, as far
as I've seen anyway.

Another case I have also seen is where M3UA is used from an SG to a
database, but the SG didn't support SUA yet.  So the SG makes up for this by
handling all the SCCP management on behalf of the database, at least those
parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).

But I don't really want to get into a long discussion of how these cases can
or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs from a
RK parameter in a REG REQ as I think removing it from the REG REQ doesn't
prevent anyone from trying the above applications.  There is to me a
difference between saying that the RK parameter in a REG REQ doesn't have a
certain sub-parameter and saying RKs cannot use certain information.  Any RK
you want to dream up is possible, its just that it may not be able to
configure it dynamically.  Of course not all RK permutations make sense for
a given application/architecture so people need to be careful of their
dreams.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

[Greg] There are some "tricks" that SGs can play with TRIDS for certain
applications/architectures.   TRIDS are not in the REG REQ but like I said
above I don't see this as an impediment to an SG configuring them in an RK-
they just couldn't be dynamically registered.  I think way back some people
were thinking of using the TRID ranges as a way of ensuring that the
responses get back to the right originating ASPs.  I haven't studied the SUA
recently enough to know if this is still an issue though.

I don't mind removing TRID as an example if it causes any confusion - as
long as there is no restriction on the Routing Key in the SG.  If there are
future applications to include field "xyz" in a Routing Key then I don't
think its not the role of the M3UA to say that it cannot be done.

Cheers,

   Greg

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

--
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 ¦

---
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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA: SCCP Message Priority
Date: Mon, 30 Jul 2001 14:42:02 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

What's wrong with just using the importance parameter in SUA, and derive the
ANSI SCCP Message Priority/ITU SCCP Importance value from that ? This MP
addition seems a little overkill to me.

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: maandag 23
juli 2001 21:11
To: sigtran
Cc: John Loughney
Subject: Re: SUA: SCCP Message Priority

Ray,

Doesn't look like it.  It seems that we need to add a priority bit
somewhere.  If for no other reason than to support ANSI (and other) TCAP
Conversation.  Maybe in the Flags parameter.  SLS takes up 5 bits of 8.
Importance takes up 3 of 8.  How about the top nibble of importance, such
as:

< 3.9.1  Flags
< 
<    The Flags parameter is a conglomerate of following parameters, <
described in ITU-T Recommendation Q.713 : < 
<       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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <      |
Tag = 0x0101          |             Length = 8        | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <      |
Seq. Control  | MP|Importance |  Hop Counter  |  Protocol Cl. | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <
<  Message Priority/Importance
<
<  Importance (3.19/Q.713)
<
<  Bits 1-3 are coded to indicate the importance of the messages. The <
values are between 0 and 7, where the value of 0 indicates the least <
important and 7 indicates the most important.
<
<  Bits 4-6 are spare bits and should be coded zero.
<
<  Message Priority (T1.111.4/Table B4) <
<  Bits 7-8 are coded to indicate the message priority of the message in <
networks which support mutliple congestion level with message priority.
<  The values are between 0 and 2, where the value of 0 indicates the <
lowest priority and 2 indicates the most important.

[email-masked] wrote:                          (Mon, 23 Jul 2001
14:01:56)
>
> Hi,
> 
> Could someone please clarify whether SUA would allow ANSI message priority
> values to be conveyed between peer SUA/SUA Users.
> 
> Thanks
> Ray
> 

-- 
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]
Date: Mon, 30 Jul 2001 08:24:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCCP Message Priority
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Unfortunately, Message Priority is not ANSI specific.  Therefore, it is
quite possible to have ITU Importance in SCCP with Message Priority in the
RL.

For example, although TTC JT-Q.712 deletes the Importance parameter,
shouldn't we let TTC JT-Q.712 put Importance in when TTC has a need for it?

If you want to let the SG take care of as much as possible, don't use one
field for two things: keep MP and Importance separate.

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
14:53:40)
> Hello Brian, all,
> 
> The SUA importance field in the Flags parameter is used to give an
> indication of the priority of the message. This field should be enough to
> derive:
> 
> - importance value in a.o. XUDT messages (the only indication of
> priority/importance in ITU)
> - message priority field in SIO in case of ANSI network
> - whatever else is needed in another flavour of SS7 regarding
> priority/importance
> 
> and to allow SCCP on the SG to perform appropriate action in case of
> congestion in the SS7 network.
> 
> Let the SG take care of as much of the SS7 flavours/specifics as possible
!
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 23 juli 2001 21:25
> To: sigtran
> Subject: Re: SCCP Message Priority
> 
> 
> John,
> 
> The message priorities (that go in the MTP RL for congestion
> control) associated with ANSI SCCP are set by the SCCP-User.
> TCAP, for example, will up the MP on Conversation packages from
> 0 to 1.  Some critical connection sections in the
> connection-oriented procedures will have some of the CO messages
> upped from 0 to 1.  OMAP uses 2.  Because these values come from
> the SCCP-User and are communicated down to MTP through the
> MTP-TRANSFER primitive, all messages which carry the Flags
> parameter may need to have message priorities assigned (some CO
> messages do not).  The SUA SHOULD police the setting of MP bits
> on messages which have a fixed priority (to save an application
> from setting them by mistake).  Other messages will use the
> value provided by the SCTP-User when formulating the
> MTP-TRANSFER primitive at the SG.  The MP value needs to be
> communicated from ASP to SG and visa versa.  Some times the SCCP
> needs to know the setting of MP for an incoming message to know
> the setting what setting to use for an outgoing message.
> 
> The message that is is definitely needed on is the CLDT.
> 
> John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> > Hi Ray,
> > 
> > > Could someone please clarify whether SUA would allow ANSI 
> > > message priority values to be conveyed between peer SUA/SUA 
> > > Users.
> > 
> > I'm not so familiar with ANSI SCCP (though I bet a few folks on
> > this list are).  Could you fill me in a little bit on what 
> > you need?
> > 
> > John
> > 
> 
> -- 
> 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]

-- 
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]
Date: Tue, 31 Jul 2001 00:53:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      AAA11758
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Ok.  You brought it up.  You have only yourself to blame. ;)

Routing Keys which contain CIC ranges do not make any sense either.  To
illustrate: can one load-share within the CIC range?  Can one load-share a
CIC?

Load-sharing in a Load-share AS where the load-sharing is based upon SLS
*will* loadshare over CIC ranges.  Because a CIC is inexhorably tied to an
SLS value (least significant bits of CIC), it does not make sense to
loadshare within a CIC range because the CICs within the range would be
strewn across processors.

Within ISUP, it does make sense to load-share based on CIC range.  Under
this scheme, OPC/CIC ranges would be assigned to ASPs in the load-share AS.
The AS itself, however, would only have an OPC/DPC routing key.
CIC would be used for load-sharing only.

To demonstrate that CIC ranges are really load-sharing rathing than routing
concepts, consider that each ASP with a CIC range still needs to receive
SPMC management messages for the OPCs involed and for the SPMC involved.

CIC ranges in the Routing Key just seem to be an unnatural way of setting up
a load-sharing pool, where one Routing Key (OPC/DPC/SI=ISUP) is split up
into separate individual override ASs which the ASPs are expected to manage
on a load-sharing basis.

It rather defeats the purpose of load-sharing to attempt to "route" on CIC.

Actually, the only routing keys should be DPC/SI (for SCCP) and OPC/DPC/SI
(for ISUP).  CICs should be handled by load sharing.

--Brian

Greg Sidebottom wrote:                           (Mon, 30 Jul 2001 22:20:13)
> Hi Gery ..
> 
> Well, philosophically speaking, saying that RK parameters "should in
general
> not include any upper layer's parameters" and then supporting CIC for M3UA
> as an exception, makes the whole statement meaningless to me  2;^)   Why
is
> CIC an exception and SSN is not?
> 
> As for TCAP TRID for an SUA RK I fear to tread here because I haven't been
> following the SUA developments in SUA as I should.  But I currently don't
> see why you couldn't allow Application Servers to divide up the TRID
space.
> There might be some application for that, but if not I won't cry if SUA
> doesn't have it.  SGs don't have to have this in the REG/DEREG procedures
if
> they want to try it - these are optional procedures so there's really
> nothing stopping an SG from trying out any kind of RK they can dream up.
> IMHO RKs aren't restricted by what can or can't be populated in a REG
> message.
> 
> Cheers,
> 
>    Greg
> 
> ----- Original Message -----
> From: "Verwimp Gery" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 30, 2001 11:43 AM
> Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Hi Greg,
> 
> I second that. Using TCAP transaction ID in SUA wouldn't be wise either.
> With the exception of the CIC, RK parameters should in general not include
> any of the upper layer's parameters (SSN, GT for M3UA; TID etc. for SUA).
> 
> Regards,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> >
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 30 juli 2001 17:17
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Greg,
> 
> I don't see that rational basis on which M3UA can apply routing keys
> based on SCCP Subsystem number.  Can someone provide an example on just
> how this was expected to work?  (Particularly how SCCP Management is
> handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> here.
> 
> I propose that we strike SSN from the Routing Key in the REG REQ
> message.
> 
> Also, TCAP Transaction Id is used as an example of a Routing Key,
> although there is no field for it in a REG REQ.  Distributing messages
> based on TCAP Transaction Ids doesn't strike me as rational either.
> I think you need TUA here.
> 
> I propose that we strike TCAP Transaction Id from the examples of
> Routing Keys.
> 
> --Brian
> 
> --
> 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 ¦
> 
> 
> ---
> 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]

-- 
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]
From: rudra <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: subscribe sigtran
Date: Tue, 31 Jul 2001 13:09:37 +0530
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type> <META
content='"MSHTML 4.72.3110.7"' name=GENERATOR> </HEAD>
<BODY bgColor=#ffffff>
<DIV>&nbsp;</DIV>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Bcc: 
Subject: Re: M3UA: Route-set congestion
Date: Tue, 31 Jul 2001 09:53:46 +0100
X-OriginalArrivalTime: 31 Jul 2001 08:53:46.0964 (UTC) 
                       FILETIME=[4F55E140:01C1199E]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: f76.pav2.hotmail.com [64.4.37.76]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Hi Brian, Greg

> > I should have added the following in the email (from 1.4.6 in v7):
> > "The M3UA layer is informed of local and IP network congestion by means 
>of
> > an implementation-dependent function (e.g., an implementation-dependent
> > indication from the SCTP of IP network congestion).
> >
> > At an ASP or IPSP, the M3UA layer indicates congestion to local 
>MTP3-Users
> > by means of an MTP-STATUS primitive, as per current MTP3 procedures, to
> > invoke appropriate upper layer responses."
> >
> > With respect to the above paragraph, what I am getting at, is that I 
>don't
> > think it is appropriate to indicate congestion to the MTP3-users unless 
>IP
> > network congestion is detected on both associations. Congestion on one
> > association should allow for the traffic to be redirected to the 2nd
> > association. This could also result in the traffic swinging back and 
>forth
> > between the two associations. A mechanism is therefore necessary to 
>detect
> > how many associations reported congestion within someone time-period 
>before
> > reporting congestion to the local MTP3-users.
>
>
>Ah, that is different that SCON.  I suppose it is pretty much up to the
>implementation to decide what to do with regard to SCTP congestion.
>Some determination might be able to be made in specific IP network
>configurations to determine whether SCTP congestion was due to too high
>and offered load or whether a one or more associations is just "bad".
>I would think that switching associations would only make sense in the
>case that the SCTP association was "bad".
>
>Switching traffic between SCTP associations which arrive a different
>endpoints must be done quite carefully, because of the possibility of
>mis-sequencing: i.e. the head of the traffic on the new association
>overtaking the tail on the old past the SG/SGP.  Some sort of controlled
>rerouting, changeover or other procedure could be necessary.  If an SCTP
>assocation congests, there are a good number of messages in the SCTP
>transmit buffers as well which might have to be collected to avoid
>holding traffic too long in a time-controlled procedure before starting
>again on the new association.  Such things as a successsful orderly 
>shutdown
>of the old association to clear buffers at both ends might be necessary
>before restarting traffic on the new.
>
>When these issues are considered, some implementations may very well
>choose to inform their local MTP Users of congestion even though it is
>only on one association.
>
>Just some thoughts.  M3UA states these actions as "implementation-
>dependent" because it would be very difficult to address these issues
>in all configurations, and many factors rely upon the intervening
>IP network and even the implementation architecture.
>
>Did you think that some text needed changing to clarify this?  If so,
>could you propose a paragraph?

Yes.

Here is suggested text (2 paragraphs) to replace the current 2nd paragraph
in section 1.4.6:
------------------------------------------- Due to the shared nature of the
bandwidth in an IP environment, network congestion does not necessarily
imply that the ASP is responsible for the congestion. When more than one
association is present between an ASP and SGP, as illustrated Figure 1, and
congestion is detected on only some of the associations an ASP (or IPSP) may
attempt to distribute some or all of the traffic from the congested
associations onto alternative associations where no congestion is present.
M3UA should later attempt to restore traffic on the affected associations
after congestion has abated. The congestion change-over and change-back
procedures are implementation dependant. These procedures should be
implemented in a time-controlled manner to avoid the loss of messages,
mis-sequencing of messages, excessive delays in message delivery and rapid
oscillatory change-over and change-back procedures.

If congestion is detected across all or a majority of the associations
within a fixed period of time M3UA SHOULD indicate congestion to the local
MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3
procedures, to invoke the appropriate upper layer responses.
-------------------------------------------

Greg, the heading for section 4.3 does not match the heading listed in the
contents.

Amish

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Tue, 31 Jul 2001 04:02:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      EAA14553
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Please see comments inline...

Greg Sidebottom wrote:                      (Tue, 31 Jul 2001 00:47:44)
> Hi Brian,
> 
> Responses below ...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Cc: "Greg Sidebottom" <[email-masked]>
> Sent: Monday, July 30, 2001 11:17 AM
> Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Greg,
> 
> I don't see that rational basis on which M3UA can apply routing keys
> based on SCCP Subsystem number.  Can someone provide an example on just
> how this was expected to work?  (Particularly how SCCP Management is
> handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> here.
> 
> [Greg] I'll try and remember but this is from a while ago.  I think there
> are valid cases where an MGC supports both ISUP and TCAP (lets say for
CCBS
> or the CLASS equivalent service).  While I'd agree that SUA is probably a
> better choice for the SCCP/TCAP traffic, the SG needs M3UA for the ISUP
> traffic already and it seems a lot of overhead to also support SUA and
> another SCTP association just for the TCAP traffic. ...

Several comments here:

"[I]t seems a lot of overhead to support SUA"--Actually, for this restricted
case, very minimal functionality from SUA is required (perhaps only class 0
operation), all all the ASP management functions are very close, really all
that is required is supporting different parameters in DUNA/DAVA/etc and the
CLDT message.  For class 0/1 operation SUA has no more overhead that M3UA
and there is a lot of common parts.

Quite frankly all that SUA needs to do is support two messages (XFER and
DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP without GT is
really close to "bare" MTP and SUA handles this as the trivial case.

Perhaps you are looking at things backwards:  perhasp it is SUA which should
provide the functionality of MTP (as a pass-through to the lower layer by
shunting just a teeny bit of class 0), rather than M3UA attempting to
provide the functionality of SCCP (by loading SS7 SCCP procedures into the
M3UA at the SG).  Don't place SCCP functionality into M3UA (above the MTP
user interface)--allow SUA to pass-down to MTP.
This keeps SS7 functionality in the SS7 layers and UA functionality in the
UA layers.

Nevertheless, it is not necessary to have multiple associations.  UA peers
can be multiplexed over the same association by Payload Protocol Identifier.
See the thread "Multiple UAs per Association".

The simple example of CLASS belies the fact that the normal switch has alot
more to do in the SCCP realm (LNP queries, AIN/IN dips).  These types of
transaction which the switch needs to do also require conversations, both
class 0 and 1 support, and interworking support on UDT/XUDT/LUDT,
correlation of conversations, ...

> ... So a RK could be used
> to direct SCCP traffic for this service to an active MGC.

This traffic can be routed on SI without SSN.  Unless you are considering
some type of Global Title lookup as well, the SSN will not tell you where
the subscriber data is (which AS to use).  Although splitting traffic into
ISUP and SCCP traffic makes sense, splitting SCCP traffic by SSN does not,
particularly in the case of CLASS-like services where all queries are
against a GT which reflects subscriber information.  The SSN traffic will
need to be split further (somewhere) for redundancy, so why do this?  Why
not just loadshare all SCCP traffic by SLS and perform the SCCP functions at
the ASP?  SLS (extended by CIC) is the only rational basis for loadsharing
in M3UA, anyway.

> I assume that
> SCCP management is not perfect but it is probably not used completely
anyway
> for these end-node to end-node services because SCCP management will
> probably not be concerned about the subsystem state of all the possible
CCBS
> peers (or support traffic Mix procedures or SOR/SOG for that matter).

Again, this belies the fact that these switches also have LNP dips to
perform which requires close monitoring of subsystem availability (the
status of the LNP database from the MGC).  Also, switches normally do
perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention the
requirements of an MSC).

> I'm
> not sure why OMAP SRVT would be an issue yet.  In any case, for the SSN RK
> cases I've seen discussed, OMAP SRVT could be ignored as it wasn't used in
> the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks, as
far
> as I've seen anyway.

You may have never noticed it.  An SG/MGC must be able to respond to the
message.

> 
> Another case I have also seen is where M3UA is used from an SG to a
> database, but the SG didn't support SUA yet.  So the SG makes up for this
by
> handling all the SCCP management on behalf of the database, at least those
> parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).

At the rate we are going SUA may beat M3UA to proposed standard.  It may be
the other way around: the MGC has SUA but no M3UA yet and must use the
services of SUA to provide M3UA.  As I noted, all that SUA needs to provide
M3UA service as well is a DUPU and XFER message.

> 
> But I don't really want to get into a long discussion of how these cases
can
> or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs from
a
> RK parameter in a REG REQ as I think removing it from the REG REQ doesn't
> prevent anyone from trying the above applications.  There is to me a
> difference between saying that the RK parameter in a REG REQ doesn't have
a
> certain sub-parameter and saying RKs cannot use certain information.  Any
RK
> you want to dream up is possible, its just that it may not be able to
> configure it dynamically.  Of course not all RK permutations make sense
for
> a given application/architecture so people need to be careful of their
> dreams.

I think we need to draw a line here somewhere.  Otherwise, why not try to do
MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try to do TCAP
with M3UA?  These "experiments" are deviations from the fundamental SIGTRAN
architecture--the stuff of reasearch.  For the sake of interoperability, the
architecture needs to be adhered to and functional demarcations drawn.
Otherwise an ASP implementation will never know what to expect from an SG
implementation an visa versa.

If the sake of M3UA is not interoperability between different SG and AS
implementations, why is the spec being written?  A vendor can do whatever
they want within their own architecture now anyway.

> 
> 
> 
> I propose that we strike SSN from the Routing Key in the REG REQ
> message.
> 
> Also, TCAP Transaction Id is used as an example of a Routing Key,
> although there is no field for it in a REG REQ.  Distributing messages
> based on TCAP Transaction Ids doesn't strike me as rational either.
> I think you need TUA here.
> 
> [Greg] There are some "tricks" that SGs can play with TRIDS for certain
> applications/architectures.   TRIDS are not in the REG REQ but like I said
> above I don't see this as an impediment to an SG configuring them in an
RK-
> they just couldn't be dynamically registered.  I think way back some
people
> were thinking of using the TRID ranges as a way of ensuring that the
> responses get back to the right originating ASPs.  I haven't studied the
SUA
> recently enough to know if this is still an issue though.

M3UA can provide the service TCAP requires (via SCCP) by loadsharing on SLS.
The TCAP transaction Id coming off the SS7 network has no bearing on
anything and is not even unique unless it is taken into context with the
complete SCCP Calling Part Address (including Global Title).  The
Transaction Id is local to the exchange betwen two TC-entities and does need
not even be unique by SSN.  AIN, for example, uses Global Title in the
Calling and Called Party addresses to determine the TC-entity.  This
includes Transation Type and Address.  Correlation Ids in conversations are
next to impossible to attempt to handle in this fashion.

Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA here.
If that is the approach the WG wants to take, why not smash all four drafts
together (M2UA, M3UA, SUA, TUA) and call them SS7UA?

> 
> I don't mind removing TRID as an example if it causes any confusion - as
> long as there is no restriction on the Routing Key in the SG.  If there
are
> future applications to include field "xyz" in a Routing Key then I don't
> think its not the role of the M3UA to say that it cannot be done.

I disagree.  I believe that M3UA should be constrained to the SIGTRAN
architecture and not try to skip upwards in protocol level.  I believe that
there would be more value in skipping downwards from SUA to MTP than in
skipping upwards from M3UA to SUA to TUA and on...  Again, I believe that
the line should be drawn.

I believe that the same is true for ISUP.  CIC ranges have no place in the
Routing Key.  I believe that M3UA should consider them an "extended" SLS for
loadsharing, but routing on them makes no sense.

--Brian

> 
> Cheers,
> 
>    Greg
> 
> 
> 
> 
> 
> I propose that we strike TCAP Transaction Id from the examples of
> Routing Keys.
> 
> --Brian
> 
> --
> 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 ¦
> 
> 
> ---
> 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]

-- 
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]
Date: Tue, 31 Jul 2001 04:04:45 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
List-Unsubscribe: <mailto:[email-masked]>

Amish,

I can live with that.

--Brian

Amish Chana wrote:                                          (Tue, 31 Jul
2001 09:53:46)

[snip]
> >
> >Did you think that some text needed changing to clarify this?  If so,
> >could you propose a paragraph?
> 
> Yes.
> 
> Here is suggested text (2 paragraphs) to replace the current 2nd paragraph

> in section 1.4.6:
> -------------------------------------------
> Due to the shared nature of the bandwidth in an IP environment, network 
> congestion does not necessarily imply that the ASP is responsible for the 
> congestion. When more than one association is present between an ASP and 
> SGP, as illustrated Figure 1, and congestion is detected on only some of
the 
> associations an ASP (or IPSP) may attempt to distribute some or all of the

> traffic from the congested associations onto alternative associations
where 
> no congestion is present. M3UA should later attempt to restore traffic on 
> the affected associations after congestion has abated. The congestion 
> change-over and change-back procedures are implementation dependant. These

> procedures should be implemented in a time-controlled manner to avoid the 
> loss of messages, mis-sequencing of messages, excessive delays in message 
> delivery and rapid oscillatory change-over and change-back procedures.
> 
> If congestion is detected across all or a majority of the associations 
> within a fixed period of time M3UA SHOULD indicate congestion to the local

> MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3 
> procedures, to invoke the appropriate upper layer responses.
> -------------------------------------------
> 
> Greg, the heading for section 4.3 does not match the heading listed in the

> contents.
> Amish

-- 
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]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 11:27:17 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandy,

To boot, the SSN doesn't even need to be present in class 0 or 1 messages,
when routing on Global Title is used. And coming up with RKs for GTs is
actually reinventing the existing GT translation process.

Using TIDs would only have a chance of working if both SG and AS (SGPs and
ASPs) belong to the same vendor ...

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: maandag 30
juli 2001 22:17
To: sigtran
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

Sandy,

They don't make sense.  For example, SCCP classes 2 and 3 have no SSN in
messages after the connection establishment phase.  So that means classes 2
and 3 are out.  Class 0 and 1 are connectionless and have SSN in the
message, but SCCP management messages are also sent Class 0 with SSN=0 and
needs to be sent to all concerned SCCP subsytems.  By the time your done
with this, you are doing SUA classes 0 and 1 anyways.  To get the class 2
and 3 support requires full blown SUA.

Note that SUA supports all the SNMM messages that M3UA does.  In effect, for
classes 0 and 1 they are very similar.

Unless someone can come up with a practical use for SSN routing keys in M3UA
I think that they make a bad example.

Why this late in the review process?  I commented on these before...
But in longer notes.

Transaction ID is absurd.  It makes a foolish example.

--brian

Sandy Smart wrote:                              (Mon, 30 Jul 2001 15:56:03)
> Brian,
> 
> Are you suggesting to remove these possible routing keys entirely from the
> draft or only from the dynamic registration section? They have existed in
> the routing key overview section since early in its development so I'm
> curious as to the objection late in the review process. M3UA is only using
> them to make a routing decision and wouldn't it be up to the
implementation
> of the application at the ASP to handle the issues you describe?
> 
> Sandy
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Cc: "Greg Sidebottom" <[email-masked]>
> Sent: Monday, July 30, 2001 11:17 AM
> Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Greg,
> 
> I don't see that rational basis on which M3UA can apply routing keys
> based on SCCP Subsystem number.  Can someone provide an example on just
> how this was expected to work?  (Particularly how SCCP Management is
> handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> here.
> 
> I propose that we strike SSN from the Routing Key in the REG REQ
> message.
> 
> Also, TCAP Transaction Id is used as an example of a Routing Key,
> although there is no field for it in a REG REQ.  Distributing messages
> based on TCAP Transaction Ids doesn't strike me as rational either.
> I think you need TUA here.
> 
> I propose that we strike TCAP Transaction Id from the examples of
> Routing Keys.
> 
> --Brian
> 
> --
> 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 ¦
> 
> 
> ---
> 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]

-- 
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]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Tue, 31 Jul 2001 11:41:33 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello John,

The routing context may implicitly identify the SS7 network with which
interworking actually takes place or not (e.g. when routing is on Global
Title). The limitation of an RK/RC was that it could not go beyond 1
network, at least that's my current  perception ...

When during static or dynamic (REG, DEREG) configuration RKs and their RCs
are defined, why not use these parameters instead of yet another one which
has to be understood by SG and AS ? And of which the definition is still not
clear ...

Just my 0.02$,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Schantz, John [mailto:[email-masked]] Sent: maandag 30 juli
2001 20:46
To: sigtran
Subject: RE: M3UA07: Network Appearance

Brian,

	I do not agree with your views on this.  Why are you adding
additional complexity?

	A Network Appearance (== Network ID) is more than sufficient to
uniquely discriminate the affected point codes in the DUNA/DAVA/...
Anything more is re-inventing a round wheel but with many flat sides.

	"Readily adopted by SUAv7", could it be that current real SS7 node
implementers may not have been interest and have not been paying attention.
I have not been that interested in SUA, so I have not been paying attention.

	I understand gateway screening, but who cares, it is an external
function separate from the protocol.  It does not drive the protocol.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
30, 2001 1:24 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Barry,

The only reason is because of lack of an SPMC Identifier in the DUNA/DAVA/..
messages.  The only parameter at my disposal in M3UAv8 is the Network
Apperance.  As anything less that an SPMC Identifier, Network Appearance is
insufficient for discriminating the SPMC on DUNA/DAVA/... messages.

The proposal to replace Network Appearance with Routing Context to solve
this problem, while readily adopted by SUAv7, has met with resistance from
those that do not understand that STP Gateway screening can completely
"partitions" an SS7 network by end-point.

In practice, the owner of an M3UA platform who needs to interconnect to
existing SS7 networks, has little choice whether the network provider
performs gateway screening.  Gateway screening is permitted in ITU models as
well and is even permitted on the International Network.

Here is one more illustrative example:

                |                                                      
                      /----------------\                               
                |     |      SG        |                               
                      |                |                               
        GWS     |     |    5.255.1     |                               
       _____          |A1    ___       |  _____|     |___|_____|____ /   \
|                               
      | STP |         |  __| SEP |     |                               
     /|_____|\  |A-links/   \___/      |                               
    /    |    \       |/ A2     \      |          /----------------\   
   /     |     \|     /          \ RC1 |     __   |      ASP       |   
  /      |      \    /|           \    |    /  \  |                |  /
C-links   |\  / |            \___|___|____|_|____ AS1        |  B/D     |
\/  |                |   |    | |                |  links   |      | /\  |
___|___|____|_|____ AS2        |  \       |       /  \ |            /   |
|    | |                |   
  \      |      |    \|           /    |    \__/  |                |   
   \     |     /      \          / RC2 |     \    |                |   
    \  __|__  / |     |\ A3  ___/      |      \   \----------------/   
     \|     |/   A-links\__ /   \      |       \  _____| STP
|___|_____|____| SEP |     |        \                      
      |_____|         |     \___/      |         \                     
                |     |A4              |       1 Association           
        GWS           |    5.255.2     |                               
                |     |                |                               
                      |                |                               
                |     \----------------/                               
                                                                       
                |                                                      
           Demarcation                                                 

Consider that I have one signalling point with two "real" point codes.
By "real" I mean that each point code has A-links associated with it as
illustrated.  There are several reasons for doing this: a) CIC range
exhaustion on large switches; b) A-link exhaustion on large databases.
Because I interconnect to a network provider (I don't own my own SS7
network) my network provider applies Gateway Screening on their side of the
Demarcation.

What gateway screening means at an access point is that the network
provider's STPs will only allow MSUs on A-links A1 and A2 in the diagram
which have OPC = 5.255.1.  Any other OPC and the MSUs will be thrown on the
floor without warning.  The STPs will only allow MSUs on A-links A3 and A4
which have OPC = 5.255.2.

So Gateway screening has effectively partitioned access into the network so
that SEP 5.255.1 can only access the network from A-links A1 and A2, and SEP
5.255.2 can only access the network from A-links A3 and A4.

I stress: this is real world example.  This happens all the time at
interconnect points.  Even between carriers.

Now, because I have one big switch or one big database, I serve each entire
point code into two Routing Contexts: RC1 and RC2.  I have a pool of ASPs
each serving AS1(RC1) and AS2(RC2).  To separate this from a multiple
SGP/ASP issue, I have only drawn one SG/SGP and one ASP.  The ASP is
connected over a single association to the SG/SGP.

Now, through a combination of conditions in the network and of the A-links
connecting the SG to the SS7 network, it is possible that a routeset becomes
prohibited, restricted or congested to SEP 5.255.1, but is it not
prohibited, restticted nor congested to SEP 5.255.2.

Consider isolation:  Say, for example, we lose A-links A1 and A2.
SEP 5.255.1 is isolated from the SS7 network and goes into MTP-RESTART.  We
want to send DUNA(-1) to the ASP to tell it that SEP 5.255.1 is isolated
from the network.  If I follow your view of Network Appearance, I do not
include a Network Appearance parameter in the DUNA message, so I send it to
the ASP.

The ASP receives DUNA(-1).  It does not know which SPMC is isolated from the
newtork, so it is forced to apply it to all ASs.  As a result, it has
effectively disconnected SEP 5.255.2 from the network.

If the SG were permitted to put RC in the DUNA message, it would label it
with RC1 and the DUNA(-1) would only be applied to AS1 at the ASP.

If Network Appearance followed the initial recommendation on this thread, it
would identify SPMC 5.255.1 and the ASP would only apply the DUNA(-1) to
AS1/SPMC1.

If RC is included in the SNMM messages, Network Appearance as you define it
would become redundant.

So you pick: which way are you going to keep a 50% link failure somewhere in
the network from turning into a 100% failure at the ASP.

--Brian

[email-masked] wrote:           (Mon, 30 Jul 2001 13:14:06)
>
> Brian,
> 
> Your attempt to redefine "Network Appearance" as the "SPMC identifier" is 
> unnecessary, confusing and incorrect.
> 
> The purpose of the Network Appearance is to allow the Sigtran stack to 
> differentiate in its handling of messages coming from different SS7 
> networks to which the SG may be connected, particularly when the traffic 
> from the different networks is going over the same SCTP association.
> 
> The purpose of the SPMC is almost exactly opposite. Its purpose is to 
> allow the SS7 network to view the Sigtran network of SG's and AS's as a 
> single entity to which SS7 network management procedures can be applied.
> 
> I also object to the following sentence which was added to the Network 
> Appearance definition in v7:
> 
> "It is also necessary when an SG is configured as an STP hosting multiple 
> point codes, or when configured as multiple end nodes within the same 
> network, in which case each point code is a separate network appearance."
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>
> 07/28/01 09:07 AM
> Please respond to sigtran
> 
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        Re: M3UA07: Network Appearance
> 
> 
> [snip]
> 
> The definition of a Network Appearance becomes (effectively): "An unique
> identifier indicating the Signalling Point Management Cluster (SPMC) to
> which Signalling Network Management Messages apply."
> 
> --Brian
> 
> 
> Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> > Brian,
> > 
> >                Why the need to include a concerned PC at all, the PC 
> would be
> > redundant to the one in the DPC.  Why not let the network appearance
> > parameter be equal to the Network ID (all 32 bits).  Then Network
> > Appearance(Network ID) + DPC will be unique and it will separate out the
> > traffic into networks in both directions SG->AS and AS->SG(-> and 
> beyond).
> > 
> > John 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:41 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA07: Network Appearance
> > 
> > 
> > Greg,
> > 
> > When an SG is has multiple point codes serving ASPs which are
> > active in multiple SPMCs, it becomes necessary to label each
> > SPMC with a unique Network Appearance parameter to demultiplex
> > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > assignment is necessary for each SPMC and the adminstration of
> > these assignments could get quite tedious for an SGP/ASP pool
> > representing a large number of point codes, I would like to
> > propose the following refinement to the Network Appearance
> > Parameter:
> > 
> > (This is in fitting with the definition that a "Network Appearance 
> uniquely
> > identifies an SS7 entity (Point Code) into an SS7 network.")
> > 
> > The format of the Network Appearance 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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |  Network Id   |            Concerned Point Code               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Network Identifier: 8-bit (unsigned integer)
> > 
> >    The Network Identifier identifies the network in which the Concerned
> >    Point Code can be considered unique, and distinguishes this Concerned
> >    Point Code from an identical point code in any another network.
> >    A Network Identifier identifying a specific adminsitrative domain for
> >    the assignment of SS7 Signalling Point Codes MUST be global to all
> >    SGPs in an SG.
> > 
> > Concerned Point Code:
> > 
> >    The Concerned Point Code identifies a point code within the
> >    administrative domain as indicated by the Network Identifier.  The
> >    Concerned Point Code is the one point code of a Signalling Point
> >    Management Cluster (SPMC) which needs to receive updates concerning
> >    the accessibility/restriction/congestion status of routesets from the
> >    SPMC.
> > 
> > 
> > Comments?
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 12:03:45 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

Well, for one thing, the CIC is always at the same place and could be seen
as an extension of the routing label for ISUP & TUP. On the other hand, the
SSN is only optional in an SCCP message and might mean different things in
different networks. So leave this one for SUA ;)

TCAP TID is an even more dangerous way to go : - what TID : the destination
TID I would presume, - take into account TCAP message type (Query/Uni don't
contain a DTID), - the RK would define an additional AS with a single ASP
for each TID range, But :
- how to split up in TID ranges ? Every vendor has it's own personal layout
of TID to perform internal distribution of a TCAP message, and to catch
stray messages on old, no longer existing transactions.

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: dinsdag 31 juli 2001
4:20
To: sigtran
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

Hi Gery ..

Well, philosophically speaking, saying that RK parameters "should in general
not include any upper layer's parameters" and then supporting CIC for M3UA
as an exception, makes the whole statement meaningless to me  2;^)   Why is
CIC an exception and SSN is not?

As for TCAP TRID for an SUA RK I fear to tread here because I haven't been
following the SUA developments in SUA as I should.  But I currently don't
see why you couldn't allow Application Servers to divide up the TRID space.
There might be some application for that, but if not I won't cry if SUA
doesn't have it.  SGs don't have to have this in the REG/DEREG procedures if
they want to try it - these are optional procedures so there's really
nothing stopping an SG from trying out any kind of RK they can dream up.
IMHO RKs aren't restricted by what can or can't be populated in a REG
message.

Cheers,

   Greg

----- Original Message -----
From: "Verwimp Gery" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 30, 2001 11:43 AM
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.

Hi Greg,

I second that. Using TCAP transaction ID in SUA wouldn't be wise either.
With the exception of the CIC, RK parameters should in general not include
any of the upper layer's parameters (SSN, GT for M3UA; TID etc. for SUA).

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: maandag 30
juli 2001 17:17
To: sigtran
Cc: Greg Sidebottom
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

--
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 ¦

---
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]
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Bcc: 
Subject: Re: M3UA: Route-set congestion
Date: Tue, 31 Jul 2001 11:07:17 +0100
X-OriginalArrivalTime: 31 Jul 2001 10:07:18.0170 (UTC) 
                       FILETIME=[949E7FA0:01C119A8]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: f141.pav2.hotmail.com [64.4.37.141]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Hi Al,

Seem comments, below.

Amish

>    I agree -- this would be a pretty implementation-specific decision
>(waiting for multiple SCTP or IP associations to indicate congestion before
>notifying MTP3-users).  In general, if SCTP is operating but congested, I
>think most PSTN-signaling protocols (MTP, SCCP, Q.931) would be better off
>either killing the congested association or continuing to use it (with
>notification to the MTP3-user, etc.).  As Brian notes below, changing the
>SCTP association (or stream) used for MTP/SCCP/ISDN presents the
>possibility of mis-sequencing messages (or dropping all those still in the
>congested queue).

Yes, I agree with you. But I think it is necessary to explicitly specify
that an implementation should attempt to re-route the messages via another
association if possible - the current 2nd paragraph of 1.4.6 gives the
impression that user parts should start reducing traffic soon after
congestion is detected on a single "bad" association without attempting to
reroute the traffic. Having user-parts reduce their traffic if congestion is
detected on one linkset in a traditional fix-bandwith environment is correct
but in an IP environment this is dependent of the IP network design.

With reference to mis-sequecing of messages during an association
change-over: What's worse, mis-sequecing or loosing messages due to
congestion and blocking of calls/transactions when congestion occurs,
especially is a perfectly good alternate route exists? Should we not attempt
to re-route the traffic (possibly at the expense of implementation dependant
mis-sequencing) if we can continue to maintain the designed call/transaction
load on the alternate associations?

>
>    While I have no experience with SCTP in the field, much of SS7
>congestion today is very short-lived and re-routing around such events
>could often take longer than the events last.

Well that depends on the quality/reliability/diversity of the transmission
network and the how the operator has designed the overlying signalling
network. I have seen route-set congestion in the order of a few minutes to
an hour.

>Handshakes and message
>holding while doing changeover/changeback or similar re-routing schemes
>also increase the chance of congestion on other routes.  That's why SS7
>operates with the philosophy of just continuing as usual when congestion
>events occur -- they're infrequent, short and assumed to apply to all
>traffic to a TFC-producing destination.  In other words, the network
>overreacts to congestion as a trade-off to avoiding large queues of
>messages internally.

The design of the SS7 congestion control is based on the philosophy that the
signalling load is distributed evenly across all the active routes (e.g. the
4 routes in the typical quad STP architecture - where the same bandwidth is
allocated across all the A-links and across all the B-links). Congestion
detected on a single link makes the assumption that the traffic is more or
less equivalent across all the other links (in all that routes) that carry
the same traffic - hence we use route-set congestion controls and not
controls that attempt to address congestion on a single route.

In an IP environment the associations from the MGC or the SGPs may not have
the bandwidth reserved for themselves as in traditional A-links. Congestion
controls for congestion detected in the IP-space should try to overcome
congested routes if possible. Congestion controls for congestion detected in
the SS7 network on the other side of the SGs should still be based on the
route-set congestion method as it is based on the traditional SS7 concepts.

>
>    If SCTP carries MTP traffic over a transport sub-network with constant
>congestion events, then it will provide its MTP-users with poor
>service.  But the messages that make it through should at least be timely
>ones, eh?

Poor service is not the goal of SS7 transport protocols, but timely delivery
is.

>
>>Switching traffic between SCTP associations which arrive a different
>>endpoints must be done quite carefully, because of the possibility of
>>mis-sequencing: i.e. the head of the traffic on the new association
>>overtaking the tail on the old past the SG/SGP.  Some sort of controlled
>>rerouting, changeover or other procedure could be necessary.
>
>    I'm waiting for completion of your meeting before commenting on Brian's
>"per-SGP/per-ASP" proposal for dealing with DUNA, etc.  I like the idea,
>but believe it suffers from exactly this same problem -- without an
>alternative M3UA message mechanism (SGP management messages) mis-sequencing
>or unneeded message loss will occur when an ASP re-directs traffic from one
>SGP to another.  I don't believe you can have an ASP re-direct traffic away
>from or back to an SGP without SGP/ASP management interaction.  DUNA, etc.
>are the wrong messages for that.
>
>    I'm assuming the meeting will be more productive than some of the other
>blather I've seen on the multi-SGP topic ("Mine is bigger than yours!!"
>doesn't fit into this technical discussion).

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 12:12:12 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Greg,

Just use SI=3 in your M3UA RK to separate SCCP traffic !

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: dinsdag 31 juli 2001
6:48
To: sigtran
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

Hi Brian,

Responses below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "Greg Sidebottom" <[email-masked]>
Sent: Monday, July 30, 2001 11:17 AM
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

[Greg] I'll try and remember but this is from a while ago.  I think there
are valid cases where an MGC supports both ISUP and TCAP (lets say for CCBS
or the CLASS equivalent service).  While I'd agree that SUA is probably a
better choice for the SCCP/TCAP traffic, the SG needs M3UA for the ISUP
traffic already and it seems a lot of overhead to also support SUA and
another SCTP association just for the TCAP traffic.  So a RK could be used
to direct SCCP traffic for this service to an active MGC.  I assume that
SCCP management is not perfect but it is probably not used completely anyway
for these end-node to end-node services because SCCP management will
probably not be concerned about the subsystem state of all the possible CCBS
peers (or support traffic Mix procedures or SOR/SOG for that matter).  I'm
not sure why OMAP SRVT would be an issue yet.  In any case, for the SSN RK
cases I've seen discussed, OMAP SRVT could be ignored as it wasn't used in
the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks, as far
as I've seen anyway.

Another case I have also seen is where M3UA is used from an SG to a
database, but the SG didn't support SUA yet.  So the SG makes up for this by
handling all the SCCP management on behalf of the database, at least those
parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).

[snip]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SCCP Message Priority
Date: Tue, 31 Jul 2001 12:21:58 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Well I don't want to discuss this too long, but is this (yet another)
additional parameter really necessary ? Regardless of philosophy, the SCCP
gets a "priority" parameter from it's user and derives importance (if it's
required in the XUDT e.g.) and MP (if required by the MTP layer) from it.

I don't think their would be messages around having a low MP but a high
importance ??

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: maandag 30
juli 2001 15:25
To: sigtran
Subject: Re: SCCP Message Priority

Gery,

Unfortunately, Message Priority is not ANSI specific.  Therefore, it is
quite possible to have ITU Importance in SCCP with Message Priority in the
RL.

For example, although TTC JT-Q.712 deletes the Importance parameter,
shouldn't we let TTC JT-Q.712 put Importance in when TTC has a need for it?

If you want to let the SG take care of as much as possible, don't use one
field for two things: keep MP and Importance separate.

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
14:53:40)
> Hello Brian, all,
> 
> The SUA importance field in the Flags parameter is used to give an
> indication of the priority of the message. This field should be enough to
> derive:
> 
> - importance value in a.o. XUDT messages (the only indication of
> priority/importance in ITU)
> - message priority field in SIO in case of ANSI network
> - whatever else is needed in another flavour of SS7 regarding
> priority/importance
> 
> and to allow SCCP on the SG to perform appropriate action in case of
> congestion in the SS7 network.
> 
> Let the SG take care of as much of the SS7 flavours/specifics as possible
!
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 23 juli 2001 21:25
> To: sigtran
> Subject: Re: SCCP Message Priority
> 
> 
> John,
> 
> The message priorities (that go in the MTP RL for congestion
> control) associated with ANSI SCCP are set by the SCCP-User.
> TCAP, for example, will up the MP on Conversation packages from
> 0 to 1.  Some critical connection sections in the
> connection-oriented procedures will have some of the CO messages
> upped from 0 to 1.  OMAP uses 2.  Because these values come from
> the SCCP-User and are communicated down to MTP through the
> MTP-TRANSFER primitive, all messages which carry the Flags
> parameter may need to have message priorities assigned (some CO
> messages do not).  The SUA SHOULD police the setting of MP bits
> on messages which have a fixed priority (to save an application
> from setting them by mistake).  Other messages will use the
> value provided by the SCTP-User when formulating the
> MTP-TRANSFER primitive at the SG.  The MP value needs to be
> communicated from ASP to SG and visa versa.  Some times the SCCP
> needs to know the setting of MP for an incoming message to know
> the setting what setting to use for an outgoing message.
> 
> The message that is is definitely needed on is the CLDT.
> 
> John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> > Hi Ray,
> > 
> > > Could someone please clarify whether SUA would allow ANSI 
> > > message priority values to be conveyed between peer SUA/SUA 
> > > Users.
> > 
> > I'm not so familiar with ANSI SCCP (though I bet a few folks on
> > this list are).  Could you fill me in a little bit on what 
> > you need?
> > 
> > John
> > 
> 
> -- 
> 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]

-- 
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]
Date: Tue, 31 Jul 2001 05:37:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCCP Message Priority
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Really, the MP value has nothing to do with importance in the sense that a
911 call is more "important" than another call.  It has to do with
congestion and which messages may be discarded and expect that state
machines will generate less messages than more.

For example, opening a transaction is of a lower MTP messages priority than
closing one.  This is because after the close of  the transaction no
messages follow related to the transaaction state machine.  If the closing
message were to be discarded, the peer would likely regenerate the request.
Opening a transaction is..... well, you get the point.

My understanding of the Importance parameter was it had more to do with
classes of service and the "911" call kind of thing.

Even in semantics I believe that these two parameters are orthoginal.

Al?

--Brian

Verwimp Gery wrote:                                 (Tue, 31 Jul 2001
12:21:58)
> Well I don't want to discuss this too long, but is this (yet another)
> additional parameter really necessary ? Regardless of philosophy, the SCCP
> gets a "priority" parameter from it's user and derives importance (if it's
> required in the XUDT e.g.) and MP (if required by the MTP layer) from it.
> 
> I don't think their would be messages around having a low MP but a high
> importance ??
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 30 juli 2001 15:25
> To: sigtran
> Subject: Re: SCCP Message Priority
> 
> 
> Gery,
> 
> Unfortunately, Message Priority is not ANSI specific.  Therefore, it is
> quite possible to have ITU Importance in SCCP with Message Priority in
> the RL.
> 
> For example, although TTC JT-Q.712 deletes the Importance parameter,
> shouldn't we let TTC JT-Q.712 put Importance in when TTC has a need for
> it?
> 
> If you want to let the SG take care of as much as possible, don't
> use one field for two things: keep MP and Importance separate.
> 
> --Brian
> 
> Verwimp Gery wrote:                                       (Mon, 30 Jul
2001
> 14:53:40)
> > Hello Brian, all,
> > 
> > The SUA importance field in the Flags parameter is used to give an
> > indication of the priority of the message. This field should be enough
to
> > derive:
> > 
> > - importance value in a.o. XUDT messages (the only indication of
> > priority/importance in ITU)
> > - message priority field in SIO in case of ANSI network
> > - whatever else is needed in another flavour of SS7 regarding
> > priority/importance
> > 
> > and to allow SCCP on the SG to perform appropriate action in case of
> > congestion in the SS7 network.
> > 
> > Let the SG take care of as much of the SS7 flavours/specifics as
possible
> !
> > 
> > ____________________________
> > 
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > > 
> > > Tel. : +32 14 25 3424
> > Fax: +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> > 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: maandag 23 juli 2001 21:25
> > To: sigtran
> > Subject: Re: SCCP Message Priority
> > 
> > 
> > John,
> > 
> > The message priorities (that go in the MTP RL for congestion
> > control) associated with ANSI SCCP are set by the SCCP-User.
> > TCAP, for example, will up the MP on Conversation packages from
> > 0 to 1.  Some critical connection sections in the
> > connection-oriented procedures will have some of the CO messages
> > upped from 0 to 1.  OMAP uses 2.  Because these values come from
> > the SCCP-User and are communicated down to MTP through the
> > MTP-TRANSFER primitive, all messages which carry the Flags
> > parameter may need to have message priorities assigned (some CO
> > messages do not).  The SUA SHOULD police the setting of MP bits
> > on messages which have a fixed priority (to save an application
> > from setting them by mistake).  Other messages will use the
> > value provided by the SCTP-User when formulating the
> > MTP-TRANSFER primitive at the SG.  The MP value needs to be
> > communicated from ASP to SG and visa versa.  Some times the SCCP
> > needs to know the setting of MP for an incoming message to know
> > the setting what setting to use for an outgoing message.
> > 
> > The message that is is definitely needed on is the CLDT.
> > 
> > John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> > > Hi Ray,
> > > 
> > > > Could someone please clarify whether SUA would allow ANSI 
> > > > message priority values to be conveyed between peer SUA/SUA 
> > > > Users.
> > > 
> > > I'm not so familiar with ANSI SCCP (though I bet a few folks on
> > > this list are).  Could you fill me in a little bit on what 
> > > you need?
> > > 
> > > John
> > > 
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SCCP Message Priority
Date: Tue, 31 Jul 2001 13:32:16 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Hm, I don't think they are ortogonal. Now they are used for the same purpose
: a congestion level is calculated (either by MTP or the User Parts), and if
the priority/importance is not high enough, the message is
discarded/rerouted via a less congested route.

They would be orthogonal if priority would mean "send this message first,
because it has higher priority than other messages", and importance would
mean "this message should not get lost due to congestion, because of it's
high importance".

E.g. a TC_Query (opening a transaction) now gets low importance, and hence
low priority. Of course, with the (ANSI) MTP calculated levels, you have
limited possibilities (0, 1, occasionally 2, 3 reserved for MTP management
messages) ...

Are there any other views ?

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: dinsdag 31
juli 2001 12:38
To: sigtran
Subject: Re: SCCP Message Priority

Gery,

Really, the MP value has nothing to do with importance in the sense that a
911 call is more "important" than another call.  It has to do with
congestion and which messages may be discarded and expect that state
machines will generate less messages than more.

For example, opening a transaction is of a lower MTP messages priority than
closing one.  This is because after the close of  the transaction no
messages follow related to the transaaction state machine.  If the closing
message were to be discarded, the peer would likely regenerate the request.
Opening a transaction is..... well, you get the point.

My understanding of the Importance parameter was it had more to do with
classes of service and the "911" call kind of thing.

Even in semantics I believe that these two parameters are orthoginal.

Al?

--Brian

Verwimp Gery wrote:                                 (Tue, 31 Jul 2001
12:21:58)
> Well I don't want to discuss this too long, but is this (yet another)
> additional parameter really necessary ? Regardless of philosophy, the SCCP
> gets a "priority" parameter from it's user and derives importance (if it's
> required in the XUDT e.g.) and MP (if required by the MTP layer) from it.
> 
> I don't think their would be messages around having a low MP but a high
> importance ??
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 30 juli 2001 15:25
> To: sigtran
> Subject: Re: SCCP Message Priority
> 
> 
> Gery,
> 
> Unfortunately, Message Priority is not ANSI specific.  Therefore, it is
> quite possible to have ITU Importance in SCCP with Message Priority in
> the RL.
> 
> For example, although TTC JT-Q.712 deletes the Importance parameter,
> shouldn't we let TTC JT-Q.712 put Importance in when TTC has a need for
> it?
> 
> If you want to let the SG take care of as much as possible, don't
> use one field for two things: keep MP and Importance separate.
> 
> --Brian
> 
> Verwimp Gery wrote:                                       (Mon, 30 Jul
2001
> 14:53:40)
> > Hello Brian, all,
> > 
> > The SUA importance field in the Flags parameter is used to give an
> > indication of the priority of the message. This field should be enough
to
> > derive:
> > 
> > - importance value in a.o. XUDT messages (the only indication of
> > priority/importance in ITU)
> > - message priority field in SIO in case of ANSI network
> > - whatever else is needed in another flavour of SS7 regarding
> > priority/importance
> > 
> > and to allow SCCP on the SG to perform appropriate action in case of
> > congestion in the SS7 network.
> > 
> > Let the SG take care of as much of the SS7 flavours/specifics as
possible
> !
> > 
> > ____________________________
> > 
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > > 
> > > Tel. : +32 14 25 3424
> > Fax: +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> > 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: maandag 23 juli 2001 21:25
> > To: sigtran
> > Subject: Re: SCCP Message Priority
> > 
> > 
> > John,
> > 
> > The message priorities (that go in the MTP RL for congestion
> > control) associated with ANSI SCCP are set by the SCCP-User.
> > TCAP, for example, will up the MP on Conversation packages from
> > 0 to 1.  Some critical connection sections in the
> > connection-oriented procedures will have some of the CO messages
> > upped from 0 to 1.  OMAP uses 2.  Because these values come from
> > the SCCP-User and are communicated down to MTP through the
> > MTP-TRANSFER primitive, all messages which carry the Flags
> > parameter may need to have message priorities assigned (some CO
> > messages do not).  The SUA SHOULD police the setting of MP bits
> > on messages which have a fixed priority (to save an application
> > from setting them by mistake).  Other messages will use the
> > value provided by the SCTP-User when formulating the
> > MTP-TRANSFER primitive at the SG.  The MP value needs to be
> > communicated from ASP to SG and visa versa.  Some times the SCCP
> > needs to know the setting of MP for an incoming message to know
> > the setting what setting to use for an outgoing message.
> > 
> > The message that is is definitely needed on is the CLDT.
> > 
> > John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> > > Hi Ray,
> > > 
> > > > Could someone please clarify whether SUA would allow ANSI 
> > > > message priority values to be conveyed between peer SUA/SUA 
> > > > Users.
> > > 
> > > I'm not so familiar with ANSI SCCP (though I bet a few folks on
> > > this list are).  Could you fill me in a little bit on what 
> > > you need?
> > > 
> > > John
> > > 
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 09:01:57 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by oak.neustar.com id 
                      f6VE1q313204
X-SMTP-HELO: oak.neustar.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: oak.neustar.com [209.173.53.70]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg, Gery:

Not only is the CIC always at the same place, but - unlike in ITU networks -
in ANSI networks the SLS is *NOT* tied to the CIC, so load distribution on
SLS to MGCs which handle certain CIC ranges (say odd and even) will not
work.
And even in ITU networks vendors with an ANSI background might violate the
CIC/SLS agreement.
As the SLS in SS7 networks is not used to select different end nodes, this
does not cause any problems (well, at least no obvious ones ;o) )

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: July 31, 2001 6:04 AM
> To: sigtran
> Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Hi Greg,
> 
> Well, for one thing, the CIC is always at the same place and 
> could be seen
> as an extension of the routing label for ISUP & TUP. On the 
> other hand, the
> SSN is only optional in an SCCP message and might mean 
> different things in
> different networks. So leave this one for SUA ;)
> 
> TCAP TID is an even more dangerous way to go :
> - what TID : the destination TID I would presume,
> - take into account TCAP message type (Query/Uni don't 
> contain a DTID),
> - the RK would define an additional AS with a single ASP for 
> each TID range,
> But :
> - how to split up in TID ranges ? Every vendor has it's own 
> personal layout
> of TID to perform internal distribution of a TCAP message, 
> and to catch
> stray messages on old, no longer existing transactions.
> 
> Regards,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: dinsdag 31 juli 2001 4:20
> To: sigtran
> Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Hi Gery ..
> 
> Well, philosophically speaking, saying that RK parameters 
> "should in general
> not include any upper layer's parameters" and then supporting 
> CIC for M3UA
> as an exception, makes the whole statement meaningless to me  
> 2;^)   Why is
> CIC an exception and SSN is not?
> 
> As for TCAP TRID for an SUA RK I fear to tread here because I 
> haven't been
> following the SUA developments in SUA as I should.  But I 
> currently don't
> see why you couldn't allow Application Servers to divide up 
> the TRID space.
> There might be some application for that, but if not I won't 
> cry if SUA
> doesn't have it.  SGs don't have to have this in the 
> REG/DEREG procedures if
> they want to try it - these are optional procedures so there's really
> nothing stopping an SG from trying out any kind of RK they 
> can dream up.
> IMHO RKs aren't restricted by what can or can't be populated in a REG
> message.
> 
> Cheers,
> 
>    Greg
> 
> ----- Original Message -----
> From: "Verwimp Gery" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 30, 2001 11:43 AM
> Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Hi Greg,
> 
> I second that. Using TCAP transaction ID in SUA wouldn't be 
> wise either.
> With the exception of the CIC, RK parameters should in 
> general not include
> any of the upper layer's parameters (SSN, GT for M3UA; TID 
> etc. for SUA).
> 
> Regards,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> >
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 30 juli 2001 17:17
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Greg,
> 
> I don't see that rational basis on which M3UA can apply routing keys
> based on SCCP Subsystem number.  Can someone provide an 
> example on just
> how this was expected to work?  (Particularly how SCCP Management is
> handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> here.
> 
> I propose that we strike SSN from the Routing Key in the REG REQ
> message.
> 
> Also, TCAP Transaction Id is used as an example of a Routing Key,
> although there is no field for it in a REG REQ.  Distributing messages
> based on TCAP Transaction Ids doesn't strike me as rational either.
> I think you need TUA here.
> 
> I propose that we strike TCAP Transaction Id from the examples of
> Routing Keys.
> 
> --Brian
> 
> --
> 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 ¦
> 
> 
> ---
> 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]
Date: Tue, 31 Jul 2001 10:21:17 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dan,

I can see your point, which is similar to mine (making the SG appear as a
member in different networks).  In either scenario, it seems the goal is to
associate messages with a specific network when communicating between the SG
and the ASP.  The purpose of which is to support different network protocol
variants?

Jeff

Dan Brendes wrote:
> 
> I was under the impression that the purpose of the network appearance was
to be
> able to differentiate a point code in some network (such as an ITUN point
code
> of 100 in an Italian national network) from some other instance of that
point
> code in a different network.  By including the network appearance as
optional
> parameters in Data and DUNA/DAVA/etc messages it provides a way to
distinguish
> the Italian ITUN pc = 100 from the German ITUN pc =100, and so on.  Thats
all it
> is.  Nothing more.
> 
> The network appearance is a locally administered value at the SG that must
be
> shared with the ASP(s) only for those situations where the SG is connected
to
> multiple networks.
> 
> Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> Subject:  Re: M3UA07: Network Appearance
> 
> Brian,
> 
> I see an SG as receiving many SS7 links from the network and packaging
> the SS7 user for delivery into the IP network.  I really don't care what
> type of links they are as it shouldn't matter.
> 
> A SG receives an SS7 message and relays it to some node in the IP
> network.
> 
> Jeff
> 
> "Brian F. G. Bidulock" wrote:
> >
> > Jeff,
> >
> > If the SG is connected to the network with A-links, E-links or
> > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > an STP model would rule out many non-quasi-associated (F-link
> > connected) networks in places such as Europe.
> >
> > --Brian
> >
> > Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> > > Klaus,
> > >
> > > I agree with you that the discussions are getting increasingly
> > > confusing.  This multiple networks business is getting increasingly
> > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > connects to multiple networks with no problems, so this must not be
the
> > > problem trying to be solved.
> > >
> > > Given the above thought, I go to the next thought which is that
perhaps
> > > an attempt is being made to make the SG(STP) appear as if it belongs
to
> > > different networks rather than just one.  In such a case, the SG(STP)
> > > would need to have a multiple unique point code for identifying
itself,
> > > one for each network that it belongs to.  In such a case, if I'm
> > > forwarding a message to some other element such as an ASP, then I
would
> > > need something like an NA to represent each SS7 network to the ASPs.
> > > Doing this though would be a pain in the .... thought processs.
> > >
> > > Jeff
> > >
> > >
> > > "Gradischnig, Klaus" wrote:
> > > >
> > > > All:
> > > >
> > > > I am getting increasingly confused by this discussion on NA.
However, just
> > > > looking at its definition in M3UA08 alone would be enough to do the
job:
> > > >
> > > > "Network Appearance - The Network Appearance uniquely identifies an
SS7
> > > > entity (Point Code) into an SS7 network, as presented by the SG.  It
is
> > > > used for the purposes of logically separating the signalling traffic
> > > > between the SG and the Application Server Processes over a common
SCTP
> > > > association.  This partitioning is necessary where an SG is
logically
> > > > partitioned to appear as end node elements in multiple separate SS7
> > > >                                               ^^^^^^^^^^^^^^^^^^^^^
> > > > networks, in which case there is a separate network appearance for
each
> > > > ^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > point code in the SS7 networks.  It is also necessary when an SG is
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > [KDG] This clearly says to me that I need an NA if and only if I
have
> > > > multiple networks. In this case I need an NA for every point code,
> however.
> > > > Why I would need this in the case of multiple networks only beats
me.
> [KDG]
> > > >
> > > > configured as an STP hosting multiple point codes, or when
configured
> > > > as multiple end nodes within the same network, in which case each
point
> > > > code is a separate network appearance.between the SG and the
> > > > Application Server Processes over a common SCTP Association.  An
> > > > example is where an SG is logically partitioned to appear as an
element
> > > > in four separate national SS7 networks.  A Network Appearance
> > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > protocol type/variant/version used within a separate SS7 network.
> > > >
> > > > [KDG] In contrast, this last sentence now tells me that I need one
and
> only
> > > > one
> > > > NA for each network. This is at least something I understand and it
> > > > corresponds
> > > > to NA's original definition. [KDG]"
> > > >
> > > > And while I can see where Brian's example below is coming from, I
can't
> > > > except his arguments:
> > > > In the general case OPC specific screening cannot be handled by MTP
> > > > network/route management functions and therefore OPC specific
routing
> cannot
> > > > be supported without restrictions to either connectivity or network
> > > > management functionality. The example might start making sense if
the SG
> > > > considered 5.255.3 and 5.255.4 to belong to "separate" networks
using
> > > > different routing tables in the SG. In this case the SG may have to
have
> > > > distinct point codes in these "separate" networks, provided then
> "separate"
> > > > networks are actually interconnected (seems not to be the case in
this
> > > > example, though).
> > > > In any case, I fully support John's and Barry's view that NA
identifies a
> > > > network (albeit from an SG internal view) and not an SPMC.
> > > >
> > > > I am -- on an abstract level -- rather concerned about the
unnecessary
> > > > complexity which has been introduced into m3ua and I have some
indication
> > > > that a number of operators and manufacturers share this view. How
much of
> > > > m3ua's functionality has actually been tested in Sophia? It seems to
me
> that
> > > > without some extensive testing in a real or emulated SS7 network
> environment
> > > > going for last call is premature.
> > > >
> > > > Klaus
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: July 30, 2001 1:09 PM
> > > > > To: sigtran
> > > > > Subject: Re: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > > Please see response inline...
> > > > >
> > > > > John Schantz wrote:                               (Mon, 30
> > > > > Jul 2001 09:24:56)
> > > > > > Brian,
> > > > > >
> > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > single network
> > > > > > appearance is needed per network connection.
> > > > > >
> > > > > >     More comments below.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Perhaps now you can see (from our discussion on the thread
"M3UA:
> > > > > > Routing Context") that to cover all configurations, a
> > > > > Network Appearance
> > > > > > valud is required per primary point code and network id,
> > > > > and that this
> > > > > > proposal was a natural extension of that fact.  Consider
> > > > > the case below:
> > > > > >
> > > > > > [John] NO.
> > > > > >
> > > > >
> > > > >
> > > > >                            200.1.4    __________
> > > > >                              ___     /          \     ___
> > > > >                             /   \   |            |   /   \
> > > > >                            | SEP |__|____________|__| SEP |  AS1
> > > > >                             \___/   |            |   \___/
> > > > >                            //       |            |
> > > > >                           / |       | Signalling |  5.255.3
> > > > >                          / /        |   Gateway  |
> > > > >                         /  |        |            |
> > > > >                        /  /         |            |
> > > > >                _____  /   |         |            |
> > > > >               |     |/   /          |            |
> > > > >          -----| STP |____|__________|______      |
> > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > >             /    |      |           |          \_|_   ___
> > > > >          \ /     |     /            |            | \ /   \
> > > > >           X      |     |            |            |  | SEP |  AS2
> > > > >          / \     |    /             |           _|_/ \___/
> > > > >             \  __|__ /              |       ___/ |
> > > > >              \|     |_______________|______/     |       5.255.5
> > > > >          -----| STP |               |            |       (alias)
> > > > >               |_____|               |            |
> > > > >                                     |            |
> > > > >                                      \__________/
> > > > >
> > > > >
> > > > > >
> > > > > > The signalling gateway needs two different Network Appearance
> > > > > > parameters: one per SPMC.  The bottom SPMC needs only one
Network
> > > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > > the alias
> > > > > > point code 5.255.5 because they are both treated as the
> > > > > same from an SS7
> > > > > > newtork management view.
> > > > > >
> > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > figure above, NO
> > > > > > network appearance is needed at all.  What do you think the
> > > > > point code is
> > > > > > for??????  You seem to proposing that the network
> > > > > appearance replace the
> > > > > > point code for routing, NO.
> > > > >
> > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > and entire SEP in
> > > > > the diagram as labelled.  They are served over 1 association
> > > > > to an ASP which
> > > > > is configured and active for both ASs.  When the F-link fails
> > > > > from the SG to
> > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > Without something
> > > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > > AS2 will also
> > > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > > 200.1.4 via
> > > > > the STPs.
> > > > >
> > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > traffic from AS1
> > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > may throw these
> > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > only point codes
> > > > > allowed in the OPC on messages on the A-links.
> > > > >
> > > > > So, again, there are two choices:  Make Network Appearance an
> > > > > identifier
> > > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
servers
> > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > >
> > > > > >
> > > > > > Now, in general, a rational basis for assigning Network
> > > > > Apearance Id's
> > > > > > is to use the Network Id and Point Code of the node (the
> > > > > node *is* the
> > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > the SG sends
> > > > > > concerning the SPMC will be properly distinguish.
> > > > > >
> > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > affected point
> > > > > > code is all that is needed.
> > > > > >
> > > > > > Note that if the proposed assignment of Network Appearances is
used,
> > > > > > the SCON message no longer requires a Concerned Point Code
parameter
> > > > > > when the SPMC is signalling congestion to the SG.  It need only
use
> > > > > > the Network Appearance.
> > > > > >
> > > > > > [John] NO.
> > > > > >
> > > > > > The definition of a Network Appearance becomes
> > > > > (effectively): "An unique
> > > > > > identifier indicating the Signalling Point Management
> > > > > Cluster (SPMC) to
> > > > > > which Signalling Network Management Messages apply."
> > > > > >
> > > > > > [John]  NO.
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > >
> > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > 2001 13:37:00)
> > > > > > > Brian,
> > > > > > >
> > > > > > >   Why the need to include a concerned PC at all, the PC would
be
> > > > > > > redundant to the one in the DPC.  Why not let the network
> > > > > appearance
> > > > > > > parameter be equal to the Network ID (all 32 bits).  Then
Network
> > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > separate out the
> > > > > > > traffic into networks in both directions SG->AS and
> > > > > AS->SG(-> and beyond).
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > To: sigtran
> > > > > > > Cc: Greg Sidebottom
> > > > > > > Subject: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > Greg,
> > > > > > >
> > > > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
Appearance
> > > > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > > > representing a large number of point codes, I would like to
> > > > > > > propose the following refinement to the Network Appearance
> > > > > > > Parameter:
> > > > > > >
> > > > > > > (This is in fitting with the definition that a "Network
Appearance
> > > > > > uniquely
> > > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > > >
> > > > > > > The format of the Network Appearance 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
> > > > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > >    |  Network Id   |            Concerned Point Code
> > > > >          |
> > > > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > >
> > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > >
> > > > > > >    The Network Identifier identifies the network in which
> > > > > the Concerned
> > > > > > >    Point Code can be considered unique, and distinguishes
> > > > > this Concerned
> > > > > > >    Point Code from an identical point code in any another
network.
> > > > > > >    A Network Identifier identifying a specific
> > > > > adminsitrative domain for
> > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > global to all
> > > > > > >    SGPs in an SG.
> > > > > > >
> > > > > > > Concerned Point Code:
> > > > > > >
> > > > > > >    The Concerned Point Code identifies a point code within the
> > > > > > >    administrative domain as indicated by the Network
> > > > > Identifier.  The
> > > > > > >    Concerned Point Code is the one point code of a
> > > > > Signalling Point
> > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > updates concerning
> > > > > > >    the accessibility/restriction/congestion status of
> > > > > routesets from the
> > > > > > >    SPMC.
> > > > > > >
> > > > > > >
> > > > > > > Comments?
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > > >
> > > > > > --
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > Content-Description: Card for Jeff Copley
> > > begin:vcard
> > > n:Copley;Jeff
> > > tel;work:972.519.3758
> > > x-mozilla-html:FALSE
> > > org:Alcatel USA, Inc.
> > > version:2.1
> > > email;internet:[email-masked]
> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> NSGAP;Plano;Texas;75075-5813;USA
> > > x-mozilla-cpt:;20864
> > > fn:Jeff Copley
> > > end:vcard
> > >
> > >
> > >
> >
> > Content-Description: footer
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> [email-masked]
> >
> > --
> > 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley14.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 31 Jul 2001 10:26:18 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc. http://www.usa.alcatel.com/
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: m2pa query
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail2.alcatel.com [128.251.168.51]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Deepa,

Thanks for the comment. The picture in 5.1 was not updated. The text in
4.1.2 is "official". 

But keep in mind that the pictures in section 5 are only examples. If for
some reason the association has not been established when MTP3 sends Start
to M2PA, then M2PA should go ahead and establish the association. 

tomG.

[email-masked] wrote:
> 
> As reflected by the changes in m2pa-03.txt section 4.1.2, SCTP
> association is now created "early", rather than waiting for MTP3
> Start.
> 
> But the example message flow in the section of 5.1 still waits for the
> "start request" from MTP3 before sending "associate" primitive to
> SCTP;
> 
> Can someone clarify this?
> 
> Thanks,
> 
> Deepa Tonse,
> 
> RADISYS Corporation,

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 31 Jul 2001 10:46:56 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit
to quoted-printable by netmail.alcatel.com id KAA14965

Greg and Brian,

M3UA is supposed to support the upper layers of SS7.  If I needed both ISUP
and SCCP between two destinations, why would I want to develop a second UA
such as SUA when M3UA (or M2PA) can acheive this in just one UA.  Am I
missing something obvious? (It wouldn't be the first time.)

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Greg,
> 
> Please see comments inline...
> 
> Greg Sidebottom wrote:                      (Tue, 31 Jul 2001 00:47:44)
> > Hi Brian,
> >
> > Responses below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: "Greg Sidebottom" <[email-masked]>
> > Sent: Monday, July 30, 2001 11:17 AM
> > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> >
> >
> > Greg,
> >
> > I don't see that rational basis on which M3UA can apply routing keys
> > based on SCCP Subsystem number.  Can someone provide an example on just
> > how this was expected to work?  (Particularly how SCCP Management is
> > handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> > here.
> >
> > [Greg] I'll try and remember but this is from a while ago.  I think
there
> > are valid cases where an MGC supports both ISUP and TCAP (lets say for
CCBS
> > or the CLASS equivalent service).  While I'd agree that SUA is probably
a
> > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the ISUP
> > traffic already and it seems a lot of overhead to also support SUA and
> > another SCTP association just for the TCAP traffic. ...
> 
> Several comments here:
> 
> "[I]t seems a lot of overhead to support SUA"--Actually, for this
> restricted case, very minimal functionality from SUA is required
> (perhaps only class 0 operation), all all the ASP management functions
> are very close, really all that is required is supporting different
> parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> operation SUA has no more overhead that M3UA and there is a lot of
> common parts.
> 
> Quite frankly all that SUA needs to do is support two messages (XFER
> and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> without GT is really close to "bare" MTP and SUA handles this as the
> trivial case.
> 
> Perhaps you are looking at things backwards:  perhasp it is SUA which
> should provide the functionality of MTP (as a pass-through to the lower
> layer by shunting just a teeny bit of class 0), rather than M3UA
> attempting to provide the functionality of SCCP (by loading SS7 SCCP
> procedures into the M3UA at the SG).  Don't place SCCP functionality
> into M3UA (above the MTP user interface)--allow SUA to pass-down to MTP.
> This keeps SS7 functionality in the SS7 layers and UA functionality in
> the UA layers.
> 
> Nevertheless, it is not necessary to have multiple associations.  UA
> peers can be multiplexed over the same association by Payload Protocol
> Identifier.  See the thread "Multiple UAs per Association".
> 
> The simple example of CLASS belies the fact that the normal switch has
> alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> types of transaction which the switch needs to do also require
> conversations, both class 0 and 1 support, and interworking support on
> UDT/XUDT/LUDT, correlation of conversations, ...
> 
> > ... So a RK could be used
> > to direct SCCP traffic for this service to an active MGC.
> 
> This traffic can be routed on SI without SSN.  Unless you are
> considering some type of Global Title lookup as well, the SSN will not
> tell you where the subscriber data is (which AS to use).  Although
> splitting traffic into ISUP and SCCP traffic makes sense, splitting SCCP
> traffic by SSN does not, particularly in the case of CLASS-like services
> where all queries are against a GT which reflects subscriber
> information.  The SSN traffic will need to be split further (somewhere)
> for redundancy, so why do this?  Why not just loadshare all SCCP traffic
> by SLS and perform the SCCP functions at the ASP?  SLS (extended by CIC)
> is the only rational basis for loadsharing in M3UA, anyway.
> 
> > I assume that
> > SCCP management is not perfect but it is probably not used completely
anyway
> > for these end-node to end-node services because SCCP management will
> > probably not be concerned about the subsystem state of all the possible
CCBS
> > peers (or support traffic Mix procedures or SOR/SOG for that matter).
> 
> Again, this belies the fact that these switches also have LNP dips to
> perform which requires close monitoring of subsystem availability (the
> status of the LNP database from the MGC).  Also, switches normally do
> perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention
> the requirements of an MSC).
> 
> > I'm
> > not sure why OMAP SRVT would be an issue yet.  In any case, for the SSN
RK
> > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't used
in
> > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks, as
far
> > as I've seen anyway.
> 
> You may have never noticed it.  An SG/MGC must be able to respond to the
> message.
> 
> >
> > Another case I have also seen is where M3UA is used from an SG to a
> > database, but the SG didn't support SUA yet.  So the SG makes up for
this by
> > handling all the SCCP management on behalf of the database, at least
those
> > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).
> 
> At the rate we are going SUA may beat M3UA to proposed standard.  It may
> be the other way around: the MGC has SUA but no M3UA yet and must use
> the services of SUA to provide M3UA.  As I noted, all that SUA needs to
> provide M3UA service as well is a DUPU and XFER message.
> 
> >
> > But I don't really want to get into a long discussion of how these cases
can
> > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs
from a
> > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > prevent anyone from trying the above applications.  There is to me a
> > difference between saying that the RK parameter in a REG REQ doesn't
have a
> > certain sub-parameter and saying RKs cannot use certain information.
Any RK
> > you want to dream up is possible, its just that it may not be able to
> > configure it dynamically.  Of course not all RK permutations make sense
for
> > a given application/architecture so people need to be careful of their
> > dreams.
> 
> I think we need to draw a line here somewhere.  Otherwise, why not try
> to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try to
> do TCAP with M3UA?  These "experiments" are deviations from the
> fundamental SIGTRAN architecture--the stuff of reasearch.  For the sake
> of interoperability, the architecture needs to be adhered to and
> functional demarcations drawn.  Otherwise an ASP implementation will
> never know what to expect from an SG implementation an visa versa.
> 
> If the sake of M3UA is not interoperability between different SG and AS
> implementations, why is the spec being written?  A vendor can do
> whatever they want within their own architecture now anyway.
> 
> >
> >
> >
> > I propose that we strike SSN from the Routing Key in the REG REQ
> > message.
> >
> > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > although there is no field for it in a REG REQ.  Distributing messages
> > based on TCAP Transaction Ids doesn't strike me as rational either.
> > I think you need TUA here.
> >
> > [Greg] There are some "tricks" that SGs can play with TRIDS for certain
> > applications/architectures.   TRIDS are not in the REG REQ but like I
said
> > above I don't see this as an impediment to an SG configuring them in an
RK-
> > they just couldn't be dynamically registered.  I think way back some
people
> > were thinking of using the TRID ranges as a way of ensuring that the
> > responses get back to the right originating ASPs.  I haven't studied the
SUA
> > recently enough to know if this is still an issue though.
> 
> M3UA can provide the service TCAP requires (via SCCP) by loadsharing on
SLS.
> The TCAP transaction Id coming off the SS7 network has no bearing on
> anything and is not even unique unless it is taken into context with the
> complete SCCP Calling Part Address (including Global Title).  The
> Transaction Id is local to the exchange betwen two TC-entities and does
> need not even be unique by SSN.  AIN, for example, uses Global Title in
> the Calling and Called Party addresses to determine the TC-entity.  This
> includes Transation Type and Address.  Correlation Ids in conversations
> are next to impossible to attempt to handle in this fashion.
> 
> Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA
> here.  If that is the approach the WG wants to take, why not smash all
> four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> 
> >
> > I don't mind removing TRID as an example if it causes any confusion - as
> > long as there is no restriction on the Routing Key in the SG.  If there
are
> > future applications to include field "xyz" in a Routing Key then I don't
> > think its not the role of the M3UA to say that it cannot be done.
> 
> I disagree.  I believe that M3UA should be constrained to the SIGTRAN
> architecture and not try to skip upwards in protocol level.  I believe
> that there would be more value in skipping downwards from SUA to MTP
> than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> believe that the line should be drawn.
> 
> I believe that the same is true for ISUP.  CIC ranges have no place in
> the Routing Key.  I believe that M3UA should consider them an "extended"
> SLS for loadsharing, but routing on them makes no sense.
> 
> --Brian
> 
> >
> > Cheers,
> >
> >    Greg
> >
> >
> >
> >
> >
> > I propose that we strike TCAP Transaction Id from the examples of
> > Routing Keys.
> >
> > --Brian
> >
> > --
> > 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 ¦
> >
> >
> > ---
> > 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]
> 
> --
> 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley15.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
Subject: RE: SCCP Message Priority
To: "sigtran" <[email-masked]>
Date: Tue, 31 Jul 2001 11:57:21 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 07/31/2001 11:57:22 AM
X-SMTP-HELO: dnsmx1pya.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnsmx1pya.telcordia.com [128.96.20.31]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Gery and Others,

Actually Importance and Message Priority are unrelated, and it is quite
possible that a network may be performing the procedures associated  both of
these parameters.   The Importance parameter is an SCCP parameter used by
the SCCP for SCCP congestion control at a node.  The Message Priority is an
MTP parameter used for congestion control at the MTP layer.

Ray

Verwimp Gery <[email-masked]> on 07/31/2001 07:32:16 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Ray P.
Singh/Telcordia)
Subject:  RE: SCCP Message Priority

Brian,

Hm, I don't think they are ortogonal. Now they are used for the same purpose
: a congestion level is calculated (either by MTP or the User Parts), and if
the priority/importance is not high enough, the message is
discarded/rerouted via a less congested route.

They would be orthogonal if priority would mean "send this message first,
because it has higher priority than other messages", and importance would
mean "this message should not get lost due to congestion, because of it's
high importance".

E.g. a TC_Query (opening a transaction) now gets low importance, and hence
low priority. Of course, with the (ANSI) MTP calculated levels, you have
limited possibilities (0, 1, occasionally 2, 3 reserved for MTP management
messages) ...

Are there any other views ?

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: dinsdag 31
juli 2001 12:38
To: sigtran
Subject: Re: SCCP Message Priority

Gery,

Really, the MP value has nothing to do with importance in the sense that a
911 call is more "important" than another call.  It has to do with
congestion and which messages may be discarded and expect that state
machines will generate less messages than more.

For example, opening a transaction is of a lower MTP messages priority than
closing one.  This is because after the close of  the transaction no
messages follow related to the transaaction state machine.  If the closing
message were to be discarded, the peer would likely regenerate the request.
Opening a transaction is..... well, you get the point.

My understanding of the Importance parameter was it had more to do with
classes of service and the "911" call kind of thing.

Even in semantics I believe that these two parameters are orthoginal.

Al?

--Brian

Verwimp Gery wrote:                                 (Tue, 31 Jul 2001
12:21:58)
> Well I don't want to discuss this too long, but is this (yet another)
> additional parameter really necessary ? Regardless of philosophy, the SCCP
> gets a "priority" parameter from it's user and derives importance (if it's
> required in the XUDT e.g.) and MP (if required by the MTP layer) from it.
>
> I don't think their would be messages around having a low MP but a high
> importance ??
>
> ____________________________
>
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> >
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
>
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 30 juli 2001 15:25
> To: sigtran
> Subject: Re: SCCP Message Priority
>
>
> Gery,
>
> Unfortunately, Message Priority is not ANSI specific.  Therefore, it is
> quite possible to have ITU Importance in SCCP with Message Priority in
> the RL.
>
> For example, although TTC JT-Q.712 deletes the Importance parameter,
> shouldn't we let TTC JT-Q.712 put Importance in when TTC has a need for
> it?
>
> If you want to let the SG take care of as much as possible, don't
> use one field for two things: keep MP and Importance separate.
>
> --Brian
>
> Verwimp Gery wrote:                                       (Mon, 30 Jul
2001
> 14:53:40)
> > Hello Brian, all,
> >
> > The SUA importance field in the Flags parameter is used to give an
> > indication of the priority of the message. This field should be enough
to
> > derive:
> >
> > - importance value in a.o. XUDT messages (the only indication of
> > priority/importance in ITU)
> > - message priority field in SIO in case of ANSI network
> > - whatever else is needed in another flavour of SS7 regarding
> > priority/importance
> >
> > and to allow SCCP on the SG to perform appropriate action in case of
> > congestion in the SS7 network.
> >
> > Let the SG take care of as much of the SS7 flavours/specifics as
possible
> !
> >
> > ____________________________
> >
> > Gery Verwimp
> > > SIEMENS ATEA
> > > ICN D CS D5
> > >
> > > Tel. : +32 14 25 3424
> > Fax: +32 14 25 3212
> > mailto:[email-masked]
> > ____________________________________
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: maandag 23 juli 2001 21:25
> > To: sigtran
> > Subject: Re: SCCP Message Priority
> >
> >
> > John,
> >
> > The message priorities (that go in the MTP RL for congestion
> > control) associated with ANSI SCCP are set by the SCCP-User.
> > TCAP, for example, will up the MP on Conversation packages from
> > 0 to 1.  Some critical connection sections in the
> > connection-oriented procedures will have some of the CO messages
> > upped from 0 to 1.  OMAP uses 2.  Because these values come from
> > the SCCP-User and are communicated down to MTP through the
> > MTP-TRANSFER primitive, all messages which carry the Flags
> > parameter may need to have message priorities assigned (some CO
> > messages do not).  The SUA SHOULD police the setting of MP bits
> > on messages which have a fixed priority (to save an application
> > from setting them by mistake).  Other messages will use the
> > value provided by the SCTP-User when formulating the
> > MTP-TRANSFER primitive at the SG.  The MP value needs to be
> > communicated from ASP to SG and visa versa.  Some times the SCCP
> > needs to know the setting of MP for an incoming message to know
> > the setting what setting to use for an outgoing message.
> >
> > The message that is is definitely needed on is the CLDT.
> >
> > John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> > > Hi Ray,
> > >
> > > > Could someone please clarify whether SUA would allow ANSI
> > > > message priority values to be conveyed between peer SUA/SUA
> > > > Users.
> > >
> > > I'm not so familiar with ANSI SCCP (though I bet a few folks on
> > > this list are).  Could you fill me in a little bit on what
> > > you need?
> > >
> > > John
> > >
> >
> > --
> > 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]
>
> --
> 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]

--
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]
From: "May, Howard" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Tue, 31 Jul 2001 17:22:21 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: odin.isw.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: swfdns01.isw.intel.com [192.55.37.143]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I believe it is fair to say that a requirement to differentiate between PCs
in different networks exists.  I also believe that the NA does this well.  I
also believe that the M3UA07 definition of NA does more than just this....

If the SG has multiple PC appearances into the same network (no comment on
why you would want to do this) then the NA differentiates between these.
E.G. The SG connects to one network but has two point codes in the network
(perhaps one linkset per point code)

So the question I am asking is is there really a requirement to know the PC
a message arrived at?  What would we do with the information?

Taking this a little further it could be asked whether we want to know not
only which PC a message arrived at at the SG, but which link set it arrived
at...

Lets say we have an SG in a single network.  Lets say the SG has one PC and
connects to two STPs (one link set to each STP).  If we have a network
appearance per link-set then an ASP can know which link-set and hence which
STP a message came from.  This allows more flexible routing to be employed.

I know that in a perfect SS7 world there is no reason to onward route
messages differently based on just the route they took to get to you.  I
also know this is not a perfect world ..

Do you think having a NA per link-set simplifies the concept?  The NA
definition would boil down to something as simple as 'The Network Appearance
uniquely identifies the link-set a message arrived at etc etc'

Do you think there is a requirement to know this kind of information?

> -----Original Message-----
> From: Jeff Copley [mailto:[email-masked]]
> Sent: 31 July 2001 16:21
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
> 
> 
> Dan,
> 
> I can see your point, which is similar to mine (making the SG 
> appear as
> a member in different networks).  In either scenario, it 
> seems the goal
> is to associate messages with a specific network when communicating
> between the SG and the ASP.  The purpose of which is to support
> different network protocol variants?
> 
> Jeff
> 
> Dan Brendes wrote:
> > 
> > I was under the impression that the purpose of the network 
> appearance was to be
> > able to differentiate a point code in some network (such as 
> an ITUN point code
> > of 100 in an Italian national network) from some other 
> instance of that point
> > code in a different network.  By including the network 
> appearance as optional
> > parameters in Data and DUNA/DAVA/etc messages it provides a 
> way to distinguish
> > the Italian ITUN pc = 100 from the German ITUN pc =100, and 
> so on.  Thats all it
> > is.  Nothing more.
> > 
> > The network appearance is a locally administered value at 
> the SG that must be
> > shared with the ASP(s) only for those situations where the 
> SG is connected to
> > multiple networks.
> > 
> > Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
> > 
> > Please respond to [email-masked]
> > 
> > To:   "sigtran" <[email-masked]>
> > cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> > Subject:  Re: M3UA07: Network Appearance
> > 
> > Brian,
> > 
> > I see an SG as receiving many SS7 links from the network 
> and packaging
> > the SS7 user for delivery into the IP network.  I really 
> don't care what
> > type of links they are as it shouldn't matter.
> > 
> > A SG receives an SS7 message and relays it to some node in the IP
> > network.
> > 
> > Jeff
> > 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jeff,
> > >
> > > If the SG is connected to the network with A-links, E-links or
> > > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > > an STP model would rule out many non-quasi-associated (F-link
> > > connected) networks in places such as Europe.
> > >
> > > --Brian
> > >
> > > Jeff Copley wrote:                           (Mon, 30 Jul 
> 2001 14:59:22)
> > > > Klaus,
> > > >
> > > > I agree with you that the discussions are getting increasingly
> > > > confusing.  This multiple networks business is getting 
> increasingly
> > > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > > connects to multiple networks with no problems, so this 
> must not be the
> > > > problem trying to be solved.
> > > >
> > > > Given the above thought, I go to the next thought which 
> is that perhaps
> > > > an attempt is being made to make the SG(STP) appear as 
> if it belongs to
> > > > different networks rather than just one.  In such a 
> case, the SG(STP)
> > > > would need to have a multiple unique point code for 
> identifying itself,
> > > > one for each network that it belongs to.  In such a case, if I'm
> > > > forwarding a message to some other element such as an 
> ASP, then I would
> > > > need something like an NA to represent each SS7 network 
> to the ASPs.
> > > > Doing this though would be a pain in the .... thought processs.
> > > >
> > > > Jeff
> > > >
> > > >
> > > > "Gradischnig, Klaus" wrote:
> > > > >
> > > > > All:
> > > > >
> > > > > I am getting increasingly confused by this discussion 
> on NA. However, just
> > > > > looking at its definition in M3UA08 alone would be 
> enough to do the job:
> > > > >
> > > > > "Network Appearance - The Network Appearance uniquely 
> identifies an SS7
> > > > > entity (Point Code) into an SS7 network, as presented 
> by the SG.  It is
> > > > > used for the purposes of logically separating the 
> signalling traffic
> > > > > between the SG and the Application Server Processes 
> over a common SCTP
> > > > > association.  This partitioning is necessary where an 
> SG is logically
> > > > > partitioned to appear as end node elements in 
> multiple separate SS7
> > > > >                                               
> ^^^^^^^^^^^^^^^^^^^^^
> > > > > networks, in which case there is a separate network 
> appearance for each
> > > > > ^^^^^^^^                         
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > point code in the SS7 networks.  It is also necessary 
> when an SG is
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > [KDG] This clearly says to me that I need an NA if 
> and only if I have
> > > > > multiple networks. In this case I need an NA for 
> every point code,
> > however.
> > > > > Why I would need this in the case of multiple 
> networks only beats me.
> > [KDG]
> > > > >
> > > > > configured as an STP hosting multiple point codes, or 
> when configured
> > > > > as multiple end nodes within the same network, in 
> which case each point
> > > > > code is a separate network appearance.between the SG and the
> > > > > Application Server Processes over a common SCTP 
> Association.  An
> > > > > example is where an SG is logically partitioned to 
> appear as an element
> > > > > in four separate national SS7 networks.  A Network Appearance
> > > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > > implicitly defines the SS7 Point Code(s), Network 
> Indicator and MTP3
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > protocol type/variant/version used within a separate 
> SS7 network.
> > > > >
> > > > > [KDG] In contrast, this last sentence now tells me 
> that I need one and
> > only
> > > > > one
> > > > > NA for each network. This is at least something I 
> understand and it
> > > > > corresponds
> > > > > to NA's original definition. [KDG]"
> > > > >
> > > > > And while I can see where Brian's example below is 
> coming from, I can't
> > > > > except his arguments:
> > > > > In the general case OPC specific screening cannot be 
> handled by MTP
> > > > > network/route management functions and therefore OPC 
> specific routing
> > cannot
> > > > > be supported without restrictions to either 
> connectivity or network
> > > > > management functionality. The example might start 
> making sense if the SG
> > > > > considered 5.255.3 and 5.255.4 to belong to 
> "separate" networks using
> > > > > different routing tables in the SG. In this case the 
> SG may have to have
> > > > > distinct point codes in these "separate" networks, 
> provided then
> > "separate"
> > > > > networks are actually interconnected (seems not to be 
> the case in this
> > > > > example, though).
> > > > > In any case, I fully support John's and Barry's view 
> that NA identifies a
> > > > > network (albeit from an SG internal view) and not an SPMC.
> > > > >
> > > > > I am -- on an abstract level -- rather concerned 
> about the unnecessary
> > > > > complexity which has been introduced into m3ua and I 
> have some indication
> > > > > that a number of operators and manufacturers share 
> this view. How much of
> > > > > m3ua's functionality has actually been tested in 
> Sophia? It seems to me
> > that
> > > > > without some extensive testing in a real or emulated 
> SS7 network
> > environment
> > > > > going for last call is premature.
> > > > >
> > > > > Klaus
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: July 30, 2001 1:09 PM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Please see response inline...
> > > > > >
> > > > > > John Schantz wrote:                               (Mon, 30
> > > > > > Jul 2001 09:24:56)
> > > > > > > Brian,
> > > > > > >
> > > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > > single network
> > > > > > > appearance is needed per network connection.
> > > > > > >
> > > > > > >     More comments below.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Perhaps now you can see (from our discussion on 
> the thread "M3UA:
> > > > > > > Routing Context") that to cover all configurations, a
> > > > > > Network Appearance
> > > > > > > valud is required per primary point code and network id,
> > > > > > and that this
> > > > > > > proposal was a natural extension of that fact.  Consider
> > > > > > the case below:
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >                            200.1.4    __________
> > > > > >                              ___     /          \     ___
> > > > > >                             /   \   |            |   /   \
> > > > > >                            | SEP 
> |__|____________|__| SEP |  AS1
> > > > > >                             \___/   |            |   \___/
> > > > > >                            //       |            |
> > > > > >                           / |       | Signalling |  5.255.3
> > > > > >                          / /        |   Gateway  |
> > > > > >                         /  |        |            |
> > > > > >                        /  /         |            |
> > > > > >                _____  /   |         |            |
> > > > > >               |     |/   /          |            |
> > > > > >          -----| STP |____|__________|______      |
> > > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > > >             /    |      |           |          \_|_   ___
> > > > > >          \ /     |     /            |            | \ /   \
> > > > > >           X      |     |            |            |  
> | SEP |  AS2
> > > > > >          / \     |    /             |           _|_/ \___/
> > > > > >             \  __|__ /              |       ___/ |
> > > > > >              \|     |_______________|______/     |  
>      5.255.5
> > > > > >          -----| STP |               |            |  
>      (alias)
> > > > > >               |_____|               |            |
> > > > > >                                     |            |
> > > > > >                                      \__________/
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > The signalling gateway needs two different 
> Network Appearance
> > > > > > > parameters: one per SPMC.  The bottom SPMC needs 
> only one Network
> > > > > > > Appearance to cover both the primary point code 
> 5.255.4 and
> > > > > > the alias
> > > > > > > point code 5.255.5 because they are both treated as the
> > > > > > same from an SS7
> > > > > > > newtork management view.
> > > > > > >
> > > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > > figure above, NO
> > > > > > > network appearance is needed at all.  What do you 
> think the
> > > > > > point code is
> > > > > > > for??????  You seem to proposing that the network
> > > > > > appearance replace the
> > > > > > > point code for routing, NO.
> > > > > >
> > > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > > and entire SEP in
> > > > > > the diagram as labelled.  They are served over 1 association
> > > > > > to an ASP which
> > > > > > is configured and active for both ASs.  When the 
> F-link fails
> > > > > > from the SG to
> > > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > > Without something
> > > > > > (Routing Context/Network Appearance) to distinguish 
> the DUNA,
> > > > > > AS2 will also
> > > > > > process the DUNA(200.1.4).  Yet, AS2 still has a 
> route to SEP
> > > > > > 200.1.4 via
> > > > > > the STPs.
> > > > > >
> > > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > > traffic from AS1
> > > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > > may throw these
> > > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > > only point codes
> > > > > > allowed in the OPC on messages on the A-links.
> > > > > >
> > > > > > So, again, there are two choices:  Make Network 
> Appearance an
> > > > > > identifier
> > > > > > of the SPMC and include it on all DUNA/DAVA/etc. 
> where the ASP servers
> > > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > > >
> > > > > > >
> > > > > > > Now, in general, a rational basis for assigning Network
> > > > > > Apearance Id's
> > > > > > > is to use the Network Id and Point Code of the node (the
> > > > > > node *is* the
> > > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > > the SG sends
> > > > > > > concerning the SPMC will be properly distinguish.
> > > > > > >
> > > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > > affected point
> > > > > > > code is all that is needed.
> > > > > > >
> > > > > > > Note that if the proposed assignment of Network 
> Appearances is used,
> > > > > > > the SCON message no longer requires a Concerned 
> Point Code parameter
> > > > > > > when the SPMC is signalling congestion to the SG. 
>  It need only use
> > > > > > > the Network Appearance.
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > > > The definition of a Network Appearance becomes
> > > > > > (effectively): "An unique
> > > > > > > identifier indicating the Signalling Point Management
> > > > > > Cluster (SPMC) to
> > > > > > > which Signalling Network Management Messages apply."
> > > > > > >
> > > > > > > [John]  NO.
> > > > > > >
> > > > > > > --Brian
> > > > > > >
> > > > > > >
> > > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > > 2001 13:37:00)
> > > > > > > > Brian,
> > > > > > > >
> > > > > > > >   Why the need to include a concerned PC at 
> all, the PC would be
> > > > > > > > redundant to the one in the DPC.  Why not let 
> the network
> > > > > > appearance
> > > > > > > > parameter be equal to the Network ID (all 32 
> bits).  Then Network
> > > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > > separate out the
> > > > > > > > traffic into networks in both directions SG->AS and
> > > > > > AS->SG(-> and beyond).
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > > To: sigtran
> > > > > > > > Cc: Greg Sidebottom
> > > > > > > > Subject: M3UA07: Network Appearance
> > > > > > > >
> > > > > > > >
> > > > > > > > Greg,
> > > > > > > >
> > > > > > > > When an SG is has multiple point codes serving 
> ASPs which are
> > > > > > > > active in multiple SPMCs, it becomes necessary 
> to label each
> > > > > > > > SPMC with a unique Network Appearance parameter 
> to demultiplex
> > > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate 
> Network Appearance
> > > > > > > > assignment is necessary for each SPMC and the 
> adminstration of
> > > > > > > > these assignments could get quite tedious for 
> an SGP/ASP pool
> > > > > > > > representing a large number of point codes, I 
> would like to
> > > > > > > > propose the following refinement to the Network 
> Appearance
> > > > > > > > Parameter:
> > > > > > > >
> > > > > > > > (This is in fitting with the definition that a 
> "Network Appearance
> > > > > > > uniquely
> > > > > > > > identifies an SS7 entity (Point Code) into an 
> SS7 network.")
> > > > > > > >
> > > > > > > > The format of the Network Appearance 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
> > > > > > > >
> > > > > > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >    |  Network Id   |            Concerned Point Code
> > > > > >          |
> > > > > > > >
> > > > > > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >
> > > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > > >
> > > > > > > >    The Network Identifier identifies the 
> network in which
> > > > > > the Concerned
> > > > > > > >    Point Code can be considered unique, and 
> distinguishes
> > > > > > this Concerned
> > > > > > > >    Point Code from an identical point code in 
> any another network.
> > > > > > > >    A Network Identifier identifying a specific
> > > > > > adminsitrative domain for
> > > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > > global to all
> > > > > > > >    SGPs in an SG.
> > > > > > > >
> > > > > > > > Concerned Point Code:
> > > > > > > >
> > > > > > > >    The Concerned Point Code identifies a point 
> code within the
> > > > > > > >    administrative domain as indicated by the Network
> > > > > > Identifier.  The
> > > > > > > >    Concerned Point Code is the one point code of a
> > > > > > Signalling Point
> > > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > > updates concerning
> > > > > > > >    the accessibility/restriction/congestion status of
> > > > > > routesets from the
> > > > > > > >    SPMC.
> > > > > > > >
> > > > > > > >
> > > > > > > > Comments?
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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]
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > > >
> > > > > > --
> > > > > > 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]
> > > Content-Description: Card for Jeff Copley
> > > > begin:vcard
> > > > n:Copley;Jeff
> > > > tel;work:972.519.3758
> > > > x-mozilla-html:FALSE
> > > > org:Alcatel USA, Inc.
> > > > version:2.1
> > > > email;internet:[email-masked]
> > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > NSGAP;Plano;Texas;75075-5813;USA
> > > > x-mozilla-cpt:;20864
> > > > fn:Jeff Copley
> > > > end:vcard
> > > >
> > > >
> > > >
> > >
> > > Content-Description: footer
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
> > [email-masked]
> > >
> > > --
> > > 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]
Date: Tue, 31 Jul 2001 09:39:43 -0700
From: Ajit Sadarangani <[email-masked]>
Subject: Re: unsubscribe sigtran
To: "sigtran" <[email-masked]>
Organization: Telesys Software
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
X-SMTP-HELO: snfc21.pbi.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mta5.snfc21.pbi.net [206.13.28.241]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ajit Sadarangani wrote:

> rudra wrote:
>
> >   ---
> > 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]

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\ajits.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 31 Jul 2001 12:07:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      MAA22723
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jeff,

Are you proposing that we strike SUA as a work item?  In that case M3UA is
going to need a lot more "stuff" to fully support all classes of SCCP
operation.

ISUP is trivial.  If circuits are kept together by SLS or CIC there is not
much to worry about.  Besides ISUP only requires a loadsharing scheme not a
routing scheme.  SCCP requires both.

--Brian

Jeff Copley wrote:                                           (Tue, 31 Jul
2001 10:46:56)
> Greg and Brian,
> 
> M3UA is supposed to support the upper layers of SS7.  If I needed both
> ISUP and SCCP between two destinations, why would I want to develop a
> second UA such as SUA when M3UA (or M2PA) can acheive this in just one
> UA.  Am I missing something obvious? (It wouldn't be the first time.)
> 
> Jeff
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Greg,
> > 
> > Please see comments inline...
> > 
> > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001 00:47:44)
> > > Hi Brian,
> > >
> > > Responses below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Cc: "Greg Sidebottom" <[email-masked]>
> > > Sent: Monday, July 30, 2001 11:17 AM
> > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > >
> > >
> > > Greg,
> > >
> > > I don't see that rational basis on which M3UA can apply routing keys
> > > based on SCCP Subsystem number.  Can someone provide an example on
just
> > > how this was expected to work?  (Particularly how SCCP Management is
> > > handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> > > here.
> > >
> > > [Greg] I'll try and remember but this is from a while ago.  I think
there
> > > are valid cases where an MGC supports both ISUP and TCAP (lets say for
CCBS
> > > or the CLASS equivalent service).  While I'd agree that SUA is
probably a
> > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the
ISUP
> > > traffic already and it seems a lot of overhead to also support SUA and
> > > another SCTP association just for the TCAP traffic. ...
> > 
> > Several comments here:
> > 
> > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > restricted case, very minimal functionality from SUA is required
> > (perhaps only class 0 operation), all all the ASP management functions
> > are very close, really all that is required is supporting different
> > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > operation SUA has no more overhead that M3UA and there is a lot of
> > common parts.
> > 
> > Quite frankly all that SUA needs to do is support two messages (XFER
> > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > without GT is really close to "bare" MTP and SUA handles this as the
> > trivial case.
> > 
> > Perhaps you are looking at things backwards:  perhasp it is SUA which
> > should provide the functionality of MTP (as a pass-through to the lower
> > layer by shunting just a teeny bit of class 0), rather than M3UA
> > attempting to provide the functionality of SCCP (by loading SS7 SCCP
> > procedures into the M3UA at the SG).  Don't place SCCP functionality
> > into M3UA (above the MTP user interface)--allow SUA to pass-down to MTP.
> > This keeps SS7 functionality in the SS7 layers and UA functionality in
> > the UA layers.
> > 
> > Nevertheless, it is not necessary to have multiple associations.  UA
> > peers can be multiplexed over the same association by Payload Protocol
> > Identifier.  See the thread "Multiple UAs per Association".
> > 
> > The simple example of CLASS belies the fact that the normal switch has
> > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> > types of transaction which the switch needs to do also require
> > conversations, both class 0 and 1 support, and interworking support on
> > UDT/XUDT/LUDT, correlation of conversations, ...
> > 
> > > ... So a RK could be used
> > > to direct SCCP traffic for this service to an active MGC.
> > 
> > This traffic can be routed on SI without SSN.  Unless you are
> > considering some type of Global Title lookup as well, the SSN will not
> > tell you where the subscriber data is (which AS to use).  Although
> > splitting traffic into ISUP and SCCP traffic makes sense, splitting SCCP
> > traffic by SSN does not, particularly in the case of CLASS-like services
> > where all queries are against a GT which reflects subscriber
> > information.  The SSN traffic will need to be split further (somewhere)
> > for redundancy, so why do this?  Why not just loadshare all SCCP traffic
> > by SLS and perform the SCCP functions at the ASP?  SLS (extended by CIC)
> > is the only rational basis for loadsharing in M3UA, anyway.
> > 
> > > I assume that
> > > SCCP management is not perfect but it is probably not used completely
anyway
> > > for these end-node to end-node services because SCCP management will
> > > probably not be concerned about the subsystem state of all the
possible CCBS
> > > peers (or support traffic Mix procedures or SOR/SOG for that matter).
> > 
> > Again, this belies the fact that these switches also have LNP dips to
> > perform which requires close monitoring of subsystem availability (the
> > status of the LNP database from the MGC).  Also, switches normally do
> > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention
> > the requirements of an MSC).
> > 
> > > I'm
> > > not sure why OMAP SRVT would be an issue yet.  In any case, for the
SSN RK
> > > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't
used in
> > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks,
as far
> > > as I've seen anyway.
> > 
> > You may have never noticed it.  An SG/MGC must be able to respond to the
> > message.
> > 
> > >
> > > Another case I have also seen is where M3UA is used from an SG to a
> > > database, but the SG didn't support SUA yet.  So the SG makes up for
this by
> > > handling all the SCCP management on behalf of the database, at least
those
> > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).
> > 
> > At the rate we are going SUA may beat M3UA to proposed standard.  It may
> > be the other way around: the MGC has SUA but no M3UA yet and must use
> > the services of SUA to provide M3UA.  As I noted, all that SUA needs to
> > provide M3UA service as well is a DUPU and XFER message.
> > 
> > >
> > > But I don't really want to get into a long discussion of how these
cases can
> > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs
from a
> > > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > > prevent anyone from trying the above applications.  There is to me a
> > > difference between saying that the RK parameter in a REG REQ doesn't
have a
> > > certain sub-parameter and saying RKs cannot use certain information.
Any RK
> > > you want to dream up is possible, its just that it may not be able to
> > > configure it dynamically.  Of course not all RK permutations make
sense for
> > > a given application/architecture so people need to be careful of their
> > > dreams.
> > 
> > I think we need to draw a line here somewhere.  Otherwise, why not try
> > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try to
> > do TCAP with M3UA?  These "experiments" are deviations from the
> > fundamental SIGTRAN architecture--the stuff of reasearch.  For the sake
> > of interoperability, the architecture needs to be adhered to and
> > functional demarcations drawn.  Otherwise an ASP implementation will
> > never know what to expect from an SG implementation an visa versa.
> > 
> > If the sake of M3UA is not interoperability between different SG and AS
> > implementations, why is the spec being written?  A vendor can do
> > whatever they want within their own architecture now anyway.
> > 
> > >
> > >
> > >
> > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > message.
> > >
> > > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > > although there is no field for it in a REG REQ.  Distributing messages
> > > based on TCAP Transaction Ids doesn't strike me as rational either.
> > > I think you need TUA here.
> > >
> > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > applications/architectures.   TRIDS are not in the REG REQ but like I
said
> > > above I don't see this as an impediment to an SG configuring them in
an RK-
> > > they just couldn't be dynamically registered.  I think way back some
people
> > > were thinking of using the TRID ranges as a way of ensuring that the
> > > responses get back to the right originating ASPs.  I haven't studied
the SUA
> > > recently enough to know if this is still an issue though.
> > 
> > M3UA can provide the service TCAP requires (via SCCP) by loadsharing on
SLS.
> > The TCAP transaction Id coming off the SS7 network has no bearing on
> > anything and is not even unique unless it is taken into context with the
> > complete SCCP Calling Part Address (including Global Title).  The
> > Transaction Id is local to the exchange betwen two TC-entities and does
> > need not even be unique by SSN.  AIN, for example, uses Global Title in
> > the Calling and Called Party addresses to determine the TC-entity.  This
> > includes Transation Type and Address.  Correlation Ids in conversations
> > are next to impossible to attempt to handle in this fashion.
> > 
> > Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA
> > here.  If that is the approach the WG wants to take, why not smash all
> > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > 
> > >
> > > I don't mind removing TRID as an example if it causes any confusion -
as
> > > long as there is no restriction on the Routing Key in the SG.  If
there are
> > > future applications to include field "xyz" in a Routing Key then I
don't
> > > think its not the role of the M3UA to say that it cannot be done.
> > 
> > I disagree.  I believe that M3UA should be constrained to the SIGTRAN
> > architecture and not try to skip upwards in protocol level.  I believe
> > that there would be more value in skipping downwards from SUA to MTP
> > than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> > believe that the line should be drawn.
> > 
> > I believe that the same is true for ISUP.  CIC ranges have no place in
> > the Routing Key.  I believe that M3UA should consider them an "extended"
> > SLS for loadsharing, but routing on them makes no sense.
> > 
> > --Brian
> > 
> > >
> > > Cheers,
> > >
> > >    Greg
> > >
> > >
> > >
> > >
> > >
> > > I propose that we strike TCAP Transaction Id from the examples of
> > > Routing Keys.
> > >
> > > --Brian
> > >
> > > --
> > > 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 ¦
> > >
> > >
> > > ---
> > > 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]
> > 
> > --
> > 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] Content-Description: Card for
Jeff Copley
> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard

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

-- 
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]
Date: Tue, 31 Jul 2001 12:11:57 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA: SCCP Message Priority
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

See the related thread "SCCP Message Priority" (without the "SUA: ").

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
14:42:02)
> Hi all,
> 
> What's wrong with just using the importance parameter in SUA, and derive
the
> ANSI SCCP Message Priority/ITU SCCP Importance value from that ? This MP
> addition seems a little overkill to me.
> 
> Regards,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: maandag 23 juli 2001 21:11
> To: sigtran
> Cc: John Loughney
> Subject: Re: SUA: SCCP Message Priority
> 
> 
> Ray,
> 
> Doesn't look like it.  It seems that we need to add a priority bit
> somewhere.  If for no other reason than to support ANSI (and other)
> TCAP Conversation.  Maybe in the Flags parameter.  SLS takes up 5
> bits of 8.  Importance takes up 3 of 8.  How about the top nibble of
> importance, such as:
> 
> 
> < 3.9.1  Flags
> < 
> <    The Flags parameter is a conglomerate of following parameters,
> <    described in ITU-T Recommendation Q.713 :
> < 
> <       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
> <      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> <      |         Tag = 0x0101          |             Length = 8        |
> <      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> <      | Seq. Control  | MP|Importance |  Hop Counter  |  Protocol Cl. |
> <      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> <
> <  Message Priority/Importance
> <
> <  Importance (3.19/Q.713)
> <
> <  Bits 1-3 are coded to indicate the importance of the messages. The
> <  values are between 0 and 7, where the value of 0 indicates the least
> <  important and 7 indicates the most important.
> <
> <  Bits 4-6 are spare bits and should be coded zero.
> <
> <  Message Priority (T1.111.4/Table B4)
> <
> <  Bits 7-8 are coded to indicate the message priority of the message in
> <  networks which support mutliple congestion level with message priority.
> <  The values are between 0 and 2, where the value of 0 indicates the
> <  lowest priority and 2 indicates the most important.
> 
> 
> [email-masked] wrote:                          (Mon, 23 Jul 2001
> 14:01:56)
> >
> > Hi,
> > 
> > Could someone please clarify whether SUA would allow ANSI message
priority
> > values to be conveyed between peer SUA/SUA Users.
> > 
> > Thanks
> > Ray
> > 
> 
> -- 
> 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]

-- 
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]
Date: Tue, 31 Jul 2001 12:21:57 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Howard,

Welcom to the discussion...

May, Howard wrote:                                           (Tue, 31 Jul
2001 17:22:21)
>
> I believe it is fair to say that a requirement to differentiate between
PCs
> in different networks exists.  I also believe that the NA does this well.
I
> also believe that the M3UA07 definition of NA does more than just this....
> 
> If the SG has multiple PC appearances into the same network (no comment on
> why you would want to do this) then the NA differentiates between these.
> E.G. The SG connects to one network but has two point codes in the network
> (perhaps one linkset per point code)
>

Others are arguing that this is an inappropriate use of Network Appearance
and that the Network Appearance should just provide the former.

> 
> So the question I am asking is is there really a requirement to know the
PC
> a message arrived at?  What would we do with the information?

Yes.  The SPMC would know that the message/indication is address to it.

> 
> Taking this a little further it could be asked whether we want to know not
> only which PC a message arrived at at the SG, but which link set it
arrived
> at...

That would be M3PA, not M3UA.

> 
> Lets say we have an SG in a single network.  Lets say the SG has one PC
and
> connects to two STPs (one link set to each STP).  If we have a network
> appearance per link-set then an ASP can know which link-set and hence
which
> STP a message came from.  This allows more flexible routing to be
employed.

If a single SPMC has multiple network access points, it is the SG's
responsibility to indicate overall signalling point availability to the
SPMC.  There is no need to identify linkset.  The problems only come up
where there are multiple SPMCs, each with their own network access.

> 
> I know that in a perfect SS7 world there is no reason to onward route
> messages differently based on just the route they took to get to you.  I
> also know this is not a perfect world ..
> 
> Do you think having a NA per link-set simplifies the concept?  The NA
> definition would boil down to something as simple as
> 'The Network Appearance uniquely identifies the link-set a message arrived
> at etc etc'

Really, it is an NA (or whatever) per SPMC.  SPMC can easily be uniquely
identified by a Network Id and a Point Code.  Thus the several proposals to
make the Network Appearance a  combination of the two and make its
management and assignment trivial.

> 
> Do you think there is a requirement to know this kind of information?

No, I don't believe so.  The SG hides the link set differences from a single
SPMC, it is just that it has to treat SPMCs as independent from one another
when there are different network attachments.

--Brian

> 
> 
> > -----Original Message-----
> > From: Jeff Copley [mailto:[email-masked]]
> > Sent: 31 July 2001 16:21
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> > 
> > 
> > Dan,
> > 
> > I can see your point, which is similar to mine (making the SG 
> > appear as
> > a member in different networks).  In either scenario, it 
> > seems the goal
> > is to associate messages with a specific network when communicating
> > between the SG and the ASP.  The purpose of which is to support
> > different network protocol variants?
> > 
> > Jeff
> > 
> > Dan Brendes wrote:
> > > 
> > > I was under the impression that the purpose of the network 
> > appearance was to be
> > > able to differentiate a point code in some network (such as 
> > an ITUN point code
> > > of 100 in an Italian national network) from some other 
> > instance of that point
> > > code in a different network.  By including the network 
> > appearance as optional
> > > parameters in Data and DUNA/DAVA/etc messages it provides a 
> > way to distinguish
> > > the Italian ITUN pc = 100 from the German ITUN pc =100, and 
> > so on.  Thats all it
> > > is.  Nothing more.
> > > 
> > > The network appearance is a locally administered value at 
> > the SG that must be
> > > shared with the ASP(s) only for those situations where the 
> > SG is connected to
> > > multiple networks.
> > > 
> > > Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
> > > 
> > > Please respond to [email-masked]
> > > 
> > > To:   "sigtran" <[email-masked]>
> > > cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> > > Subject:  Re: M3UA07: Network Appearance
> > > 
> > > Brian,
> > > 
> > > I see an SG as receiving many SS7 links from the network 
> > and packaging
> > > the SS7 user for delivery into the IP network.  I really 
> > don't care what
> > > type of links they are as it shouldn't matter.
> > > 
> > > A SG receives an SS7 message and relays it to some node in the IP
> > > network.
> > > 
> > > Jeff
> > > 
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jeff,
> > > >
> > > > If the SG is connected to the network with A-links, E-links or
> > > > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > > > an STP model would rule out many non-quasi-associated (F-link
> > > > connected) networks in places such as Europe.
> > > >
> > > > --Brian
> > > >
> > > > Jeff Copley wrote:                           (Mon, 30 Jul 
> > 2001 14:59:22)
> > > > > Klaus,
> > > > >
> > > > > I agree with you that the discussions are getting increasingly
> > > > > confusing.  This multiple networks business is getting 
> > increasingly
> > > > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > > > connects to multiple networks with no problems, so this 
> > must not be the
> > > > > problem trying to be solved.
> > > > >
> > > > > Given the above thought, I go to the next thought which 
> > is that perhaps
> > > > > an attempt is being made to make the SG(STP) appear as 
> > if it belongs to
> > > > > different networks rather than just one.  In such a 
> > case, the SG(STP)
> > > > > would need to have a multiple unique point code for 
> > identifying itself,
> > > > > one for each network that it belongs to.  In such a case, if I'm
> > > > > forwarding a message to some other element such as an 
> > ASP, then I would
> > > > > need something like an NA to represent each SS7 network 
> > to the ASPs.
> > > > > Doing this though would be a pain in the .... thought processs.
> > > > >
> > > > > Jeff
> > > > >
> > > > >
> > > > > "Gradischnig, Klaus" wrote:
> > > > > >
> > > > > > All:
> > > > > >
> > > > > > I am getting increasingly confused by this discussion 
> > on NA. However, just
> > > > > > looking at its definition in M3UA08 alone would be 
> > enough to do the job:
> > > > > >
> > > > > > "Network Appearance - The Network Appearance uniquely 
> > identifies an SS7
> > > > > > entity (Point Code) into an SS7 network, as presented 
> > by the SG.  It is
> > > > > > used for the purposes of logically separating the 
> > signalling traffic
> > > > > > between the SG and the Application Server Processes 
> > over a common SCTP
> > > > > > association.  This partitioning is necessary where an 
> > SG is logically
> > > > > > partitioned to appear as end node elements in 
> > multiple separate SS7
> > > > > >                                               
> > ^^^^^^^^^^^^^^^^^^^^^
> > > > > > networks, in which case there is a separate network 
> > appearance for each
> > > > > > ^^^^^^^^                         
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > point code in the SS7 networks.  It is also necessary 
> > when an SG is
> > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > [KDG] This clearly says to me that I need an NA if 
> > and only if I have
> > > > > > multiple networks. In this case I need an NA for 
> > every point code,
> > > however.
> > > > > > Why I would need this in the case of multiple 
> > networks only beats me.
> > > [KDG]
> > > > > >
> > > > > > configured as an STP hosting multiple point codes, or 
> > when configured
> > > > > > as multiple end nodes within the same network, in 
> > which case each point
> > > > > > code is a separate network appearance.between the SG and the
> > > > > > Application Server Processes over a common SCTP 
> > Association.  An
> > > > > > example is where an SG is logically partitioned to 
> > appear as an element
> > > > > > in four separate national SS7 networks.  A Network Appearance
> > > > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > > > implicitly defines the SS7 Point Code(s), Network 
> > Indicator and MTP3
> > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > protocol type/variant/version used within a separate 
> > SS7 network.
> > > > > >
> > > > > > [KDG] In contrast, this last sentence now tells me 
> > that I need one and
> > > only
> > > > > > one
> > > > > > NA for each network. This is at least something I 
> > understand and it
> > > > > > corresponds
> > > > > > to NA's original definition. [KDG]"
> > > > > >
> > > > > > And while I can see where Brian's example below is 
> > coming from, I can't
> > > > > > except his arguments:
> > > > > > In the general case OPC specific screening cannot be 
> > handled by MTP
> > > > > > network/route management functions and therefore OPC 
> > specific routing
> > > cannot
> > > > > > be supported without restrictions to either 
> > connectivity or network
> > > > > > management functionality. The example might start 
> > making sense if the SG
> > > > > > considered 5.255.3 and 5.255.4 to belong to 
> > "separate" networks using
> > > > > > different routing tables in the SG. In this case the 
> > SG may have to have
> > > > > > distinct point codes in these "separate" networks, 
> > provided then
> > > "separate"
> > > > > > networks are actually interconnected (seems not to be 
> > the case in this
> > > > > > example, though).
> > > > > > In any case, I fully support John's and Barry's view 
> > that NA identifies a
> > > > > > network (albeit from an SG internal view) and not an SPMC.
> > > > > >
> > > > > > I am -- on an abstract level -- rather concerned 
> > about the unnecessary
> > > > > > complexity which has been introduced into m3ua and I 
> > have some indication
> > > > > > that a number of operators and manufacturers share 
> > this view. How much of
> > > > > > m3ua's functionality has actually been tested in 
> > Sophia? It seems to me
> > > that
> > > > > > without some extensive testing in a real or emulated 
> > SS7 network
> > > environment
> > > > > > going for last call is premature.
> > > > > >
> > > > > > Klaus
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: July 30, 2001 1:09 PM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Please see response inline...
> > > > > > >
> > > > > > > John Schantz wrote:                               (Mon, 30
> > > > > > > Jul 2001 09:24:56)
> > > > > > > > Brian,
> > > > > > > >
> > > > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > > > single network
> > > > > > > > appearance is needed per network connection.
> > > > > > > >
> > > > > > > >     More comments below.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > > > To: sigtran
> > > > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > > >
> > > > > > > >
> > > > > > > > John,
> > > > > > > >
> > > > > > > > Perhaps now you can see (from our discussion on 
> > the thread "M3UA:
> > > > > > > > Routing Context") that to cover all configurations, a
> > > > > > > Network Appearance
> > > > > > > > valud is required per primary point code and network id,
> > > > > > > and that this
> > > > > > > > proposal was a natural extension of that fact.  Consider
> > > > > > > the case below:
> > > > > > > >
> > > > > > > > [John] NO.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >                            200.1.4    __________
> > > > > > >                              ___     /          \     ___
> > > > > > >                             /   \   |            |   /   \
> > > > > > >                            | SEP 
> > |__|____________|__| SEP |  AS1
> > > > > > >                             \___/   |            |   \___/
> > > > > > >                            //       |            |
> > > > > > >                           / |       | Signalling |  5.255.3
> > > > > > >                          / /        |   Gateway  |
> > > > > > >                         /  |        |            |
> > > > > > >                        /  /         |            |
> > > > > > >                _____  /   |         |            |
> > > > > > >               |     |/   /          |            |
> > > > > > >          -----| STP |____|__________|______      |
> > > > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > > > >             /    |      |           |          \_|_   ___
> > > > > > >          \ /     |     /            |            | \ /   \
> > > > > > >           X      |     |            |            |  
> > | SEP |  AS2
> > > > > > >          / \     |    /             |           _|_/ \___/
> > > > > > >             \  __|__ /              |       ___/ |
> > > > > > >              \|     |_______________|______/     |  
> >      5.255.5
> > > > > > >          -----| STP |               |            |  
> >      (alias)
> > > > > > >               |_____|               |            |
> > > > > > >                                     |            |
> > > > > > >                                      \__________/
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > The signalling gateway needs two different 
> > Network Appearance
> > > > > > > > parameters: one per SPMC.  The bottom SPMC needs 
> > only one Network
> > > > > > > > Appearance to cover both the primary point code 
> > 5.255.4 and
> > > > > > > the alias
> > > > > > > > point code 5.255.5 because they are both treated as the
> > > > > > > same from an SS7
> > > > > > > > newtork management view.
> > > > > > > >
> > > > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > > > figure above, NO
> > > > > > > > network appearance is needed at all.  What do you 
> > think the
> > > > > > > point code is
> > > > > > > > for??????  You seem to proposing that the network
> > > > > > > appearance replace the
> > > > > > > > point code for routing, NO.
> > > > > > >
> > > > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > > > and entire SEP in
> > > > > > > the diagram as labelled.  They are served over 1 association
> > > > > > > to an ASP which
> > > > > > > is configured and active for both ASs.  When the 
> > F-link fails
> > > > > > > from the SG to
> > > > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > > > Without something
> > > > > > > (Routing Context/Network Appearance) to distinguish 
> > the DUNA,
> > > > > > > AS2 will also
> > > > > > > process the DUNA(200.1.4).  Yet, AS2 still has a 
> > route to SEP
> > > > > > > 200.1.4 via
> > > > > > > the STPs.
> > > > > > >
> > > > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > > > traffic from AS1
> > > > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > > > may throw these
> > > > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > > > only point codes
> > > > > > > allowed in the OPC on messages on the A-links.
> > > > > > >
> > > > > > > So, again, there are two choices:  Make Network 
> > Appearance an
> > > > > > > identifier
> > > > > > > of the SPMC and include it on all DUNA/DAVA/etc. 
> > where the ASP servers
> > > > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > > > >
> > > > > > > >
> > > > > > > > Now, in general, a rational basis for assigning Network
> > > > > > > Apearance Id's
> > > > > > > > is to use the Network Id and Point Code of the node (the
> > > > > > > node *is* the
> > > > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > > > the SG sends
> > > > > > > > concerning the SPMC will be properly distinguish.
> > > > > > > >
> > > > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > > > affected point
> > > > > > > > code is all that is needed.
> > > > > > > >
> > > > > > > > Note that if the proposed assignment of Network 
> > Appearances is used,
> > > > > > > > the SCON message no longer requires a Concerned 
> > Point Code parameter
> > > > > > > > when the SPMC is signalling congestion to the SG. 
> >  It need only use
> > > > > > > > the Network Appearance.
> > > > > > > >
> > > > > > > > [John] NO.
> > > > > > > >
> > > > > > > > The definition of a Network Appearance becomes
> > > > > > > (effectively): "An unique
> > > > > > > > identifier indicating the Signalling Point Management
> > > > > > > Cluster (SPMC) to
> > > > > > > > which Signalling Network Management Messages apply."
> > > > > > > >
> > > > > > > > [John]  NO.
> > > > > > > >
> > > > > > > > --Brian
> > > > > > > >
> > > > > > > >
> > > > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > > > 2001 13:37:00)
> > > > > > > > > Brian,
> > > > > > > > >
> > > > > > > > >   Why the need to include a concerned PC at 
> > all, the PC would be
> > > > > > > > > redundant to the one in the DPC.  Why not let 
> > the network
> > > > > > > appearance
> > > > > > > > > parameter be equal to the Network ID (all 32 
> > bits).  Then Network
> > > > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > > > separate out the
> > > > > > > > > traffic into networks in both directions SG->AS and
> > > > > > > AS->SG(-> and beyond).
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > > > To: sigtran
> > > > > > > > > Cc: Greg Sidebottom
> > > > > > > > > Subject: M3UA07: Network Appearance
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Greg,
> > > > > > > > >
> > > > > > > > > When an SG is has multiple point codes serving 
> > ASPs which are
> > > > > > > > > active in multiple SPMCs, it becomes necessary 
> > to label each
> > > > > > > > > SPMC with a unique Network Appearance parameter 
> > to demultiplex
> > > > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate 
> > Network Appearance
> > > > > > > > > assignment is necessary for each SPMC and the 
> > adminstration of
> > > > > > > > > these assignments could get quite tedious for 
> > an SGP/ASP pool
> > > > > > > > > representing a large number of point codes, I 
> > would like to
> > > > > > > > > propose the following refinement to the Network 
> > Appearance
> > > > > > > > > Parameter:
> > > > > > > > >
> > > > > > > > > (This is in fitting with the definition that a 
> > "Network Appearance
> > > > > > > > uniquely
> > > > > > > > > identifies an SS7 entity (Point Code) into an 
> > SS7 network.")
> > > > > > > > >
> > > > > > > > > The format of the Network Appearance 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
> > > > > > > > >
> > > > > > > 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > > >    |  Network Id   |            Concerned Point Code
> > > > > > >          |
> > > > > > > > >
> > > > > > > 
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > > >
> > > > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > > > >
> > > > > > > > >    The Network Identifier identifies the 
> > network in which
> > > > > > > the Concerned
> > > > > > > > >    Point Code can be considered unique, and 
> > distinguishes
> > > > > > > this Concerned
> > > > > > > > >    Point Code from an identical point code in 
> > any another network.
> > > > > > > > >    A Network Identifier identifying a specific
> > > > > > > adminsitrative domain for
> > > > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > > > global to all
> > > > > > > > >    SGPs in an SG.
> > > > > > > > >
> > > > > > > > > Concerned Point Code:
> > > > > > > > >
> > > > > > > > >    The Concerned Point Code identifies a point 
> > code within the
> > > > > > > > >    administrative domain as indicated by the Network
> > > > > > > Identifier.  The
> > > > > > > > >    Concerned Point Code is the one point code of a
> > > > > > > Signalling Point
> > > > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > > > updates concerning
> > > > > > > > >    the accessibility/restriction/congestion status of
> > > > > > > routesets from the
> > > > > > > > >    SPMC.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Comments?
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 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]
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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]
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > Content-Description: Card for Jeff Copley
> > > > > begin:vcard
> > > > > n:Copley;Jeff
> > > > > tel;work:972.519.3758
> > > > > x-mozilla-html:FALSE
> > > > > org:Alcatel USA, Inc.
> > > > > version:2.1
> > > > > email;internet:[email-masked]
> > > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > > NSGAP;Plano;Texas;75075-5813;USA
> > > > > x-mozilla-cpt:;20864
> > > > > fn:Jeff Copley
> > > > > end:vcard
> > > > >
> > > > >
> > > > >
> > > >
> > > > Content-Description: footer
> > > > > ---
> > > > > You are currently subscribed to sigtran as: [email-masked]
> > > > > To unsubscribe send a blank email to
> > > [email-masked]
> > > >
> > > > --
> > > > 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]

-- 
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]
X-Lotus-FromDomain: TEKELEC
From: Dan Brendes <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Tue, 31 Jul 2001 13:30:40 -0400
Subject: RE: M3UA07: Network Appearance
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [198.89.40.41]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"May, Howard" <[email-masked]> on 07/31/2001 12:22:21 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Dan
Brendes/Raleigh/TEKELEC) Subject:  RE: M3UA07: Network Appearance

I believe it is fair to say that a requirement to differentiate between PCs
in different networks exists.  I also believe that the NA does this well.  I
also believe that the M3UA07 definition of NA does more than just this....

If the SG has multiple PC appearances into the same network (no comment on
why you would want to do this) then the NA differentiates between these.
E.G. The SG connects to one network but has two point codes in the network
(perhaps one linkset per point code)

(danb) - how/why does NA differentiate the multiple PCs?  if there is just 1
network why do you need >1 network appearance?  For any PC that the SG is
acting as, the combination of PC + NA uniquely identifies the PC...the PC
itself may be reused in other networks...all PC in the same network use the
same NA.

So the question I am asking is is there really a requirement to know the PC
a message arrived at?  What would we do with the information?

Taking this a little further it could be asked whether we want to know not
only which PC a message arrived at at the SG, but which link set it arrived
at...

Lets say we have an SG in a single network.  Lets say the SG has one PC and
connects to two STPs (one link set to each STP).  If we have a network
appearance per link-set then an ASP can know which link-set and hence which
STP a message came from.  This allows more flexible routing to be employed.

I know that in a perfect SS7 world there is no reason to onward route
messages differently based on just the route they took to get to you.  I
also know this is not a perfect world ..

Do you think having a NA per link-set simplifies the concept?  The NA
definition would boil down to something as simple as 'The Network Appearance
uniquely identifies the link-set a message arrived at etc etc'

Do you think there is a requirement to know this kind of information?

(danb) no i don't.

> -----Original Message-----
> From: Jeff Copley [mailto:[email-masked]]
> Sent: 31 July 2001 16:21
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
>
>
> Dan,
>
> I can see your point, which is similar to mine (making the SG
> appear as
> a member in different networks).  In either scenario, it
> seems the goal
> is to associate messages with a specific network when communicating
> between the SG and the ASP.  The purpose of which is to support
> different network protocol variants?
>
> Jeff
>
> Dan Brendes wrote:
> >
> > I was under the impression that the purpose of the network
> appearance was to be
> > able to differentiate a point code in some network (such as
> an ITUN point code
> > of 100 in an Italian national network) from some other
> instance of that point
> > code in a different network.  By including the network
> appearance as optional
> > parameters in Data and DUNA/DAVA/etc messages it provides a
> way to distinguish
> > the Italian ITUN pc = 100 from the German ITUN pc =100, and
> so on.  Thats all it
> > is.  Nothing more.
> >
> > The network appearance is a locally administered value at
> the SG that must be
> > shared with the ASP(s) only for those situations where the
> SG is connected to
> > multiple networks.
> >
> > Jeff Copley <[email-masked]> on 07/30/2001 05:03:29 PM
> >
> > Please respond to [email-masked]
> >
> > To:   "sigtran" <[email-masked]>
> > cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
> > Subject:  Re: M3UA07: Network Appearance
> >
> > Brian,
> >
> > I see an SG as receiving many SS7 links from the network
> and packaging
> > the SS7 user for delivery into the IP network.  I really
> don't care what
> > type of links they are as it shouldn't matter.
> >
> > A SG receives an SS7 message and relays it to some node in the IP
> > network.
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jeff,
> > >
> > > If the SG is connected to the network with A-links, E-links or
> > > F-links, you cannot look at it as an STP.  Restricting M3UA to
> > > an STP model would rule out many non-quasi-associated (F-link
> > > connected) networks in places such as Europe.
> > >
> > > --Brian
> > >
> > > Jeff Copley wrote:                           (Mon, 30 Jul
> 2001 14:59:22)
> > > > Klaus,
> > > >
> > > > I agree with you that the discussions are getting increasingly
> > > > confusing.  This multiple networks business is getting
> increasingly
> > > > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > > > connects to multiple networks with no problems, so this
> must not be the
> > > > problem trying to be solved.
> > > >
> > > > Given the above thought, I go to the next thought which
> is that perhaps
> > > > an attempt is being made to make the SG(STP) appear as
> if it belongs to
> > > > different networks rather than just one.  In such a
> case, the SG(STP)
> > > > would need to have a multiple unique point code for
> identifying itself,
> > > > one for each network that it belongs to.  In such a case, if I'm
> > > > forwarding a message to some other element such as an
> ASP, then I would
> > > > need something like an NA to represent each SS7 network
> to the ASPs.
> > > > Doing this though would be a pain in the .... thought processs.
> > > >
> > > > Jeff
> > > >
> > > >
> > > > "Gradischnig, Klaus" wrote:
> > > > >
> > > > > All:
> > > > >
> > > > > I am getting increasingly confused by this discussion
> on NA. However, just
> > > > > looking at its definition in M3UA08 alone would be
> enough to do the job:
> > > > >
> > > > > "Network Appearance - The Network Appearance uniquely
> identifies an SS7
> > > > > entity (Point Code) into an SS7 network, as presented
> by the SG.  It is
> > > > > used for the purposes of logically separating the
> signalling traffic
> > > > > between the SG and the Application Server Processes
> over a common SCTP
> > > > > association.  This partitioning is necessary where an
> SG is logically
> > > > > partitioned to appear as end node elements in
> multiple separate SS7
> > > > >
> ^^^^^^^^^^^^^^^^^^^^^
> > > > > networks, in which case there is a separate network
> appearance for each
> > > > > ^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > point code in the SS7 networks.  It is also necessary
> when an SG is
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > [KDG] This clearly says to me that I need an NA if
> and only if I have
> > > > > multiple networks. In this case I need an NA for
> every point code,
> > however.
> > > > > Why I would need this in the case of multiple
> networks only beats me.
> > [KDG]
> > > > >
> > > > > configured as an STP hosting multiple point codes, or
> when configured
> > > > > as multiple end nodes within the same network, in
> which case each point
> > > > > code is a separate network appearance.between the SG and the
> > > > > Application Server Processes over a common SCTP
> Association.  An
> > > > > example is where an SG is logically partitioned to
> appear as an element
> > > > > in four separate national SS7 networks.  A Network Appearance
> > > > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > > > implicitly defines the SS7 Point Code(s), Network
> Indicator and MTP3
> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > protocol type/variant/version used within a separate
> SS7 network.
> > > > >
> > > > > [KDG] In contrast, this last sentence now tells me
> that I need one and
> > only
> > > > > one
> > > > > NA for each network. This is at least something I
> understand and it
> > > > > corresponds
> > > > > to NA's original definition. [KDG]"
> > > > >
> > > > > And while I can see where Brian's example below is
> coming from, I can't
> > > > > except his arguments:
> > > > > In the general case OPC specific screening cannot be
> handled by MTP
> > > > > network/route management functions and therefore OPC
> specific routing
> > cannot
> > > > > be supported without restrictions to either
> connectivity or network
> > > > > management functionality. The example might start
> making sense if the SG
> > > > > considered 5.255.3 and 5.255.4 to belong to
> "separate" networks using
> > > > > different routing tables in the SG. In this case the
> SG may have to have
> > > > > distinct point codes in these "separate" networks,
> provided then
> > "separate"
> > > > > networks are actually interconnected (seems not to be
> the case in this
> > > > > example, though).
> > > > > In any case, I fully support John's and Barry's view
> that NA identifies a
> > > > > network (albeit from an SG internal view) and not an SPMC.
> > > > >
> > > > > I am -- on an abstract level -- rather concerned
> about the unnecessary
> > > > > complexity which has been introduced into m3ua and I
> have some indication
> > > > > that a number of operators and manufacturers share
> this view. How much of
> > > > > m3ua's functionality has actually been tested in
> Sophia? It seems to me
> > that
> > > > > without some extensive testing in a real or emulated
> SS7 network
> > environment
> > > > > going for last call is premature.
> > > > >
> > > > > Klaus
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: July 30, 2001 1:09 PM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Please see response inline...
> > > > > >
> > > > > > John Schantz wrote:                               (Mon, 30
> > > > > > Jul 2001 09:24:56)
> > > > > > > Brian,
> > > > > > >
> > > > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > > > single network
> > > > > > > appearance is needed per network connection.
> > > > > > >
> > > > > > >     More comments below.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Perhaps now you can see (from our discussion on
> the thread "M3UA:
> > > > > > > Routing Context") that to cover all configurations, a
> > > > > > Network Appearance
> > > > > > > valud is required per primary point code and network id,
> > > > > > and that this
> > > > > > > proposal was a natural extension of that fact.  Consider
> > > > > > the case below:
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >                            200.1.4    __________
> > > > > >                              ___     /          \     ___
> > > > > >                             /   \   |            |   /   \
> > > > > >                            | SEP
> |__|____________|__| SEP |  AS1
> > > > > >                             \___/   |            |   \___/
> > > > > >                            //       |            |
> > > > > >                           / |       | Signalling |  5.255.3
> > > > > >                          / /        |   Gateway  |
> > > > > >                         /  |        |            |
> > > > > >                        /  /         |            |
> > > > > >                _____  /   |         |            |
> > > > > >               |     |/   /          |            |
> > > > > >          -----| STP |____|__________|______      |
> > > > > >              /|_____|   /           |      \___  |  5.255.4
> > > > > >             /    |      |           |          \_|_   ___
> > > > > >          \ /     |     /            |            | \ /   \
> > > > > >           X      |     |            |            |
> | SEP |  AS2
> > > > > >          / \     |    /             |           _|_/ \___/
> > > > > >             \  __|__ /              |       ___/ |
> > > > > >              \|     |_______________|______/     |
>      5.255.5
> > > > > >          -----| STP |               |            |
>      (alias)
> > > > > >               |_____|               |            |
> > > > > >                                     |            |
> > > > > >                                      \__________/
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > The signalling gateway needs two different
> Network Appearance
> > > > > > > parameters: one per SPMC.  The bottom SPMC needs
> only one Network
> > > > > > > Appearance to cover both the primary point code
> 5.255.4 and
> > > > > > the alias
> > > > > > > point code 5.255.5 because they are both treated as the
> > > > > > same from an SS7
> > > > > > > newtork management view.
> > > > > > >
> > > > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > > > figure above, NO
> > > > > > > network appearance is needed at all.  What do you
> think the
> > > > > > point code is
> > > > > > > for??????  You seem to proposing that the network
> > > > > > appearance replace the
> > > > > > > point code for routing, NO.
> > > > > >
> > > > > > John, say I have one ASP serving two ASs and each AS serves
> > > > > > and entire SEP in
> > > > > > the diagram as labelled.  They are served over 1 association
> > > > > > to an ASP which
> > > > > > is configured and active for both ASs.  When the
> F-link fails
> > > > > > from the SG to
> > > > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > > > Without something
> > > > > > (Routing Context/Network Appearance) to distinguish
> the DUNA,
> > > > > > AS2 will also
> > > > > > process the DUNA(200.1.4).  Yet, AS2 still has a
> route to SEP
> > > > > > 200.1.4 via
> > > > > > the STPs.
> > > > > >
> > > > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > > > traffic from AS1
> > > > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > > > may throw these
> > > > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > > > only point codes
> > > > > > allowed in the OPC on messages on the A-links.
> > > > > >
> > > > > > So, again, there are two choices:  Make Network
> Appearance an
> > > > > > identifier
> > > > > > of the SPMC and include it on all DUNA/DAVA/etc.
> where the ASP servers
> > > > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > > > >
> > > > > > >
> > > > > > > Now, in general, a rational basis for assigning Network
> > > > > > Apearance Id's
> > > > > > > is to use the Network Id and Point Code of the node (the
> > > > > > node *is* the
> > > > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > > > the SG sends
> > > > > > > concerning the SPMC will be properly distinguish.
> > > > > > >
> > > > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > > > affected point
> > > > > > > code is all that is needed.
> > > > > > >
> > > > > > > Note that if the proposed assignment of Network
> Appearances is used,
> > > > > > > the SCON message no longer requires a Concerned
> Point Code parameter
> > > > > > > when the SPMC is signalling congestion to the SG.
>  It need only use
> > > > > > > the Network Appearance.
> > > > > > >
> > > > > > > [John] NO.
> > > > > > >
> > > > > > > The definition of a Network Appearance becomes
> > > > > > (effectively): "An unique
> > > > > > > identifier indicating the Signalling Point Management
> > > > > > Cluster (SPMC) to
> > > > > > > which Signalling Network Management Messages apply."
> > > > > > >
> > > > > > > [John]  NO.
> > > > > > >
> > > > > > > --Brian
> > > > > > >
> > > > > > >
> > > > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > > > 2001 13:37:00)
> > > > > > > > Brian,
> > > > > > > >
> > > > > > > >   Why the need to include a concerned PC at
> all, the PC would be
> > > > > > > > redundant to the one in the DPC.  Why not let
> the network
> > > > > > appearance
> > > > > > > > parameter be equal to the Network ID (all 32
> bits).  Then Network
> > > > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > > > separate out the
> > > > > > > > traffic into networks in both directions SG->AS and
> > > > > > AS->SG(-> and beyond).
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > > > To: sigtran
> > > > > > > > Cc: Greg Sidebottom
> > > > > > > > Subject: M3UA07: Network Appearance
> > > > > > > >
> > > > > > > >
> > > > > > > > Greg,
> > > > > > > >
> > > > > > > > When an SG is has multiple point codes serving
> ASPs which are
> > > > > > > > active in multiple SPMCs, it becomes necessary
> to label each
> > > > > > > > SPMC with a unique Network Appearance parameter
> to demultiplex
> > > > > > > > DUNA, DAVA, DRST and SCON.  Because a separate
> Network Appearance
> > > > > > > > assignment is necessary for each SPMC and the
> adminstration of
> > > > > > > > these assignments could get quite tedious for
> an SGP/ASP pool
> > > > > > > > representing a large number of point codes, I
> would like to
> > > > > > > > propose the following refinement to the Network
> Appearance
> > > > > > > > Parameter:
> > > > > > > >
> > > > > > > > (This is in fitting with the definition that a
> "Network Appearance
> > > > > > > uniquely
> > > > > > > > identifies an SS7 entity (Point Code) into an
> SS7 network.")
> > > > > > > >
> > > > > > > > The format of the Network Appearance 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
> > > > > > > >
> > > > > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >    |  Network Id   |            Concerned Point Code
> > > > > >          |
> > > > > > > >
> > > > > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > > > >
> > > > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > > > >
> > > > > > > >    The Network Identifier identifies the
> network in which
> > > > > > the Concerned
> > > > > > > >    Point Code can be considered unique, and
> distinguishes
> > > > > > this Concerned
> > > > > > > >    Point Code from an identical point code in
> any another network.
> > > > > > > >    A Network Identifier identifying a specific
> > > > > > adminsitrative domain for
> > > > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > > > global to all
> > > > > > > >    SGPs in an SG.
> > > > > > > >
> > > > > > > > Concerned Point Code:
> > > > > > > >
> > > > > > > >    The Concerned Point Code identifies a point
> code within the
> > > > > > > >    administrative domain as indicated by the Network
> > > > > > Identifier.  The
> > > > > > > >    Concerned Point Code is the one point code of a
> > > > > > Signalling Point
> > > > > > > >    Management Cluster (SPMC) which needs to receive
> > > > > > updates concerning
> > > > > > > >    the accessibility/restriction/congestion status of
> > > > > > routesets from the
> > > > > > > >    SPMC.
> > > > > > > >
> > > > > > > >
> > > > > > > > Comments?
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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]
> > > > > > >
> > > > > > > --
> > > > > > > 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]
> > > > > >
> > > > > > --
> > > > > > 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]
> > > Content-Description: Card for Jeff Copley
> > > > begin:vcard
> > > > n:Copley;Jeff
> > > > tel;work:972.519.3758
> > > > x-mozilla-html:FALSE
> > > > org:Alcatel USA, Inc.
> > > > version:2.1
> > > > email;internet:[email-masked]
> > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > NSGAP;Plano;Texas;75075-5813;USA
> > > > x-mozilla-cpt:;20864
> > > > fn:Jeff Copley
> > > > end:vcard
> > > >
> > > >
> > > >
> > >
> > > Content-Description: footer
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
> > [email-masked]
> > >
> > > --
> > > 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]
Date: Tue, 31 Jul 2001 13:04:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UAv8: UPU and multiple SG/SGP configuration
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

I have noticed another difficulty.  User Part Flow control cannot feasibly
be performed by the SGs in multiple SG configuration and is difficult in
multiple SGP configurations.

Consider the following example:

                                                        _______  
                   _______                _______      /       \ 
                  |       |     RC1      |       |    |         |
      ____________|  SG   |______________|  ASP  |- - -   AS1   |
                  | (STP) |     A1      _|       |    |         |
                 /|_______|            / |_______|    |         |
                /     |               /                \_______/ 
               /      |              /                           
          \   /       |      Associations                        
           \ /        |            /                             
            X         |           /A2                            
           / \        |          /                               
          /   \       |         / RC1                            
               \      |        /                                 
                \  ___|___    /                                  
                 \|       |  /                                   
      ____________|  SG   |_/                                    
                  | (STP) |                                      
                  |_______|                                      

A routing key/context RC1 (consider 5.255.1/ISUP) from two SGs is sent to an
ASP servicing AS1.  The MTP layer at each SG are separately responsible for
User Part availability.  That is each SG must know when to send UPU.  But
the SG has no way of determining this without SG to SG communication.

That is, each SG should only send UPU(ISUP) when AS1 is inactive for both
SG.  Because the SG may lose communication with the ASP, and because the ASP
does not notify the SG of overall AS state, the SG cannot properly send UPU
unless they coordinate the response between them using some SG-to-SG
communication.

This should be highlighted in the draft for the multiple SG configuration.

This also has ramifications on multiple SGP configurations as well, where
the overall state of the User Part must be coordinated at MTP3.
Similar to the DRST case, the SGP must coordinate *beneath* the MTP to
MTP-User interface, making this a non-trivial implementation issue.

The draft speaks alot to the availability/restriction/congestion of
routesets to the ASP, but should in a like manner address the availability
of user parts to the SG.

--Brian

-- 
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]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Tue, 31 Jul 2001 11:42:06 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by rainier.illuminet.com
id 
                      LAA29595
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Jeff:

M3UA emulates the MTP level 3 layer.  It does not handle the SCCP functions.
Since, Sigtran is emulating the SS7 stack in IP then it would make sense to
develop another layer, SUA, to handle SCCP functionality.

If you want to do SS7 over IP without so many stacks, you can do what
Tekelec did and just do SS7 encapsulation over IP.  It works.  But then
again that would not be what Sigtran's goal is....

Kevin

-----Original Message-----
From: Jeff Copley [mailto:[email-masked]] Sent: Tuesday, July
31, 2001 10:47 AM
To: sigtran
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg and Brian,

M3UA is supposed to support the upper layers of SS7.  If I needed both ISUP
and SCCP between two destinations, why would I want to develop a second UA
such as SUA when M3UA (or M2PA) can acheive this in just one UA.  Am I
missing something obvious? (It wouldn't be the first time.)

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Greg,
> 
> Please see comments inline...
> 
> Greg Sidebottom wrote:                      (Tue, 31 Jul 2001 00:47:44)
> > Hi Brian,
> >
> > Responses below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: "Greg Sidebottom" <[email-masked]>
> > Sent: Monday, July 30, 2001 11:17 AM
> > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> >
> >
> > Greg,
> >
> > I don't see that rational basis on which M3UA can apply routing keys
> > based on SCCP Subsystem number.  Can someone provide an example on just
> > how this was expected to work?  (Particularly how SCCP Management is
> > handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> > here.
> >
> > [Greg] I'll try and remember but this is from a while ago.  I think
there
> > are valid cases where an MGC supports both ISUP and TCAP (lets say for
CCBS
> > or the CLASS equivalent service).  While I'd agree that SUA is probably
a
> > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the ISUP
> > traffic already and it seems a lot of overhead to also support SUA and
> > another SCTP association just for the TCAP traffic. ...
> 
> Several comments here:
> 
> "[I]t seems a lot of overhead to support SUA"--Actually, for this
> restricted case, very minimal functionality from SUA is required
> (perhaps only class 0 operation), all all the ASP management functions
> are very close, really all that is required is supporting different
> parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> operation SUA has no more overhead that M3UA and there is a lot of
> common parts.
> 
> Quite frankly all that SUA needs to do is support two messages (XFER
> and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> without GT is really close to "bare" MTP and SUA handles this as the
> trivial case.
> 
> Perhaps you are looking at things backwards:  perhasp it is SUA which
> should provide the functionality of MTP (as a pass-through to the lower
> layer by shunting just a teeny bit of class 0), rather than M3UA
> attempting to provide the functionality of SCCP (by loading SS7 SCCP
> procedures into the M3UA at the SG).  Don't place SCCP functionality
> into M3UA (above the MTP user interface)--allow SUA to pass-down to MTP.
> This keeps SS7 functionality in the SS7 layers and UA functionality in
> the UA layers.
> 
> Nevertheless, it is not necessary to have multiple associations.  UA
> peers can be multiplexed over the same association by Payload Protocol
> Identifier.  See the thread "Multiple UAs per Association".
> 
> The simple example of CLASS belies the fact that the normal switch has
> alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> types of transaction which the switch needs to do also require
> conversations, both class 0 and 1 support, and interworking support on
> UDT/XUDT/LUDT, correlation of conversations, ...
> 
> > ... So a RK could be used
> > to direct SCCP traffic for this service to an active MGC.
> 
> This traffic can be routed on SI without SSN.  Unless you are
> considering some type of Global Title lookup as well, the SSN will not
> tell you where the subscriber data is (which AS to use).  Although
> splitting traffic into ISUP and SCCP traffic makes sense, splitting SCCP
> traffic by SSN does not, particularly in the case of CLASS-like services
> where all queries are against a GT which reflects subscriber
> information.  The SSN traffic will need to be split further (somewhere)
> for redundancy, so why do this?  Why not just loadshare all SCCP traffic
> by SLS and perform the SCCP functions at the ASP?  SLS (extended by CIC)
> is the only rational basis for loadsharing in M3UA, anyway.
> 
> > I assume that
> > SCCP management is not perfect but it is probably not used completely
anyway
> > for these end-node to end-node services because SCCP management will
> > probably not be concerned about the subsystem state of all the possible
CCBS
> > peers (or support traffic Mix procedures or SOR/SOG for that matter).
> 
> Again, this belies the fact that these switches also have LNP dips to
> perform which requires close monitoring of subsystem availability (the
> status of the LNP database from the MGC).  Also, switches normally do
> perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention
> the requirements of an MSC).
> 
> > I'm
> > not sure why OMAP SRVT would be an issue yet.  In any case, for the SSN
RK
> > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't used
in
> > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks, as
far
> > as I've seen anyway.
> 
> You may have never noticed it.  An SG/MGC must be able to respond to the
> message.
> 
> >
> > Another case I have also seen is where M3UA is used from an SG to a
> > database, but the SG didn't support SUA yet.  So the SG makes up for
this by
> > handling all the SCCP management on behalf of the database, at least
those
> > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).
> 
> At the rate we are going SUA may beat M3UA to proposed standard.  It may
> be the other way around: the MGC has SUA but no M3UA yet and must use
> the services of SUA to provide M3UA.  As I noted, all that SUA needs to
> provide M3UA service as well is a DUPU and XFER message.
> 
> >
> > But I don't really want to get into a long discussion of how these cases
can
> > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs
from a
> > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > prevent anyone from trying the above applications.  There is to me a
> > difference between saying that the RK parameter in a REG REQ doesn't
have a
> > certain sub-parameter and saying RKs cannot use certain information.
Any RK
> > you want to dream up is possible, its just that it may not be able to
> > configure it dynamically.  Of course not all RK permutations make sense
for
> > a given application/architecture so people need to be careful of their
> > dreams.
> 
> I think we need to draw a line here somewhere.  Otherwise, why not try
> to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try to
> do TCAP with M3UA?  These "experiments" are deviations from the
> fundamental SIGTRAN architecture--the stuff of reasearch.  For the sake
> of interoperability, the architecture needs to be adhered to and
> functional demarcations drawn.  Otherwise an ASP implementation will
> never know what to expect from an SG implementation an visa versa.
> 
> If the sake of M3UA is not interoperability between different SG and AS
> implementations, why is the spec being written?  A vendor can do
> whatever they want within their own architecture now anyway.
> 
> >
> >
> >
> > I propose that we strike SSN from the Routing Key in the REG REQ
> > message.
> >
> > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > although there is no field for it in a REG REQ.  Distributing messages
> > based on TCAP Transaction Ids doesn't strike me as rational either.
> > I think you need TUA here.
> >
> > [Greg] There are some "tricks" that SGs can play with TRIDS for certain
> > applications/architectures.   TRIDS are not in the REG REQ but like I
said
> > above I don't see this as an impediment to an SG configuring them in an
RK-
> > they just couldn't be dynamically registered.  I think way back some
people
> > were thinking of using the TRID ranges as a way of ensuring that the
> > responses get back to the right originating ASPs.  I haven't studied the
SUA
> > recently enough to know if this is still an issue though.
> 
> M3UA can provide the service TCAP requires (via SCCP) by loadsharing on
SLS.
> The TCAP transaction Id coming off the SS7 network has no bearing on
> anything and is not even unique unless it is taken into context with the
> complete SCCP Calling Part Address (including Global Title).  The
> Transaction Id is local to the exchange betwen two TC-entities and does
> need not even be unique by SSN.  AIN, for example, uses Global Title in
> the Calling and Called Party addresses to determine the TC-entity.  This
> includes Transation Type and Address.  Correlation Ids in conversations
> are next to impossible to attempt to handle in this fashion.
> 
> Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA
> here.  If that is the approach the WG wants to take, why not smash all
> four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> 
> >
> > I don't mind removing TRID as an example if it causes any confusion - as
> > long as there is no restriction on the Routing Key in the SG.  If there
are
> > future applications to include field "xyz" in a Routing Key then I don't
> > think its not the role of the M3UA to say that it cannot be done.
> 
> I disagree.  I believe that M3UA should be constrained to the SIGTRAN
> architecture and not try to skip upwards in protocol level.  I believe
> that there would be more value in skipping downwards from SUA to MTP
> than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> believe that the line should be drawn.
> 
> I believe that the same is true for ISUP.  CIC ranges have no place in
> the Routing Key.  I believe that M3UA should consider them an "extended"
> SLS for loadsharing, but routing on them makes no sense.
> 
> --Brian
> 
> >
> > Cheers,
> >
> >    Greg
> >
> >
> >
> >
> >
> > I propose that we strike TCAP Transaction Id from the examples of
> > Routing Keys.
> >
> > --Brian
> >
> > --
> > 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 ¦
> >
> >
> > ---
> > 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]
> 
> --
> 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]
Date: Tue, 31 Jul 2001 15:21:03 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit
to quoted-printable by netmail.alcatel.com id PAA08140

Kevin,

What's the point of emulating MTP level 3 if there is no MTP-3 user such as
ISUP and SCCP?  I understand that it does not handle SCCP functions. 
It certainly can deliver SCCP, can't it?  

Regards,

Jeff

Kevin McCandless wrote:
> 
> Jeff:
> 
> M3UA emulates the MTP level 3 layer.  It does not handle the SCCP
functions.
> Since, Sigtran is emulating the SS7 stack in IP then it would make sense
to
> develop another layer, SUA, to handle SCCP functionality.
> 
> If you want to do SS7 over IP without so many stacks, you can do what
> Tekelec did and just do SS7 encapsulation over IP.  It works.  But then
> again that would not be what Sigtran's goal is....
> 
> Kevin
> 
> -----Original Message-----
> From: Jeff Copley [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 10:47 AM
> To: sigtran
> Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> Greg and Brian,
> 
> M3UA is supposed to support the upper layers of SS7.  If I needed both
> ISUP and SCCP between two destinations, why would I want to develop a
> second UA such as SUA when M3UA (or M2PA) can acheive this in just one
> UA.  Am I missing something obvious? (It wouldn't be the first time.)
> 
> Jeff
> 
> "Brian F. G. Bidulock" wrote:
> >
> > Greg,
> >
> > Please see comments inline...
> >
> > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001 00:47:44)
> > > Hi Brian,
> > >
> > > Responses below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Cc: "Greg Sidebottom" <[email-masked]>
> > > Sent: Monday, July 30, 2001 11:17 AM
> > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > >
> > >
> > > Greg,
> > >
> > > I don't see that rational basis on which M3UA can apply routing keys
> > > based on SCCP Subsystem number.  Can someone provide an example on
just
> > > how this was expected to work?  (Particularly how SCCP Management is
> > > handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> > > here.
> > >
> > > [Greg] I'll try and remember but this is from a while ago.  I think
> there
> > > are valid cases where an MGC supports both ISUP and TCAP (lets say for
> CCBS
> > > or the CLASS equivalent service).  While I'd agree that SUA is
probably
> a
> > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the
ISUP
> > > traffic already and it seems a lot of overhead to also support SUA and
> > > another SCTP association just for the TCAP traffic. ...
> >
> > Several comments here:
> >
> > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > restricted case, very minimal functionality from SUA is required
> > (perhaps only class 0 operation), all all the ASP management functions
> > are very close, really all that is required is supporting different
> > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > operation SUA has no more overhead that M3UA and there is a lot of
> > common parts.
> >
> > Quite frankly all that SUA needs to do is support two messages (XFER
> > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > without GT is really close to "bare" MTP and SUA handles this as the
> > trivial case.
> >
> > Perhaps you are looking at things backwards:  perhasp it is SUA which
> > should provide the functionality of MTP (as a pass-through to the lower
> > layer by shunting just a teeny bit of class 0), rather than M3UA
> > attempting to provide the functionality of SCCP (by loading SS7 SCCP
> > procedures into the M3UA at the SG).  Don't place SCCP functionality
> > into M3UA (above the MTP user interface)--allow SUA to pass-down to MTP.
> > This keeps SS7 functionality in the SS7 layers and UA functionality in
> > the UA layers.
> >
> > Nevertheless, it is not necessary to have multiple associations.  UA
> > peers can be multiplexed over the same association by Payload Protocol
> > Identifier.  See the thread "Multiple UAs per Association".
> >
> > The simple example of CLASS belies the fact that the normal switch has
> > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> > types of transaction which the switch needs to do also require
> > conversations, both class 0 and 1 support, and interworking support on
> > UDT/XUDT/LUDT, correlation of conversations, ...
> >
> > > ... So a RK could be used
> > > to direct SCCP traffic for this service to an active MGC.
> >
> > This traffic can be routed on SI without SSN.  Unless you are
> > considering some type of Global Title lookup as well, the SSN will not
> > tell you where the subscriber data is (which AS to use).  Although
> > splitting traffic into ISUP and SCCP traffic makes sense, splitting SCCP
> > traffic by SSN does not, particularly in the case of CLASS-like services
> > where all queries are against a GT which reflects subscriber
> > information.  The SSN traffic will need to be split further (somewhere)
> > for redundancy, so why do this?  Why not just loadshare all SCCP traffic
> > by SLS and perform the SCCP functions at the ASP?  SLS (extended by CIC)
> > is the only rational basis for loadsharing in M3UA, anyway.
> >
> > > I assume that
> > > SCCP management is not perfect but it is probably not used completely
> anyway
> > > for these end-node to end-node services because SCCP management will
> > > probably not be concerned about the subsystem state of all the
possible
> CCBS
> > > peers (or support traffic Mix procedures or SOR/SOG for that matter).
> >
> > Again, this belies the fact that these switches also have LNP dips to
> > perform which requires close monitoring of subsystem availability (the
> > status of the LNP database from the MGC).  Also, switches normally do
> > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention
> > the requirements of an MSC).
> >
> > > I'm
> > > not sure why OMAP SRVT would be an issue yet.  In any case, for the
SSN
> RK
> > > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't
used
> in
> > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks,
as
> far
> > > as I've seen anyway.
> >
> > You may have never noticed it.  An SG/MGC must be able to respond to the
> > message.
> >
> > >
> > > Another case I have also seen is where M3UA is used from an SG to a
> > > database, but the SG didn't support SUA yet.  So the SG makes up for
> this by
> > > handling all the SCCP management on behalf of the database, at least
> those
> > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP etc).
> >
> > At the rate we are going SUA may beat M3UA to proposed standard.  It may
> > be the other way around: the MGC has SUA but no M3UA yet and must use
> > the services of SUA to provide M3UA.  As I noted, all that SUA needs to
> > provide M3UA service as well is a DUPU and XFER message.
> >
> > >
> > > But I don't really want to get into a long discussion of how these
cases
> can
> > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed SSNs
> from a
> > > RK parameter in a REG REQ as I think removing it from the REG REQ
> doesn't
> > > prevent anyone from trying the above applications.  There is to me a
> > > difference between saying that the RK parameter in a REG REQ doesn't
> have a
> > > certain sub-parameter and saying RKs cannot use certain information.
> Any RK
> > > you want to dream up is possible, its just that it may not be able to
> > > configure it dynamically.  Of course not all RK permutations make
sense
> for
> > > a given application/architecture so people need to be careful of their
> > > dreams.
> >
> > I think we need to draw a line here somewhere.  Otherwise, why not try
> > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try to
> > do TCAP with M3UA?  These "experiments" are deviations from the
> > fundamental SIGTRAN architecture--the stuff of reasearch.  For the sake
> > of interoperability, the architecture needs to be adhered to and
> > functional demarcations drawn.  Otherwise an ASP implementation will
> > never know what to expect from an SG implementation an visa versa.
> >
> > If the sake of M3UA is not interoperability between different SG and AS
> > implementations, why is the spec being written?  A vendor can do
> > whatever they want within their own architecture now anyway.
> >
> > >
> > >
> > >
> > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > message.
> > >
> > > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > > although there is no field for it in a REG REQ.  Distributing messages
> > > based on TCAP Transaction Ids doesn't strike me as rational either.
> > > I think you need TUA here.
> > >
> > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > applications/architectures.   TRIDS are not in the REG REQ but like I
> said
> > > above I don't see this as an impediment to an SG configuring them in
an
> RK-
> > > they just couldn't be dynamically registered.  I think way back some
> people
> > > were thinking of using the TRID ranges as a way of ensuring that the
> > > responses get back to the right originating ASPs.  I haven't studied
the
> SUA
> > > recently enough to know if this is still an issue though.
> >
> > M3UA can provide the service TCAP requires (via SCCP) by loadsharing on
> SLS.
> > The TCAP transaction Id coming off the SS7 network has no bearing on
> > anything and is not even unique unless it is taken into context with the
> > complete SCCP Calling Part Address (including Global Title).  The
> > Transaction Id is local to the exchange betwen two TC-entities and does
> > need not even be unique by SSN.  AIN, for example, uses Global Title in
> > the Calling and Called Party addresses to determine the TC-entity.  This
> > includes Transation Type and Address.  Correlation Ids in conversations
> > are next to impossible to attempt to handle in this fashion.
> >
> > Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA
> > here.  If that is the approach the WG wants to take, why not smash all
> > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> >
> > >
> > > I don't mind removing TRID as an example if it causes any confusion -
as
> > > long as there is no restriction on the Routing Key in the SG.  If
there
> are
> > > future applications to include field "xyz" in a Routing Key then I
don't
> > > think its not the role of the M3UA to say that it cannot be done.
> >
> > I disagree.  I believe that M3UA should be constrained to the SIGTRAN
> > architecture and not try to skip upwards in protocol level.  I believe
> > that there would be more value in skipping downwards from SUA to MTP
> > than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> > believe that the line should be drawn.
> >
> > I believe that the same is true for ISUP.  CIC ranges have no place in
> > the Routing Key.  I believe that M3UA should consider them an "extended"
> > SLS for loadsharing, but routing on them makes no sense.
> >
> > --Brian
> >
> > >
> > > Cheers,
> > >
> > >    Greg
> > >
> > >
> > >
> > >
> > >
> > > I propose that we strike TCAP Transaction Id from the examples of
> > > Routing Keys.
> > >
> > > --Brian
> > >
> > > --
> > > 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 ¦
> > >
> > >
> > > ---
> > > 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]
> >
> > --
> > 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley16.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 31 Jul 2001 15:28:11 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.51]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit
to quoted-printable by netmail2.alcatel.com id PAA00395

Hi Brian,

My current opinions are too biased to express my view of SUA.  I am always
open to change.

With respect to carrying SCCP over M3UA, what "stuff"?  M3UA carries the
routing label.  It also carries the MTP-3 user.  So why can't I carry any
MTP-3 user?  I must be missing something (and don't say a brain, Brian).

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Jeff,
> 
> Are you proposing that we strike SUA as a work item?  In that
> case M3UA is going to need a lot more "stuff" to fully support
> all classes of SCCP operation.
> 
> ISUP is trivial.  If circuits are kept together by SLS or CIC
> there is not much to worry about.  Besides ISUP only requires
> a loadsharing scheme not a routing scheme.  SCCP requires both.
> 
> --Brian
> 
> Jeff Copley wrote:                                           (Tue, 31 Jul
2001 10:46:56)
> > Greg and Brian,
> >
> > M3UA is supposed to support the upper layers of SS7.  If I needed both
> > ISUP and SCCP between two destinations, why would I want to develop a
> > second UA such as SUA when M3UA (or M2PA) can acheive this in just one
> > UA.  Am I missing something obvious? (It wouldn't be the first time.)
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Greg,
> > >
> > > Please see comments inline...
> > >
> > > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001
00:47:44)
> > > > Hi Brian,
> > > >
> > > > Responses below ...
> > > >
> > > > ----- Original Message -----
> > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > To: "sigtran" <[email-masked]>
> > > > Cc: "Greg Sidebottom" <[email-masked]>
> > > > Sent: Monday, July 30, 2001 11:17 AM
> > > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > > >
> > > >
> > > > Greg,
> > > >
> > > > I don't see that rational basis on which M3UA can apply routing keys
> > > > based on SCCP Subsystem number.  Can someone provide an example on
just
> > > > how this was expected to work?  (Particularly how SCCP Management is
> > > > handled and OMAP SCCP Route Verification Tests.)  I think you need
SUA
> > > > here.
> > > >
> > > > [Greg] I'll try and remember but this is from a while ago.  I think
there
> > > > are valid cases where an MGC supports both ISUP and TCAP (lets say
for CCBS
> > > > or the CLASS equivalent service).  While I'd agree that SUA is
probably a
> > > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the
ISUP
> > > > traffic already and it seems a lot of overhead to also support SUA
and
> > > > another SCTP association just for the TCAP traffic. ...
> > >
> > > Several comments here:
> > >
> > > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > > restricted case, very minimal functionality from SUA is required
> > > (perhaps only class 0 operation), all all the ASP management functions
> > > are very close, really all that is required is supporting different
> > > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > > operation SUA has no more overhead that M3UA and there is a lot of
> > > common parts.
> > >
> > > Quite frankly all that SUA needs to do is support two messages (XFER
> > > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > > without GT is really close to "bare" MTP and SUA handles this as the
> > > trivial case.
> > >
> > > Perhaps you are looking at things backwards:  perhasp it is SUA which
> > > should provide the functionality of MTP (as a pass-through to the
lower
> > > layer by shunting just a teeny bit of class 0), rather than M3UA
> > > attempting to provide the functionality of SCCP (by loading SS7 SCCP
> > > procedures into the M3UA at the SG).  Don't place SCCP functionality
> > > into M3UA (above the MTP user interface)--allow SUA to pass-down to
MTP.
> > > This keeps SS7 functionality in the SS7 layers and UA functionality in
> > > the UA layers.
> > >
> > > Nevertheless, it is not necessary to have multiple associations.  UA
> > > peers can be multiplexed over the same association by Payload Protocol
> > > Identifier.  See the thread "Multiple UAs per Association".
> > >
> > > The simple example of CLASS belies the fact that the normal switch has
> > > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> > > types of transaction which the switch needs to do also require
> > > conversations, both class 0 and 1 support, and interworking support on
> > > UDT/XUDT/LUDT, correlation of conversations, ...
> > >
> > > > ... So a RK could be used
> > > > to direct SCCP traffic for this service to an active MGC.
> > >
> > > This traffic can be routed on SI without SSN.  Unless you are
> > > considering some type of Global Title lookup as well, the SSN will not
> > > tell you where the subscriber data is (which AS to use).  Although
> > > splitting traffic into ISUP and SCCP traffic makes sense, splitting
SCCP
> > > traffic by SSN does not, particularly in the case of CLASS-like
services
> > > where all queries are against a GT which reflects subscriber
> > > information.  The SSN traffic will need to be split further
(somewhere)
> > > for redundancy, so why do this?  Why not just loadshare all SCCP
traffic
> > > by SLS and perform the SCCP functions at the ASP?  SLS (extended by
CIC)
> > > is the only rational basis for loadsharing in M3UA, anyway.
> > >
> > > > I assume that
> > > > SCCP management is not perfect but it is probably not used
completely anyway
> > > > for these end-node to end-node services because SCCP management will
> > > > probably not be concerned about the subsystem state of all the
possible CCBS
> > > > peers (or support traffic Mix procedures or SOR/SOG for that
matter).
> > >
> > > Again, this belies the fact that these switches also have LNP dips to
> > > perform which requires close monitoring of subsystem availability (the
> > > status of the LNP database from the MGC).  Also, switches normally do
> > > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to mention
> > > the requirements of an MSC).
> > >
> > > > I'm
> > > > not sure why OMAP SRVT would be an issue yet.  In any case, for the
SSN RK
> > > > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't
used in
> > > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7 networks,
as far
> > > > as I've seen anyway.
> > >
> > > You may have never noticed it.  An SG/MGC must be able to respond to
the
> > > message.
> > >
> > > >
> > > > Another case I have also seen is where M3UA is used from an SG to a
> > > > database, but the SG didn't support SUA yet.  So the SG makes up for
this by
> > > > handling all the SCCP management on behalf of the database, at least
those
> > > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP
etc).
> > >
> > > At the rate we are going SUA may beat M3UA to proposed standard.  It
may
> > > be the other way around: the MGC has SUA but no M3UA yet and must use
> > > the services of SUA to provide M3UA.  As I noted, all that SUA needs
to
> > > provide M3UA service as well is a DUPU and XFER message.
> > >
> > > >
> > > > But I don't really want to get into a long discussion of how these
cases can
> > > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed
SSNs from a
> > > > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > > > prevent anyone from trying the above applications.  There is to me a
> > > > difference between saying that the RK parameter in a REG REQ doesn't
have a
> > > > certain sub-parameter and saying RKs cannot use certain information.
Any RK
> > > > you want to dream up is possible, its just that it may not be able
to
> > > > configure it dynamically.  Of course not all RK permutations make
sense for
> > > > a given application/architecture so people need to be careful of
their
> > > > dreams.
> > >
> > > I think we need to draw a line here somewhere.  Otherwise, why not try
> > > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not try
to
> > > do TCAP with M3UA?  These "experiments" are deviations from the
> > > fundamental SIGTRAN architecture--the stuff of reasearch.  For the
sake
> > > of interoperability, the architecture needs to be adhered to and
> > > functional demarcations drawn.  Otherwise an ASP implementation will
> > > never know what to expect from an SG implementation an visa versa.
> > >
> > > If the sake of M3UA is not interoperability between different SG and
AS
> > > implementations, why is the spec being written?  A vendor can do
> > > whatever they want within their own architecture now anyway.
> > >
> > > >
> > > >
> > > >
> > > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > > message.
> > > >
> > > > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > > > although there is no field for it in a REG REQ.  Distributing
messages
> > > > based on TCAP Transaction Ids doesn't strike me as rational either.
> > > > I think you need TUA here.
> > > >
> > > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > > applications/architectures.   TRIDS are not in the REG REQ but like
I said
> > > > above I don't see this as an impediment to an SG configuring them in
an RK-
> > > > they just couldn't be dynamically registered.  I think way back some
people
> > > > were thinking of using the TRID ranges as a way of ensuring that the
> > > > responses get back to the right originating ASPs.  I haven't studied
the SUA
> > > > recently enough to know if this is still an issue though.
> > >
> > > M3UA can provide the service TCAP requires (via SCCP) by loadsharing
on SLS.
> > > The TCAP transaction Id coming off the SS7 network has no bearing on
> > > anything and is not even unique unless it is taken into context with
the
> > > complete SCCP Calling Part Address (including Global Title).  The
> > > Transaction Id is local to the exchange betwen two TC-entities and
does
> > > need not even be unique by SSN.  AIN, for example, uses Global Title
in
> > > the Calling and Called Party addresses to determine the TC-entity.
This
> > > includes Transation Type and Address.  Correlation Ids in
conversations
> > > are next to impossible to attempt to handle in this fashion.
> > >
> > > Certainly M3UA is trying to be M3UA plus some of SUA plus some of TUA
> > > here.  If that is the approach the WG wants to take, why not smash all
> > > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > >
> > > >
> > > > I don't mind removing TRID as an example if it causes any confusion
- as
> > > > long as there is no restriction on the Routing Key in the SG.  If
there are
> > > > future applications to include field "xyz" in a Routing Key then I
don't
> > > > think its not the role of the M3UA to say that it cannot be done.
> > >
> > > I disagree.  I believe that M3UA should be constrained to the SIGTRAN
> > > architecture and not try to skip upwards in protocol level.  I believe
> > > that there would be more value in skipping downwards from SUA to MTP
> > > than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> > > believe that the line should be drawn.
> > >
> > > I believe that the same is true for ISUP.  CIC ranges have no place in
> > > the Routing Key.  I believe that M3UA should consider them an
"extended"
> > > SLS for loadsharing, but routing on them makes no sense.
> > >
> > > --Brian
> > >
> > > >
> > > > Cheers,
> > > >
> > > >    Greg
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I propose that we strike TCAP Transaction Id from the examples of
> > > > Routing Keys.
> > > >
> > > > --Brian
> > > >
> > > > --
> > > > 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 ¦
> > > >
> > > >
> > > > ---
> > > > 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]
> > >
> > > --
> > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
> 
> Content-Description: footer
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> 
> --
> 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley17.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Date: Tue, 31 Jul 2001 13:33:03 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: SUA last call
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

M2UA seems to have gotten through Last Call in good shape.
Next in line is SUA, which is already getting comments on the latest draft.
I'd like to poll the group on whether there are objections to starting WG
Last Call on SUA, say, next Monday, going through to August 17th.  If so, we
can compile a list of the comments on SUA so far, and number them as "early"
Last Call comments.

The current draft is
http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-07.txt.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 31 Jul 2001 15:45:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      PAA26894
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jeff,

I think we have a crossed connection here.  I see no problems with M3UA
routing (delivering) SI=SCCP.  What I do see a problem with is M3UA
attempting to route on SSN.  M3UA should stick to the Routing Label for the
purposes of distributing messages to MTP3-Users at the ASP.  For
loadsharing, it makes sense for ISUP that M3UA could use a loadsharing
algorithm based on CIC, because it is trivial.  It is neither trivial nor
within the architecture that M3UA starts routing or loadsharing on SSN.  The
more "stuff" which would be required is captured nicely in the SUA draft.

--Brian

Jeff Copley wrote:                                           (Tue, 31 Jul
2001 15:28:11)
> Hi Brian,
> 
> My current opinions are too biased to express my view of SUA.  I am
> always open to change.
> 
> With respect to carrying SCCP over M3UA, what "stuff"?  M3UA carries the
> routing label.  It also carries the MTP-3 user.  So why can't I carry
> any MTP-3 user?  I must be missing something (and don't say a brain,
> Brian).
> 
> Jeff
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jeff,
> > 
> > Are you proposing that we strike SUA as a work item?  In that
> > case M3UA is going to need a lot more "stuff" to fully support
> > all classes of SCCP operation.
> > 
> > ISUP is trivial.  If circuits are kept together by SLS or CIC
> > there is not much to worry about.  Besides ISUP only requires
> > a loadsharing scheme not a routing scheme.  SCCP requires both.
> > 
> > --Brian
> > 
> > Jeff Copley wrote:                                           (Tue, 31
Jul 2001 10:46:56)
> > > Greg and Brian,
> > >
> > > M3UA is supposed to support the upper layers of SS7.  If I needed both
> > > ISUP and SCCP between two destinations, why would I want to develop a
> > > second UA such as SUA when M3UA (or M2PA) can acheive this in just one
> > > UA.  Am I missing something obvious? (It wouldn't be the first time.)
> > >
> > > Jeff
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Greg,
> > > >
> > > > Please see comments inline...
> > > >
> > > > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001
00:47:44)
> > > > > Hi Brian,
> > > > >
> > > > > Responses below ...
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > To: "sigtran" <[email-masked]>
> > > > > Cc: "Greg Sidebottom" <[email-masked]>
> > > > > Sent: Monday, July 30, 2001 11:17 AM
> > > > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > > > >
> > > > >
> > > > > Greg,
> > > > >
> > > > > I don't see that rational basis on which M3UA can apply routing
keys
> > > > > based on SCCP Subsystem number.  Can someone provide an example on
just
> > > > > how this was expected to work?  (Particularly how SCCP Management
is
> > > > > handled and OMAP SCCP Route Verification Tests.)  I think you need
SUA
> > > > > here.
> > > > >
> > > > > [Greg] I'll try and remember but this is from a while ago.  I
think there
> > > > > are valid cases where an MGC supports both ISUP and TCAP (lets say
for CCBS
> > > > > or the CLASS equivalent service).  While I'd agree that SUA is
probably a
> > > > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the
ISUP
> > > > > traffic already and it seems a lot of overhead to also support SUA
and
> > > > > another SCTP association just for the TCAP traffic. ...
> > > >
> > > > Several comments here:
> > > >
> > > > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > > > restricted case, very minimal functionality from SUA is required
> > > > (perhaps only class 0 operation), all all the ASP management
functions
> > > > are very close, really all that is required is supporting different
> > > > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > > > operation SUA has no more overhead that M3UA and there is a lot of
> > > > common parts.
> > > >
> > > > Quite frankly all that SUA needs to do is support two messages (XFER
> > > > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > > > without GT is really close to "bare" MTP and SUA handles this as the
> > > > trivial case.
> > > >
> > > > Perhaps you are looking at things backwards:  perhasp it is SUA
which
> > > > should provide the functionality of MTP (as a pass-through to the
lower
> > > > layer by shunting just a teeny bit of class 0), rather than M3UA
> > > > attempting to provide the functionality of SCCP (by loading SS7 SCCP
> > > > procedures into the M3UA at the SG).  Don't place SCCP functionality
> > > > into M3UA (above the MTP user interface)--allow SUA to pass-down to
MTP.
> > > > This keeps SS7 functionality in the SS7 layers and UA functionality
in
> > > > the UA layers.
> > > >
> > > > Nevertheless, it is not necessary to have multiple associations.  UA
> > > > peers can be multiplexed over the same association by Payload
Protocol
> > > > Identifier.  See the thread "Multiple UAs per Association".
> > > >
> > > > The simple example of CLASS belies the fact that the normal switch
has
> > > > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> > > > types of transaction which the switch needs to do also require
> > > > conversations, both class 0 and 1 support, and interworking support
on
> > > > UDT/XUDT/LUDT, correlation of conversations, ...
> > > >
> > > > > ... So a RK could be used
> > > > > to direct SCCP traffic for this service to an active MGC.
> > > >
> > > > This traffic can be routed on SI without SSN.  Unless you are
> > > > considering some type of Global Title lookup as well, the SSN will
not
> > > > tell you where the subscriber data is (which AS to use).  Although
> > > > splitting traffic into ISUP and SCCP traffic makes sense, splitting
SCCP
> > > > traffic by SSN does not, particularly in the case of CLASS-like
services
> > > > where all queries are against a GT which reflects subscriber
> > > > information.  The SSN traffic will need to be split further
(somewhere)
> > > > for redundancy, so why do this?  Why not just loadshare all SCCP
traffic
> > > > by SLS and perform the SCCP functions at the ASP?  SLS (extended by
CIC)
> > > > is the only rational basis for loadsharing in M3UA, anyway.
> > > >
> > > > > I assume that
> > > > > SCCP management is not perfect but it is probably not used
completely anyway
> > > > > for these end-node to end-node services because SCCP management
will
> > > > > probably not be concerned about the subsystem state of all the
possible CCBS
> > > > > peers (or support traffic Mix procedures or SOR/SOG for that
matter).
> > > >
> > > > Again, this belies the fact that these switches also have LNP dips
to
> > > > perform which requires close monitoring of subsystem availability
(the
> > > > status of the LNP database from the MGC).  Also, switches normally
do
> > > > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to
mention
> > > > the requirements of an MSC).
> > > >
> > > > > I'm
> > > > > not sure why OMAP SRVT would be an issue yet.  In any case, for
the SSN RK
> > > > > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't
used in
> > > > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7
networks, as far
> > > > > as I've seen anyway.
> > > >
> > > > You may have never noticed it.  An SG/MGC must be able to respond to
the
> > > > message.
> > > >
> > > > >
> > > > > Another case I have also seen is where M3UA is used from an SG to
a
> > > > > database, but the SG didn't support SUA yet.  So the SG makes up
for this by
> > > > > handling all the SCCP management on behalf of the database, at
least those
> > > > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP
etc).
> > > >
> > > > At the rate we are going SUA may beat M3UA to proposed standard.  It
may
> > > > be the other way around: the MGC has SUA but no M3UA yet and must
use
> > > > the services of SUA to provide M3UA.  As I noted, all that SUA needs
to
> > > > provide M3UA service as well is a DUPU and XFER message.
> > > >
> > > > >
> > > > > But I don't really want to get into a long discussion of how these
cases can
> > > > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed
SSNs from a
> > > > > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > > > > prevent anyone from trying the above applications.  There is to me
a
> > > > > difference between saying that the RK parameter in a REG REQ
doesn't have a
> > > > > certain sub-parameter and saying RKs cannot use certain
information.  Any RK
> > > > > you want to dream up is possible, its just that it may not be able
to
> > > > > configure it dynamically.  Of course not all RK permutations make
sense for
> > > > > a given application/architecture so people need to be careful of
their
> > > > > dreams.
> > > >
> > > > I think we need to draw a line here somewhere.  Otherwise, why not
try
> > > > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not
try to
> > > > do TCAP with M3UA?  These "experiments" are deviations from the
> > > > fundamental SIGTRAN architecture--the stuff of reasearch.  For the
sake
> > > > of interoperability, the architecture needs to be adhered to and
> > > > functional demarcations drawn.  Otherwise an ASP implementation will
> > > > never know what to expect from an SG implementation an visa versa.
> > > >
> > > > If the sake of M3UA is not interoperability between different SG and
AS
> > > > implementations, why is the spec being written?  A vendor can do
> > > > whatever they want within their own architecture now anyway.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > > > message.
> > > > >
> > > > > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > > > > although there is no field for it in a REG REQ.  Distributing
messages
> > > > > based on TCAP Transaction Ids doesn't strike me as rational
either.
> > > > > I think you need TUA here.
> > > > >
> > > > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > > > applications/architectures.   TRIDS are not in the REG REQ but
like I said
> > > > > above I don't see this as an impediment to an SG configuring them
in an RK-
> > > > > they just couldn't be dynamically registered.  I think way back
some people
> > > > > were thinking of using the TRID ranges as a way of ensuring that
the
> > > > > responses get back to the right originating ASPs.  I haven't
studied the SUA
> > > > > recently enough to know if this is still an issue though.
> > > >
> > > > M3UA can provide the service TCAP requires (via SCCP) by loadsharing
on SLS.
> > > > The TCAP transaction Id coming off the SS7 network has no bearing on
> > > > anything and is not even unique unless it is taken into context with
the
> > > > complete SCCP Calling Part Address (including Global Title).  The
> > > > Transaction Id is local to the exchange betwen two TC-entities and
does
> > > > need not even be unique by SSN.  AIN, for example, uses Global Title
in
> > > > the Calling and Called Party addresses to determine the TC-entity.
This
> > > > includes Transation Type and Address.  Correlation Ids in
conversations
> > > > are next to impossible to attempt to handle in this fashion.
> > > >
> > > > Certainly M3UA is trying to be M3UA plus some of SUA plus some of
TUA
> > > > here.  If that is the approach the WG wants to take, why not smash
all
> > > > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > > >
> > > > >
> > > > > I don't mind removing TRID as an example if it causes any
confusion - as
> > > > > long as there is no restriction on the Routing Key in the SG.  If
there are
> > > > > future applications to include field "xyz" in a Routing Key then I
don't
> > > > > think its not the role of the M3UA to say that it cannot be done.
> > > >
> > > > I disagree.  I believe that M3UA should be constrained to the
SIGTRAN
> > > > architecture and not try to skip upwards in protocol level.  I
believe
> > > > that there would be more value in skipping downwards from SUA to MTP
> > > > than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> > > > believe that the line should be drawn.
> > > >
> > > > I believe that the same is true for ISUP.  CIC ranges have no place
in
> > > > the Routing Key.  I believe that M3UA should consider them an
"extended"
> > > > SLS for loadsharing, but routing on them makes no sense.
> > > >
> > > > --Brian
> > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > >    Greg
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I propose that we strike TCAP Transaction Id from the examples of
> > > > > Routing Keys.
> > > > >
> > > > > --Brian
> > > > >
> > > > > --
> > > > > 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
¦
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > > >
> > > > --
> > > > 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]
> > Content-Description: Card for Jeff Copley
> > > begin:vcard
> > > n:Copley;Jeff
> > > tel;work:972.519.3758
> > > x-mozilla-html:FALSE
> > > org:Alcatel USA, Inc.
> > > version:2.1
> > > email;internet:[email-masked]
> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > > x-mozilla-cpt:;20864
> > > fn:Jeff Copley
> > > end:vcard
> > >
> > >
> > >
> > 
> > Content-Description: footer
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
[email-masked]
> > 
> > --
> > 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] Content-Description: Card for
Jeff Copley
> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard

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

-- 
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]
Date: Tue, 31 Jul 2001 16:03:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA last call
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

There are a lot of changes outstanding to SUA: addition of sequence control
field to flags, addition of MP bits to flags parameter, proposals to split
flags parameter into separate parameters, division of responsibilities for
segmentation/reassmbly/sequencing, decoupled operation additions of
parameters to messages, addition of registration procedure for SUA, removal
of ASP capabilities parameter, addition of Broadcast traffic mode, heartbeat
updates, ...

Also, the SUAv7 draft failed to capture all of the comments and issues which
have carried over from SUAv5 and SUAv6.

I would like to see an SUAv8 which addresses the concesus which has been
reached on a good number of the above items, and most of those outstanding
from v5 and 6, before moving to Last Call: if only so that we all know what
we are reviewing.

--Brian

Lyndon Ong wrote:                                          (Tue, 31 Jul 2001
13:33:03)
> Folks,
> 
> M2UA seems to have gotten through Last Call in good shape.
> Next in line is SUA, which is already getting comments on
> the latest draft.  I'd like to poll the group on whether
> there are objections to starting WG Last Call on SUA, say,
> next Monday, going through to August 17th.  If so, we can
> compile a list of the comments on SUA so far, and number
> them as "early" Last Call comments.
> 
> The current draft is
http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-07.txt.
> Cheers,
> L. Ong

-- 
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]
Date: Tue, 31 Jul 2001 16:30:41 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail2.alcatel.com [128.251.168.51]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit
to quoted-printable by netmail2.alcatel.com id QAA09878

Brian,

Thanks for the clarifying this for me.

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Jeff,
> 
> I think we have a crossed connection here.  I see no problems with
> M3UA routing (delivering) SI=SCCP.  What I do see a problem with is
> M3UA attempting to route on SSN.  M3UA should stick to the Routing
> Label for the purposes of distributing messages to MTP3-Users at
> the ASP.  For loadsharing, it makes sense for ISUP that M3UA could
> use a loadsharing algorithm based on CIC, because it is trivial.  It is
> neither trivial nor within the architecture that M3UA starts routing or
> loadsharing on SSN.  The more "stuff" which would be required is captured
> nicely in the SUA draft.
> 
> --Brian
> 
> Jeff Copley wrote:                                           (Tue, 31 Jul
2001 15:28:11)
> > Hi Brian,
> >
> > My current opinions are too biased to express my view of SUA.  I am
> > always open to change.
> >
> > With respect to carrying SCCP over M3UA, what "stuff"?  M3UA carries the
> > routing label.  It also carries the MTP-3 user.  So why can't I carry
> > any MTP-3 user?  I must be missing something (and don't say a brain,
> > Brian).
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jeff,
> > >
> > > Are you proposing that we strike SUA as a work item?  In that
> > > case M3UA is going to need a lot more "stuff" to fully support
> > > all classes of SCCP operation.
> > >
> > > ISUP is trivial.  If circuits are kept together by SLS or CIC
> > > there is not much to worry about.  Besides ISUP only requires
> > > a loadsharing scheme not a routing scheme.  SCCP requires both.
> > >
> > > --Brian
> > >
> > > Jeff Copley wrote:                                           (Tue, 31
Jul 2001 10:46:56)
> > > > Greg and Brian,
> > > >
> > > > M3UA is supposed to support the upper layers of SS7.  If I needed
both
> > > > ISUP and SCCP between two destinations, why would I want to develop
a
> > > > second UA such as SUA when M3UA (or M2PA) can acheive this in just
one
> > > > UA.  Am I missing something obvious? (It wouldn't be the first
time.)
> > > >
> > > > Jeff
> > > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Greg,
> > > > >
> > > > > Please see comments inline...
> > > > >
> > > > > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001
00:47:44)
> > > > > > Hi Brian,
> > > > > >
> > > > > > Responses below ...
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > > To: "sigtran" <[email-masked]>
> > > > > > Cc: "Greg Sidebottom" <[email-masked]>
> > > > > > Sent: Monday, July 30, 2001 11:17 AM
> > > > > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > > > > >
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > I don't see that rational basis on which M3UA can apply routing
keys
> > > > > > based on SCCP Subsystem number.  Can someone provide an example
on just
> > > > > > how this was expected to work?  (Particularly how SCCP
Management is
> > > > > > handled and OMAP SCCP Route Verification Tests.)  I think you
need SUA
> > > > > > here.
> > > > > >
> > > > > > [Greg] I'll try and remember but this is from a while ago.  I
think there
> > > > > > are valid cases where an MGC supports both ISUP and TCAP (lets
say for CCBS
> > > > > > or the CLASS equivalent service).  While I'd agree that SUA is
probably a
> > > > > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for
the ISUP
> > > > > > traffic already and it seems a lot of overhead to also support
SUA and
> > > > > > another SCTP association just for the TCAP traffic. ...
> > > > >
> > > > > Several comments here:
> > > > >
> > > > > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > > > > restricted case, very minimal functionality from SUA is required
> > > > > (perhaps only class 0 operation), all all the ASP management
functions
> > > > > are very close, really all that is required is supporting
different
> > > > > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > > > > operation SUA has no more overhead that M3UA and there is a lot of
> > > > > common parts.
> > > > >
> > > > > Quite frankly all that SUA needs to do is support two messages
(XFER
> > > > > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > > > > without GT is really close to "bare" MTP and SUA handles this as
the
> > > > > trivial case.
> > > > >
> > > > > Perhaps you are looking at things backwards:  perhasp it is SUA
which
> > > > > should provide the functionality of MTP (as a pass-through to the
lower
> > > > > layer by shunting just a teeny bit of class 0), rather than M3UA
> > > > > attempting to provide the functionality of SCCP (by loading SS7
SCCP
> > > > > procedures into the M3UA at the SG).  Don't place SCCP
functionality
> > > > > into M3UA (above the MTP user interface)--allow SUA to pass-down
to MTP.
> > > > > This keeps SS7 functionality in the SS7 layers and UA
functionality in
> > > > > the UA layers.
> > > > >
> > > > > Nevertheless, it is not necessary to have multiple associations.
UA
> > > > > peers can be multiplexed over the same association by Payload
Protocol
> > > > > Identifier.  See the thread "Multiple UAs per Association".
> > > > >
> > > > > The simple example of CLASS belies the fact that the normal switch
has
> > > > > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).
These
> > > > > types of transaction which the switch needs to do also require
> > > > > conversations, both class 0 and 1 support, and interworking
support on
> > > > > UDT/XUDT/LUDT, correlation of conversations, ...
> > > > >
> > > > > > ... So a RK could be used
> > > > > > to direct SCCP traffic for this service to an active MGC.
> > > > >
> > > > > This traffic can be routed on SI without SSN.  Unless you are
> > > > > considering some type of Global Title lookup as well, the SSN will
not
> > > > > tell you where the subscriber data is (which AS to use).  Although
> > > > > splitting traffic into ISUP and SCCP traffic makes sense,
splitting SCCP
> > > > > traffic by SSN does not, particularly in the case of CLASS-like
services
> > > > > where all queries are against a GT which reflects subscriber
> > > > > information.  The SSN traffic will need to be split further
(somewhere)
> > > > > for redundancy, so why do this?  Why not just loadshare all SCCP
traffic
> > > > > by SLS and perform the SCCP functions at the ASP?  SLS (extended
by CIC)
> > > > > is the only rational basis for loadsharing in M3UA, anyway.
> > > > >
> > > > > > I assume that
> > > > > > SCCP management is not perfect but it is probably not used
completely anyway
> > > > > > for these end-node to end-node services because SCCP management
will
> > > > > > probably not be concerned about the subsystem state of all the
possible CCBS
> > > > > > peers (or support traffic Mix procedures or SOR/SOG for that
matter).
> > > > >
> > > > > Again, this belies the fact that these switches also have LNP dips
to
> > > > > perform which requires close monitoring of subsystem availability
(the
> > > > > status of the LNP database from the MGC).  Also, switches normally
do
> > > > > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to
mention
> > > > > the requirements of an MSC).
> > > > >
> > > > > > I'm
> > > > > > not sure why OMAP SRVT would be an issue yet.  In any case, for
the SSN RK
> > > > > > cases I've seen discussed, OMAP SRVT could be ignored as it
wasn't used in
> > > > > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7
networks, as far
> > > > > > as I've seen anyway.
> > > > >
> > > > > You may have never noticed it.  An SG/MGC must be able to respond
to the
> > > > > message.
> > > > >
> > > > > >
> > > > > > Another case I have also seen is where M3UA is used from an SG
to a
> > > > > > database, but the SG didn't support SUA yet.  So the SG makes up
for this by
> > > > > > handling all the SCCP management on behalf of the database, at
least those
> > > > > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP
etc).
> > > > >
> > > > > At the rate we are going SUA may beat M3UA to proposed standard.
It may
> > > > > be the other way around: the MGC has SUA but no M3UA yet and must
use
> > > > > the services of SUA to provide M3UA.  As I noted, all that SUA
needs to
> > > > > provide M3UA service as well is a DUPU and XFER message.
> > > > >
> > > > > >
> > > > > > But I don't really want to get into a long discussion of how
these cases can
> > > > > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed
SSNs from a
> > > > > > RK parameter in a REG REQ as I think removing it from the REG
REQ doesn't
> > > > > > prevent anyone from trying the above applications.  There is to
me a
> > > > > > difference between saying that the RK parameter in a REG REQ
doesn't have a
> > > > > > certain sub-parameter and saying RKs cannot use certain
information.  Any RK
> > > > > > you want to dream up is possible, its just that it may not be
able to
> > > > > > configure it dynamically.  Of course not all RK permutations
make sense for
> > > > > > a given application/architecture so people need to be careful of
their
> > > > > > dreams.
> > > > >
> > > > > I think we need to draw a line here somewhere.  Otherwise, why not
try
> > > > > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not
try to
> > > > > do TCAP with M3UA?  These "experiments" are deviations from the
> > > > > fundamental SIGTRAN architecture--the stuff of reasearch.  For the
sake
> > > > > of interoperability, the architecture needs to be adhered to and
> > > > > functional demarcations drawn.  Otherwise an ASP implementation
will
> > > > > never know what to expect from an SG implementation an visa versa.
> > > > >
> > > > > If the sake of M3UA is not interoperability between different SG
and AS
> > > > > implementations, why is the spec being written?  A vendor can do
> > > > > whatever they want within their own architecture now anyway.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > > > > message.
> > > > > >
> > > > > > Also, TCAP Transaction Id is used as an example of a Routing
Key,
> > > > > > although there is no field for it in a REG REQ.  Distributing
messages
> > > > > > based on TCAP Transaction Ids doesn't strike me as rational
either.
> > > > > > I think you need TUA here.
> > > > > >
> > > > > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > > > > applications/architectures.   TRIDS are not in the REG REQ but
like I said
> > > > > > above I don't see this as an impediment to an SG configuring
them in an RK-
> > > > > > they just couldn't be dynamically registered.  I think way back
some people
> > > > > > were thinking of using the TRID ranges as a way of ensuring that
the
> > > > > > responses get back to the right originating ASPs.  I haven't
studied the SUA
> > > > > > recently enough to know if this is still an issue though.
> > > > >
> > > > > M3UA can provide the service TCAP requires (via SCCP) by
loadsharing on SLS.
> > > > > The TCAP transaction Id coming off the SS7 network has no bearing
on
> > > > > anything and is not even unique unless it is taken into context
with the
> > > > > complete SCCP Calling Part Address (including Global Title).  The
> > > > > Transaction Id is local to the exchange betwen two TC-entities and
does
> > > > > need not even be unique by SSN.  AIN, for example, uses Global
Title in
> > > > > the Calling and Called Party addresses to determine the TC-entity.
This
> > > > > includes Transation Type and Address.  Correlation Ids in
conversations
> > > > > are next to impossible to attempt to handle in this fashion.
> > > > >
> > > > > Certainly M3UA is trying to be M3UA plus some of SUA plus some of
TUA
> > > > > here.  If that is the approach the WG wants to take, why not smash
all
> > > > > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > > > >
> > > > > >
> > > > > > I don't mind removing TRID as an example if it causes any
confusion - as
> > > > > > long as there is no restriction on the Routing Key in the SG.
If there are
> > > > > > future applications to include field "xyz" in a Routing Key then
I don't
> > > > > > think its not the role of the M3UA to say that it cannot be
done.
> > > > >
> > > > > I disagree.  I believe that M3UA should be constrained to the
SIGTRAN
> > > > > architecture and not try to skip upwards in protocol level.  I
believe
> > > > > that there would be more value in skipping downwards from SUA to
MTP
> > > > > than in skipping upwards from M3UA to SUA to TUA and on...  Again,
I
> > > > > believe that the line should be drawn.
> > > > >
> > > > > I believe that the same is true for ISUP.  CIC ranges have no
place in
> > > > > the Routing Key.  I believe that M3UA should consider them an
"extended"
> > > > > SLS for loadsharing, but routing on them makes no sense.
> > > > >
> > > > > --Brian
> > > > >
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > >    Greg
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I propose that we strike TCAP Transaction Id from the examples
of
> > > > > > Routing Keys.
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > > --
> > > > > > 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 ¦
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > > Content-Description: Card for Jeff Copley
> > > > begin:vcard
> > > > n:Copley;Jeff
> > > > tel;work:972.519.3758
> > > > x-mozilla-html:FALSE
> > > > org:Alcatel USA, Inc.
> > > > version:2.1
> > > > email;internet:[email-masked]
> > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > > > x-mozilla-cpt:;20864
> > > > fn:Jeff Copley
> > > > end:vcard
> > > >
> > > >
> > > >
> > >
> > > Content-Description: footer
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
[email-masked]
> > >
> > > --
> > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
> 
> Content-Description: footer
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> 
> --
> 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley18.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Lotus-FromDomain: TEKELEC
From: Dan Brendes <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Tue, 31 Jul 2001 18:08:51 -0400
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: domino2.nc.tekelec.com [198.89.40.41]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

brian -

i'm not claiming to be an SCCP expert by any means, but it seems to me that
there is a subset of SCCP traffic (class 0 and class 1) that works just fine
using the DPC-SI-SSN routing key that was proposed some time ago.  i'm not
saying there aren't issues, such as getting SCMG messages such as Subsystem
Test to the right ASP, but they aren't insurmountable.  Why can't ASPs
register for ssn=1 (or 0, whatever the SCMG subsystem is) and use the
broadcast traffic mode you had advocated to ensure that the right message
gets to the right ASP if you think the decision is too complex for the SG?

Why don't we leave it to the actual implementations to decide what is
trivial and within their architecture...and leave it to them to use an SSN
based routing key if/when it makes sense to do so.

"Brian F. G. Bidulock" <[email-masked]> on 07/31/2001 04:45:43 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Dan
Brendes/Raleigh/TEKELEC) Subject:  Re: M3UAv8: SSN in Routing Key and TCAP
TID in example.

Jeff,

I think we have a crossed connection here.  I see no problems with M3UA
routing (delivering) SI=SCCP.  What I do see a problem with is M3UA
attempting to route on SSN.  M3UA should stick to the Routing Label for the
purposes of distributing messages to MTP3-Users at the ASP.  For
loadsharing, it makes sense for ISUP that M3UA could use a loadsharing
algorithm based on CIC, because it is trivial.  It is neither trivial nor
within the architecture that M3UA starts routing or loadsharing on SSN.  The
more "stuff" which would be required is captured nicely in the SUA draft.

--Brian

Jeff Copley wrote:                                           (Tue, 31 Jul
2001 15:28:11)
> Hi Brian,
>
> My current opinions are too biased to express my view of SUA.  I am
> always open to change.
>
> With respect to carrying SCCP over M3UA, what "stuff"?  M3UA carries the
> routing label.  It also carries the MTP-3 user.  So why can't I carry
> any MTP-3 user?  I must be missing something (and don't say a brain,
> Brian).
>
> Jeff
>
> "Brian F. G. Bidulock" wrote:
> >
> > Jeff,
> >
> > Are you proposing that we strike SUA as a work item?  In that
> > case M3UA is going to need a lot more "stuff" to fully support
> > all classes of SCCP operation.
> >
> > ISUP is trivial.  If circuits are kept together by SLS or CIC
> > there is not much to worry about.  Besides ISUP only requires
> > a loadsharing scheme not a routing scheme.  SCCP requires both.
> >
> > --Brian
> >
> > Jeff Copley wrote:                                           (Tue, 31
Jul 2001 10:46:56)
> > > Greg and Brian,
> > >
> > > M3UA is supposed to support the upper layers of SS7.  If I needed both
> > > ISUP and SCCP between two destinations, why would I want to develop a
> > > second UA such as SUA when M3UA (or M2PA) can acheive this in just one
> > > UA.  Am I missing something obvious? (It wouldn't be the first time.)
> > >
> > > Jeff
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Greg,
> > > >
> > > > Please see comments inline...
> > > >
> > > > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001
00:47:44)
> > > > > Hi Brian,
> > > > >
> > > > > Responses below ...
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > To: "sigtran" <[email-masked]>
> > > > > Cc: "Greg Sidebottom" <[email-masked]>
> > > > > Sent: Monday, July 30, 2001 11:17 AM
> > > > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > > > >
> > > > >
> > > > > Greg,
> > > > >
> > > > > I don't see that rational basis on which M3UA can apply routing
keys
> > > > > based on SCCP Subsystem number.  Can someone provide an example on
just
> > > > > how this was expected to work?  (Particularly how SCCP Management
is
> > > > > handled and OMAP SCCP Route Verification Tests.)  I think you need
SUA
> > > > > here.
> > > > >
> > > > > [Greg] I'll try and remember but this is from a while ago.  I
think there
> > > > > are valid cases where an MGC supports both ISUP and TCAP (lets say
for CCBS
> > > > > or the CLASS equivalent service).  While I'd agree that SUA is
probably a
> > > > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for the
ISUP
> > > > > traffic already and it seems a lot of overhead to also support SUA
and
> > > > > another SCTP association just for the TCAP traffic. ...
> > > >
> > > > Several comments here:
> > > >
> > > > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > > > restricted case, very minimal functionality from SUA is required
> > > > (perhaps only class 0 operation), all all the ASP management
functions
> > > > are very close, really all that is required is supporting different
> > > > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > > > operation SUA has no more overhead that M3UA and there is a lot of
> > > > common parts.
> > > >
> > > > Quite frankly all that SUA needs to do is support two messages (XFER
> > > > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > > > without GT is really close to "bare" MTP and SUA handles this as the
> > > > trivial case.
> > > >
> > > > Perhaps you are looking at things backwards:  perhasp it is SUA
which
> > > > should provide the functionality of MTP (as a pass-through to the
lower
> > > > layer by shunting just a teeny bit of class 0), rather than M3UA
> > > > attempting to provide the functionality of SCCP (by loading SS7 SCCP
> > > > procedures into the M3UA at the SG).  Don't place SCCP functionality
> > > > into M3UA (above the MTP user interface)--allow SUA to pass-down to
MTP.
> > > > This keeps SS7 functionality in the SS7 layers and UA functionality
in
> > > > the UA layers.
> > > >
> > > > Nevertheless, it is not necessary to have multiple associations.  UA
> > > > peers can be multiplexed over the same association by Payload
Protocol
> > > > Identifier.  See the thread "Multiple UAs per Association".
> > > >
> > > > The simple example of CLASS belies the fact that the normal switch
has
> > > > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).  These
> > > > types of transaction which the switch needs to do also require
> > > > conversations, both class 0 and 1 support, and interworking support
on
> > > > UDT/XUDT/LUDT, correlation of conversations, ...
> > > >
> > > > > ... So a RK could be used
> > > > > to direct SCCP traffic for this service to an active MGC.
> > > >
> > > > This traffic can be routed on SI without SSN.  Unless you are
> > > > considering some type of Global Title lookup as well, the SSN will
not
> > > > tell you where the subscriber data is (which AS to use).  Although
> > > > splitting traffic into ISUP and SCCP traffic makes sense, splitting
SCCP
> > > > traffic by SSN does not, particularly in the case of CLASS-like
services
> > > > where all queries are against a GT which reflects subscriber
> > > > information.  The SSN traffic will need to be split further
(somewhere)
> > > > for redundancy, so why do this?  Why not just loadshare all SCCP
traffic
> > > > by SLS and perform the SCCP functions at the ASP?  SLS (extended by
CIC)
> > > > is the only rational basis for loadsharing in M3UA, anyway.
> > > >
> > > > > I assume that
> > > > > SCCP management is not perfect but it is probably not used
completely anyway
> > > > > for these end-node to end-node services because SCCP management
will
> > > > > probably not be concerned about the subsystem state of all the
possible CCBS
> > > > > peers (or support traffic Mix procedures or SOR/SOG for that
matter).
> > > >
> > > > Again, this belies the fact that these switches also have LNP dips
to
> > > > perform which requires close monitoring of subsystem availability
(the
> > > > status of the LNP database from the MGC).  Also, switches normally
do
> > > > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to
mention
> > > > the requirements of an MSC).
> > > >
> > > > > I'm
> > > > > not sure why OMAP SRVT would be an issue yet.  In any case, for
the SSN RK
> > > > > cases I've seen discussed, OMAP SRVT could be ignored as it wasn't
used in
> > > > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7
networks, as far
> > > > > as I've seen anyway.
> > > >
> > > > You may have never noticed it.  An SG/MGC must be able to respond to
the
> > > > message.
> > > >
> > > > >
> > > > > Another case I have also seen is where M3UA is used from an SG to
a
> > > > > database, but the SG didn't support SUA yet.  So the SG makes up
for this by
> > > > > handling all the SCCP management on behalf of the database, at
least those
> > > > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP
etc).
> > > >
> > > > At the rate we are going SUA may beat M3UA to proposed standard.  It
may
> > > > be the other way around: the MGC has SUA but no M3UA yet and must
use
> > > > the services of SUA to provide M3UA.  As I noted, all that SUA needs
to
> > > > provide M3UA service as well is a DUPU and XFER message.
> > > >
> > > > >
> > > > > But I don't really want to get into a long discussion of how these
cases can
> > > > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed
SSNs from a
> > > > > RK parameter in a REG REQ as I think removing it from the REG REQ
doesn't
> > > > > prevent anyone from trying the above applications.  There is to me
a
> > > > > difference between saying that the RK parameter in a REG REQ
doesn't have a
> > > > > certain sub-parameter and saying RKs cannot use certain
information.
Any RK
> > > > > you want to dream up is possible, its just that it may not be able
to
> > > > > configure it dynamically.  Of course not all RK permutations make
sense for
> > > > > a given application/architecture so people need to be careful of
their
> > > > > dreams.
> > > >
> > > > I think we need to draw a line here somewhere.  Otherwise, why not
try
> > > > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not
try to
> > > > do TCAP with M3UA?  These "experiments" are deviations from the
> > > > fundamental SIGTRAN architecture--the stuff of reasearch.  For the
sake
> > > > of interoperability, the architecture needs to be adhered to and
> > > > functional demarcations drawn.  Otherwise an ASP implementation will
> > > > never know what to expect from an SG implementation an visa versa.
> > > >
> > > > If the sake of M3UA is not interoperability between different SG and
AS
> > > > implementations, why is the spec being written?  A vendor can do
> > > > whatever they want within their own architecture now anyway.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > > > message.
> > > > >
> > > > > Also, TCAP Transaction Id is used as an example of a Routing Key,
> > > > > although there is no field for it in a REG REQ.  Distributing
messages
> > > > > based on TCAP Transaction Ids doesn't strike me as rational
either.
> > > > > I think you need TUA here.
> > > > >
> > > > > [Greg] There are some "tricks" that SGs can play with TRIDS for
certain
> > > > > applications/architectures.   TRIDS are not in the REG REQ but
like I said
> > > > > above I don't see this as an impediment to an SG configuring them
in an RK-
> > > > > they just couldn't be dynamically registered.  I think way back
some people
> > > > > were thinking of using the TRID ranges as a way of ensuring that
the
> > > > > responses get back to the right originating ASPs.  I haven't
studied the SUA
> > > > > recently enough to know if this is still an issue though.
> > > >
> > > > M3UA can provide the service TCAP requires (via SCCP) by loadsharing
on SLS.
> > > > The TCAP transaction Id coming off the SS7 network has no bearing on
> > > > anything and is not even unique unless it is taken into context with
the
> > > > complete SCCP Calling Part Address (including Global Title).  The
> > > > Transaction Id is local to the exchange betwen two TC-entities and
does
> > > > need not even be unique by SSN.  AIN, for example, uses Global Title
in
> > > > the Calling and Called Party addresses to determine the TC-entity.
This
> > > > includes Transation Type and Address.  Correlation Ids in
conversations
> > > > are next to impossible to attempt to handle in this fashion.
> > > >
> > > > Certainly M3UA is trying to be M3UA plus some of SUA plus some of
TUA
> > > > here.  If that is the approach the WG wants to take, why not smash
all
> > > > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > > >
> > > > >
> > > > > I don't mind removing TRID as an example if it causes any
confusion - as
> > > > > long as there is no restriction on the Routing Key in the SG.  If
there are
> > > > > future applications to include field "xyz" in a Routing Key then I
don't
> > > > > think its not the role of the M3UA to say that it cannot be done.
> > > >
> > > > I disagree.  I believe that M3UA should be constrained to the
SIGTRAN
> > > > architecture and not try to skip upwards in protocol level.  I
believe
> > > > that there would be more value in skipping downwards from SUA to MTP
> > > > than in skipping upwards from M3UA to SUA to TUA and on...  Again, I
> > > > believe that the line should be drawn.
> > > >
> > > > I believe that the same is true for ISUP.  CIC ranges have no place
in
> > > > the Routing Key.  I believe that M3UA should consider them an
"extended"
> > > > SLS for loadsharing, but routing on them makes no sense.
> > > >
> > > > --Brian
> > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > >    Greg
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I propose that we strike TCAP Transaction Id from the examples of
> > > > > Routing Keys.
> > > > >
> > > > > --Brian
> > > > >
> > > > > --
> > > > > 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
¦
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > > >
> > > > --
> > > > 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]
> > Content-Description: Card for Jeff Copley
> > > begin:vcard
> > > n:Copley;Jeff
> > > tel;work:972.519.3758
> > > x-mozilla-html:FALSE
> > > org:Alcatel USA, Inc.
> > > version:2.1
> > > email;internet:[email-masked]
> > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > > x-mozilla-cpt:;20864
> > > fn:Jeff Copley
> > > end:vcard
> > >
> > >
> > >
> >
> > Content-Description: footer
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
[email-masked]
> >
> > --
> > 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] Content-Description: Card for
Jeff Copley
> begin:vcard
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard

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

--
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]
To: "sigtran" <[email-masked]>
Date: Tue, 31 Jul 2001 15:14:26 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: SUA last call
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Brian,

What I'd like to do is make the process a bit more close-ended: as part of
WG Last Call, make our comments against the v7 text, with suggested text
changes if possible, then let the editor incorporate these into v8.  If v8
is satisfactory we can then move it to IESG review, otherwise we can always
have another round of WG Last Call.

Cheers,

Lyndon
 
--

On Tue, 31 Jul 2001 16:03:34   Brian F. G. Bidulock wrote:
>Lyndon,
>
>There are a lot of changes outstanding to SUA: addition of sequence
>control field to flags, addition of MP bits to flags parameter,
>proposals to split flags parameter into separate parameters, division of
>responsibilities for segmentation/reassmbly/sequencing, decoupled
>operation additions of parameters to messages, addition of registration
>procedure for SUA, removal of ASP capabilities parameter, addition of
>Broadcast traffic mode, heartbeat updates, ...
>
>Also, the SUAv7 draft failed to capture all of the comments and issues
>which have carried over from SUAv5 and SUAv6.
>
>I would like to see an SUAv8 which addresses the concesus which has been
>reached on a good number of the above items, and most of those
>outstanding from v5 and 6, before moving to Last Call: if only so that
>we all know what we are reviewing.
>
>--Brian
>
>Lyndon Ong wrote:                                          (Tue, 31 Jul
2001 13:33:03)
>> Folks,
>> 
>> M2UA seems to have gotten through Last Call in good shape.
>> Next in line is SUA, which is already getting comments on
>> the latest draft.  I'd like to poll the group on whether
>> there are objections to starting WG Last Call on SUA, say,
>> next Monday, going through to August 17th.  If so, we can
>> compile a list of the comments on SUA so far, and number
>> them as "early" Last Call comments.
>> 
>> The current draft is
http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-07.txt.
>> 
>> Cheers,
>> 
>> L. Ong
>> 
>
>-- 
>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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 31 Jul 2001 17:26:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      RAA28643
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Dan,

It doesn't make sense to me because the restricted subset that you mention
is less than what is required for a typical switch, and is far less than
what is required for a database.  And, as I said, a more valid approach,
both within the SIGTRAN architecture and with consideration for SS7
interworking and the requirements of the MGC would be to pass-down ISUP
through SUA, rather than try to deal with SCCP in M3UA.

Performing these functions over M3UA is a duplication of the work done for
SUA, with the exception that the M3UA version is almost completely
unspecified, and highly unlikely to be interoperable.
The goal is interoperability between SG and MGC implementations: leaving
M3UA open to attempt to "fake-out" SCCP does not accomplish this.

--Brian

Dan Brendes wrote:                                            (Tue, 31 Jul
2001 18:08:51)
> 
> 
> brian -
> 
> i'm not claiming to be an SCCP expert by any means, but it seems to me
that
> there is a subset of SCCP traffic (class 0 and class 1) that works just
fine
> using the DPC-SI-SSN routing key that was proposed some time ago.  i'm not
> saying there aren't issues, such as getting SCMG messages such as
Subsystem Test
> to the right ASP, but they aren't insurmountable.  Why can't ASPs register
for
> ssn=1 (or 0, whatever the SCMG subsystem is) and use the broadcast traffic
mode
> you had advocated to ensure that the right message gets to the right ASP
if you
> think the decision is too complex for the SG?
> 
> Why don't we leave it to the actual implementations to decide what is
trivial
> and within their architecture...and leave it to them to use an SSN based
routing
> key if/when it makes sense to do so.
> 
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/31/2001 04:45:43 PM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Dan Brendes/Raleigh/TEKELEC)
> Subject:  Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> 
> 
> Jeff,
> 
> I think we have a crossed connection here.  I see no problems with
> M3UA routing (delivering) SI=SCCP.  What I do see a problem with is
> M3UA attempting to route on SSN.  M3UA should stick to the Routing
> Label for the purposes of distributing messages to MTP3-Users at
> the ASP.  For loadsharing, it makes sense for ISUP that M3UA could
> use a loadsharing algorithm based on CIC, because it is trivial.  It is
> neither trivial nor within the architecture that M3UA starts routing or
> loadsharing on SSN.  The more "stuff" which would be required is captured
> nicely in the SUA draft.
> 
> --Brian
> 
> Jeff Copley wrote:                                           (Tue, 31 Jul
2001
> 15:28:11)
> > Hi Brian,
> >
> > My current opinions are too biased to express my view of SUA.  I am
> > always open to change.
> >
> > With respect to carrying SCCP over M3UA, what "stuff"?  M3UA carries the
> > routing label.  It also carries the MTP-3 user.  So why can't I carry
> > any MTP-3 user?  I must be missing something (and don't say a brain,
> > Brian).
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jeff,
> > >
> > > Are you proposing that we strike SUA as a work item?  In that
> > > case M3UA is going to need a lot more "stuff" to fully support
> > > all classes of SCCP operation.
> > >
> > > ISUP is trivial.  If circuits are kept together by SLS or CIC
> > > there is not much to worry about.  Besides ISUP only requires
> > > a loadsharing scheme not a routing scheme.  SCCP requires both.
> > >
> > > --Brian
> > >
> > > Jeff Copley wrote:                                           (Tue, 31
Jul
> 2001 10:46:56)
> > > > Greg and Brian,
> > > >
> > > > M3UA is supposed to support the upper layers of SS7.  If I needed
both
> > > > ISUP and SCCP between two destinations, why would I want to develop
a
> > > > second UA such as SUA when M3UA (or M2PA) can acheive this in just
one
> > > > UA.  Am I missing something obvious? (It wouldn't be the first
time.)
> > > >
> > > > Jeff
> > > >
> > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > Greg,
> > > > >
> > > > > Please see comments inline...
> > > > >
> > > > > Greg Sidebottom wrote:                      (Tue, 31 Jul 2001
00:47:44)
> > > > > > Hi Brian,
> > > > > >
> > > > > > Responses below ...
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > > To: "sigtran" <[email-masked]>
> > > > > > Cc: "Greg Sidebottom" <[email-masked]>
> > > > > > Sent: Monday, July 30, 2001 11:17 AM
> > > > > > Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > > > > >
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > I don't see that rational basis on which M3UA can apply routing
keys
> > > > > > based on SCCP Subsystem number.  Can someone provide an example
on
> just
> > > > > > how this was expected to work?  (Particularly how SCCP
Management is
> > > > > > handled and OMAP SCCP Route Verification Tests.)  I think you
need SUA
> > > > > > here.
> > > > > >
> > > > > > [Greg] I'll try and remember but this is from a while ago.  I
think
> there
> > > > > > are valid cases where an MGC supports both ISUP and TCAP (lets
say for
> CCBS
> > > > > > or the CLASS equivalent service).  While I'd agree that SUA is
> probably a
> > > > > > better choice for the SCCP/TCAP traffic, the SG needs M3UA for
the
> ISUP
> > > > > > traffic already and it seems a lot of overhead to also support
SUA and
> > > > > > another SCTP association just for the TCAP traffic. ...
> > > > >
> > > > > Several comments here:
> > > > >
> > > > > "[I]t seems a lot of overhead to support SUA"--Actually, for this
> > > > > restricted case, very minimal functionality from SUA is required
> > > > > (perhaps only class 0 operation), all all the ASP management
functions
> > > > > are very close, really all that is required is supporting
different
> > > > > parameters in DUNA/DAVA/etc and the CLDT message.  For class 0/1
> > > > > operation SUA has no more overhead that M3UA and there is a lot of
> > > > > common parts.
> > > > >
> > > > > Quite frankly all that SUA needs to do is support two messages
(XFER
> > > > > and DUPU) and SUA could do M3UA's job quite easliy.  Class 0 SCCP
> > > > > without GT is really close to "bare" MTP and SUA handles this as
the
> > > > > trivial case.
> > > > >
> > > > > Perhaps you are looking at things backwards:  perhasp it is SUA
which
> > > > > should provide the functionality of MTP (as a pass-through to the
lower
> > > > > layer by shunting just a teeny bit of class 0), rather than M3UA
> > > > > attempting to provide the functionality of SCCP (by loading SS7
SCCP
> > > > > procedures into the M3UA at the SG).  Don't place SCCP
functionality
> > > > > into M3UA (above the MTP user interface)--allow SUA to pass-down
to MTP.
> > > > > This keeps SS7 functionality in the SS7 layers and UA
functionality in
> > > > > the UA layers.
> > > > >
> > > > > Nevertheless, it is not necessary to have multiple associations.
UA
> > > > > peers can be multiplexed over the same association by Payload
Protocol
> > > > > Identifier.  See the thread "Multiple UAs per Association".
> > > > >
> > > > > The simple example of CLASS belies the fact that the normal switch
has
> > > > > alot more to do in the SCCP realm (LNP queries, AIN/IN dips).
These
> > > > > types of transaction which the switch needs to do also require
> > > > > conversations, both class 0 and 1 support, and interworking
support on
> > > > > UDT/XUDT/LUDT, correlation of conversations, ...
> > > > >
> > > > > > ... So a RK could be used
> > > > > > to direct SCCP traffic for this service to an active MGC.
> > > > >
> > > > > This traffic can be routed on SI without SSN.  Unless you are
> > > > > considering some type of Global Title lookup as well, the SSN will
not
> > > > > tell you where the subscriber data is (which AS to use).  Although
> > > > > splitting traffic into ISUP and SCCP traffic makes sense,
splitting SCCP
> > > > > traffic by SSN does not, particularly in the case of CLASS-like
services
> > > > > where all queries are against a GT which reflects subscriber
> > > > > information.  The SSN traffic will need to be split further
(somewhere)
> > > > > for redundancy, so why do this?  Why not just loadshare all SCCP
traffic
> > > > > by SLS and perform the SCCP functions at the ASP?  SLS (extended
by CIC)
> > > > > is the only rational basis for loadsharing in M3UA, anyway.
> > > > >
> > > > > > I assume that
> > > > > > SCCP management is not perfect but it is probably not used
completely
> anyway
> > > > > > for these end-node to end-node services because SCCP management
will
> > > > > > probably not be concerned about the subsystem state of all the
> possible CCBS
> > > > > > peers (or support traffic Mix procedures or SOR/SOG for that
matter).
> > > > >
> > > > > Again, this belies the fact that these switches also have LNP dips
to
> > > > > perform which requires close monitoring of subsystem availability
(the
> > > > > status of the LNP database from the MGC).  Also, switches normally
do
> > > > > perform SSA/SSP/SST (which are SCMG) for LNP/IN/AIN.  (Not to
mention
> > > > > the requirements of an MSC).
> > > > >
> > > > > > I'm
> > > > > > not sure why OMAP SRVT would be an issue yet.  In any case, for
the
> SSN RK
> > > > > > cases I've seen discussed, OMAP SRVT could be ignored as it
wasn't
> used in
> > > > > > the SS7 network - OMAP SRVT isn't really ubiquitous in SS7
networks,
> as far
> > > > > > as I've seen anyway.
> > > > >
> > > > > You may have never noticed it.  An SG/MGC must be able to respond
to the
> > > > > message.
> > > > >
> > > > > >
> > > > > > Another case I have also seen is where M3UA is used from an SG
to a
> > > > > > database, but the SG didn't support SUA yet.  So the SG makes up
for
> this by
> > > > > > handling all the SCCP management on behalf of the database, at
least
> those
> > > > > > parts that don't have M3UA analogs (e.g., such as SSA, SST, SSP
etc).
> > > > >
> > > > > At the rate we are going SUA may beat M3UA to proposed standard.
It may
> > > > > be the other way around: the MGC has SUA but no M3UA yet and must
use
> > > > > the services of SUA to provide M3UA.  As I noted, all that SUA
needs to
> > > > > provide M3UA service as well is a DUPU and XFER message.
> > > > >
> > > > > >
> > > > > > But I don't really want to get into a long discussion of how
these
> cases can
> > > > > > or cannot work in M3UA or SUA.  And I wouldn't cry if we removed
SSNs
> from a
> > > > > > RK parameter in a REG REQ as I think removing it from the REG
REQ
> doesn't
> > > > > > prevent anyone from trying the above applications.  There is to
me a
> > > > > > difference between saying that the RK parameter in a REG REQ
doesn't
> have a
> > > > > > certain sub-parameter and saying RKs cannot use certain
information.
> Any RK
> > > > > > you want to dream up is possible, its just that it may not be
able to
> > > > > > configure it dynamically.  Of course not all RK permutations
make
> sense for
> > > > > > a given application/architecture so people need to be careful of
their
> > > > > > dreams.
> > > > >
> > > > > I think we need to draw a line here somewhere.  Otherwise, why not
try
> > > > > to do MTP2 with M3UA?  Why not try to do MTP3 with M2UA?  Why not
try to
> > > > > do TCAP with M3UA?  These "experiments" are deviations from the
> > > > > fundamental SIGTRAN architecture--the stuff of reasearch.  For the
sake
> > > > > of interoperability, the architecture needs to be adhered to and
> > > > > functional demarcations drawn.  Otherwise an ASP implementation
will
> > > > > never know what to expect from an SG implementation an visa versa.
> > > > >
> > > > > If the sake of M3UA is not interoperability between different SG
and AS
> > > > > implementations, why is the spec being written?  A vendor can do
> > > > > whatever they want within their own architecture now anyway.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I propose that we strike SSN from the Routing Key in the REG REQ
> > > > > > message.
> > > > > >
> > > > > > Also, TCAP Transaction Id is used as an example of a Routing
Key,
> > > > > > although there is no field for it in a REG REQ.  Distributing
messages
> > > > > > based on TCAP Transaction Ids doesn't strike me as rational
either.
> > > > > > I think you need TUA here.
> > > > > >
> > > > > > [Greg] There are some "tricks" that SGs can play with TRIDS for
> certain
> > > > > > applications/architectures.   TRIDS are not in the REG REQ but
like I
> said
> > > > > > above I don't see this as an impediment to an SG configuring
them in
> an RK-
> > > > > > they just couldn't be dynamically registered.  I think way back
some
> people
> > > > > > were thinking of using the TRID ranges as a way of ensuring that
the
> > > > > > responses get back to the right originating ASPs.  I haven't
studied
> the SUA
> > > > > > recently enough to know if this is still an issue though.
> > > > >
> > > > > M3UA can provide the service TCAP requires (via SCCP) by
loadsharing on
> SLS.
> > > > > The TCAP transaction Id coming off the SS7 network has no bearing
on
> > > > > anything and is not even unique unless it is taken into context
with the
> > > > > complete SCCP Calling Part Address (including Global Title).  The
> > > > > Transaction Id is local to the exchange betwen two TC-entities and
does
> > > > > need not even be unique by SSN.  AIN, for example, uses Global
Title in
> > > > > the Calling and Called Party addresses to determine the TC-entity.
This
> > > > > includes Transation Type and Address.  Correlation Ids in
conversations
> > > > > are next to impossible to attempt to handle in this fashion.
> > > > >
> > > > > Certainly M3UA is trying to be M3UA plus some of SUA plus some of
TUA
> > > > > here.  If that is the approach the WG wants to take, why not smash
all
> > > > > four drafts together (M2UA, M3UA, SUA, TUA) and call them SS7UA?
> > > > >
> > > > > >
> > > > > > I don't mind removing TRID as an example if it causes any
confusion -
> as
> > > > > > long as there is no restriction on the Routing Key in the SG.
If
> there are
> > > > > > future applications to include field "xyz" in a Routing Key then
I
> don't
> > > > > > think its not the role of the M3UA to say that it cannot be
done.
> > > > >
> > > > > I disagree.  I believe that M3UA should be constrained to the
SIGTRAN
> > > > > architecture and not try to skip upwards in protocol level.  I
believe
> > > > > that there would be more value in skipping downwards from SUA to
MTP
> > > > > than in skipping upwards from M3UA to SUA to TUA and on...  Again,
I
> > > > > believe that the line should be drawn.
> > > > >
> > > > > I believe that the same is true for ISUP.  CIC ranges have no
place in
> > > > > the Routing Key.  I believe that M3UA should consider them an
"extended"
> > > > > SLS for loadsharing, but routing on them makes no sense.
> > > > >
> > > > > --Brian
> > > > >
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > >    Greg
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I propose that we strike TCAP Transaction Id from the examples
of
> > > > > > Routing Keys.
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > > --
> > > > > > 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 ¦
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > 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]
> > > > >
> > > > > --
> > > > > 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]
> > > Content-Description: Card for Jeff Copley
> > > > begin:vcard
> > > > n:Copley;Jeff
> > > > tel;work:972.519.3758
> > > > x-mozilla-html:FALSE
> > > > org:Alcatel USA, Inc.
> > > > version:2.1
> > > > email;internet:[email-masked]
> > > > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> NSGAP;Plano;Texas;75075-5813;USA
> > > > x-mozilla-cpt:;20864
> > > > fn:Jeff Copley
> > > > end:vcard
> > > >
> > > >
> > > >
> > >
> > > Content-Description: footer
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
> [email-masked]
> > >
> > > --
> > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
> 
> Content-Description: footer
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> 
> 
> --
> 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]
> 
> 
> 
> 
> 
> 
> 
> 

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

-- 
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]
Date: Tue, 31 Jul 2001 17:28:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA last call
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

Sounds ok to me as long as we get another good kick at a draft version
before it moves to IESG.

Anyone else have any druthers?

--brian

Lyndon Ong wrote:                                          (Tue, 31 Jul 2001
15:14:26)
> Hi Brian,
> 
> What I'd like to do is make the process a bit more
> close-ended: as part of WG Last Call, make our comments
> against the v7 text, with suggested text changes if
> possible, then let the editor incorporate these into
> v8.  If v8 is satisfactory we can then move it to 
> IESG review, otherwise we can always have another
> round of WG Last Call.
> 
> Cheers,
> 
> Lyndon
>  
> --
> 
> On Tue, 31 Jul 2001 16:03:34   Brian F. G. Bidulock wrote:
> >Lyndon,
> >
> >There are a lot of changes outstanding to SUA: addition of sequence
> >control field to flags, addition of MP bits to flags parameter,
> >proposals to split flags parameter into separate parameters, division of
> >responsibilities for segmentation/reassmbly/sequencing, decoupled
> >operation additions of parameters to messages, addition of registration
> >procedure for SUA, removal of ASP capabilities parameter, addition of
> >Broadcast traffic mode, heartbeat updates, ...
> >
> >Also, the SUAv7 draft failed to capture all of the comments and issues
> >which have carried over from SUAv5 and SUAv6.
> >
> >I would like to see an SUAv8 which addresses the concesus which has been
> >reached on a good number of the above items, and most of those
> >outstanding from v5 and 6, before moving to Last Call: if only so that
> >we all know what we are reviewing.
> >
> >--Brian
> >
> >Lyndon Ong wrote:                                          (Tue, 31 Jul
2001 13:33:03)
> >> Folks,
> >> 
> >> M2UA seems to have gotten through Last Call in good shape.
> >> Next in line is SUA, which is already getting comments on
> >> the latest draft.  I'd like to poll the group on whether
> >> there are objections to starting WG Last Call on SUA, say,
> >> next Monday, going through to August 17th.  If so, we can
> >> compile a list of the comments on SUA so far, and number
> >> them as "early" Last Call comments.
> >> 
> >> The current draft is
http://ietf.org/internet-drafts/draft-ietf-sigtran-sua-07.txt.
> >> 
> >> Cheers,
> >> 
> >> L. Ong
> >> 
> >
> >-- 
> >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]
> >
> 
> 
> Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 25 Jul 2001 20:11:17 -0400
To: "Tomar, Nitin" <[email-masked]>,
        "'Lyndon Ong'" <[email-masked]>,
        "'Greg Sidebottom'" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Interface ID Mgmt

Nitin,

These changes are necessary.  Thanks.

Ken

At 10:00 AM 7/24/01 -0700, Tomar, Nitin wrote:
>Hi Ken, Lyndon, Greg,
>
>  Based on the mailing list discussion on Dynamic registration of Routing
Key
>in M3UA, I think the following changes is required in 
>  M2UA draft as well.
>
>regards
>Nitin
>
>
>Section 1.6.4 Definition of Layer Management / M2UA Boundary, shall also
>include following: 
>
>If dynamic registration of Link Key(s) is supported by the M2UA layer, the
>layer MAY support the following additional primitives
>M-Link Key_REG  Request
>Direction : LM -> M2UA
>Purpose: LM requests ASP to register Link Key with SG by sending REG REQ
>message.
>
>M-Link Key_REG  Confirm
>Direction :  M2UA -> LM
>Purpose: ASP reports to LM that it has successfully received a REG RSP
>message from SG.
>
>M-Link Key_REG  Indication
>Direction : M2UA -> LM
>Purpose: SG reports to LM that it has successfully processed an incoming
REG
>REQ message from ASP.
>
>M-Link Key_DEREG  Request
>Direction : LM -> M2UA
>Purpose: LM requests ASP to de-register Link Key with SG by sending DEREG
>REQ message.
>
>M-Link Key_DEREG  Confirm
>Direction : M2UA -> LM
>Purpose: ASP reports to LM that it has successfully received a DEREG RSP
>message from SG.
>
>M-Link Key_DEREG  Indication
>Direction : M2UA -> LM
>Purpose: SG reports to LM that it has successfully processed an incoming
>DEREG REQ message from ASP.
>
>Section 4.4.1  contains:
>
>" A unique method of Interface Identifier valid assignment at the SG/SGP is
>implementation dependent but must be guaranteed
>to be unique across all SGPs in an SG"
>The above text require a change similar to the proposed change in M3UA
>[refer thread : M3UA07: Routing Context assignment ]
>" A unique method of Interface Identifier valid assignment at the SG/SGP is
>implementation dependent but must be guaranteed
>to be unique for each Application server or Link Key served by SGP"
>
>Section 4.4.1 and 4.4.2
>
>Add the timers related to the IIM messages, the text can be same as M3UA
>[refer thread: M3UA06: Routing Key management procedure]