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

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 27 Feb 2012 15:11:58 +0100

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

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 28 Feb 2012 17:34:40 +0100

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:
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime