Subject: RE: [SUA issue 14] Changes and additions required for decoupled o peration.

From: [email-masked]
Date: Tue, 4 Sep 2001 10:50:34 +0300

Hi all,

I need some additional clarificatoin for this issue:

> Attached is an SUA Last Call issue:
> Changes and additions required for decoupled operation.
> 
> From: [email-masked]
>
> 1. Reassembly of XUDT at SG : I think everyone agrees on that 
> now. To deal with link/routeset failures, can everyone agree on 
> following procedure ?
> 
> "If a SG 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 SG or if no mated SG is available, the 
> return on error procedures must be invoked."

Is this sufficient?
> 
> 2. Coupling of connection sections at SG : let's see if we can reach a
> compromise ...
> 
> The CR message can contain information (e.g. GT, SSN) based 
> on which an AS/ASP is selected. This information is no longer present 
> in subsequent CO messages. Therefor, in order to provide seemless SS7 - IP

> interworking, coupling of connection sections is required in the SG when :
> 
> - the SG acts as SEP : in this case SUA is used to provide 
> the interface between SCCP on the SG and the SCCP-user on the ASP.
> 
> - the SG acts as STP, and the AS/ASP cannot be derived from 
> the received SCCP-CO message, or the SEP cannot be derived from the 
> received SUA-CO message.
> 
> To avoid coupling, we need SS7 address info (at least a PC) 
> in all SUA-CO messages (CODT etc.) ! If we want coupling of connection 
> sections optional at the SG, we need to update the SUA-CO messages in this

> respect.

Is this sufficient?

> BTW: are we going to work with routing contexts instead of network
> appearance now in each SUA-CL and CO message ? If so, this 
> could be used for
> mapping to a SEP in case of "no coupling" at the SG. To me 
> this sounds like
> a good idea for 2 reasons :
> 
> - the network appearance parameter definition is still rather shaky
> - the routing context could well provide the same (and more) 
> functionality
> 
> 3. SCON : yes, there are multiple congestion levels (0 -> 7)
> 
> 4. Concerning DRST : let's see if I get it straight ... this 
> is to signal to
> concerned/neighbouring nodes that a SG/SUA-relay node from a 
> mated pair has
> lost connectivity to a SEP/SUA-end node and routing should preferably
> continue over the other mate. The other mate will receive a 
> DUNA instead of
> a DRST, and when he loses connectivity to the same endpoint 
> as well, both
> SGs will send DUNA to their neighbours.
> 
> Since SGs can consist of several SGPs (and would be modelled 
> as such in the
> ASP to guard SCTP connectivity), the SSNM messages (DUNA, 
> DAVA, SCON, DRST),
> when received from any of these SGPs, should be regarded as 
> valid for the entire SG.
Is this sufficient?  What text is needed?

JOhn

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 03:24:09 -0500

John,

> > return on error procedures must be invoked."

No.  The SG has no procedure for passing such messages to its mate.
As regards segmentation/reassembly, we have pretty much agreed to
allow the ASP to perform segmentation and reassembly of (XL)UDT
messages if it wishes to avoid disruption of the process due to
changeovers in the SS7 network.

> > sections optional at the SG, we need to update the SUA-CO messages in this

No.  Because changeovers in the network can cause disruption of
connections first initiated via one SG/STP which is not the case
for an SS7 STP/SEP.  A mechanism is required to inform the SG/STP
mate of the DLR/RC mapping.  If such a mechanism is provided, then
these additions are not required to the CO messages.  If it is not,
then the addition of dest address to CO messages does not fully
address the problem.  You dismissed current registration proposals
to address this deficiency in SUA as "discussed" and "not required"
for M3UA.

> Is this sufficient?  What text is needed?

This sounds like the SGP/SG issue on SNMM for M3UA.  I don't believe
that it is related to Issue 14.

--brian

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

---

---

From: [email-masked]
Date: Tue, 4 Sep 2001 11:38:58 +0300

Brian,

PART I

> changeovers in the SS7 network.

So could we say:

If a SG  operated in mated pair configuration receives a non-first XUDT 
segment for which no reassembly process exists and it cannot pass the 
segment to it's mate then the return on error procedures must be invoked.

PART II

> to address this deficiency in SUA as "discussed" and "not required"

I'm just reporting what I saw.  Is this part of this issue related to
your following proposal:

