Subject: [AAA-WG]: [issue] Server Identification

From: David Spence <[email-masked]>
Date: Fri, 18 May 2001 16:35:33 -0400

Subject: [issue] Server Identification

Submitter name: David Spence
Submitter email address: [email-masked]
Date first submitted: May 18, 2001
Reference: 
Document: Base
Comment type: T
Priority: 1
Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others
Rationale/Explanation of issue:

    There are various places in the base protocol specification that
    assume that only one copy of a Diameter server can run on a host and
    therefore that a Diameter server can be uniquely identified by an
    FQDN or an IP address.  It would be helpful to allow for multiple
    server processes to run on a host.  Some of the places where this
    assumption is made are as follows:

    1. DRI election process

       There is a problem in the DRI election process, where a server is
       identified solely by FQDN.  The DRI election process resolves by
       comparing FQDNs and assumes that they won't be the same.

    2. Origin-FQDN AVP and Destination-FQDN AVP

       The Origin-FQDN and Destination-FQDN AVPs are used for final hop
       routing.

    3. Route-Record AVP

       The Route-Record AVP is also FQDN based and is used both for
       routing and for loop detection.

       This issue was actually raised in February on the mailing list.
       (See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.)  The
       thread died without resolution, but Pat's final question was
       "whether multiple aaad processes on a single box is a
       requirement?"

    4. Error-Reporting-FQDN AVP

       The Error-Reporting-FQDN AVP is also FQDN based and is used for
       identifying a Diameter server.

    There is one place where Diameter does accommodate multiple servers
    per host.  A redirect host is identified by a Redirect-Host grouped
    AVP which contains an FQDN and a port.

Requested change:

    Invent a general way to identify an instance of a Diameter server.  A
    combination of FQDN and TCP/SCTP port number is suggested.  Use this
    combination in each of the above AVPs.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 18 May 2001 13:30:51 -0700

On Fri, May 18, 2001 at 04:35:33PM -0400, David Spence wrote:

Out of curiosity, would you mean something like the FQDN AVPs would
contain:

	myhost.domain.com/1812
?

PatC

---

From: David Spence <[email-masked]>
Date: Fri, 18 May 2001 18:30:54 -0400

> Out of curiosity, would you mean something like the FQDN AVPs would

Perhaps.  But I would prefer to use a Grouped type AVP containing two AVPs,
one of type octet string and one of type integer.

We could define an FQDN AVP and a Port-Number AVP that would only appear in
Grouped AVPs.  Then the Origin-FQDN, Destination-FQDN, Route-Record, and
Error-Reporting-FQDN AVPs would all contain an FQDN AVP and a Port-Number
AVP.  (Yes, I know I'm still trying to have reusable data objects, sigh, but
I do think it would be nice to define the FQDN format only once.)

---

From: David Spence <[email-masked]>
Date: Wed, 30 May 2001 14:29:51 -0400

>     combination in each of the above AVPs.

Resolution:

   At the May interim meeting, we decided to use a Diameter URL instead of
   host and port number AVPs.  The Diameter server URL would look something
   like:

        diameter://host.domain:port;transport=sctp

   SIP does a similar thing, and we copied their way of indicating
   transport.

---

From: Paul Funk <[email-masked]>
Date: Wed, 30 May 2001 16:12:49 -0400

I believe the scheme can also be optional, allowing reduction of the text 
size. In URI terms (RFC 2396), we can use a relative URI, with an application-
defined base URI of "diameter://". 

Thus, the examples can be reduced to:

      host.abc.com
      host.abc.com:6666
      host.abc.com;transport=tcp
      host.abc.com:6666;transport=tcp

In effect, the diameter scheme becomes a formality for adhering to URI rules.

We should probably make reference to URIs and RFC 2396 in the text.

Paul

At 11:24 AM 5/30/01 -0700, Pat Calhoun wrote:
>On Wed, May 30, 2001 at 02:29:51PM -0400, David Spence wrote:
>> Resolution of:
>> > 
>The actual text that I propose is as follows:
>
>2.7  Diameter Identity Encoding
>
>  Several Diameter AVPs are used to include a node's identity, such as
>  the Destination-Host, Origin-Host, Route-Record, etc. The contents of
>  such AVPs MUST follow the encoding rules defined in this section.
>
>      Diameter-Identity  = "diameter://" fqdn [ port ]
>                           [ transport ]
>
>      fqdn               = Fully Qualified Host Name
>
>      port               = ":" port
>      ; If absent, the default Diameter port (TBD) is assumed.
>
>      transport          = ";transport=" ( "tcp" | "sctp" )
>      ; If absent, the default SCPT [26] protocol is assumed.
>
>  The following are examples of valid Diameter host identities:
>
>      diameter://host.abc.com
>      diameter://host.abc.com:6666
>      diameter://host.abc.com;transport=tcp
>      diameter://host.abc.com:6666;transport=tcp

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 30 May 2001 11:24:13 -0700

port               = ":" port

      diameter://host.abc.com

---

From: Mark Eklund <[email-masked]>
Date: Wed, 30 May 2001 16:38:10 -0400 (EDT)

Pat,

If you had

If you have a proxy that speaks both radius and diameter and is
connected to a radius NAS and a Diameter server, could it set
the NAS identifier as below before proxying to the Diameter
server?

radius://nas.legacy.xyz:1813;transport=udp

-mark

---

From: Erik Guttman <[email-masked]>
Date: Thu, 31 May 2001 07:57:57 +0200 (MET DST)

An additional implication of this isssue is a modification of the
service template in Appendix A.  Two lines have to change:

   template-url-syntax=
     url-path= ; The standard service URL syntax is used.
               ; For example: 'service:diameter://aaa.example.com:1812

Should become:

   template-url-syntax=
     url-path= ; The diameter URL format is described in section XXX.
               ; Example: 'diameter://aaa.example.com:1812;transport=tcp

Erik

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 31 May 2001 11:41:54 -0700

> radius://nas.legacy.xyz:1813;transport=udp

Seems like a good idea for a protocol gateway to do. I guess
that would belong somewhere in the NASREQ spec. I suppose I should
open a separate issue on that one.

PatC

---

From: Mark Eklund <[email-masked]>
Date: Thu, 31 May 2001 16:03:26 -0400 (EDT)

Pat, 

> open a separate issue on that one.

Sounds good.  It would also involve the base.  A change
something like this would be needed.

            Diameter-Identity  = [protocol] fqdn [port]

            protocol	       = protocol-type "//"
            ; If absent, the default is "diameter://"

            protocol-type      = The protocol of the originator.
	    ; This is typically "diameter", but may be other
            ; values like "radius" if a radius gateway is involved.

            port               = ":" port

-mark