Subject: Re: [Dime] Command re-use, implicit capability exchange

From: Marco Liebsch <[email-masked]>
Date: Mon, 4 Mar 2013 15:17:50 +0000

Hi Lionel,
please see inline.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Donnerstag, 28. Februar 2013 11:41
>To: Marco Liebsch; [email-masked]
>Subject: RE: Command re-use, implicit capability exchange
>
>Hi Marco,
>
>Thank you for reactivating this discussion.
>
>See below.
>
>Lionel
>
>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Marco Liebsch Envoyé : mardi 19 février 2013 17:24 À : [email-masked] Objet :
>[Dime] Command re-use, implicit capability exchange
>
>Hi,
>
>the latest proposal to enable Diameter to signal group commands re-uses
>existing Diameter messages and adds new group-specific AVPs to the command.
>
>Can such approach implicitly avoid conflicts with group signaling between a
>group-enabled Diameter node and a Diameter node, which does *not* support
>group signaling? When the specification allows each node to assign a session to
>a group and both sides agree to the group, it means implicitly that at least these
>two nodes support group operations.
>
>[LM] ok
>
>In such case, the new AVPs to assign a session to a group, could be
>informational, hence they do not have the M-bit set. Group assignment could
>e.g. be done during AAR/AAA when the session ID is built.
>In case a receive cannot understand the semantics of the AVPs that are meant to
>build the group, the response must not include these AVPs. The originator of the
>AAR implicitly learns that the remote peer does not support group operations.
>
>[LM] ok
>
>In case the remote peer does not want to assign the session to a group for other
>reasons, this needs to be signaled explicitly.
>
>[LM] ok.
>
>It's more difficult if group assignment is being done only by the receiver of a
>message and the receiver indicates the group in the response (i.e. AAA). The
>sender of the AAR may not be able to interpret the group-specific AVPs.
>
>[LM] The principle given above can be also applied in this case. The client can
>ask for group assignment and wait for the answer from the server. This could be
>done using a flag, an empty value in the Group-Session-ID AVP, or any other
>suitable solution.

That's not the scenario I refer to above. Assume the client sends a single-session
AAR (without group-ID, as it does not support grouping) and the server assigns the
associated Session ID to a group, letting the client know about the Group ID in the AAA.
The client will ignore the group-ID in the AAA as it does not support grouping and group
operations. The Server will not be aware of this. So, we need to handle this case.

What we could mandate is that clients, which support grouping, must include a
Group-ID in any case, even if it's empty. So the server knows about the client's
capability and can assign the session to a group. In case the server receives a
request without Group-ID AVP, the server MUST NOT assigned the session
to a group. Is that the way out?

>
>Furthermore, changes in the support of group operations may be possible after
>one of the Diameter nodes changed and the existing session context is
>transferred to the new Diameter node. That could be after a handover or after a
>failover scenario. Here, group re-assignment is needed anyhow, at least in case
>of handover. First handshakes after such relocation of a Diameter node may
>require fallback to single session operations e.g. to assign a session to a new
>group.
>
>[LM] For me there are two steps: the old node has to remove the "transferred"
>session from the group-session handled locally and the transferred session is
>assigned to a new Group-session in the new client (if supported). In such a case,
>the old client should notify the server of the change in the group assignment.
>After, there is a new group assignment mechanism between the new client and
>the server, which would be independent of the other one.

We could force client and server to re-assign transferred Sessions to groups in any case.
In such case we may run into the abovementioned scenario: The handover target client
sends the first message to the server. The server has a user context stored and
assigns the user session to a different group. The associated Group ID is signaled to
the target client in the Server's response. The client ignores the Group-ID.

The other scenario is probably less likely: Server change, e.g. during failover handling.
But here I guess the (redundant) server, which takes over the sessions of the failed server,
should support the same capabilities, including group operations. 

marco

>
>Any thoughts?
>
>marco
>
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>
>_________________________________________________________________
>________________________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
>copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
>signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration, France Telecom - Orange decline
>toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be distributed, used
>or copied without authorisation.
>If you have received this email in error, please notify the sender and delete this
>message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>Thank you.