Subject: RE: M3UA08: Network Appearance

From: [email-masked]
Date: Thu, 16 Aug 2001 12:37:50 -0400

Gery,

This is the raison d'etre of the Network Appearance. 

Section 1.2 states: "A Network Appearance implicitly defines the SS7 Point Code(s), Network 
Indicator and MTP3 protocol type/variant/version used within a separate SS7 network."

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Verwimp Gery <[email-masked]>
08/16/01 11:41 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        RE: M3UA08: RC in DATA and SSNM messages

Barry,

Yes, but the physical ASP can register for several RKs at once (be part of
several logical ASes). It needs to distinguish which is which, because 
PCs,
SSNs, ... meaning can depend on it. RC is more precise and the most 
logical
information to (optionally) add to the message instead of NA, which is
magically understood between ASP and SG even in the registration 
procedures.

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 14 augustus 2001 20:24
To: sigtran
Subject: Re: M3UA08: RC in DATA and SSNM messages

Brian,

The ASP does NOT have to "demultiplex traffic for the separate ASs". The 
ASP
_is_ the physical implementation of the logical concept called 
AS.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

"Brian F. G. Bidulock" <[email-masked]>
08/14/01 01:53 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA08: RC in DATA and SSNM messages

Barry,

[email-masked] wrote:                (Tue, 14 Aug 2001 
13:09:09)
> Brian,
> 
> Several of your assertions are incorrect and/or misleading and/or 
> mixed-up. I would like to set the facts straight:
> 
> 1. RC is _not_ required in the DATA message.

Several others prefer it this way as well: I suppose they are
completely mixed up in their implementations as well.
Gee, SUA must be completely mixed up as well...

Please, set us (and SUA) straight, Barry.  Explain to us why
we should not want to demultiplex AS traffic using RC instead
of reapplying the RK(AMF) at the ASP.

> 
> 2. When you say "multiple RC multiplexed over the same association"
> I think that you are referring to a single ASP instantiating multiple 
> logical ASs. This does _not_ require the RC to be in the ASPAC. RC is 
> required in the ASPAC _only_ when the ASP does not wish to go active for 

> all of the ASs for which it is configured.

True.  But when an ASP goes active for all ASs for which it
is configured, it must still demultiplex traffic for the separate
ASs.  It either does that on RC (if provided) or it is forced to
provision and apply the RK(AMF) to each and every message.  That
is undesirable for the interoperability and RK neutrality reasons
already stated.

--brian

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

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

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

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

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

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 11:20:59 -0700

"Those" = "one" is not a good enough excuse to change NA to anything more
than ID.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, August 16, 2001 12:29 PM
> To: sigtran
> Subject: Re: M3UA08: Network Appearance
> 
> 
> Barry,
> 
> NA's raison d'etre is not a fate accompli.  (Pardon my French.)
> 
> There are those on the WG that strongly disagree with NA representing
> more than pure SS7 Network Id, as the administrative nightmare imposed
> by the extension of NA to Network Id/Network Attachment is a fairly
> compelling argument.
> 
> --brian
> 
> [email-masked] wrote:                (Thu, 16 
> Aug 2001 12:37:50)
> >
> > Gery,
> > 
> You are currently subscribed to sigtran as: [email-masked]

---

---

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

John,

You misread what I was saying: I was referring to your (and others')
objection to NA being more than ID on the basis of administrative
concerns.

I was agreeing with you (and you missed it!)

My point was, the current v7/v8 definition which Barry quoted from
the v8 specification is not necessarily a "faite accompli" for
the NA definition and is not it's "raison d'etre".  If anything, NA's
"raison d'etre" for M3UA is simply Network Id.

--brian

John Schantz wrote:                                          (Thu, 16 Aug 2001 11:20:59)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 12:29:05 -0700

Why thank-you.  I'm afraid that my French is limited to selected works ;^)

> Sent: Thursday, August 16, 2001 1:53 PM
> To: sigtran

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 16 Aug 2001 18:11:37 -0700

Hmm, are we headed towards a consensus on this issue?
There seem to be a number of folks supporting using
the definition of Network Appearance from the earlier
drafts, rather than the one in version 8.

Cheers,

Lyndon 
--

On Thu, 16 Aug 2001 12:29:05   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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 22:09:07 -0500

Lyndon,

Anytime that someone is willing to put RC in SNMM and DATA
we can put that NA right back to Network Id.  Without changes
to SNMM and DATA, the v7/8 NA definition must stand to support
the cases already cited.

--brian

Lyndon Ong wrote:                          (Thu, 16 Aug 2001 18:11:37)

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

---