Subject: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule)

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Apr 2004 09:23:57 +0100

changed the subject line to match the subject ;-)

Dear all,

These are some thoughts about how to handle this question of
cross-application common functions.

We can say that for at least some of the functions in Dave's
list below, the impact of the function on the protocol stack 
is that there is some object to be carried in [some of the]
signalling messages which expresses (for example) priority,
or the binding between different sessions, or whatever.

The current default assumption in NSLP design is that each NSLP 
spec should define its own objects for all the non-GIMPS functionality 
that it needs. The worry is that this will lead to a proliferation
of nearly similar objects which are processed by different
applications in subtly different ways. (I can sympathise with
that concern, although I'm not sure it's totally avoidable.)

Here is a modified approach:
- it should be possible to use a single object definition
  in multiple applications
- the implication is that there should be a single identifier
  space for NSLP objects (one IANA registry for the T values 
  in the TLV format)
- extensibility rules about mandatoriness/optionality will
  probably have to be common between different applications
  and encoded separately from the object types
- the NSIS (NSLP:TLV object) structure will look quite
  similar to the Diameter (Application:AVP object) structure.

What do people think about this? Supplementary questions would
be: where should this sort of structural information be stated; 
where and how should the common objects be defined; and which 
people are working on defining them.

NOTE: This approach still wouldn't guarantee that, for example,
a signalling exchange about NAT and QoS requirements for a 
specific flow would use the same MLPP values; that coordination
would still have to be done between the signalling applications.
Indeed, it might not be possible to bind the signalling applications
together that tightly, if only because the NAT and QoS processing
were taking place on different nodes. Guaranteeing that such binding
took place wherever it was logically possible would need non-trivial
changes to GIMPS, and I'm not sure that is what is really being
asked for. We are just encouraging the applications to use the 
same language.

robert h.

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, April 26, 2004 17:34
> To: [email-masked]; Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] Tentative Interim Meeting schedule
> 
> >> minor comment: there is some discussion on whether there are
> >> application-generic functionalities outside the transport.
> >>
> >> the specific item that made me think about this is the
> >> 'intserv/diffserv' agenda point: does this include handling
> >> mlpp and 2-phase operation? or should it be generalised to
> >> qos-models which do this? or should there be an even more
> >> wide-ranging discussion?
> >
> I think these things are in fact *orthogonal* to the QoS 
> model and in fact 
> have broader semantics than QoS. My partial list includes:
> - precedence and preemption
> - separation of reserve and commit phases
> - fate sharing
> - policy control for AAA and envelope resource utilization
> 
> These all strike me as things which are not really part of 
> the transport, 
> but which are identical or nearly so across NLSPs, and may in 
> fact need 
> explicit coordination across NLSPs.
> 
> There are also some gray areas:
> - route recording and explicit routing (this might belong 
> directly in the 
> transport, or between the transport and the NLSPs)
> - resource sharing (this might not gain much abstracted from the NLSP)
> 
[snipped stuff about qos definition]

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

---

From: [email-masked]
Date: Thu, 29 Apr 2004 12:47:06 +0300

Robert & Rüdiger,

Just a general comment:

> |Here is a modified approach:
> |- it should be possible to use a single object definition
> |  in multiple applications
> |- the implication is that there should be a single identifier
> |  space for NSLP objects (one IANA registry for the T values 
> |  in the TLV format)
> 
> That's a good idea.
> 
> |- extensibility rules about mandatoriness/optionality will
> |  probably have to be common between different applications
> |  and encoded separately from the object types
> 
> This allows to combine different objects as required by a 
> specific NSLP application, right? Then it is a good idea too.
> 
> |where should this sort of structural information be stated
> |where and how should the common objects be defined; and which 
> |people are working on defining them.
> 
> Two approaches come to my mind:
> - a single toolbox doc containing all basic rules, data 
>   formats and parameters ever specified for any NSLP.
> - NSLP application specs referring to toolbox contents.
> 
> or
> - a spec of basic rules and data formats.
> - NSLPs defining parameters and cross-referencing if one 
>   re-uses a parameter of another.
> 
> The first would be the cleaner approach, but it creates a 
> lot of ongoing maintenance acitivty. The latter better suits 
> to WG's of limited lifetime. It however requires some 
> mechanism to prevent repeated specification of the same 
> feature. If a simple an reliable mechanism to prevent this 
> can be designed, I'd tend to the second approach. 

The 2nd approach doesn't sound very different from how Diameter
was designed, with multiple application support.  Would that
be a good analogy, or were you thinking of something different?

John