Subject: RE: [SUA issue 17] IPSP cases.

From: Verwimp Gery <[email-masked]>
Date: Tue, 28 Aug 2001 14:56:32 +0200

Brian,

The for SUA somewhat artificial distinction between "peer-to-peer" and
"backhaul" case is something I'd like to avoid. This kind of modelling
creates more problems than it can clarify.

For SUA on the IPSP, it seems as if he is talking to his peer on the SGP. Of
course, since interworking with SS7 is going on, the address formats are
limited to SPC or GT plus SSN, but this is specified by routing context.
There is no difference in the basic SUA procedures for these cases. Also,
the SSNM messages (the only thing specific to SS7 interworking I could find)
can also be extended (the hooks are there) to pure all-IP environment by use
of the "extended" SUA address parameter.

In this respect, I think it is very useful to already provide in the base
protocol the hooks for an all-IP environment. Further procedures (extended
use of SSNM messages was something I already provided some time ago) for
these scenario's and their use can be part of an extension document. And
frankly, the only thing that is "extended" right now is the possible address
formats that can be used; this is hardly a new protocol invention.

The big mistery around AMF is rather trivial : it is in essence a GTT
function, which happens to be able to handle (but not necessarily so) more
address formats than the GTT can. But in essence, the same procedures as in
SCCP apply (relay function, hop counter, valid input/output). In that
respect, an IPSP can be SUA endpoint (the actual user is there) or SUA relay
point (the AMF needs to be invoked to forward the message over the next SCTP
association towards the destination).

Imagine a 3G UMTS network completely based on SCTP/IP, which uses SUA
throughout to transport SCCP-user (MAP, INAP, CCBS, etc.) messages.
Interworking between 3G operators will very likely be run over such SUA
relay points, deploying the AMF for the GTT currently executed in the mobile
SS7 networks nowadays. In a next step, UMTS services can be made using
hostnames instead of GTs as addresses.

As far as the COERR message is concerned, this has the same functionality as
the SCCP ERR message, within the scope of an SCCP connection. If you don't
know what DPC/destination it is intended for, the you also wouldn't know for
what destination the CODT or whatever other CO message is intended. The
COERR, just like the other CO messages (except CORE), contains a DRN
(destination reference number) and when required also the RC parameter. No
backhaul/peer-to-peer mystery here either.

Best 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 28 augustus 2001 12:18
To: sigtran
Subject: Re: [SUA issue 17] IPSP cases.

John,

Now you've really confused me with the COERR message.  What primitive
does that correspond to in the backhaul case?

What I'm wondering is this: there is a whole range of ways of
implementing IPSP operation, many of which will not interoperate.
Consider the two extremes: a backhaul approach and a peer approach.

The backhaul approach has one IPSP acting as SGP and the other acting as
ASP as follows:

                 IPSP (SGP)                       IPSP (ASP)
        ________  __________________                ________
       |  SCCP  ||                  |              |  SCCP  |
       |  User  ||     NIF/AMF      |              |  User  |
       |________||__________________|              |________|
       |        ||        ||        |              |        |
       |  SCCP  ||  SCCP  ||  SUA   |              |  SUA   |
       |________||________||________|              |________|
       |        ||        ||        |              |        |
       |  MTP   ||  MTP   ||  SCTP  |              |  SCTP  |
       |________||________||________|              |________|
           |         |          |                       |    
           |_________|          |_______________________|    

In this arrangement SUA messages correspond to SCCP/SCCP-User primitives
and SCCP state machines are contained completely at the IPSP in the role
of SGP.

The peer approach has each IPSP acting as a peer to the other (at least
for SUA messages, not ASPSM or ASPTM) as follows:

                   IPSP                    IPSP
                 ________                ________
                |  SCCP  |              |  SCCP  |
                |  User  |              |  User  |
                |________|              |________|
                |        |              |        |
                |  SCCP  |              |  SCCP  |
                |________|              |________|
                |        |              |        |
                |  SUA   |              |  SUA   |
                |________|              |________|
                |        |              |        |
                |  SCTP  |              |  SCTP  |
                |________|              |________|
                     |                      |
                     |______________________|

In this arrangement SUA messages correspond to SCCP (and MTP) PDUs and a
full SCCP (and possibly MTP) state machine is provided at each IPSP.
Where does the AMF sit here?

There is a spectrum between these two as SCCP (and MTP) state machine
functionality is moved from one IPSP to the other.

