Subject: RE: [Dime] Summary of 3588bis Issues Status

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Tue, 18 Jul 2006 18:32:50 +0200

See in line.

Br
Marco

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: martedì 18 luglio 2006 18.10
To: STURA, Marco, VF-IT
Cc: [email-masked]
Subject: Re: [Dime] Summary of 3588bis Issues Status

Hi Marco,

comments inline:
>> It maybe a little bit confusing for relays with cannot resolve a route via >destination-host to look at an ASR with an app id of 0.
>>     
>
> Interesting argument I have to say. Routing ASR based on app id doesn't ensure that the session ASR is supposed to kill is actually running on the client where the request is routed to. Suppose a relay agent connected to 10 clients all of which support app id x, the relay routes based on app id x to client 2 but the session indicated in the <session-id> is actually running in client 5. The ASR will not kill the session as requested by the server, therefore ASR MUST use Destination-Host based routing.
>   

I agree with your example above regarding destination-host. It is 
required in the case of ASR (and perhaps some other message) though I 
guess I was stating a case which is a little bit different than your 
example above. I was thinking of the following case:

clients[1,2,3...x] <--- relay1 <---- relay2 <---- server

in this case relay2 will not be able to route using dest-host. This is 
where dest-realm and app id becomes important. In this case app id of 0 
might not work as well ... or maybe I'm wrong.

[MSt] In this case R1 would advertise it self as a relay (i.e. 0xffffffff) it won't advertise app id x or y or z. So, any app id would be routed to R1 by R2.

> Same argument stands for RAR.
>
> In fact the base defines ASR and RAR with Destination-Host AVP as mandatory in the ABNF of the message.
>
> I think in the AAA thread also available in the issue tracker there were arguments why ASR is really a common message, same would be for RAR if no mandatory AVPs are defined by the application.
>   
I've read through some of the comments in the AAA thread regarding this 
issue and it was not clear to me why an app id of 0 is applicable to ASR 
and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set 
to 4 (CC app id).

[MSt] Because the ASR or RAR requests a specific action to the client that is to be inferred to the session indicated in the <session-id>. Diameter CC sets the app id 4 in RAR because it augments the base message with mandatory AVPs defined in it with associated behavior. All ASR does is "kill the session". So, the why not stick on the original rules when RFC3588 was defined? Base common messages such as ASR and RAR MUST use app id 0 unless augmented with mandatory AVPs that define a specific behavior of the client (e.g. DCC application).

hope this helps,
victor

