Subject: RE: M3UA07: Network Appearance

From: Hong Liu <[email-masked]>
Date: Mon, 6 Aug 2001 22:27:57 +0200

Brian, and others,

Sorry if I bring this long thread back to life. Have we reached any
conclusion on this thread at all?

Regards,

--Hong

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 2001Äê8ÔÂ1ÈÕ 15:01
To: sigtran
Subject: Re: M3UA07: Network Appearance

John,

So, are you talking the differnce between SG/MGC
operation and IPSP operation here?

What's the big deal in this discussion?  Choose
the one that works for you.  I see nothing missing.

--brian

John Schantz wrote:                                          (Wed, 01
Aug 2001 11:53:12)
> Brian,
> 
> 	In the "backhaul" scenario, the MGC or AS is really just an
> extension of the SG.  It is known not know to the SS7 community as an
> individual node but is known only via the PC assigned to the SG.  I
think
> this limits the SG's use and also limits the MGC's and AS's ability to
> connect to more than one SG.
> 
> 	In the non-backhaul scenario, the MGC, AS, and SG each have
their
> own assigned PC.  This allows the MGC and AS to connect to as many SGs
(or
> IPSPs) as it wants or needs to.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 1:45 PM
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
> 
> 
> John, Barry, Klaus,
> 
> Can you enlighten me on what it means for an MGC or SG
> to "own" a point code?  I am not familiar with that
> term.  The draft speaks of an SPMC where both the SG
> and MGC may be part of the SPMC.  An SPMC certainly
> "has" a point code--but, what does it mean to "own"
> a point code?
> 
> --Brian
> 
> John Schantz wrote:                                          (Wed, 01
Aug
> 2001 09:26:09)
> > Barry,
> > 
> > 	My model is correct, you are taking a very narrow view, and it
is
> > supported by M3UA.  It is the non-backhaul case of connecting an AS
with
> an
> > SG.  My AS is a member of the SS7 network (today), and when we
transition
> to
> > SS7 over IP, we are only changing its regular SS7 transport access
with IP
> > transport access to the SS7 network.
> > 
> > 	Just how do you think the current SS7 nodes will transition to
using
> > SS7 over IP?
> > 
> > John
> > 
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]
> > Sent: Wednesday, August 01, 2001 11:06 AM
> > To: sigtran
> > Subject: RE: M3UA07: Network Appearance
> > 
> > 
> > John,
> > 
> > Your model, in which you "view the AS and SG as independent SS7
nodes,
> each
> > owning 
> > their own PCs", is incorrect. 
> > 
> > The SG has a PC because it exists at the boundary of the SS7 and the
IP 
> > networks. The AS, which resides in the Media Gateway Controller,
exists
> only
> > in the IP network and thus has no PC.
> > 
> > Barry Nagelberg
> > Software Engineer
> > RadiSys, Corp.
> > Signaling Products Design Center
> > [email-masked]
> > +1-856-642-9229 x237
> > 
> > 
> > 
> > 
> > 
> > "Schantz, John" <[email-masked]>
> > 08/01/01 11:25 AM
> > Please respond to sigtran
> > 
> >  
> >         To:     "sigtran" <[email-masked]>
> >         cc: 
> >         Subject:        RE: M3UA07: Network Appearance
> > 
> > 
> > Howard,
> > 
> >                  My comments are below.
> > 
> > John
> > 
> > -----Original Message-----
> > From: May, Howard [mailto:[email-masked]]
> > Sent: Tuesday, July 31, 2001 11:22 AM
> > To: sigtran
> > 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....
> > 
> > [John]  We agree that the network should be used to make PCs unique
when
> > multiple networks are involved.  I disagree with the rest of the NA
> > definition:  "It is also necessary when an SG is configured as an
STP
> > hosting multiple point codes..."  An NA is not needed in this case.
STPs
> > host multiple point codes and they don't need anything more than the
PC to
> > separate the traffic.  "or when configured as multiple end nodes
within 
> > the
> > same network..."  To me this is just stating that it is acting as an
STP,
> > hence the PC is still sufficient.  The NA is only needed to define
the
> > logical network partition, it should not contain any PC information;
PCs 
> > are
> > already present in the messages.
> > 
> > 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).
> > 
> > [John]  OK, but the need for this may have gone away with the high
speed 
> > IP
> > connections.
> > 
> > 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?
> > 
> > [John]  I think you lost me here.  "Know the PC a message arrived
at?"
> > Isn't this the DPC?
> > 
> > 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...
> > 
> > [John]  As an AS, we will know what link (linkset) a message has
arrived 
> > on
> > but this is a local issue.
> > 
> > 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.
> > 
> > [John]  Here is where we are starting to disagree.  In my model, I
view 
> > the
> > AS and SG as independent SS7 nodes, each owning their own PCs.  From
the
> > AS's point of view, I don't want or need to know the network
configuration
> > of the SG.  I only need to know the SG's routing capabilities to
remote 
> > PCs.
> > Even a Backhaul view may have this same point of view. 
> > 
> > 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'
> > 
> > [John]  No, I would rather keep it at the network level since the SG

> > should
> > have multiple linksets to a single network (e.g., combined linkset).
> > 
> > Do you think there is a requirement to know this kind of
information?
> > 
> > [John] No.
> > 
> > > -----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]
> > 
> > 
> > 
> > 
> > 
> > ---
> > 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 15:09:37 -0500

Hong,

The conclusion is that the current situation is unsatisfactory
for the reasons cited.

The ultimate fate of NA, however, does not appear to have yet
been decided for M3UA (it has, it seems for SUA).

--Brian

Hong Liu wrote:                                              (Mon, 06 Aug 2001 22:27:57)
> 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/

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 07:53:03 -0500

I think the definition of NA should be clarified as soon as possible. My
personal opinion is to use NA to differentiate between different networks,
not between SPMCs. If an ASP is serving ASs on different point codes, then
correct handling of received DUNA, DAVA etc... is a responsibility of ASP
based on Affected PC and NA fields in the received message. NIF on ASP can
do the required analysis, which is out of the scope of M3UA.
I like definition of NA in draft6 more than the one in draft7-8. 

draft6:
"The Network Apperarence identifies an SS7 network context for the purpose
of logically separating the signalling traffic between the SG and the ASP
overa common SCTP Association."

draft7-8:
"The Network Appearence uniquely identifies an SS7 entty(Point Code) into an
SS7 netwrk, as presented by SG."
Especially the following sentence, which was added in draft7, I don't like:
"It is also necessary when an SG is configured as an STP hosting multiple
point codes, or wen configured as multiple end nodes within the same
network, in which case each point code is a separate network appearence
between the SG and the ASP over a common SCTP Association"

This sentence is in line with Brian's idea (and not in line with my idea ;)
) 
I always tend to think NA as an identifier for separate networks.

   Regards,
   Tolga Asveren

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, August 06, 2001 4:10 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Hong,

--Brian

Hong Liu wrote:                                              (Mon, 06 Aug
2001 22:27:57)

-- 
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: [email-masked]
Date: Tue, 7 Aug 2001 09:02:02 -0400

I completely agree with Tolga.

Barry Nagelberg

"Asveren, Tolga" <[email-masked]>
08/07/01 08:53 AM
Please respond to sigtran

draft6:

draft7-8:
"The Network Appearence uniquely identifies an SS7 entty(Point Code) into 
an
SS7 netwrk, as presented by SG."
Especially the following sentence, which was added in draft7, I don't 
like:
"It is also necessary when an SG is configured as an STP hosting multiple
point codes, or wen configured as multiple end nodes within the same
network, in which case each point code is a separate network appearence
between the SG and the ASP over a common SCTP Association"

This sentence is in line with Brian's idea (and not in line with my idea 
;)
) 
I always tend to think NA as an identifier for separate networks.

   Regards,
   Tolga Asveren

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, August 06, 2001 4:10 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Hong,

--Brian

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

---

---

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 7 Aug 2001 08:33:20 -0500

So do I.

Klaus

> From: [email-masked] [mailto:[email-masked]]
> Sent: August 07, 2001 9:02 AM
> To: sigtran
> > >              In the "backhaul" scenario, the MGC or AS is 
> really just 
> an
> > >              In the non-backhaul scenario, the MGC, AS, 
> and SG each 
> have
> > their
> > > >            My model is correct, you are taking a very 
> narrow view, 
> and it
> > is
> > > > > > > > > > John Schantz wrote:                         
>       (Mon,
> > > > > > > > > >                             /   \   |       
>      |   /
> > > > > > > > > >          \ /     |     /            |       
>      | \ /
> accessibility/restriction/congestion status
> > of
> > > > > > > > > > routesets from the
> > > > > > > > > > > >    SPMC.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Comments?
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > http://www.openss7.org/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 11:25:55 -0500

Tolga,

Asveren, Tolga wrote:                                    (Tue, 07 Aug 2001 07:53:03)
> I like definition of NA in draft6 more than the one in draft7-8. 

Sorry, doing the required analysis on DAVA etc. is *NOT* out of scope of
M3UA.  It is fully within the scope to address how to (successfully) process
M3UA messages.  There is not enough information in DAVA etc. to accomplish
this in all cases.  DAVA etc. will require a concerned point code field or the
Routing Context included in the kmessage in those cases.  When Routing Context
must be included, Network Appearance is unnecessary.

So, basically, if you want to keep your definition of Network Appearance
as Network Id, it goes away and is replaced by Concerned Point Code or Routing
Context in all messages except REG REQ.

--brian

> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 7 Aug 2001 11:15:07 -0700

I agree with Tolga, Barry, Klaus.

This is what I have been preaching for the last couple of weeks.  

Network Appearance should only be an assigned network ID that has only
"local significance" to the nodes involved (AS, connecting SGs, etc.).
Defining a Network Appearance this way allows the nodes and their messages
to be view as being in separate "overlaying" networks.  Hence, I would
assume that if multiple networks (and this does include multiple ITU
networks) are involved, almost all M3UA messages must have the Network
Appearance parameter present so that all point codes within the message
(ISUP, SCCP, and TCAP included) can be associated with a specific network
(overlay).  Its a local implementation issue of how the "Network Appearance"
is maintained through the MTP-users and their user applications.

The SSNM (SS7 Signalling Network Management) message should never include
Routing Context.  They must include the Affected PCs only, not Routing
Context.  You need to define a separate management message set if you want
to manage entities any finer than Affected PCs (plus user for the DUPU).

John  

> Sent: Tuesday, August 07, 2001 11:26 AM
> To: sigtran
>    (Wed, 01
> really just an
>      (Wed, 01
> narrow view, and it
>      \_|_
> > > > > > > > > > >           X      |     |            |     
> > > > > > > > > > >          / \     |    /             |     
>       _|_/
> > > > > > > > > > >          -----| STP |               |     

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 13:38:08 -0500

Brian,

For me the real important issue is keeping NA as just "network identifier". 
If something is to be added to management messages I favor the idea to have
the granularity on point code, rather than route context. This will be more
similar to the case in SS7 network I believe. So, if a concerned point code
will be added to DAVAetc..., then we will still need NA there, but with
"network identifier" meaning.
And I still think, one can live without concerned point codes in M3UA
management messages. Consider the following configuration:

        +---------------------------+
        |    AS1       |   AS2      |
        |    1-1-1     | 2-2-2      |
        +--------------+------------+
        |                           |
        |          ASP1             |
        +---------------------------+
                  |
                  | 
                  |
                  |
        +----------------------------+
        |  AS1       |    AS2        |
        |  1-1-1     |   2-2-2       |
        +------------+---------------+
        |                            |
        |           SG1              |
        +----------------------------+

(NA=1 for AS1 and AS2 in ASP1 and SG1)

SG1 receives MTP-PAUSE for 3-3-3. It is send as DUNA with NA=1, APC= 3-3-3.
NIF at ASP side sends MTP-PAUSE to SS7 User Parts in 1-1-1 and in 2-2-2.

I think what Brian is proposing is to send two DUNAs from SG1 to ASP1, one
per PC (or per AS?) So the difference between two approaches is, in one of
them a distribution of network management message is done in SG(Brian's
approach), in the other one in ASP-NIF.

I only see the need for something like "Concerned Point Code" for DUPU.
Because MTP-STATUS-IND is sent only to the node, which has sent a
MTP-TRANSFER-REQUEST to the node with no user part. So, NIF at ASP should be
able to get a concerned point code from DUPU, to be able to sent
MTP-STATUS-IND only to the correct SS7 User Part. Another approach could be
to process it for every PC (in our example both for 1-1-1 and for
2-2-2)(which ,I think, can still work but also does not match exactly with
SS7 behaviour). 

As final word:
1) I want to keep NA only as "Network Indicator"
2) I think concerned point code is needed only for DUPU
3) I think to use concerned point code is better than using route context
,when needed, because also in SS7 the granularity on MTP3 level is point
code.

    Regards,
    Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 12:26 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

Asveren, Tolga wrote:                                    (Tue, 07 Aug 2001
07:53:03)

Sorry, doing the required analysis on DAVA etc. is *NOT* out of scope of
M3UA.  It is fully within the scope to address how to (successfully) process
M3UA messages.  There is not enough information in DAVA etc. to accomplish
this in all cases.  DAVA etc. will require a concerned point code field or
the
Routing Context included in the kmessage in those cases.  When Routing
Context
must be included, Network Appearance is unnecessary.

So, basically, if you want to keep your definition of Network Appearance
as Network Id, it goes away and is replaced by Concerned Point Code or
Routing
Context in all messages except REG REQ.

--brian

an
;)

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

---

---

---

From: Dan Brendes <[email-masked]>
Date: Tue, 7 Aug 2001 14:46:41 -0400

i agree w/ john's summary of how this should work.  i believe the SSNM messages
(such as DUNA) need an affectedPC + a network appearance parm, but not a routing
context.

"Schantz, John" <[email-masked]> on 08/07/2001 02:15:07 PM

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

John

> > > Sent: 2001

Äê8ÔÂ1ÈÕ 15:01
> > > > > > > > > > point cod
e in the SS7 networks.  It is also
> necessary

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 14:29:40 -0500

John,

You are forgetting that Network Appearance as Network Id is
insufficient in SNMM for multiple network attachments.  M3UA
permitting multiple SPMC and multiple network attachments requires
an optional SPMC identifier (concerned point code, routing context)
in SNMM messages.  That is one thing that this thread has shown
clearly.

I object strongly to any proposal to put Network Appearance back
to Network Id without including concerned point code or routing
context in the SNMM messages, as it makes implementations with
multiple SPMC and network attachments unworkable.

--brian

John Schantz wrote:                                (Tue, 07 Aug 2001 11:15:07)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 14:35:49 -0500

Tolga,

Asveren, Tolga wrote:                                    (Tue, 07 Aug 2001 13:38:08)
> "network identifier" meaning.

I would agree with a proposal to put Network Appearance back to be Network Id
if the Concerned Point Code parameter was included as optional on all SNMM
messages (it already appears in SCON), with the requirement that it MUST be
included in SNMM messages when it is required to distinguish SNMM messages for
different SPMCs.

> management messages. Consider the following configuration:

Please see multiple network attachment examples earlier on this thread.
For multiple network attachments it becomes necessary to distinguish all
SNMM messages, not just DUPU.  You do no see this in your example because
you are not considering what the SS7 network will do an what attachments
there are to the SS7 network.

> ,when needed, because also in SS7 the granularity on MTP3 level is point

I would agree, except that concerned point code should be included when
necessary on all SNMM messages.  I agree that a concerned point code
parameter woule obviate the need for routing context in SNMM messages.

-brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 14:37:33 -0500

Dan,

Please don't send MIME mail to the reflector.

Dan Brendes wrote:                                            (Tue, 07 Aug 2001 14:46:41)
> (such as DUNA) need an affectedPC + a network appearance parm, but not a routing

If not routing context then concerned point code is required.  Please
see multiple network attachment examples earlier in this thread.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 7 Aug 2001 12:40:29 -0700

Brian,
	The SNMM messages should be kept "clean", i.e., they should only
handle affected point codes for a single network appearance.  The SNMM
messages would be complicated by mixing affected point codes from different
network appearances, and the processing of the messages at the AS and SG
would be complicated too.  If you keep the SNMM messages "clean", then all
that is needed is one network appearance parameter and the affected point
codes for that network appearance.

	Why do you want to complicate processing at the SG and the AS?

John

> Sent: Tuesday, August 07, 2001 2:30 PM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 7 Aug 2001 12:44:05 -0700

Brian,
	I can not agree to this.  A single SNMM message should NOT handle
affected point codes from multiple network appearances.  See my other
response to you on this.

John

> Sent: Tuesday, August 07, 2001 2:36 PM
> To: sigtran
> narrow view, and
> > it
> > > > > > 	Just how do you think the current SS7 nodes 
> will transition
> > to
> > > > using
> > > > > > SS7 over IP?
> > > > > > 
> > > > > > John
> > > > > > 
> > > > > > > > > > > >                              ___     /  
> > > > > > > > > > > >                             \___/   |   
> > > > > > > > > > > >                            //       |   
> > > > > > > > > > > >                           / |       | 
> Signalling |
> > > > > > > > > > > >                          / /        |   
> Gateway  |
> > > > > > > > > > > >                         /  |        |   
> > > > > > > > > > > >                        /  /         |   
> > > > > > > > > > > >                _____  /   |         |   
> > > > > > > > > > > >               |     |/   /          |   
> > > > > > > > > > > >              /|_____|   /           |   
>    \___  |
> > > > > > > > > > > >             \  __|__ /              |   
>     ___/ |
> > > > > > > > > > > >               |_____|               |   
> > > > > > > > > > > > > >     0                   1           
>         2 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 15:23:18 -0500

John,

John Schantz wrote:                                          (Tue, 07 Aug 2001 12:40:29)
> codes for that network appearance.

Concerned point code is required: see multiple network attachment examples
earlier in this thread.  (This is the DPC from the SS7 SNTM message.)  It is
not complicated.  Just as Network Id, it is not required in all messages in
all configurations, just some configurations.  It would be an optional
parameter which only must be included when needed.

I would prefer Routing Context to be consistent with SUA, but would agree
to an optional (but required in certain circumstances) Concerned Point Code
parameter in all SNMM messages.

> 	Why do you want to complicate processing at the SG and the AS?

For the same reason the TFP complicated with a DPC.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 15:24:19 -0500

John,

You have neither an argument nor a proposal.

--Brian

John Schantz wrote:                                          (Tue, 07 Aug 2001 12:44:05)
> > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ---

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 7 Aug 2001 13:53:01 -0700

Brian,
	If you requesting that the SNMM have DPCs and OPCs like there peer
SS7 Network Management Messages (TFP, etc.), I would support this.  I don't
like to implicitly imply anything in network management messages.  Right now
the AS may need to implicitly derive the DPC.  But more importantly, the AS
must implicitly derive the OPC for the SNMM from the SGP/association the
SNMM was received on.  In regular SS7 networks, if the Network Management
message was not generated by the adjacent node (in most cases STP), the
message is ignored.  This is security feature to prevent remote nodes from
screwing up the network.  Also, STP would discard/stop any message that it
received with its PC as the OPC.

	Hence, not having the OPC in the message is a big hole.  I would
like to see DPC also.

John

> Sent: Tuesday, August 07, 2001 3:23 PM
> To: sigtran
> (Tue, 07 Aug 2001 12:40:29)
> > Brian,

---

---

From: Hong Liu <[email-masked]>
Date: Wed, 8 Aug 2001 00:36:21 +0200

Hi, Brian and others,
 
Since I was the one bringing up this thread again, I feel "obligated" to
chip in what I feel about this issue. In case my thoughts have been
already expressed and discussed, please take them as refresh of the
memory since this thread has been very long, -:)
 
I guess there are two issues involved here: the semantics of Network
Appearance and the need to demux the management messages from a common
SCTP association betweeen an SGP and an ASP.
 
From the semantical perspective, I agree with John, Klaus, Tolga and
Barry about the definition of Network Appearance as a network ID, when
an SGP is sitting on multiple SS7 networks. What Brian has been arguing
is that the parameter itself is NOT sufficient for an ASP to distinguish
SNMM from different point codes an SGP represents, and hence he needs
some mechanism to do that. (Brian, please correct me if I misunderstood
your point.)
 
In fact, the problem manifests itself for an SGP attaching to a single
SS7 network, but bearing more than one point code, and there are
different routes into the SS7 network from these point codes. (See
Brian's example in the earlier part of the thread.) In this case, the
ASP needs to update its own routing information based on the SNMM
messages relayed from the SGP. Hence, the problem actually has little to
do with Network Appearance for multiple networks.
 
To make the example more concrete, say the SGP has two PCs A and B, and
A and B have different linksets into the SS7 network. The fact that an
SS7 signaling point C is not reachable from A does not necessarily imply
that it is not reachable from B. Suppose C is still reachable from B,
then the ASP, when receiving an DUNA message from the SGP, needs to
differentiate that the unavailability of C is through A, not through B,
and updates its routesets accordingly. It seems to me there are three
solutions:
(1) Establish separate SCTP associations between SGP and ASP for each PC
pair;
(2) Add PC A also in the DUNA message as an affected point code;
(3) Use a separate parameter to convey the information of "reachability
via A in the SGP"
 
Option (1) mirrors the linkset concept in current SS7 networks, but does
not seem to be favored by the M3UA community. Option (3) is in essence
what Brian was trying to do. I think Brian's intention was not to
introduce another parameter, so he tried to maximize the use of Network
Appearance with additional information. (which caused objections from
semantics viewpoint.) Option (2) seems to be less intrusive, but
additional procedures need to be specified as how to interpret "A" in
this context. For example, if A is the only affected PC in DUNA, then it
means the SGP is disconnected from the SS7 network via PC A, etc... In
any case, I don't have strong opinions on any options above as long as
we find a solution to this problem.
 
The ultimate question, of course, is whether this example has any real
meaning. I will leave it to the experts in SS7 operations to justify
that. The beauty of M3UA is that it is flexible to accommodate different
usage scenarios, many of which seem to be extensions to what SS7 can do
today. However, it also places the burden on the protocol itself in
order to meet the needs in these scenarios...
 
Cheers,
 
--Hong

-----Original Message----- 
From: Brian F. G. Bidulock 
Sent: 2001-8-7 (星期二) 18:25 
To: sigtran 
Cc: 
Subject: Re: M3UA07: Network Appearance

	Tolga,
	
	Asveren, Tolga wrote:                                    (Tue,
07 Aug 2001 07:53:03)
	> I like definition of NA in draft6 more than the one in
draft7-8.
	
	Sorry, doing the required analysis on DAVA etc. is *NOT* out of
scope of
	M3UA.  It is fully within the scope to address how to
(successfully) process
	M3UA messages.  There is not enough information in DAVA etc. to
accomplish
	this in all cases.  DAVA etc. will require a concerned point
code field or the
	Routing Context included in the kmessage in those cases.  When
Routing Context
	must be included, Network Appearance is unnecessary.
	
	So, basically, if you want to keep your definition of Network
Appearance
	as Network Id, it goes away and is replaced by Concerned Point
Code or Routing
	Context in all messages except REG REQ.
	
	--brian

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 17:24:19 -0500

Hong,
 
I think another solution would be, splitting SG in Brian's example in two
SG's, so that every SG serves only one SEP. Then one would have different
associations from ASP to two different SGs. This would solve the problem.
 
    Regards,
     Tolga

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 6:36 PM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Hi, Brian and others,
 
Since I was the one bringing up this thread again, I feel "obligated" to
chip in what I feel about this issue. In case my thoughts have been already
expressed and discussed, please take them as refresh of the memory since
this thread has been very long, -:)
 
I guess there are two issues involved here: the semantics of Network
Appearance and the need to demux the management messages from a common SCTP
association betweeen an SGP and an ASP.
 
