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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 15:05:34 -0500

Verwimp,

Verwimp Gery wrote:                                       (Wed, 29 Aug 2001 10:17:52)
> Brian,
> 
> Answers below (of course) ...
> 
> -Gery
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: dinsdag 28 augustus 2001 21:21
> To: sigtran
> Subject: Re: [SUA issue 17] IPSP cases.
> 
> 
> Gery,
> 
> Verwimp Gery wrote:                                       (Tue, 28 Aug 2001
> 14:56:32)
> > 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.
> 
> I'm sorry you feel that way.  You must hate the SIGTRAN AS ;)
> 
> [GV]: I just hate the distinction peer-to-peer vs. backhaul; seems like 2
> different protocols ;)
> 
> An interoperable implementation needs to know which state machines
> to expect at the other end.  Providing for all the cases between the
> extremes I present is not feasible.
> 
> [GV]: What differences in state machines you have in mind ? CL and CO are
> the same. Even SCCP management procedures can be taken over : it comes down
> to knowing who the affected destination is (PC vs. IPaddress; PC + SSN vs.
> IPaddress + RC). The SCTP association over which the message was received
> identifies the neighbour.
> 
> > For SUA on the IPSP, it seems as if he is talking to his peer on the SGP.
> 
> What SGP?
> 
> [GV]: the SGP in your diagram.

I have a problem with a symetrical model where both IPSPs attempt to both
be ASPs an SGPs.  Are you suggesting an IPSP as SGP and IPSP as ASP approach?

> 
> > 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.
> 
> I can handle extended address parameters if they are defined and
> their use is described.  In the current draft they are lacking in
> both categories.
> 
> [GV]: Their definition is given in the address parameter section. We also
> defined valid address formats (maybe there's still some errors there). Also,
> the SCCP doesn't define the use of addresses; it only gives some hints in
> the user guide. Don't you think this is Appl. Stat. material ? In the end
> it's up to the applications which address formats they're gonna use.

I still think that address parameters which have no definitive use in
SUA which only needs to transport SCCP are a waste of text and are
clearly the stuff of experimentation or extension drafts.

> > 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).
> 
> But is it going in a peer sense or in an ASP/SGP sense?
> 
> (John says that SUA relay is not explicitly provided for.  Which is it?)
> 
> [GV]: SUA relay is explicitly provided for, through use of the AMF. As such
> it can be present (it's not a mandatory feature; GTT isn't either) on
> IPSP/ASP/SGP or whatever platform running SUA. This is my beef with
> peer-to-peer/backhaul. In my view, backhaul is very limited : you have the
> SG doing GTT (if even that) and the SCCP-user is sitting on the ASP, which
> doesn't have any AMF.

SUA relay in an all IP domain is completely unnecessary.  The purpose of
SIGTRAN is to transport SCCP over IP.  Relay is not required for transport.
IP routers peform relay quite nicely and SCTP associations can be formed
from host to host without the need for an intervening SUA relay function.
SUA relay is not a user function: as such is is not needed for SCCP end
to end transport.  There is no point in describing it nor permitting it.

> > 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.
> 
> Neither my imagination nor yours is a basis for interoperability in
> of themselves.  It this is the intended use, describe it in the
> draft and provide a basis for interoperability between
> implementations.
> 
> [GV]: Again, this is AS material; 3GPP already provided a feasability study
> on the use of SUA. The draft shouldn't tell them how to build their UMTS
> networks.
> We can only state that routing on GT or hostname requires the AMF
> functionality in SUA.

When 3GPP decides how they want to extend SUA, they are welcome to write
an extension draft.  The SIGTRAN charter consists of signalling transport,
not the invention of new signalling protocols.  Are you proposing that
the SIGTRAN charter be extended to include the creation of new signalling
protocols?

> 
> > 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.
> 
> RC is only sufficient where not allowed to span DPCs.  Please add
> the restriction to the draft that RC is not permitted to span DPC,
> whether they be alias PCs or not.  You did not address the OPC of
> the COERR.  There is nothing stopping an SCCP today from assigning
> SLR on the basis of OPC/DPC pairs instead of just DPC.  In these
> situations DLR does not determine the OPC of the message and cannot
> be used in conjunction with DPC alone to determine the connection
> identification.  In these SCCP conforming implementations, OPC/DPC
> and DLR are required to identify the connection.
> 
> [GV]: I fail to see what this has to do with the COERR in particular. Just
> like the CODT message, it is populated with DLR (no SLR) and optionally RC
> for the decoupled case. COERR is intended within the scope of a connection,
> not an entire PC.

Unfortunately it is used in a large number of cases where there is no
connection.  Then it is used by state machines at the PC level.  This
is a difference between the peer case and the user case.  The user
has an implicit connection identification, the peer does not necessarily
have the referenced connection.  The user need only interact within the
context of the connection, the peer must interact also within the context
of a peer to peer relationship which is outside of any given connection.

ERR is used in the scope of an entire PC.  Whan a SCCP receives any message
for a non-existent DLR, it replies with an ERR message within the context
of the entire PC.

This is just one very narrow slice of what I point out as state machines
which are present in SCCP for the back-haul (user) case which must be
placed somewhere for the peer case.

Where does all the services that SCCP provides to its users go for the
peer case?  If it is expected that SCCP state machines provide those
services, one might as well transport SCCP PDUs with M3UA than try to
force SUA messages to transparently provide all the information of an MSU.

--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]