> In both M3UA and the current SUA proposal for registration
> the Routing Key is fixed against a RC after the registration
> is complete.  There is no provision to permit the ASP to
> change the Routing Key without first deregistering.  This
> is not good on a live system.
> 
> An example is where an ASP wants to add additional CIC-ranges
> to an existing AS, or where an ASP wants to add additional
> GT's to an existing AS.
> 
> As a quick solution, I propose that we add Routing Context
> as an optional parameter to the REG REQ message.  When included
> in the REG REQ message the SG should interpret this to mean
> that the Routing Key is to be added to the existing Routing
> Context.
> 
> To remove Routing Key components from an existing AS, the
> Routing Key parameters could be added as an optional component
> of the DEREG REQ message.  When an RK is included in the
> DEREG REQ message, the SG should interpret this to mean that
> the Routing Key is to be removed from the existing Routing
> Context.
> 
> The SG SHOULD apply the addition or removal of a Routing Key
> component to Routing Keys received on one SGP to all SGP
> consistent with the requirement that Routing Contexts must
> be coordinated across SGP in an SG.
> 
> In addition, for SUA decoupled operation, SLR (and a few
> other parameters of CORE or COAK) could be added to the SUA
> REG REQ as an optional parameter of the Routing Key.  This
> would permit an ASP to register with an SG the fact that it
> has a connection for a given SLR/Dest within an existing
> Routing Context.  This would permit seamless decoupled
> connection-oriented operation in SUA by permitting multiple
> SG to associate an ASP SLR/Dest value with a routing
> context for routing CODT messages.  An ASP operating across
> two SGP could register an SLR/Dest/... in the appropriate
> routing context with all SGs which do not receive the CORE
> or COAK message, so the SG can populate the attributes of
> the connection.
> 
> This could resolve the connection-oriented problems in 
> SUA Issue 14.
[text clipped]

> that it is related to Issue 14.

So the text I clipped not part of issue 14?  So do PART I & PART II
of the above cover everything for you?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 03:54:01 -0500

John,

> segment to it's mate then the return on error procedures must be invoked.

I think that we are addressing this under Issue 15.  (See also below)

> I'm just reporting what I saw.  Is this part of this issue related to

Yes.  The paragraph starting with "In addition" describes how
the procedure can resolve Issue 14.

> > be coordinated across SGP in an SG.

The following paragraph addresses Issue 14, but relies on the
above changes.

> of the above cover everything for you?

There is one issue: decoupled operation.  Part I relates to decoupled
operation for CL.  Part II relates to decoupled operation for CO.
Part I (CL operation) can largely be addressed by decoupled
considerations under a resolution to Issue 15.  Part II (CO operation)
requires some procedure which allows the ASP to notify the SG
through which the connection is not initially formed of the details
of the connection (i.e., the "Connection Identification").

--brian

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

---

---

From: [email-masked]
Date: Wed, 5 Sep 2001 13:36:24 +0300

Hi Brian,

[re-arranging some text for clarity]

> > If a SG  operated in mated pair configuration receives a 
> > non-first XUDT segment for which no reassembly process exists 
> > and it cannot pass the segment to it's mate then the return 
> > on error procedures must be invoked.
> 

OK, I will take the above up in a seperate thread on Issue 15.

> of the connection (i.e., the "Connection Identification").

Part I will be handled under issue 15, OK?

Part II - with regards to the Connection ID, you had suggest a parameter
called 'Correlation ID' - is this the same parameter, or is this new?

Additionally for resolving issue 14, the changes you want are:

1) Adding RC to Req Req & Dereq Req as optional parameters
2) Adding SLR & other paramters to be part of Routing Key

-> Can you remind me what SLR is & what other parameters you 
   wish to be added.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 14:14:12 -0500

John,

> OK, I will take the above up in a seperate thread on Issue 15.

Ok.  I think Sandeep is already discussing it there.

> -> Can you remind me what SLR is & what other parameters you 

I can go one better and provide proposed text.  But first, are there
any objections to this approach?

--brian

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

---

---

From: [email-masked]
Date: Thu, 6 Sep 2001 09:08:51 +0300

Hi Brian,

> any objections to this approach?

Go for it.

John

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 10:19:17 +0300

Hi Brian,

> > any objections to this approach?

We are waiting on your text to close this.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 03:36:11 -0500

John,

Here's a proposal which is different that the REG REQ proposal.
(complete with text ;)

--brian
      
   Connection-Oriented Messages  
    
     0         Reserved 
     1         Connection Request (CORE)  
     2         Connection Acknowledge (COAK) 
     3         Connection Refused (COREF)  
     4         Release Request (RELRE)  
     5         Release Complete (RELCO)  
     6         Reset Confirm (RESCO)  
     7         Reset Request (RESRE)  
     8         Connection Oriented Data Transfer (CODT) 
     9         Connection Oriented Data Acknowledge (CODA) 
     10        Connection Oriented Error (COERR) 
     11        Inactivity Test (COIT) 
 >   12        Connection Indication Registration (CIRE)
 >   13        Connection Indication Deregistration (CIDE)
 |   14 - 127  Reserved by the IETF 
     128 - 255 Reserved for IETF-Defined Message Class Extensions 