For the first case, where SUA messages map to SCCP primitives, it is
clear that all of the information needed is present in the messages
because the information is present for the normal backhaul
configuration.

For the later case, where SUA messages map to SCCP (and MTP) peer to
peer PDUs, there is obviously some information missing: the OPC, DPC and
SLS would need to be included in all messages.  All optional parameters
of the equivalent SCCP PDUs would need to be included in the
corresponding SUA messages.  So it doesn't appear as though this later
case (peer-to-peer) is really supported.

So, which is it?  What range between the two?  How is the one
implementation to know what SCCP state machine functionality is
peer-to-peer and what is backhaul?

Now, the reason that COERR confuses me is that there is no corresponding
N-Primitive, so it is useless for backhaul, but it lacks OPC, DPC and
SLS so how can it represent a peer PDU?  When the receiving SCCP state
machine receives a COERR message, how does it know who sent it?  In the
normal SCCP state machine, the SCCP state machine has the OPC of the
message to determine that the sender of the message is indeed the one to
which it has a connection as indicated in the DRN.  Otherwise, this may
be a stray COERR message relating to a DRN which was closed some time
ago but which was to another OPC.  Where an IPSP supports multiple alias
point codes, how is the receiving SCCP state machine supposed to know
which DPC the COERR message is for?  The normal SCCP state machine has
the DPC from the MTP to indicate the destination.  RC might resolve this
*iff* there was a restriction that an RC could not span multiple point
codes in SUA, but there is no such restriction.

So, I can see that if the backhaul approach is used for IPSP (where one
acts as SGP, the other as ASP, and the one acting as SGP has all the SS7
state machines) things are possible.

If the peer approach is used for IPSP (where each IPSP acts as a
complete peer) that there is too much information missing in the SUA
messages for the SCCP state machines at the IPSP to do its job.

The only possibility is either the backhaul approach or some poorly
defined grey area in between, or the spec needs a lot of updating of
message information for SUA messages exchanged as peer messages.

Which is it?

--brian

John Loughney wrote:                                         (Tue, 28 Aug
2001 12:10:56)
> Hi Brian,
> 
> > Which IPSP sends APSUP?  
> 
> Which ever one wants to.
> 
> > What happens if both IPSPs sends ASPUP?
> 
> Then you may get 2 SUA 'associations' - if this is
> being done within a single operator network, it can
> be handled as a network management issue.  
> 
> > When one IPSP sends ASPAC for an RC does it activate it for both
> > IPSPs?  Or, does the other IPSP need to send ASPAC as well?  
> 
> I have always thought it is then active for both.  By accepting
> the ASPAC, the recieving IPSP is implicitly accepting the RC.
> 
> > When CO messages are exchanged, how does the receiving IPSP indicate
> > protocol specific error conditions to the other IPSP?  (i.e, those
> > which are provided peer-to-peer by the ER message in SCCP?).
> 
> COERR message.
> 
> > Is there any coupling of connection sections between IPSP?  
> 
> I haven't seen a requirement for coupling of connection sections.
> 
> > Does an IPSP ever act as a relay point?  As an SCCP relay?  As an MTP
> > relay?  
> 
> As per SUA v7, no.  The SUA relay has not been well defined, as I 
> understand it was something that Gery supported & we agreed that 
> we should allow it, but not detail how it can be used.  Its use
> could be specified in an extension draft.  It does not act as
> an SCCP relay nor an MTP relay.
> 
> > What is the role of the AMF for IPSPs?  Does the AMF sit
> > above or below the SCCP/SCCP-User interface?  
> 
> Below the use interface.  AMF is a function that SUA can use,
> is somewhat analagous to GTT.  
> 
> > Does an IPSP provide an SCCP/SCCP-User interface to local SCCP-Users?  
> 
> Yes, just as an ASP would.
> 
> > Does an IPSP need to support multipled associations and multiple 
> > routing contexts between IPSPs?  
> 
> No, but it may.  Implementation specific.
> 
> > What parts of the SCCP state machines must be implemented at the 
> > IPSP?  
> 
> Enough to ensure proper working of the IPSP.
> 
> > Can an SG be both an SGP and an IPSP?
> 
> Anything is possible, but I probably wouldn't recommend this 
> kind of configuration.  
>  
> ====
> 
> Some things that I think could be better specified:
> 
> IPSP -> provides a user interface.  Does not provide relay functionality
> 
> SUA Relay Point -> does not provide a user interface. Does provide relay
> functionality.
> 
> 
> John

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

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

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