Subject: SUAv7 : General Comments

From: [email-masked]
Date: Fri, 17 Aug 2001 15:29:51 +0530

Hi ,

Please see some comments on SUAv7.

1. Section 1.3.2 Protocol Architecture for Connection-Oriented Transport
Further messages for this connection are routed on DPC in the SS7 connection
section (MTP routing label), and on IP address in the IP connection section
(SCTP header).  No other routing information is present in the SCCP or SUA
messages themselves. Resources are kept within the SG to forward messages from
one section to another and to populate the MTP routing label or SCTP header,
based on the destination local reference of these messages (Connect Confirm,
Data Transfer, ...)

Above text makes a analogy of MTP routing label in SS7 Network , with SCTP
header in IP network, this is confusing and incorrect.
As Coupling of connection sections present in SCCP and SUA is done in NIF, this
coupling should be done based on connection Identification parameter and not on
destination reference numbers.

2.  Section 4.1 SCCP 

û SUA Interworking at the SG
If a SGP is operated in mated pair configuration, and it receives a non-first
XUDT segment for which no reassembly process exists, it should pass on this
segment to it's mate; if the segment was already received from the mated SGP or
if no mated SGP is available, the return on error procedures is invoked.

At SG , any message from SS7 network first reaches SCCP via MTP3. As per SCCP
specifications (section 4.1.1.2.2 of Q.714 and T1.112.4 ), if SCCP receives a
non  first XUDT segment for which no reassembly process exists , SCCP should
discard message.  It is not very clear to me that If SCCP discards the message
how can that message be passed to mated pair ?

3. Routing context parameter is not needed in CODT , CODA , RELRE  , RELCO ,
RESRE, RESCO, COERR, COIT messages. Destination Reference Number alone should be
enough to relate them to concerned connection section.

4. 1.3.1.1 SG as endpoint
However, when TCAP messages are transported, load sharing is only possible for
the first message in a TCAP dialogue (TC_Begin, TC_Query, TC_Unidirectional).
All other TCAP messages in the same dialogue are sent to the same ASP that was s
elected for the first message

Sample loadsharing described above will be very expensive( involving heavy
processing) and should not be recommended by draft. Will it not be enough to do
load sharing based on sequence control parameter ?

Best Regards,
-Sandeep

---
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: Fri, 17 Aug 2001 10:57:04 -0500

Sandeep,

Please see comments below....

[email-masked] wrote:                            (Fri, 17 Aug 2001 15:29:51)
> header in IP network, this is confusing and incorrect.

(This is Issue 17: IPSP cases.)

> destination reference numbers.

Although I disagree with your statement as well, it is clear that the SG
does not populate the MTP header based on DLR.  I propose that the "based
on the destination local reference of these messages ..." phrase be struck.

> how can that message be passed to mated pair ?

(This is Issue 15: Segmentation/Reassembly/Sequencing.)

> enough to relate them to concerned connection section.

RC is needed in these messages for decoupled operation (where DRN only
identifies the connection section at the remote point code or relay point).
Also, even in the coupled case, RC identifies traffic by Routing Key and AS,
for demultiplexing between multiple AS at the ASP.

RC is included in all messages for the same reason.  The purpose of including
RC is not to identify connection sections: that is the purpose of DLR.

Please do not remove RC from these messages.

> load sharing based on sequence control parameter ?

The loadsharing described does not involve any heavier processing than is
already performed by TCAP today.  Also, the condition stated can be ensured by
load-sharing on transaction id when the ASs assign transaction id on a
partitioned basis.  Subsequent messages from the TC-BEGIN TC-QWP/QWOP then
identify the appropriate load share selection by TID.

If the processing looks that heavy to you, I would suggest that you implement
it another way.  This is clearly an implementation issue which is outside of
the scope of the document.

If TCAP is restricted from being handled by SUA in this and related maneers,
it will force TUA to be placed back on the aggenda.

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 13:32:27 +0530

Brian ,

Please see my comments below  ..

"Brian F. G. Bidulock" <[email-masked]> on 08/17/2001 10:27:04 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  Re: SUAv7 : General Comments

Sandeep,

[email-masked] wrote:                            (Fri, 17 Aug 2001
15:29:51)

(This is Issue 17: IPSP cases.)
Sandeep >> I am only asking for some editorial changes here.

> destination reference numbers.

Although I disagree with your statement as well,
Sandeep >> Please explain Why so ?

it is clear that the SG

(This is Issue 15: Segmentation/Reassembly/Sequencing.)
Sandeep >> Would appreciate a response on this..

Sandeep >> IMO coupled/decoupled seperation is valid till connection setup
phase. SCCP CO Data message can either a relay Node (where coupling was done) or
destination Node, does that change in SUA.

Sandeep >> Demultiplexing between multiple AS should be done while processing
CORE (i.e connection setup phase) and not while processing CODT (i.e. Data
transfer phase )

Sandeep >> This means SUA will have to parse SUA data parameter to extract
various TCAP header fields; and take routing decision on these values (This
parsing would take major processing). This requires SUA be aware of that a) TCAP
header format b) Message being transferred in TCAP message. Point b) means this
type of routing can not be applied for case where GT is not yet resolved. Also
consider that where TCAP segmentation is done , SUA user data may not have TID
and message type parameters. How to do route these messages ??

--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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 08:02:04 -0500

Sandeep,

Please see comments below...

[email-masked] wrote:                            (Mon, 20 Aug 2001 13:32:27)
[snip]
> > 
> > > As Coupling of connection sections present in SCCP and SUA is done in NIF,
> > > this coupling should be done based on connection Identification parameter
> > > and not on destination reference numbers.
> > 

Coupling may also be performed in SCCP and not done in NIF.

[snip]
> CORE (i.e connection setup phase) and not while processing CODT (i.e. Data

I completely disagree.  If DLR is used for demultiplexing at the ASP, the ASP
SUA will have to incorporate portions of the SCCP state machine (for dealing
with invalid or missing DLRs).  Demultiplexing by RC only requires ASP SUA
ASPTM state machines (Error - Invalid Routing Context).  I would rather not be
forced to recreate SCCP state machines on the ASP side to the greatest extent
possible.

> > RC is included in all messages for the same reason.  The purpose of
> > including RC is not to identify connection sections: that is the purpose
> > of DLR.
> > 
> > > 4. 1.3.1.1 SG as endpoint However, when TCAP messages are transported,
> > > load sharing is only possible for the first message in a TCAP dialogue
> > > (TC_Begin, TC_Query, TC_Unidirectional).  All other TCAP messages in the
> > > same dialogue are sent to the same ASP that was selected for the first
> > > message
> > >
> > > Sample loadsharing described above will be very expensive( involving
> > > heavy processing) and should not be recommended by draft. Will it not be
> > > enough to do load sharing based on sequence control parameter ?
> > 
> > already performed by TCAP today.  Also, the condition stated can be
> > ensured by load-sharing on transaction id when the ASs assign transaction
> > id on a partitioned basis.  Subsequent messages from the TC-BEGIN
> > TC-QWP/QWOP then identify the appropriate load share selection by TID.
> > 
> parsing would take major processing).

This statement is an overexaggeration, Sandeep, pulling out transaction ids
out of the TCAP payload of SCCP messages takes about 10 lines of C code on
a lazy day.

> This requires SUA be aware of that a) TCAP header format

Two possible formats: ITU application TCAP and ANSI private TCAP.  The same
two that SCCP has.  Big deal.

> b) Message being transferred in TCAP message.

This is identified first constructor (byte) into the TCAP message.

> Point b) means this type of routing can not be applied for case where GT is
> not yet resolved.

Why?  I can route to whatever AS I want on whatever basis I want--
particularly for loadsharing.  GT has nothing to do with it.

> Also consider that where TCAP segmentation is done , SUA user data may not
> have TID and message type parameters. How to do route these messages ??

TCAP segmentation is performed at the component level (Invoke and Result in
ANSI, Result only in ITU) not at the transaction level.  All TCAP packages
have transaction ids with the exception of unidirectional and some general
aborts, which don't require any kind of coupling.  Unidirectionals can be
load-shared simply, and you can do pretty much whatever you want with general
aborts that do not identify a transaction: because they do not identify a
transaction, they cannot affect one.

Load-sharing on TID in SUA is no more complex than loadsharing on CIC in M3UA.

> > If the processing looks that heavy to you, I would suggest that you
> > implement it another way.  This is clearly an implementation issue which
> > is outside of the scope of the document.
> > 
> > If TCAP is restricted from being handled by SUA in this and related
> > manners, it will force TUA to be placed back on the aggenda.
> > 

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 19:32:01 +0530

"Brian F. G. Bidulock" <[email-masked]> on 08/20/2001 07:32:04 PM

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001
13:32:27)

Sandeep >> No SCCP state machine at ASP ? Is it your implementation decision of
is this what SUA suggests/recommends,
Please clarify ?  Also if we have a SCCP state machine at SG side , why should
it not exist at ASP?

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 09:49:38 -0500

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001 19:32:01)
[snip]
> is this what SUA suggests/recommends,

It is recommended in SUA in the definition of Routing Context and that it
be used to distinguish traffic flows to AS.

> Please clarify ?  Also if we have a SCCP state machine at SG side , why should

Because it is not necessary.

--brian

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

---

---

From: [email-masked]
Date: Tue, 21 Aug 2001 14:02:36 +0300

Hi Sandeep,

Catching up after a few days on vacation.

Brian has done a good job of answering your questions,

> Sandeep >> Would appreciate a response on this..

I will get to this later today.

John

---

---

From: [email-masked]
Date: Wed, 22 Aug 2001 14:05:30 +0530

Brian,

Please see some comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/20/2001 09:19:38 PM

Sandeep,

19:32:01)
[snip]

Sandeep >>  I don't agree with you , it is not even implicit in the definition
of RC that SUA recommends no SCCP state machine at ASP. SUA at many places like
section 1.4.2 clearly states that SUA shall support all SCCP protocol classes.
It does not say it is not applicable for ASP.

I have doubts if it is possible not to have SCCP state machine at ASP.
* Who will assign sequence numbers to data messages
* Who will generate CODA messages
* Where to implement flow control procedures at ASP
* Who will initiate /reply to inactivity procedures
* If there are multiple users at ASP, which user SUA should give incoming CODT
message to.
* If ASP is connected to multiple SGs , how to choose SG to send message to.
There is no address parameter in N-DATA request primitive.

In my view SUA does not and should not recommend not having a SCCP state machine
at ASP.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 03:55:57 -0500

Sandeep,