3.3.x Connection Indentification Registration (CIRE)

   This message notifies an alternate SG that an ASP has established a
   connection for the identified destination address, destination
   reference number and Routing Context.

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0006         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       Routing Context                         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0103         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                     Destination Address                       /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0105         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Destination Reference Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context                    Mandatory
     Destination Address                Mandatory
     Destination Reference Number       Mandatory

3.3.x Connection Identification Deregistration (CIDE)

   This message notifies an alternate SG that an ASP has released a
   connection for the identified destination address, destination
   reference number and Routing Context.

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0006         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       Routing Context                         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0103         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                     Destination Address                       /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0105         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Destination Reference Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context                    Mandatory
     Destination Address                Mandatory
     Destination Reference Number       Mandatory

John Loughney wrote:                              (Tue, 11 Sep 2001 10:19:17)

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

---

---

From: [email-masked]
Date: Tue, 18 Sep 2001 13:32:36 +0300

Hi Brian,

> Here's a proposal which is different that the REG REQ proposal.

Quick question - do you have a preference for which proposal
you prefer?

Additionally, any comments from the audience?  Both proposals are 
attached:

==== proposal 1 ====

     0         Reserved 

      0                   1                   2                   3  

   Parameters

      0                   1                   2                   3  

   Parameters

==== proposal 2 ====

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Sep 2001 12:21:44 -0500

John,

In the end, I prefer the non-reg-req version.  The reason
being that this is a protocol function (e.g. it only applies
to CO and not CL) rather than a general management function.
Perhaps the messages could be named better.

--brian

John Loughney wrote:                         (Tue, 18 Sep 2001 13:32:36)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 09:16:48 +0200

John & Brian,

Does this really have any use ? You have several ASPs serving CO traffic
coming via 2 (or more) SGs from the SS7 network. Is each ASP going to inform
each SG of each connection (DRN) he's currently handling/releasing ? What if
2 or more ASP "register" the same DRN (within the same RC), what's there to
prevent them (also situations where (de)registrations cross) ? 

I guess this is a lot of excess traffic just for opening up a new can of
worms ... therefor I strongly oppose this manner of working.

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: dinsdag 18 september 2001 19:22
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

John,

--brian

> To unsubscribe send a blank email to
[email-masked]

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

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 03:22:54 -0500

Gery,

Verwimp Gery wrote:                    (Wed, 19 Sep 2001 09:16:48)
> each SG of each connection (DRN) he's currently handling/releasing ?

This is necessary only if decoupled operation is supported.

> What if 2 or more ASP "register" the same DRN (within the same RC), what's
> there to prevent them (also situations where (de)registrations cross) ? 

The idea is to register on the SG not receiving the CORE or COAK.  If the
registration were to be refused, the CORE/COAK would also have been refused.

> worms ... therefor I strongly oppose this manner of working.

Decoupled operation requires it.  Let me illustrate this once more so you
get the idea:

                         SG-A                                      
                       ________                                    
                      |        |                                   
                      |        |                                   
                 _____| STP/SG |___     SCTP                       
                /     |        |   \ Association                   
               /      |________|    \                              
              /           |          \                             
    _____    / A-link     |           \       _______              
   /     \  /             |            \     |       |             
  /       \/           C-links          \____|       |             
  |  SEP  |               |              ____|  ASP  |             
  \       /\              |             /    |       |             
   \_____/  \  A-link     |            /     |_______|             
             \            |           /                            
              \        ___|____      /                             
               \      |        |    /   SCTP                       
                \_____|        |___/ Association                   
                      | STP/SG |                                   
                      |        |                                   
                      |________|                                   
                                                                   
                         SG-B                                      

In the above diagram without coupling of connection sections at the SG,
remember that there is nothing in the SS7 nework requiring CO messages
in one direction and CO messages in the other direction to pass through
the same STP.

That is DT1 are sent, for example, from SEP to ASP with SLS=0110
traversing SG-A, where as the ASP sends CODT to SG-B.  Without coupling
there is no way to know through which STP messages will pass from SEP to
ASP in advance of establishing the connection.  Both SGs must be informed
of the local reference number assigned to the ASP.  In the SCCP-user
primitives this is called the "Connection Identification" parameter
which might or might not be implicit to the interface.

If the SCCP-User interface is to be made to appear at both SGs, then
must both be informed when a connection is formed.

