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

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Wed, 19 Jul 2006 10:04:45 +0200

Tolga,

Diameter was defined as a framework with a set of base common messages and procedures on top of which we could build additional service specific application logic. This additional service specific application logic is supposed to use 'utilities' from the base framework such as transport and routing, session handling, capability negotiation and common messages handling.

What you're saying is changing the paradigm and philosophy of the base framework; essentially you're saying that we don't have common messages and common mechanisms anymore. All what RFC 3588 defines as session based common messages according to your comments is shifted to the service specific application, hence jeopardizing the entire framework. To me your proposal calls for re-building the same handling for those common messages in each of the service specific applications rather than applications re-using the common handling offered by the base framework. Not a good idea IMHO.

Regards
Marco 

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

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

> -----Original Message-----
> 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
>
> -----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

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

---

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

Marco,

I understand your point. OTOH, to me it sounds strange to leave decisions
related with session life cycle to anything else than the application logic,
because it usually is dependent on the type of application and the context
of the scenario.

The way I see it is as follows:
a) We have hop-to-hop messages, to be consumed by base diameter.
b) We have messages defined by base protocol, which are related with session
life-cycle, are generic in nature -hence defined in base diameter rather
than replicated in every new application specification-, and are consumed by
application.
c) Messages which are defined by applications.

I don't see this as a drastic paradigm shift. Actually the reason for this
thread is that the text in RFC3588 can be interpreted in different ways, so
whether there is a shift or not depends of ones understanding of the current
specifications -where obviously people have different interpretations-.

     Thanks,
     Tolga
> Sent: Wednesday, July 19, 2006 4:05 AM
> To: Tolga Asveren; Victor Fajardo
> Cc: [email-masked]
> Diameter was defined as a framework with a set of base common
> messages and procedures on top of which we could build additional
> service specific application logic. This additional service
> specific application logic is supposed to use 'utilities' from
> the base framework such as transport and routing, session
> handling, capability negotiation and common messages handling.
>
> What you're saying is changing the paradigm and philosophy of the
> base framework; essentially you're saying that we don't have
> common messages and common mechanisms anymore. All what RFC 3588
> defines as session based common messages according to your
> comments is shifted to the service specific application, hence
> jeopardizing the entire framework. To me your proposal calls for
> re-building the same handling for those common messages in each
> of the service specific applications rather than applications
> re-using the common handling offered by the base framework. Not a
> good idea IMHO.
>
> Regards
> Marco
>