From the semantical perspective, I agree with John, Klaus, Tolga and Barry
about the definition of Network Appearance as a network ID, when an SGP is
sitting on multiple SS7 networks. What Brian has been arguing is that the
parameter itself is NOT sufficient for an ASP to distinguish SNMM from
different point codes an SGP represents, and hence he needs some mechanism
to do that. (Brian, please correct me if I misunderstood your point.)
 
In fact, the problem manifests itself for an SGP attaching to a single SS7
network, but bearing more than one point code, and there are different
routes into the SS7 network from these point codes. (See Brian's example in
the earlier part of the thread.) In this case, the ASP needs to update its
own routing information based on the SNMM messages relayed from the SGP.
Hence, the problem actually has little to do with Network Appearance for
multiple networks.
 
To make the example more concrete, say the SGP has two PCs A and B, and A
and B have different linksets into the SS7 network. The fact that an SS7
signaling point C is not reachable from A does not necessarily imply that it
is not reachable from B. Suppose C is still reachable from B, then the ASP,
when receiving an DUNA message from the SGP, needs to differentiate that the
unavailability of C is through A, not through B, and updates its routesets
accordingly. It seems to me there are three solutions:
(1) Establish separate SCTP associations between SGP and ASP for each PC
pair;
(2) Add PC A also in the DUNA message as an affected point code;
(3) Use a separate parameter to convey the information of "reachability via
A in the SGP"
 
Option (1) mirrors the linkset concept in current SS7 networks, but does not
seem to be favored by the M3UA community. Option (3) is in essence what
Brian was trying to do. I think Brian's intention was not to introduce
another parameter, so he tried to maximize the use of Network Appearance
with additional information. (which caused objections from semantics
viewpoint.) Option (2) seems to be less intrusive, but additional procedures
need to be specified as how to interpret "A" in this context. For example,
if A is the only affected PC in DUNA, then it means the SGP is disconnected
from the SS7 network via PC A, etc... In any case, I don't have strong
opinions on any options above as long as we find a solution to this problem.
 
The ultimate question, of course, is whether this example has any real
meaning. I will leave it to the experts in SS7 operations to justify that.
The beauty of M3UA is that it is flexible to accommodate different usage
scenarios, many of which seem to be extensions to what SS7 can do today.
However, it also places the burden on the protocol itself in order to meet
the needs in these scenarios...
 
Cheers,
 
--Hong

-----Original Message----- 
From: Brian F. G. Bidulock 
Sent: 2001-8-7 (星期二) 18:25 
To: sigtran 
Cc: 
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

an
;)
> From: Brian F. G. Bidulock [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 17:53:09 -0500

Hong,
 
I think another solution would be, splitting SG in Brian's example in two SG's, so that every SG serves only one SEP. Then one would have different associations from ASP to two different SGs. This would solve the problem.
 
    Regards,
     Tolga

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 6:36 PM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Hi, Brian and others,
 
Since I was the one bringing up this thread again, I feel "obligated" to chip in what I feel about this issue. In case my thoughts have been already expressed and discussed, please take them as refresh of the memory since this thread has been very long, -:)
 
I guess there are two issues involved here: the semantics of Network Appearance and the need to demux the management messages from a common SCTP association betweeen an SGP and an ASP.
 
From the semantical perspective, I agree with John, Klaus, Tolga and Barry about the definition of Network Appearance as a network ID, when an SGP is sitting on multiple SS7 networks. What Brian has been arguing is that the parameter itself is NOT sufficient for an ASP to distinguish SNMM from different point codes an SGP represents, and hence he needs some mechanism to do that. (Brian, please correct me if I misunderstood your point.)
 
In fact, the problem manifests itself for an SGP attaching to a single SS7 network, but bearing more than one point code, and there are different routes into the SS7 network from these point codes. (See Brian's example in the earlier part of the thread.) In this case, the ASP needs to update its own routing information based on the SNMM messages relayed from the SGP. Hence, the problem actually has little to do with Network Appearance for multiple networks.
 
To make the example more concrete, say the SGP has two PCs A and B, and A and B have different linksets into the SS7 network. The fact that an SS7 signaling point C is not reachable from A does not necessarily imply that it is not reachable from B. Suppose C is still reachable from B, then the ASP, when receiving an DUNA message from the SGP, needs to differentiate that the unavailability of C is through A, not through B, and updates its routesets accordingly. It seems to me there are three solutions:
(1) Establish separate SCTP associations between SGP and ASP for each PC pair;
(2) Add PC A also in the DUNA message as an affected point code;
(3) Use a separate parameter to convey the information of "reachability via A in the SGP"
 
Option (1) mirrors the linkset concept in current SS7 networks, but does not seem to be favored by the M3UA community. Option (3) is in essence what Brian was trying to do. I think Brian's intention was not to introduce another parameter, so he tried to maximize the use of Network Appearance with additional information. (which caused objections from semantics viewpoint.) Option (2) seems to be less intrusive, but additional procedures need to be specified as how to interpret "A" in this context. For example, if A is the only affected PC in DUNA, then it means the SGP is disconnected from the SS7 network via PC A, etc... In any case, I don't have strong opinions on any options above as long as we find a solution to this problem.
 
The ultimate question, of course, is whether this example has any real meaning. I will leave it to the experts in SS7 operations to justify that. The beauty of M3UA is that it is flexible to accommodate different usage scenarios, many of which seem to be extensions to what SS7 can do today. However, it also places the burden on the protocol itself in order to meet the needs in these scenarios...
 
Cheers,
 
--Hong

-----Original Message----- 
From: Brian F. G. Bidulock 
Sent: 2001-8-7 (星期二) 18:25 
To: sigtran 
Cc: 
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

> From: Brian F. G. Bidulock [ mailto:[email-masked] <mailto:[email-masked]> ]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 18:10:31 -0500

Tolga,

That is not a workable solution in fully associated networks: a single
SPMC may be conntext to the network via multiple F-link connections,
each which serves as a separate network attachment.  Instead of 1 SG
with 192 F-links, you would have this be 192 SGs, each with 1 F-link,
requiring 192 separate SCTP associations.  Separating into separate SGs
does not scale in fully associated networks.

This is not terribly different than Hong's solution (2), which is
equally unworkable for the same reason.

--brian

Asveren, Tolga wrote:                                    (Tue, 07 Aug 2001 17:53:09)
> Hong,
>  
> I think another solution would be, splitting SG in Brian's example in
> two SG's, so that every SG serves only one SEP. Then one would have
> different associations from ASP to two different SGs. This would solve
> the problem.
>  
>     Regards,
>      Tolga
> 
> Since I was the one bringing up this thread again, I feel "obligated"
> to chip in what I feel about this issue. In case my thoughts have been
> >Barry about the definition of Network Appearance as a network ID,
> >when an SGP is sitting on multiple SS7 networks. What Brian has been
> >arguing is that the parameter itself is NOT sufficient for an ASP to
> >distinguish SNMM from different point codes an SGP represents, and
> >hence he needs some mechanism to do that. (Brian, please correct me
> >if I misunderstood your point.)
>  
> messages relayed from the SGP.  Hence, the problem actually has little
> to do with Network Appearance for multiple networks.
>  
> To make the example more concrete, say the SGP has two PCs A and B,
> and A and B have different linksets into the SS7 network. The fact
> that an SS7 signaling point C is not reachable from A does not
> necessarily imply that it is not reachable from B. Suppose C is still
> reachable from B, then the ASP, when receiving an DUNA message from
> the SGP, needs to differentiate that the unavailability of C is
> through A, not through B, and updates its routesets accordingly. It
> seems to me there are three solutions:
>
> Option (1) mirrors the linkset concept in current SS7 networks, but
> does not seem to be favored by the M3UA community. Option (3) is in
> essence what Brian was trying to do. I think Brian's intention was not
> to introduce another parameter, so he tried to maximize the use of
> Network Appearance with additional information. (which caused
> objections from semantics viewpoint.) Option (2) seems to be less
> intrusive, but additional procedures need to be specified as how to
> interpret "A" in this context. For example, if A is the only affected
> PC in DUNA, then it means the SGP is disconnected from the SS7 network
> via PC A, etc... In any case, I don't have strong opinions on any
> options above as long as we find a solution to this problem.
>  
> that. The beauty of M3UA is that it is flexible to accommodate
> different usage scenarios, many of which seem to be extensions to what
> SS7 can do today. However, it also places the burden on the protocol
> itself in order to meet the needs in these scenarios...
>  
> Cheers,
>  
> --Hong
>  
>  
> Sent: 2001-8-7 (???) 18:25 
> To: sigtran 
> Cc: 
> > I think the definition of NA should be clarified as soon as
> > possible. My personal opinion is to use NA to differentiate between
> > different networks, not between SPMCs. If an ASP is serving ASs on
> > different point codes, then correct handling of received DUNA, DAVA
> > etc... is a responsibility of ASP based on Affected PC and NA fields
> > in the received message. NIF on ASP can do the required analysis,
> > which is out of the scope of M3UA.  I like definition of NA in
> > draft6 more than the one in draft7-8.
> 
> Sorry, doing the required analysis on DAVA etc. is *NOT* out of scope
> of M3UA.  It is fully within the scope to address how to
> (successfully) process M3UA messages.  There is not enough information
> in DAVA etc. to accomplish this in all cases.  DAVA etc. will require
> a concerned point code field or the Routing Context included in the
> kmessage in those cases.  When Routing Context must be included,
> Network Appearance is unnecessary.
> 
> Appearance as Network Id, it goes away and is replaced by Concerned
> Point Code or Routing Context in all messages except REG REQ.
> 
> --brian
> 
> 
> >
> > draft6:
> > "The Network Apperarence identifies an SS7 network context for the
> > purpose of logically separating the signalling traffic between the
> > SG and the ASP overa common SCTP Association."
> >
> > draft7-8:
> > "The Network Appearence uniquely identifies an SS7 entty(Point Code)
> > into an SS7 netwrk, as presented by SG."
> > Especially the following sentence, which was added in draft7, I
> > don't like: "It is also necessary when an SG is configured as an STP
> > hosting multiple point codes, or wen configured as multiple end
> > nodes within the same network, in which case each point code is a
> > separate network appearence between the SG and the ASP over a common
> > SCTP Association"
> >
> > This sentence is in line with Brian's idea (and not in line with my
> > idea ;))
> > The conclusion is that the current situation is unsatisfactory for
> > the reasons cited.
> >
> > The ultimate fate of NA, however, does not appear to have yet been
> > decided for M3UA (it has, it seems for SUA).
> >
> > --Brian
> >
> > > Sorry if I bring this long thread back to life. Have we reached
> > > any conclusion on this thread at all?
> > >
> > > Regards,
> > >
> > > --Hong
> > >

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 18:12:41 -0500

Tolga,

Sorry, that should read "Hong's solution (1)..." (i.e. multiple associations,
one per network attachment).

--brian

Brian F. G. Bidulock wrote:                               (Tue, 07 Aug 2001 18:10:31)
> This is not terribly different than Hong's solution (2), which is
                                             ^^^^^^^^^^^^

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 18:19:41 -0500

Brian,

Then what about running SG in STP mode with its own point code? In fact I don't like the configuration where SG is working in SEP mode with more than one point code.

Just another try ;)

      Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 7:13 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

                                             ^^^^^^^^^^^^

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 18:41:34 -0500

Tolga,

That would be the IPSP case, I believe.  M3UA has to work that
way too.  There is a long dicussion on multiple STPs on another
thread.  If your meaning that the SG is an SP with the transfer
function (not an STP, there is just one of them), then, again,
it is the IPSP case.  This is running with a modified MTP and
everything gets real blurry.  M3UA does not address the IPSP
case sufficiently in the draft to even comment.

M3UA must address the backhaul case with SEP, because STP or
"transfer function" interconnect might not be available to the
operator.

--brian

Asveren, Tolga wrote:                                    (Tue, 07 Aug 2001 18:19:41)
> Brian,
> 
> Then what about running SG in STP mode with its own point code? In fact I
> don't like the configuration where SG is working in SEP mode with more than
> one point code.
> 
> Just another try ;)
> 
>       Tolga
> 

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Aug 2001 18:53:50 -0500

Brian,

What I mean is that to have SG with its own point code (different than the ones of SEPs in your example).
Because, I think, the real reason why there is a problem with management messages is that two SEPs have different connectivity to SS7 network in your example. Separating SEPs from SG will make this connectivity again single.
I know SG can also run in SEP mode. What I am only saying is that, if there would be a restriction saying that a SG cannot have more than one SEP with different network connectivity, then your example wouldn't be a valid configuration, and there wouldn't be a problem.

     Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 7:42 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 19:40:30 -0500

Tolga,

But then M3UA would be imposing a restriction of the configuration
of SG/ASP.  It is M3UAs objective to not impose such a restriction,
and doing so for the sake of not permitting an optional parameter
is a message is absurd.

--brian

Asveren, Tolga wrote:                             (Tue, 07 Aug 2001 18:53:50)
> Brian,
> 
> What I mean is that to have SG with its own point code (different than
> the ones of SEPs in your example).  Because, I think, the real reason
> why there is a problem with management messages is that two SEPs have
> different connectivity to SS7 network in your example. Separating SEPs
> from SG will make this connectivity again single.  I know SG can also
> run in SEP mode. What I am only saying is that, if there would be a
> restriction saying that a SG cannot have more than one SEP with
> different network connectivity, then your example wouldn't be a valid
> configuration, and there wouldn't be a problem.
> 
>      Tolga
>             
>             
> 

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 19:50:29 -0500

Tolga,

Also, the restriction you propose does not work for the fully
associated (F-link connected) network.  One cannot restrict
an SEP to not be connected multiply to the network because
multiple F-link connections in fully associated networks (common
in Europe, I hear) would also be restricted.  This would make
M3UA useless in a large portion of the deployed SS7 networks.

I'm sorry, you can twist it this way and that way and the same
problem arises.  The simplest way to accomplish this is to
relieve the problem by adding an optional parameter to the SNMM
messages which must be included in these otherwise problematic
configurations.

I don't understand anyone's resistance to an optional parameter
(Routing Context or Concerned Point Code) which is immediately
available at the SG to be populated in the message and which is
immediately usable at the ASP so that the ASP can ignore the
idiosynchrasies of these configurations.

Its simple, just add the parameter.  Otherwise you can talk
yourself blue in the face for several months.

It just so happens that including Routing Context obviates the
need for Network Appearance, and even adding a Concerned Point
Code with an embedded Network Id (high byte), obviates the need
for Network Appearance as well.

Network Appearance is primarly useless because there is no
corresponding concept in SS7 (unless you consider the equally
useless NI bits in the RL as equivalent).

--brian

Brian F. G. Bidulock wrote:                        (Tue, 07 Aug 2001 19:40:30)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 8 Aug 2001 07:26:48 -0500

Brian,

I agree that the restriction I have proposed would limit the flexibility of
M3UA, although personally I don't like a SG working in SEP mode with
multiple point codes. But it seems nobody else is complaining. 
But the other thing I have proposed will solve the problem I think, to have
SG with its own point code. Then one can have as many direct links as
desired to any other destination from SG. What is wrong with this
configuration? One disadvantage would be, that one uses one more point code
for SG, but I think this is acceptable in this case. The configuration I am
speaking of is below. 

                   +-------+
                   | ASP1  | (AS1 with DPC = 5.255.3)
                   +-------+  (AS2 with DPC = 5.255.4)
                      |
                      |
                      |
                   +--------+ (AS1 with DPC = 5.255.3)
                   |  SG1   | (AS2 with DPC = 5.255.4)
                   +--------+ SS7 PC of SG1 = 5.255.6
                    |    | |
                  +---+  | |
          200.1.4 |SEP|  | |
                  +---+  | +------------------+
                    | |  |                    |
                    | |  |                    |
                    | |  +---+                +----+
                    | + -|STP|----------------| STP|
                    |    +---+                +----+
                    |                            |
                    +----------------------------+

The goal is by no means to resist adding a new parameter ;)

    Regards,
    Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 8:50 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

Brian F. G. Bidulock wrote:                        (Tue, 07 Aug 2001
19:40:30)
> Asveren, Tolga wrote:                             (Tue, 07 Aug 2001
18:53:50)
> > > > > (1) Establish separate SCTP associations between SGP and ASP for
each
> > > > > PC pair;
scope
> > > > > > The conclusion is that the current situation is unsatisfactory
for
> > > > > > The ultimate fate of NA, however, does not appear to have yet
been

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

---

---

---

From: Hong Liu <[email-masked]>
Date: Wed, 8 Aug 2001 16:59:16 +0200

Hi, Tolga,
 
One solution to the A-link congestion problem is to assign multiple
point codes to an SEP, as the A linkset is limited to 16 links. (There
may be other reasons to have multiple point codes.) I don't know how
many SEPs in the SS7 networks can support this feature but it is (I
heard) one solution that is being used today. Supporting multiple point
codes in an SEP definitely introduce additional complexity in management
(as seen in this discussion), maybe that is why not many SEPs are able
to do that today. Of course, there are other solutions to the A-link
capacity problem, such as high speed links.
 
In the meantime, I think the problem we are talking about here goes
beyond just having multiple point codes in an SGP, irrespective of
whether the network is quasi-associated or fully associated. Only when
the SGP has different connectivity into the same SS7 network with
different point codes, i.e. partitioning the SS7 network, will the
problem occur. Is such connectivity scheme being used in today's SS7
networks? I don't know for sure. On the other hand, with M3UA, we
already go beyond existing SS7 network configurations, as illustrated in
your diagram.
 
Although I hate to impose restrictions on configurations, it would be
helpful to crystalize the underlying architectural models M3UA intends
to support. It seems to me that many discussions on the list about M3UA,
including this thread, boil down to this issue: different people seem to
have different assumptions. Maybe now it is time to put them all on the
table.
 
Cheers,
 
--Hong
 
-----Original Message----- 
From: Asveren, Tolga 
Sent: 2001-8-8 (星期三) 14:26 
To: sigtran 
Cc: 
Subject: RE: M3UA07: Network Appearance

	Brian,
	
	I agree that the restriction I have proposed would limit the
flexibility of
	M3UA, although personally I don't like a SG working in SEP mode
with
	multiple point codes. But it seems nobody else is complaining.
	But the other thing I have proposed will solve the problem I
think, to have
	SG with its own point code. Then one can have as many direct
links as
	desired to any other destination from SG. What is wrong with
this
	configuration? One disadvantage would be, that one uses one more
point code
	for SG, but I think this is acceptable in this case. The
configuration I am
	speaking of is below.
	
	                   +-------+

	    Regards,
	    Tolga
	
	-----Original Message-----
	From: Brian F. G. Bidulock [mailto:[email-masked]]
	Sent: Tuesday, August 07, 2001 8:50 PM
	To: sigtran
	Subject: Re: M3UA07: Network Appearance

	Tolga,

	

	
	
	--brian
	
	Brian F. G. Bidulock wrote:                        (Tue, 07 Aug
2001
	19:40:30)
	18:53:50)
	> > Asveren, Tolga wrote:
(Tue, 07 Aug
	2001 18:19:41)
	> > > Brian,
	> > >
	> > > Then what about running SG in STP mode with its own point
code? In
	fact I
	> > > don't like the configuration where SG is working in SEP
mode with more
	than
	> > > Sorry, that should read "Hong's solution (1)..." (i.e.
multiple
	associations,
	> > > Brian F. G. Bidulock wrote:
(Tue, 07 Aug
	2001 18:10:31)
	> > > > Tolga,
	> > > >
	> > > > That is not a workable solution in fully associated
networks: a
	single
	> > > > with 192 F-links, you would have this be 192 SGs, each
with 1
	F-link,
	> > > > requiring 192 separate SCTP associations.  Separating
into separate
	SGs
	> > > > Asveren, Tolga wrote:
(Tue, 07
	Aug 2001 17:53:09)
	> > > > > Hong,
	> > > > > 
	> > > > > I think another solution would be, splitting SG in
Brian's example
	in
	> > > > > two SG's, so that every SG serves only one SEP. Then
one would
	have
	> > > > > different associations from ASP to two different SGs.
This would
	solve
	> > > > > Since I was the one bringing up this thread again, I
feel
	"obligated"
	> > > > > to chip in what I feel about this issue. In case my
thoughts have
	been
	> > > > > already expressed and discussed, please take them as
refresh of
	the
	> > > > > I guess there are two issues involved here: the
semantics of
	Network
	> > > > > Appearance and the need to demux the management
messages from a
	common
	> > > > > >From the semantical perspective, I agree with John,
Klaus, Tolga
	and
	> > > > > >when an SGP is sitting on multiple SS7 networks. What
Brian has
	been
	> > > > > >arguing is that the parameter itself is NOT
sufficient for an ASP
	to
	> > > > > >distinguish SNMM from different point codes an SGP
represents,
	and
	> > > > > >hence he needs some mechanism to do that. (Brian,
please correct
	me
	> > > > > In fact, the problem manifests itself for an SGP
attaching to a
	single
	> > > > > Brian's example in the earlier part of the thread.) In
this case,
	the
	> > > > > messages relayed from the SGP.  Hence, the problem
actually has
	little
	> > > > > To make the example more concrete, say the SGP has two
PCs A and
	B,
	> > > > > necessarily imply that it is not reachable from B.
Suppose C is
	still
	> > > > > reachable from B, then the ASP, when receiving an DUNA
message
	from
	> > > > > through A, not through B, and updates its routesets
accordingly.
	It
	each
	> > > > > (3) Use a separate parameter to convey the information
of
	> > > > > "reachability via A in the SGP"
	> > > > > 
	> > > > > Option (1) mirrors the linkset concept in current SS7
networks,
	but
	> > > > > does not seem to be favored by the M3UA community.
Option (3) is
	in
	> > > > > essence what Brian was trying to do. I think Brian's
intention was
	not
	> > > > > intrusive, but additional procedures need to be
specified as how
	to
	> > > > > interpret "A" in this context. For example, if A is
the only
	affected
	> > > > > PC in DUNA, then it means the SGP is disconnected from
the SS7
	network
	> > > > > The ultimate question, of course, is whether this
example has any
	real
	> > > > > meaning. I will leave it to the experts in SS7
operations to
	justify
	> > > > > different usage scenarios, many of which seem to be
extensions to
	what
	> > > > > SS7 can do today. However, it also places the burden
on the
	protocol
	> > > > > Asveren, Tolga wrote:
(Tue, 07
	Aug 2001 07:53:03)
	> > > > > > possible. My personal opinion is to use NA to
differentiate
	between
	> > > > > > different networks, not between SPMCs. If an ASP is
serving ASs
	on
	> > > > > > different point codes, then correct handling of
received DUNA,
	DAVA
	> > > > > > etc... is a responsibility of ASP based on Affected
PC and NA
	fields
	> > > > > > in the received message. NIF on ASP can do the
required
	analysis,
	scope
	> > > > > (successfully) process M3UA messages.  There is not
enough
	information
	> > > > > in DAVA etc. to accomplish this in all cases.  DAVA
etc. will
	require
	> > > > > a concerned point code field or the Routing Context
included in
	the
	> > > > > Appearance as Network Id, it goes away and is replaced
by
	Concerned
	> > > > > > "The Network Apperarence identifies an SS7 network
context for
	the
	> > > > > > purpose of logically separating the signalling
traffic between
	the
	> > > > > > "The Network Appearence uniquely identifies an SS7
entty(Point
	Code)
	> > > > > > don't like: "It is also necessary when an SG is
configured as an
	STP
	> > > > > > nodes within the same network, in which case each
point code is
	a
	> > > > > > separate network appearence between the SG and the
ASP over a
	common
	> > > > > > SCTP Association"
	> > > > > >
	> > > > > > This sentence is in line with Brian's idea (and not
in line with
	my
	> > > > > > idea ;))
	> > > > > > I always tend to think NA as an identifier for
separate
	networks.
	for
	been
	> > > > > > > Sorry if I bring this long thread back to life.
Have we
	reached
	> > > > > > > any conclusion on this thread at all?
[email-masked]
	> > > To unsubscribe send a blank email to
	[email-masked]
