[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Outsourcing and Provisioning common model
The notion of converging the Outsourcing and Provisioning model was first
raised in the context of the Access Bind PIB. The reason was that Access
Bind is in effect designed to configure/provision the criteria for
signalling (outsourcing) a request to the PDP. It was explicitly designed to
allow a PEP to be provisioned with both the criteria for initiating an
outsource request (in our case the detection of a new session) and to also
provision the PEP with the pieces of information that should be passed with
the request (port, headers, etc.)
The reason why normalization of Outsourcing and Provisioning was raised was
because we realized that this PIB could also be used to provision a PEP to
detect and notify the PDP when RSVP PATH/RESV messages were detected. What
was even more interesting was that by using this PIB for RSVP outsouring, we
could provide far more than just a YES or NO answer to the PEP. We could in
fact use the DS and Framework PIBs to explicitly specify the QoS semantics
for the reservation. Since very few switches in fact support WFQ on a per
reservation basis, this allows the PDP to use the PIB Capabilities semantics
to assign the optimal router components to meet the reservation
requirements.
As such the arguement for normalization is to take the best of both COPS and
COPS-PR, and merge them together. The question is how much should this
normalization depend explicitly on the Access Bind PIB? At the meeting, I
believe Shai argued that he would like to see some of these concepts moved
from the Access Bind PIB to the Framework PIB.
regards,
-Walter
> -----Original Message-----
> From: Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com]
> Sent: Thursday, January 31, 2002 10:38 AM
> To: rap@ops.ietf.org
> Subject: Re: Outsourcing and Provisioning common model
>
>
>
> Hi everybody,
>
> I'm also interested in this presentation at 52th IETF. This
> mode take advantage
> of both the dynamicity of Outsourcing mode and the
> flexibility of using PIB of
> Configuration mode. I had a question about "What type of
> ClientSI (Signaled
> ClientSI or Named ClientSI) we can use in the unifed mode?"
> that was supposed to
> discussed in the mailling list.
>
> I would like to know in COPS-UMTS, which type of ClientSI
> object is intended to
> be used?
>
> In my opinon, and also in COPS-SLS, I used Signaled ClientSI
> because the
> objective of the information in the clientSI object is
> signalling in despite of
> their form of PIB. I preferes the terminology "Using PIB in
> Outsourcing mode" to
> "Using COPS-PR in Outsourcing mode" because, for me, COPS-PR
> is already the
> provisioning mode. "Using Provisioning mode in Outsourcing
> mode" sounds not
> logic :-)
>
> What do you think about it?
> Thanks,
> Mai Trang
>
> Yacine El Mghazli wrote:
>
> > Hi everybody,
> >
> > At the last IETF meeting, Shai Herzog launched a discussion
> about a COPS
> > common model merging both outsourcing and provisioning
> modes. The fact was
> > that some recent drafts use COPS-PR to OUTSOURCE
> information towards the PDP
> > (umts, access-bind, sls...) and the goal was to identify
> where the 2 modes
> > meets and to agree on a common model.
> >
> > This discussion was supposed to take place on the mailing
> list, but...
> > doesnt come !
> >
> > Speaking as a co-author of the cops-sls draft, I'm
> wondering about this
> > common model and, after all, about the future of such practises.
> >
> > thanks,
> > yacine
> >
> > -- Yacine El Mghazli
> >
> ----------------------------------------------------------------------
> > Alcatel R&I
> > Next Generation Router & Cross-Connect - NGRX
> > Marcoussis, France
> > Tel +33 1 6963 4187
> > Fax +33 1 6963 1169
> > yacine.el_mghazli@alcatel.fr
> >
> ----------------------------------------------------------------------
> >
> > ----- Original Message -----
> > From: "Da Silva, Pedro" <pdasilva@orchestream.com>
> > To: <rap@ops.ietf.org>
> > Sent: Thursday, January 31, 2002 12:08 PM
> > Subject: RE: A question about SPPI
> >
> > > Man, Ravi,
> > >
> > > The uniqueness clause also states that "The specified set
> of attributes
> > > provide a necessary and sufficient set of values by which
> to identify an
> > > instance of this PRC".
> > > As such does an optional attribute constitute a necessary one for
> > UNIQUENESS
> > > clauses?
> > > Also, considering the case where a UNIQUENESS clause's
> set is composed of
> > > optional attributes only, does that constitute a
> sufficient set by which
> > to
> > > identify an instance of the PRC?
> > >
> > > cheers,
> > > Pedro
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com]
> > > Sent: Wednesday, January 30, 2002 11:50 PM
> > > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org
> > > Subject: RE: A question about SPPI
> > >
> > >
> > > Man Li,
> > >
> > > The UNIQUENESS clause itself is optional. The SPPI does
> > > not put any constraints on which attributes can be specified
> > > in this clause other than -
> > > 1. The attribute named in the PIB-INDEX clause may not be
> > > present in the UNIQUENESS clause.
> > > 2. An attribute may not appear more than once in a UNIQUENESS
> > > clause.
> > >
> > > So, yes, the UNIQUNESS clause can contain optional attributes
> > > as long as it follows the rules above.
> > >
> > > Hope that helps,
> > > Ravi
> > >
> > > -----Original Message-----
> > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> > > Sent: Monday, January 28, 2002 11:08 AM
> > > To: rap@ops.ietf.org
> > > Subject: A question about SPPI
> > >
> > >
> > > In a PIB table, some attributes can be optional. Should
> the UNIQUENESS
> > > clause exclude optional attributes? In other words, can a
> UNIQUENESS
> > clause
> > > contain any optional attributes?
> > >
> > > Man Li
> > >
>
> --
> ----------------------------------------------------
> Nguyen Thi Mai Trang
> Ecole Nationale Superieure des Telecommunications
> Dept. INFRES - Bur. C234-4
> 46 Rue Barrault - 75013 Paris
> Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19
> email : trnguyen@enst.fr
>
>
>