Subject: [SUA Issue 27]: Hostname as Routing Parameter

From: [email-masked]
Date: Fri, 24 Aug 2001 14:47:58 +0300

Hi all,

There has been a request to address usage of hostname as a routing
parameter.  See attached message.

John

> a) In Roting Indicator == 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 ?
>
> Considering above two requirements existing DNS mechanism can
> not be used for resolving hostname. What scheme SUA proposes/recommends
> for resolving hostname present in SUA source/destination address parameter
?

These I consider to be implementation dependent.  DNS is not promoted
as the way to handle resolution, but as an example.

Sandeep >> This is a bad example then, DNS CAN'T be used in this case. There
is
no existing Resource Record (RR) TYPE that can be used in DNS query and
response. If SUA suggests an extension in DNS (a new RR TYPE or something
else)
, it should be clearly stated.

Please note that IUA, M2UA, M3UA do not explain how to get from
the SS7 address to the IP address, except through local mechanisms.

I think the most I could do is to clarify that DNS is a mechanism
that can be used, but there are others.

Sandeep >> I disagree with the proposal of using hostname as listed above.
Hostname had always been used as an alias to IP address(s) and lets keep it
like
that. If we need some logical number/string that after resolution  yields
a) SUA/SCCP User (IP addr + SSN, DPC + SSN)
b) IP addr of next node + New Hostname + SSN (optional)
This logical number/string is not hostname and I suggest we do not use terms
"hostname" and "DNS".

Local configurations can be used to get above desired results, but then how
is
it different from GTT.

best regards,
John

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

---

From: [email-masked]
Date: Mon, 27 Aug 2001 10:00:02 +0300

Hi Brian,

[clip]

> I think the Sandeep's "New Hostname" could maybe include URL.
> Using, for example, and ENUM URL makes more sense perhaps than just
> a Hostname.

This has been suggested - perhaps if I replace 'hostname' with
URL, that could be good.

> If we want to leave Hostname and IP address (would that be IPv4 or
> IPv6 or both?) as place-holders in the Address format, there is no
> real problem with that.  Their use, however, should be reserved for
> an extension draft and clearly stated (I believe that is already is)
> that SCCP-Users do not use these parameters.

I'd prefer this.  

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 27 Aug 2001 02:40:33 -0500

John,

John Loughney wrote:                              (Mon, 27 Aug 2001 10:00:02)
> > that SCCP-Users do not use these parameters.

Would this do? -- spinning a little text into the intro or parameter
descriptions to the effect that the use of hostname (or URL) as a routing
parameter is not necessary to the SCCP-User and will be described elsewhere.

--brian

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

---

---

From: [email-masked]
Date: Mon, 27 Aug 2001 10:47:58 +0300

Hi Brian,

> descriptions to the effect that the use of hostname (or URL) 
> as a routing parameter is not necessary to the SCCP-User and will be 
> described elsewhere.

Exactly.  My intention is that an SUA-user (as opposed to an SCCP-user)
could define how to use this and the protocol would/could support
this.  There are some 3G-users of SUA that could benefit from this.
The burden would be for these SUA-users to say how they would use
them.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 27 Aug 2001 02:52:37 -0500

John,

I'll leave it in your capable hands to figure out just how to
say that in the draft.

--brian

John Loughney wrote:                              (Mon, 27 Aug 2001 10:47:58)

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

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Mon, 27 Aug 2001 06:00:31 -0500

John, Brian:

this is a good apporach. We should definitely allow hostnames and URLs. Even
the SCTP allows hostnames. And work on such addresses in SS7 protocols has
started in ITU. However, besides SUA users having to define how to use the
address, would not the AMF also have to support such addresses?

Klaus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: August 27, 2001 3:48 AM
> To: sigtran
> Subject: RE: [SUA Issue 27]: Hostname as Routing Parameter
> 
> 
> Hi Brian,
> 
> 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, 27 Aug 2001 15:01:23 -0500

Klaus,

I don't think that the draft makes any restrictions on what is or is not
part of the AMF.  Nor do I beleive it should.  The scope and implementation
of the AMF is certainly implementation-specific and an implementation may
decide to use Hostname/URL and IP or not.