[email-masked] wrote:                            (Wed, 22 Aug 2001 14:05:30)
[snip]
> It does not say it is not applicable for ASP.

My point was that RC is used to demultiplex at the ASP because the
definition of RC is that it be used to distinguish traffic flows.
DLR should not be used to distinguish traffic flows.  DLR does not
have to be unique across all ASs: RC does.  That is why RC is in the
messages.  You originally thought that RC as not required in these
messages: it is.
> * Who will assign sequence numbers to data messages

A counter is not what I would consider a state machine.

> * Who will generate CODA messages

The SCCP-User.

> * Where to implement flow control procedures at ASP

Don't: implement them at SG.

> * Who will initiate /reply to inactivity procedures

SG can do this: send BEAT ASP and reply to inactivity test.

> * If there are multiple users at ASP, which user SUA should give incoming CODT

Demux AS by RC and deliver to SCCP-User.

> * If ASP is connected to multiple SGs , how to choose SG to send message to.

That's a different story.  Multiple SG case is not handled well in SUA.

> There is no address parameter in N-DATA request primitive.

It is implicit to the interface to the SCCP-User per NSD.

> In my view SUA does not and should not recommend not having a SCCP state machine

It should not require it either.

--brian

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

---

---

From: [email-masked]
Date: Wed, 22 Aug 2001 15:12:05 +0530

Brian ,

Comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/22/2001 03:25:57 PM

Sandeep,

[email-masked] wrote:                            (Wed, 22 Aug 2001
14:05:30)
[snip]

Sandeep >> I do not see any benefit of making DLR unique within an AS. DLR is a
reference a connection section and it is allocated locally by SUA and it is
enough for it to be unique within a SUA node. I see no benefit of RC in CO data
messages as I do not want to perform routing/AMF functions for CO data messages.
It should be enough to do routing/AMF at connection set up time and use
information related to that connection section for routing all subsequent
messages.

A counter is not what I would consider a state machine.
Sandeep >> What did you mean by state machine  Are you suggesting to have some
subset of SCCP procedures at ASP? What is this subset then ?

> * Who will generate CODA messages
The SCCP-User.
Sandeep >> SCCP user does not and should not generate acknowledgements.

Don't: implement them at SG.
Sandeep >> SUA supports Class 3, these can not be avoided at SG. Implementation
supporting Class 3 will have to implement flow control at SG.

SG can do this: send BEAT ASP and reply to inactivity test.
Sandeep >> I was talking about connection inactivity procedures.

message to.
Demux AS by RC and deliver to SCCP-User.
Sandeep  >> It is not mandatory for AS be a single SCCP user, it can be a set of
users. I have one big AS for one DPC and all SSNs in that DPC represented by
same AS and hence RC. There is no way we can relate information in destination
address to information in RC.

--brian

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 14:54:32 +0200

Hi,

Time to focus some attention to SUA again ...

I took one of the earlier messages on this thread, because inserting answers
gets messy after a while. Let's see if I can answer some of the issues ;)

1. & 3. Section 1.3.2 Protocol architecture for Connection-Oriented
Transport & Routing Context in CO messages.
========
These issues are related. There are 2 approaches :

- using coupling of connection sections at the SG, since only CR/CORE
contain sufficient address information (possibly GT) to route towards an
appropriate ASP or SS7 destination resp. In this case, one doesn't need to
use the RC parameter, but the drawback is it's consumes resources (keeps
state) at the SG which has some consequences already described (SG or
routing failure a.s.o).

What I meant in the text of this section is that the connection resources
(where the data is kept to populate the MTP routing label, stored after
reception of the SCCP CR message) are retrieved using the DRN as key (what
else ?)

Also, I use the term destination reference number (not connection ID, that's
internal interface talk between SCCP/SUA and their users) because that's the
name of the parameter both in SCCP and SUA !

- not using coupling of connection sections. In this case the RC is
mandatory in the SUA-CO messages, otherwise the SG is not capable of
populating the MTP routing label (it doesn't know the intended SS7
destination). The drawback here is that it limits the definition of RK/RC/AS
: it can go no finer than an SS7 point code for protocol classes 2 & 3. The
ASP handling the SCCP/SUA connection can be selected out of the AS by using
the DRN (destination reference number) received in the SCCP DT1 (or other
CO) message.

Furthermore, I don't compare MTP routing label and SCTP header info (sorry
to get you confused), but :

- the ASP keeps RC and/or SG info (yes, the SUA-CO state/event machine) in
order to route the CODT with the correct RC to the correct SG, after
receiving N_DATA_REQ from it's SCCP-user. In an all IP-case, association
IDs/streamIDs towards the next SUA relay or final SUA node may be kept.

- just as it's counterpart in SS7 (SCCP-CO state/event machine) keeps DPC.

2. Segmenting/Reassembly
====
SCCP at the SG is enhanced (we call this "enhancement" the NIF, by lack of a
better term) to detect that the message is intended for the IP-world and SUA
should be invoked. And vice versa.
However, this NIF reassembles incoming XUDTs so SUA can format a single
CLDT, and the NIF segments incoming CLDTs into XUDTs fitting into the SS7
network.
The idea behind it is clear : relieve SUA on the ASPs from tedious CL
segmenting/reassembly issues !
Actually, the NIF contains every functionality not present in strict SS7
SCCP nor in IP SUA, but is required in the SG for seamless inter-working. As
such only a black-box description (going in - coming out) can be given,
what's inside is totally implementation dependent.

Now, the idea behind the procedure below was that if the ASP has routes via
2 SGs (redundancy), in-sequence-delivery of the XUDT segments does not
guarantee that each segment will pass the same SG (required for NIF
reassembly) e.g. due to routing failures. The procedure might be a bit
overkill though, because it assumes :

- SGs know each other as "mated pairs" for this RC => their is an SCTP
association between them,
- their NIFs must be intelligent enough to forward and accept non-first XUDT
segments (as CLDTs)

But I don't have a problem deleting the entire paragraph ...

4. Loadsharing
====
Sandeep, the same kind of loadsharing (and much more complicated things) of
TCAP messages is currently done in multiprocessor SS7 switches at the cost
of a few lines of code and negligable performance cost. However, the Q.715
states that to be absolutely safe, loadsharing should only be applicable to
TC_Uni (of course), TC_Begin (or TC_Query for ANSI). After that, the chosen
system (SS7 or ASP) can return a unique address (e.g. GT) which TCAP HAS TO
use in subsequent messages in order to reach to same system again. In
SUA/AMF terms : the unique address leads to an AS with only 1 ASP in it.

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: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 17:57
To: sigtran
Subject: Re: SUAv7 : General Comments

Sandeep,

> As Coupling of connection sections present in SCCP and SUA is done in NIF,
this

including

already performed by TCAP today.  Also, the condition stated can be ensured
by

implement

--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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 12:08:46 -0500

Sandeep,

Comments below...

[email-masked] wrote:                            (Wed, 22 Aug 2001 15:12:05)
[snip]
> enough for it to be unique within a SUA node.

It is enough for DLR to be unique within a Point Code.  An SUA node can
represent multiple point codes.  Therefore, the DLR is not necessarily
unique across ASs.  RC is unique across ASs.

> I see no benefit of RC in CO data messages as I do not want to perform
> routing/AMF functions for CO data messages.

If your implementation can't use it, ignore it.  My implementation can
use it as it was intended, to demultiplex traffic at the ASP to the AS.
It is only within the AS in my implementation that the DLR is examined
becuase it is only guaranteed unique within an AS (not across as illustrated
above).

> information related to that connection section for routing all subsequent

DLR is not sufficient to identify the connection section.  It is not
guaranteed unique across ASs.  RC is needed to identify the context of
the DLR.

> subset of SCCP procedures at ASP? What is this subset then ?

Because the connection oriented procedures require both the N-Provider
and N-User to have a concept of the interface state, both the SUA and
SCCP-User must maintain the interface state.  A state machine which
is associated purely with the interface state is required for connection
oriented operation at the SUA to SCCP-User interface.  This interface
state machine is not specified in the SCCP standards but is alluded to
in the NSD.  IMO that is part of the interface and is completely
implementation dependent in SUA.  The state machines that SUA can do
without are the SCCP peer-to-peer state machines which are described
in detail in the SCCP standards specifications.

Saying that things which are part of the interface state machine they
have to be at the ASP SUA, I agree with (they are part of the
SCCP/SCCP-User interface).  Saying how to do them I don't (they are
implementation dependent).

Saying that things which are part of the SCCP peer-to-peer state
machines have to be at the ASP for anything but the multiple SG
case, I completely disagree with.  All of these functions can be
performed by the SG in the backhaul case.

> Sandeep >> SCCP user does not and should not generate acknowledgements.

The NPI OSI NSD compliant interface provides for the N_DATACK_REQ primitive
which permits the NS-User to indicate acknowledgement of messages.  The
SCCP/SCCP-User interface is implementation specific.  One implemented
to the NPI would allo the SCCP-User to acknowledge messages.  I'm afraid
that neither you nor the SUA draft can set restrictions on the SUA/SCCP-User
interface either.

> supporting Class 3 will have to implement flow control at SG.

Flow control (push back) to the SCCP-User is implementation dependent
at the SCCP/SCCP-User interface, and so it is at the SUA/SCCP-User
interface.  Handling of Credit is done at the SG in the backhaul case.

> Sandeep >> I was talking about connection inactivity procedures.

So was I.

> address to information in RC.

How multiple connections are handled at the SCCP/SCCP-User interface is
implementation dependent.  NSD gives a model where the connection id is
implicit to the bidirectional queue upon which objects are exchaged with
the NS-User.  Once the AS is determined by RC, the connection can be
identified by DLR within the context of the AS.  It is the interface
implementation's responsibility to determine how to map DLR onto whatever
model it uses for implementation.

If your AS is one big AS, I would suggest that after the message is
delivered by RC to the big AS, that you use DLR to determine which
connection the message corresponds to and deliver it to that connection
identification for the SCCP-User.  If your implementation wants to, it
could use the DLR itself as the connection identification.  This is just
my suggestion.  The draft must not restrict these implementation
decisions at the SCCP/SCCP-User interface.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 13:28:03 -0500

Gery,

I agree with your points here.  However, there is still a separate
Segmentation/Reassembly issue which involves the ASP assigning SLR
numbers for the SG to use in segementation and the ASP being
responsible for CODT segmentation and reassembly.

--brian

Verwimp Gery wrote:                                       (Wed, 22 Aug 2001 14:54:32)
> Fax: +32 14 25 3212
> 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: [email-masked]
Date: Thu, 23 Aug 2001 20:49:48 +0530