The same is true for TCAP support for CL.  It will be necessary for
the ASP to be able to inform both SGs that a given Transaction Id has
been associated with a given ASP.

Can you propose a mechanism which does not register?  I have proposed
two: can you think of a third?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 11:40:02 +0200

Brian,

Yes, I get the idea.
We can take the approach so that GT or DPC identifies a single ASP, but this
is probably too restrictive. But instead of taking a single TID/DRN to
register, I'd propose the following :

The ASPs in an AS have to agree a "label" which would mark the TID/DRN as
uniquely theirs within this AS. This can be done for CL and CO separately.
The bit positions and length of the "label" can be specified in the REG REQ
(either common for CO/CL, or you'd have separate RK/RC for CO and CL resp).

So : layout of extra/changed RK parameter (besides the indication CO, CL or
both) for SUA, optional of course :

+--------+--------+--------+--------+
|  tag = 0x????   |   length = 8    |
+--------+--------+--------+--------+
| start  |   end  |   label value   |
+--------+--------+--------+--------+

start : start position of label, between 0 (LSB) and 31 (MSB)
end : end position of label, between 0 (LSB) and 31 (MSB)

Check : start > end (going from MSB to LSB); the length of the label (start
- end + 1) determines the maximum number of ASPs, but this should be a minor
issue. Maximum length is 16 bits, does anybody want more than 64K ASPs in
his AS ??

label value : the actual label of the ASP sending the REG REQ.

I think this provides both flexibility and low dynamic overhead ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 10:23
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

                         SG-A                                      
                       ________                                    
                      |        |                                   
                      |        |                                   
                 _____| STP/SG |___     SCTP                       
                /     |        |   \ Association                   
               /      |________|    \                              
              /           |          \                             
                                                                   
                         SG-B                                      

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 05:21:00 -0500

Gery,

Even if partitioning TID/DRN were practical
(which it is not in large systems), it does
not matter that an SG knows to which ASP a
DRN/TID belongs, it must also know the state
of the connection/transaction.

If the SG does not know the state of the
connection or transaction, full SCCP state
machines will be required at the ASP.  This
is against the objectives of the backhaul
case.

By registering against an RC, the ASP can
both indicate the state of the SCCP-User
interface as well as the routing for a given
TID/DRN.  Partitioning can only indicate
routing and makes the ASP responsible for
stateful responses to SCCP PDUs (i.e, the
ASP must implement SCCP state machines).

Per TID/DRN registration cannot be avoided
in the backhaul case.

--brian

Verwimp Gery wrote:                              (Wed, 19 Sep 2001 11:40:02)
> So: layout of extra/changed RK parameter (besides the indication CO, CL or
> start: start position of label, between 0 (LSB) and 31 (MSB)
> end: end position of label, between 0 (LSB) and 31 (MSB)
> 
> Check: start > end (going from MSB to LSB); the length of the label (start

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 12:28:04 +0200

Brian,

I don't follow your reasoning here. The ASP has to have state machines
anyway. If the SG has state machines (connection oriented, backhaul, because
SCCP wouldn't know the transaction state anyway (CL remember, or do you
propose using TUA ?)) you'd have the coupled approach described already in
the SUA draft.

There's absolutely no need for the SG to keep any state, that's the whole
idea of decoupling anyway (a relay node without coupling also couldn't care
less about connection/transaction state). The use of TID/DRN labels serves
the purpose of forwarding the message to the correct ASP, which is all that
matters. The connection/transaction is end-to-end between ASP and SEP, and
the SG does nothing but mapping and forwarding.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 12:21
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 05:53:41 -0500

Gery,

What you describe is not the ASP/SG backhaul model.  The ASP/SG backhaul
model exports the SCCP/SCCP-User interface from SG to ASP.  It does not
push to the ASP state machines from below the SCCP/SCCP-User interface.

For example, when the SG receives a DT1 for a DRN which is in the
disconnected state, the SCCP does not indicate N-DATA to the SCCP-User
and expect the SCCP-User to respond from the disconnected state.  The
SG SCCP replies to this with the appropriate peer error message
according to the SCCP state machines.  What you would have us do is
move these SCCP state machines to the ASP when all the backhaul model
need send from SG to ASP is the N-Primitives.  That is why it does not
work.

Registration permits the ASP to inform SGs that it has a connection in
the data transfer state so the SG knows to forward N-DATA indications
rather than responding to the SCCP peer with an error.  This leaves the
SCCP state machines at the SG (and in the SS7 stack) and permits the ASP
to act as SCCP-User.

--brian

Verwimp Gery wrote:                           (Wed, 19 Sep 2001 12:28:04)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 13:29:45 +0200

Brian,

That's what I am concerned about.

First of all, in the coupled approach, SCCP wouldn't send the N_DATA
primitive either but already send an appropriate answer back because it
can't find the second leg (or whatever resource). This cannot work in the
decoupled approach : the connection state must be kept at either end-point,
whether it is SCCP or SUA.

What you're saying is that SCCP at the SG keeps the connection data (state,
addresses) instead of SUA at the ASP (the endpoint where I think it
belongs). Furthermore, not only on this SG, but on all SGs the ASP can
communicate with. This opens a can of worms if you consider SCTP association
failures (does the SG consider the connection lost or not ?), the inactivity
test procedure for SCCP connections (what SG is responsible; is it the one
who lost connection to the ASP ?) a.s.o. just to save a few lines of code at
the ASP. The backhaul case you describe, I fear can only work when SG and
ASP work in unique cooperation (probably same vendor of SG and ASP) which
wouldn't require registration anyway.

For TCAP transactions it's the same thing, you can't expect SCCP at the SG
to keep track of those, can you ?

This is also my argument for making no distinction for SUA between
peer-to-peer and backhaul cases. The minimum SUA is already small enough.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 12:54
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 12:10:43 -0500

Gery,

Verwimp Gery wrote:                          (Wed, 19 Sep 2001 13:29:45)
> whether it is SCCP or SUA.

The problem also occurs in the coupled case under failure:

                         SG-A                                      
                       ________                                    
                      |        |                                   
                      |        |                                   
                 _____| STP/SG |XXX     SCTP                       
                /     |        |   X Association                   
               /      |________|    X                              
              /           |                                        
    _____    / A-link     |           X       _______              
   /     \  /             |            X     |       |             
  /       \/           C-links          XXXXX|       |             
  |  SEP  |               |              ____|  ASP  |             
  \       /\              |             /    |       |             
   \_____/  \  A-link     |            /     |_______|             
             \            |           /                            
              \        ___|____      /                             
               \      |        |    /   SCTP                       
                \_____|        |___/ Association                   
                      | STP/SG |                                   
                      |        |                                   
                      |________|                                   
                                                                   
                         SG-B                                      

In the coupled case where SG-A has made the coupling, if associations
are lost between the ASP and SG-A, SG-A has no choice but to route to
the ASP-PC over C-links.  SG-B will still get DT1/DT2 for a connection
for which it has no information.  Note that this does not cause any
problems in the equivalent SS7 case (that is 0 connections fail, not 50%).
So, quit thinking that this does not apply to the coupled case as well.

> wouldn't require registration anyway.

It is SUA (and other UA) approach to not specify NIF.  You can't have
your cake and eat it too here.  We are currently allowed to implement
as I described (no SCCP state machines at the ASP in backhaul case) and
the sufficiency of the SUA message syntax is referenced to and determined
on the basis of the N-primitive interface.  If not the N-primitive
interface, then what?  The SCCP peer PDU interface?

> to keep track of those, can you ?

Then put TUA back on the bill, as SCCP is incapable of supporting it.
That does not change the fact that SCCP connections need to be handled.

> peer-to-peer and backhaul cases. The minimum SUA is already small enough.

If we do not follow the SIGTRAN reference architecture and distinguish the
backhaul and peer cases there will be no basis for interoperability.
In the backhaul case SUA interworks with the SCCP/SCCP-User interface at
the SG.  In the peer case SUA *is* the SCCP/SCCP-User interface.  There
is quite a distinction.

--brian

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

---

---

From: [email-masked]
Date: Thu, 20 Sep 2001 10:01:21 +0300

Hi Brian,

> If we do not follow the SIGTRAN reference architecture and 
> distinguish the backhaul and peer cases there will be no basis for
> interoperability. In the backhaul case SUA interworks with the 
> SCCP/SCCP-User interface at the SG.  In the peer case SUA *is* the 
> SCCP/SCCP-User interface.  There is quite a distinction.

However, the ASP provides a SCCP-user interface to the application
running at the ASP.  As there is no SCCP-user at the SG, the 
SG does not need to provide support for it.

This is the case for M3UA as well.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 09:05:06 +0200

Last one on this too.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 19:11
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

                         SG-A                                      
                       ________                                    
                      |        |                                   
                      |        |                                   
                 _____| STP/SG |XXX     SCTP                       
                /     |        |   X Association                   
               /      |________|    X                              
              /           |                                        
                                                                   
                         SG-B                                      

[GV] : I never said the coupled case was all hunky-dory : of course if the
coupling SG goes down, the connection is lost. Simple as that. But to try
and make your decoupled case work like that (keeping state over several SGs)
... well good luck !

[GV] : No. SUA peer to peer interface. And you'd have SUA state machines
(also needed in your multiple SG solution for decoupled approach by the
way).

[GV] : Very deep sigh.

[GV] : Quit using the SIGTRAN reference architecture as an excuse for
messing up the protocol.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 03:39:22 -0500

John,

John Loughney wrote:                          (Thu, 20 Sep 2001 10:01:21)
> This is the case for M3UA as well.

Huh?  Neither SUA nor M3UA preclude an SCCP-User or MTP-User at the
SG.  Where did you get the idea that there was no SCCP/MTP-User at
the SG?

M3UA even states:

    1.3.2 Services Provided by the M3UA Layer

    The M3UA Layer at an ASP or IPSP provides the equivalent set of 
    primitives at its upper layer to the MTP3-Users as provided by the MTP 
    Level 3 to its local MTP3-Users at an SS7 SEP.  In this way, the ISUP 
    and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 
    services are offered remotely from an MTP3 Layer at an SGP, and not by 
    a local MTP3 layer.  The MTP3 layer at an SGP may also be unaware that 
    its local users are actually remote user parts over M3UA.  In effect, 
    the M3UA extends access to the MTP3 layer services to a remote IP-based 
    application.  The M3UA layer does not itself provide the MTP3 services.  
    However, in the case where an ASP is connected to more than one SGP, 
    the M3UA layer at an ASP should maintain the status of configured SS7 
    destinations and route messages according to the availability and 
    congestion status of the routes to these destinations via each SGP.

This is fundamental.  Neither M3UA nor SUA should provide MTP or SCCP
services.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 03:51:12 -0500

Gery,

Please see comments below...

Verwimp Gery wrote:                                       (Thu, 20 Sep 2001 09:05:06)
> Last one on this too.
[snip]
> > decoupled approach : the connection state must be kept at either
> > end-point, whether it is SCCP or SUA.
> 
> In the coupled case where SG-A has made the coupling, if associations are
> lost between the ASP and SG-A, SG-A has no choice but to route to the ASP-PC
> over C-links.  SG-B will still get DT1/DT2 for a connection for which it has
> no information.  Note that this does not cause any problems in the
> equivalent SS7 case (that is 0 connections fail, not 50%).  So, quit
> thinking that this does not apply to the coupled case as well.
> 
> [GV]: I never said the coupled case was all hunky-dory : of course if the

It's its as easy as keeping state between one ASP and one SG.

> > 
> > What you're saying is that SCCP at the SG keeps the connection data
> > (state, addresses) instead of SUA at the ASP (the endpoint where I think
> > it belongs). Furthermore, not only on this SG, but on all SGs the ASP can
> > communicate with. This opens a can of worms if you consider SCTP
> > association failures (does the SG consider the connection lost or not ?),
> > the inactivity test procedure for SCCP connections (what SG is
> > responsible; is it the one who lost connection to the ASP ?) a.s.o. just
> > to save a few lines of code at the ASP. The backhaul case you describe, I
> > fear can only work when SG and ASP work in unique cooperation (probably
> > same vendor of SG and ASP) which wouldn't require registration anyway.
> 
> It is SUA (and other UA) approach to not specify NIF.  You can't have your
> cake and eat it too here.  We are currently allowed to implement as I
> described (no SCCP state machines at the ASP in backhaul case) and the
> sufficiency of the SUA message syntax is referenced to and determined on the
> basis of the N-primitive interface.  If not the N-primitive interface, then
> what?  The SCCP peer PDU interface?
> 
> [GV]: No. SUA peer to peer interface. And you'd have SUA state machines

Nope.  I don't need SUA state machines.  The SCCP-User (AS) keeps track of
the interface state.  The SUA at the ASP just translates SCCP-User primities
into SUA messages.  Thats it.  No state machines.  The state machine is in
the SCCP at the SG.  The SCCP-User at the AS tracks that state.  Since when
did you think that a transport protocol got involved in the state of the
application being transported?

> Then put TUA back on the bill, as SCCP is incapable of supporting it.  That
> does not change the fact that SCCP connections need to be handled.
> 
> [GV]: Very deep sigh.

TUA would be easy to write as long as SUA can be made to handle connections
without breaking.

> backhaul and peer cases there will be no basis for interoperability.  In the
> backhaul case SUA interworks with the SCCP/SCCP-User interface at the SG.
> In the peer case SUA *is* the SCCP/SCCP-User interface.  There is quite a
> distinction.
> 
> [GV]: Quit using the SIGTRAN reference architecture as an excuse for messing
> up the protocol.

Quite trying to mess up the architecture and the protocol will be clean.

--brian

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

---

---

From: [email-masked]
Date: Thu, 20 Sep 2001 12:44:08 +0300

Hi Brian,

Let me reformat my original mail.

running at the ASP.  

In the IPSP to IPSP case, both M3UA & SUA are providing transport
of MTP3-user / SCCP-user messages.  

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 05:11:15 -0500

John,

John Loughney wrote:                                         (Thu, 20 Sep 2001 12:44:08)
> However, the ASP provides a SCCP-user interface to the application

Yes, but does not provide the SCCP services to this user directly.
Forcing SCCP state machines into the ASP will also force the ASP
to directly provide SCCP services.

> This is the case for M3UA as well.

It is also the case for M3UA that the ASP does not directly provide
MTP services and as such does not require MTP state machines.  (Some
routing is required in the multiple SG case.)

> of MTP3-user / SCCP-user messages.  

But again are not providing MTP or SCCP services directly within the
M3UA or SUA layers?  This goes back again to my original question:
Do M3UA IPSPs need to implement MTP state machines?  Do SUA IPSPs need
to implement SCCP state machines?  Do SUA messages exchanged between
IPSPs correspond to SCCP-User primitives?  Or do they correspond
to SCCP peer-to-peer messages (PDUs)?

The IPSP case is still very unclear.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 13:12:12 +0200

John,

I agree with you. We're not going to introduce an assymetric version of SUA
(SG as server, ASP as client) here. This is opening the door to a lot of
interworking problems.

The pure SG does not contain itself any SCCP-users (no TCAP, MAP, IN or
subscriber database there), only a routing database and the SCCP/SUA
interworking function.

The end-user is at the ASP. SUA on the ASP should therefor provide the
end-node functions (protocol class services) with a minimum of routing
facilities. SCCP/SUA on the SG has no end users, it only provides relay
functions (to relay messages received from ASP to SS7 and vice versa). SUA
is exactly like SCCP in this respect (end- and relay-node functions). So the
CO state machines belong on the ASP. And we're not forcing anyone to provide
CO services at the ASP, but if an ASP claims it does, these things are
required (nothing comes for free).

The SG mustn't be concerned with the states of connections/transactions
handled at the ASPs, and certainly not state distribution over several SGs
... TUA is not even a consideration.

MTP3/M3UA only provide a connectionless service; M3UA on the ASP needs the
minimum of transfer/routing functions as well to support it's users. The
"direct/indirect service" terminology is rather moot.

Of course the functionality required at SG and ASP is different, but in
essence it's UA <-> UA peer-to-peer communication.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 20 september 2001 12:11
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

John,

John Loughney wrote:                                         (Thu, 20 Sep
2001 12:44:08)

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 06:24:12 -0500

Gery,

Either a registration procedure is required or SUA can not attempt
to make an ASP appear to be in two places at once in the multiple
SG scenario.  Basically SUA makes the multiple SG configuration
unusable without registration (abhorent failure rates).

There is a simple (but equally undesirable) solution: do not permit
multiple SG with SUA.  If the operator wants multiple SG, use SCCP
over M3UA.  That will move all the SCCP state machines to the ASP.

--brian

Verwimp Gery wrote:                                       (Thu, 20 Sep 2001 13:12:12)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 13:47:21 +0200

Brian,

Exactly. Registration (dynamic or static) for TID and DRN within an AS is
required. You're also registering in your solution by the way, only it's
repeated for each started/ended connection/transaction. Imagine the traffic
overhead. It's obvious some registration/configuration is required, SS7
wouldn't work otherwise as well. And I don't want to introduce an abhorrent
self-regulating protocol.

What's your problem with SCCP CO state machines ? They're required for CO
mode of operation, so what else is new ? Provide them in SUA as well.

Your solution requires state machines on every SG with all risks of getting
them out of synch and headaches in case of routing failures. And with
multiple SGs, the ASP needs to keep track of available alternative routes
too. How you're going to do that without keeping state ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 20 september 2001 13:24
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

--brian

Verwimp Gery wrote:                                       (Thu, 20 Sep 2001
13:12:12)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 11:27:40 -0500

Gery,

Verwimp Gery wrote:                                       (Thu, 20 Sep 2001 13:47:21)
> self-regulating protocol.

You can always use M3UA if you want.

> mode of operation, so what else is new ? Provide them in SUA as well.

Because SUA need not provide SCCP services, it need only transport SCCP-User
primitives.

> too. How you're going to do that without keeping state ?

State is kept on the SG, but not in SUA, in SCCP.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 21 Sep 2001 09:18:40 +0200

Brian,

See also mails on M3UA/SUA IPSP. Seems to me you're forcing SUA to act as
SCCP-user on the SG.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 20 september 2001 18:28
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

13:47:21)

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Sep 2001 03:10:49 -0500