The use of Hostname in SCTP does not imply DNS lookup and is merely a
shorthand for an IP address list (see Randall's recent note on TSVWG
about this).  I don't know how this possibly relates to SUA.

Unfortunately, because SUA is transporting the SCCP/SCCP-User interface,
any future enhancements to the SCCP/SCCP-User interface may need to be
reflected in SUA.  (I have already identified that if new GT types are
defined with new GT components, the SUA definition of Source and Destination
Address will likely have to be expanded).  If ITU enhances the GT with
URL or something else, SUA will need to be expanded.  Placing some GT
components in the SUA GT in anticipation of these developments in ITU
and elsewhere is ok, but defining new SUA-Users which have enhancements
beyond SCCP-Users is really not within the scope of the draft or the
working group.

If 3GPP wants to define some enhanced capabilities for SCCP, I have no
problem seeing the parameter support or even AMF and RK descriptions in
SUA.  Without a 3GPP document to reference the behavior of such an enhanced
SCCP-User, I think is should be left alone.  Regardless of whether Hostname
or URL or IP address are provided as parameter "place-holders", I believe
that all reference to the SUA-User as distinct from any other SCCP-User
(be it 3GPP or classical) should be removed.  I cite from the SIGTRAN
charter: "Nor will the working group work on defining new call control or
device control protocols."

Therefore, I still propose that we chuck SUA-User and descriptions of how
to use Hostname/URL and IP addresses in AMF and elsewhere.  If 3GPP has
some definitive need for procedures associated with these parameters,
let us see the definition of this 3GPP SCCP User in some document and
let 3GPP provide the descriptions of the use of these parameters in AMF
and elsewhere.

Because the sub-parameters themselves sit in a reserved IETF parameter
numbering space, and they do not affect the core protocol, I would still
prefer to see Hostname/URL and IP address removed altogether from the
core SUA draft.  This would still permit 3GPP to define them and their
use more clearly in an SUA extension draft.

--brian

Gradischnig, Klaus wrote:                            (Mon, 27 Aug 2001 06:00:31)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Coene Lode <[email-masked]>
Date: Tue, 28 Aug 2001 11:48:53 +0200

Mr. Bidulock,

Some comments below.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 27 augustus 2001 22:01
To: sigtran
Subject: Re: [SUA Issue 27]: Hostname as Routing Parameter

>about this).  I don't know how this possibly relates to SUA.
Not at all. the DNS option seems to make sense for NAT(or something alongs
those lines). Up till this moment nobody seems to be using it. 
And there is no relation with SUA.
>beyond SCCP-Users is really not within the scope of the draft or the

You may be transporting the SCCP/SCCP user interface, I am transporting
protocols.
And if new GT components gets in, well then you have to included those in
the protocol. I'll be the last to be against that. 
When the hostname got in the SUA draft, there was no anticipation on ITU
developments or anything else. Hostname/URL do like to me as GT and thus it
was very likely that they could be used that way(and actually it is far
easier to put in a hostname as a CLD and CLG instead of a IP address(easier
to remember). unfortunaly resolving it via DNS with a PC with a temporary ip
address assigned by DHCP ain't so easy for DNS.(if a "fixed" DHCP address is
used, then it works)
I would welcome any new SUA users, but this work group hasn't defined any
new users, nor will be in the forseeable future.(so I am at a loss what you
are trying to imply here)

>device control protocols."

As far as I know, this does not look to me as as a extended SUA user(or that
would mean that all present and furture existing application internet
protocols are theoretical enhanced SUA users as they use IP addresses and
hostnames: don't know if they would appreciate that)

>use more clearly in an SUA extension draft.

huh, all parameters of SUA are then in IETF reserved space and do not affect
the core protocol(according to your interpretation) then shouldn't we remove
the whole SUA spec?
I am just kidding:-)

I'm for keeping them in the document(it looks very usefull to me 	and
I am even using them as I speak).

I would propose to remove anything about that registration stuff  from the
document. That registration stuff together with the routing key will only
lead to more tables in the SG which will use up memory and gives us no
benefit at all. 