Hi ,

To restate the problem is whether CO Data messages should have RC parameters ?
The rational for having RC in these messages seems to be  to avoid having a SCCP
state machine at ASP and use RC parameter for de-multiplexing CO Data messages
to correct User at ASP.  I disagree with this approach . I think SUA does not
and SHOULD not recommend not having a SCCP peer to peer state machine at ASP.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/22/2001 11:38:46 PM

Sandeep,

Comments below...

15:12:05)
[snip]

Sandeep >> Why do you want to make DLR unique within a Point Code ? What benefit
it gives you by making DLR unique within point code against the case when DLR is
unique within a SUA Node ?

The NPI OSI NSD compliant interface provides for the N_DATACK_REQ primitive
which permits the NS-User to indicate acknowledgement of messages.  The
SCCP/SCCP-User interface is implementation specific.  One implemented
to the NPI would allo the SCCP-User to acknowledge messages.  I'm afraid
that neither you nor the SUA draft can set restrictions on the SUA/SCCP-User
interface either.
Sandeep >> We had this discussion before, SCCP only claims to provide subset of
layer 3 services as per X.213 not all. SCCP nevers talks about ACKs being
generated by SCCP Users. You can have your implementation specific SCCP/SCCP
User interface ,but you can force standard SCCP Users to be designed for that.
SO I do not forsee any SCCP/SUA User ever generating ACKs.

Flow control (push back) to the SCCP-User is implementation dependent
at the SCCP/SCCP-User interface, and so it is at the SUA/SCCP-User
interface.  Handling of Credit is done at the SG in the backhaul case.
Sandeep >> Ok, the point is these need to be implemented somewhere in the NODE.

> Sandeep >> I was talking about connection inactivity procedures.
So was I.
Sandeep >> I mean to say CO inactivity procedures uses COIT not BEAT message. It
is not enough for only SG to send COIT message. According to SCCP procedures
there are send and receive inactivity timers. After send inactivity timer
timeout SCCP sends IT message, after receive inactivity timeout SCCP deletes
connection. If there is no state machine at ASP and COIT message is not sent
after send inactivity timer , connection at SG will be closed.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 23 Aug 2001 17:38:16 -0500

Gery,

I agree with your statements.  The only issue is changing
the text from SUAv7 to reflect that:  SUAv7 currently
places segmentation/reassembly responsibility for CO and
SLR in LUDTS on the SGP.

--brian

Verwimp Gery wrote:                                       (Thu, 23 Aug 2001 14:13:04)
>
> Brian,
> 
> CODT can be viewed as "streaming data", in the sense that there is no limit
> to the number of DT segments. So the ASP must at least support reassembly.
> 
> It is also recommended to perform segmenting at the ASP (i.e. limit the user
> data to 255 bytes max) to assure a CODT will fit into a DT1/2 (for ED even
> 128 bytes). Otherwise the SG will have issues segmenting CODTs, especially
> with protocol class 3 where the segments are numbered (DT2) or no segmenting
> exists (ED). I guess a small price to pay to avoid a lot of interworking
> issues.
> 
> Assigning SLR at the ASP is also recommended, to anticipate segmentation at
> the SG. The same is true for SCCP when LUDT messages are used.
> 
> Hope that John L. can find some time to update the CO and CL sections in
> this respect ...
> 

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

---

---

From: [email-masked]
Date: Fri, 24 Aug 2001 09:46:05 +0530

resending ...
---------------------- Forwarded by Sandeep Mahajan/HSS on 08/24/2001 12:06 PM
---------------------------

Sandeep Mahajan
08/23/2001 05:57 PM

To:   [email-masked]
cc:

Subject:  RE: SUAv7 : General Comments  (Document link not converted)

Hi Gery ,

Verwimp Gery <[email-masked]> on 08/22/2001 07:24:32 PM

Subject:  RE: SUAv7 : General Comments

Hi,

Sandeep >> Following is my understanding of connection oriented message
transport case. In case coupling is done in SG. we have one connection section
in SCCP layer and one connection section in SUA layer. Connection section in
SCCP terminates SCCP procedures and connection section in SUA terminates SUA
procedures. Services of both these layers (SUA and SCCP ) should be invoked
using standard interface as listed in section 1.6.1 of SUA. it also means both
SCCP and SUA should not be invoking each others procedures directly.

Follwoing in my view should be sequence of events for connection setup for SS7
originated connection requests

* CR message received at SCCP on SG , SCCP passes N-CONNECTION indication
primitive to NIF.
* NIF invokes N-CONNECT request primitive of SUA, SUA sends CORE message to ASP
and passes connection ID of this connection section to NIF.
* NIF makes a coupling of SCCP and SUA connection sections
* At ASP SUA receives CORE message and passes N-CONNECTION indication primitive
to SCCP/SUA user.
* SCCP/SUA User at ASP invokes N-CONNECTION response primitive , SUA sends COAK
message to SG
* SUA at SG receives COAK message and passes N-CONNECTION confirm primitive to
NIF
* NIF invokes N-CONNECTION response primitive of SCCP, SCCP send CC message to
SEP.
Similar procedures will apply for ASP originated connection setup.

And following should be the sequence of events for CO Data Transfer
* DT1 message is received from SEP, SCCP finds the connection section with the
matching DRN. Determines user is local and passes the N-DATA indication
primitive to NIF.
* NIF finds the related SUA connection section and invokes SUA N-DATA request
primitive.
* SUA sends CODT message to ASP ( gets SCTP association and stream values from
connection info)
* SUA at ASP passes N-DATA indication primitive to SCCP/SUA user.

Connection sections are maintained at all nodes, SCCP at SG, SUA at SG and SUA
at ASP.Also in ny view coupling of connection section should be done in NIF.

Do you agree with above statements and did I miss something very basic? Can
there be some alternate mechanisms ?

Sandeep >> Non Coupling at SG case is not very clear to me. My understanding of
SCCP non coupling operation is.  Say we have three nodes A , B and C. CR message
is received at node B and it decides if the coupling is required or NOT. If
coupling is not required this node relays the CR message to node C but does not
maintain any connection section info. while processing CR message at Node C , CC
message is sent directly to Node A. All data messages for this connection are
exchanged directly between node A and Node C. So in SCCP data message does not
arrive at Node B (where coupling was not done)

Are you saying that in Non Coupled SG case ,
* SCCP procedures does not terminate at SG
* No connection info is maintained at SCCP and SUA at SG. SCCP CO DT message
from SEP still arrives at SCCP on SG. How will SCCP process CO data message for
which it has no connection info ?
* If SCCP procedures only terminates at SUA at ASP and SUA at ASP, assigns
reference number to the connection section. Two different SUAs at two different
ASPs can assign same DRN for two different connection sections , So DRN can't be
used as key for de-multiplexing messages at SG to different ASPs.

Please clarify ??

Sandeep >> I understand that was not the intention , may be text can be
rephrased !

2. Segmenting/Reassembly
====

Sandeep >> What all enhancements in SCCP are being suggested/recommended? Do we
have some sort of list of these enhancements ?

Sandeep >> I will suggest that we delete this paragraph , its bit of a overkill
as you stated !!

4. Loadsharing
====
TC_Uni (of course), TC_Begin (or TC_Query for ANSI).

Sandeep >>  Ok

After that, the chosen system (SS7 or ASP) can return a unique address (e.g. GT)
which TCAP HAS TO use in subsequent messages in order to reach to same system
again. In SUA/AMF terms : the unique address leads to an AS with only 1 ASP in
it.
Sandeep >> Till SCCP/SUA addess is resolved completly it can not be known if the
user data is TCAP or not. So such load sharing may not be used at all nodes.

Best Regards,

-Sandeep

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 00:34:22 -0500

Sandeep,

[email-masked] wrote:                     (Fri, 24 Aug 2001 09:46:05)
[snip]
> * SCCP procedures does not terminate at SG

In the decoupled case SCCP procedures terminate at multiple SGs.

> which it has no connection info ?

The SG that receives the DT message is not necessarily the same SG
which received or generated the CR.  The DLR in the CODT is taken
directly from the DT message and the RC is chosen using the DPC of
the message and an understanding of partitioned SLR selection for
AS.  In this way the SG can determine RC without being involved in
the setup of the connection.  This is a decoupled approach.

> used as key for de-multiplexing messages at SG to different ASPs.

For decoupled operation to work, the SG and ASPs must agree on SLR
assignment rules which permit distinction of AS.  This also depends
on the granularity of the RK and the traffic mode of the AS.  It is
probably true that the decoupled case presents more restrictions on
AS configuration than coupled, but it places less restrictions on
the SS7 network (coupled operation with multiple SGs requires that
final SCCP GTT be performed at the SG, some SS7 network
configurations will not permit this).

> Please clarify ??

The matter is rather moot, RC is required in all CO and CL messages
so that ASPTM procedures can be performed.

[snip]
> have some sort of list of these enhancements ?

What Gery describes for (XL)UDT messages is not an SCCP enhancement.
There is a procedure in SCCP which permits it to segment LUDT
messages into (X)UDT messages.

> Sandeep >> I will suggest that we delete this paragraph , its bit of a overkill

When receiving (X)UDT messages and exising SCCP is not required to
reassemble them into LUDT or larger messages.  Reassembly is a
function of the interface between SCCP and the SCCP-User which is
not specified by SUA (it is the part that sits between the SUA
peer-to-peer protocol and the SCCP-User).

> user data is TCAP or not. So such load sharing may not be used at all nodes.

There is no requirement to support any kind of loadsharing.  The
spec permits an implementation to not even support loadsharing at
all if if wants.

--brian

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

---

---

From: [email-masked]
Date: Sat, 25 Aug 2001 12:00:27 +0530

Brian ,

Thanks for such detailed replies . Please see some comments on Non Coupled SG
case below. I wished some of these details could go in SUA specs or SUA AS. So
the same set of questions are not asked again and again.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/24/2001 12:04:22 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Sandeep Mahajan/HSS)

Sandeep,

[snip]

Sandeep >> SCCP at SEP will be having one end of a connection section (SCCP
state machine), what I mean to ask was where will the other end of this
connection section (SCCP state machine) will be ? Are you saying
a) SCCP at multiple SGs will be having connection section?
b) SCCP at NO SG will be having  connection section ?
c) SCCP at SG that was involved in CR/CC message exchange will be having
connection ?

