Subject: Re: Network Appearance.

From: Joyce Archibald <[email-masked]>
Date: Mon, 02 Apr 2001 09:01:46 +0100

Hi Norm,

As I understand it in SUA, the purpose of Network Appearance is to
define "... the SS7 Point Code format used, the SS7 Network Indicator
value and the SCCP protocol type/variant/version used within the SS7
network partion". I don't see how this can be defined as "a single point
code in any given network". While it is possible that each point code in
a network may use a different format and thus require a different
Network Appearance, it doesn't seem very likely.

If you are saying that it is possible for a network management message
to contain point codes with different formats, then having one Network
Appearance parameter in the message is not going to work, however you
define it. If that is the case please see the thread "M3UA and SUA:
Point Code formats" beginning on 8th March.

Regards,
Joyce

Normand Glaude wrote:
> Folks, I circulated a message on the list in January about the
> definition of the Network Appearance. This was discussed in Minneapolis,
> and I thought I'd produce a bit more info, so that we all agreed on
> basic definitions.
> 
> There are 2 definitions circulating in the drafts today for Network
> Appearance
> 
> 1) In M3UA, it means the appearance OF a network. Essentially, all point
> codes in the same network belong network appearance.
> 
> 2) In SUA, it means the appearance IN a network. Essentially, a single
> point code in any given network is a network appearance, in a one-to-one
> relationship.
> 
> There are issues with (1), in that all network management messages
> (DUNA, DAVA, etc.) use the network appearance as the context, and that
> creates ambiguities in cases where multiple point codes are represented
> by a single signaling gateway in a network.
> 
> There are duplication issues with (2), as a single event in the SS7
> network may generate multiple events on the M3UA side.
> 
> I propose we use definition (2), since duplication is less of an issue
> than ambiguity.
> 
> The following is what I circulated in January, and it covers the same
> issue for different reasons, and the SUA definition has changed since.
> 
> Greg/John, I'll produce some text for the drafts to clearly indicate
> this, unless this becomes a hot debate on the mailing list, like it did
> the last time :-)
> 
> Norm.
> 

-- 
==================================================================
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]
==================================================================

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

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Mon, 2 Apr 2001 10:42:02 -0500

Norm:
 
I must say I never liked the term "network appearance". For me -- at least
in m3ua -- it always corresponded to a "network identity", i.e. it was an
acknowledgement that the 2-bit NI was too limited and that an SS7 network
element could indeed be connected to more than 4 MTP networks or more than
one MTP network using the same NI. And while in the SS7 world one could
(more or less) tie this network identity to a physical link(set) this was
not possible when dealing with SCTP assocs having the ability to serve
multiple ASes. Thus something like "network appearance" was needed. (And
certainly, when used in m3ua, it would not necessarily imply the version on
an upper layer protocol like SCCP or ISUP.)
I am not sure I understand the ambiguity problem you listed below for the
m3ua meaning of network appearance. If the multiple pointcodes represented
by the SG belong to the same network, network status like (userpart)
reachability/congestion/restriction applies to all of them, as they all have
the same network connectivity, or what am I missing? If not, they would have
different appearances anyway. As, however, appearance is a purely bilateral
issue, nothing prevents an SG to assign different ones to point codes in the
same network, despite the general definition given in m3ua. But I do not see
a reason to require that each pointcode has its own appearance.
 
BTW, I cannot see the restriction you made in Jan. that a signaling end
point can only have one signaling point code (presumably you meant within
one MTP network). I cannot see any technical/protocol problems and there is
certainly a need for SEPs supporting multiple point codes (think about
switch consolidation). Also I seem to recall that some Bellcore/Telcordia
requirement asks for it.

Klaus

-----Original Message-----
From: Normand Glaude [mailto:[email-masked]]
Sent: Friday, March 30, 2001 6:24 PM
To: [email-masked]
Subject: Network Appearance.

Folks, I circulated a message on the list in January about the definition of
the Network Appearance. This was discussed in Minneapolis, and I thought I'd
produce a bit more info, so that we all agreed on basic definitions. 

2) In SUA, it means the appearance IN a network. Essentially, a single point
code in any given network is a network appearance, in a one-to-one
relationship. 

There are issues with (1), in that all network management messages (DUNA,
DAVA, etc.) use the network appearance as the context, and that creates
ambiguities in cases where multiple point codes are represented by a single
signaling gateway in a network. 

