[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] RE: policy control for AAA & common signalling application functi ons
hi robert,
if you look at the following figure (copy-and-paste from section 3.3 of
<draft-ietf-nsis-qos-nslp-03.txt>):
+-------------+
| Entity |
| authorizing |
| resource |
| request |
+-----+-------+
|
|
/-\----+-----/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+-------------+ QoS signaling +---+--+
| Entity |<=================>| |<=========>
| requesting | Data Flow | QNE |
| resource |-------------------|------|---------->
+-------------+ +------+
the information carried
- between the end host and the QNE and
- the QNE and the AAA infrastructure
needs to match.
there are certainly some requirements on the protocol handling on both
protocols.
ciao
hannes
> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> Sent: Wednesday, May 26, 2004 2:09 PM
> To: Tschofenig Hannes; 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> Cc: nsis at ietf.org
> Subject: RE: policy control for AAA & common signalling application
> functi ons
>
>
> this is part of what I think is being discussed.
>
> i think a very reasonable deployment approach is to consider
> that node B uses a backhaul protocol (like radius or diameter
> or cops or even ldap or ...) to find out the answer, and that
> how to do this shouldn't be re-invented for every different
> type of answer that one wants. but i'm not certain how much
> impact this should have on the wire protocol itself as compared
> to the implementation inside the node.
>
> r.
>
> -----Original Message-----
> From: Tschofenig Hannes [mailto:hannes.tschofenig at siemens.com]
> Sent: Wednesday, May 26, 2004 12:17 PM
> To: Hancock, Robert; 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> Cc: nsis at ietf.org
> Subject: policy control for AAA & common signalling application
> functions
>
>
> hi robert,
> hi dave,
>
> dave, you raised a very interesting issue in one of your mails:
>
> "is the aaa functionality a common part for all applications? "
>
> apart from the fact that the term "AAA" is confusing which i
> had to notice
> already with one of my previous drafts i think that this is a
> perfectly
> valid question. in fact i came accross this issue in our work
> on the nat/fw
> nslp.
>
> in particular you seem to point to the following problem:
>
> - you have an nsis node A and an nsis node B.
> - nsis node A needs to authenticate itself to node B and more
> important to
> be authorized todo certain actions.
> - however, node B might not be able to make this decision.
> instead it needs
> to ask another third entity to make this decision.
>
> is my interpretation on this correct?
>
> ciao
> hannes
>
>
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> > Sent: Monday, May 24, 2004 5:59 PM
> > To: 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> > Cc: nsis at ietf.org
> > Subject: RE: [NSIS] common signalling application functions
> >
> >
> > [Apologies for the late reply:]
> >
> > Hi,
> >
> > Considering the various options discussed:
> >
> > 1. I suspect it's nicer to have a dedicated toolbox that to
> > have re-use bits and pieces of insides of NSLPs (at least at an
> > early stage). But that requires more work and organisation and
> > documents, so it's really a question of energy ("good stuff"
> > as Dave describes it does not come free.) After repeated calls
> > for input on this subject during the framework development, we
> > didn't get very far (Bob made similar comments when the purpose
> > of the signalling analysis work was being discussed), so I think
> > it's probably best to consider addressing these problems in a
> > 'bottom up' way at least for now.
> >
> > 2. I'm opposed to integrating this stuff into GIMPS. GIMPS
> > has enough non-trivial things to do without adding more things
> > which don't have a strong interaction with its transport
> > functions.
> >
> > 3. I checked Dave's list of common functions to see how these
> > things are currently being progressed, if at all. Here is my
> > perception:
> >
> > *) precedence and pre-emption: the QoS model people have included
> > a proposal in their latest draft. That could be evaluated from the
> > perspective of other application users.
> >
> > *) separation of reserve and commit phases: at the moment, I still
> > don't see _how_ this can be treated independently of the resource
> > description issue (not why it is necessary to do so), and why
> > finessing it as part of the resource description is a bad idea.
> >
> > *) fate sharing: if this is a reference to wanting the
> state installed
> > for one application to be conditional on the state installed for
> > another application in failure cases, this was actually discussed
> > at length in the requirements phase and agreed to be a
> > non-requirement.
> > The reason is that it can get almost unboundedly complex to do this
> > in the network, and you can never do as good a job as in the end
> > system; so, why go for extra efficiency in the form of
> network support
> > when this is just to handle exceptional (failure) cases. but see
> > also the next point:
> >
> > *) inter-nslp binding: there probably is an issue about setting up
> > signalling state for multiple signalling applications needing
> > inter-NSLP interactions and hence possibly several round trips.
> > I think we need examples of this to work on understanding what a
> > general solution would look like. We do know there is a problem with
> > NAT/other-NSLP interactions, but that is also a problem which affect
> > GIMPS as well, so I would like to see how that works out before
> > considering the case extending to a more general concern.
> >
> > *) policy control for AAA, etc.: I have to admit I don't really
> > understand this one. If it is a matter of having unified handling
> > of NSIS resource requests in the context of a AAA architecture, it
> > is clearly a Good Thing; however, how much does it relate to common
> > interactions within a node rather than having an impact on the wire
> > NSIS protocols themselves?
> >
> > *) route recording: i can see this as being a common (i.e.
> shareable)
> > object - provided the applications can agree on what
> information about
> > the route to record (node ingress address, node egress
> address, ports,
> > node FQDNs...). I think this sort of thing would best be handled
> > as a set of common diagnostic objects; Xiaoming has already done
> > some thinking here AFAIK.
> >
> > *) explicit routing: *IF* this was to be supported as a function I
> > think it would have to be in the transport in some form. I raised
> > a previous email on whether this would ever be the case
> (i.e. in what
> > sense explicit routing would be part of NSIS scope) which
> > didn't really
> > get discussed much (see the archive around 20/04); in any case,
> > it is becoming clearer how to fit variable message routing methods
> > into GIMPS (NATFW requires it IIRC) and this would just be one more.
> >
> > *) resource sharing: i think this has to be in the NSLP.
> >
> > So, at the moment, while seeing that it is probably a good thing
> > for the NSIS 'architecture' to enable some commonality between
> > signalling applications, the best specific cases are already being
> > worked on.
> >
> > robert h.
> >
> > > -----Original Message-----
> > > From: Yacine.El_Mghazli at alcatel.fr
> > > [mailto:Yacine.El_Mghazli at alcatel.fr]
> > > Sent: Friday, April 30, 2004 15:24
> > > To: David Oran
> > > Cc: john.loughney at nokia.com; Ruediger.Geib at t-systems.com; Hancock,
> > > Robert; nsis at ietf.org; Tschofenig Hannes
> > > Subject: Re: [NSIS] common signalling application
> functions (was RE:
> > > Tentative Interi m Meeting schedule)
> > >
> > >
> > > dear all,
> > >
> > > I participated into the design of the AAA in the QoS-NSLP
> > > together with
> > > hannes. I tend to agree that this should fall into the
> > > so-called 'common
> > > sig app functions' block.
> > >
> > > moreover when examinating the dave's list of targetted
> > > applications, we
> > > could even narrow the scope of such a common block to AAA
> > (at large...
> > > let's say 'policy'). concerning the design alternative
> > > (rüdiger mentions
> > > 'toolbox' vs. cross-ref between NSLPs), IMO the first one
> > > should lead to
> > > a cleaner design and avoid doing twice the same thing.
> > >
> > > I have finally a couple of comments/questions:
> > >
> > > 1) did you consider integrating such a generic 'toolbox' into
> > > GIMPS ? or
> > > maybe the WG wants GIMPS to keep strictly relating to transport ?
> > >
> > > I would suggest to copy the RSVP design here: a generic
> > > POLICY_DATA TLV
> > > in GIMPS, which contains a list of Policy Element (PE)
> > objects. those
> > > PEs would be designed separately and I'm pretty sure a couple
> > > of already
> > > RFCed PEs could even be re-used as is.
> > >
> > > 2) does the working group think that the design of such
> > > generic objects
> > > will come together with some kind of framework ? authz protocols ?
> > > requirements ?
> > >
> > >
> > > thanks,
> > > yacine
> > >
> > >
> > >
> > >
> > >
> > > David Oran wrote:
> > >
> > > > --On Thursday, April 29, 2004 1:09 PM +0300
> > john.loughney at nokia.com
> > > > wrote:
> > > >
> > > >> Robert,
> > > >>
> > > >>> 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?
> > > >>
> > > >>
> > > >> Rüdiger's mail arrived first, so I didn't see your
> mail where you
> > > >> suggested it was Diameter-like ...
> > > >>
> > > >> Anyhow, I support your suggestion. Dave, would this
> > address your
> > > >> concerns at all?
> > > >>
> > > > It solves the pragmatic problems of encoding and abstract
> > > syntax, but
> > > > by itself does not ensure that the design of the common
> > functions is
> > > > in fact carefully done with the goal of generality and
> > extensibility
> > > > across NLSPs.
> > > >
> > > > So, this is progress, yes.
> > > >
> > > > Many of these common functions have impact similar to
> designing an
> > > > NLSP itself. It would be good if we could tackle them
> > directly with
> > > > people identified to do the work and ensure it meets the
> > > needs of the
> > > > NLSPs we know about and that the specification is clean
> clear, and
> > > > all that other good stuff.
> > > >
> > > > I think we still need further discussion of the related
> > problem of
> > > > ordering among NLSPs so that things like NAT
> translations and QoS
> > > > flow classifiers work together and don't need multiple RTTs to
> > > > establish state.
> > > >
> > > > Dave.
> > > >
> > > >
> > > >> John
> > > >>
> > > >> _______________________________________________ nsis
> > mailing list
> > > >> nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________ nsis
> mailing list
> > > > nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> --
>
> Visit our website at www.roke.co.uk
>
> Registered Office: Roke Manor Research Ltd, Siemens House,
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third
> party without
> permission. This communication is for information only and
> shall not create or
> change any contractual relationship.
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis