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

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 10:17:52 +0200

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.

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

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

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

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

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