Subject: Re: [Dime] Comments on Diameter NAT control -13

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 5 Mar 2012 15:22:18 +0100

Hi Frank,

Thanks for taking the time to reply with so many details. I think I now 
better understand how the NCR command works. I would have designed it 
slightly differently, but I can live with the way it works.

BR,

       Miguel

On 28/02/2012 17:34, Frank Brockners (fbrockne) wrote:
> Hi Miguel,
>
> thanks for your email and also thanks for brining the discussion to the
> list. IMHO there are two different views, depending on what you identify
> as the entity that DNCA manages. Right now the managed entity is the
> _session_ associated with an endpoint. To manage the life-cycle of a
> session one would need to be able to
> a) initialize/create it
> b) update parameters associated with the session
> c) terminate it
> d) query the state of one or multiple sessions
> The NCR command currently handles a), b), and d) - and the action is
> indicated using a single de-multiplexer, the NC-Request-Type AVP. a) is
> served by INITIAL_REQUEST, b) by UPDATE_REQUEST, and d) by
> QUERY_REQUEST. c) is served by the normal STA command. Updating a
> session could include adding bindings, removing bindings, changing the
> maximum number of binding supported on a session. What kind of update
> actions are needed are determined by the AVPs present in an update
> request. This obviously means that you need to evaluate all the AVPs in
> the NCR/Update-Request message. If a future revision of the protocol
> would require additional parameters to be managed on a session (think of
> e.g. managing the timeouts for bindings on a per-endpoint basis), we'd
> just add the additional AVP - changes to the protocol would be
> relatively small - though an implementation would of course need to
> evaluate yet another AVP.
>
> In your email below you inspire a somewhat different approach. You seem
> to hint at making the different objects kept at NAT-device the managed
> entity for DNCA. Those objects at the NAT-devices are obviously the
> NAT-bindings, but are not limited to bindings, because we also manage
> other objects such as the maximum amount of bindings allowed for a
> particular endpoint.
>
> If we'd follow this logic then we some form of "command" to install,
> update, and remove these objects at the NAT-device. These commands would
> not be limited to individual bindings, but should equally apply to other
> objects such as the Max-NAT-Bindings.
> That said, the need for managing the session (e.g. query the state) does
> not disappear. This means that you'd need to differentiate between
> - session level commands (init, update, terminate, query) and
> - for the specific use of "update" a session, implement either a
> specific de-multiplexer or add additional commands
>
> Given that an implementation would need to check the validity of a
> message in any case, would adding a multiplexer AVP - for the use within
> "update" - really add much? This multiplexer would likely come in the
> form of a bit-mask, with a bit for "NAT-Control-Install AVP present",
> "NAT-Control-Remove AVP present", etc. - and the bit-mask should be long
> enough so that we can leave room for future additions (think of the
> timeout example above). All the bit mask AVP would do is off-load us
> from checking all the AVPs - though, per what I said above, you likely
> need to check all the AVPs in any case to do a validity check on the
> message, hence I'm not sure what we gain here.
> The other alternative would be to add additional commands per parameter,
> e.g. UPDATE-ADD-BINDING, UPDATE-REMOVE-BINDING,
> UPDATE-CHANGE-MAX_BINDINGS... etc. - though this would make extensions
> more difficult - and at the same time would no longer allow us to change
> multiple parameters/objects of an endpoint session with a single command
> (i.e. add bindings and remove binding and change max-bindings).
>
> Thoughts?
>
> Thanks, Frank
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Miguel
>> A. Garcia
>> Sent: Monday, February 27, 2012 3:12 PM
>> To: [email-masked]
>> Subject: [Dime] Comments on Diameter NAT control -13
>>
>> Hi:
>>
>> I was doing a review of earlier versions of the Diameter NAT control
>> draft for the Gen-ART team. And I have been in touch with the authors,
>> keeping an eye to this draft.
>>
>> I would like to share one of the comments with other members of the
>> working group to see if the WG can better get an opinion.
>>
>> - NCR demultiplexor.
>> As I understand, the NCR command has three main functions: create or
>> update a binding, remove a binding, or query for a binding. At the
> moment
>> there is not a single AVP that clearly indicates the function of the
>> command. A server has to inspect the presence of the
> NAT-Control-Install
>> to see if this is a create or update (the difference between create an
>> update is given by the NCR-Request-Type AVP). Or the presence of the
>> NAT-Control-Remove to see that this is a remove. Or the
> NCR-Request-Type
>> set to QUERY_REQUEST to see that this is a query.
>>
>>
>> I was arguing that is a good protocol design practice to have clear
> and
>> easily expandable semantics in messages. In this case, there is no
> clear
>> semantics of the NCR command. The receiver of this command should
> inspect
>> NCR-Request-Type and NAT-Control-Remove to find out what this is all
> about.
>>
>> This mechanism also poses a future problem, if an application needs to
>> add additional semantics to NCR. So, I was recommending to have a
> single
>> AVP that clearly denotes the function of the NCR command
>>
>> What do the WG think about?
>>
>> /Miguel
>> --
>> Miguel A. Garcia
>> +34-91-339-3608
>> Ericsson Spain
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain