Subject: SUAv7: Global Title Translation Query

From: [email-masked]
Date: Mon, 13 Aug 2001 20:31:39 +0530

Hi ,

I have some queries about Global Title Translation in SUA.

1. Global Title Indicator:
GTI is present as an element in Called and Calling party address parameters of
SCCP , but is not present in Source and Destination Address parameters of SUA. I
saw the same was changed between version 4 and version 5 of SUA, but could not
locate the reason for change.
Can somebody please explain (or refer me to the related thread) why GTI was
removed from Source/Destination Address parameter. Can't there be two
applications that use the same Network ID but still uses different GTI ?

2. Routing on Hostname
a) In RI == Hostname , SSN is optional . Does it means resolution of Hostname
should result into IP address + SSN ?
b)'From section 1.5.3
Routing on Hostname: SCTP association ID towards next relay node, (new) Hostname
and optionally SSN and/or Routing Context.' Does it mean resolution of Hostname
can result in IP address of next node and a new Hostname ?
We were thinking of using existing DNS mechanisms for Hostname resolution , but
considering above two requirements it does not look possible. Please comment ??

Best Regards,
-Sandeep

---
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: Mon, 13 Aug 2001 19:33:18 -0500

Sandeep,

Please see comments below...

[email-masked] wrote:                            (Mon, 13 Aug 2001 20:31:39)
> applications that use the same Network ID but still uses different GTI ?

SUA has normalized the GTI types into a single mega-type which includes all
the pieces from all GTI types.  I don't know how valid this approach is (its
will cause problems if one comes up with a new GTI type which includes
sub-fields not present in the current types).

Unused sub-fields are coded as described on the bottom of Page 58 of SUAv7.

This may not be the best approach but is it sufficient for the time being.

> considering above two requirements it does not look possible. Please comment ??

IMHO Hostname and SSN+IP are useless.  Making an SS7 network out of an IP
network is a ridiculous concept at any level above M2PA.  Neither Hostname
nor IP+SSN are described in any usable fashion: since when does an IP address
have an SSN?  What protocol is this?  Not SUA.  Not SS7.  Where were you going
to relay these messages once you "resolved" them?

--brian

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

---

---

From: [email-masked]
Date: Thu, 16 Aug 2001 17:46:57 +0530

Brian ,

Please see comments below ...

"Brian F. G. Bidulock" <[email-masked]> on 08/14/2001 07:03:18 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  Re: SUAv7: Global Title Translation Query

Sandeep,

[email-masked] wrote:                            (Mon, 13 Aug 2001
20:31:39)

Sandeep >> Having a single meta message type for Global Title is OK. But list of
valid GT elements in a message is extracted from parameter network ID. Although
Network Id is not defined within SUA, I am assuming it is related to type of SS7
network (??). In SS7 networks, applications select GTI values and it is allowed
for applications using the same SS7 network to choose two different GTI values
for 2 different messages. So relating GTI with type of SS7 network will be
restrictive for some applications.

Sandeep >> Some details added here will be of great help.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 11:48:25 -0500

Sandeep,

[email-masked] wrote:                            (Thu, 16 Aug 2001 17:46:57)
[snip]
> restrictive for some applications.

I agree that NI is defined to permit different SCCP GTs in the same network,
but I do not know of an instance where it is used (or even implemented).
Do you know of such an instance where it is used?  Also, it is possible to
arrange your routing keys and contexts in such a fashion so that the NI in
the GT is implicit or can be derived from RC, so even though the multiple
NI case is not explicitly provided for, it could still be accomplished in
SUA for some corner-case that needs it.

[snip]
> Sandeep >> Some details added here will be of great help.

If you are meaning details added to the draft, I agree.  But it has
already been raised as an issue for Last Call to clarify the IPSP
case.

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 21:01:32 +0530

Brian ,

Comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/16/2001 11:18:25 PM

Sandeep,

[email-masked] wrote:                            (Thu, 16 Aug 2001
17:46:57)
[snip]

I agree that NI is defined to permit different SCCP GTs in the same network,
but I do not know of an instance where it is used (or even implemented).
Do you know of such an instance where it is used?

Sandeep >> My simple network is of three nodes A , B and C. My simple
application is a GSM VLR, sitting at Node A.
There is a request for location update for two suscribers one local and one
using international roaming. For the first subscriber  HLR is residing on Node
C. Since it is on my local network I want to use GTI == 3 for this messge
delivery  For Second subscriber HLR is in some other network accessible via Node
C. Since it an international GTT case I want to use GTI == 4 and TT ==3 for this
message. So on the same network path I need GTI == 3 for one message and GTI== 4
for other. Do I make any sense ??

Also, it is possible to

[snip]

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:31:24 -0500

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001 21:01:32)
[snip]
> for other. Do I make any sense ??

