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

From: "Gradischnig, Klaus" <[email-masked]>
Date: Wed, 29 Aug 2001 16:00:22 -0500

Gery,

I second that - specially the first 2 sentences.

Klaus

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: August 28, 2001 8:57 AM
> To: sigtran
> Subject: RE: [SUA issue 17] IPSP cases.
> 
> 
> 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]
> 

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