Subject: Re: M3UA08: RC in DATA and SSNM messages

From: [email-masked]
Date: Tue, 14 Aug 2001 12:49:16 -0400

Brian,

I disagree with your assertion that the RC is needed in the DATA and SSNM 
messages.

1. Your concept of "the ASP forwarding the DATA message to the AS" makes 
no sense. The ASP _is_ the instantiation of the logical element called AS, 
as defined in section 1.2. Thus this cannot be a justification for adding 
the RC to the DATA message.

2.  The SSNM messages are merely mappings of the MTP-PAUSE, MTP-RESUME and MTP-STATUS Indication Primitives. These primitives are presented to the MTP3 user with nothing more than 
the affected point code parameters, which is exactly what is present today 
(m3ua v8) in the SSNM messages. Thus no other parameters are needed in the 
SSNM messages.

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 11:54 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA07: Network Appearance

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,
> 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
> 
> 
> >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)
> >>
> >>
> >> NI+DPC+OPC are all the MTP information,
> >> why do we need RC in SSNM and DATA???
> >>

---
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, 14 Aug 2001 12:01:53 -0500

Barry,

[email-masked] wrote:                (Tue, 14 Aug 2001 12:49:16)
> the RC to the DATA message.

The ASP is an SCTP endpoint: not a process or thread of execution, nor
an interface to a MTP-User.  The AS is the interface to the MTP-User.

> (m3ua v8) in the SSNM messages. Thus no other parameters are needed in the 

Yes, they must also identify the specific MTP/MTP-User interface instance
as identified by RK/RC/AS.

--brian

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

---

---

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

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.

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.

Barry Nagelberg

08/14/01 12:01 PM

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,
> 
> 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,
MP,
the
> > >You are currently subscribed to sigtran as: [email-masked]
> > >To unsubscribe send a blank email to
> >[email-masked]
> >
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to 
[email-masked] 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
[email-masked]

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

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

---

---

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

Folks,

I am reading generally a lot more opposition to adding the RC to
the DATA and SSNM messages than support.  I would like to put
this issue to rest.

For this next version, let's omit the RC.  If we later find
in testing that it is necessary, we can add it as an optional
parameter without much difficulty.

BTW, I also find it confusing to say an ASP "forwards" data
to an AS, my understanding is that the AS is a logical 
entity consisting of component ASPs.

Cheers,

L. Ong 
--

On Tue, 14 Aug 2001 12:49:16   Barry.Nagelberg wrote:
>> 7"<~HK: Brian F. G. Bidulock <[email-masked]>
>> JU<~HK: sigtran <[email-masked]>
>> HUFZ: 2001Dj8TB14HU 15:22
>> VwLb: Re: M3UA07: Network Appearance
>> 
>> 
>> >Ming,
>> >
>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: Tue, 14 Aug 2001 12:53:29 -0500

Barry,

[email-masked] wrote:                (Tue, 14 Aug 2001 13:09:09)
> 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 

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/

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 14:01:44 -0400

Brian,

You are using terminology which does NOT exist in m3ua v8, and denying the 
terminology that DOES exist. By deliberately spreading disinformation, you 
are spreading confusion and wasting a lot of time for a lot of people. 
PLEASE STOP.

1. The AS is not, and cannot be, a concrete object, and thus cannot be "the interface to the MTP-User".
It is defined in section 1.2 as a "logical entity". It is akin to a class definition in C++, for which one or more ASPs are 
the instantiated objects.

2. The ASP is most certainly a process. It is defined in section 1.2 as "Application Server Process (ASP) - A process instance of an Application Server." The _ASP_ is "the interface to the MTP-User", as well as being an SCTP endpoint.

3. The SSNM messages DO NOT have to identify an AS. They must merely 
identify affected point codes as they do now.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/14/01 01:01 PM

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

Barry,

[email-masked] wrote:                (Tue, 14 Aug 2001 
12:49:16)

> 
> 2.  The SSNM messages are merely mappings of the MTP-PAUSE, MTP-RESUME 
and MTP-STATUS Indication Primitives. These primitives are presented to 
the MTP3 user with nothing more than 

--brian

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

---

---

---

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

Lyndon,

Why not include it as an optional parameter now and
let those who don't want to use it not use it?  Then 
nothing has to be added later and if it falls out of
use, then the normal IETF procedures will make sure
that the "cruft" gets removed.  This approach has been
taken to other paraemters in the drafts to which objections
have been raised.  Why not for RC?

Also, the use of RC is not only detailed, but quite
mandatory in similar cases in SUA.  There is no reason
why M3UA should not permit as optional an approach
which is required in SUA.

BTW, the AS represents the MTP-User.  As such, for the
ASP to place the primitives to the MTP-User in context,
it must be placed into the context of the specific MTP-User
interface.  The MTP-User interface into which the primitives
must be placed in context is identified by one of RK or RC.
To determine this context requires re-application of RK or
addition of RC.  Not even permitting RC as an optional
parameter on DATA and SNMM forces the reapplication of RK
to perform this demultiplexing.  RK maintenance is not
required in any other UA, and should not be forced on
M3UA implementation either.  If those with objections to
RC wish to reapply RK at the ASP, let them ignore the
parameter and reapply the RK if they wish.

This is not a minor implementation issue.

--brian

Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 10:49:06)

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

---

---

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

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.

08/14/01 01:53 PM

Barry,

13:09:09)

--brian

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

---

---

---

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

Barry,

[email-masked] wrote:                (Tue, 14 Aug 2001 14:01:44)
[snip]
> 
> 1. The AS is not, and cannot be, a concrete object, and thus cannot be "the
> interface to the MTP-User".  It is defined in section 1.2 as a "logical
> entity". It is akin to a class definition in C++, for which one or more ASPs
> are the instantiated objects.