I don't follow you.  (And this is one of my applications as well by the way.)
As far as I look at it the SCCP-User consists of multiple AS in this case:
one TCAP/SCCP-User interface (AS) is for the national network, another
TCAP/SCCP-User interface (AS) is for the international network.  The
application chooses the national TCAP/SCCP-User interface when it wishes to
launch national TCAP messages, and, the international when it wishes to
launch international TCAP messages.  They are two different subsystems from
the point of view of the network.  The SG determines which NI value to
apply when coding the SCCP message on the basis of which SCCP-User is sending
the message.  This is in fitting with the following statement:

> > Also, it is possible to arrange your routing keys and contexts in such a
> > fashion so that the NI in the GT is implicit or can be derived from RC, so
> > even though the multiple NI case is not explicitly provided for, it could
> > still be accomplished in SUA for some corner-case that needs it.

I would go father to say that because SCCP-Users are determined by PC+SSN,
that NI is implicit in the definition of an SCCP-User.  This is why you
do not see NI as part of the SCCP-User primitive interface, nor is it a
part of the TCAP (TC/TR) primitive interface.  The appropriate NI is implied
by the SAP of the interface (which in SIGTRAN's case may be determined from
the RC).  Network Appearance (== Network Id) is one of the parameters which
is provided in the SUA dynamic registration proposal, so that it can be
associated with the AS at the time that the RC value is assigned.  Therefore,
the NI value is an AS attribute and is implicit in every message labelled
with an RC.  (Another reason why CODT and the others you listed in another
e-mail still need RC and cannot rely on DLR.)

--brian

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

---

---

From: [email-masked]
Date: Tue, 21 Aug 2001 13:28:37 +0300

Hi Brian,

I agree with your points.  My proposal is not to modify the
SUA document with regards to this matter (except for the 
IPSP Issue you have raised).

I think this matter relates to how you use the protocol,
and isn't really applicable to the protocol itself.

There is a UA Applicability Statement draft - perhaps it
is time to collect issues for that.  This could be one.

John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 20 August, 2001 19:31
> To: sigtran
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 15:41:29 +0200

Hello Sandeep,

I don't see the issue here : both SCCP GTT and SUA AMF will select the
appropriate translator based on NI, GTI, TT, ... info. Once the translator
is found, the digits determine the destination : either local HLR or HLR
from another network. What additional functionality would you need from SUA
?

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: maandag 20 augustus 2001 18:31
To: sigtran
Subject: Re: SUAv7: Global Title Translation Query

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001
21:01:32)
[snip]
> for other. Do I make any sense ??

I don't follow you.  (And this is one of my applications as well by the
way.)
As far as I look at it the SCCP-User consists of multiple AS in this case:
one TCAP/SCCP-User interface (AS) is for the national network, another
TCAP/SCCP-User interface (AS) is for the international network.  The
application chooses the national TCAP/SCCP-User interface when it wishes to
launch national TCAP messages, and, the international when it wishes to
launch international TCAP messages.  They are two different subsystems from
the point of view of the network.  The SG determines which NI value to
apply when coding the SCCP message on the basis of which SCCP-User is
sending

associated with the AS at the time that the RC value is assigned.
Therefore,

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

---

---

From: [email-masked]
Date: Wed, 22 Aug 2001 19:24:23 +0530

Hello Gery,

GTI is not present in Global Title parameter message format (section 3.9.2.3)
and is linked with network ID. I think GTI should be present in each message and
should not be linked with network ID.

Best Regards,
Sandeep

Verwimp Gery <[email-masked]> on 08/22/2001 08:11:29 PM

Subject:  RE: SUAv7: Global Title Translation Query

Hello Sandeep,

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 20 augustus 2001 18:31
To: sigtran
Subject: Re: SUAv7: Global Title Translation Query

Sandeep,

[snip]

--brian

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

---

---

---

---

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

Hi Sandeep,

The format presented in 3.9.2.3 is generic. But I see your point. The
question is do we have to take over the problems related to these different
GT formats in SUA as well ?

For the scenario you described (location update local/roaming) choosing a
different GTI seems very tricky to me (e.g. what if the mobile subscriber is
ported ?) Normally, if you want different SCCP routing for the same address
information, you'd use a different TT or a different NoA to distinguish
national/international significant number.

But ok, it's in the Q.714 (a.o. chapters 2.4.2.1 item 4) and 2.4.3.2)
together with "encoding scheme" (which plays a specific role in case of
"generic numbering plan"). I see 2 possibilities :

1) either add an optional address parameter containing GTI and ES
2) agree on the GTI an ES to be used per Routing Context, so the RC implies
GTI and ES used in these specific cases.

Any thoughts ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 22 augustus 2001 15:54
To: sigtran
Subject: RE: SUAv7: Global Title Translation Query

Hello Gery,

GTI is not present in Global Title parameter message format (section
3.9.2.3)
and is linked with network ID. I think GTI should be present in each message
and
should not be linked with network ID.

Best Regards,
Sandeep

Hello Sandeep,

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 20 augustus 2001 18:31
To: sigtran
Subject: Re: SUAv7: Global Title Translation Query

Sandeep,

[snip]

--brian

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

---

---

---

---

---

From: [email-masked]
Date: Fri, 24 Aug 2001 09:49:51 +0530

resending ...
---------------------- Forwarded by Sandeep Mahajan/HSS on 08/24/2001 12:07 PM
---------------------------

Sandeep Mahajan
08/23/2001 01:23 PM

To:   [email-masked]
cc:

Subject:  RE: SUAv7: Global Title Translation Query  (Document link not
      converted)

Hi Gery,

Please see  my comments below  ..

Best Regards,
-Sandeep

Verwimp Gery <[email-masked]> on 08/22/2001 09:40:41 PM

Hi Sandeep,

Sandeep >> I was trying to put the point , that there can be cases when SCCP
messages pass through the same set of intermediate nodes and use different GTI
formats. These messages can be generated by a single or different SCCP Users on
any of these nodes. GT format can also be changed as a result of GT translation
of these messages on any of these nodes. So forcing to use a single GTI format
be used in one Network Id can be restrictive for some applications,

Sandeep >> I agree with this approach ..

Sandeep >> In my views this will be putting restrictions on the definition of
AS. If my definition of AS is one DPC, Applications will be forced to use same
GTI for all messages to that DPC. In all IP case , where this DPC corresponds to
AS (hence the route) to reach to next node , all messages passing through this
route will be forced to have a particular GTI.

Any thoughts ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 22 augustus 2001 15:54
To: sigtran
Subject: RE: SUAv7: Global Title Translation Query

Hello Gery,

Best Regards,
Sandeep

Hello Sandeep,

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 20 augustus 2001 18:31
To: sigtran
Subject: Re: SUAv7: Global Title Translation Query

Sandeep,

[snip]

--brian

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

---

---

---

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 02:02:55 -0500

Gery,

Verwimp Gery wrote:                                (Wed, 22 Aug 2001 17:10:41)
> GT formats in SUA as well ?

There is not need for GTI in SUA:

  GTI = 0001 <=> NAI=nai, TT=0,  NPLAN=0,     ES=0,   ADDR in BCD
  GTI = 0010 <=> NAI=0,   TT=tt, NPLAN=0,     ES=0,   ADDR in BCD
  GTI = 0011 <=> NAI=0,   TT=tt, NPLAN=nplan, ES=BCD, ADDR in BCD
  GTI = 0100 <=> NAI=nai, TT=tt, NPLAN=nplan, ES=BCS, ADDR in BCD

There is no format specified for GT in the SCCP/SCCP-User interface.

There are several ways to represent simple address even in the SCCP PDU.
Even an SCCP implementation would be foolish to route based on the GTI
alone, GTI just makes the GT more compact for some codings.

> "generic numbering plan"). I see 2 possibilities :

SUA need not be based on the SCCP PDU, all that is required is that
the aguments of the SCCP Primitives be available and any information
necessary to support the SCCP/SCCP-User interface.  Regardless of
how GT is formated in SCCP PDUs, how it is passed back and forth to
the SCCP-User is important.  Because SCCP does not specify the format
of the Calling or Called Party Address in the N-UNITDATA or N-CONNECT
primitives, it is implementation dependent.  The Source and Destination
Address formats in SUA have all the information necessary for both
the SGP and the ASP to format either an SCCP PDU or a N-UNITDATA or
N-CONNECT primitive.

> GTI and ES used in these specific cases.

Neither of these approaches are required.  The GTI is implicit in the
coding of the NAI, TT and NPLAN values in the SUA Source and Destination
Addresses as shown above.

--brian

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

---

---

From: [email-masked]
Date: Fri, 24 Aug 2001 10:30:00 +0300

Hi Brian,

I agree with your conclusion.  I do not see this as an open issue.

John

> coding of the NAI, TT and NPLAN values in the SUA Source and 
> Destination Addresses as shown above.

---

---

From: [email-masked]
Date: Sat, 25 Aug 2001 14:32:59 +0530

Brian ,

Current SUA text relates GTI value with network Id (Definition of Network Id is
also missing in SUA).  I disagree with this approach as different messages on
the same network Id can use different GTI formats.

You are suggesting that there is no need of GTI in the message format because
the same is implied in the coding of the NAI, TT and NPLAN .   Is the intention
here is to save some bits in the message ?  I think both for interworking with
SS7 network and for using existing Global Title Translation functions it will be
much simpler and cleaner if we include GTI in the message format.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/24/2001 01:32:55 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Sandeep Mahajan/HSS)

Gery,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 25 Aug 2001 11:54:26 -0500

Sandeep,

For SUA, because GTI formats are normalized, GTI is not required in
SUA message.

Because there are no differences in GTI formats between national
and international the important distinction for SCCP-Users and
thus SUA is in the NAI.  NI bits are not required.

--brian

[email-masked] wrote:                 (Sat, 25 Aug 2001 14:32:59)
> You are currently subscribed to sigtran as: [email-masked]

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

---