And if we allowed such a thing to happen, then 3GPP SUA would be different
from the IETF SUA, isn't it. This is starting to look as a rerun of 2
different version of the same protocol.

Brian, if you don't like hostname, IP addresses, DNS and/or ENUM, don't
implement them and leave the rest(of the implementors) alone. 
I am quite sure we can use them and they surely make much more sense than
including the MTP pointcode as source and destination pointcode in a SUA
message. Most SCCP application and therefore SUA users, use global title and
then certainly the MTP PC or IP address use becomes irrelevant.

I'm going to stop. Posts of such a nature always gives me the creeps.

yours sincerly,
Lode Coene

---

---

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

Hi all,

I have been reconsidering this issue.  The scenario is as follows:

SEP a wants to send to SEP c.  

Through local configuration, SEP has no SCTP associations setup to  
c, but knows that b is a relay point between them.  

SEP a knows SEP c host name and routes on hostname via relay b.

This is the point of section 1.5.3.

The text in the current draft is not clear.  I will add clarify text to
1.5.3 stating:

Usage of routing on Hostname is for further study.

John

> From: ext [email-masked] 
> Sent: 24 August, 2001 14:48
> To: sigtran
> Subject: [SUA Issue 27]: Hostname as Routing Parameter
> 
> 
> Hi all,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 05:23:45 -0500

John,

John Loughney wrote:                                         (Tue, 28 Aug 2001 13:07:07)
> SEP a knows SEP c host name and routes on hostname via relay b.

SEPs don't have hostnames, they have point codes.

> Usage of routing on Hostname is for further study.

So why include Hostname?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 05:44:55 -0500

Mr. Lode,

Please see comments below...

Coene Lode wrote: (Tue, 28 Aug 2001 11:48:53)
> are trying to imply here)

An SUA-User that provides hostnames is not an SCCP-User.  SUA-Users are
not defined by any standard I know of and the definition or augmentation
of SCCP protocols it is outside the scope of SUA and the WG.

> hostnames: don't know if they would appreciate that)

The SUA-User in the draft was distinguished from the SCCP-User by the
SUA-User's ability to also specify hostname and IP address in global
titles.  This gives an SUA-User a set of capabilities in addition to an
SCCP-User and is thus "enhanced".

[snip]
> different version of the same protocol.
One would extend the other: not two different protocols.

> then certainly the MTP PC or IP address use becomes irrelevant.

SCCP applications (SCCP-Users) have no concept of hostname or IP
address.  Only some sort of enhanced SCCP-User (SUA-User) might.  I
don't see any problem with requiring those that might want to use such
an enhanced SUA-User to define just how the enhancement is supposed to
work and interoperate with other such enhanced users, aside from it
being outside the scope of SIGTRAN.  The current draft is quite unclear
just what one is supposed to do with a hostname or URL which is provided
by an SUA-User and how that is supposed to resolve to an association and
an RC.  Placing a hostname or IP address in a GT to an SGP requires
defining just how the SGP is supposed to generate the SCCP-defined GT in
an outgoing SS7 message, and when and how an SGP is supposed to generate
a hostname/URL or IP address GT from an incoming SS7 SCCP message or GTT
result which contains neither.  If the hostname/URL or IP address is
only for going between IPSPs (which does not have explicit support for
relay nodes in the draft) what is a receiving IPSP supposed to do with
the hostname/URL or IP address?  How is it to provide these to a normal
SCCP-User which does not understand them?

If you would like to see them kept in the draft, I invite you to
describe how they are going to be used in the ASP/SGP/IPSP cases to
normal SCCP-Users.  If they are not normal SCCP-Users, I invite you to
describe these enhanced users, point to where outside of SIGTRAN they
are defined, and describe how to treat these enhanced GT components and
how they are going to interwork with existing SCCP networks.  Without
some description there is no hope of interoperability.

--brian

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

---

---

From: Coene Lode <[email-masked]>
Date: Tue, 28 Aug 2001 13:55:51 +0200

Nice to be invited.

> Sent: dinsdag 28 augustus 2001 12:45
> To: sigtran
> an RC. 

that is implementation specific. The AMF is a function: you put a address in
and out comes a address(possible another) + association. Speaking in models:
GT/hostname yields a GT'/hostname' + optional SSN + pointcode/IP address
(and that IP address (or PC mapped onto a IP address) points to a certain
SCTP association. What more is needed to make a decision? Specify the
function, but SCCP has never, ever specified a function, why should it be
specified here then. The only thing that has to be kept in mind is that the
return message must be able to be routed back to the orignator of the first
msg. The function used for the transformation is completely up the
implementor and teh folks who engineer the SG, relaypoint or whatever name
is en-vogue.

 Placing a hostname or IP address in a GT to an SGP requires
> result which contains neither. 
If it only contains a GT and the AMF function is not engineered to transform
that GT into a hostname, then no hostname will be included in the SUA
message. If on the other hand something is engineerd then the folks
engineering the SG will have their work cut out for them. For example: cld
+01911( a GT) transforms to cld org.ss7.0.1.9.1.1, the calling party address
will get some form of transformation also clg +0180052 transforms to
org.sS7.SG1.0.1.8.0.0.5.2 . the fact is that you add or remove whatever you
want and that would mean that those messages are routable in SS7
network(because you can strip off the org.ss7.SG1 stuff off before they get
into a SS7 network while in the IP network, especially in the case where
more than one SG has to be traversed, you can do the routing on the
org.SS7.* stuff. To me that isn't rocket science, the DNS can even resolve
some of this stuff, not all and with restrictions. That is how GTT has
always worked and will remain to work, heck you can even start encrypting or
decrypting part or the whole GT/hostname in a IP network(provided naturaly
that the keys get distributed to the right entities.)

 If the hostname/URL or IP address is
> SCCP-User which does not understand them?

invoke the AMF and decrement the hopcounter -> output: a SCTP association on
which to send your SUA msg in case of a relay node otherwise give it to the
right SUA user. What more do you need? A normal SCCP user which does not
understand them?: listen: the node with the normal SCCP user did receive the
msg and (apart from screening) delivered it to the SUA user. The SUA user
doesn't need to understand the addresses, it simply needs to flip  and store
them. If the SUA accepts the msg(in what format whatsoever),then the SUA
user will accept the msg as well and send a answer back. If you wory about
the API, then please go ahead and specify the API(I am not going to do that)
Suggestion: it will look a bit like the IP address structure withthe choice
between IPv4 and IPv6.
If the SUA user is the initiator, then it is his choice what format of
address he is going to use: PC, GT, IP address, hostname whatever... If he
choose only to use a PC or/and a GT then that is up to him. Nothing in SUA
will prevent him from doing so. Hostnames (and for that same matter GT) are
not mandatory but history has shown that GT clearly have better properties
than solely relying on Pointcodes.

> some description there is no hope of interoperability.

I think I did just that in this mail. 
And I'll stop for today, otherwise the real work doesn't get done.

yours sincerly,
Lode
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 14:02:57 -0500

Coene,

Sandeep had a problem with the current text and I agree
with him.  I do not believe that the current draft supports
what you propose here.

Please propose text modifications or additions to the
current draft which would provide for what you propose
in support of interoperability.

--brian

Coene Lode wrote:                                           (Tue, 28 Aug 2001 13:55:51)
[snip]
> > Placing a hostname or IP address in a GT to an SGP requires defining just
> > how the SGP is supposed to generate the SCCP-defined GT in an outgoing SS7
> > message, and when and how an SGP is supposed to generate a hostname/URL or
> > IP address GT from an incoming SS7 SCCP message or GTT result which
> > contains neither. 
>
> > If the hostname/URL or IP address is only for going between IPSPs (which
> > does not have explicit support for relay nodes in the draft) what is a
> > receiving IPSP supposed to do with the hostname/URL or IP address?  How is
> > it to provide these to a normal SCCP-User which does not understand them?
> 

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

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 30 Aug 2001 11:06:27 -0500

John,

The scenario is valid but I fail to see what's unclear in 1.5.3. I think the
text is fine as it stands.

Klaus

> Sent: August 28, 2001 6:07 AM
> To: sigtran

---