[email-masked]
	> > > To unsubscribe send a blank email to
	[email-masked]
[email-masked]
	> > To unsubscribe send a blank email to
	[email-masked]
[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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 09:50:15 -0500

Tolga,

I believe that what you are getting at here is that the
5.255.6 point code has the "transfer function".  Again,
operators do not often have the choice when they interconnect
on the form of the interconnection.  This is essentially an
SEP with the transfer function and virtuaal "F-links" to the
AS point codes.  This arrangement is forbidden in some
networks (no SEP w/ xfer function allowed due to performance)
an unfeasible in others (exhaustion of point codes).  It is
also another restriction on configuration.

--brian

Asveren, Tolga wrote:                                    (Wed, 08 Aug 2001 07:26:48)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 09:53:22 -0500

Liu,

Please see comments below...

Hong Liu wrote:                                              (Wed, 08 Aug 2001 16:59:16)
> have different assumptions. Maybe now it is time to put them all on the

Or, maybe, instead, just add an optional parameter and be done with it.

--brian

> Sent: 2001-8-8 (???) 14:26 
> To: sigtran 
> Cc: 

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 09:24:37 -0700

Liu,
 
You guys have been busy on this last night, I only working on my sprinkler
system.
 
I didn't want to go backward in the thread but I would like to reply back to
your first message where you represented the problem and proposed that there
were 3 solutions.  Actually there are two more and I think they may already
be used in regular SS7 networks:
 
4) SG merges the traffic from its multiple network accesses and presents a
single node/PC view to the ASs
 
5) SG does not merge the traffic from its multiple network accesses but
assigns a network appearance per access (used locally by an SEP to support
multiple linksets to the same set of STPs).
 
I'll recap the network so others don't have to dig down for it.  We have an
SG with two "appearances" on an SS7 network (PC A and PC B).  There is a
signalling point, PC C, in the network that is unavailable to the SG's PC
A's access to the network, but node C is available via the SG's PC B's
access to the network.  There are ASs behind the SG, so the question is "How
is the unavailability of C presented to these ASs?"
 
Option (4), the SG merges the traffic from its multiple accesses and
presents a single node/PC view to the ASs (i.e., the ASs do not need to know
how the SG is connected to the network) and C is available via the SG's B
side, NO unavailability is forwarded to the ASs connected to the SG since
the SG still has an available route to C (via the SG's B access).  It is a
local implementation issue at the SG of how it merges its traffic from the
SS7 network and presents it as coming from a single SG to the ASs.
Actually, I think this is how it should be done.  Nodes connected to the SG
should not know how the SG is connected to the network.
 
Option (5),  the SG is not able to merge the traffic from its multiple
accesses (appearances).  Hence it must present separate traffic flows to its
connecting ASs.  The SG should assign a network appearance per access, hence
allowing the traffic to flow on the same associations to the ASs.  This
should be sufficient to identify the flows for the SG and the ASs.  When a
DUNA for A is received for one of the network appearances, an AS will know
that it can not use that "network appearance" to send traffic to A.  There
is a local issue of whether the AS is intelligent enough to know that
[network appearance 1 / node A] is the same as [network appearance 2 / node
A].  If the SG was not intelligent enough to merge the traffic, why should
the AS be any different.  Perhaps the service application sitting on top of
all of this could be intelligent enough to know and it could move the
traffic over, but this still a local implementation issue.
 
Your Option (2) does not work.  The DATA messages are not addressed to PC A,
you have not separated traffic flows, and SG is functioning as an STP, hence
since the DATA messages are addressed to PC C, there is nothing to stop
them.  Placing an OPC A in the DUNA or making A as an affected point code
has no effect, you have not separate your traffic flows.  The PC-to-PC model
is broken in (2) and (3).  If the SG must maintain the traffic separation
for its multiple accesses, then either use separate associations (option 1
where SG is now SG/PC-A and SG/PC-B) or use separate network appearances
(option 5).
 
John 

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 9:59 AM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Hi, Tolga,
 
One solution to the A-link congestion problem is to assign multiple point
codes to an SEP, as the A linkset is limited to 16 links. (There may be
other reasons to have multiple point codes.) I don't know how many SEPs in
the SS7 networks can support this feature but it is (I heard) one solution
that is being used today. Supporting multiple point codes in an SEP
definitely introduce additional complexity in management (as seen in this
discussion), maybe that is why not many SEPs are able to do that today. Of
course, there are other solutions to the A-link capacity problem, such as
high speed links.
 
In the meantime, I think the problem we are talking about here goes beyond
just having multiple point codes in an SGP, irrespective of whether the
network is quasi-associated or fully associated. Only when the SGP has
different connectivity into the same SS7 network with different point codes,
i.e. partitioning the SS7 network, will the problem occur. Is such
connectivity scheme being used in today's SS7 networks? I don't know for
sure. On the other hand, with M3UA, we already go beyond existing SS7
network configurations, as illustrated in your diagram.
 
Although I hate to impose restrictions on configurations, it would be
helpful to crystalize the underlying architectural models M3UA intends to
support. It seems to me that many discussions on the list about M3UA,
including this thread, boil down to this issue: different people seem to
have different assumptions. Maybe now it is time to put them all on the
table.
 
Cheers,
 
--Hong
 
-----Original Message----- 
From: Asveren, Tolga 
Sent: 2001-8-8 (星期三) 14:26 
To: sigtran 
Cc: 
Subject: RE: M3UA07: Network Appearance

Brian,

                   +-------+

    Regards,
    Tolga

-----Original Message-----

Tolga,

--brian

18:53:50)
2001 18:10:31)
> > > > > From: Hong Liu [ mailto:[email-masked]
<mailto:[email-masked]> ]
each
scope
> > > > > > From: Brian F. G. Bidulock [ mailto:[email-masked]
<mailto:[email-masked]> 
< mailto:[email-masked] <mailto:[email-masked]> > ]
for
been
> > > > http://www.openss7.org/ <http://www.openss7.org/> 
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/ <http://www.openss7.org/> 
> > >
> > >
> > > ---
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/ <http://www.openss7.org/> 
> >
> >
> > ---
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/ <http://www.openss7.org/> 

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

---

---

---

---

From: Dan Brendes <[email-masked]>
Date: Wed, 8 Aug 2001 13:35:58 -0400

I have the same opinion as that expressed in John's option #4.  I took some time
 to create a picture
with an SG attached to 3 separate networks and tried to walk through a simple
DUNA example.
(Hopefully the picture is legible if you select a fixedsys font, my apologies in
 advance if its not)...

The argument now seems to have come down to:
- If we reduce the scope of the Network Appearance to simply be a network
identifier, do we need to add a concerned point code parameter (CPC) to all
of the SSNM messages to cover the case where the SG is connected to multiple
networks?
- And if so is it required or optional?
- Or instead of adding CPC, should we be adding routing context(RC)?

1st off, assuming one of the 2 is needed, let me say that I think CPC would be
a better choice than RC.  I believe the CPC that is being proposed is a point
code
in the SG (ie: for DUNA the SG is saying it can't get to the Affected PC from
the
viewpoint of one of its own point codes).  This is in line with an earlier
comment
about having an OPC for the SSNM.

2nd, I think it is absolutely ridiculous to expect the SG to send one
notification
for each RC.  I do agree that the SG needs to replicate DUNA notifications to
multiple associations, but there is no reason to send the same notification
multiple
times just because there are multiple routing keys being carried on that
association.
The ASP can perform that replication if it needs to.

Now is the CPC needed?

Lets consider the SG connected to 3 networks as shown below and see if CPC is
needed on DUNA.

The DUNA message contains the following parameters:

     Network Appearance      Optional
     Affected Destinations   Mandatory
     INFO String             Optional

The format for DUNA Message parameters 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0200          |           Length =8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Network Appearance                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0203          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |                 Affected DPC 1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                              ...                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |                 Affected DPC n                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag = 0x0004         |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                          INFO String                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The example configuration shows an SG with 3 point codes in 3 different
networks talking to an ASP that is receiving traffic for 30 routing keys
(RC, AS, whatever you want to call it) that are spread across 6 PCs
that happen to be split across the 3 networks.

ASP
|-----------------------------------|
|  as01-10  |  as11-20  |  as21-30  |
|   pc1, 2  |  pc1, 2   |  pc1, 2   |
|  in na=1  |  in na=2  |  in na=3  |
-------------------------------------
           |
           |
           | there is 1 assoc
           | between SG/ASP
           |
SG         |
|-----------------------------------|
|  rc01-10  |  rc11-20  |  rc21-30  |
|   pc3     |  pc3      |  pc3      |
|  in na=1  |  in na=2  |  in na=3  |
-------------------------------------
   /  /      /    /     /       /
   |   |       |    |       |   |    SG has multiple
   |   |       |    |      |    |    connections to
   |   |       |    |      |    |    each network
   |   |       |    |      |    |
/---------\ /----------\ /----------\
|         | |          | |          |
| pc4,5,6 | | pc4,5,6  | | pc4,5,6  |
| in na=1 | | in na=2  | | in na=3  |
|         | |          | |          |
\---------/ \----------\ /----------\
network=1    network=2   network=3

So what needs to happen when PC4 in NA=1 becomes unavailable from the
viewpoint of the SG?

- I think everyone agrees that the SG needs a PC in each of the networks
it is connected to.
- I think everyone agrees that NA is no longer optional for this configuration
and that NA=1 in the DUNA.
- Obviously the affected destination = PC4.  NA=1 is required to be able to
differentiate PC4 in NA=1 from the other PC4s in NA=2, NA=3.

So does the SG need to include a CPC in the DUNA?
- I believe the answer is NO.
- If the SG can reach PC=4/NA=1 via any routes (whether they are through
NA=1, NA=2, or NA=3) it would not be sending a DUNA to the ASP.
Therefore the fact that the DUNA is being sent tells the ASP that PC3 in
NA=1, NA=2, and NA=3 are all unable to reach PC=4 in NA=1.

"Schantz, John" <[email-masked]> on 08/08/2001 12:24:37 PM

Liu,

John

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 9:59 AM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Hi, Tolga,

Cheers,

--Hong

-----Original Message-----
From: Asveren, Tolga
Sent: 2001-8-8 (?????????) 14:26
To: sigtran
Cc:
Subject: RE: M3UA07: Network Appearance

Brian,

                   +-------+

    Regards,
    Tolga

-----Original Message-----

Tolga,

--brian

18:53:50)
2001 18:10:31)
each
scope
for
been

---

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 13:18:09 -0500

Hong,

John's Option (4) does not work.  M3UA cannot force a single
network attachment view on the SS7 network.  See my example
earlier on this thread which does not include gateway screening.

--brian

Hong Liu wrote:                                (Wed, 08 Aug 2001 20:31:01)
> Hi, John,
>  
> I also had to  have the air conditioning unit fixed last night. It is
> getting hot in NJ area, -:)
>  
> Thanks for the explanation. Option (2) was kind of a kludge coming off
> the top of my "sweating" head at the time. I realized that there will be
> problems with it...
>  
> I think both of your solutions should work. If I am to pick one, I would
> prefer option (4). As for option (5), we are back to the initial debate
> about the semantics of "Network Appearance". If I remember correctly, a
> number of people on the list would like to use it only to identify
> different networks, not different attachments to the same network. As
> long as we agree to extend the semantics to include the latter, I see no
> problem making the scenario work. Of course, the texts in the spec need
> to be modified in order to accommodate the new semantics.
>  
> Cheers,
>  
> --Hong
> 

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

---

---

From: Hong Liu <[email-masked]>
Date: Wed, 8 Aug 2001 20:31:01 +0200

Hi, John,

 
 
Cheers,
 
--Hong

	-----Original Message----- 
	From: Schantz, John 
	Sent: 2001-8-8 (星期三) 18:24 
	To: sigtran 
	Cc: 
	Subject: RE: M3UA07: Network Appearance

	Liu,
	 
	You guys have been busy on this last night, I only working on my
sprinkler system.
	 
	I didn't want to go backward in the thread but I would like to
reply back to your first message where you represented the problem and
proposed that there were 3 solutions.  Actually there are two more and I
think they may already be used in regular SS7 networks:
	 
	4) SG merges the traffic from its multiple network accesses and
presents a single node/PC view to the ASs
	 
	5) SG does not merge the traffic from its multiple network
accesses but assigns a network appearance per access (used locally by an
SEP to support multiple linksets to the same set of STPs).
	 
	I'll recap the network so others don't have to dig down for it.
We have an SG with two "appearances" on an SS7 network (PC A and PC B).
There is a signalling point, PC C, in the network that is unavailable to
the SG's PC A's access to the network, but node C is available via the
SG's PC B's access to the network.  There are ASs behind the SG, so the
question is "How is the unavailability of C presented to these ASs?"
	 
	Option (4), the SG merges the traffic from its multiple accesses
and presents a single node/PC view to the ASs (i.e., the ASs do not need
to know how the SG is connected to the network) and C is available via
the SG's B side, NO unavailability is forwarded to the ASs connected to
the SG since the SG still has an available route to C (via the SG's B
access).  It is a local implementation issue at the SG of how it merges
its traffic from the SS7 network and presents it as coming from a single
SG to the ASs.  Actually, I think this is how it should be done.  Nodes
connected to the SG should not know how the SG is connected to the
network.
	 
	Option (5),  the SG is not able to merge the traffic from its
multiple accesses (appearances).  Hence it must present separate traffic
flows to its connecting ASs.  The SG should assign a network appearance
per access, hence allowing the traffic to flow on the same associations
to the ASs.  This should be sufficient to identify the flows for the SG
and the ASs.  When a DUNA for A is received for one of the network
appearances, an AS will know that it can not use that "network
appearance" to send traffic to A.  There is a local issue of whether the
AS is intelligent enough to know that [network appearance 1 / node A] is
the same as [network appearance 2 / node A].  If the SG was not
intelligent enough to merge the traffic, why should the AS be any
different.  Perhaps the service application sitting on top of all of
this could be intelligent enough to know and it could move the traffic
over, but this still a local implementation issue.
	 
	Your Option (2) does not work.  The DATA messages are not
addressed to PC A, you have not separated traffic flows, and SG is
functioning as an STP, hence since the DATA messages are addressed to PC
C, there is nothing to stop them.  Placing an OPC A in the DUNA or
making A as an affected point code has no effect, you have not separate
your traffic flows.  The PC-to-PC model is broken in (2) and (3).  If
the SG must maintain the traffic separation for its multiple accesses,
then either use separate associations (option 1 where SG is now SG/PC-A
and SG/PC-B) or use separate network appearances (option 5).
	 
	John 
	 
	[snip... to save bandwidth]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 13:33:52 -0500

Dan,

Option (4) will not work.  See my non-gateway screening example
earlier in this thread.  Your example does not to require a CPC
because it does not have multiple attachments to the *same*
network.

Please see additional comments below...

Dan Brendes wrote:                            (Wed, 08 Aug 2001 13:35:58)
> 
> 
> I have the same opinion as that expressed in John's option #4.  I took
> some time to create a picture with an SG attached to 3 separate
> networks and tried to walk through a simple DUNA example.  (Hopefully
> the picture is legible if you select a fixedsys font, my apologies in
> advance if its not)...
> 
> 
> - If we reduce the scope of the Network Appearance to simply be a
>   network identifier, do we need to add a concerned point code
>   parameter (CPC) to all of the SSNM messages to cover the case where
>   the SG is connected to multiple networks?

No.  We need to to handle the case where the SG has multiple attachments
to the same network.  It suffices for multiple networks as well.

> - And if so is it required or optional?

Required in the case of multiple network attachments to the same
network.  Required where used instead of NA and NA would be required.
Optional otherwise.

> - Or instead of adding CPC, should we be adding routing context(RC)?

RC would be better.

> 
> 1st off, assuming one of the 2 is needed, let me say that I think CPC
> would be a better choice than RC.  I believe the CPC that is being
> proposed is a point code in the SG (ie: for DUNA the SG is saying it
> can't get to the Affected PC from the viewpoint of one of its own
> point codes).  This is in line with an earlier comment about having an
> OPC for the SSNM.

Routing Context is immediately available to the SG.  The SG must
determine which AS to send the SNMM to, and once it determines an AS
it has determined RC.  The RC contains more information than a CPC.

> notification for each RC.

The SG must send one notification to each ASP for each AS.  This can
be a single SNMM with a list of RCs as in the SUA case.  Multiple
messages on the same association are not required.

RC is more immediately usable by the ASP, because it can distribute
MTP-PAUSE/STATUS indications to AS (perhaps individual processes or
threads) on the basis of the RC without having to redetermine which AS
correspond to the CPC.

Using RC in this fashion makes perfect sense, and that is how it is
used in SUA.

> I do agree that the SG needs to replicate
> DUNA notifications to multiple associations, but there is no reason to
> send the same notification multiple times just because there are
> multiple routing keys being carried on that association.

This is accomplished by an RC list, not a single RC as in SUA.  For
the SG to determine which associations the SNMM needs to be sent on
it must first determine which AS need the notification (list of RCs)
and determine which assocations have the AS active (sublist of RCs).
The SG must go through the process of forming this list of AS
identifiers anyway.  Placing the list of RCs (AS Ids) in the message
is trivial, yet conveys the best information to the ASP.

> perform that replication if it needs to.

Not without a some work.  The ASP must use the CPC to determine the list
of active AS (RCs) to which the CPC applies and distribute
MTP-PAUSE/STATUS indications to whatever processes are associated with
those AS.  If the RCs are already in the SNMM message, the ASP need only
send one MTP-PAUSE/STATUS indication to each AS on the RC list.

RCs works quite well.  CPC works worse.  NA == NI doesn't work.
> Now is the CPC needed?

Your example needs to include multiple network attachments to the same
network.  As it stands it is worthless.  This case is already handled
by NA == NI.  It is the case of multiple network attachments to the
same network that NA == NI fails and CPC or RCs are required.

--Brian

> - I think everyone agrees that the SG needs a PC in each of the
>   networks it is connected to.
> - I think everyone agrees that NA is no longer optional for this
>   configuration and that NA=1 in the DUNA.
> - Obviously the affected destination = PC4.  NA=1 is required to be
>   able to differentiate PC4 in NA=1 from the other PC4s in NA=2, NA=3.
> 
> 
> - If the SG can reach PC=4/NA=1 via any routes (whether they are
>   through NA=1, NA=2, or NA=3) it would not be sending a DUNA to the
>   ASP.  Therefore the fact that the DUNA is being sent tells the ASP
>   that PC3 in NA=1, NA=2, and NA=3 are all unable to reach PC=4 in
>   NA=1.
> 

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 11:54:13 -0700

Brian,
	Option (4) does work and you also seem to have confused in which
direction the single view is being presented.

	For Option (4) to work, it may mean that the SG has to support a
extra PC for its single PC view to the ASs (figure 1 below) or one of its
supported PCs needs to be a master to present a single PC view to the ASs
(figure 2 below).  I don't care, either way works but it depends on the
implementation.

Figure 1
                          SG                _________
                   +------+------+         (         ) 
  +----+           |      | PC-A |--------(           )
  | AS |-----------| PC-D |------|       ( SS7 Network )
  +----+           |      | PC-B |--------(           )
                   +------+------+         (_________)

Figure 2
                          SG                _________
                   +------+------+         (         ) 
  +----+           |    PC-A     |--------(           )
  | AS |-----------|      +------|       ( SS7 Network )
  +----+           |      | PC-B |--------(           )
                   +------+------+         (_________)

John

> Sent: Wednesday, August 08, 2001 1:18 PM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 12:24:14 -0700

Brian,

See comments below...

> Sent: Wednesday, August 08, 2001 12:17 PM
> To: sigtran
> Plese see commends below...
> 
> John Schantz wrote:                                          
> (Wed, 08 Aug 2001 09:24:37)
> > 
> >    Liu,
> >    
> >    
> >    
> >    I didn't want to go backward in the thread but I would 
> like to reply
> >    back to your first message where you represented the problem and
> >    proposed that there were 3 solutions.  Actually there 
> are two more and
> >    I think they may already be used in regular SS7 networks:
> >    
> >    
> >    
> If you look back in the messages, this is not possible since 
> this places
> requirements on routing configurations within the SS7 network 
> which are
> not natural.
> 
[John]  No you just have to be more creative with the configuring of primary
and alternate routes.  I admit that it is more administrative work but if
you are have to...
> >    
> >    
> >    
> >    5) SG does not merge the traffic from its multiple 
> network accesses
> >    but assigns a network appearance per access (used 
> locally by an SEP to
> >    support multiple linksets to the same set of STPs).
> 
> This was proposed.  You originally thought that this violated 
> the pristine
> concept of Network Appearance is Network Id...