There are duplication issues with (2), as a single event in the SS7 network
may generate multiple events on the M3UA side. 

I propose we use definition (2), since duplication is less of an issue than
ambiguity. 

The following is what I circulated in January, and it covers the same issue
for different reasons, and the SUA definition has changed since. 

Greg/John, I'll produce some text for the drafts to clearly indicate this,
unless this becomes a hot debate on the mailing list, like it did the last
time :-) 

Norm. 

--------------------- 

Background -

In the various SS7 SCCP specifications, it is assumed that MTP is
aware of the local point code of its users, i.e. SCCP.  In an
end-node configuration, there is only one point code, therefore
the local point code is implicit. In an STP configuration, there
could be many point codes, but traditionally, there is an
SCCP user only for the alias point code which is used for the
Global Title Translation function. Also, in the proposed sigtran scheme, it
is also possible for a SG to have multiple End-node point codes in the same
network

Issue -

In SUA, although there is support for STP-like configuration, where
multiple point codes within the same SS7 network are hosted, there
is no way to distinguish which SCCP-user, or more importantly, to
which network element (point code within a network) when an ASP sends
a message to a SG. Essentially it is not possible to properly support
STP configurations at the SG in the current SUA draft.

Proposed solutions:

1) Change the definition of Network Appearance, and make the parameter
optional for all messages:

In the current definition, for a single SCTP association, the network
appearance is the set of all point codes within the same network,
"hosted" or "represented" by the same signaling gateway.

If the definition was changed so that a network appearance was
constricted to a single point code, or network element, and the 
parameter was made optional for all messages, then the conditions 
would be satisfied.  In fact, such a concept already exists in M3UA 
and SUA, as it is implied in the definition of the Signalling Point 
Management Cluster (SPMC).

A definition could go something like this:

   Network Appearance - The Network Appearance identifies an SS7
   signaling node (a unique point code in a single SS7 network) for
   the purpose of logically separating the signaling traffic between
   the SG and the ASP over a common SCTP Association.  This partitioning
   is necessary where an SG is logically partitioned to appear as an
   end-node elements in multiple separate national SS7 networks, in
   which case there is a separate network appearance for each SS7 network.
   It is also necessary when an SG is configured as an STP and hosts
   multiple point codes within the same network, in which case each point
   code is a separate network appearance.

One I need to clear in my mind is what does "Network Appearance" really
means - is it:
  (a) the appearance **OF** an SS7 network to an element or
  (b) the appearance of an element **IN** an SS7 network?

In any case, I think that the definition of network appearance needs
clarification.

2) Introduce the MTP routing label in some of the SUA messages.

That method is a bit less appealing to the SS7 purists, since in changes
the nature of the SCCP-user primitives, by forcing the SCCP user to know
about MTP-L3 information. - But - it has been done before, and in some
ways, it is simpler to add.

3) Remove STP configurations altogether.

A bit more drastic. I don't endorse this one myself, but I'm trying to
be more complete with the alternatives.

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

---

---

From: Normand Glaude <[email-masked]>
Date: Mon, 02 Apr 2001 14:46:10 -0400

Joyce,

Yes, you are correct in saying that the purpose of the Network Appearance is to
define the format and network indicator and protocol variant used within the SS7
network partition. However, in light of the later definitions, the concept of
"network partitioning" comes into play. So the question is: What is a Network
Partition?

This is what I'm trying to address.  More specifically, in the event that an
SG represents two end nodes in the same network, how can an ASP distinguish  which
end-node a DUNA pertains to? By defining a network appearance as the appearance of a
node in a network, this ambiguity is no longer there.

Greg/John, how about this as a definition?

Network Appearance - The Network Appearance uniquely identifies an SS7 entity (point
code) into a SS7 network, as presented by the SG.  It is used for the purposes of
logically separating the signaling 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 an 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 configured as an STP
hosting multiple point codes, or when configured as multiple endnodes within the
same network, in which case each point code is a separate network appearance.

Norm
--

Joyce Archibald wrote:

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

--
Normand Glaude, Chief Engineer, Signaling Systems Group
Performance Technologies Canada, Inc.
E-Mail: [email-masked]
Tel: +1 (613) 237 4344       Fax: +1 (613) 237 4456

---