If your implementation make an AS an instance of a object, then your
ASP must select the appropriate instance to process any given message.
That is the demultiplexing operation which the ASP must perform.

Perhaps you cannot understand this because you view the ASP as a user-level
process.  In my (and other) implementations, the ASP is a kernel-level
process: the AS are the upper layer processes to which the ASP provides
service.  This is perfectly in fitting with both the SIGTRAN and the M3UA
protocol architectures, where the ASP presents the MTP/MTP-User interface
for an AS.

> 
> 2. The ASP is most certainly a process. It is defined in section 1.2 as
> "Application Server Process (ASP) - A process instance of an Application
> Server." The _ASP_ is "the interface to the MTP-User", as well as being an
> SCTP endpoint.

In the case of multiple AS, the ASP is "the interfaces to the MTP-Users".
The ASP must select which interface (which MTP-User) to which each
primitive applies (including MTP-TRANSFER).  The only mechanism available
to perform this is the RK/RC for multilple AS.  The RK or RC is the
AS identifier (or MTP-SAP) if you will.  Either the ASP has RC available
for this selection (demultiplexing) or it must reapply the RK.

> identify affected point codes as they do now.

SSNM messages need to be turned into MTP-PAUSE/RESUME/STATUS primitives
when presented to the AS (MTP-User).  To present the SNMM message, the
AS (MTP-User) must be identified and demultiplexing is required precisely
as in the DATA case.  To present the same indication to multiple MTP-Users
will require providing the primitive multiply to the list of ASs (MTP-Users)
involved.  This can either be accomplished via an RC list the SNMM messages,
or the ASP will be required to apply the RK to the CPC (or somehow to the NA
as it stands) of the SNMM message to determine to which MTP-Users (ASs) to
indicate the MTP-PAUSE/RESUME/STATUS primitive.

--brian

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

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 14:34:25 -0400

Brian,

The absence of RC does not "force the reapplication of RK to perform this demultiplexing". There is no demultiplexing to be done. 

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/14/01 02:08 PM

Lyndon,

--brian

Lyndon Ong wrote:                                          (Tue, 14 Aug 
2001 10:49:06)

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

---

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 14:45:43 -0400

Brian,

It seems pretty obvious that you are trying to pervert the spec to make it 
fit the particular case of an implementation path that you decided upon a 
while back, and are now having trouble implementing within the existing 
confines of the spec.

Your decision to put the ASP in the kernel is fine. We may do the same. 
However your implementation of the AS as an upper level process is a 
mistake. The AS is a logical concept that was never designed to be 
implemented as a real process.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/14/01 02:29 PM

Barry,

14:01:44)
[snip]

Perhaps you cannot understand this because you view the ASP as a 
user-level

SSNM messages need to be turned into MTP-PAUSE/RESUME/STATUS primitives
when presented to the AS (MTP-User).  To present the SNMM message, the
AS (MTP-User) must be identified and demultiplexing is required precisely
as in the DATA case.  To present the same indication to multiple MTP-Users
will require providing the primitive multiply to the list of ASs 
(MTP-Users)
involved.  This can either be accomplished via an RC list the SNMM 
messages,
or the ASP will be required to apply the RK to the CPC (or somehow to the 
NA
as it stands) of the SNMM message to determine to which MTP-Users (ASs) to
indicate the MTP-PAUSE/RESUME/STATUS primitive.

--brian

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

---

---

---

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

Barry,

We are talking the non-trivial multiple AS per ASP case here...

--brian

[email-masked] wrote:                (Tue, 14 Aug 2001 14:24:01)
> 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.
> 

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

---

---

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

Barry,

I'm sorry, but all my ASs are not implemented in the same
executional thread.  To require that would be to change
the existing MTP/MTP-User interface where each MTP-User
interface to MTP is independent and can (and usually is)
implemented in different process threads.

There is plenty of demultiplexing to perform.  Perhaps not
in your implementation, but perhaps you don't care to present
the existing MTP/MTP-User interface to your applications.

--brian

[email-masked] wrote:                (Tue, 14 Aug 2001 14:34:25)
> Brian,
> 
> The absence of RC does not "force the reapplication of RK to perform this
> demultiplexing". There is no demultiplexing to be done. 
> 

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

---

---

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

Barry,

The implementation path that I have decided upon is the implementation
path which is supposed to be guaranteed by the spec: that the MTP-User
can be implemented in such a fashion that it cannot distinguish whether
M3UA sits between it and an MTP-Provider.  As it stands, the ASP
implementations needs to implement MTP variant specific information
to accomplish this in clear layer violation of the SIGTRAN architecture.

The implementation of the AS as an upper-level process (i.e. MTP-User)
is precisely what both the SIGTRAN architecture and M3UA explicitly
claim to guarantee.

--brian

[email-masked] wrote:                (Tue, 14 Aug 2001 14:45:43)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Aug 2001 18:32:30 -0500

Barry,

Still there can be a multiplexing needed if the ASP is serving for more than
one AS, whose route keys have different DPCs, but this can be done based on
the DPC field in the MTP3 message.
But regardless how incoming traffic is handled by ASP, still for outgoing
traffic RK provisioning and selection among SGs is necessary. It is possible
that ASP has connections to multiple SGs, and is active for different ASs on
different SGs. In such a case traffic coming from user application should be
analysed to select the correct SG. 

     Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 2:34 PM
To: sigtran
Subject: Re: M3UA08: RC in DATA and SSNM messages

Brian,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Lyndon,

--brian

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

---

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 16 Aug 2001 17:41:59 +0200

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.

Barry,

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

---