Gery,

No forcing: permitting.

--brian

Verwimp Gery wrote:                                       (Fri, 21 Sep 2001 09:18:40)
> Fax: +32 14 25 3212
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 21 Sep 2001 10:44:35 +0200

Ok, I propose to quit the philosophies for now and see what we have to do in
SUA :

1) RK parameter proposal for TID/DRN label : permits SG to distribute TCAP
and SCCP CO traffic to the correct ASP without keeping state (just store the
distribution table for the AS). The ASP registers this per AS to each
connected SG.

For CO without association of connection sections, the RK cannot be SSN
specific (DT1 does not contain SSN); the AS must be found based on incoming
linkset (NetApp), OPC, DPC, CO-traffic parameters only. This also implies
the CO state/event machines are implemented on the ASP itself (in SUA).

2) On the fly (de)registration of TID/DRN to each (alternative) SG (although
for TID I don't see the need, since the state/event machines for TCAP
transactions have to be on the ASP anyway).

This implies CO state/event is kept at (each?) SG instead of the ASP.

Some questions :
- dynamical overhead for sending (de)registration messages for each
started/released connection (unless you would also work with a label ?)
- keeping states in synch over the SGs in case of routing/association
failure. It seems to me that although the SUA on ASP doesn't keep state, it
would have to 
	1) assign a connectionID (reference number)
	2) remember sending deregs to a SG when the association was