Sandeep >> In my view to maintain sequencing of CO data messages, SCCP
procedures mandate that all messages of same connection section go through the
same path (same set of intermediate Nodes). If that is the case how can messages
of same connection section reach multiple SGs. Are we considering Link/Route set
failure conditions here ? How will sequencing of messages will be maintained in
case they pass through multiple SGs?

AS configuration than coupled,

Sandeep >> This will require SCCP to be enhanced also.
1. SCCP does not expect CC message at a relay Node where coupling was not
performed. To support Non Coupled SG case if SCCP receives a CC message it
should be ready to relay it; if does not find a local connection section for it.
2. If SCCP gets CO Data message from peer SCCP and it can not find connection
section for incoming DRN it should pass this message to some default user.
3. User of SCCP ( at SG) should be able to request SCCP to send DT1 message,
where User specifies all parameters like DPC, SLS, sequence number etc.

but it places less restrictions on
the SS7 network (coupled operation with multiple SGs requires that
final SCCP GTT be performed at the SG, some SS7 network
configurations will not permit this).

Sandeep >> Can you please explain the same problem is no there in Non Coupled SG
case ?

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 25 Aug 2001 11:44:57 -0500

Sandeep,

[email-masked] wrote:                 (Sat, 25 Aug 2001 12:00:27)
[snip]
> > > Sandeep >> Non Coupling at SG case is not very clear to me. My
> > > understanding of SCCP non coupling operation is.  Say we have
> > > three nodes A , B and C. CR message is received at node B and it
> > > decides if the coupling is required or NOT. If coupling is not
> > > required this node relays the CR message to node C but does not
> > > maintain any connection section info. while processing CR message
> > > at Node C , CC message is sent directly to Node A. All data
> > > messages for this connection are exchanged directly between node A
> > > and Node C. So in SCCP data message does not arrive at Node B
> > > (where coupling was not done)
> > >
> Sandeep >> SCCP at SEP will be having one end of a connection section
> (SCCP state machine), what I mean to ask was where will the other end
> of this connection section (SCCP state machine) will be ? Are you
> saying
> c) SCCP at SG that was involved in CR/CC message exchange will be
> having connection ?

I would say b).  Decoupled means no connection sections at the relay: it
is done by SCCP in the SS7 network as well.

> > > * No connection info is maintained at SCCP and SUA at SG. SCCP CO
> > > DT message from SEP still arrives at SCCP on SG. How will SCCP
> > > process CO data message for which it has no connection info ?
> > 
> procedures mandate that all messages of same connection section go
> through the same path (same set of intermediate Nodes).

This is not true.  When the same SLS value is chosen in MTP, MTP
provides a strong assurance of insequence deliver regardless of
changing paths through the network for that SLS due to failures
and changeovers.  For multiple SG as STP, the path of any connection
section can change between STPs.  If connection sections are coupled
through the STP the connection will fail if paths change.  If there
is no coupling of connection secions at an STP (i.e, only MTP transfer
is used) then changing traffic between STPs will not disrupt
connections.

Sandeep, please read the thread "SUA: Relay Problems".  This was
discussed at some length there and led to some of the text that
you see in SUAv7.

> If that is the case how can messages of same connection section reach
> multiple SGs.  Are we considering Link/Route set failure conditions
> here ? How will sequencing of messages will be maintained in case they
> pass through multiple SGs?
> 

No, actually it requires that the SG perform MTP relay functions.
That is not "enhancing" SCCP.  The draft does not fully address these
situations yet, so SUA needs some "enhancements".  Those things are
already submitted as issues at Last Call.

> 1. SCCP does not expect CC message at a relay Node where coupling was
> not performed. To support Non Coupled SG case if SCCP receives a CC
> message it should be ready to relay it; if does not find a local
> connection section for it.

It will not find a local connection section for it because it is
addressed to a DPC other than the SG's DPC.

> 2. If SCCP gets CO Data message from peer SCCP and it can not find
> connection section for incoming DRN it should pass this message to
> some default user.

Not in my implementation. In my implementation the appropriate ER
message will be returned per the SCCP state machines.

> 3. User of SCCP ( at SG) should be able to request SCCP to send DT1
> message, where User specifies all parameters like DPC, SLS, sequence
> number etc.

This is SUA Issue 19: CODT Message: addition of optional parameters to
CO and CL messages to permit decoupled operation.

> 
> > but it places less restrictions on the SS7 network (coupled
> > operation with multiple SGs requires that final SCCP GTT be
> > performed at the SG, some SS7 network configurations will not permit
> > this).
> 
> Sandeep >> Can you please explain the same problem is no there in Non
> Coupled SG case ?

Because the SG does not need to perform final GTT.

--brian

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 10:28:50 +0530

Brian ,

I tried to summarise my understanding of SG decoupled approach. Please comment
..

In  a decoupled SG operation case SG acts as STP ( i.e. MTP3 relay). In this
approach one end of connection section is present at SCCP layer on SEP node and
other end of connection section is present at SUA layer at ASP node. This
approach has following benefits.
* No connection sections present either at SCCP or at SUA on SG, Resources
needed for keeping connection sections are saved at SG
* In case of coupled approach connection section is present at SG , so if SG
becomes inaccessible because of Path/Route Set failure or in case of failure of
a SG end to end connection between two SCCP/SUA users is broken.  while in
decoupled approach connection between two SCCP Users (one at SEP in SS7 network
and one at ASP in IP network ) remained established as messages can be routed
via different SGs.
* Final GTT need not to be performed at SG.

Are there any other benefits and which of the above is the most motivating
reason for supporting decoupled SG approach ?

Set-up Sequence

Processing of CR message from SEP
Case 1
SEP send SCCP CR message to SG, DPC in routing Label of this message is set to
DPC of the ASP.  MTP3 at SG while processing this message detects that this
message is not for local User . MTP3 somehow passes this message to a
interworking function at SG.  This message is required to be converted to SUA
CORE message and routed to correct ASP based on the destination address
parameter of SCCP CR message.  One option for achieving this can be SUA having a
Upper Layer interface for letting its User pass SCCP CR message. Interworking
function at SG will use this interface to pass CR message to SUA. SUA will use
AMF to determine AS and ASP , will construct and send CORE message and will keep
no connection section info for the same. Can there be other option here ?
Case 2 (Optional)
SEP send SCCP CR message to SG, DPC in routing Label of this message is set to
DPC of the SG. MTP3 passes this message to SCCP layer. Routing Indicator (RI) is
set to Route on GT, SCCP performs GT; result of GT is still RI = Route on GT.
SCCP detects that DPC where next GT is to be performed is accessible via SUA.
SCCP decides not to perform coupling and somehow passes this CR message to a
interworking function at SG.  Same procedures as case 1 apply to send this
message to ASP.

Processing COAK Message from ASP
*  COAK reaches SUA on the SG. This message need to be converted to SCCP CC
message and sent to SCCP at SEP.  One option here can be when SUA receives COAK
message it somehow bypass normal SUA procedures (similar to SCCP procedures,
where it tries to find the connection section for received COAK message ) and
passes this message to a interworking function. How to achieve this ?? This
interworking function  builds CC message and send CC message to SEP. Now how to
determine DPC to send the message to ? Destination address parameter of COAK
message can be used to extract DPC but will it always have next node DPC ?

Processing of SCCP DT1 message from SEP
DPC in this message will be set to DPC of the ASP. MTP3 needs to pass this
message to a interworking function at SG.  This message need to be converted to
SUA CODT message and need to be sent to ASP where CR was sent. One option can be
that SUA had a new Upper Layer Interface to let interworking function passe DT1
message to SUA.  SUA  based on the DRN and DPC of the DT1 message selects AS and
ASP to send the message to.  This approach requires
Restrictions on the definitions of Application Server , it can not be finer than
DPC. Once AS is selected ASP within AS is selected based on the DLR of the
message. This requires each ASP to work with a unique range of reference numbers
and SG is made aware of that using either configuration info or with
registration procedures.

Processing of SUA CODT message from ASP.
SUA at SG receives CODT message from ASP, this message needs to be converted to
SCCP DT1 message and sent to SEP. For achieving this SUA after receiving this
message need to pass this message to interworking function. This interworking
function need to build SCCP DT1 message and pass the same to MTP3 for sending it
to SEP. We require at least DPC of SEP and SLS to be present in the CODT message
to support this. Existing RC parameter in the CODT message can not be used as RC
corresponds to DPC of the ASP.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/25/2001 11:14:57 PM

Sandeep,

[snip]

> message, where User specifies all parameters like DPC, SLS, sequence
-> number etc.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 03:08:42 -0500

Sandeep,

[email-masked] wrote:                     (Tue, 28 Aug 2001 10:28:50)
> 
> 
> 
> Brian ,
> 
> I tried to summarise my understanding of SG decoupled approach. Please
> comment ..
> 
> In  a decoupled SG operation case SG acts as STP ( i.e. MTP3 relay).
> In this approach one end of connection section is present at SCCP
> layer on SEP node and other end of connection section is present at
> SUA layer at ASP node. ...

I don't think it is a good idea to place the end of the connection
section at the ASP.  It would still reside at the SG, but in association
with the ASP's point code rather than the SG's point code.

> This approach has following benefits.

End of connection section should be at the SG but associated with ASP
point code.  This actually does not necessarily save any connection section
resources at the SG.

> a SG end to end connection between two SCCP/SUA users is broken.

This is not really true.  In the case that there are path failures which
causes different paths to be taken to the ASP point code, there will be
no disruption of coupled connections.  Coupled connections terminate a
connection section at the STP's point code (not the ASP's).  It would
take failure of an entire STP or failure of all communication between
the SG and ASP to disrupt connection sections.  Decoupled connection
might survive an entire STP failure, but the probability of a full STP
node failure is normally extremely low, so there is normally little
advantage in this respect between coupled and decoupled.

> while in decoupled approach connection between two SCCP Users (one at
> SEP in SS7 network and one at ASP in IP network ) remained established
> as messages can be routed via different SGs.

The only difference is for full STP failure.

> * Final GTT need not to be performed at SG.

This is correct.  But Final GTT can still be performed at the SG without
coupling also.

> reason for supporting decoupled SG approach ?

The performance requirements for decoupled connections is higher than
that of coupled connections for connection establishment, data transfer
and disconnection phases.  This means that delay and throughput are
higher on decoupled connections than they are on coupled connections.
As each connection section is introduced with coupling, the delay and
throughput QOS deteriorates.  But, again, this is an SCCP advantage,
and I don't believe the draft should discuss the advantages and
disadvantges of SCCP approaches.  The advantages and disadvantages are
in the SCCP specifications for the SCCP implementor to judge.