[John]  I think you may be confusing me with someone else.  I am more than
willing to use network IDs to distinguish between network
appearances/accesses.  It is one of the ways that a SEPs can "internally"
solve the need for multiple linksets.  It is the basis for the ITU MTP-SAP
and SCCP-SAP.
> 
> >    
> >    
> >    
> >    I'll recap the network so others don't have to dig down 
> for it.  We
> >    have an SG with two "appearances" on an SS7 network (PC 
> A and PC B).
> >    There is a signalling point, PC C, in the network that 
> is unavailable
> >    to the SG's PC A's access to the network, but node C is 
> available via
> >    the SG's PC B's access to the network.  There are ASs 
> behind the SG,
> >    so the question is "How is the unavailability of C 
> presented to these
> >    ASs?"
> >    
> >    
> >    
> >    presents a single node/PC view to the ASs (i.e., the ASs 
> do not need
> >    the SG's B side, NO unavailability is forwarded to the 
> ASs connected
> >    to the SG since the SG still has an available route to C 
> (via the SG's
> >    B access).  It is a local implementation issue at the SG 
> of how it
> >    merges its traffic from the SS7 network and presents it 
> as coming from
> >    a single SG to the ASs.  Actually, I think this is how 
> it should be
> >    done.  Nodes connected to the SG should not know how the SG is
> >    connected to the network.
> 
> But, this is not the way that it is done in the SS7 network 
> (an not in the
> IP network either for that matter).  See the example which 
> does not require
> gateway screening to fail.
> 
[John]  Maybe you just don't know about it.  What is your hang-up with a
non-protocol functions?
> >    accesses (appearances).  Hence it must present separate 
> traffic flows
> >    to its connecting ASs.  The SG should assign a network 
> appearance per
> >    access, hence allowing the traffic to flow on the same 
> associations to
> >    the ASs.  This should be sufficient to identify the 
> flows for the SG
> >    appearance" to send traffic to A.  There is a local 
> issue of whether
> >    the AS is intelligent enough to know that [network 
> appearance 1 / node
> >    A] is the same as [network appearance 2 / node A].  If 
> the SG was not
> This was originally proposed (and is how it stands in the draft).  You
> objected strongly to it at that point.  Has your position changed?
> 
[John]  My position has never changed.  I opposed your proposal to define
Network Appearance with everything but the kitchen sink.  It only needs to
be a locally significant network ID.

> >    Your Option (2) does not work.  The DATA messages are 
> not addressed to
> >    PC A, you have not separated traffic flows, and SG is 
> functioning as
> >    an STP, hence since the DATA messages are addressed to 
> PC C, there is
> >    nothing to stop them.  Placing an OPC A in the DUNA or 
> making A as an
> >    affected point code has no effect, you have not separate 
> your traffic
> >    flows.  The PC-to-PC model is broken in (2) and (3).  If 
> the SG must
> >    maintain the traffic separation for its multiple 
> accesses, then either
> >    use separate associations (option 1 where SG is now SG/PC-A and
> >    SG/PC-B) or use separate network appearances (option 5).
> 
> Agreed.  I didn't have the heart (or stamina) to point it out.
> 
> ..........
> 
> To summarize, your Option (4) does not work, and Option (5) has been
> proposed.  The proposals that work are:
> 
> 	(a) Network Appearance == Network Access (the easiest 
> way to ensure
> 	    this is to make the NA a Network Id and SPMC point code).

[John] NOOOOO, only Network Appearance = Network ID is needed.  Remember the
Network ID I am talking about is a arbitrary number that only has local
significance.  Assigning one per network access is fine with me if your node
is unable to remerge the traffic before it passes it on.
> 
> 	(b) Include optional Concerned Point Code on SNMM (perhaps with
> 	    Network Id embedded, obviating need for Network Appearance
> 	    in SNMM).
> 
[John]  This is not a solution.  How does Concerned PC provide real-time
traffic flow separation, it doesn't.  So please stop proposing something
that does NOT work.

> 	(c) Include optional Routing Context(s) in SNMM (obviating need
> 	    for Network Appearance in SNMM).

[John]  This is not a solution either for the same reason I gave above.
> 
> I prefer (c).  It is less work for both the SG and the ASP in these
> circumstances and it is consistent with SUA.

[John]  I would conclude that Option (5) is the only solution.  Network
Appearance assigned per network access independent of whether it is multiple
networks or a single network that is being accessed.
> >    heard) one solution that is being used today. Supporting multiple
> >    point codes in an SEP definitely introduce additional 
> complexity in
> >    management (as seen in this discussion), maybe that is 
> why not many
> >    SEPs are able to do that today. Of course, there are 
> other solutions
> >    to the A-link capacity problem, such as high speed links.
> >    
> >    
> >    
> >    already go beyond existing SS7 network configurations, 
> as illustrated
> >    in your diagram.
> >    
> >    
> >    
> >    to support. It seems to me that many discussions on the 
> list about
> >    M3UA, including this thread, boil down to this issue: 
> different people
> >    seem to have different assumptions. Maybe now it is time 
> to put them
> >    all on the table.
> >    
> >    
> >    
> >    Cheers,
> >    
> >    
> >    
> >    --Hong
> >    
> >    
> >    
> >    Sent: 2001-8-8 () 14:26
> >      But the other thing I have proposed will solve the 
> problem I think,
> >      to have
> >      SG with its own point code. Then one can have as many 
> direct links
> >      as
> >      From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
> >      > > the ones of SEPs in your example).  Because, I 
> think, the real
> >      reason
> >      > > from SG will make this connectivity again single.  
> I know SG
> >      can also
> >      > > run in SEP mode. What I am only saying is that, if 
> there would
> >      be a
> >      > > different network connectivity, then your example 
> wouldn't be a
> >      valid
> >      > > From: Brian F. G. Bidulock [[2]mailto:[email-masked]]
>       (Tue,
> >      07 Aug
> >      > > > don't like the configuration where SG is working 
> in SEP mode
> >      with more
> >      than
> >      > > > one point code.
> >      > > >
> >      > > > Just another try ;)
> >      > > >
> >      > > >       Tolga
> >      > > >
> [[3]mailto:[email-masked]]
> >      > > > > with 192 F-links, you would have this be 192 
> SGs, each with
> >      1
> >      F-link,
> >      > > > > requiring 192 separate SCTP associations.  
> Separating into
> >      separate
> >      SGs
> >      > > > > This is not terribly different than Hong's 
> solution (2),
> >      which is
> >      > > >                                              ^^^^^^^^^^^^
> >      > > > > > two SG's, so that every SG serves only one 
> SEP. Then one
> >      would
> >      have
> >      > > > > > From: Hong Liu [[4]mailto:[email-masked]]
> >      > > > > > Since I was the one bringing up this thread 
> again, I feel
> >      "obligated"
> >      > > > > > I guess there are two issues involved here: 
> the semantics
> >      of
> >      Network
> >      > > > > > Appearance and the need to demux the 
> management messages
> >      from a
> >      common
> >      > > > > > >Barry about the definition of Network 
> Appearance as a
> >      network ID,
> sufficient
> >      for an ASP
> >      > > > > > >hence he needs some mechanism to do that. 
> (Brian, please
> >      correct
> >      me
> >      > > > > > SS7 network, but bearing more than one point 
> code, and
> >      there are
> >      > > > > > different routes into the SS7 network from 
> these point
> >      codes. (See
> >      > > > > > ASP needs to update its own routing 
> information based on
> >      the SNMM
> >      > > > > > and A and B have different linksets into the 
> SS7 network.
> >      The fact
> >      > > > > > the SGP, needs to differentiate that the 
> unavailability
> >      of C is
> >      > > > > > (1) Establish separate SCTP associations 
> between SGP and
> >      ASP for
> >      each
> >      > > > > > PC pair;
> >      > > > > >
> >      > > > > > (3) Use a separate parameter to convey the 
> information of
> >      > > > > > does not seem to be favored by the M3UA 
> community. Option
> >      (3) is
> >      in
> >      > > > > > to introduce another parameter, so he tried 
> to maximize
> >      the use of
> >      > > > > > Network Appearance with additional 
> information. (which
> >      caused
> >      > > > > > objections from semantics viewpoint.) Option 
> (2) seems to
> >      be less
> >      > > > > > intrusive, but additional procedures need to 
> be specified
> >      as how
> >      to
> >      > > > > > interpret "A" in this context. For example, 
> if A is the
> >      only
> >      affected
> >      > > > > > The ultimate question, of course, is whether 
> this example
> >      has any
> >      real
> >      > > > > > meaning. I will leave it to the experts in 
> SS7 operations
> >      to
> >      justify
> >      > > > > > SS7 can do today. However, it also places 
> the burden on
> >      the
> >      protocol
> >      > > > > > > etc... is a responsibility of ASP based on 
> Affected PC
> >      and NA
> >      fields
> >      > > > > > > in the received message. NIF on ASP can do 
> the required
> >      analysis,
> >      > > > > > > which is out of the scope of M3UA.  I like 
> definition
> >      of NA in
> >      > > > > > Sorry, doing the required analysis on DAVA 
> etc. is *NOT*
> >      out of
> >      scope
> >      > > > > > in DAVA etc. to accomplish this in all 
> cases.  DAVA etc.
> >      will
> >      require
> >      > > > > > kmessage in those cases.  When Routing 
> Context must be
> >      included,
> >      > > > > > Appearance as Network Id, it goes away and 
> is replaced by
> >      Concerned
> >      > > > > > Point Code or Routing Context in all 
> messages except REG
> >      REQ.
> >      > > > > >
> >      > > > > > --brian
> >      > > > > >
> >      > > > > >
> >      > > > > > >
> >      > > > > > > draft6:
> >      > > > > > > purpose of logically separating the 
> signalling traffic
> >      between
> >      the
> >      > > > > > > Especially the following sentence, which 
> was added in
> >      draft7, I
> >      > > > > > > nodes within the same network, in which 
> case each point
> >      code is
> >      a
> >      > > > > > > separate network appearence between the SG 
> and the ASP
> >      over a
> >      common
> >      > > > > > > SCTP Association"
> >      > > > > > >
> >      > > > > > > This sentence is in line with Brian's idea 
> (and not in
> >      line with
> >      my
> >      > > > > > > idea ;))
> >      > > > > > > I always tend to think NA as an identifier 
> for separate
> >      networks.
> >      > > > > > >
> >      > > > > > >    Regards,
> >      > > > > > >    Tolga Asveren
> >      > > > > > >
> >      > > > > > >
> >      > > > > > > From: Brian F. G. Bidulock [
> >      [5]mailto:[email-masked]
> >      <[6]mailto:[email-masked]> ]
> >      > > > > > > The ultimate fate of NA, however, does not 
> appear to
> >      have yet
> >      been
> >      > > > > > > > Sorry if I bring this long thread back 
> to life. Have
> >      we
> >      reached
> >      > > > > [7]http://www.openss7.org/
> >      > > >
> >      > > > --
> >      > > > Brian F. G. Bidulock
> >      > > > [email-masked]
> >      > > > [8]http://www.openss7.org/
> >      > > >
> >      > > >
> >      > > > ---
> >      > > [9]http://www.openss7.org/
> >      > >
> >      > >
> >      > > ---
> >      > [10]http://www.openss7.org/
> >      --
> >      Brian F. G. Bidulock
> >      [email-masked]
> >      [11]http://www.openss7.org/
> >      ---
> > References
> >    1. mailto:[email-masked]
> >    2. mailto:[email-masked]
> >    3. mailto:[email-masked]
> >    4. mailto:[email-masked]
> >    5. mailto:[email-masked]
> >    6. mailto:[email-masked]
> >    7. http://www.openss7.org/
> >    8. http://www.openss7.org/
> >    9. http://www.openss7.org/
> >   10. http://www.openss7.org/
> >   11. http://www.openss7.org/
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 14:25:01 -0500

John,

It does not work for this example which has already been
presented:

                      200.1.4    __________
                        ___     /          \     ___
                       /   \   |            |   /   \
                      | SEP |__|____________|__| SEP |  AS1
                       \___/   |            |   \___/
                      //       |            |
                     / |       | Signalling |  5.255.3
                    / /        |   Gateway  |
                   /  |        |            |
                  /  /         |            |
          _____  /   |         |            |
         |     |/   /          |            |
    -----| STP |____|__________|______      |
        /|_____|   /           |      \___  |  5.255.4
       /    |      |           |          \_|_   ___
    \ /     |     /            |            | \ /   \
     X      |     |            |            |  | SEP |  AS2
    / \     |    /             |           _|_/ \___/
       \  __|__ /              |       ___/ |
        \|     |_______________|______/     |       5.255.5
    -----| STP |               |            |       (alias)
         |_____|               |            |
                               |            |
                                \__________/

When the F-link to 200.1.4 fails, how can the SG present a single
view towards the AS?  The network is inaccessible from 5.255.3 and
5.255.3 is inaccessible from the network.  5.255.5 is still has
access to the network and the network still has access to 5.255.5.

If you tell 5.255.3 that the network is still accessible (presumably
via the STPs) you can still not tell the SS7 network that 5.255.3 is
accessible to it.  The SS7 network will not route any messages to
5.255.3, it has already broadcast TFP(5.255.3).

If you tell 5.255.4 that the network is inaccessible, the entire
system will fail every time the F-link fails, which is ridiculous.

Option (4) is not an option because it does not address the
situation which has been the point of dicussion all along.

Please address further "solutions" to this diagram.

--Brian

John Schantz wrote:                                          (Wed, 08 Aug 2001 11:54:13)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 14:52:39 -0500

John,

See comments below...

John Schantz wrote:                                          (Wed, 08 Aug 2001 12:24:14)
> > >    You guys have been busy on this last night, I only working on
> > >    my sprinkler system.
> > >    
> > >    reply back to your first message where you represented the
> > >    problem and proposed that there were 3 solutions.  Actually
> > >    there are two more and I think they may already be used in
> > >    regular SS7 networks:
> > >    
> > If you look back in the messages, this is not possible since this
> > places requirements on routing configurations within the SS7 network
> > which are not natural.
> > 
> [John]  No you just have to be more creative with the configuring of
> primary and alternate routes.  I admit that it is more administrative
> work but if you are have to...

The example presented is supported by GR-317-CORE and GR-394-CORE for
switches with multiple point code.  It is a natural, dare I say even
standard, configuration of the SS7 network.  It appears that you wish
to change the example to make your case.  Address the example.  In the
example your Option (4) is not an option.

> > >    accesses but assigns a network appearance per access (used
> > >    locally by an SEP to support multiple linksets to the same set
> > >    of STPs).
> > 
> > This was proposed.  You originally thought that this violated the
> > pristine concept of Network Appearance is Network Id...
> 
> [John]  I think you may be confusing me with someone else.  I am more
> than willing to use network IDs to distinguish between network
> appearances/accesses.  It is one of the ways that a SEPs can
> "internally" solve the need for multiple linksets.  It is the basis
> for the ITU MTP-SAP and SCCP-SAP.

John, you contradict yourself in the same note!  Here you say that
Network Apperance == Network Access is ok.  Down below you say
"NOOOOOO."  Which is it?

> > >    We have an SG with two "appearances" on an SS7 network (PC A
> > >    and PC B).  There is a signalling point, PC C, in the network
> > >    that is unavailable to the SG's PC A's access to the network,
> > >    but node C is available via the SG's PC B's access to the
> > >    network.  There are ASs behind the SG, so the question is "How
> > >    Option (4), the SG merges the traffic from its multiple
> > >    accesses and presents a single node/PC view to the ASs (i.e.,
> > >    the ASs do not need to know how the SG is connected to the
> > >    network) and C is available via the SG's B side, NO
> > >    unavailability is forwarded to the ASs connected to the SG
> > >    since the SG still has an available route to C (via the SG's B
> > >    access).  It is a local implementation issue at the SG of how
> > >    it merges its traffic from the SS7 network and presents it as
> > >    coming from a single SG to the ASs.  Actually, I think this is
> > >    how it should be done.  Nodes connected to the SG should not
> > >    know how the SG is connected to the network.
> > 
> > But, this is not the way that it is done in the SS7 network (an not
> > in the IP network either for that matter).  See the example which
> > does not require gateway screening to fail.
> > 
> [John]  Maybe you just don't know about it.  What is your hang-up with
> a non-protocol functions?

I have hang-ups, but non-protocol functions is not one of them.  The
example provided is a standard configuration of a switch/MGC with
multiple point codes as standardized in GR-317=CORE and GR-394-CORE.

> > >    multiple accesses (appearances).  Hence it must present
> > >    separate traffic flows to its connecting ASs.  The SG should
> > >    assign a network appearance per access, hence allowing the
> > >    traffic to flow on the same associations to the ASs.  This
> > >    should be sufficient to identify the flows for the SG and the
> > >    ASs.  When a DUNA for A is received for one of the network
> > >    appearance" to send traffic to A.  There is a local issue of
> > >    whether the AS is intelligent enough to know that [network
> > >    appearance 1 / node A] is the same as [network appearance 2 /
> > >    node A].  If the SG was not intelligent enough to merge the
> > >    traffic, why should the AS be any different.  Perhaps the
> > >    service application sitting on top of all of this could be
> > >    intelligent enough to know and it could move the traffic over,
> > >    but this still a local implementation issue.
> > 
> > This was originally proposed (and is how it stands in the draft).
> > You objected strongly to it at that point.  Has your position
> > changed?
> > 
> [John]  My position has never changed.  I opposed your proposal to
> define Network Appearance with everything but the kitchen sink.  It
> only needs to be a locally significant network ID.

Then why do you say "NOOOOO" below?

> > >    addressed to PC A, you have not separated traffic flows, and SG
> > >    is functioning as an STP, hence since the DATA messages are
> > >    addressed to PC C, there is nothing to stop them.  Placing an
> > >    OPC A in the DUNA or making A as an affected point code has no
> > >    effect, you have not separate your traffic flows.  The PC-to-PC
> > >    model is broken in (2) and (3).  If the SG must maintain the
> > >    traffic separation for its multiple accesses, then either use
> > >    separate associations (option 1 where SG is now SG/PC-A and
> > 	(a) Network Appearance == Network Access (the easiest way to
> > 	    ensure this is to make the NA a Network Id and SPMC point
> > 	    code).
> 
> [John] NOOOOO, only Network Appearance = Network ID is needed.
> Remember the Network ID I am talking about is a arbitrary number that
> only has local significance.  Assigning one per network access is fine
> with me if your node is unable to remerge the traffic before it passes
> it on.

Here's the apparent contradiction.  Back above you say NA == Network
Access is just fine.  Now you say only Network Appearance == Newtork Id
is necessary.

It appears that you have requalified Network Id so that Network Id ==
Network Access (where required).  This is precisely where the M3UA
draft sits today, so you should have absolutely no objections with it.

Further, if you permit such netword access numbering, it is only
required where there are multiple SPMCs over multiple accesses.  The
rational assigment policy for Network Appearances in this case is as
proposed by Joyce and reproposed by myself:  NA = NI + PC or SPMC Id.
You objected strenuously to those proposals on the grounds that it
violated the pristine Network Appearance == Network Id paradigm, so I
cannot see where you are agreeing to Network Appearance == Network
Id/Access.

Which is it, John?

> [John]  This is not a solution.  How does Concerned PC provide
> real-time traffic flow separation, it doesn't.  So please stop
> proposing something that does NOT work.

It works just fine.  In this case CPC is merely the SPMC Id.  It is
just in an alternate form.  You are seriously confused.  SPMC Id is
sufficient to solve the difficulty.  Just as numbering a NA so that
it includes Network Id and SPMC Id embedded also solves the problem.

It would be better to ask questions than make invalid assertions.

> [John]  This is not a solution either for the same reason I gave

You did not give a reason above. But it is the same solution in (a) and
(b) and the one you say you agree to (not the one you say you don't).
Routing Context uniquely identifies SPMC, which is all that is required
on SNMM to solve the situation.

> [John]  I would conclude that Option (5) is the only solution.
> Network Appearance assigned per network access independent of whether
> it is multiple networks or a single network that is being accessed.

Oh boy.  Four or five contradictions in one note!

[snip]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 13:08:38 -0700

Brian,

	You are just not getting it.  I am being very consistent.

	I support only NA = Network ID (an arbitrary assignment!!!! that is
only significant/used by the nodes involved, it has no relationship to the
Network ID that is part of an ANSI, or China, or Japan SS7 PC.)  This is
also what the other agreed to.

	I do NOT support NA = Network ID + PC.  This is totally useless.

John

> Sent: Wednesday, August 08, 2001 2:53 PM
> To: sigtran
> (Wed, 08 Aug 2001 12:24:14)
> > Brian,
> > 
> > See comments below...
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 15:38:06 -0500

John,

So, you are completely satisfied with the M3UAv8 draft?  That is
what it has: NA == Network Id with arbitrary assignment.

You started by objecting to the arbitrary assignment part.

Note also that arbitrary assignment means that I can number them
how I like, and as I want to number them NI + PC, I will.

Routing Context is still superior from the standpoint of SG/ASP
processing and is more interoperabe.  With the NA arbitrary
assignment, the ASP has no way of checking the validity of the
values presented to it in the message.  Also, NA with arbitrary
assignment is a divergence from SUA's approach and it would be
better for the two UAs to be consistent on this.  SUA cannot use
this NA with arbitrary assignment because a large number of
complicated arbitrary assignments would need to be generated.

You certainly have provided no evidence whatsoever which would
imply that Network Apperance (with arbitrary assignment) is in
any way better than CPC or RC, while evidence has been presented
that CPC is better than NA (it removed the "arbitrary") and RC
is better that CPC (it removes unnecessary processing from the
ASP).

Could you explain why you prefer NA+Arbitrary Assignment to CPC
or RCs?

--brian

John Schantz wrote:                                          (Wed, 08 Aug 2001 13:08:38)

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

---

---

From: Hong Liu <[email-masked]>
Date: Thu, 9 Aug 2001 00:04:50 +0200

Hi, Brian,
 
I don't mean to beat up the dead horse, but I do want to understand your
example more. In the case of the F-link failure, what are the expected
behaviors of the network elements involved (SG, STPs, AS1, AS2)?  For
example, do you still consider AS1 and AS2 connected to each other?
 
I apoplogize in advance if I did not quite catch your points in previous
emails.
 
Cheers,
 
--Hong

	-----Original Message----- 
	From: Brian F. G. Bidulock 
	Sent: 2001-8-8 (星期三) 21:25 
	To: sigtran 
	Cc: 
	Subject: Re: M3UA07: Network Appearance

	John,

	
	                      200.1.4    __________
	                        ___     /          \     ___
	                       /   \   |            |   /   \
	
	When the F-link to 200.1.4 fails, how can the SG present a
single
	view towards the AS?  The network is inaccessible from 5.255.3
and
	5.255.3 is inaccessible from the network.  5.255.5 is still has
	access to the network and the network still has access to
5.255.5.
	
	If you tell 5.255.3 that the network is still accessible
(presumably
	via the STPs) you can still not tell the SS7 network that
5.255.3 is
	accessible to it.  The SS7 network will not route any messages
to
	5.255.3, it has already broadcast TFP(5.255.3).
	
	If you tell 5.255.4 that the network is inaccessible, the entire
	system will fail every time the F-link fails, which is
ridiculous.

	--Brian

	John Schantz wrote:
(Wed, 08 Aug 2001 11:54:13)
	> > > Thanks for the explanation. Option (2) was kind of a
kludge
	> > coming off
	> > > I think both of your solutions should work. If I am to
pick
	> > one, I would
[email-masked]
[email-masked]
	
	--
	Brian F. G. Bidulock
	[email-masked]
	http://www.openss7.org/

	---

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 14:03:45 -0700

Brian,

Below is my original response on this topic.  You will find that I have not
changed my stance on this.  You proposed to have the format defined as NA =
NID + PC.  As long as a format is not specified in M3UA (nor hinted at), I
guess we can agree.

John

Original response:
----------------------------------------------------------------------------
---------
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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

> Sent: Wednesday, August 08, 2001 3:38 PM
> To: sigtran
> (Wed, 08 Aug 2001 13:08:38)
> > Brian,
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 16:57:39 -0500

John,

The discussion went in different directions from there because
there are there are advocates of the pristine Network
Apperance == Network Id paradigm (without arbitrary assigment,
as in the Japan, Uraguay, etc.)

Besides.  You original objection is to making NA anything but
Network Id.

Nevertheless, this original proposal of Joyce's has several
excellent advantages over arbitrary assignment:

    1) It permits passive monitoring devices to discern the
       format of point codes.

    2) ASP which are performing dynamic registration for
       multiple network attachments do not have to be
       statically provisioned with a set of NI + DPC to
       Network Appearance mappings for each SG to which they
       register. (Which kinda defeats the purpose of dynamic
       registration in the first place.)

    3) It permits a global numbering plan for Network
       Appearance values.

    4) It uniquely identifies the SPMC so that the ASP does
       not need to maintain a separate mapping table of NA to
       DPC for each SG.

So, I suppose that we are not in agreement on the "nor hinted
at" part.

Could you state your objections to this original propsal in
technical terms?

--brian

P.S.  If we leave the assignment abritrary, I will set Network
Apperance == Routing Context at the SG and an ASP
implementation must be prepared to handle it (because of the
arbitrary nature).  (Multiple network apperance values in the
SNMM are called for anyway, but I will address that in another
note.)

John Schantz wrote:                          (Wed, 08 Aug 2001 14:03:45)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 17:09:08 -0500

Hong,

When the F-link from 200.1.4 to the SG fails, 200.1.4 (which has the
"transfer function") broadcasts TFP(5.255.3) back to the network
(i.e.  the STPs).  The STPs only routset to 5.255.3 is via 200.1.4,
so it marks the routeset as prohibited and broadcasts TFP(5.255.3)
to the left into the remainder of the network.  As far as any point
code in the SS7 network is concerned, 5.255.3 is prohibited.  This
is normal and expected behavior per Q.704/T1.111.3

This is independent of whether 5.255.3 and 5.255.4 are point codes
of the same switch.  On switching element is permitted (and in some
cases it is necessary for it to have) multiple point codes with
multiple network attachments.  There are several cited cases: CIC
exhaustion, PC exhaustion, representation of one element in multiple
sub-networks for multiple interconnects, and any number of other
engineering and administrative reasons for wanting to do so.

This is just the way the SS7 network works and must be accomodated
by M3UA (and SUA for that matter as well).

In analogy to IP, consider the switch as a "multihomed host" in
the SS7 network.  MTP, just as IP, has no concept of "multihomed"
built into its routing scheme.

--brian

Hong Liu wrote:                                (Thu, 09 Aug 2001 00:04:50)
[snip]
[snip]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 8 Aug 2001 15:04:38 -0700

Brian,
	It would help a lot if this was a valid example.  F-links are
point-to-point.  No STPs or SGs involved.  Maybe you have it set up wrong.
You can't expect us to solve every drawing if they are incorrect to begin
with.