temporarily lost
	3) when the association is lost, it's hard to tell whether it's due
to an IP/SCTP routing failure or to SG outage. In each case, you would have
the REG procedures (static/dynamic) kick in, fixing case1). Case2) would
have a hard time to decide whether the connection is lost (Inactivity Test
(IT) is only performed in SCCP on the SG, since SUA on ASP doesn't keep
state; IT is not part of the SCCP-user interface).

Clearly, I prefer 1) but go ahead if you like 2).

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 21 september 2001 10:11
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

No forcing: permitting.

--brian

Verwimp Gery wrote:                                       (Fri, 21 Sep 2001
09:18:40)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Sep 2001 04:43:33 -0500

Gery,

Why all the fuss?  All the draft need say is that the ASP may
register with an SG using the messages provided.

--brian

Verwimp Gery wrote:                                       (Fri, 21 Sep 2001 10:44:35)
> SUA:

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 21 Sep 2001 11:44:50 +0200

Brian,

Same thing for my proposal ;)

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 21 september 2001 11:44
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

--brian

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Sep 2001 04:52:48 -0500

Gery,

Are we agreed then?

> All the draft need say is that the ASP may register
> with an SG using the messages provided.

--brian

Verwimp Gery wrote:                                       (Fri, 21 Sep 2001 11:44:50)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 21 Sep 2001 11:59:39 +0200