The reason for permitting the decoupled approach for SUA is so that
SUA can seamlessly interoperate with SCCP.  If SUA does not support
decoupled connections, it will not seamlessly interoperate with SCCP,
and only interoperate in restricted configurations.

> DPC of the ASP.
> MTP3 at SG while processing this message detects that this

Result can also be route on PC/SSN without coupling.  For
connection-oriented SCCP procedures, the result of GTT also determines
whether coupling is required or not for any relayed CR.  You are missing
quite a few cases above.

> message can be used to extract DPC but will it always have next node DPC ?

SCCP N-CONNECT response primitive includes "connection identification"
parameter.  This is the "SLR" or "DLR" in CORE and COAK.  There is no
problem with SG running SCCP state machine and providing primitive
interface to ASP.

> and SG is made aware of that using either configuration info or with

No, SG uses DLR and DPC to determine the correct "connection
identification" and route it to the appropriate ASP under the
appropriate Routing Context.

> corresponds to DPC of the ASP.

SG uses "connection identification" to identify the connection and
populate the DLR and DPC in the message as it does today in SCCP state
machine.

All that is really required is a way for the ASP to populate the
attributes of the "connection" in SGs other that those through which the
connection was either accepted "N-CONNECT Response" or confirmed
"N-CONNECT Confirm".  A proposal has been placed forth to use the REG
REQ to allow registration and deregistration of a connection identification
and connected point code against an existing Routing Context.  A similar
approach to that would suffice.  No other difference at the ASP from the
current procedures for coupled connection sections would be required.

--brian

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 16:47:51 +0530

Brian ,

"Brian F. G. Bidulock" <[email-masked]> on 08/28/2001 02:38:42 PM

Sandeep,

Sandeep >>  I am not sure if I understood the above statement. Please clarify ..
My understanding was that in decoupled SG case there is no connection section
present at SG, Are you saying that there is a connection section at SUA layer at
SG but not at SCCP Layer at SG ?

For now the only compelling reason for supporting decoupled SG approach is

Sandeep >> Are you talking about the case where GTT could not be fully resolved
at SCCP on SG or something else ?

"N-CONNECT Confirm".

Sandeep >> If a connection section is present at one SG and a SCCP state machine
is running there. How can messages of the same connection be routed through some
other SG ?

A proposal has been placed forth to use the REG

--brian

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 28 Aug 2001 15:18:25 +0200

Sandeep,

Some comments on your comments ...

1. The implementation of your NIF is up to you. The NIF does model the
interworking between SCCP and SUA in the SG, but it is misleading to present
the NIF as "SCCP-user" or "SUA-user". It really isn't.

For support of coupling of connection sections it is only important to know
that the SG must keep "state" or "information" in the SCCP/SUA software
complex. Where you actually put it, is again up to you. The issue is that
the SG terminates both an SCCP connection section and an SUA connection
section, and has enough information (using destination reference numbers
from the incoming SCCP/SUA messages) to know which section is coupled to
which in order to forward the CO messages. Nothing hi-tech about it. The
only thing different from coupling in all SS7, is that an additional mapping
to/from SCCP <-> SUA format is required. For the rest, all procedures are
the same, and supported in both SCCP (of course) and SUA.

2. If no coupling is performed at the SG, the SG must be able to make it's
forwarding decision based on the SS7 routing label (and possibly DRN) on the
one side, and RC on the other side. This restrict the possible interworking
scenario's, but avoid the drawback of coupling (keeping state).

3. The segmenting/reassembly issues are closed I think.

- for CL, the SUA doesn't segment/reassemble. The SG thus has to reassemble
all XUDTs before sending CLDT, and vice versa, the ASP has to include a
segmentation parameter to anticipate segmenting at the SG if the CLDT
doesn't fit into a single MSU. This avoids a lot of interworking problems,
and only has the (small) drawback that XUDTs could get missing if routing
occurs via multiple SGs AND a routing failure occurs. Hence my proposed
procedure ...

- for CO, both sides (SEP and ASP) have to be able to segment/reassemble and
restrict DT sizes to 255 bytes (ED to 128 even); because there is no limit
on number of segments here (streaming data). CO segmenting/reassembly
procedures are a lot easier than their CL counterpart, and it was considered
a small price to pay to avoid lots of interworking issues (esp. with
protocol class 3).

4. Of course you can only use TID for loadsharing, if you know it's a TCAP
message your transporting. Mostly, this is clear from the SSN in the address
parameter, possibly obtained after GTT at the SG.

Best regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 24 augustus 2001 6:16
To: [email-masked]
Subject: RE: SUAv7 : General Comments

resending ...
---------------------- Forwarded by Sandeep Mahajan/HSS on 08/24/2001 12:06
PM
---------------------------

Sandeep Mahajan
08/23/2001 05:57 PM

Hi Gery ,

Hi,

Sandeep >> Following is my understanding of connection oriented message
transport case. In case coupling is done in SG. we have one connection
section
in SCCP layer and one connection section in SUA layer. Connection section in
SCCP terminates SCCP procedures and connection section in SUA terminates SUA
procedures. Services of both these layers (SUA and SCCP ) should be invoked
using standard interface as listed in section 1.6.1 of SUA. it also means
both
SCCP and SUA should not be invoking each others procedures directly.

Follwoing in my view should be sequence of events for connection setup for
SS7
originated connection requests

* CR message received at SCCP on SG , SCCP passes N-CONNECTION indication
primitive to NIF.
* NIF invokes N-CONNECT request primitive of SUA, SUA sends CORE message to
ASP
and passes connection ID of this connection section to NIF.
* NIF makes a coupling of SCCP and SUA connection sections
* At ASP SUA receives CORE message and passes N-CONNECTION indication
primitive
to SCCP/SUA user.
* SCCP/SUA User at ASP invokes N-CONNECTION response primitive , SUA sends
COAK
message to SG
* SUA at SG receives COAK message and passes N-CONNECTION confirm primitive
to
NIF
* NIF invokes N-CONNECTION response primitive of SCCP, SCCP send CC message
to
SEP.
Similar procedures will apply for ASP originated connection setup.

And following should be the sequence of events for CO Data Transfer
* DT1 message is received from SEP, SCCP finds the connection section with
the
matching DRN. Determines user is local and passes the N-DATA indication
primitive to NIF.
* NIF finds the related SUA connection section and invokes SUA N-DATA
request
primitive.
* SUA sends CODT message to ASP ( gets SCTP association and stream values
from
connection info)
* SUA at ASP passes N-DATA indication primitive to SCCP/SUA user.

Connection sections are maintained at all nodes, SCCP at SG, SUA at SG and
SUA
at ASP.Also in ny view coupling of connection section should be done in NIF.

Sandeep >> Non Coupling at SG case is not very clear to me. My understanding
of
SCCP non coupling operation is.  Say we have three nodes A , B and C. CR
message
is received at node B and it decides if the coupling is required or NOT. If
coupling is not required this node relays the CR message to node C but does
not
maintain any connection section info. while processing CR message at Node C
, CC
message is sent directly to Node A. All data messages for this connection
are
exchanged directly between node A and Node C. So in SCCP data message does
not
arrive at Node B (where coupling was not done)

Are you saying that in Non Coupled SG case ,
* SCCP procedures does not terminate at SG
* No connection info is maintained at SCCP and SUA at SG. SCCP CO DT message
from SEP still arrives at SCCP on SG. How will SCCP process CO data message
for
which it has no connection info ?
* If SCCP procedures only terminates at SUA at ASP and SUA at ASP, assigns
reference number to the connection section. Two different SUAs at two
different
ASPs can assign same DRN for two different connection sections , So DRN
can't be
used as key for de-multiplexing messages at SG to different ASPs.

Please clarify ??

2. Segmenting/Reassembly
====

Sandeep >> What all enhancements in SCCP are being suggested/recommended? Do
we
have some sort of list of these enhancements ?

Sandeep >> I will suggest that we delete this paragraph , its bit of a
overkill
as you stated !!

4. Loadsharing
====

Sandeep >>  Ok

After that, the chosen system (SS7 or ASP) can return a unique address (e.g.
GT)
which TCAP HAS TO use in subsequent messages in order to reach to same
system
again. In SUA/AMF terms : the unique address leads to an AS with only 1 ASP
in
it.
Sandeep >> Till SCCP/SUA addess is resolved completly it can not be known if
the
user data is TCAP or not. So such load sharing may not be used at all nodes.

Best Regards,

-Sandeep

---

---

---

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

Gery,

Verwimp Gery wrote:                                       (Tue, 28 Aug 2001 15:18:25)
> the NIF as "SCCP-user" or "SUA-user". It really isn't.

For the backhaul case, it is not misleading at all to represent the NIF as an
SCCP-User to the SS7 stack.  This is a valid implementation of the NIF and is
a good basis for discussion of whether the NIF black box has adequate events
at its disposal on the NIF/SUA boundary.  Although the NIF/SS7 boundary need
not be implemented as an SCCP/SCCP-User interface, there should be sufficient
events available at the NIF/SUA boundary to permit it to be implemented as
such.

Certainly no-one is requiring that the NIF/SS7 boundary be implemented as
an SCCP/SCCP-User interface, however, it is an excellent reference with
which to described possible NIF functions in response to UA events.

> complex. Where you actually put it, is again up to you.

I was dicussing with Sandeep whether this "state" information was maintained
in the SG or the ASP for the decoupled case.  Whether it is in SG or ASP is
extremely pertinent to interoperability.

> The issue is that the SG terminates both an SCCP connection section and an
> SUA connection section, and has enough information (using destination
> reference numbers from the incoming SCCP/SUA messages) to know which section
> is coupled to which in order to forward the CO messages. Nothing hi-tech
> about it. The only thing different from coupling in all SS7, is that an
> additional mapping to/from SCCP <-> SUA format is required. For the rest,
> all procedures are the same, and supported in both SCCP (of course) and SUA.

This view is not so simple when multiple SGs are involved.

> scenario's, but avoid the drawback of coupling (keeping state).

There are three cases for connection establishment:  1) the CR was addressed
to the SG's point code and the SG decides to couple a connection to the ASP's
point code, 2) the CR was addressed to the SG's point code and the SG decides
not to couple the connection to the ASP's point code; and 3) the CR is
addressed directly to the ASP's point code.  The first two are SG/STP does
final GTT cases, the last is SG/STP does not do final GTT case.

> occurs via multiple SGs AND a routing failure occurs. Hence my proposed

Based on what your are saying here, I don't think we have closed this yet.

