Subject: Common Parameters in SUA & M3UA: DATA

From: [email-masked]
Date: Mon, 1 Oct 2001 09:47:59 +0300

Hi all,

After a small discussion with the authors of M3UA, we agreed that DATA
should not be a common parameter.  In SUA, there is an SUA-specific
DATA parameter.

br,
John

=== discussion ====

> Data 0x0003

[Greg] I don't think we should have a common Data parameter as the contents
differ per adaptation Layer (e.g., MTP3-User Data and SCCP-User data).  I
suggest moving the the SUA assignment to an SUA-specific Tag value and
change to "Not used in SUA".  M3UA Data 1,2,3 already have M3UA-specific
assignment(s) - soon to be one assignment it seems (yeah!)

---
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, 1 Oct 2001 04:06:18 -0500

John,

What makes DATA different than, say, Routing Context?  Also, the UA
message header already distinguishes between the two.

--brian

John Loughney wrote:                               (Mon, 01 Oct 2001 09:47:59)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Mon, 1 Oct 2001 12:10:30 +0300

Hi Brian,

> message header already distinguishes between the two.

As indicated by Greg below, M3UA will move the DATA parameter to the M3UA
specific range.  He was suggesting SUA do the same.  Do you feel this is
a bad idea?  If so, let Greg know.

John

> > To unsubscribe send a blank email to 
> [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: Verwimp Gery <[email-masked]>
Date: Mon, 1 Oct 2001 12:17:55 +0200

Hi John, Greg,

It has to be considered that both protocols overlap a great deal :
- same ASPSM/TM procedures (Up, Active, Inactive, Down, ...)
- same REG procedures
- same SSNM procedures (DUNA, DAVA, DRST, SCON, ...)
 
The only thing that really differs is the content of the DATA messages. But
both layers try to add functionality that is missing in the SCTP/IP stack :
- loadsharing among routes (NOT supported by SCTP multihoming !)
- loadsharing among end/relay nodes (relay esp. in SUA)
- immediate rerouting in case of association/node failures
- the management procedures to make this possible
- SUA with the additional advantage to let the application make use of any
address format (IPaddress, hostname).
 
In my view, we should consider effort to end up with a single UA, which
either :
 
(1) only supports the M3UA interface peer-to-peer, and to it's users
(2) supports both M3UA and SUA DATA interface peer-to-peer, and either
MTP3/SCCP interface to it's users depending on their needs (local decision).
 
What is required peer-to-peer between the UA's is a change in REG procedures
only, so it can be established per RK/RC what data interface is being used
(M3UA or SUA).
 
In this way, people with a UA only doing (1) can interwork with a UA doing
(2). At (2), it is almost trivial to filter out the SCCP for CL traffic; for
CO traffic, the state/event machines must be supported there anyway.
 
So we can have interworking in any scenario :
 
(1) RANAP or MAP or INAP / SCCP / UA1 / SCTP / IP <-> IP / SCTP / UA2 /
RANAP or MAP or INAP
 
UA2 has an agreement with UA1 (via REG) to use the M3UA DATA interface (no
other option). Locally, it can still provide the SCCP interface to it's
users ! Management procedures are the same in both UA1 and UA2.
 
(2) RANAP or MAP or INAP / UA1 / SCTP / IP <-> IP / SCTP / UA2 / RANAP or
MAP or INAP
 
Both UA's agree to use the SUA interface (CO and CL messages).

Any ideas about that ?

____________________________

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: maandag 1 oktober 2001 8:48
To: sigtran
Subject: Common Parameters in SUA & M3UA: DATA

Hi all,

br,
John

=== discussion ====

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 1 Oct 2001 10:07:51 -0400

Hi John, Brian

M3UA Data 1 and 2 was already in the M3UA-specific range in Issue 8 as its
payload content is different from SUA - I only noticed in discussion with
John L that the SUA Data parameter was in the common UA assignment range.
(M2UA Data parameter Tags are also on the M2UA-specific range.)  So if SUA
moves its assignment to be consistent, then the Tags will be completely
self-identifying.   It is true that you could have a common Data parameter
and use the message header to tell SUA and M3UA Data parameters apart but we
felt this was cleaner.   RC is different in my eyes as it is identical
foramt and content between the UAs (32-bit integer).

Maybe there is an  opportunity to make a common Data though - we can think
about that.

 Cheers,

   Greg

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, October 01, 2001 5:10 AM
Subject: RE: Common Parameters in SUA & M3UA: DATA

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

---

---

From: [email-masked]
Date: Tue, 2 Oct 2001 10:50:20 +0300

Hi Greg,

> foramt and content between the UAs (32-bit integer).

I've moved the (SUA) Data parameter to the SUA parameter list.
Unless someone tells me a good reason, I don't see a reason
to move it back to a common parameter.

John

---

---

From: [email-masked]
Date: Tue, 2 Oct 2001 16:17:32 +0300

Gery,

I fear that this proposal would only delay both M3UA and SUA.  I 
agree that such a proposal is a good idea - but I think it is
quite implementation related (a clever implementation could
do much of this, while supplying two different APIs - one for
SCCP-users and one for MTP3-users).

I think that since both M3UA & SUA have both already completed
WG last call, such a major revision to both protocols (not to
mention the SIGTRAN charter) would be problematic.  I think
that both protocols should be moved to IESG last call upon
revision (any outstanding issues could be addressed at that
point).  

After we get some deployment experience with these protocols, 
we could always review some of this when moving from Proposed
Standard to Draft Standard.

best regards,
John

---