Do you really want the SG to do its job as an STP.  Then AS1 would know that
its signalling is coming via the SG.  But in this case, the SG has B-links
(or D-links or G-links) to the network and an E-link to 200.1.4.  Hence, the
primary route for all ASs behind the SG to 200.1.4 is the E-link, the
B-links would be the alternate route for 200.1.4.  If the link from the SG
to 200.1.4 fails, then the SG uses the alternate route to 200.1.4.  Only if
the E-link failed and TFPs were received from both STPs would the SG send a
DUNA to AS1 about 200.1.4.

John

> Sent: Wednesday, August 08, 2001 2:25 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 18:34:52 -0500

John,

The example is directly from Q.705/ANSI T1.111.5.  It is
more than valid.  E-link arrangements are similar and
exhibit the same problem.  You'll have to come up with
another excuse.

--brian

John Schantz wrote:                             (Wed, 08 Aug 2001 15:04:38)

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

---

---

From: Hong Liu <[email-masked]>
Date: Thu, 9 Aug 2001 02:39:36 +0200

Hi, Brian,
 
Thanks for the detailed explanation. We are in agreement that there are
valid cases in the current SS7 networks where a signaling node may bear
more than one point code. What I tried to get at is the SS7 connectivity
on the IP side, i.e. AS1 and AS2 (via SG). When F-link goes down, AS1 is
disconnected from the rest of the network via the circuit side. If SG is
still working fine, are AS1 and AS2 still connected? In other words,
shall we assume there exists a virtual IP F-link between AS1 and AS2
when they are connected to the same SG?
 
--Hong

	-----Original Message----- 
	From: Brian F. G. Bidulock 
	Sent: 2001-8-9 (星期四) 0:09 
	To: sigtran 
	Cc: 
	Subject: Re: M3UA07: Network Appearance

	Hong,
	
	When the F-link from 200.1.4 to the SG fails, 200.1.4 (which has
the
	"transfer function") broadcasts TFP(5.255.3) back to the network
	(i.e.  the STPs).  The STPs only routset to 5.255.3 is via
200.1.4,
	so it marks the routeset as prohibited and broadcasts
TFP(5.255.3)
	to the left into the remainder of the network.  As far as any
point
	code in the SS7 network is concerned, 5.255.3 is prohibited.
This
	is normal and expected behavior per Q.704/T1.111.3
	
	This is independent of whether 5.255.3 and 5.255.4 are point
codes
	of the same switch.  On switching element is permitted (and in
some
	cases it is necessary for it to have) multiple point codes with
	multiple network attachments.  There are several cited cases:
CIC
	exhaustion, PC exhaustion, representation of one element in
multiple
	sub-networks for multiple interconnects, and any number of other
	engineering and administrative reasons for wanting to do so.
	
	This is just the way the SS7 network works and must be
accomodated
	by M3UA (and SUA for that matter as well).
	
	In analogy to IP, consider the switch as a "multihomed host" in
	the SS7 network.  MTP, just as IP, has no concept of
"multihomed"
	built into its routing scheme.
	
	--brian
	
	Hong Liu wrote:                                (Thu, 09 Aug 2001
00:04:50)
	[snip]
	>            X      |     |            |            |  | SEP |
AS2
5.255.5
(alias)
(presumably
ridiculous.
	[snip]
	
	--
	Brian F. G. Bidulock
	[email-masked]
	http://www.openss7.org/

	---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 00:53:45 -0500

Hi Hong,

In the example the SG offers no direct route from 5.255.3 to
5.255.4/5.  It wouldn't help anyway, even if there was a "virtual"
F-link, 5.255.3 still cannot talk to the rest of the world.  If the
ASP wants to transfer messages between AS1 and AS2, it can do so on
its own.  But the network still cannot talk to 5.255.3, even if the
message appears from AS2 with PC=5.255.3.

--Brian

Hong Liu wrote:                                (Thu, 09 Aug 2001 02:39:36)
>  Sent: 2001-8-9 (???) 0:09 
>  To: sigtran 
>  Cc: 
[snip]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 9 Aug 2001 07:07:44 -0700

Brian,
	You will find NO picture of an F-link going through an STP in
T1.111.5.  I should know, I drew all the pictures in T1.111.5, I was the
original editor for this standard.  Therefore, I think you had better come
up with another excuse.

John

> Sent: Wednesday, August 08, 2001 6:35 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 10:56:30 -0500

Hi John,

Since you editted the T1 specs, perhaps you should refresh your
memory by looking at Figure 4/T1.111.1 where it is explicitly
shown that a signalling point may have both the user function and
the transfer function.  The diagram also shows such a node
permiting the network to act in a mix of fully associated and
quasi-associated modes.

My point code 200.1.4 is such a switch: it has the transfer
function as well as the user function.

You are incorrect in your assertions: the diagram is in full
accordance with the standards.

--Brian

John Schantz wrote:                            (Thu, 09 Aug 2001 07:07:44)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 9 Aug 2001 09:01:53 -0700

Brian,

	Did I say at anytime SPs were not permitted to have the "transfer
function"? NO

	I know that most European networks don't have official STPs.  Many
of the switches have the transfer function so that they don't have to all
interconnect.  I know this, I have dealt with these networks and I have
products in these networks today.

	What excuses do I need, I am one of the original architects of
standards that you quote.  I know how standard works and I know how to make
it work. I have built working products of networks over the world since
1987.  

	I may have stayed in the background at the beginning of M3UA's
definition, BUT after it became clear that you were degrading the protocol
to an usable state for SS7 vendors that build real products, I had to come
out and speak up and try to get it back on track.	

	I recommend that get off of this current line of discussion and
start acting like a professional in the Telecommunications Industry.

John

> Sent: Thursday, August 09, 2001 10:24 AM
> To: sigtran
> Figure 8/T1.111.5.
> All SP's are permitted to have the "transfer function".  They do
> not have to be STPs.  The sponsor of this reflector has been selling
> software for their switches for over 15 years which provides for
> this arrangement.  Get another excuse.  You must address the
> diagram.  It is a real situation.
> 
> --Brian
> 
> John Schantz wrote:                                          
> (Thu, 09 Aug 2001 07:07:44)
> > Brian,
> > > > > > > Hong Liu wrote:                                
> (Wed, 08 Aug 
> > > > > > > 2001 20:31:01)
> > > > > > > > I also had to  have the air conditioning unit 
> fixed last 
> > > > > > > night. It is
> > > > > > > > Thanks for the explanation. Option (2) was kind 
> of a kludge 
> > > > > > > coming off
> > > > > > > > the top of my "sweating" head at the time. I 
> realized that 
> > > > > > > there will be
> > > > > > > > problems with it...
> > > > > > > >  
> > > > > > > > I think both of your solutions should work. If 
> I am to pick 
> > > > > > > one, I would
> > > > > > > > prefer option (4). As for option (5), we are 
> back to the 
> > > > > > > initial debate
> > > > > > > > about the semantics of "Network Appearance". If 
> I remember 
> > > > > > > correctly, a
> > > > > > > > different networks, not different attachments 
> to the same 
> > > > > > > network. As
> > > > > > > > problem making the scenario work. Of course, 
> the texts in 
> > > > > > > the spec need

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 11:15:21 -0500

John,

John Schantz wrote:                               (Thu, 09 Aug 2001 09:01:53)
> 	Did I say at anytime SPs were not permitted to have the "transfer

You said the configuration was invalid because I didn't have an STP
in the diagram.  You were wrong.  Be professional and admit it.

> products in these networks today.

It is more than this.  I was putting DMS Inodes in the SS7 network before
you started editting the T1 spec.

> it work. I have built working products of networks over the world since

I was putting in this configuration in 1986.  It still persists in the
SS7 network and is a natural and intended part of the specification.
I'm sorry but the real world does not subscribe to your interpretation
of the standards, and hasn't for over 15 years.

> out and speak up and try to get it back on track.	

Your opinion.  What I am attempting to do is make M3UA more robust, valuable
and interoperable as a specification: one that works with existing SS7
networks.  You call this degrading, yet you cannot put your finger on a
single "degradation" other than proposals don't fit your view of the world.

Please.  Tell us now.  What is it about these changes which so degrades
M3UA from a technical perspective?

> start acting like a professional in the Telecommunications Industry.

Please act as a professional.  Particularly and engineering professional
and address the technical situation at hand.

I ask again: what are your technical objections to CPC and RC in SNMM?
Please be a little more precise than "I don't like it" or "its too complex"
or "it degrades M3UA".

--Brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 13:28:12 -0500

Hong, and others,

There are a number of ways of getting around the problem
presented in the network configuration example.  I summarize
them here for discussion:

    A)	Restrict ASPs to serve no more than one Point Code.

    B)  Restrict SGs to no more than one network access to the
	same network (i.e. point code address space).

    C)  Force the ASP in these situations to have one
	association per set of ASs which form a uniquely
	attached SPMC.

    D)	Let the definition of Network Appearance be expanded
	from Network Id (i.e. point code address space) to
	include Network Attachment (i.e. unique network
	attachment/SPMC combination).

    E)  Place Concerned Point Code(s) information in all SNMM
	messages to identify the SPMC(s) to which the SNMM
	message applies.

    F)	Place Routing Context(s) in all SNMM messages to
	identify the AS(s) to which the SNMM message applies.

    G)	Combined E) and F) approach.

Following is my technical consideration of the merits and
drawbacks of each approach:

Approach A): Restrict ASPs to serve no more than one Point Code.

   This restriction has been opposed in the past due to
   consideration of valid cases where an MGC can have multiple
   point codes.  Switches with multiple point codes has been
   supported in GR-137 GR-394 and Q.764/767 for some time.
   Multiple point codes in an MGC may be required for any of the
   reasons for which it is required in a switch today: CIC
   exhaustion, special routing, multiple network attachments,
   mediation, gateway switching between networks in the same
   point code address space (e.g. access tandems), etc.

   Approach A will limit the usable deployment of M3UA within
   the SS7 network.

Approach B):  Restict SGs to no more than one network access to
	      the same network (i.e, point code address space).

   This approach would require mixed fully associated and
   quasi-associated networks to have one SG per F-link which is
   attached to a node with the transfer function.  This would be
   an administrative nightmare from two perspectives:  1) in
   some existing networks this will require hundreds of SGs per
   ASP, 2) addition (or activation) of the transfer function at
   the end of an F-link would mean that a separate SG must be
   split off from other F-Links.  The only way that
   adminstration would be possible in some prevalent network
   configurations would be if a separate SG were to be allocated
   to each F-Link.  This approach effectively turns M3UA into
   M2UA in these configurations.  In addition, M3UA cannot
   properly handle the case of multiple SGs yet, particularly as
   regards UPU handling across the SGs.

   Another, related, alternative which does not have the
   multiple-SG problem, is restricting SGPs to no more than one
   network access to the same network.  But then, this will
   require the ASP to keep track of routing on a per-SGP basis
   (part of the embroiled controversy over partitioning of
   SGPs).

   Approach B is not practical in mixed fully and
   quasi-associated networks, limiting M3UA's applicability to
   primarily the North American market in all but very
   restricted applications.

Approach C):  Force the ASP in these situations to have one
	      association per set of ASs which form a uniquely
	      attached SPMC.

   The difficulty with this approach is that in mixed fully and
   quasi-associated networks, similar to Approach D, it is
   difficult for the ASP to know when a separate association is
   required.  Also, the requirement for a separate association
   may change depending upon changes made back in the SS7
   network over which the operator of the SG may have no
   control.  The only way around this is to allocate a separate
   association for each network attachment (e.g., F-link).  This
   could result in the associations being required numbering the
   product num(ASP) X num(SGP) X n(F-Links).  For 4 ASPs, 4 SGPs
   and 100 F-links, this requires 1,600 associations.  This does
   not scale well and may hit the limitations of the number of
   usable open system-wide or per-process file descriptors, not
   to mention the addressable space necessary and management
   nightmare to track 1,600 AS states at the SG.

   Approach C does not scale and is not practical in mixed fully
   and quasi-associated networks, limiting M3UA's applicability
   to prmiarily the North American market in all but very
   restricted applications.