I agree with the ASP -> SG direction: the ASP must include segmentation
parameter so that SG can segment, but why cannot an ASP be permitted to
do the segmentation into something similar if it so wishes?  If the ASP knows
that segmentation may be required, can it not be permitted to segment itself?
I agree that the SG must be prepared to segment unsegmented ASP CLDTs based
on the Segmentation parameter (which still needs to be described) in the CLDT
and that if the ASP does not place a segmentation parameter in the CLDT when
necessary that the SG will either UDTS the message with reason segmentation
failure (or some such) or may discard it if return on error is not set.  But
why should an SG not accept presegmented CLDT?  This would permit an ASP
implementation which is worried about segmentation disruption across multiple
SGs to choose to segment messages itself without interoperability impacts.

In the SG -> ASP direction for the backhaul case, it makes sense that the
SG could reassemble segmented (XL)UDT into CLDT, but must it be required to
do so?  When multiple SGs are used, an ASP which is capable of performing
this reassembly itself would not experience distruption of segmentation
across changeovers between SGs.  Although I agree that in normal
configurations the SG SHOULD perform reassembly, it is not so desirable in
multiple SG configurations for decoupled (XL)UDTS which form the initial
BEGIN/INVOKE for ITU-T TCAP transactions.  (For all others a separate
segmentation facility is provided in TCAP).  Certainly it the SG does not
perform reassembly, the ASP should be prepared to either perform the
reassembly itself or reject the message with CLDS or discard.

In the IPSP -> IPSP case, is segmentation precluded?  An implementation
may very well want to segment long CLDT into pieces for better SCTP stream,
HOL blocking and IP fragmentation performance.

Including a full segmentation parameter in CLDT would permit all these
scenarios.  Then, aside from a few careful SHOULDs, in the draft, the
implementation can pretty much do what it likes and multiple SG cases can
be accomodated by the implementation.

Statements which would aid interoperability would be something like: an
SGP/ASP/IPSP MUST be prepared to deal with segmented CLDT (reassembly, CLDS,
etc..); an SGP SHOULD support segmentation of unsegmented CLDT where required;
an ASP SHOULD place segmentation parameter in CLDT where segmentation might be
required at an SGP and MAY always include it; an ASP/SGP/IPSP MAY segment
CLDT.

> a small price to pay to avoid lots of interworking issues (esp. with

Agreed.  Is there sufficient support in the CODT message to support this
segmentation in both directions?

> parameter, possibly obtained after GTT at the SG.

I think we closed TID.

--brian

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

---

---

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

Sandeep,

[email-masked] wrote:                            (Tue, 28 Aug 2001 16:47:51)
[snip]
> SG but not at SCCP Layer at SG ?

I was meaning that the connection section from the SS7 network could
"terminate" at the SG rather than terminating at the ASP.  I think
that it is better to leave SS7 specifics to the SG rather than the ASP
where possible.

> at SCCP on SG or something else ?

Two cases: a) the CR is addressed to the SG/STP's point code an GTT results
in the ASP's point code but coupling is specified in the GTT result as not
required.  b) the CR is addressed directly to the ASP's point code.

These two cases are provided for in SCCP at an STP today.  For the SG/STP
to address the full range of SCCP operation at an STP, these two decoupled
cases must be addressed.

> is running there. How can messages of the same connection be routed through some

This might be accomplished by the proposal mentioned below.  Before an ASP
moves a connection to the Data-Transfer (Established) state, it (optionally)
registers the local reference number and connected point code with the
alternate SGs.  Then any data or release messages can find their way to the
ASP via any SG.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 14:03:32 +0200

resend ...

Brian,

I agree it's a good excercise, but my point is the NIF deviates in a number
of cases. I'll try to list them below :

1. Coupling : 

State is kept in the end-point (the CO state machines) and in the SG. The
NIF mediates in the coupling between an SCCP and a SUA connection section.
In this respect it's not a "user"; also in the pure SCCP coupling of
connection sections, there's no SCCP-user present on the node performing the
coupling.

In terms of interoperability, yes, you'd have to know whether the SG you
connect to supports coupling or not. The same is true for an SCCP relay
node, which may or may not support coupling of connection sections.

The ASP has to consider the connection as lost when the SG goes down or
becomes unreachable.

2. Decoupled approach :

The third case is not possible with SCCP/SUA : the message is always
delivered from MTP distribution to SCCP, hence it's always the SG's point
code. Then you have either the "virtual local SSN" if routing is on DPC+SSN,
or GTT at the SG when routing is on GT which may be enhanced (AMF ?) to give
an AS/ASP as result of the translation. The ASP itself does not require a
point code.

The default case should be "coupling", which works in every case, although
it introduces a single point of failure. Decoupled approach is restricted
and must be specified in the RC (new parameter for RK in SUA ?)

Actually here's another issue to be considered : reference numbers are 3
bytes in SCCP and 4 bytes in SUA; for RC using decoupled approach, the SUA
must only use 3 bytes and code the MSB zero. Then the NIF can add/strip this
zero byte.

3. CL segmenting/reassembly :

I agree you have some valuable arguments, but want to note the following
points.

First of all : the segmentation parameter

+--------+--------+--------+--------+
|       tag       |    length = 8   |
+--------+--------+--------+--------+
|fst.rem.|    segmentation ref.     |
+--------+--------+--------+--------+

The first/remaining segments field is formatted as follows :

bit 8 (MSB) : indicates whether this is the first segment (1) or not (0)

bits 1-7 : indicate the number of remaining segments, value between 0 and 15

The field would thus be coded 1000 0000 (first, no remaining segments) for a
non-segmented CLDT.

The segmentation reference field is a 3 byte integer, assigned by the ASP.

3.1 ASP -> SG direction : if the CLDTs are pre-segmented, and still don't
fit into a single XUDT, the SG would have to reassemble and re-segment. This
cannot be the intention (not even in SCCP) so respond with CLDR
(segmentation failure).

3.2 SG -> ASP direction, or IPSP -> IPSP : the destination must support
reassembly. This is something you'd have to configure, if you want to use
segmentation.

-Gery

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 29 augustus 2001 0:14
To: sigtran
Subject: Re: SUAv7 : General Comments

Gery,

Verwimp Gery wrote:                                       (Tue, 28 Aug 2001
15:18:25)
> the NIF as "SCCP-user" or "SUA-user". It really isn't.

For the backhaul case, it is not misleading at all to represent the NIF as
an
SCCP-User to the SS7 stack.  This is a valid implementation of the NIF and
is
a good basis for discussion of whether the NIF black box has adequate events
at its disposal on the NIF/SUA boundary.  Although the NIF/SS7 boundary need
not be implemented as an SCCP/SCCP-User interface, there should be
sufficient
events available at the NIF/SUA boundary to permit it to be implemented as
such.

There are three cases for connection establishment:  1) the CR was addressed
to the SG's point code and the SG decides to couple a connection to the
ASP's
point code, 2) the CR was addressed to the SG's point code and the SG
decides
not to couple the connection to the ASP's point code; and 3) the CR is
addressed directly to the ASP's point code.  The first two are SG/STP does
final GTT cases, the last is SG/STP does not do final GTT case.

I agree with the ASP -> SG direction: the ASP must include segmentation
parameter so that SG can segment, but why cannot an ASP be permitted to
do the segmentation into something similar if it so wishes?  If the ASP
knows
that segmentation may be required, can it not be permitted to segment
itself?
I agree that the SG must be prepared to segment unsegmented ASP CLDTs based
on the Segmentation parameter (which still needs to be described) in the
CLDT
and that if the ASP does not place a segmentation parameter in the CLDT when
necessary that the SG will either UDTS the message with reason segmentation
failure (or some such) or may discard it if return on error is not set.  But
why should an SG not accept presegmented CLDT?  This would permit an ASP
implementation which is worried about segmentation disruption across
multiple
SGs to choose to segment messages itself without interoperability impacts.

Statements which would aid interoperability would be something like: an
SGP/ASP/IPSP MUST be prepared to deal with segmented CLDT (reassembly, CLDS,
etc..); an SGP SHOULD support segmentation of unsegmented CLDT where
required;
an ASP SHOULD place segmentation parameter in CLDT where segmentation might
be
required at an SGP and MAY always include it; an ASP/SGP/IPSP MAY segment
CLDT.

I think we closed TID.

--brian

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 13:38:26 +0200

Brian,

1. Coupling : 

2. Decoupled approach :

-Gery

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 29 augustus 2001 0:14
To: sigtran
Subject: Re: SUAv7 : General Comments

Gery,

I think we closed TID.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 14:06:50 -0500

Gery,

Verwimp Gery wrote:                                       (Wed, 29 Aug 2001 14:03:32)
> resend ...
> 
> Brian,
> 
> I agree it's a good excercise, but my point is the NIF deviates in
> a number of cases. I'll try to list them below :
> 
> 1. Coupling : 
> 
> State is kept in the end-point (the CO state machines) and in the
> SG. The NIF mediates in the coupling between an SCCP and a SUA
> connection section.  In this respect it's not a "user"; also in
> the pure SCCP coupling of connection sections, there's no
> SCCP-user present on the node performing the coupling.

SCCP mediates in the coupling (termination) of the final connection
section for its users, and an SCCP relay (STP) provides the function
of mediating.  SUA no longer requires that an NIF form a "artificial"
connection section.  At an end-point the NIF can be implemented almost
precisely as an SCCP-User.  Relays can be placed outside of SUA and
left in the SS7 network.  I don't see coupling as necessary in the SG.

> In terms of interoperability, yes, you'd have to know whether the
> SG you connect to supports coupling or not. The same is true for
> an SCCP relay node, which may or may not support coupling of
> connection sections.

There is no requirement to place SCCP relay node functionality into an
SUA implementation.  It can easisly be left in the SS7 network.

> 
> The ASP has to consider the connection as lost when the SG goes
> down or becomes unreachable.

This is a major failing of this artificial approach.

> 2. Decoupled approach :
> 
> The third case is not possible with SCCP/SUA :

This third case is exactly possible and was the intent of decoupling
in the first place that SUA not bind an operator to peform final GTT
at the SG.  It is quite easy to deliver all messages regardless of
destination address on SI value to the NIF.  The NIF decides where
to forward route based on RK and information in the messages like
any other SUA message being routed.

> the message is always delivered from MTP distribution to SCCP,
> hence it's always the SG's point code.

As far as the MTP at the SG is concerned, the ASP's PC does belong
to the MTP at the SG.

Gery, there is really nothing stopping an implementation from
handling case 3 as both a MTP-User and an SCCP-User.