If John L. is ok with putting both options in the SUA draft, no problem !

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 21 september 2001 11:53
To: sigtran
Subject: Re: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

Are we agreed then?

--brian

11:44:50)

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

---

---

---

From: [email-masked]
Date: Tue, 25 Sep 2001 16:10:34 +0300

Gery,

> If John L. is ok with putting both options in the SUA draft, 

I think that both options would be a bad idea.  I think we
need to stick with one.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 25 Sep 2001 16:14:47 +0200

Hi John,

We at least need a simple mechanism to allow SG distribution of TCAP or SCCP
CO messages to the correct ASP.

Therefor, I repeat my proposed parameter, to be included optionally in the
ASPAC (TID and DRN stuff doesn't belong in the REG procedures) :

TID-label

DRN-label

This allows the SG to build up/update his distribution table for a certain
RC, any time the association is established and/or the ASP goes active. The
SG has to perform some trivial plausibility checks :

- start, end between 0 and 31 (between 0 and 23 for DRN with decoupled
approach)
- 0 < (start - end + 1) <= 16 (label maximum 16-bit)
- start/end values are the same for each ASP which goes active for this RC
- TID resp. DRN label values must be different for each ASP

If any of these checks fail, the ASP cannot go active (neg ack with error
"invalid label"). It is clear from RC (CL, CO or both) which labels must be
present. If it is not required for the SG to perform distribution, no labels
are present in any ASPAC for this RC.

If an ASP is not available, the SG may generate (X)UDTS "routing failure",
if CL with return option is used. For CO, either IT or flow control
procedures are adequate; SG simply has to discard the message.

Brian's proposal needs further study, because it is unclear (not only to
me), what effects this has (synchronization between SGs, reaction to
routing/association/node failures) ??

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 25 september 2001 15:11
To: sigtran
Subject: RE: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

John

---

---