Approach D):  Let the definition of Network Appearance be
	      expanded to include Network Attachment where
	      necessary.

   The difficulties in this approach are two-fold:

   It is not possible for the ASP to determine `a priori' the
   requirement for separate Network Appearance values.  This
   depends on SS7 network configuration and attachment at the SG
   which can change.  The requirements for separate Network
   Appearance values can change with a few keystrokes on a node
   back in the SS7 network over which the operator of the SG and
   ASP may have no control.  To provide additional attachments
   to the SS7 network which do not include the addition of new
   SPMCs or SPMC point codes could result in the need for new
   Network Appearance values which would have to be provisioned
   at both the SG and the ASP.

   This requires the ASP to have information pertaining to the
   attachment of the SG to the SS7 network.  In the backhaul
   case, there is absolutely no need for an MTP-User to have
   knowledge of the underlying network configuration.  This is
   information which is unnecessary at the ASP and provides an
   unnecessary administrative hassle.  It provides a necessity
   for coordination of SG attachment changes at the ASP which,
   where SG and ASP are separate operators, is completely
   impractical.

   In addition, this requires passive monitoring devices to be
   equipped with the same information which is provisioned at
   the SG and ASP to be able to interpret monitored messages
   between the two systems.

   Configurations can occur where multiple Network Appearances
   values have been assigned to the same network attachment/SPMC
   combination requiring the SG to send multiple SNMM for the
   same SPMC, including multiple NAs in one SNMM message, or
   performing complex logic at both the SG and ASP to reduce the
   redunancy between non-unique Network Appearance assignments.

   Approach D causes problems for configurations wishing dynamic
   allocation (because these shifting NA values must be
   statically provisioned before they can be used in REG REQ
   messages).

   Approach D is not practical at interconnect points.  As most
   MGC operators are expected to be interconnects (or treated as
   interconnects within a regulatory framework), Approach D
   would limit M3UA's usability to a single operator's network.

Approach E):  Place Concerned Point Code(s) information in all
	      SNMM messages to identify the SPMC(s) to which the
	      SNMM message applies.

   Approach E can be accomplished by putting SPMC Id (primary
   PC) in the NA as proposed originally by Joyce, or replacing
   or augmenting the NA with a Concerned Point Code parameter.

   Approach E has the advantage that it resolves the
   administrative hassles associated wtih Approach D, it is
   possible to statically provision a point code list at the ASP
   without regard to the explicit network attachment of the SG
   to the SS7 network.  It permits passive monitoring without
   provisioning of Approach D Network Appearance values.

   Approach E has the disadvantage that the ASP must perform
   more complicated logic and maintain additional mappings to
   determine to which active AS (MTP-User) the MTP-PAUSE/STATUS
   primitive must be indicated.  In addition, it requires the
   ASP to have knowledge of the provisioned routing keys to
   perform this mapping, meaning that routing keys must be
   provisioned at both the SG and the ASP.  This is because the
   ASP must map CPC to a routing key list which includes that
   CPC as a DPC, to an RC list, to a list of active ASs, to
   determine whether to issued the MTP-PAUSE/STATUS primitive to
   the MTP-User at the AS.

   Approach E also has the disadvantage that it is inconsistent
   with the approach taken by SUA.

   Approach E is workable in all network configurations, but
   places additional (and unnecessary) mapping and information
   requirements on the ASP and is inconsistent with the approach
   taken by SUA.

Approach F):  Place Routing Context(s) in all SNMM messages to
	      identify the AS(s) to which the SNMM message
	      applies.

   Approach F has all the advantages of Approach E (except
   passive monitoring) plus it reduces the information and
   mapping requirements at the ASP in the backhaul case.  When
   the ASP receives an SNMM message, it simply generates
   MTP-PAUSE/STATUS primtives to those MTP-Users at those AS
   which are indicated by the RC in the list.  The ASP does not
   need to maintain Routing Keys or Routing Key to Routing
   Context mappings.  This has the advantage in static
   configurations that the only information that an ASP need
   know is the Routing Context to provide full service to an
   Application Server.

   Approach F has the advantage that the approach is consistent
   with that taken by SUA.  It also has the advantage that it is
   consistent with the Routing Context demultiplexing approach
   taken for DATA messages.

   Approach F has the disadvantage that passive monitoring
   devices must either be statically provisioned or intercept
   REG REQ messages to determine the nature of the SNMM if there
   is no other information in the SNMM.

   Approach F is workable in all network configurations, but
   makes it difficult to perform passive monitoring.

Approach G):  Combined E) and F) approach.

   Approach G consists of placing Routing Context(s) in all SNMM
   messages which require them, and optionally placing a
   Concerned Point Code parameter in the message as well.  This
   is effectively Approach F with the extension of an optional
   Concerned Point Code parameter to be placed in the message
   when passive monitoring is required.

   Approach G has all the advatages and none of the
   disadvantages of the other approaches.

I propose Approach G.

--brian

Hong Liu wrote:                                  (Wed, 08 Aug 2001 00:36:21)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 9 Aug 2001 13:50:55 -0700

I would like to once again state that I agree with Tolga, Barry, & Klaus.

I have re-looked at the Network Appearance definition in v8 and I do not
agree with it.    In drafts 5 & 6 the definition identified a network
context that several nodes could share.  In v7 (& v8), it was changed to
identify unique nodes in a network.  This is quite a change.  We need to go
back to at least the previous definition (v5 & v6).

Here is an example of how the v5/v6 definition would work:

Suppose you have a pair for signalling points connected to a pair of SGs
that are functioning as STPs and but more than that, mated STPs.  All these
node are part of network A and have PCs assigned from A.

                             +-----+       +-----+
                      -------| SG1 |-------| AS1 |
                            /+-----+\     /+-----+
              to the    \ /           \ /
             rest of    / \           / \
            network A       \+-----+/     \+-----+
                      -------| SG2 |-------| AS2 |
                             +-----+       +-----+             

Now suppose that AS1 & AS2 need to communicate with another network (for
roaming wireless customers as an example).  AS1 & AS2 could connect to the
other network (say B) themselves or with SS7 over IP, the SGs and ASs can
become part of both networks and the traffic from A & B could share the same
associations between the SGs and ASs.  In this case, you would want to
assign a network appearance NA-Aa that all 4 nodes will use to identify the
traffic and nodes for network A.  A network appearance NA-Bb would be
assigned and used by all 4 nodes to identify the traffic and nodes for
network B. Logically nodes SG1-Aa, SG2-Aa, AS1-Aa, and AS2-Aa function as
part of network A.  Nodes SG1-Bb, SG2-Bb, AS1-Bb, and AS2-Bb function as
part of network B.  The only thing these nodes have in common is the
hardware that they run on and the associations.

There is no other simple solution to this problem.  I don't v8's definition
works very well in this situation.

John
"Let them with Eyes See and Understand"  

> From: Gradischnig, Klaus [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 8:33 AM
> To: sigtran
> > possible. My
> > entty(Point Code) into 
> > (Mon, 06 Aug

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 16:29:22 -0500

John,

I cannot support reverting the NA definition of M3UA to v5 or 6
definition without the addition of CPC and RC to data and management
messages per existing technical argument on this thread, consistent
with the original view of Norm Glaude and Joyce Arhcibald which led
to the change in M3UA v7 and 8.

Without these other changes, your proposal will restrict M3UA from
supporting existing network configurations as already discussed, both
leading up to the original change and more recently on this thread.

John Schantz wrote:                            (Thu, 09 Aug 2001 13:50:55)
> back to at least the previous definition (v5 & v6).

Why?  What are your technical grounds for this reversal?

> associations between the SGs and ASs.

Network B is not shown in the diagram.

> In this case, you would want to
> traffic and nodes for network A.

You may want to do that but it is sufficient to apply the v8 definition.

> A network appearance NA-Bb would be
> network B.

Again, you may want to do that but it is sufficient to apply the v8 definition.

> Logically nodes SG1-Aa, SG2-Aa, AS1-Aa, and AS2-Aa function as

So?

> 
> There is no other simple solution to this problem.

I see no problem.

> I don't v8's definition

The v8 definition works fine in this situation.  You can easily assign 4
network appearance values, one for each point code for each network
attachment.  They uniquely identify data and management message network
identity and SPMC.

Yes, it would be more ideal if CPC and RC were added to M3UA messages,
then, and only then, the definition of NA could be reverted to represent
point code numbering space only.

--brian

> "Let them with Eyes See and Understand"  
"The blind leading the blind."

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 10 Aug 2001 00:07:32 -0700

Simmer down, folks, let's not let this get out
of hand.  

Lyndon
 
--

On Thu, 9 Aug 2001 09:01:53    Schantz, John wrote:
>You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 09:00:11 -0700

Hong and others,

Comments below.

John
"Let them with Eyes see and understand"

> Sent: Thursday, August 09, 2001 1:28 PM
> To: sigtran
[John]  I don't see why an AS/IPSP can not handle more than one PC, most
being virtual PCs.  We do it today in SS7 networks.

> 	same network (i.e. point code address space).
[John]  If an SG can figure out how to do why restrict it?  Some STP vendors
and SEP vendors have found ways to do it in SS7 networks.
 
> 	association per set of ASs which form a uniquely

[John]  Using separate associations (i.e., not merging the traffic from
different network appearances on the same associations) is a valid solution.
We (the ASs/IPSPs) will use our own method for solving the issue.
> 	attachment/SPMC combination).

[John]  NA should be left alone, it already defines a network attachment for
a set of nodes.  Just provide the missing information in the SNMM messages
that the SS7 SNMM had, that is, just add sender (OPC) and receiver (DPC).
> 	messages to identify the SPMC(s) to which the SNMM
[John]  Only need to add sender (OPC) and receiver (DPC) to the SNMM
messages.

> 	identify the AS(s) to which the SNMM message applies.
[John]  Just add receiver (OPC).
 
>     G)	Combined E) and F) approach.
[John]  See comments above.  I am not going to bother commenting on the
rest.

> networks, but does

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 12:08:39 -0500

John,

Please see comments below....

John Schantz wrote:                                          (Fri, 10 Aug 2001 09:00:11)
> being virtual PCs.  We do it today in SS7 networks.

I take it you don't like approach A.  Neither do I.

> and SEP vendors have found ways to do it in SS7 networks.

I take it you don't like approach B.  Neither do I.

> We (the ASs/IPSPs) will use our own method for solving the issue.

Valid, but not the best for reasons discussed below.  Would you
care to comment on the reasons why/when one would not want to do
things this way?

> that the SS7 SNMM had, that is, just add sender (OPC) and receiver (DPC).

Not all SNMM messages derive from SS7 SNTM messages.  As such,
not all SNMM messages have an OPC or DPC as you indicate.
The CPC is the point code that the SNMM applies to.  OPC/DPC
will not work, and OPC is not needed by an MTP-User anyway:
The ASP M3UA could care less where an indication came from
in terms of OPC, it is only the fact that it applies to an SPMC
which counts.

> [John]  Only need to add sender (OPC) and receiver (DPC) to the SNMM

OPC/DPC does not work as explained above.

> [John]  Just add receiver (OPC).

OPC is worthless as explained above.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 10 Aug 2001 12:15:37 -0500

Please see comments and questions below:

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 2:28 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Hong, and others,

   Approach A will limit the usable deployment of M3UA within
   the SS7 network.
TOLGA>> In such a case, what is wrong defining more than one ASP, one per
point code, for this MGC?

TOLGA>> I think, here what is meant is defining more than one ASP. Because,
at least in my understanding, ASP is an SCTP endpoint, and between a SG and
ASP, there can be only one association. So, this will again correspond to
definign multiple ASPs. What is wrong with this? 

TOLGA >> If something has to be added to the SNMM messages, then I am for
CPC. This will mimic the situation in SS7 well, where also those messages
are sent on point code granularity. And I think, anyhow to have route keys
on ASP side is something usefull, for purposes like giving user applications
using ASP the opportunity to query the route keys, or when user applications
want to register for a traffic range, to check that the desired trafic range
is covered by a defined route key in ASP. Of course CPC is not enough, CPC +
old style NA.

I propose Approach G.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 12:40:43 -0500

Tolga,

Asveren, Tolga wrote:                                    (Fri, 10 Aug 2001 12:15:37)
> point code, for this MGC?

There is nothing wrong about it and it should be permitted.  If it
is the only solution in this case, then it places a restriction on
the architecture of the ASP which should be stated in the draft.
Currently the draft states that M3UA places no such architectural
restrictions on the SG/ASP configuration.

> definign multiple ASPs. What is wrong with this? 

There is nothing in the draft stopping multiple associations
between the same ASP/SGP pair.  Nevertheless, I agree that multiple
ASPs with disjoint routing contexts is also a possibility here.

> are sent on point code granularity.

SS7 does not send SNTM on a point code granularity, it sends them
on a route (linkset) granularity.  TFP, for example, only applies
to the route (linkset) upon which it is received.  Routing Context
better mimics SS7 granularity because it is at the level of the
route rather than the routeset.

> And I think, anyhow to have route keys
> is covered by a defined route key in ASP.

RK neutrality is not really the only reason to prefer RC over CPC.
RC simplifies demultiplexing of SNMM messages to AS just as it does
for the DATA case.

> Of course CPC is not enough, CPC +
> old style NA.

Or CPC == Network Id + PC as proposed by Joyce.

--brian

[snip]

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 10 Aug 2001 13:17:15 -0500

Brian,

But from SS7 User Part point of view, aren't SNTM on point code granularity?

  Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 10, 2001 1:41 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

[snip]

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

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 10 Aug 2001 14:06:32 -0500

Sorry, small correction, not SNTM messages but MTP-RESUME-IND,
MTP-PAUSE-IND, MTP-STATUS-IND, which is sent to SS7 User parts. All those
are sent to signaling points.

   Tolga

-----Original Message-----
From: Asveren, Tolga 
Sent: Friday, August 10, 2001 2:17 PM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Brian,

  Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 10, 2001 1:41 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

Asveren, Tolga wrote:                                    (Fri, 10 Aug 2001
12:15:37)

--brian

[snip]

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

---

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 12:21:23 -0700

Tolga,
	You are correct.  The TFP, TFA, and TFR are on a point code level
and apply only to the route between the two adjacent nodes/PCs (STP sending
the message (OPC) and the receiving node (DPC) (could be SS7 node)).

This is another reason why the DUNA, DAVA, etc. were defined at the PC level
so that they would be peers to the SS7 management messages.  This
network/node management philosophy should not change.  If some SGs and ASs
need to manage at the interface level (SGP/ASP), then separate management
procedures and messages should be defined for their use.

Ultimately it will come down to whether networks will want to buy the
limited SGs and ASs that can not support the single network/node management
view.

John

> From: Asveren, Tolga [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 1:17 PM
> To: sigtran
> (Fri, 10 Aug 2001 12:15:37)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 14:30:20 -0500

Tolga,

MTP-PAUSE, STATUS, etc are sent to User Parts.  The granularity is
the user part.  This is true particularly for MTP-STATUS which has
the User Part granularity inherent in the user part status
indication.

--brian

Asveren, Tolga wrote:                                    (Fri, 10 Aug 2001 14:06:32)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 12:37:28 -0700

Tolga,
	Actually you are correct in both cases.  But the cases where a DUNA
maps immediately into a number of MTP-PAUSEs are not major cases.  This
situation ONLY occurs when an AS has only one route for the affected
destinations in the DUNA.

	I think the general case is that the AS has multiple routes (routes
to a set of at least 2 SGs).  In this case, DUNAs must be collected from
each route that a remote destination is associated with before M3UA can send
an MTP-PAUSE for the unavailable destination.

	In the DAVA case, only one DAVA is sufficient for M3UA to send an
MTP-PAUSE (but only if it is the first).

John

> Sent: Friday, August 10, 2001 2:07 PM
> To: sigtran
> > at least in my understanding, ASP is an SCTP endpoint, and 
> between a SG
> and
> > want to register for a traffic range, to check that the 
> desired trafic
> range

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 14:48:07 -0500

John,

DUNA, DAVA, etc are not peer to SS7 management messages
in the backhaul case: they are peers to the MTP/MTP-User
primitives.  This is clearly stated in the draft: M3UA
exports the MTP/MTP-User interface, it does not attempt
transport MTP to MTP Peers messages, not does it claim
to do so.

John Schantz wrote:                                          (Fri, 10 Aug 2001 12:21:23)
> limited SGs and ASs that can not support the single network/node management

The proposed changes do not preclude a single network/node management
view.  They merely permit other views as well.  So, ultimately it will
come down to whether networks will want to buy SG ASs which *only*
support the single network/node management view.

--brian

> > between a SG and
> > desired trafic range

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 10 Aug 2001 14:54:19 -0500

Brian,

Except for MTP-STATUS with UPU, I wouldn't agree with you for the following
reason:
For example when MTP-PAUSE should be sent, it is sent to all user parts, not
to a specific one based on the content of the message. The functionalit here
is not selection odf user part but distribution to user parts. And I think
this distribution functionality fits more to ASP-NIF. What is your opinion?
Also for MTP-STATUS with UPU, I would like to do the analysis (selection of
user part) in ASP-NIF. Comments?

   Regards,
   Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 10, 2001 3:30 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

14:06:32)

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

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 12:54:08 -0700

If you are stating that M3UA still sends TFP, TFA, etc. in the non-backhaul
cases and uses DUNA, DAVA, etc. ONLY in the backhaul case, then fine, I
don't care what you do with them.

> Sent: Friday, August 10, 2001 2:48 PM
> To: sigtran
> (Fri, 10 Aug 2001 12:21:23)
> > Tolga,

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 15:07:22 -0500

Hi Tolga,

Allow me to elaborate on some of the reasons for wanting RC in
SNMM over CPC.  Although it appears that it is not too difficult
for the M3UA ASP to support routing keys to the level necessary
to perform CPC to AS mapping for M3UA SNMM this is not the case
for M3UA DATA, nor is it the case for IUA, M2UA and SUA.

To demultiplex M3UA DATA messages to AS would require the ASP
M3UA to maintain a list of arbirtrarily complex Routing Keys to
support all SG implementations.  By including RC in the DATA
message permits the M3UA ASP to be RK neutral in this respect
and enhances interoperability.

M2UA (and IUA similar) do not use a link key for messages passed
across the Link to MTP inteface because these messages are
referenced to one and only one interface.  Nevertheless, when
messgaes are passed to the M2UA ASP, IID is used in the same
fashion as RC to indicate the AS to which the message applies.

SUA cannot use a Routing Key at the ASP SUA.  This is because
SUA's equivalent of a Routing Key is the Address Mapping
function.  The AMF is quite complicated and could even be
database size.  Requiring the ASP SUA to maintain a copy of the
SG's AMF database at the ASP is not feasilble in SUA, so SUA
uses the RC to keep the SUA ASP AMF neutral.

So we have this situation where IUA and M2UA are LK neutral,
M3UA DATA needs to be RK neutral, and SUA messages are AMF
neutral.

I agree with John Loughney that consistency is important here.
A common approach needs to be taken between M3UA and SUA,
particularly as regards the DUNA, DAVA, DRST,... messages that
they overlap on.  RC in SNMM for M3UA is completely consistent
with the entire SIGTRAN suite.  CPC only will rule out the
advantages of consistency from M3UA which include the ability to
transfer implementation and engineering experience with the IUA,
M2UA, M3UA DATA and SUA approaches to implicitly cover M3UA SNMM
as well.

There is no question that RC provides all of the capabilities of
CPC with the exception of passive monitoring.  CPC could be
easily optionally included when passive monitoring is desired
and so I propose Approach G).

Also, placing RC in SNMM does not preclude the ASP UA from
maintaining a list of Routinkg Keys if it so chooses to do so.
It just doesn't require the ASP to maintain such a list.

And, sending MTP-PAUSE/RESUME/STATUS to an MTP-User part list
is exactly what MTP does in the standards specifications.  It
is quite natural for the MTP at the SG to compile the list,
because that is what it does in SS7 today.

Do you have any technical objections to Approach G?

--brian

Asveren, Tolga wrote:                     (Fri, 10 Aug 2001 13:17:15)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 15:09:27 -0500

John,

M3UA provides the MTP-User interface even in the IPSP case,
it does not transport MTP Peer-to-Peer messages.  It transports
MTP-User primitives from one MTP-User interface to another.

--brian

John Schantz wrote:                                          (Fri, 10 Aug 2001 12:54:08)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 15:30:05 -0500

Tolga,

Yes, MTP sends these primitives to all user parts.  Without RC in SNMM
M3UA would have the ASP compile this list of user parts rather than the
MTP in the SG, where it belongs.  Distribution of MTP primitives to user
parts is a normal function of MTP at the SG, it is in the MTP procedures
and in the MTP SDLs.  It will be unnatural to coerce a compliant MTP to
give up the ability to perform this distribution to User Parts.  The
M3UA NIF at the SG would have to attach as all users, collapse the
multiple user part indications into a single message, calculate all the
user parts again, and then send the message with CPC.

This hack has problems with compliant MTP stacks which are perfectly
within their rights to cancel a broadcast of MTP-PAUSE to multiple users
mid-stream upon detection of routeset availability.  It is only
necessary for it to send MTP-RESUME to those user-parts to which it has
previsously sent an MTP-PAUSE.  Your function which collects these
indications must be placed below the MTP/MTP-User interface as defined
in Q.704/T1.111.4/...

Also, some MTP/MTP-user interfaces (ITU-T) differ somewhat in the way
they address MTP User indications.  Some interfaces will only return an
MTP User indication in response to a message sent to a concerned for
every 2n, 3n, 4nth message from the User Part.  How is the ASP to
distinguish to the MTP at the SG which user part is sending?  Did you
expect the MTP at SG to apply a reverse Routing Key to the message to
determine which count to increment?  If the AS places its Routing
Context in its DATA messages from the ASP to the SG, the SG can inject
the message into the appropriate MTP/MTP-User interface and let the MTP
at the SG do the counting.

Did you really want these MTP/MTP-User variant issues to be placed in
the ASP?  I don't.

Also, this would both be against the objectives of M3UA to export the
MTP-User interface (and gets into a blurry zone where someone will need
to define how this is going to work below the interface in a standard
and interoperable way), and also precludes SG vendors who wish to
provide M3UA functionality on top of compliant 3rd party commercial MTP
stacks.

No, I must disagree.  The architecture precludes this function from
being performed at the ASP and having it performed at the SG and placing
RC in DATA and SNMM permits the ASP to be completely neutral and just
transport the MTP/MTP-User Primitive interface syntactically, without
necessarily getting involved in the variations of semantics of the
interface.

The RC approach with ASP neutrality in all these regards, is perfectly
valid for the IPSP case, where the ASP merely echoes the MTP Primitive
interface between two IPSPs.  It is up to the IPSP NIF to determine
which MTP Primitives to send when, and is responsible for its choice of
semantics for the exchange.  IPSPs must choose between ITU-T and ANSI
and other MTP/MTP-User semantics anyway, but the ASP implementation gets
out of the way.  The MTP/MTP-User primitive interface is easily
normalized from a syntactic view, but cannot be normalized from a
semantic view.

It would be best to leave the interface semantics in the compliant MTP
implementation at the SG, where they already reside.

Does that clear up more of my leanings towards Approach G?

--brian

Asveren, Tolga wrote:                           (Fri, 10 Aug 2001 14:54:19)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 13:32:57 -0700

Sorry, but NO.  In the non-backhaul case, M3UA peer-to-peer network
management messages are REQUIRED.  MTP-user primitives are useless at this
level.  I think these peer-to-peer messages are the DUNA, DAVA, etc.  Only
in the special case of backhaul might they be used to convey information for
the MTP-user primitives.

John

> Sent: Friday, August 10, 2001 3:09 PM
> To: sigtran
> (Fri, 10 Aug 2001 12:54:08)

---

---

From: Joyce Archibald <[email-masked]>
Date: Mon, 13 Aug 2001 09:14:45 +0100

Hi All,

My interest is in passive monitoring of networks which use SCTP and its
User Adaptation layers.

In April, (04/02/01 on the Network Appearance thread) Norm Glaude
explained at some length why the Network Appearance parameter needed to
define end-nodes rather than just being the Network Id. This explanation
appeared to be accepted by the list at that time, so to accomodate this
requirement I proposed the following format for the Network Appearance
parameter:

    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 = 1            |        Length = 8             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Network Id.   |         End node Id (or pointcode)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For passive monitoring, all that is required is the Network Id. This can
be within a Network Appearance parameter or embedded in the high byte of
the point codes.

I agree with John Loughney that M3UA and SUA should be consistent on
this issue. However, since SUA does not support dynamic registration,
how and where is the Routing Context defined/allocated?

Regards,
Joyce

-- 
==================================================================
Joyce Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521
Agilent Technologies UK Ltd  | Telnet:   313 2521 
South Queensferry,           | Mailstop: SQFRD3A
EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---

---

From: [email-masked]
Date: Mon, 13 Aug 2001 11:49:06 +0300

Hi Joyce,

> how and where is the Routing Context defined/allocated?

With regards to SUA, Routing Context is a locally defined parameter - 
of only importance to the local endpoints.  Most likely, this will
be provisioned via a MIB, or local configuration tables.  

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 03:50:45 -0500

Joyce,

A dynamic registration proposal for SUA was provided July 30 on the
thread "SUAv7: ASP Capablities".

--brian

Joyce Archibald wrote:                        (Mon, 13 Aug 2001 09:14:45)
[snip]

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

---

---

From: Joyce Archibald <[email-masked]>
Date: Mon, 13 Aug 2001 10:57:39 +0100

Hi John,

Surely that means that in SUA-07, since Network Appearance has been
replaced by Routing Context, it is not possible to identify which
network a point code belongs to.

This is likely to be a problem for monitoring systems.

If the Network Appearance parameter is re-introduced in line with
whatever is decided for M3UA, does there need to be some way of linking
Network Appearance and Routing Context?

What is the latest position regarding the proposal for dynamic
registration in SUA

Regards,
Joyce

PS. Perhaps this whole discussion should be moved to "M3UA08 & SUA07:
Network Appearance".

[email-masked] wrote:
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Ming Lin <[email-masked]>
Date: Mon, 13 Aug 2001 21:14:59 +0800

Hi all,

I think there are two issues:
1.SSNM messages don't reflect the affected OPC
when one ASP serves for multiple ASes with different PC.
2.What is Network Appearance?

For issues 1, I have proposed to add OPC as optional parameter
in SSNM message a long time ago.
I think it is still a reasonable solution.

For issues 2, as the definition in M3UA draft, it is used
when the NI in MTP lable is not enough to identify
the difference between the networks supported by SG.
In most time, NI is enough, and network appearace is not used.
I think network appearace could be used when SG is connected to
a SS7 national network supported ITU white book
and a SS7 national network supported ITU blue book,
or SG is connected to MTP3 and MTP3B. -:0)

-----Original Message-----
发件人: Joyce Archibald <[email-masked]>
收件人: sigtran <[email-masked]>
日期: 2001年8月13日 17:52
主题: Re: M3UA07: Network Appearance

>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Aug 2001 08:26:09 -0500

Brian,

Please see comments and questions below.
   
   Regards,
   Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 10, 2001 4:07 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Hi Tolga,

TOLGA>>But for outgoing traffic (from ASP to SGs) still we will need to know RKs to be able to do the analysis of the messages sent by user applications, to decide to which SG they should be sent. Of course RK information can be kept outside of M3UA, but this will not get rid of RK on ASP side, just will change its place there.

TOLGA>>Now I see your point better and I think why different people have different ideas about this topic is, where they see the boundary between MTP3 and SS7 User Parts in SIGTRAN architecture, between SG-NIF and MTP3 or between ASP-NIF and SS7 User Parts. I think, your approach corresponds more to the first one. What I was thinking was the second one. I think, this is the real point, where the decision should be made and can have quite some impact on the protocol. 

Do you have any technical objections to Approach G?
TOLGA>> No (means not yet :) ) But as I indicated in the comment below, this is more than adding a new parameter.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 12:18:45 -0500

Tolga,

Asveren, Tolga wrote:                                    (Mon, 13 Aug 2001 08:26:09)
> TOLGA>>But for outgoing traffic (from ASP to SGs) still we will
> need to know RKs to be able to do the analysis of the messages
> sent by user applications, to decide to which SG they should be
> sent. Of course RK information can be kept outside of M3UA, but
> this will not get rid of RK on ASP side, just will change its
> place there.

The multiple SG case is not working well in M3UA anyway, there
is no need for any routing key distinctions in the multiple SG
case because the routing key is just the point code and the
only thing that need be examined is the SLS.  The availability
of point codes is available at the MTP/MTP-User interface,
regardless of whether there is one or multiple SGs.

What RK information did you think that the ASP would need to
maintain in the multiple SG case which is different from the
single SG case?  I say again: the ASP as the M3UA will not need
to maintain routing keys if RC is included in DATA.
> TOLGA>>Now I see your point better and I think why different
> people have different ideas about this topic is, where they
> see the boundary between MTP3 and SS7 User Parts in SIGTRAN
> architecture, between SG-NIF and MTP3 or between ASP-NIF and
> SS7 User Parts. I think, your approach corresponds more to the
> first one. What I was thinking was the second one. I think,
> this is the real point, where the decision should be made and
> can have quite some impact on the protocol. 

Per the following quotations from m3ua-08, it is clear to me
that the former approach is correct: the boundary between MTP3
and SS7 User Parts is the boundary between NIF and M3UA.
(The M3UA layer does not provide any MTP services).

Blurring MTP functions into the NIF at either the SG or ASP
strikes me as against both the M3UA protocool architecture as
stated in the draft and the SIGTRAN architecture as stated in
the RFC.

  M3UA Section 1.3.1 - Protocol Architecture:

  "Within the framework architecture, this document defines an
  MTP3-User adaptation module suitable for supporting the
  transfer of message of any protocol layer that is identified
  to the MTP Level 3 as an MTP User."

  M3UA Section 1.3.2 - Services Provided by the M3UA Layer

  "The M3UA Layer at an ASP or IPSP provides the equivalent set
  of primitive at its upper layer to the MTP3-Users as provided
  by the MTP Level 3 to its local MTP3-Users at an SS7 SEP..."

  "...The M3UA layer does not itself provide the MTP3 services."

> TOLGA>> No (means not yet :) ) But as I indicated in the
> comment below, this is more than adding a new parameter.

No parameter is being added.  An existing parameter is being
included in a message as optional.

First let's start with this: do you have any technical
objections to including RC as an optional parameter in SNMM
messages?

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Aug 2001 13:31:24 -0500

Brian,

Please see comments and questions below...
  
   Tolga

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

Tolga,

TOLGA>> What I think of is not loadsharing between SGs for the same RK but using different SGs for different RKs. In such a case, M3UA at ASP should be able to analyze the message to select the correct SG.

TOLGA>> Do you mean the boundary between SG-NIF and SG-M3UA?

  "...The M3UA layer does not itself provide the MTP3 services."
TOLGA>>When I look to SNMM in draft-08, I think for them the second approach is taken, the boundary is between ASP-NIF and SS7 User Parts, because they are sent once to ASP and distribution to different SS7 User Parts takes place on ASP side. 

First let's start with this: do you have any technical
objections to including RC as an optional parameter in SNMM
messages?
TOLGA>> I don't have any technical objection, because I think it should work fine. What I say is that, if necessary, other changes should also be done to make the boundary between MTP3 and SS7 User Parts consistent among M3UA, and also IMHO there are still valid solutions if one wants to leave the boundary as now.

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 13:50:51 -0500

Tolga,

Asveren, Tolga wrote:                                    (Mon, 13 Aug 2001 13:31:24)

[snip]

> TOLGA>> What I think of is not loadsharing between SGs for the
> same RK but using different SGs for different RKs. In such a
> case, M3UA at ASP should be able to analyze the message to
> select the correct SG.

In that case there is a 1:1 relationship between RK, RC, AS and
SG.  The ASP does not need to reapply the RK to select an SG:
the SG is associated directly with the AS.

> TOLGA>> Do you mean the boundary between SG-NIF and SG-M3UA?

Yes

> TOLGA>> I don't have any technical objection, because I think
> it should work fine. What I say is that, if necessary, other
> changes should also be done to make the boundary between MTP3
> and SS7 User Parts consistent among M3UA, and also IMHO there
> are still valid solutions if one wants to leave the boundary
> as now.

The boundary as it is now is the MTP/MTP-User interface.  See
sections 1.3.1 and 1.3.2.

[snip]

-brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Aug 2001 14:19:01 -0500

Brian,

More questions below....
  
    Tolga

In that case there is a 1:1 relationship between RK, RC, AS and
SG.  The ASP does not need to reapply the RK to select an SG:
the SG is associated directly with the AS.
TOLGA>> But then the problem is how to find the AS for a message coming from user application?

The boundary as it is now is the MTP/MTP-User interface.  See
sections 1.3.1 and 1.3.2.
TOLGA>> IMHO, it is still open to interpretation and when I look to M3UA messages, I get the impression the boundary is put between ASP-NIF and SS7 User parts for the following reason: (I am not saying that is the correct place for the boundary)
One SSNM message is sent from SG to ASP, it is split to multiple messages on ASP side. Also MTP3 sends multiple indications per user part.

[snip]

-brian

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

---

---

---

From: Ken Morneault <[email-masked]>
Date: Mon, 13 Aug 2001 15:27:03 -0400

Brian,

I do not understand your insistence that RC is required in
DATA message so that the ASP does not need to maintain
RKs.

For instance, let's say we are transitioning a piece of
call processing equipment from direct SS7 termination
to use of M3UA.  The User Part processes (i.e. those 
processing ISUP or SCCP traffic) would still be provisioned 
the same (OPC, DPC, SI, ....).  Thus, the User Part processes 
would have all the information required to "register" (not to 
mention enough information build Routing Keys for REG
REQ messages, if desired) with its M3UA layer to receive 
traffic of interest.  So, even though the ASP M3UA layer
does not have "formal" RKs, it has enough information along
with the Routing Label to determine the User Part process
the DATA message belongs to.

Sorry if I missed something you previously explained in
this thread.

Ken

At 01:50 PM 8/13/01 -0500, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 16:59:13 -0500

Tolga,

Asveren, Tolga wrote:                  (Mon, 13 Aug 2001 14:19:01)

[snip]

> coming from user application?

At the user application the MTP-User interface instance is the AS.
Selecting the MTP-User interface from multiple MTP-User interfaces
is the job of the user application, not the ASP M3UA.  Once the
MTP-User has selected the interface it corresponds 1:1 with an AS.
M3UA does not have to do any work or apply any routing keys.  The
MTP-User which is cognizant of the RK for which the MTP-User
interface (AS) applies, makes the selection.  M3UA at the ASP can
be completely RK neutral.

> TOLGA>> IMHO, it is still open to interpretation and when I look
> to M3UA messages, I get the impression the boundary is put between
> ASP-NIF and SS7 User parts for the following reason: (I am not
> saying that is the correct place for the boundary) One SSNM
> message is sent from SG to ASP, it is split to multiple messages
> on ASP side. Also MTP3 sends multiple indications per user part.

It is not interpretation: it is the stated intention of the SIGTRAN
and M3UA protocol architectures.

Once RC is included in SNMM the situation you describe will be
rectified and conform to the architecture.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Aug 2001 17:31:55 -0500

Brian,

   Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, August 13, 2001 5:59 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

>>be completely RK neutral.

TOLGA>> I disagree with this approach. I think, user applications should be
made unaware of M3UA constructs as much as possible. What you are proposing
is simplifying ASP-M3UA at the cost of increasing user application
complexity.
From 1.3.2:
"The M3UA Layer at an ASP or IPSP provides the equivalent set of primitives
at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its
local MTP3-Users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at
an ASP or IPSP is unaware that the expected MTP3 services are offered
remotely from an MTP3 layer at an SGP, and not by a local MTP3 layer"
As stated there, existence of M3UA should be as transparent as possible to
user parts. Probably then one can propose RK analysis for outgoing messages
to decide for AS shold be done on ASP-NIF, but this is still not getting rid
of RK on ASP side, just shifting it to somewhere else.
And the above paragraph from draft is one of the places which gives me the
impression that the boundary between MTP3 and SS7 User parts is between
ASP-NIF and SS7 User Parts. There it is said that the same interface like
between SS7 User Parts and MTP3 is provided between ASP and SS7 User Parts.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 17:56:47 -0500

Tolga,

Asveren, Tolga wrote:                                    (Mon, 13 Aug 2001 17:31:55)
> is simplifying ASP-M3UA at the cost of increasing user application

Actually I am not proposing that the application be aware of any
M3UA constructs, just that it be aware of MTP-User interfaces.  An
MTP-User must be aware of MTP-User interfaces regardless of whether
they are to MTP3 directly or via M3UA.  The application need not
know the difference.  What I am saying is that the AS selection is
implicit in the application selection of MTP-User interfaces.
Making a 1:1 association between RK:RC:AS and MTP-User interfaces is
provided for in M3UA.  It is not a proposal.

> of RK on ASP side, just shifting it to somewhere else.

The application does not perform RK analysis to select AS: it
selects the MTP-User interface that it chooses to use as an MTP-User
and the selection of AS is implicit in selection of MTP-User
interface.  RK analysis need not be performed on the ASP at all,
neither by M3UA at the ASP, nor by the application.  Only the SG
need perform RK analysis.  That is the whole point.  This is how
IUA, M2UA and SUA work.  If RC is placed in SNMM and DATA, that is
how M3UA can work as well.

> between SS7 User Parts and MTP3 is provided between ASP and SS7 User Parts.

So it is.  In selection of the MTP-User interface, the MTP-User
selects the AS and RC.  With RC in DATA and SNMM, the ASP (and
MTP-User for that matter) can remain RK neutral for all data
transfers and management messages.  It is only at the time that the
MTP-User interface is bound (either by RC selection or RK provided
in REG REQ) that the RK even becomes remotely involved.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Aug 2001 18:18:39 -0500

Brian,

Please see questions below....

   Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, August 13, 2001 6:57 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

>>how M3UA can work as well.

TOLGA>>This will work fine if the route key is limited to PC(+ SS7 User
Part) Now I see better why you try to avoid CIC ranges in route keys. But
when the CIC ranges are there, a route key analysis is necessary somewhere
on ASP side. Am I wrong?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 18:46:26 -0500

Tolga,

Asveren, Tolga wrote:                                    (Mon, 13 Aug 2001 18:18:39)

[snip]
> when the CIC ranges are there, a route key analysis is necessary somewhere

No routing key analysis is necessary in the CIC case either.  If the
application is binding to a CIC range on the MTP-User interface, then
by selection of the MTP-User interface so bound, it implicitly selects
AS:RC:RK once again.  Even though this is "above" the MTP-User interface,
the RK analysis can still be performed completely at the SG.

The application may care about the RK (CIC range) when it initially
binds this ISUP MTP-User interface, but the ASP M3UA need not ever
know the routing key.

This is the advantage of the RK-neutral approach, in that only the
application need know the form of the routing key (and need not perform
routing key analysis on any messages, this is implicit in selection
of interface).  This permits the SG to implement even more complex routing
keys of unforeseen types without modification at the ASP M3UA.

So, in short, no, RK analysis is never necessary on the ASP side for DATA
and SNMM messages, provided that the SG identifies those messages with RC.

The ASP M3UA merely maps RC to AS application interface and delivers the
messages as MTP primitives across the selected interfaces.  The application
selects the interface it wishes to send on (it must anyway) and this ties
an AS and RC value to the message.  The ASP may include this RC value in
DATA and SNMM so that the SGP need not apply reverse RKs nor examine the
messages in any other way that the stuff them down the same SG-local MTP
interface that is specified by the RC.

It works perfectly for SSN and TID as well (but I don't believe that
these are rational keys).  Another example would be a key (not loadshare
but routing) based on SLS.

This approach works fine in the case of SUA which has very complicated
routing keys (address mapping function) in comparison to M3UA.  It also
works fine for the trivial routing keys (link keys) in IAU and M2UA.

Why cannot M3UA get with the program?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 19:16:29 -0500

Ming,

Plese see comments below...

Ming Lin wrote:               (Mon, 13 Aug 2001 21:14:59)
> when one ASP serves for multiple ASes with different PC.

I like to use the term "Concerned Point Code" as defined in
the SS7 specifications.  With respect to SNTM messages, the
"Affected Point Code" is the one for which the status
pertains, the "Concerned Point Code" is the point code which
needs be notified of the status change.

> in SSNM message a long time ago.

Using the terminology "Concerned Point Code" which is a little
more accurate than OPC, you should have no problems with the
current proposal Approach E) and Approach G).

> I think it is still a reasonable solution.

Excellent.

> the difference between the networks supported by SG.

There is no label in M3UA SNMM messages.  As there is no
label and no NI bits, the Network Apperance as it stands
is required in M3UA SNMM messages to distinguish between
two NI values for M3UA SNMM messages.

What you say is true for M3UA DATA, but not for M3UA SNMM.

> In most time, NI is enough, and network appearace is not used.

NI is never enough because M3UA SNMM do not contain labels.

> or SG is connected to MTP3 and MTP3B. -:0)

SS7 compatibility rules permit these networks to interwork
without identification using NI bits in the SS7 network.
These compatibility rules apply to M3UA as well and there
is no need to use Network Apperance for Blue/White book
distinctions nor MTP Q.703/Q.2140 distinctions.

Because with the addition of RC to DATA and SNMM, the only
distinction required between different network ids is for
passive monitoring only.  The optional CPC of Approach G)
with embedded Network Id, as illustrated again by Joyce on
this thread, would be sufficient for the purposes of passive
monitoring.

With RC in DATA and SNMM, Network Appearance is no longer
required.

Ming, your simplified treatment of the issues overlooks: AS
demultiplexing at the ASP, routing key neutrality issues at
the ASP, RL neutrality issues at the ASP, and passive
monitoring issues.  Moving thru implementation, each of these
is a significant issue it its own right.

--brian

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

---

---

From: Ming Lin <[email-masked]>
Date: Tue, 14 Aug 2001 09:36:25 +0800

Brian,

The thread is so long to trace back.-:)

Could adding NI and CPC as optional parameter in SSNM
work for these problem?

And if NI could identify all the cases that SG will face
I think Network Appearance is no use and could be removed.
But are you sure NI is enough??

Cheers
Ming Lin
-----Original Message-----
发件人: Brian F. G. Bidulock <[email-masked]>
收件人: sigtran <[email-masked]>
日期: 2001年8月14日 8:11
主题: Re: M3UA07: Network Appearance

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 00:13:05 -0500

Ming,

Please see comments below:

Ming Lin wrote:                     (Tue, 14 Aug 2001 09:36:25)
> Could adding NI and CPC as optional parameter in SSNM

Approach G) includes Network Indicator + PC (not NI bits)
as an optional parameter (CPC in SNMM and OPC in DATA)
which solves the passive monitoring problem.  It also
includes RC in SNMM and DATA which solves the other
implementation issues.

> But are you sure NI is enough??

RC in DATA and SNMM identifies all the cases the SG will face
and resolves the implementation issues.  Network Ind + PC
(CPC in SNMM and OPC in DATA) solves the passive monitoring
issues.

This is the proposed Approach G.

--brian

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

---

---

From: Ming Lin <[email-masked]>
Date: Tue, 14 Aug 2001 14:55:13 +0800

Brian,
Please see commets below...

-----Original Message-----
发件人: Brian F. G. Bidulock <[email-masked]>
收件人: sigtran <[email-masked]>
日期: 2001年8月14日 13:09
主题: Re: M3UA07: Network Appearance

>includes RC in SNMM and DATA which solves the other

NI+DPC+OPC are all the MTP information,
why do we need RC in SSNM and DATA???

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 02:27:35 -0500

Ming,

Because NI+DPC+OPC is not all the MTP information: there is also SI, MP,
SLS, and user-part information such as CIC.

These other pieces of information with the NI+DPC+OPC form the Routing
Key which is identified by a Routing Context.i

The SG applies the RK and obtains a RC for routing the message.

Labelling SNMM and DATA with RC at the SG saves the ASP from knowing the
RK and reapplying it to this MTP information (which the M3UA SNMM
messages no longer contain, anyway).

--brian

Ming Lin wrote:                            (Tue, 14 Aug 2001 14:55:13)

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

---

---

From: Ming Lin <[email-masked]>
Date: Tue, 14 Aug 2001 17:57:09 +0800

Brian,
DATA message hold all the information that you list,
so DATA doesn't need RC.
SSNM messages don't need the information other than NI+DPC+OPC+SI,
and SI will be a parameter in DUPU message, and SSNM messages other
than DUPU don't need SI,
so SSNM also doesn't need RC.

Ming Lin
-----Original Message-----
发件人: Brian F. G. Bidulock <[email-masked]>
收件人: sigtran <[email-masked]>
日期: 2001年8月14日 15:22
主题: Re: M3UA07: Network Appearance

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 14 Aug 2001 08:05:32 -0400

Brian,

I agree with Ming.  Further, if RC was put in DATA then RC
would have to be provisioned on the ASP. 

Regards,

Ken

At 05:57 PM 8/14/01 +0800, you wrote:
>·¢¼þÈË: Brian F. G. Bidulock <[email-masked]>
>ÊÕ¼þÈË: sigtran <[email-masked]>
>ÈÕÆÚ: 2001Äê8ÔÂ14ÈÕ 15:22
>Ö÷Ìâ: Re: M3UA07: Network Appearance
>
>
> >Ming,
> >

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 07:10:00 -0500

Ken,

I think RC should be provisioned on ASP side anyhow. Otherwise how can it
sent ASPAC for a traffic range, which is identified in ASPAC message with RC
or how can it interprete a NTFY, whihc again has a RC parameter?
  
     Regards,
     Tolga

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:06 AM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Brian,

Regards,

Ken

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 07:58:56 -0500

I think RC should be provisioned on ASP side anyhow. Otherwise how can it sent ASPAC for a traffic range, which is identified in ASPAC message with RC or how can it interprete a NTFY, whihc again has a RC parameter?
  
     Regards,
     Tolga

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:06 AM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Brian,

Regards,

Ken

---

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 14 Aug 2001 09:18:47 -0400

Depends on your point of view.  An ASP does not need to have 
RC or RKs provisioned.   The ASPAC does not require RCs
and Notify is just informative.

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 09:21:49 -0400

Tolga,

The RC parameter is not mandatory in the ASPAC or NTFY messages. However, 
in the absence of an RC parameter, the receiving side must be configured 
with a mapping of ASPs to ASs.

Sections 4.2.3.4 (ASPAC) and 4.2.3.6 (NOTIFY) of m3ua v8 state:

"In the case where a Notify message does not contain a Routing Context 
parameter, the receiver must know, via configuration data, of which 
Application Servers the ASP is a member and take the appropriate action in 
each AS."

Barry Nagelberg

08/14/01 08:58 AM

I think RC should be provisioned on ASP side anyhow. Otherwise how can it 
sent ASPAC for a traffic range, which is identified in ASPAC message with 
RC or how can it interprete a NTFY, whihc again has a RC parameter?
 
     Regards,
     Tolga

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:06 AM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Brian,

Regards,

Ken

---

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 08:36:00 -0500

But if we consider the scenario where an ASP is serving only one AS, then
there won't be a need to analyse RK on ASP side (because there is only one)
so again Brian's proposal (using RC to eliminate RK analysis on ASP side)
will be valid (although I don't aggree with this approach 100% for other
reasons) And if ASP is serving more than one AS, then RC should be
provisioned on ASP, so using it in DATA does not bring extra burden.

      Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 9:22 AM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Tolga,

Barry Nagelberg

 
     Regards,
     Tolga

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:06 AM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Brian,

Regards,

Ken

---

---

---

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 14 Aug 2001 09:52:43 -0400

Pls see below.

Ken

>provisioned on ASP, so using it in DATA does not bring extra burden.

why do you feel it is necessary for RC/RK to be provisioned on ASP 
if ASP is serving more than one AS.  ASP can decide to be
active for all configured AS(s) or none (i.e. the call agent is processing
calls or it is not).   RC is only needed if there is a desire for ASP to 
control Active/Inactive state on an AS basis.

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 08:59:10 -0500

Ken,

Lets say ASP1 is configured to serve AS1 and AS2. If a user application (call control etc...) is registered to process traffic range for AS1 but not for AS2 then I think it is logical to activate ASP1 just for AS1 but not for AS2, because there is no user application to process traffic for AS2.
But if one limits user applications to register for every AS served by an ASP or none of them, then I aggree with you. Comments?

     Tolga

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 9:53 AM
To: sigtran
Subject: RE: M3UA07: Network Appearance

Pls see below.

Ken

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 07:28:05 -0700

Joyce,

Trying to force a parameter to include extra info for passive monitoring is
NOT being passive.  Including a PC is additional stuff that is not needed in
the real operation of the network, it only causes the operation of
separating the traffic to be more complicated.

I think that your monitoring equipment should do what everyone else does, go
into the message and pair up the NA with either the DPC or OPC.  But you
should know the  DPC & OPC since you are monitoring the transmission.

I think SUA should come back to earth and define an NA as an ID.

John

> From: Joyce Archibald [mailto:[email-masked]]
> Sent: Monday, August 13, 2001 3:15 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 10:54:14 -0500

Ming,

I have been around the horn with this with others.  Please
refer to the notes already on this thread.

The DATA message needs the RC so that the ASP need not
reapply the RK to obtain the RC for forwarding the
message to the AS.  This permits the ASP to be RK neutral
and protocol variant neutral, increases interoperability
and smooths implementation.

The SNMM messages need RC for the reasons already cited.
Please refer to the extensive technical argument already
presented on this thread.

--brian

Ming Lin wrote:                                              (Tue, 14 Aug 2001 17:57:09)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:01:23 -0500

Ken,

Don't be ridiculous.  When RC is required in the DATA, then
it is only because there are multiple RC multiplexed over
the same association.  When multiple RC are multiplexed over
the same assoctiation, the RC must be provided in the ASPAC
and must be either provisioned or dynamically obtained by the
ASP.  So, the RC is already "provisioned" on the ASP when
required in the DATA message.

I don't think that IID should be required in M2UA MAUP DATA
messages.  The ASP should be able to detect from the SLC in
various messages in the data stream which interface the
data corresponds to. :P  If the M2UA ASP cannot distinguish,
then it doesn't matter anyway because messages should only
be forward routed :P

Does that illustrate the ridiculousness of these statements?
What makes you think that M2UA and M3UA should be so different.
M2UA rates an IID lists (not just an IID mind you, but a integer
or text IID list, yet) in each message, where M3UA cannot be
permitted to have a Routing Context in a single message? Absurd.

--brian

Ken Morneault wrote:                                          (Tue, 14 Aug 2001 08:05:32)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:03:06 -0500

Ken,

DATA and SNMM would not require RC in the same circumstance:
where only one RC is active on an association.

--Brian

Ken Morneault wrote:                                          (Tue, 14 Aug 2001 09:18:47)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:08:47 -0500

Ken,

If it is not provisioned for RC in this case, then it will
have to be provisioned with each RK.  That is the current
arrangement for M3UA.  For M2UA and SUA and IUA it is the
reverse.  The M2UA ASP must be provisioned with IIDs in
similar circumstances.  IIDs are used in the control and
data messages in M2UA.  Why must the M2UA ASP be provisioned
with the IID?  We should remove the IID from all the M2UA
data messages and the ASP should be forced to determine the
AS and the interface within an AS on the basis of discerning
the SLC from various messages in the data stream.

--brian

Ken Morneault wrote:                                          (Tue, 14 Aug 2001 09:52:43)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 09:09:36 -0700

Brian,
	You know that is not true.  M3UA already has the minimal set, the
Network Management message peers, DUNA - TFP, DAVA - TFA, SCON - TFC, DUPU -
UPU, DAUD - RCT/RSM.

Are you forgetting the discussion on changeover and it was decided that it
was not needed, hence, COO, COA, CBD, CBA, ECO, and ECA are not needed.

RCT is already covered by DAUD.  RSP is not even a message. RSR could be
covered by DAUD.  RCP and RCR are cluster messages and already covered by
DAUD via a mask.

LIN, LUN, LIA, LUA, LID, LFU, LLI, LRI are point-to-point and involve the
management inhibit procedures.  This was also discussed and M3UA is not
supporting it, OK.

TRA and TRW are restart messages and they are also point-to-point.  Some
networks probably want restart covered somehow but it does not have to be
with these messages.

DLC, CSS, CNS, CNP are all data link allocation messages and I don't know of
a single vendor or network that uses these procedures and their messages.

Therefore, all the required management messages are already covered for
peer-to-peer communication.

John

> Sent: Friday, August 10, 2001 3:59 PM
> To: sigtran
> Hey John,
> If M3UA wished to support peer to peer MTP messaging it would need
> to include the following MTP peer-to-perr messages:
> 
> 	COO, COA, CBD, CBA, ECO, ECA, RCT, RSP, RSR, RCP, RCR,
> 	LIN, LUN, LIA, LUA, LID, LFU, LLI, LRI, TRA, TRW, DLC,
> 	CSS, CNS, CNP
> 
> M3UA only has MTP/MTP-User primitives covered.
> 
> --brian
> 
> John Schantz wrote:                                          
> (Fri, 10 Aug 2001 13:32:57)
> > > > > > > But from SS7 User Part point of view, aren't SNTM 
> on point 
> > > > > > > code granularity?
> > > > > > > 
> > > > > > >   Tolga
> > > > > > > 
> > > > > > > > TOLGA>> In such a case, what is wrong defining 
> more than 
> > > > > > > one ASP, one per
> > > > > > > > TOLGA>> I think, here what is meant is defining 
> more than 
> > > > > > > one ASP. Because,
> > > > > > > > ASP, there can be only one association. So, 
> this will again 
> > > > > > > correspond to
> > > > > > > > TOLGA >> If something has to be added to the 
> SNMM messages, 
> > > > > > > then I am for
> > > > > > > > CPC. This will mimic the situation in SS7 well, 
> where also 
> > > > > > > those messages
> > > > > > > > on ASP side is something usefull, for purposes 
> like giving 
> > > > > > > user applications
> > > > > > > > using ASP the opportunity to query the route 
> keys, or when 
> > > > > > > user applications

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:12:10 -0500

Tolga,

You can save provisioning RC at the expense of being forced
to provision RK at the ASP.  I see no reason not to permit
the ASP to do this if it wants.  Any SG including an RC in
the DATA and SNMM messages could be ignored by the ASP and
the ASP could use its provisioned RKs instead.  If the
ASP wants to be really inefficient about how it goes about
doing things, I see no reason not to let it.  This corner
case does not effect the proposal.  The ASP can do as it may
here.  It has all the information necessary.

--brian

Asveren, Tolga wrote:                                    (Tue, 14 Aug 2001 08:59:10)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 09:25:48 -0700

You are not looking at the whole picture.  

1) Backhaul vs. Non-backhaul:  The existing SS7 networks want to evolve and
use SS7 over IP.  M3UA is definitely one of the options that is being
heavily looked at.  Therefore, the non-backhaul case will be the general
(only) case for the nodes from these networks.  The backhaul case will only
apply to some new nodes that want to communicate with these existing
networks.

2) The evolution of the network will take time.  Initially some of the
higher capacity SS7 nodes (e.g., SCPs/HLRs and STPs) will move over to SS7
over IP.  Only as more of the SEPs move over to SS7 over IP will it be
possible for IPSP-IPSP communication.  But until that time, a common
protocol is needed that supports both IPSP-IPSP and IPSP(ASP) to SG.  This
protocol is M3UA.

3) The routing needs of the existing SS7 nodes moving over to IP are few.
The basic need is only PC routing.  Hence, all the bells and whistle that
are being added may never be needed by these nodes, therefore they must be
optional.

John

> Sent: Friday, August 10, 2001 4:23 PM
> To: sigtran
> Guess what?  M3UA SNMM messages are not even required in the IPSP
> case!  Each IPSP can derive the availability of point codes and user
> parts directly off of AS state and association state for those
> signalling points.  In the IPSP world, there is no STP transfer
> functions, so equivalents of SNTM messages are not required.  The
> only M3UA message other than ASPXM and RKM needed is DATA.  Congestion
> is derived direclty from SCTP association congestion state.
> 
> The IPSP still needs, however, to faithfully present the MTP/MTP-User
> interface on the upper boundary for MTP-Users to take advantage of.
> So, the MTP-User Primitives still need to be supported, but none of
> the MTP management peer-to-peer messages need to be supported.
> 
> So M3UA SNMM mesages are NOT REQUIRED.  They convey no information
> not already provided for in ASPXM and RKM messages.
> 
> --brian
> 
> John Schantz wrote:                                          

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 14 Aug 2001 12:30:05 -0400

Brian,

Pls see below.

Ken

>required in the DATA message.

I absolutely don't agree RC must be provided in the ASPAC
if multiple RC are multiplexed over the same association.

>then it doesn't matter anyway because messages should only

SLC is not unique if the M2UA SG terminates links from
more than one linkset.   Further, I don't think we want the
M2UA ASP to have to have knowledge required to look at the
Routing Label of a message.

>permitted to have a Routing Context in a single message? Absurd.

They are different.  The M3UA Data message contains all the
information needed by the M3UA ASP.

While I do not like adding RC as an optional parameter to DATA
(yet another optional parameter), my main concern was your
insistence in previous email that it was necessary.  Based on
reading another email you just sent on the same topic, I see
that I don't need to be worried about that anymore. 

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 09:30:24 -0700

I think Ming and I are coming from the same background.  We already have SS7
nodes that know how to associate a PC with an outbound route and loadshare
the traffic appropriately over the links within that route.

Therefore, all the information is already there in the message.  You only
have to use it.

I think the "others" that you have been around the "horn" with have not
accepted you answers.

John

> Sent: Tuesday, August 14, 2001 10:54 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:57:28 -0500

Ken,

Ken Morneault wrote:                                          (Tue, 14 Aug 2001 12:30:05)
> if multiple RC are multiplexed over the same association.

If multiple AS are multiplexed over the same association, then
either the RCs must be provisioned at the ASP or the RKs need
to be provisioned at the ASP for demultiplexing traffic to
multiple AS.  I would rather provision an integer than a
psuedo-arbitrary routing key.  The current spec forces me to
provision the routing key in this circumstance.

> Routing Label of a message.

Gee, why not?  It is so simple for M3UA to do on each
data message? :P  Also, the M2UA could discern the IID from
the SLS value for all received messages.  IID is (as)
unnecessary in the data message.

> information needed by the M3UA ASP.

M2UA data message contains all the information needed by the
M2UA ASP: it contains the SLS value, nothing more is needed.
I propose that we remove IID from data messages for M2UA.

> that I don't need to be worried about that anymore. 

What problems do you have with Approach G) all proposed?

--brian

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

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 13:24:55 -0400

As one of the "others" that John refers to, I would like to say that I 
have not accepted Brian's answers either.

Barry Nagelberg

08/14/01 12:30 PM

I think Ming and I are coming from the same background.  We already have 
SS7
nodes that know how to associate a PC with an outbound route and loadshare
the traffic appropriately over the links within that route.

John

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 14 Aug 2001 10:37:24 -0700

Folks,

We are getting carried away in this discussion.
I see no point in making new proposals every day
for changing this or that parameter in this or 
that UA.  We cannot make progress in this manner.

People are welcome to submit their own versions
of UAs to the IETF, and if they wish, they can
submit new versions with new ideas whenever the
urge comes to them.

We should be trying to narrow down exactly what
changes we have consensus on to make in the drafts
so that they can get finished.  Please try to 
focus your messages on this goal.

Thanks,

L. Ong
 
--

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 14 Aug 2001 10:52:18 -0700

Folks,

This discussion has gotten off track, and in fact
overlapped with the discussion on RC.

Let's get back to the thread of NA, definition
and use.

Thanks,

L. Ong

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 12:58:24 -0500

Lyndon,

John L. indicated that there should be consistency between
M3UA and SUA on this matter, and that this was of some
importance.  As it stands M3UA sticks out amoungst the UAs
and is not consistent with the others in this respect.

I would expect that one WG UA could strive for consistency
with the others.  M3UA has not.

Are you saying that this consistency is of some lesser
importance that was originally laid out by John?

--brian

Lyndon Ong wrote:                (Tue, 14 Aug 2001 10:37:24)

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 14 Aug 2001 11:06:54 -0700

I'm simply saying that the consensus in
the group at this time appears to be against the
RC, and we should move on. 

Cheers,

L. Ong
--

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 13:18:10 -0500

Lyndon,

I do not agree.  This issue must be resolved as
implementation depends on it.

It is also an issue for SUA Last Call whether
SUA needs align itself with M3UA or M3UA needs
align itself with SUA.

--brian

Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 11:06:54)

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 14 Aug 2001 11:32:20 -0700

Brian,

The issue is resolved, based on rough consensus of the
group, against the inclusion of RC.  As I noted, this
can be added in future if it really appears to be needed.

SUA is a separate discussion and should be handled
as such.

Let's move on, please.

Thanks,

L. Ong 
--

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 13:52:32 -0500

Lyndon,

I will not move on.

I object to the lack of RC in DATA messages on the technical
grounds that it violates the SIGTRAN architecutre and
introduces interoperability issues into M3UA at both the
syntactic (RK) and semantic (differences between ITU and
ANSI MTP/MTP-User semanitcs) levels.

At the M3UA bake*ff in Madrid, most of the chatter the first
days was whether an implementation supported a ANSI RL or an
ITU RL.  MTP-Providers and MTP-Users were not even being
tested.  The syntactic violation was obvious.  Why should an
M3UA implementation need to be RL specific?  Why should it
be MTP/MTP-User semantic specific? (Which was also raised
at the bake*off by Heinz Pratner's question as to whether
we supported ITU-T semantics at the MTP/MTP-User boundary or
ANSI semanitcs.)

As it stands M3UA cannot be implemented without MTP protocol
variant specifics (both syntax and semantic) being embedded
in the implementation.  This neither promotes interoperability
nor adheres to the SIGTRAN architecture.

While a proper approach is clear (SUA), M3UA does not address
these interoperability issues and you might leave no recourse
but to lodge formal complaint on technical grounds if the WG
moves the existing draft to IESG.

--brian

Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 11:32:20)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 19:03:40 -0500

IMHO, to be able to come a conclusion for Network Appearence Parameter, it
is important to decide for a strategy how to handle the configuration (SG
serving two SEPs with different point codes and with different SS7
connectivity) in figure posted by Brian to this thread some while ago.(The
figure is shown below)The problem is, what to do when link from SG to
200.1.4 is down? 5.255.3 cannot reach 200.1.4 but 5.255.4 can.
I think the options are:
1) If SG does not have transfer capability, don't allow it to have point
codes with different SS7 connectivity
2) Add a mechanism (Brian proposes adding RC + Concerned Point Code) to be
able to distinguish between point codes with different SS7 connectivity, to
be able to route DAVA, DUNA etc... correctly.

I am for 1). Either give SG transfer capability or does not allow multiple
point codes with different SS7 connectivity on that SG.  ===> NA can be
changed to definition in draft6 

If interested people say their preference, I think it could be easier to
come to a conclusion.

     Regards,
      Tolga 

                            200.1.4    __________
                              ___     /          \___
                             /   \   |            |   /\
                            | SEP |__|____________|__| SEP |  AS1
                             \___/   |            |\___/
                            //       |            |
                           / |       | Signalling |5.255.3
                          / /        |   Gateway  |
                         /  |        |            |
                        /  /         |            |
                _____  /   |         |            |
               |     |/   /          |            |
          -----| STP |____|__________|______      |
              /|_____|   /           |      \___  |5.255.4
             /    |      |           |          \_|____
          \ /     |     /            |            | \ /\
           X      |     |            |            | | SEP |  AS2
          / \     |    /             |           _|_/\___/
             \  __|__ /              |       ___/ |
              \|     |_______________|______/     | 5.255.5
          -----| STP |               |            | (alias)
               |_____|               |            |
                                     |            |
                                      \__________/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 19:37:28 -0500

Tolga,

You missed Approach D, which is basically leave the NA definition as it
stands in M3UAv8.  There is no reason to restrict the configuration as
in your option 1).  The situation in the diagram is already handled by
the current (M3UAv8) definition of NA.  In particular that an NA value
must be assigned for each Point Code in a network which represents a
unique network attachment.

No change is required to M3UAv8 to handle this situation.  I was
originally proposing that NA == Id + PC per Joyce's original proposal.
The current M3UAv8 places no restrictions on how I or other
implementations choose the NA values.  I will make them Network ID + PC
so Joyce's passive monitoring equipment will work with my
implementation, and in anticipation of any dynamic changes to network
configuration at the SG.  In effect, M3UAv8 allows me to number NA
values such that NA == CPC.  Other implementations can break Joyce's
equipment if they see some value in that.

I was also resisting proposals to make NA == Network Id (as it was in
M3UAv5 and v6).  In doing that I was echoing Norm Glaude's original
concerns which led to the change, and the example diagram.

The proposal to include RC in SNMM is merely for consistency with SUA on
the very same set of messagses used to indicated the very same network
management events (N_PCSTATE == SNMM).

If noone can see their way to support RC in SNMM, I see no reason to
change the existing M3UAv8 definition of NA or restrict the M3UA
configuration architecture in any way.  The current definition allows me
to do what I need to do to implement.

(RC in DATA is another matter and has many reasons to permit it as a
purely optional parameter.)

I will resist any proposal to change the existing NA back to be Network
Id from its current definition of on a per-attachment point code basis,
and thus your option 1) which restricts the architecture further than is
currently necessary.

Given the lack of support for RC, my preference is to leave M3UAv8 as
it stands regarding the definition of NA.  So, please add Option 3)
to your list:  "Leave M3UA as it stands (v7/v8 definition) regarding NA."

--brian

Asveren, Tolga wrote:                                    (Tue, 14 Aug 2001 19:03:40)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 15 Aug 2001 07:08:00 -0500

I apologize to forget two more choices:

3) Use different ASPs for AS1 and AS2, or more generaly said, if two ASs
have different SS7 connectivity, use different ASPs to serve them (Although
I have said I am for 1) in my former e-mail, I am also for      3), and it
has the advantage over 1) not putting a restriction and it also allows NA to
be defined as in draft6)
4) Don't address the problem at all

For all of the choices, there can be a different variants, I just wanted to
list the main ideas. For all of them pros and contras have been introduced
and discussed for long time in this thread.

   Regards,
    Tolga

-----Original Message-----
From: Asveren, Tolga 
Sent: Tuesday, August 14, 2001 8:04 PM
To: sigtran
Subject: RE: M3UA07: Network Appearance

     Regards,
      Tolga 

                            200.1.4    __________
                              ___     /          \___
                             /   \   |            |   /\

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 15 Aug 2001 07:11:32 -0500

Brian,

You are right. There is another option.
5) Leave NA as it is

    Regards,
    Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:37 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Tolga,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 08:48:39 -0500

Tolga,

With just a little massaging (you missed Approach E, place CPC in SNMM)
you will have my list of August 9th, which I attach again for your
convenience.

--brian

Asveren, Tolga wrote:                           (Wed, 15 Aug 2001 07:11:32)
> You are right. There is another option.

Bidulock, Brian wrote:                          (Thu,  9 Aug 2001 13:31:09)
> 
> Hong, and others,
> 
> There are a number of ways of getting around the problem presented in
> the network configuration example.  I summarize them here for
> discussion:
> 
>     B)  Restrict SGs to no more than one network access to the same
>         network (i.e. point code address space).
> 
>     C)  Force the ASP in these situations to have one association per
>         set of ASs which form a uniquely attached SPMC.
> 
>     D)  Let the definition of Network Appearance be expanded from
>         Network Id (i.e. point code address space) to include Network
>         Attachment (i.e. unique network attachment/SPMC combination).
> 
>     E)  Place Concerned Point Code(s) information in all SNMM messages
>         to identify the SPMC(s) to which the SNMM message applies.
> 
>     F)  Place Routing Context(s) in all SNMM messages to identify the
>         AS(s) to which the SNMM message applies.
> 
> Following is my technical consideration of the merits and drawbacks of
> each approach:
> 
>    This restriction has been opposed in the past due to consideration
>    of valid cases where an MGC can have multiple point codes.
>    Switches with multiple point codes has been supported in GR-137
>    GR-394 and Q.764/767 for some time.  Multiple point codes in an MGC
>    may be required for any of the reasons for which it is required in
>    a switch today: CIC exhaustion, special routing, multiple network
>    attachments, mediation, gateway switching between networks in the
>    same point code address space (e.g. access tandems), etc.
> 
>    Approach A will limit the usable deployment of M3UA within the SS7
>    network.
> 
>    attached to a node with the transfer function.  This would be an
>    administrative nightmare from two perspectives:  1) in some
>    existing networks this will require hundreds of SGs per ASP, 2)
>    addition (or activation) of the transfer function at the end of an
>    F-link would mean that a separate SG must be split off from other
>    F-Links.  The only way that adminstration would be possible in some
>    prevalent network configurations would be if a separate SG were to
>    be allocated to each F-Link.  This approach effectively turns M3UA
>    into M2UA in these configurations.  In addition, M3UA cannot
>    Another, related, alternative which does not have the multiple-SG
>    problem, is restricting SGPs to no more than one network access to
>    the same network.  But then, this will require the ASP to keep
>    track of routing on a per-SGP basis (part of the embroiled
>    controversy over partitioning of SGPs).
> 
>    Approach B is not practical in mixed fully and quasi-associated
>    networks, limiting M3UA's applicability to primarily the North
>    American market in all but very restricted applications.
> 
>    quasi-associated networks, similar to Approach D, it is difficult
>    for the ASP to know when a separate association is required.  Also,
>    the requirement for a separate association may change depending
>    upon changes made back in the SS7 network over which the operator
>    of the SG may have no control.  The only way around this is to
>    allocate a separate association for each network attachment (e.g.,
>    F-link).  This could result in the associations being required
>    numbering the product num(ASP) X num(SGP) X n(F-Links).  For 4
>    ASPs, 4 SGPs and 100 F-links, this requires 1,600 associations.
>    This does not scale well and may hit the limitations of the number
>    of usable open system-wide or per-process file descriptors, not to
>    mention the addressable space necessary and management nightmare to
>    track 1,600 AS states at the SG.
> 
>    Approach C does not scale and is not practical in mixed fully and
>    prmiarily the North American market in all but very restricted
>    applications.
> 
> 
>    requirement for separate Network Appearance values.  This depends
>    on SS7 network configuration and attachment at the SG which can
>    change.  The requirements for separate Network Appearance values
>    can change with a few keystrokes on a node back in the SS7 network
>    over which the operator of the SG and ASP may have no control.  To
>    provide additional attachments to the SS7 network which do not
>    include the addition of new SPMCs or SPMC point codes could result
>    in the need for new Network Appearance values which would have to
>    be provisioned at both the SG and the ASP.
> 
>    attachment of the SG to the SS7 network.  In the backhaul case,
>    there is absolutely no need for an MTP-User to have knowledge of
>    the underlying network configuration.  This is information which is
>    unnecessary at the ASP and provides an unnecessary administrative
>    hassle.  It provides a necessity for coordination of SG attachment
>    changes at the ASP which, where SG and ASP are separate operators,
>    is completely impractical.
> 
>    equipped with the same information which is provisioned at the SG
>    and ASP to be able to interpret monitored messages between the two
>    systems.
> 
>    Configurations can occur where multiple Network Appearances values
>    have been assigned to the same network attachment/SPMC combination
>    requiring the SG to send multiple SNMM for the same SPMC, including
>    multiple NAs in one SNMM message, or performing complex logic at
>    both the SG and ASP to reduce the redunancy between non-unique
>    Network Appearance assignments.
> 
>    allocation (because these shifting NA values must be statically
>    provisioned before they can be used in REG REQ messages).
> 
>    Approach D is not practical at interconnect points.  As most MGC
>    operators are expected to be interconnects (or treated as
>    interconnects within a regulatory framework), Approach D would
>    limit M3UA's usability to a single operator's network.
> 
> 
>    Approach E can be accomplished by putting SPMC Id (primary PC) in
>    the NA as proposed originally by Joyce, or replacing or augmenting
>    the NA with a Concerned Point Code parameter.
> 
>    Approach E has the advantage that it resolves the administrative
>    hassles associated wtih Approach D, it is possible to statically
>    provision a point code list at the ASP without regard to the
>    explicit network attachment of the SG to the SS7 network.  It
>    permits passive monitoring without provisioning of Approach D
>    Network Appearance values.
> 
>    Approach E has the disadvantage that the ASP must perform more
>    complicated logic and maintain additional mappings to determine to
>    which active AS (MTP-User) the MTP-PAUSE/STATUS primitive must be
>    indicated.  In addition, it requires the ASP to have knowledge of
>    the provisioned routing keys to perform this mapping, meaning that
>    routing keys must be provisioned at both the SG and the ASP.  This
>    is because the ASP must map CPC to a routing key list which
>    includes that CPC as a DPC, to an RC list, to a list of active ASs,
>    to determine whether to issued the MTP-PAUSE/STATUS primitive to
>    the MTP-User at the AS.
> 
>    Approach E also has the disadvantage that it is inconsistent with
>    the approach taken by SUA.
> 
>    Approach E is workable in all network configurations, but places
>    additional (and unnecessary) mapping and information requirements
>    on the ASP and is inconsistent with the approach taken by SUA.
> 
>    Approach F has all the advantages of Approach E (except passive
>    monitoring) plus it reduces the information and mapping
>    requirements at the ASP in the backhaul case.  When the ASP
>    receives an SNMM message, it simply generates MTP-PAUSE/STATUS
>    primtives to those MTP-Users at those AS which are indicated by the
>    RC in the list.  The ASP does not need to maintain Routing Keys or
>    Routing Key to Routing Context mappings.  This has the advantage in
>    static configurations that the only information that an ASP need
>    Approach F has the advantage that the approach is consistent with
>    that taken by SUA.  It also has the advantage that it is consistent
>    with the Routing Context demultiplexing approach taken for DATA
>    messages.
> 
>    Approach F has the disadvantage that passive monitoring devices
>    must either be statically provisioned or intercept REG REQ messages
>    to determine the nature of the SNMM if there is no other
>    information in the SNMM.
> 
>    Approach F is workable in all network configurations, but makes it
>    difficult to perform passive monitoring.
> 
>    messages which require them, and optionally placing a Concerned
>    Point Code parameter in the message as well.  This is effectively
>    Approach F with the extension of an optional Concerned Point Code
>    parameter to be placed in the message when passive monitoring is
>    required.
> 
>    Approach G has all the advatages and none of the disadvantages of
>    the other approaches.
> 
> I propose Approach G.
> 
> --brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 15 Aug 2001 07:24:25 -0700

No.  I don't buy Joyce's proposal.  The parameters in the messages should be
there to help the protocol and the nodes of the network, NOT to help someone
trying to monitor the network.

The NA definition in v8 is unusable.  I have seen general support for
returning it back to the definition in v5 & v6.

The figure you keep throwing up is poorly defined.  As soon a one argument
is made on it you change the information about it.  Is the SG doing its job
or not, is it providing connectivity for all of its supporting nodes.  You
claim that there are F-links but it involves 3 not 2 nodes for it (by
definition they can not be F-links).  You claim that because the remote node
connected via the invalid F-links may have the STP function and the SG loses
its links to it, this impacts how the SG functions.  Give me a break.  Stop
making up stuff, clearly define your figures, and then we can throw out the
"red-herrings".

> Sent: Tuesday, August 14, 2001 7:37 PM
> To: sigtran
> (Tue, 14 Aug 2001 19:03:40)

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 15 Aug 2001 07:37:23 -0700

Tolga,
	I've made this proposal before.  All SNMM messages should have a DPC
and OPC.  This should clearly identify the "to who" and "from what" the
message is for.  The NA is only needed when multiple networks or multiple
network appearances in the same network are involved.

I have already stated that this is a security issue in regular SS7 networks.
Most nodes will ignore Management messages that have not been sent by an
adjacent STP.  This prevent remote nodes from screwing up the route in a
node.  It also expected that an STP will discard any Management message it
receives that has its PC as the OPC.

I assume that we want to keep the SS7 over IP network just as secure as the
regular SS7 networks.

John

> Sent: Wednesday, August 15, 2001 7:12 AM
> To: sigtran

---

---

From: Joyce Archibald <[email-masked]>
Date: Thu, 16 Aug 2001 14:05:20 +0100

Hi John,

If you re-read my original message you may notice that what I actually
said was:
 
For passive monitoring, all that is required is the Network Id and my
proposed definition was to accomodate what was being agrred on the list
at the time. 

I think we are in agreement so what are you arguing about?

  Joyce

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 16 Aug 2001 08:51:30 -0500

Tolga,

I agree with your choice (I think).
From an MTP network management point of view an STP offers the same transfer
capability to all nodes in a particular network. While screening does
violate this principle, only screening based on incoming linkset/DCP can be
fully supported by network management. Therefore I see no reason to support
the configuration shown below in m3ua -- or rather, one can support it if
5.255.3 is connectd via a separate "linkset" i.e. assocication.

I agree with Lyndon even more - lets move on. It's time that m3ua gets out
the door. ITU seems to be a lot quicker...

Klaus

> Sent: August 14, 2001 8:04 PM
> To: sigtran

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 16 Aug 2001 17:23:45 +0200

Hello everyone,

Just to give my 0,02 $ on this already overloaded topic :

I guess everyone will agree to the fact that an ASP can register for several
RKs (whatever they may be), and can have multiple SCTP associations with the
same SG, over which messages for these routing keys can be multiplexed. This
is the most general architecture, no restrictions implied.

For each RK, a RC (simple integer) is agreed between SG and ASP to enable
the ASP to distinguish the traffic, for whatever reason (interpretation of
PC, management messages, SSN, ...). RCs are even more precise than NAs in
this respect, as they may define a subdomain of an SS7 network.

In this RK negotiation (static or dynamic), the NA is also specified (and
only 1, a reasonable RK limitation). This means RC implies the NA, and thus
is more than sufficient information for interpretation of point codes, SSNs,
management messages etc. This approach has been taken by SUA, and I don't
see any valid reason why M3UA couldn't go the same way.

The NA's are agreed between SG and AS providers, as part of the connectivity
arrangement.

Monitoring equipment just needs to present PCs in a general format (integer
?) and may leave the interpretation to a tool (using configuration data) or
human analyst. We don't need any configuration data in a protocol message,
do we ?

Best 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: Gradischnig, Klaus [mailto:[email-masked]]
Sent: donderdag 16 augustus 2001 15:52
To: sigtran
Subject: RE: M3UA07: Network Appearance

Tolga,

Klaus

> If interested people say their preference, I think it could 

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

---

---

From: [email-masked]
Date: Thu, 16 Aug 2001 12:32:59 -0400

Gery,

You are wrong. The RC is not used in M3UA for interpretation of point 
codes or SSNs. It is used only to specify for which ASs an ASP is going 
active or inactive, and to specify to which ASs a Notify message from the 
SG relates. It appears only in the the ASPAC, ASPIA, registration and NTFY 
messages.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Verwimp Gery <[email-masked]>
08/16/01 11:23 AM
Please respond to sigtran

Hello everyone,

I guess everyone will agree to the fact that an ASP can register for 
several
RKs (whatever they may be), and can have multiple SCTP associations with 
the
same SG, over which messages for these routing keys can be multiplexed. 
This
is the most general architecture, no restrictions implied.

In this RK negotiation (static or dynamic), the NA is also specified (and
only 1, a reasonable RK limitation). This means RC implies the NA, and 
thus
is more than sufficient information for interpretation of point codes, 
SSNs,
management messages etc. This approach has been taken by SUA, and I don't
see any valid reason why M3UA couldn't go the same way.

The NA's are agreed between SG and AS providers, as part of the 
connectivity
arrangement.

Monitoring equipment just needs to present PCs in a general format 
(integer
?) and may leave the interpretation to a tool (using configuration data) 
or
human analyst. We don't need any configuration data in a protocol message,
do we ?

Best regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Gradischnig, Klaus [mailto:[email-masked]]
Sent: donderdag 16 augustus 2001 15:52
To: sigtran
Subject: RE: M3UA07: Network Appearance

Tolga,

I agree with your choice (I think).
From an MTP network management point of view an STP offers the same 
transfer
capability to all nodes in a particular network. While screening does
violate this principle, only screening based on incoming linkset/DCP can 
be
fully supported by network management. Therefore I see no reason to 
support
the configuration shown below in m3ua -- or rather, one can support it if
5.255.3 is connectd via a separate "linkset" i.e. assocication.

Klaus

---

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 12:23:28 -0500

Barry,

I think you are overreacting: RC is used in ASPTM to distinguish traffic
in M3UA precisely as Gery describes.

--brian

[email-masked] wrote:                (Thu, 16 Aug 2001 12:32:59)
> several RKs (whatever they may be), and can have multiple SCTP
> associations with the same SG, over which messages for these routing
> keys can be multiplexed.  This is the most general architecture, no
> restrictions implied.
> 
> For each RK, a RC (simple integer) is agreed between SG and ASP to
> enable the ASP to distinguish the traffic, for whatever reason
> (interpretation of PC, management messages, SSN, ...). RCs are even
> more precise than NAs in this respect, as they may define a subdomain
> of an SS7 network.
> 
> In this RK negotiation (static or dynamic), the NA is also specified
> (and only 1, a reasonable RK limitation). This means RC implies the
> NA, and thus is more than sufficient information for interpretation of
> point codes, SSNs, management messages etc. This approach has been
> taken by SUA, and I don't see any valid reason why M3UA couldn't go
> the same way.
> 
> connectivity arrangement.
> 
> (integer ?) and may leave the interpretation to a tool (using
> configuration data) or human analyst. We don't need any configuration
> data in a protocol message, do we ?
> 
> Best regards,
> 
> Fax: +32 14 25 3212

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

---

---

From: [email-masked]
Date: Thu, 16 Aug 2001 13:39:30 -0400

Brian,

I am right. The ASPTM messages are ASPAC, ASPIA, etc. As I said, these are 
used only to specify for which ASs an ASP is going active or inactive. There are NOT used to "distinguish traffic".

Barry Nagelberg
Software Engineer
RadiSys, Corp.

"Brian F. G. Bidulock" <[email-masked]>
08/16/01 01:23 PM
Please respond to sigtran

Barry,

--brian

[email-masked] wrote:                (Thu, 16 Aug 2001 
12:32:59)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 13:06:12 -0500

Barry,

RC is used by ASPIA to indicate to the SG for which AS it is
becoming active.  In doing so, the ASP distinguishes to the
SG which routing keys (and thus traffic flows) for which it is
going active.

This is generally understood.

--brian

[email-masked] wrote:                (Thu, 16 Aug 2001 13:39:30)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 17 Aug 2001 10:43:11 +0200

Hi,

This is also my perception. The whole idea of RK/RC is to separate SS7
traffic and define a logical AS, so why can't we use RC to distinguish the
traffic streams at an ASP ???

NA is just part of the RK to help describe an SS7 traffic stream.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 16 augustus 2001 20:06
To: sigtran
Subject: Re: M3UA07: Network Appearance

Barry,

--brian

13:39:30)
> used only to specify for which ASs an ASP is going active or inactive.
There
> are NOT used to "distinguish traffic".
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.

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

---

---