> Then you have either the
> "virtual local SSN" if routing is on DPC+SSN,
> an AS/ASP as result of the translation.

> The ASP itself does not require a point code.

It does if it is going to be behind SGs as STPs.

> The default case should be "coupling",

SUA should not push recommendations on the SS7 network.

> which works in every case,

It only works where it is possible to do final GTT at the SG and
that can be forced upon an operator, thus case 3.  It can easily
work in case 3 as well.

> it introduces a single point of failure.

Not necessary.  SPOF is unacceptable.

> Decoupled approach is restricted and must be specified in the RC
> (new parameter for RK in SUA ?)

There is no reason to do this.

> must only use 3 bytes and code the MSB zero. Then the NIF can add/strip this

Where did you get this idea?  I would like to see the ability to add
an RK (OPC/DPC/DLR) to an RC, not embed an SLR in the RC itself.

> First of all : the segmentation parameter

This parameter proposal looks good.

> fit into a single XUDT, the SG would have to reassemble and re-segment.
> This cannot be the intention (not even in SCCP) so respond with
> CLDR (segmentation failure).

I agree, but we should leave the implementation to do what it wants
here.  If the implementation wants to reassemble and resegment, let
it.

> reassembly. This is something you'd have to configure, if you want to use

Sounds like something for an ASP Capabilities parameter in a REG
REQ...

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

---

---

From: [email-masked]
Date: Thu, 30 Aug 2001 11:21:26 +0530

Brian , Gery ,

Few questions ..
Do we need to support the case when SEP sends SCCP message that is not addressed
to SG's point code  what benefits does it gives and  how much restrictions does
it put on network configurations  if we do not support this case?.

In SS7 network to route messages between SCCP Users , at all intermediate nodes
relaying of messages at MTP3 is preferred , because
It is more efficient , MTP3 reads routing label , decides message is not
destined for it , determines route to reach DPC specified in routing label and
dispatch the message towards that node without ever touching the payload being
carried by it.  So we save on the processing of an extra layer (SCCP) at all
intermediate nodes if we are able to route at a lower layer (MTP3).

When SG is acting as MTP3 relay , message can not be relayed to ASP without
changing the  payload format. To achieve SG as MTP3 relay case MTP3 will have to
pass the received message of that DPC/SIO to NIF.  NIF will have to do some what
of parsing of the message to determine the type of message being carried and
invokes the corresponding SUA upper layer primitive. Lets say incoming SCCP
message is UDT, NIF can either convert this to N-UNITDATA request and pass that
to SUA or SUA starts supporting ( which it does not till date ) primitive like
N-UDT request that allows NIF to pass UDT message as such to SUA. SUA transports
this to ASP then.

In my view ( and I can be wrong ) SG as MTP3 relay is not like an MTP3 relay in
SS7 network , and much of the processing may not be saved because of protocol
conversion.

Also I do not think not supporting this case puts much restrictions on the
network configuration also. SEP just assumes that message is crossing network
boundary at SG and destined all its messages to SG's point code , where GTT is
performed , this GTT may and may not result final SCCP/SUA user but gives enough
information to route the message to ASP.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/30/2001 01:36:50 AM

Gery,

Verwimp Gery wrote:                                       (Wed, 29 Aug 2001
14:03:32)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 03:28:35 -0500

Sandeep,

[email-masked] wrote:                     (Thu, 30 Aug 2001 11:21:26)
> 
> Brian , Gery ,
> 
> Few questions ..
> Do we need to support the case when SEP sends SCCP message that is not
> addressed to SG's point code  what benefits does it gives and  how
> much restrictions does it put on network configurations  if we do not
> support this case?.

It would make SUA non-transparent.  SUA would be incapable of supporting
common configurations present in the SS7 network today.  Often within a
carrier's network final GTT is performed on many things at the
originating secondary STP or at the primary STP.  It is quite seldom
that final GTT is left for the terminating secondary STP.  That would
pretty much rule out most configurations where transactions are
incoming.  It would be bad to not support this case.  Many restrictions
would have to be identified for SUA and its lack of ability to support
STP/SGs.

> In SS7 network to route messages between SCCP Users , at all
> intermediate nodes relaying of messages at MTP3 is preferred , because
> It is more efficient , MTP3 reads routing label , decides message is
> not destined for it , determines route to reach DPC specified in
> routing label and dispatch the message towards that node without ever
> touching the payload being carried by it.  So we save on the
> processing of an extra layer (SCCP) at all intermediate nodes if we
> are able to route at a lower layer (MTP3).

This is true, but I don't think it is the reason for wanting to
implement MTP relay in the SUA/SG.  That is more a matter of where final
GTT is normally placed in the network.  Final GTT is not normally placed
at the terminating secondary (local) STP.  This is because in many cases
the terminating STP cannot even be determined until a translation has
been peformed and once a tranlsation has been performed it is final.
This is even true when multiple successive tranlsations are peformed
across multiple provider's networks: it is seldomly the last STP in the
chain which peforms final translation in large scale networks.

Because all STPs support MTP transfer as well as SCCP relay, an STP
owner may not be in a position to dictate to thier interconnects that
final GTT be performed at their STPs and certainly cannot for all
transactions or connections.

Restricting SUA to only network configurations which perform final
translation would make the SUA/SG/STP unable to meet STP conformance
requirements and would be undeplouable in a wide range of networks.

> When SG is acting as MTP3 relay , message can not be relayed to ASP
> without changing the  payload format. To achieve SG as MTP3 relay case
> MTP3 will have to pass the received message of that DPC/SIO to NIF.
> NIF will have to do some what of parsing of the message to determine
> the type of message being carried and invokes the corresponding SUA
> upper layer primitive. Lets say incoming SCCP message is UDT, NIF can
> either convert this to N-UNITDATA request and pass that to SUA or SUA
> starts supporting ( which it does not till date ) primitive like N-UDT
> request that allows NIF to pass UDT message as such to SUA. SUA
> transports this to ASP then.

It is simpler than all that, Sandeep: just assign the ASP's point code
to the SG/STP as an alias point code.  MTP will then deliver messages
addressed to the ASP's point code to the SCCP at the SG/STP as it does
for GTT aliases, SCCP can accept SCCP-Users of this alias point code.
SCCP-User interface is backhauled to ASP as usual.

> In my view ( and I can be wrong ) SG as MTP3 relay is not like an MTP3
> relay in SS7 network , and much of the processing may not be saved
> because of protocol conversion.
> 
> Also I do not think not supporting this case puts much restrictions on
> the network configuration also. SEP just assumes that message is
> crossing network boundary at SG and destined all its messages to SG's
> point code , where GTT is performed , this GTT may and may not result
> final SCCP/SUA user but gives enough information to route the message
> to ASP.

Unfortunately the configuration which SUA is attempting to support in
all cases here is multiple SG as STP.  For STPs to be ineterconnected to
the SS7 network they normally have to be conformance tested as STPs.
All STPs have MTP3 transfer capabilities and can relay SCCP at MTP3.
SUA/SG/STPs will fail in this respect.

There are really only a couple of things which must be done to support
this operation and none of it requires such radical changes as you might
think.  It is better and easier to add a couple optional procedures
which cover this case, than start listing the non-transparencies of SUA
and unsupported STP compliance items over a wide range of network
configurations.

The Segmentation/Reassembly seems to already be worked out.  All that
is required is some mechanism similar to the REG REQ procedure proposed
to permit an ASP to register a connection with alternate SGs.  That
would just about do it.  COuld you comment on the REG REQ proposal and
let us know if you see a better way of acheiving the same end?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 30 Aug 2001 10:55:56 +0200

Brian,

Let's number the general comments :

1. Coupling of connection sections

This procedure is optional in SCCP; it is also optional in the SG. It's not
an artificial procedure, and even required in a CR message crosses network
borders. The connection is setup edge-to-edge (in between link-by-link and
end-to-end). The SG is an edge. From SS7 point of view, it seems like
there's nothing "behind it".

2. Relay functionality (= ability to route on GT)

This is optional in SCCP; nodes who have this functionality are called SCCP
relay nodes. Optional in SG, it may act as SCCP relay node as well as SCCP
end node.

Now, if SCCP provides this function, why not SUA in all-IP case ? Are you
saying we should force 3GPP to deploy SCCP/M3UA instead of SUA or we should
deny the SCCP-users the "route on GT" possibility ?

3. Decoupled approach (time for me to start calling names ;)

How do you want to address SCCP/SUA at the SG when you don't use the SG's
point code ? You're using MTP3/M3UA transfer here ? It's all the SG's point
codes, but by definition of the RC, the AS/ASP may get all SCCP traffic for
one or a number of them. I hope this is what you mean by the ASP "having"
point codes.

4. Reference Numbers : look at the format

SCCP : 3 byte local reference numbers
SUA : 4 byte local reference numbers

=> no straightforward 1-1 mapping in the SG, unless ...
RC or a 4 byte reference number cannot be transported in SCCP.

5. Reassembly of pre-segmented CLDTs and re-segmenting :

Kind of defeats the purpose of having nothing to do at the SG. It also
introduces an interoperability issue.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 29 augustus 2001 21:07
To: sigtran
Subject: Re: SUAv7 : General Comments

Gery,

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 04:35:45 -0500

Gery,

Verwimp Gery wrote:  (Thu, 30 Aug 2001 10:55:56)
> This procedure is optional in SCCP; it is also optional in the SG.
> It's not an artificial procedure, and even required in a CR message
> crosses network borders. The connection is setup edge-to-edge (in
> between link-by-link and end-to-end). The SG is an edge. From SS7
> point of view, it seems like there's nothing "behind it".

SCCP does not require coupling at an edge.  SCCP specs do not state when
coupling is required or not.  It is a result of translation.  Coupling
is only performed at SCCP relay points where translation is performed
and is not required.  I do not view multiple SG as STPs as an edge of
anything an STPs always have something behind them (SEPs).

> 2. Relay functionality (= ability to route on GT)

You should qualify "Relay" with "SCCP".  STPs also perform "relay"
functions at MTP using the transfer function.

> This is optional in SCCP; nodes who have this functionality are called
> SCCP relay nodes. Optional in SG, it may act as SCCP relay node as
> well as SCCP end node.

Yes, but SG can only be both relay and end node if SG is capable of
acting as though it is two nodes (e.g, STP with SEP behind).  Otherwise,
the relay node has nowhere to relay.

> Now, if SCCP provides this function, why not SUA in all-IP case ?