>
> Regards
> Marco
>
> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: martedì 18 luglio 2006 16.53
> To: STURA, Marco, VF-IT
> Cc: [email-masked]
> Subject: Re: [Dime] Summary of 3588bis Issues Status
>
> Hi Marco,
>
> The main reason (and people can correct me if i'm wrong) is that these 
> messages belong to the session/application using them and it is 
> better/easier to co-relate these messages to the said application. Since 
> the base protocol really defines two sets of messages, one set is for 
> session/application usage and another for peer connectivity, it is also 
> semantically correct for the the session message to carry the app id of 
> the session.
>
> In addition, for implementations, it is more practical to look at the 
> app id in the header to determine the application that a message belongs 
> to ... and rightfully so. In my opinion, ASR belongs to this category 
> even if it is server directed. It maybe a little bit confusing for 
> relays with cannot resolve a route via destination-host to look at an 
> ASR with an app id of 0.
>
> hope this helps,
> victor
>   
>> Hi Victor,
>>
>>   
>>     
>>> This topic is issue #2&5 and refers to what app id 
>>> should "application session level" messages defined in the base
>>>     
>>>       
>> protocol 
>>   
>>     
>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the 
>>> meeting and more likely in this list as well is that it MUST carry the 
>>> app id of the application using it.
>>>     
>>>       
>> Could you bring some light on the reasons behind this consensus? I
>> thought the discussion in the old AAA list was toward a consensus on
>> using Appl ID 0 at least for the ASR/ASA Diameter common messages.
>>
>> Regards
>> Marco
>>
>>
>>
>>
>>   
>>     
>
>
>
>
>
>
>   

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 18 Jul 2006 12:17:22 -0400

Marco,

I think, the reason for different point of views is mainly due to the
question who is considered as the owner of a session. IMHO, session is
better owned by the application logic, because only it has full knowledge
about when a session is supposed to end, hence I believe it is best that any
session/application logic related message is handled by the application. For
that reason, I think it is a good idea to use the App-Id of the application
in message header for the messages under discussion.

     Thanks,
     Tolga

> From: STURA, Marco, VF-IT [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 12:33 PM
> To: Victor Fajardo
> Cc: [email-masked]
> Subject: RE: [Dime] Summary of 3588bis Issues Status
>
>
> See in line.
>
> Br
> Marco
>
> >> It maybe a little bit confusing for relays with cannot resolve
> a route via >destination-host to look at an ASR with an app id of 0.
> >>
> >
> > Interesting argument I have to say. Routing ASR based on app id
> doesn't ensure that the session ASR is supposed to kill is
> actually running on the client where the request is routed to.
> Suppose a relay agent connected to 10 clients all of which
> support app id x, the relay routes based on app id x to client 2
> but the session indicated in the <session-id> is actually running
> in client 5. The ASR will not kill the session as requested by
> the server, therefore ASR MUST use Destination-Host based routing.
> >
>
> [MSt] In this case R1 would advertise it self as a relay (i.e.
> 0xffffffff) it won't advertise app id x or y or z. So, any app id
> would be routed to R1 by R2.
>
> > I think in the AAA thread also available in the issue tracker
> there were arguments why ASR is really a common message, same
> would be for RAR if no mandatory AVPs are defined by the application.
> >
> [MSt] Because the ASR or RAR requests a specific action to the
> client that is to be inferred to the session indicated in the
> <session-id>. Diameter CC sets the app id 4 in RAR because it
> augments the base message with mandatory AVPs defined in it with
> associated behavior. All ASR does is "kill the session". So, the
> why not stick on the original rules when RFC3588 was defined?
> Base common messages such as ASR and RAR MUST use app id 0 unless
> augmented with mandatory AVPs that define a specific behavior of
> the client (e.g. DCC application).
>
> hope this helps,
> victor
>
> >
> > Regards
> > Marco
> >

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 18 Jul 2006 12:51:41 -0400

[.. snip ..]
> would be routed to R1 by R2.
[TOLGA] Let me try to further refine the scenario:
              *****************************
              *  Realm A                  *
              *                           *
              *           +---------+     *
              *        +--+C1 App=X |     *
              * +----+ |  +---------+     *
         +----*-+ P1 +-+  +---------+     *
+---+  +-+--+ * +----+----+C2 App=Y |     *
|S1 +--+ R1 | *           +---------+     *
+---+  +-+--+ *                           *
         |    * +----+                    *
         +----*-+ P2 +----+---------+     *
              * +----+    |C3 App=Z |     *
              *           +---------+     *
              *                           *
              *****************************
In this case, R1 wouldn't have enough knowledge to route the message
properly to the correct proxy just by looking to the App-Id in the message
header, if App-Id is populated with "0".

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 18 Jul 2006 14:04:26 -0400

Hi All,
> [MSt] Because the ASR or RAR requests a specific action to the client that is to be inferred to the session indicated in the <session-id>. Diameter CC sets the app id 4 in RAR because it augments the base message with mandatory AVPs defined in it with associated behavior. All ASR does is "kill the session". So, the why not stick on the original rules when RFC3588 was defined? 
Yes but the session being "killed" belongs to a particular application. 
Semantically speaking, setting it to 0 seems to imply all applications.

> Base common messages such as ASR and RAR MUST use app id 0 unless augmented with mandatory AVPs that define a specific behavior of the client (e.g. DCC application).
>   
I'm still not sure why we 'MUST' use app id of 0 ? I'm also not sure if 
there is any technical merit/advantage in having to define different 
rules for setting different app ids for just one or two messages 
depending on whether they are mandated to use new avp. I think it tends 
to lead to more confusion which is what we are originally trying to 
resolve. Unless I have the wrong take on this issue, there is a 
consensus that we should just use the app id of the application for 
simplicity and correctness.

To that end, I would encourage folks to give their comments if any so we 
can get a better sense on the pitfalls of the current proposals if there 
is any.

hope this helps,
victor

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 18 Jul 2006 14:40:02 -0700

Few topics has generated as many messages in this and other groups as 
the subject regarding (or the confusion surrounding) the fact that there 
is an AVP-based application id in the message in addition to the message 
id in the Diameter header.

As far as I am concerned, the application-id serves three purposes:

  1. Combined with the Command-Code as a message type discriminator to
     determine what dictionary and processing entry point to apply in
     order to process the message.
  2. Combined with the Destination-Realm to determine message routing.
  3. As a special case in the CER/CEA as a means to advertise
     application id support.

I just can't imagine what scenario would require more than one 
application id in a message to serve the purpose of both case 1 and 2 
above, but I may be wrong.
Only in case 3, which is an exception, use of the application id AVPs is 
necessary since they are overloaded to mean "support for" in contrast to 
identifying the type of message. In this latter case the header 
application id only serves as a discriminator to indicate "base".

For messages that are intended for a specific server, such as ASRs or 
any other message that are tied to a specific session, the primary means 
for reaching the correct destination is the Destination-Host AVP. The 
application id may of course still be used to make coarse routing 
decisions to reach a host that has connectivity to and knowledge about 
the given host. Obviously it is the responsibility of the network 
administrator to configure the network in this case in such a way that 
messages aren't dropped, i.e. are being relayed or proxied to reach a 
"knowledgeable" peer. This would also seem as a very likely way to set 
up routing in practice, i.e. make course decisions far away from the 
target and make more precise decisions as the message gets closer to its 
destination.

If the header application id is always set to resolve cases 1 and 2 
above, i.e. set to identify the application pertaining to the message, 
the only remaining meaningful use for the AVP based application ids is 
for CE[AR]s. For existing AVP rules that include application ids as 
AVPs, the standard could simply state that if one of the Application-Id 
AVPs appear in a message, it MUST be set to the same value as the header 
application id and thereby relieve implementers from a lot of confusion. 
For new definitions, AVP application ids may be defined as optional, or 
simply handled by the "universal last resort" *AVP rule.

IMHO, a clean and simple rule that would make life much easier both for 
implementers and standards writers that avoids complicated and/or hard 
to grasp rules regarding when to use one or the other of the application 
ids.

One obvious issue is that the AVP application id can carry 65 bits of 
information; an optional 32 bits of vendor id and a binary selector 
between Auth versus Acct. There seems to be some disagreement as to 
whether the application id numbering space is flat or not, but if it 
considered flat, which indeed a 32 bit number would be sufficient for, 
the "optional" AVP information could be disregarded and the header carry 
the authoritative source of information.  As an alternative, if the 
vendor id and the Auth/Acct distinction is deemed necessary, the header 
application id could be disregarded and the AVP be treated as the only 
authoritative piece of information instead.

Just my five cents,
Jan Nordqvist

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 18 Jul 2006 18:06:01 -0400

Hi Yoshi/Marco,
> [MSt] In this case R1 would advertise it self as a relay (i.e. 0xffffffff) it won't advertise app id x or y or z. So, any app id would be routed to R1 by R2.

Yes your right. Apologize for that. However, I think based on Yoshi and 
Tolga's comments if relay2 is actually a stateful proxy then app id 
becomes important to properly route the ASR  s. In such a case, an app 
id of 0 may not work.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 18 Jul 2006 19:13:48 -0400

Hi Jan,

Thanks for bringing up this topic. Just to clarify, this is a new 
discussion for issue 13 of the tracker.

Comments inline:
> the subject regarding (or the confusion surrounding) the fact that 
> there is an AVP-based application id in the message in addition to the 
> message id in the Diameter header.
>
> Only in case 3, which is an exception, use of the application id AVPs 
> is necessary since they are overloaded to mean "support for" in 
> contrast to identifying the type of message. In this latter case the 
> header application id only serves as a discriminator to indicate "base".
>
> any other message that are tied to a specific session, the primary 
> means for reaching the correct destination is the Destination-Host 
> AVP. The application id may of course still be used to make coarse 
> routing decisions to reach a host that has connectivity to and 
> knowledge about the given host. Obviously it is the responsibility of 
> the network administrator to configure the network in this case in 
> such a way that messages aren't dropped, i.e. are being relayed or 
> proxied to reach a "knowledgeable" peer. This would also seem as a 
> very likely way to set up routing in practice, i.e. make course 
> decisions far away from the target and make more precise decisions as 
> the message gets closer to its destination.
>
> AVPs, the standard could simply state that if one of the 
> Application-Id AVPs appear in a message, it MUST be set to the same 
> value as the header application id and thereby relieve implementers 
> from a lot of confusion. For new definitions, AVP application ids may 
> be defined as optional, or simply handled by the "universal last 
> resort" *AVP rule.

I generally agree. In terms of backward compatibility, the base protocol 
already mandates that Application-Id AVPs MUST match the app id in the 
header (Sec 3) though I think the text should be a little bit more 
clear. In that sense, I'm guessing the above scheme should work even for 
existing implementations.

>
> IMHO, a clean and simple rule that would make life much easier both 
> for implementers and standards writers that avoids complicated and/or 
> hard to grasp rules regarding when to use one or the other of the 
> application ids.
>
> the "optional" AVP information could be disregarded and the header 
> carry the authoritative source of information.  As an alternative, if 
> the vendor id and the Auth/Acct distinction is deemed necessary, the 
> header application id could be disregarded and the AVP be treated as 
> the only authoritative piece of information instead.

I think this last paragraph is a separate issue but related to issue 13. 
Regarding the last sentence, if vendor id + auth/acct distinction is 
applied then the vendor id will now have to be reflected in the routing 
table. This may have some implications with existing implementations 
which will not recognize this scheme. I guess this would be an issue 
with any app in general since they now has to be concerned with vendor 
id + auth/acct id space. So I think we need to have some resolution with 
regards to address space first. I'm more in favor of a flat 32 bit space 
and a strict allocation of app id's as currently mandated by the base. 
In this case, vendor id has no co-relation with app id. The question 
then arises on how this affects existing implementations and VSA's.

best regards,
victor

best regards,
victor

---

From: Rajith R <[email-masked]>
Date: Wed, 19 Jul 2006 12:27:42 +0530

Hi Victor

	What you suggest would render the vendor specific application Id AVP
useless, I think.

Rajith
****************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
>Sent: Wednesday, July 19, 2006 4:44 AM
>To: Jan Nordqvist
>Cc: [email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Jul 2006 12:38:49 +0300

Victor Fajardo wrote:
> I'm still not sure why we 'MUST' use app id of 0 ? 

In the case of RFC 4005 and 4072: because the spec says so?

RFC 4005, Section 1.3: "All other messages are defined by [BASE] and
use the Base application id value."

RFC 4072, Section 3, last paragraph: "the others
[RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)."

This should not lead to interoperability problems unless the
implementors can't read the specs. And in that case, producing more
specs is unlikely to be of help.

<snip>

> Unless I have the wrong take on this issue, there is a consensus
> that we should just use the app id of the application for simplicity
> and correctness.

The last time this was discussed, there was consensus that using 0 is
the right answer, and this lead to adding the above-quoted text to RFC
4005 and 4072.

So unless the approach in 4005/4072 leads to significant problems,
even when correctly implemented, I'd suggest not changing it.
Changing it could also lead to interoperability problems with
those implementations that correctly implement 4005/4072.

Best regards,
Pasi

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Jul 2006 07:12:09 -0400

Hi Rajith,
> 	What you suggest would render the vendor specific application Id AVP

Probably. I don't have a strong opinion on this so maybe someone else 
can shed light on what a good course of action would be.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Jul 2006 09:03:34 -0400

Hi Pasi,

> [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)."

I can understand how the issue can affect 4005/4072.

> specs is unlikely to be of help.

Not sure if this is the case ... it was several implementors who 
requested clarification on this issue during an interop so it maybe best 
to hear out their concerns beyond 4005 or 4072. Some of such concerns 
have been posted in this list.

> the right answer, and this lead to adding the above-quoted text to RFC

I guess if there was a previous consensus ... then maybe all we need is 
a clarification on the reasoning behind the previous consensus and see 
if it that reasoning still hold true with regards to current concerns.

hope this helps,
victor

---

From: <[email-masked]>
Date: Wed, 19 Jul 2006 18:01:58 +0300

Tolga,

This is not the first time this issue has been discussed (see e.g. 
AAA archives around July 2004). What it really boils down to
is what exactly an "application" is. Quoting myself from two
years ago:

> This brings us back to the topic what an "application" actually
> is. It could mean e.g. a software module in a Diameter
> implementation, or a (set of) specifications that document how
> Diameter is extended for some particular purpose (such as SIP or
> Mobile IPv4).
>
> My reading of RFC3588 supports the latter interpretation (but I
> guess there is some room for disagreement and other interpretations
> as well...).

With this interpretation, it does not make sense to say that you send
a message _to_ an application, or that a message is intended _for_ an
application. Instead, you send a message defined _in_ some
application.

Back then, several others seemed to agree that RFC 3588 supports 
this interpretation. 

(How a Diameter server implementation is organized to modules and 
how the modules communicate is beyond the scope of RFC 3588.)

Best regards,
Pasi

> From: ext Tolga Asveren [mailto:[email-masked]] 
> Sent: 19 July, 2006 15:25
> To: Eronen Pasi (Nokia-NRC/Helsinki); 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Pasi,
> OTOH we also have the following text from RFC3588:
> 3. Diameter Header
> 
> Application-ID
> 
> The application-id in the header MUST be the same as what is
> contained in any relevant AVPs contained in the message.
> 
> If one is building a diameter base stack following RFC3588, this
> sentence probably would make them think that all messages intended
> for a specific application will use applications identifier in
> App-Id filed of the message header.
> 
> 	Thanks,
> 	Tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 10:48:22 -0400

Pasi,

Thanks for the pointer, which clarifies your point. I think I tend to think
more similar to the first interpretation. I consider base diameter protocol
as transport-routing/encoding-decoding services, which can be used by
applications, which actually perform application level processing.

    Thanks,
    Tolga

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 11:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 08:25:10 -0400

Pasi,

Application-ID

The application-id in the header MUST be the same as what is contained in
any relevant AVPs contained in the message.

If one is building a diameter base stack following RFC3588, this sentence
probably would make them think that all messages intended for a specific
application will use applications identifier in App-Id filed of the message
header.

	Thanks,
	Tolga

> Sent: Wednesday, July 19, 2006 5:39 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 02:26:57 +0300

Hi all,

Basically, Pasi is correct here.   The specs say to use app id of zero.
The 
consensus when standardizing Diameter Base and RFC 4005, 4072, etc. is
that
these messages use app id of 0.

I don't think that we should re-open this issue, as it was discussed and
decided
long ago.

John

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 19 July, 2006 05:39
>RFC 4005, Section 1.3: "All other messages are defined by 
>[BASE] and use the Base application id value."
>
>implementors can't read the specs. And in that case, producing 
>more specs is unlikely to be of help.
>
><snip>
>
>> Unless I have the wrong take on this issue, there is a 
>consensus that 
>> we should just use the app id of the application for simplicity and 
>> correctness.
>
>The last time this was discussed, there was consensus that 
>using 0 is the right answer, and this lead to adding the 
>above-quoted text to RFC
>4005 and 4072.
>
>So unless the approach in 4005/4072 leads to significant 
>problems, even when correctly implemented, I'd suggest not changing it.