Because IP doesn't need it.  IP is a datagram service unlike MTP which
is a link-based, full duplex, sequenced service.  MTP either needs a
full mesh of F-links (expensive) or STPs (expensive in a different way)
to achieve connectivity between end nodes.  IP is a datagram service
which does not need STPs to establish connectivity between end nodes.
SCCP-Users at end nodes are unaware of the presence or absence of SCCP
relay nodes (except perhaps in the range of availale QoS).  SCCP-Users
in the IP domain are also unaware of relay functions.  Because SUA is
capable of setting up a full mesh of connections between SUA end-nodes,
and because in the IP network these connections are cheap, expensive SUA
relay functions which further degrade experienced QoS are not only not
required but it would be absurd to provide them.  They do nothing but
hamper the end-to-end transport of SCCP over IP networks.

> Are you saying we should force 3GPP to deploy SCCP/M3UA instead of SUA
> or we should deny the SCCP-users the "route on GT" possibility ?

GTT can be performed at the originating node just as in the F-linked
environment today.  STPs (SCCP relay) are not even required in an SS7
network.  Remember the promise from Q.71x: SCCP-Users are unaware that
SCCP relay functions exist in the network.  Because of that, no SCCP
User can "require" a relay function.

If 3GPP wants to break this principle of SCCP, they should *really*
be in an extension draft.

> How do you want to address SCCP/SUA at the SG when you don't use the
> SG's point code ? You're using MTP3/M3UA transfer here ? It's all the
> SG's point codes, but by definition of the RC, the AS/ASP may get all
> SCCP traffic for one or a number of them. I hope this is what you mean
> by the ASP "having" point codes.

The ASP has a point code and the SGs have their own point codes.  If the
ASP's point code is represented on the SG as an alias point code with
local SCCP-Users, the SG can backhaul the APS's point code to it without
touching MTP3, but effecting the same relay as is perfomed by MTP at
STPs.  I am not talking M3UA here.  M3UA is not involved.

> SCCP: 3 byte local reference numbers
> SUA: 4 byte local reference numbers
> 

What has a reference number got to do with RC?

> Kind of defeats the purpose of having nothing to do at the SG.

If indeed that was required for a particular configuration.  It might
not be so, and the SG might decide to resegment where the ASP has
unnecessarily (and rather incorrectly) segmented in the first place.

> It also introduces an interoperability issue.

What interoperability issue?

--brian

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

---

---

From: [email-masked]
Date: Thu, 30 Aug 2001 16:42:12 +0530

Brian ,

Just to make sure I did not misunderstood you ,if the problem is
How to support the case when SEP sends SCCP message to SG that is not addressed
to SG's point code but addressed to ASP point code that is accessible via SG.
Should MTP3 be passing messages to NIF and NIF passes then to SUA ?

You are suggesting that solution to this can be
Assign ASP point code as alias point code to SG. MTP3 will then pass all
messages destined to ASP point code to SCCP running at SG. And there is not need
of MTP3 passing messages to NIF.

If that is the solution , I agree this does not require any extra support in SUA

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/30/2001 02:58:35 PM

Sandeep,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 06:18:59 -0500

Sandeep,

That is one possible solution.  We are agreed.

The only minor addition to SUA would be to provide the ASP the ability to
optionally register a connection identification with alternate SGs for
decoupled non-final multiple SG as STP situations.

--brian

[email-masked] wrote:                     (Thu, 30 Aug 2001 16:42:12)
> 
> 
> 
> Brian ,
> 
> Just to make sure I did not misunderstood you ,if the problem is How to
> support the case when SEP sends SCCP message to SG that is not addressed to
> SG's point code but addressed to ASP point code that is accessible via SG.
> You are suggesting that solution to this can be Assign ASP point code as
> alias point code to SG. MTP3 will then pass all messages destined to ASP
> point code to SCCP running at SG. And there is not need of MTP3 passing
> messages to NIF.
> 

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

---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 11:44:35 +0530

Hi ,

Can we consider the other case now ..
SEP sends UDT/XUDT message to SG. MTP3 at SG passes this message to SCCP.
Routing label in this message is set to Route on GTT. SCCP performs the Global
Title Translation. GTT yields RI =  Route on GTT ,  New GTT digits and DPC where
next GTT to be performed = point code of ASP. So in this case message may not be
destined to ASP to which SG is directly connected and ASP that is directly
connected will be used as relay for reaching final node.

SCCP for routing message checks its local database if the DPC for which this
message is destined is accessible or not, if it finds the DPC accessible SCCP
pass the message to MTP3 for transfer to that DPC.  In our caseGTT has resulted
in next hop DPC that is accessible via SUA and not via MTP3 , SCCP at SG need to
pass this message to NIF, which further pass this to SUA. Following in my view
can be the approaches
1) SCCP is enhanced and this enhanced SCCP will be aware of which point code is
accessible via MTP3 and which point code is accessible  via  SUA , and based on
this knowledge SCCP will pass the message to either MTP3 or NIF.
2) GTT at SCCP is configured in such a way that for all those messages,  which
can not be fully resolved ( i.e. which after translation still results in RI =
Route on GTT) and which are destined for IP network; GTT set the value of next
hop DPC to local point code. And SCCP be enhanced to pass message of this type
to NIF. NIF pass this message to SUA, In SUA another GTT is performed to
determine which ASP this message should go to.  This requires less changes in
SCCP but is less optimum and put some configuration restriction.

Can there be some other approach ?

For the interface between SCCP to NIF and NIF to SUA.,  some approaches can be
a) SCCP passes UDT/XUDT message as such to NIF, NIF converts this and passes
N-UNITDATA request primitive to SUA.
b) SCCP builds and passes N-UNITDATA indication primitive to NIF and NIF passes
the N-UNITDATA request primitive to SUA.
c) SCCP passes UDT/XUDT message as such to NIF and NIF invokes N-UDT request ( a
new interface) primitive of SUA. This will let NIF pass parameters like hop
counter and Segmentation to SUA which are present in the message but not in the
SCCP/SCCP User interface.  This seems necessary also as SCCP at SG is not the
destination SCCP and a segmented XUDT will not be reassembled by SCCP at SG. So
the reassembly can either be done in NIF at SG or these segmented messages can
be passed to ASP and destination SUA reassemble them. If we decide to let
destination ASP do the reassembly some primitive like N-XUDT request is needed
in SUA.

Please correct me ..

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/30/2001 05:48:59 PM

Sandeep,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 01:55:10 -0500

Sandeep,

[email-masked] wrote:                     (Fri, 31 Aug 2001 11:44:35)
> Can there be some other approach ?

Rather than trying to modify the SCCP, I just let SG's SCCP pass the
message with the ASP's point code down to MTP: MTP discriminates and
passes it up to the SCCP (MTP-User) associated with the ASP's point
code.  (In SS7, SCCP-Users on the same node are permitted to talk to
each other via SCCP or MTP.  Many SS7 implementations are capable of
this.)  SUA is just a normal SCCP-User on the SCCP attached as an
MTP-User to the ASP's point code.  No SCCP enhancements are necessary.
In the decoupled case, messages never touch the SCCP relay on the SG's
point code and are passed directly by MTP to the ASP's SCCP.  This
automatically handles both SCCP and MTP relay to the ASP via the
SG/STP's point code.

If the ASP's SCCP (on the SG) receives RI=GT it performs normal SCCP
routing using ASP's SCCP GTT tables on the SG (not SG's which was
used for relay).  If this results in RI=GT again with the ASP's DPC the
error procedures of SCCP apply.  If this results in RI=PC/SSN and the PC
is the PC of the ASP, the message is passed to the local SCCP-User by
SSN.  This is where message is passed to NIF.

> destination ASP do the reassembly some primitive like N-XUDT request is needed

I just have SUA attached to SCCP (ASP's SCCP on the SG) as an SCCP-User.
SUA receives N-UNITDATA indication (not request) directly from SCCP.
SUA performs AMF (if necessary) and obtains RC.  SUA uses RC, AS
attributes associated with the RC, and arguments of N-UNITDATA to
determine appropriate ASP/association/stream per AS traffic mode and
states of AS and ASPs.  SUA uses RC and N-UNITDATA indication arguments
to build CLDT message.  SUA message is passed to selected ASP on
selected association/stream.

For connectionless, this is just the regular backhaul case.  No SCCP
enhancements are required and the SCCP/SCCP-User interface is sufficient
for the NIF.  The NIF can be about 1 Angstrom units thick.

Does this also make it clear why it is not always necessary to decrement
Hop Counter in NIF or SUA in the backhaul case?  All translation in this
approach is performed in SCCP, and none is performed in NIF/SUA.  SUA
just exports the SCCP/SCCP-User interface.

--brian

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

---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 16:18:17 +0530

Brian ,

I was talking about the SEP - SG - ASP1 - ASP2 case.
In this case SEP sends a message to SG which is destined for SCCP User at ASP2.
Since ASP2 is not directly connected to SG. SG sends this message to ASP1, ASP1
apply AMF to this message, determines the next node and relays the message to
ASP2. ASP2 then pass this message to local SCCP/SUA User. If we extend this case
there can be any number of intermediate nodes between SG and final ASP. In the
above network configuration it is possible that GTT is not fully resolved at
SCCP on SG (GTT yields RI= Route on GTT), but gets resolved at some intermediate
node in SUA network. This case can not be supported as a regular backhaul case..

Does/Should  SUA support this case ?

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/31/2001 01:25:10 PM

Sandeep,

--brian

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

---

---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 16:48:27 +0300

Hi Brian & Sandeep,

With all due respect, this thread has gone on quite long.
I am not sure what issue you are discussing with regards to
SUA.  

I believe you were discussing the possibility of text for 
chapter 1 of SUA and/or an Applicability Statement.

Could you summarize the discussion & your needs?

thanks,
JOhn

> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 30 August, 2001 14:19
> To: sigtran
> > If that is the solution , I agree this does not require any 
> extra support in
> > SUA
> > 
> > Best Regards,
> > -Sandeep
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 10:25:56 -0500

Sandeep,

Pardon me.  I misunderstood.

It is hard to conceive of an SG - ASP1 - ASP2 case.  SG - ASP1 would be
backhaul, but ASP1 - ASP2 would be peer.  The peer case is not well
enough defined in the spec to way what would happen.  Also, I don't see
the point of ASP1 (or an number of ASPs in peer arrangement between SG
and ASP2) acting as relays.   SG should just go straight to ASP2.  What
is the purpose of having SUA relays?

--brian

[email-masked] wrote:                            (Fri, 31 Aug 2001 16:18:17)

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

---