From owner-rap@ops.ietf.org Fri Feb 2 18:48:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05600 for ; Fri, 2 Feb 2001 18:48:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Opth-0008pH-00 for rap-data@psg.com; Fri, 02 Feb 2001 15:45:45 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14Optg-0008oL-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 15:45:44 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 18:36:30 -0500 Message-ID: From: "Weiss, Walter" To: Yoram Bernet , Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 2 Feb 2001 18:36:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D70.F7BD1DD6" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08D70.F7BD1DD6 Content-Type: text/plain; charset="iso-8859-1" Yoram, The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards, -Walter > -----Original Message----- > From: Yoram Bernet [mailto:yoramb@microsoft.com] > Sent: Wednesday, January 17, 2001 12:23 PM > To: Ron Cohen; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for the comments. This is getting complicated enouhg > to warrant some > face to face discussion. In any case, some responses below: > > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the > sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > > The application may or may not know this. For example - an > application might > (in response to failed admission control, but not the 'do not > send' message) > defer to the user, with a UI of the form: "You will not be > granted QoS for > this session. You may: 1) try your call again later 2) > proceed with no qos > 3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > T-1 button). > > > (2) Whether it supports the new instructions. > > As i'll explain below - an application could tell you this, > but I don't > think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > > I beleive that - if you add to a protocol - you must be able > to explain > specifically how the addition will change the behaviour of > the peers that > participate in the protocol. You do take a stab at this > below, but - as I > will show, i'm not sure that the behaviours you propose > really work. If we > conclude that there are no valuable behavioural changes that > result from the > protocol addition, then I don't think it can be justified on > the abstract > basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. > Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > This approach suffers from a number of problems. > > First of all - it largely removes the incentive for an > application to be > well-behaved. If the application is not upgraded, it at least > gets to try to > get service. If it's upgraded - it gets completely denied. > Why should an > application upgrade? > > Second - if you have the means in the network to provide > traffic separation, > then you should apply this means regardless of what the app > says or does not > say it will do. In other words - the signaling provides you with the > classification information that you need to recognize the > flow of interest. > If you have the ability to use this classification info to > downgrade the > priority of the traffic in the WAN, then you should do so - > regardless. Thus > - your behaviour would not change because the app claims to > be well behaved. > > The 'do not send' policy is primarily intended for networks > that do not have > the ability to offer traffic separation between b/e and lbe. On these > networks, the choice of the netadmin is to 1) allow the app > to be deployed, > regardless of its behaviour, thereby running the risk that > the wan resources > will be trashed. 2) refuse to deploy the app on the wan. 3) > allow the app to > be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > > Indeed, the hypothetical parameter could tell the pdp that > the app would or > would not do something. but - i maintain that you still would > have to apply > the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the > Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > > I imagined that there would be one resource counter for each > service level > (except b/e and lbe). The counter would be conditionally > debited as soon as > a path message is seen. The debit could be reversed if the > reservation is > denied. This does result in brief underestimations of > available resources, > but - this situation occurs in many scenarios and doesn't > strike me as a > problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > > If the sender is going to send without a reservation, the > sender will not > consume resources at a prioritized service level. The > sender's traffic will > be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > > As I proposed the protocol exchanges, there would be no additional > information in the 'query' or the application's message to > the network (the > path message in this case). The additional information would > be only in the > 'response' (the path_err message). As you propose it, there would be > additional info in both. If you were to for example, build a protocol > simulator/tester, your approach is more complex to model (and > therefore, to > implement, to test and to operate). Unless you can show a > concrete benefit > of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before > sending the > > traffic. It can send this information in the Path message. > > > > As stated in my earlier comments, the application may defer > this choice to > the user. The network should not need to behave differently > on this basis. > > > >It is true that this alternative would give the PEP/PDP > some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this > justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > > Sorry - by 'protocol exchange' I meant, 'additional > information carried in > protocol messages which require additional parsing, > additional decision > making and may alter the progression of a protocol exchange'. > > Regards, > Yoram > ------_=_NextPart_001_01C08D70.F7BD1DD6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a = service level. One of the main concerns I have with this proposal is = that only one side is being told of a specific (less optimal)service = alternative. In order to preserve the end-to-end nature of RSVP, one = alternative possiblity (suggested by Bob B.), might be to send a = ResvErr back to the receiver with a flowspec that has a higher = probability of success. This would allow the receiver to send a revised = Resv back to the sender allowing for both a viable reservation (with = all it's properties), as well as the most ideal DSCP = mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 = PM
> To: Ron Cohen; rap@ops.ietf.org
> Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Ron:
>
> Thanks for the comments. This is getting = complicated enouhg
> to warrant some
> face to face discussion. In any case, some = responses below:
>
> > After thinking on this subject for a = while, I agree that
> > there needs to be
> > a parameter (forget formats for a minute) = returned to the
> sender that
> > differs between do-not-send and = no-QoS-admission failures.
> > Otherwise the
> > solution is not flexible enough.
> >
> > I (still) think that its required to let = the PDP know two
> > things in the
> > Path message.
> > (1) Its behavior (the fact that its going = to send traffic in
> > the specified
> > TSPEC regardless of successful QoS = admission).
>
> The application may or may not know this. For = example - an
> application might
> (in response to failed admission control, but = not the 'do not
> send' message)
> defer to the user, with a UI of the form: = "You will not be
> granted QoS for
> this session. You may: 1) try your call again = later 2)
> proceed with no qos
> 3) retry with a lesser codec (e.g. press the 56 = Kbps button
> instead of the
> T-1 button).
>
> > (2) Whether it supports the new = instructions.
>
> As i'll explain below - an application could = tell you this,
> but I don't
> think it affords you to behave any = differently...
> >
> > I'll try to give examples why these are = needed below, but
> > regardless of
> > providing a set of persuading examples, I = believe in smart
> > networks and
> > policy makers to allow flexible policy = enforcement, and
> > therefore I believe
> > in the necessity to add this information = to the Path message.
>
> I beleive that - if you add to a protocol - you = must be able
> to explain
> specifically how the addition will change the = behaviour of
> the peers that
> participate in the protocol. You do take a stab = at this
> below, but - as I
> will show, i'm not sure that the behaviours you = propose
> really work. If we
> conclude that there are no valuable behavioural = changes that
> result from the
> protocol addition, then I don't think it can be = justified on
> the abstract
> basis of "smart networks and felxible = policy enforcement".
> 
> >
> > Example 1: transition period - why (2) is = needed:
> >
> > Suppose we have a network environment = where on some hosts an
> > application x
> > is upgraded to support the new standard = and some are not.
> Suppose the
> > application is sending traffic regardless = of successful RSVP
> > setup. The
> > administrator must control the application = on both upgraded
> > an not-upgraded
> > hosts and make sure that these do not harm = the WAN traffic. For the
> > upgraded applications Path-Err will = instruct them to shut up.
> > For the older
> > ones, the only option is to map them to = LBE. Therefore the
> > policy specified
> > would be something of the form:
> >
> > If (app=3Dx AND upgraded) deny
> > If (app=3Dx AND not-upgraded) admit and = set DSCP to LBE.
>
> This approach suffers from a number of = problems.
>
> First of all - it largely removes the incentive = for an
> application to be
> well-behaved. If the application is not = upgraded, it at least
> gets to try to
> get service. If it's upgraded - it gets = completely denied.
> Why should an
> application upgrade?
>
> Second - if you have the means in the network = to provide
> traffic separation,
> then you should apply this means regardless of = what the app
> says or does not
> say it will do. In other words - the signaling = provides you with the
> classification information that you need to = recognize the
> flow of interest.
> If you have the ability to use this = classification info to
> downgrade the
> priority of the traffic in the WAN, then you = should do so -
> regardless. Thus
> - your behaviour would not change because the = app claims to
> be well behaved.
>
> The 'do not send' policy is primarily intended = for networks
> that do not have
> the ability to offer traffic separation between = b/e and lbe. On these
> networks, the choice of the netadmin is to 1) = allow the app
> to be deployed,
> regardless of its behaviour, thereby running = the risk that
> the wan resources
> will be trashed. 2) refuse to deploy the app on = the wan. 3)
> allow the app to
> be deployed only if it is well-behaved.
>
> >
> > The PDP can know if the app is upgraded if = the additional
> > object/parameter
> > appears in the path message.
> > Any alternative would force the = administrator to add a list
> > of hosts where
> > the application is upgraded and where it = is not. This would
> > be a nightmare.
>
> Indeed, the hypothetical parameter could tell = the pdp that
> the app would or
> would not do something. but - i maintain that = you still would
> have to apply
> the same behaviour, regardless.
> >
> > Example 2: why (1) is needed:
> >
> > The policy I want to enforce on a WAN = interface is the following:
> >
> > Don't admit QoS request beyond X = kb/s
> > Don't allow sending beyond Y kb/s
> >
> > To implement this policy I have two = counters in my PDP:
> > Counter x measures the amount of admitted = bandwidth for QoS.
> > It is updated
> > for each successful Resv using the RSPEC = carried in the
> Resv message.
> > Counter y measures the amount of traffic = sent by the sender
> > as declared in
> > the Path TSPEC. When should I update this = counter? If traffic
> > is sent only
> > after successful admission, I should = update the counter with
> > the Path TSPEC
> > only after successful admission of the = Resv message.
> > Otherwise, I will
> > reject Path messages sent by other hosts = before I'm sure that
> > this is the
> > actual TSPEC used, and not the reduced = TSPEC that can be negotiated
> > following admission failure.
>
> I imagined that there would be one resource = counter for each
> service level
> (except b/e and lbe). The counter would be = conditionally
> debited as soon as
> a path message is seen. The debit could be = reversed if the
> reservation is
> denied. This does result in brief = underestimations of
> available resources,
> but - this situation occurs in many scenarios = and doesn't
> strike me as a
> problem.
>
> > If the sender is going to send traffic in = any case, without
> > waiting for
> > successful Resv message, I should update = the counter when the
> > Path message
> > arrives, as I must guard against a = situation where a Resv
> > will not arrive
> > at all.
>
> If the sender is going to send without a = reservation, the
> sender will not
> consume resources at a prioritized service = level. The
> sender's traffic will
> be in be or lbe and therefore, need not be = counted.
>
> > See some minor remarks inline as = well
> >
> > >2. It would complicate the protocol = exchange - instead of
> > relying solely on
> > >a response from the network indicating = that the network does
> > not want the
> > >app to send, this would require both a = query from the
> > application and a
> > >response from the network.
> >
> > I'm not sure what you mean by query and = response. We are
> > talking on the
> > normal RSVP messages exchange. Path = downstream, Resv or
> > Path-Err upstream.
> >
>
> As I proposed the protocol exchanges, there = would be no additional
> information in the 'query' or the application's = message to
> the network (the
> path message in this case). The additional = information would
> be only in the
> 'response' (the path_err message). As you = propose it, there would be
> additional info in both. If you were to for = example, build a protocol
> simulator/tester, your approach is more complex = to model (and
> therefore, to
> implement, to test and to operate). Unless you = can show a
> concrete benefit
> of the added complexity, I oppose the added = complexity.
>
> > >I'm not sure why it is necessary to = pigeonhole applications
> > as one or the
> > >other. The same application may use = different strategies at
> > different times.
> > >For example, an application might try = lesser codecs until it
> > finds that none
> > >are acceptable by the network, at = which time it would just
> > not send (or
> > >alternatively, send with best-effort). = Such an application
> > is both of the
> > >type that is going to send anyhow = (unless prohibited) and
> > simultaneously of
> > >the type that is going to renegotiate. = Again - the
> > distinction you draw
> > >seems to just complicate the set of = application behaviours.
> >
> > You don't pigeonhole applications, you = describe their
> > behavior for each
> > flow they intend to send. In each round, = the application
> > sends different
> > Path messages (different TSPECs according = to codecs), it also
> > knows whether
> > it is going to wait for a successful Resv = message before
> sending the
> > traffic. It can send this information in = the Path message.
> >
>
> As stated in my earlier comments, the = application may defer
> this choice to
> the user. The network should not need to behave = differently
> on this basis.
>
> > >It is true that this alternative would = give the PEP/PDP
> some explicit
> > >information about the application. = However - i'm not sure
> > what the PEP/PDP
> > >would do differently based on this = information. Unless the
> > PEP/PDP does
> > >something useful and different, i'm = not sure that this
> justifies the
> > >additional protocol exchange.
> >
> > There is no additional protocol = exchange.
> >
>
> Sorry - by 'protocol exchange' I meant, = 'additional
> information carried in
> protocol messages which require additional = parsing,
> additional decision
> making and may alter the progression of a = protocol exchange'.
>
> Regards,
> Yoram
>

------_=_NextPart_001_01C08D70.F7BD1DD6-- From owner-rap@ops.ietf.org Fri Feb 2 19:17:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06396 for ; Fri, 2 Feb 2001 19:17:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OqNm-0009EA-00 for rap-data@psg.com; Fri, 02 Feb 2001 16:16:50 -0800 Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by psg.com with esmtp (Exim 3.16 #1) id 14OqNk-0009Dd-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 16:16:48 -0800 Received: from zsc4c000.us.nortel.com by ertpg14e1.nortelnetworks.com; Fri, 2 Feb 2001 19:02:02 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1AJ376XG>; Fri, 2 Feb 2001 16:01:56 -0800 Message-ID: <5546C40EAD51D311BD7A0008C7915476058F3230@zsc4c012.us.nortel.com> From: "Hesham Elbakoury" To: "Weiss, Walter" , Yoram Bernet , Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 2 Feb 2001 16:01:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D74.84F07DD0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08D74.84F07DD0 Content-Type: text/plain; charset="iso-8859-1" Hi Walter How the sender figure out the flowspec that has better luck to succeed ? Hesham -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Friday, February 02, 2001 3:36 PM To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards, -Walter > -----Original Message----- > From: Yoram Bernet [ mailto:yoramb@microsoft.com ] > Sent: Wednesday, January 17, 2001 12:23 PM > To: Ron Cohen; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for the comments. This is getting complicated enouhg > to warrant some > face to face discussion. In any case, some responses below: > > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the > sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > > The application may or may not know this. For example - an > application might > (in response to failed admission control, but not the 'do not > send' message) > defer to the user, with a UI of the form: "You will not be > granted QoS for > this session. You may: 1) try your call again later 2) > proceed with no qos > 3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > T-1 button). > > > (2) Whether it supports the new instructions. > > As i'll explain below - an application could tell you this, > but I don't > think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > > I beleive that - if you add to a protocol - you must be able > to explain > specifically how the addition will change the behaviour of > the peers that > participate in the protocol. You do take a stab at this > below, but - as I > will show, i'm not sure that the behaviours you propose > really work. If we > conclude that there are no valuable behavioural changes that > result from the > protocol addition, then I don't think it can be justified on > the abstract > basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. > Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > This approach suffers from a number of problems. > > First of all - it largely removes the incentive for an > application to be > well-behaved. If the application is not upgraded, it at least > gets to try to > get service. If it's upgraded - it gets completely denied. > Why should an > application upgrade? > > Second - if you have the means in the network to provide > traffic separation, > then you should apply this means regardless of what the app > says or does not > say it will do. In other words - the signaling provides you with the > classification information that you need to recognize the > flow of interest. > If you have the ability to use this classification info to > downgrade the > priority of the traffic in the WAN, then you should do so - > regardless. Thus > - your behaviour would not change because the app claims to > be well behaved. > > The 'do not send' policy is primarily intended for networks > that do not have > the ability to offer traffic separation between b/e and lbe. On these > networks, the choice of the netadmin is to 1) allow the app > to be deployed, > regardless of its behaviour, thereby running the risk that > the wan resources > will be trashed. 2) refuse to deploy the app on the wan. 3) > allow the app to > be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > > Indeed, the hypothetical parameter could tell the pdp that > the app would or > would not do something. but - i maintain that you still would > have to apply > the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the > Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > > I imagined that there would be one resource counter for each > service level > (except b/e and lbe). The counter would be conditionally > debited as soon as > a path message is seen. The debit could be reversed if the > reservation is > denied. This does result in brief underestimations of > available resources, > but - this situation occurs in many scenarios and doesn't > strike me as a > problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > > If the sender is going to send without a reservation, the > sender will not > consume resources at a prioritized service level. The > sender's traffic will > be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > > As I proposed the protocol exchanges, there would be no additional > information in the 'query' or the application's message to > the network (the > path message in this case). The additional information would > be only in the > 'response' (the path_err message). As you propose it, there would be > additional info in both. If you were to for example, build a protocol > simulator/tester, your approach is more complex to model (and > therefore, to > implement, to test and to operate). Unless you can show a > concrete benefit > of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before > sending the > > traffic. It can send this information in the Path message. > > > > As stated in my earlier comments, the application may defer > this choice to > the user. The network should not need to behave differently > on this basis. > > > >It is true that this alternative would give the PEP/PDP > some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this > justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > > Sorry - by 'protocol exchange' I meant, 'additional > information carried in > protocol messages which require additional parsing, > additional decision > making and may alter the progression of a protocol exchange'. > > Regards, > Yoram > ------_=_NextPart_001_01C08D74.84F07DD0 Content-Type: text/html; charset="iso-8859-1" RE: draft-santitoro-rap-policy-errorcodes-01.txt
Hi Walter
 
How the sender figure out the flowspec that has better luck to succeed ?
 
Hesham
-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; rap@ops.ietf.org
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Ron:
>
> Thanks for the comments. This is getting complicated enouhg
> to warrant some
> face to face discussion. In any case, some responses below:
>
> > After thinking on this subject for a while, I agree that
> > there needs to be
> > a parameter (forget formats for a minute) returned to the
> sender that
> > differs between do-not-send and no-QoS-admission failures.
> > Otherwise the
> > solution is not flexible enough.
> >
> > I (still) think that its required to let the PDP know two
> > things in the
> > Path message.
> > (1) Its behavior (the fact that its going to send traffic in
> > the specified
> > TSPEC regardless of successful QoS admission).
>
> The application may or may not know this. For example - an
> application might
> (in response to failed admission control, but not the 'do not
> send' message)
> defer to the user, with a UI of the form: "You will not be
> granted QoS for
> this session. You may: 1) try your call again later 2)
> proceed with no qos
> 3) retry with a lesser codec (e.g. press the 56 Kbps button
> instead of the
> T-1 button).
>
> > (2) Whether it supports the new instructions.
>
> As i'll explain below - an application could tell you this,
> but I don't
> think it affords you to behave any differently...
> >
> > I'll try to give examples why these are needed below, but
> > regardless of
> > providing a set of persuading examples, I believe in smart
> > networks and
> > policy makers to allow flexible policy enforcement, and
> > therefore I believe
> > in the necessity to add this information to the Path message.
>
> I beleive that - if you add to a protocol - you must be able
> to explain
> specifically how the addition will change the behaviour of
> the peers that
> participate in the protocol. You do take a stab at this
> below, but - as I
> will show, i'm not sure that the behaviours you propose
> really work. If we
> conclude that there are no valuable behavioural changes that
> result from the
> protocol addition, then I don't think it can be justified on
> the abstract
> basis of "smart networks and felxible policy enforcement".
> 
> >
> > Example 1: transition period - why (2) is needed:
> >
> > Suppose we have a network environment where on some hosts an
> > application x
> > is upgraded to support the new standard and some are not.
> Suppose the
> > application is sending traffic regardless of successful RSVP
> > setup. The
> > administrator must control the application on both upgraded
> > an not-upgraded
> > hosts and make sure that these do not harm the WAN traffic. For the
> > upgraded applications Path-Err will instruct them to shut up.
> > For the older
> > ones, the only option is to map them to LBE. Therefore the
> > policy specified
> > would be something of the form:
> >
> > If (app=x AND upgraded) deny
> > If (app=x AND not-upgraded) admit and set DSCP to LBE.
>
> This approach suffers from a number of problems.
>
> First of all - it largely removes the incentive for an
> application to be
> well-behaved. If the application is not upgraded, it at least
> gets to try to
> get service. If it's upgraded - it gets completely denied.
> Why should an
> application upgrade?
>
> Second - if you have the means in the network to provide
> traffic separation,
> then you should apply this means regardless of what the app
> says or does not
> say it will do. In other words - the signaling provides you with the
> classification information that you need to recognize the
> flow of interest.
> If you have the ability to use this classification info to
> downgrade the
> priority of the traffic in the WAN, then you should do so -
> regardless. Thus
> - your behaviour would not change because the app claims to
> be well behaved.
>
> The 'do not send' policy is primarily intended for networks
> that do not have
> the ability to offer traffic separation between b/e and lbe. On these
> networks, the choice of the netadmin is to 1) allow the app
> to be deployed,
> regardless of its behaviour, thereby running the risk that
> the wan resources
> will be trashed. 2) refuse to deploy the app on the wan. 3)
> allow the app to
> be deployed only if it is well-behaved.
>
> >
> > The PDP can know if the app is upgraded if the additional
> > object/parameter
> > appears in the path message.
> > Any alternative would force the administrator to add a list
> > of hosts where
> > the application is upgraded and where it is not. This would
> > be a nightmare.
>
> Indeed, the hypothetical parameter could tell the pdp that
> the app would or
> would not do something. but - i maintain that you still would
> have to apply
> the same behaviour, regardless.
> >
> > Example 2: why (1) is needed:
> >
> > The policy I want to enforce on a WAN interface is the following:
> >
> > Don't admit QoS request beyond X kb/s
> > Don't allow sending beyond Y kb/s
> >
> > To implement this policy I have two counters in my PDP:
> > Counter x measures the amount of admitted bandwidth for QoS.
> > It is updated
> > for each successful Resv using the RSPEC carried in the
> Resv message.
> > Counter y measures the amount of traffic sent by the sender
> > as declared in
> > the Path TSPEC. When should I update this counter? If traffic
> > is sent only
> > after successful admission, I should update the counter with
> > the Path TSPEC
> > only after successful admission of the Resv message.
> > Otherwise, I will
> > reject Path messages sent by other hosts before I'm sure that
> > this is the
> > actual TSPEC used, and not the reduced TSPEC that can be negotiated
> > following admission failure.
>
> I imagined that there would be one resource counter for each
> service level
> (except b/e and lbe). The counter would be conditionally
> debited as soon as
> a path message is seen. The debit could be reversed if the
> reservation is
> denied. This does result in brief underestimations of
> available resources,
> but - this situation occurs in many scenarios and doesn't
> strike me as a
> problem.
>
> > If the sender is going to send traffic in any case, without
> > waiting for
> > successful Resv message, I should update the counter when the
> > Path message
> > arrives, as I must guard against a situation where a Resv
> > will not arrive
> > at all.
>
> If the sender is going to send without a reservation, the
> sender will not
> consume resources at a prioritized service level. The
> sender's traffic will
> be in be or lbe and therefore, need not be counted.
>
> > See some minor remarks inline as well
> >
> > >2. It would complicate the protocol exchange - instead of
> > relying solely on
> > >a response from the network indicating that the network does
> > not want the
> > >app to send, this would require both a query from the
> > application and a
> > >response from the network.
> >
> > I'm not sure what you mean by query and response. We are
> > talking on the
> > normal RSVP messages exchange. Path downstream, Resv or
> > Path-Err upstream.
> >
>
> As I proposed the protocol exchanges, there would be no additional
> information in the 'query' or the application's message to
> the network (the
> path message in this case). The additional information would
> be only in the
> 'response' (the path_err message). As you propose it, there would be
> additional info in both. If you were to for example, build a protocol
> simulator/tester, your approach is more complex to model (and
> therefore, to
> implement, to test and to operate). Unless you can show a
> concrete benefit
> of the added complexity, I oppose the added complexity.
>
> > >I'm not sure why it is necessary to pigeonhole applications
> > as one or the
> > >other. The same application may use different strategies at
> > different times.
> > >For example, an application might try lesser codecs until it
> > finds that none
> > >are acceptable by the network, at which time it would just
> > not send (or
> > >alternatively, send with best-effort). Such an application
> > is both of the
> > >type that is going to send anyhow (unless prohibited) and
> > simultaneously of
> > >the type that is going to renegotiate. Again - the
> > distinction you draw
> > >seems to just complicate the set of application behaviours.
> >
> > You don't pigeonhole applications, you describe their
> > behavior for each
> > flow they intend to send. In each round, the application
> > sends different
> > Path messages (different TSPECs according to codecs), it also
> > knows whether
> > it is going to wait for a successful Resv message before
> sending the
> > traffic. It can send this information in the Path message.
> >
>
> As stated in my earlier comments, the application may defer
> this choice to
> the user. The network should not need to behave differently
> on this basis.
>
> > >It is true that this alternative would give the PEP/PDP
> some explicit
> > >information about the application. However - i'm not sure
> > what the PEP/PDP
> > >would do differently based on this information. Unless the
> > PEP/PDP does
> > >something useful and different, i'm not sure that this
> justifies the
> > >additional protocol exchange.
> >
> > There is no additional protocol exchange.
> >
>
> Sorry - by 'protocol exchange' I meant, 'additional
> information carried in
> protocol messages which require additional parsing,
> additional decision
> making and may alter the progression of a protocol exchange'.
>
> Regards,
> Yoram
>

------_=_NextPart_001_01C08D74.84F07DD0-- From owner-rap@ops.ietf.org Fri Feb 2 20:27:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08753 for ; Fri, 2 Feb 2001 20:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OrTD-000A9Q-00 for rap-data@psg.com; Fri, 02 Feb 2001 17:26:31 -0800 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8] helo=DF-INET-1.dogfoodinternet.com) by psg.com with esmtp (Exim 3.16 #1) id 14OrTC-000A8v-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 17:26:30 -0800 Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 2 Feb 2001 17:11:21 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Feb 2001 17:12:05 -0800 (Pacific Standard Time) Received: from DF-SCRAPPY.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Fri, 2 Feb 2001 17:10:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D7E.05CA4121" Date: Fri, 2 Feb 2001 17:09:56 -0800 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E629F55@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: draft-santitoro-rap-policy-errorcodes-01.txt Thread-Index: AcCNeB4COxdagdkDSGuukQ4UpGegRwAAZbQg From: "Ramesh Pabbati" To: "Weiss, Walter" , "Yoram Bernet" , "Ron Cohen" , Cc: "Ralph Santitoro" X-OriginalArrivalTime: 03 Feb 2001 01:10:00.0787 (UTC) FILETIME=[081CBA30:01C08D7E] Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C08D7E.05CA4121 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Walter, =20 One of the main aims of this draft is let the a class of sender know ASAP when there are no resources available to meet this requirements of this session. One such example is IP phones which operate with a fixed flowspec and receiver just a copy of sender Tspec. The PDP will return this specific error based on the application sending (i.e., receiver is not going provide PDP any more information beyond what is in the PATH message). By sending a ResvErr back to receiver and receiver sending this ResvErr indication using another control channel will add to delay in setting up the call. Some class of applications can not tolerate this delay, for those applications PDP will return this error code in PathErr message. Ralph can provide more details on this class of applications. =20 Ramesh -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Friday, February 02, 2001 3:36 PM To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram,=20 The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards,=20 -Walter=20 > -----Original Message-----=20 > From: Yoram Bernet [ mailto:yoramb@microsoft.com]=20 > Sent: Wednesday, January 17, 2001 12:23 PM=20 > To: Ron Cohen; rap@ops.ietf.org=20 > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt=20 >=20 >=20 > Ron:=20 >=20 > Thanks for the comments. This is getting complicated enouhg=20 > to warrant some=20 > face to face discussion. In any case, some responses below:=20 >=20 > > After thinking on this subject for a while, I agree that=20 > > there needs to be=20 > > a parameter (forget formats for a minute) returned to the=20 > sender that=20 > > differs between do-not-send and no-QoS-admission failures.=20 > > Otherwise the=20 > > solution is not flexible enough.=20 > >=20 > > I (still) think that its required to let the PDP know two=20 > > things in the=20 > > Path message.=20 > > (1) Its behavior (the fact that its going to send traffic in=20 > > the specified=20 > > TSPEC regardless of successful QoS admission).=20 >=20 > The application may or may not know this. For example - an=20 > application might=20 > (in response to failed admission control, but not the 'do not=20 > send' message)=20 > defer to the user, with a UI of the form: "You will not be=20 > granted QoS for=20 > this session. You may: 1) try your call again later 2)=20 > proceed with no qos=20 > 3) retry with a lesser codec (e.g. press the 56 Kbps button=20 > instead of the=20 > T-1 button).=20 >=20 > > (2) Whether it supports the new instructions.=20 >=20 > As i'll explain below - an application could tell you this,=20 > but I don't=20 > think it affords you to behave any differently...=20 > >=20 > > I'll try to give examples why these are needed below, but=20 > > regardless of=20 > > providing a set of persuading examples, I believe in smart=20 > > networks and=20 > > policy makers to allow flexible policy enforcement, and=20 > > therefore I believe=20 > > in the necessity to add this information to the Path message.=20 >=20 > I beleive that - if you add to a protocol - you must be able=20 > to explain=20 > specifically how the addition will change the behaviour of=20 > the peers that=20 > participate in the protocol. You do take a stab at this=20 > below, but - as I=20 > will show, i'm not sure that the behaviours you propose=20 > really work. If we=20 > conclude that there are no valuable behavioural changes that=20 > result from the=20 > protocol addition, then I don't think it can be justified on=20 > the abstract=20 > basis of "smart networks and felxible policy enforcement".=20 > =20 > >=20 > > Example 1: transition period - why (2) is needed:=20 > >=20 > > Suppose we have a network environment where on some hosts an=20 > > application x=20 > > is upgraded to support the new standard and some are not.=20 > Suppose the=20 > > application is sending traffic regardless of successful RSVP=20 > > setup. The=20 > > administrator must control the application on both upgraded=20 > > an not-upgraded=20 > > hosts and make sure that these do not harm the WAN traffic. For the=20 > > upgraded applications Path-Err will instruct them to shut up.=20 > > For the older=20 > > ones, the only option is to map them to LBE. Therefore the=20 > > policy specified=20 > > would be something of the form:=20 > >=20 > > If (app=3Dx AND upgraded) deny=20 > > If (app=3Dx AND not-upgraded) admit and set DSCP to LBE.=20 >=20 > This approach suffers from a number of problems.=20 >=20 > First of all - it largely removes the incentive for an=20 > application to be=20 > well-behaved. If the application is not upgraded, it at least=20 > gets to try to=20 > get service. If it's upgraded - it gets completely denied.=20 > Why should an=20 > application upgrade?=20 >=20 > Second - if you have the means in the network to provide=20 > traffic separation,=20 > then you should apply this means regardless of what the app=20 > says or does not=20 > say it will do. In other words - the signaling provides you with the=20 > classification information that you need to recognize the=20 > flow of interest.=20 > If you have the ability to use this classification info to=20 > downgrade the=20 > priority of the traffic in the WAN, then you should do so -=20 > regardless. Thus=20 > - your behaviour would not change because the app claims to=20 > be well behaved.=20 >=20 > The 'do not send' policy is primarily intended for networks=20 > that do not have=20 > the ability to offer traffic separation between b/e and lbe. On these=20 > networks, the choice of the netadmin is to 1) allow the app=20 > to be deployed,=20 > regardless of its behaviour, thereby running the risk that=20 > the wan resources=20 > will be trashed. 2) refuse to deploy the app on the wan. 3)=20 > allow the app to=20 > be deployed only if it is well-behaved.=20 >=20 > >=20 > > The PDP can know if the app is upgraded if the additional=20 > > object/parameter=20 > > appears in the path message.=20 > > Any alternative would force the administrator to add a list=20 > > of hosts where=20 > > the application is upgraded and where it is not. This would=20 > > be a nightmare.=20 >=20 > Indeed, the hypothetical parameter could tell the pdp that=20 > the app would or=20 > would not do something. but - i maintain that you still would=20 > have to apply=20 > the same behaviour, regardless.=20 > >=20 > > Example 2: why (1) is needed:=20 > >=20 > > The policy I want to enforce on a WAN interface is the following:=20 > >=20 > > Don't admit QoS request beyond X kb/s=20 > > Don't allow sending beyond Y kb/s=20 > >=20 > > To implement this policy I have two counters in my PDP:=20 > > Counter x measures the amount of admitted bandwidth for QoS.=20 > > It is updated=20 > > for each successful Resv using the RSPEC carried in the=20 > Resv message.=20 > > Counter y measures the amount of traffic sent by the sender=20 > > as declared in=20 > > the Path TSPEC. When should I update this counter? If traffic=20 > > is sent only=20 > > after successful admission, I should update the counter with=20 > > the Path TSPEC=20 > > only after successful admission of the Resv message.=20 > > Otherwise, I will=20 > > reject Path messages sent by other hosts before I'm sure that=20 > > this is the=20 > > actual TSPEC used, and not the reduced TSPEC that can be negotiated=20 > > following admission failure.=20 >=20 > I imagined that there would be one resource counter for each=20 > service level=20 > (except b/e and lbe). The counter would be conditionally=20 > debited as soon as=20 > a path message is seen. The debit could be reversed if the=20 > reservation is=20 > denied. This does result in brief underestimations of=20 > available resources,=20 > but - this situation occurs in many scenarios and doesn't=20 > strike me as a=20 > problem.=20 >=20 > > If the sender is going to send traffic in any case, without=20 > > waiting for=20 > > successful Resv message, I should update the counter when the=20 > > Path message=20 > > arrives, as I must guard against a situation where a Resv=20 > > will not arrive=20 > > at all.=20 >=20 > If the sender is going to send without a reservation, the=20 > sender will not=20 > consume resources at a prioritized service level. The=20 > sender's traffic will=20 > be in be or lbe and therefore, need not be counted.=20 >=20 > > See some minor remarks inline as well=20 > >=20 > > >2. It would complicate the protocol exchange - instead of=20 > > relying solely on=20 > > >a response from the network indicating that the network does=20 > > not want the=20 > > >app to send, this would require both a query from the=20 > > application and a=20 > > >response from the network.=20 > >=20 > > I'm not sure what you mean by query and response. We are=20 > > talking on the=20 > > normal RSVP messages exchange. Path downstream, Resv or=20 > > Path-Err upstream.=20 > >=20 >=20 > As I proposed the protocol exchanges, there would be no additional=20 > information in the 'query' or the application's message to=20 > the network (the=20 > path message in this case). The additional information would=20 > be only in the=20 > 'response' (the path_err message). As you propose it, there would be=20 > additional info in both. If you were to for example, build a protocol=20 > simulator/tester, your approach is more complex to model (and=20 > therefore, to=20 > implement, to test and to operate). Unless you can show a=20 > concrete benefit=20 > of the added complexity, I oppose the added complexity.=20 >=20 > > >I'm not sure why it is necessary to pigeonhole applications=20 > > as one or the=20 > > >other. The same application may use different strategies at=20 > > different times.=20 > > >For example, an application might try lesser codecs until it=20 > > finds that none=20 > > >are acceptable by the network, at which time it would just=20 > > not send (or=20 > > >alternatively, send with best-effort). Such an application=20 > > is both of the=20 > > >type that is going to send anyhow (unless prohibited) and=20 > > simultaneously of=20 > > >the type that is going to renegotiate. Again - the=20 > > distinction you draw=20 > > >seems to just complicate the set of application behaviours.=20 > >=20 > > You don't pigeonhole applications, you describe their=20 > > behavior for each=20 > > flow they intend to send. In each round, the application=20 > > sends different=20 > > Path messages (different TSPECs according to codecs), it also=20 > > knows whether=20 > > it is going to wait for a successful Resv message before=20 > sending the=20 > > traffic. It can send this information in the Path message.=20 > >=20 >=20 > As stated in my earlier comments, the application may defer=20 > this choice to=20 > the user. The network should not need to behave differently=20 > on this basis.=20 >=20 > > >It is true that this alternative would give the PEP/PDP=20 > some explicit=20 > > >information about the application. However - i'm not sure=20 > > what the PEP/PDP=20 > > >would do differently based on this information. Unless the=20 > > PEP/PDP does=20 > > >something useful and different, i'm not sure that this=20 > justifies the=20 > > >additional protocol exchange.=20 > >=20 > > There is no additional protocol exchange.=20 > >=20 >=20 > Sorry - by 'protocol exchange' I meant, 'additional=20 > information carried in=20 > protocol messages which require additional parsing,=20 > additional decision=20 > making and may alter the progression of a protocol exchange'.=20 >=20 > Regards,=20 > Yoram=20 >=20 ------_=_NextPart_001_01C08D7E.05CA4121 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
Walter,
 
One of=20 the main aims of this draft is let the a class of = sender know=20 ASAP when there are no resources available to meet this requirements of = this=20 session. One such example is IP phones which operate with a fixed = flowspec and=20 receiver just a copy of sender Tspec. The PDP will return this = specific=20 error based on the application sending (i.e., receiver is not going = provide PDP=20 any more information beyond what is in the PATH message). By sending a = ResvErr=20 back to receiver and receiver sending this ResvErr indication using = another=20 control channel will add to delay in setting up the call. Some class of=20 applications can not tolerate this delay, for those applications PDP = will return=20 this error code in PathErr message. Ralph can provide more details on = this class=20 of applications.
 
Ramesh
-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 = 3:36=20 PM
To: Yoram Bernet; Ron Cohen; = rap@ops.ietf.org
Subject:=20 RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a = service=20 level. One of the main concerns I have with this proposal is that only = one=20 side is being told of a specific (less optimal)service alternative. In = order=20 to preserve the end-to-end nature of RSVP, one alternative possiblity=20 (suggested by Bob B.), might be to send a ResvErr back to the receiver = with a=20 flowspec that has a higher probability of success. This would allow = the=20 receiver to send a revised Resv back to the sender allowing for both a = viable=20 reservation (with all it's properties), as well as the most ideal DSCP = mapping.

regards,

-Walter

> -----Original Message-----
>=20 From: Yoram Bernet [mailto:yoramb@microsoft.com]=20
> Sent: Wednesday, January 17, 2001 12:23 = PM=20
> To: Ron Cohen; rap@ops.ietf.org =
> Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt=20
>
> =
> Ron:
>
>=20 Thanks for the comments. This is getting complicated enouhg =
> to warrant some
> face to = face=20 discussion. In any case, some responses below:
>=20
> > After thinking on this subject for = a while,=20 I agree that
> > there needs to be=20
> > a parameter (forget formats for a = minute)=20 returned to the
> sender that =
> > differs between do-not-send and no-QoS-admission = failures.=20
> > Otherwise the
>=20 > solution is not flexible enough.
> = >=20
> > I (still) think that its required = to let the=20 PDP know two
> > things in the =
> > Path message.
> > = (1) Its=20 behavior (the fact that its going to send traffic in
> > the specified
> > = TSPEC=20 regardless of successful QoS admission).
>=20
> The application may or may not know = this. For=20 example - an
> application might =
> (in response to failed admission control, but not the = 'do not=20
> send' message)
> defer=20 to the user, with a UI of the form: "You will not be
> granted QoS for
> this = session. You=20 may: 1) try your call again later 2)
> = proceed with=20 no qos
> 3) retry with a lesser codec = (e.g. press=20 the 56 Kbps button
> instead of = the=20
> T-1 button).
>=20
> > (2) Whether it supports the new=20 instructions.
>
> As=20 i'll explain below - an application could tell you this, =
> but I don't
> think it = affords you to=20 behave any differently...
> > =
> > I'll try to give examples why these are needed = below, but=20
> > regardless of
>=20 > providing a set of persuading examples, I believe in smart=20
> > networks and
>=20 > policy makers to allow flexible policy enforcement, and =
> > therefore I believe
> = > in the=20 necessity to add this information to the Path message. =
>
> I beleive that - if you = add to a=20 protocol - you must be able
> to = explain=20
> specifically how the addition will change the = behaviour=20 of
> the peers that
>=20 participate in the protocol. You do take a stab at this =
> below, but - as I
> will = show, i'm not=20 sure that the behaviours you propose
> = really work.=20 If we
> conclude that there are no = valuable=20 behavioural changes that
> result from = the=20
> protocol addition, then I don't think it can = be=20 justified on
> the abstract =
> basis of "smart networks and felxible policy = enforcement".=20
> 
> > =
> > Example 1: transition period - why (2) is = needed:=20
> >
> > = Suppose we have a=20 network environment where on some hosts an
> >=20 application x
> > is upgraded to = support the new=20 standard and some are not.
> Suppose the=20
> > application is sending traffic = regardless of=20 successful RSVP
> > setup. The =
> > administrator must control the application on both = upgraded=20
> > an not-upgraded
>=20 > hosts and make sure that these do not harm the WAN traffic. For = the=20
> > upgraded applications Path-Err = will instruct=20 them to shut up.
> > For the older=20
> > ones, the only option is to map = them to LBE.=20 Therefore the
> > policy specified=20
> > would be something of the = form:=20
> >
> > If = (app=3Dx AND=20 upgraded) deny
> > If (app=3Dx AND = not-upgraded)=20 admit and set DSCP to LBE.
> =
> This approach suffers from a number of problems. =
>
> First of all - it largely = removes the=20 incentive for an
> application to = be=20
> well-behaved. If the application is not = upgraded, it at=20 least
> gets to try to
>=20 get service. If it's upgraded - it gets completely denied. =
> Why should an
> application = upgrade?
>
> = Second - if=20 you have the means in the network to provide
>=20 traffic separation,
> then you should = apply this=20 means regardless of what the app
> says = or does=20 not
> say it will do. In other words - = the=20 signaling provides you with the
> = classification=20 information that you need to recognize the
> flow=20 of interest.
> If you have the ability to = use this=20 classification info to
> downgrade = the=20
> priority of the traffic in the WAN, then you = should do=20 so -
> regardless. Thus
> - your behaviour would not change because the app claims = to=20
> be well behaved.
>=20
> The 'do not send' policy is primarily = intended=20 for networks
> that do not have =
> the ability to offer traffic separation between b/e and = lbe. On=20 these
> networks, the choice of the = netadmin is to=20 1) allow the app
> to be deployed, =
> regardless of its behaviour, thereby running the risk = that=20
> the wan resources
>=20 will be trashed. 2) refuse to deploy the app on the wan. 3) =
> allow the app to
> be = deployed only if=20 it is well-behaved.
>
>=20 >
> > The PDP can know if the app = is upgraded=20 if the additional
> > object/parameter =
> > appears in the path = message.=20
> > Any alternative would force the = administrator to=20 add a list
> > of hosts where =
> > the application is upgraded and where it is not. = This would=20
> > be a nightmare.
>=20
> Indeed, the hypothetical parameter = could tell the=20 pdp that
> the app would or =
> would not do something. but - i maintain that you still = would=20
> have to apply
> the=20 same behaviour, regardless.
> > =
> > Example 2: why (1) is needed:
>=20 >
> > The policy I want to enforce = on a WAN=20 interface is the following:
> > =
> > Don't admit QoS request beyond X kb/s =
> > Don't allow sending beyond Y kb/s
> >
> > To implement = this policy I=20 have two counters in my PDP:
> > = Counter x=20 measures the amount of admitted bandwidth for QoS.
> > It is updated
> > = for each=20 successful Resv using the RSPEC carried in the
>=20 Resv message.
> > Counter y measures = the amount=20 of traffic sent by the sender
> > as = declared in=20
> > the Path TSPEC. When should I = update this=20 counter? If traffic
> > is sent only=20
> > after successful admission, I = should update=20 the counter with
> > the Path TSPEC=20
> > only after successful admission of = the Resv=20 message.
> > Otherwise, I will =
> > reject Path messages sent by other hosts before I'm = sure that=20
> > this is the
>=20 > actual TSPEC used, and not the reduced TSPEC that can be = negotiated=20
> > following admission = failure.=20
>
> I imagined that = there would=20 be one resource counter for each
> = service=20 level
> (except b/e and lbe). The counter = would be=20 conditionally
> debited as soon as =
> a path message is seen. The debit could be reversed if = the=20
> reservation is
>=20 denied. This does result in brief underestimations of
> available resources,
> but = - this=20 situation occurs in many scenarios and doesn't
>=20 strike me as a
> problem. =
>
> > If the sender is = going to send=20 traffic in any case, without
> > = waiting for=20
> > successful Resv message, I should = update the=20 counter when the
> > Path message=20
> > arrives, as I must guard against a = situation=20 where a Resv
> > will not arrive=20
> > at all.
>=20
> If the sender is going to send without = a=20 reservation, the
> sender will not =
> consume resources at a prioritized service level. The=20
> sender's traffic will
> be in be or lbe and therefore, need not be counted.=20
>
> > See = some minor=20 remarks inline as well
> > =
> > >2. It would complicate the protocol exchange - = instead of=20
> > relying solely on
> > >a response from the network indicating that the = network=20 does
> > not want the
> > >app to send, this would require both a query = from the=20
> > application and a
> > >response from the network.
>=20 >
> > I'm not sure what you mean by = query and=20 response. We are
> > talking on the=20
> > normal RSVP messages exchange. = Path=20 downstream, Resv or
> > Path-Err=20 upstream.
> >
>=20
> As I proposed the protocol exchanges, = there would=20 be no additional
> information in the = 'query' or=20 the application's message to
> the = network=20 (the
> path message in this case). The = additional=20 information would
> be only in the =
> 'response' (the path_err message). As you propose it, = there would=20 be
> additional info in both. If you were = to for=20 example, build a protocol
> = simulator/tester, your=20 approach is more complex to model (and
> = therefore,=20 to
> implement, to test and to operate). = Unless you=20 can show a
> concrete benefit =
> of the added complexity, I oppose the added = complexity.=20
>
> > >I'm = not sure why=20 it is necessary to pigeonhole applications
> >=20 as one or the
> > >other. The same=20 application may use different strategies at
> >=20 different times.
> > >For example, = an=20 application might try lesser codecs until it
> >=20 finds that none
> > >are acceptable = by the=20 network, at which time it would just
> = > not=20 send (or
> > >alternatively, send = with=20 best-effort). Such an application
> > = is both of=20 the
> > >type that is going to send = anyhow=20 (unless prohibited) and
> > = simultaneously=20 of
> > >the type that is going to=20 renegotiate. Again - the
> > = distinction you=20 draw
> > >seems to just complicate = the set of=20 application behaviours.
> > =
> > You don't pigeonhole applications, you describe = their=20
> > behavior for each
> > flow they intend to send. In each round, the = application=20
> > sends different
>=20 > Path messages (different TSPECs according to codecs), it also=20
> > knows whether
>=20 > it is going to wait for a successful Resv message before =
> sending the
> > traffic. = It can send=20 this information in the Path message.
> = >=20
>
> As = stated in my=20 earlier comments, the application may defer
> this=20 choice to
> the user. The network should = not need=20 to behave differently
> on this basis.=20
>
> > = >It is true=20 that this alternative would give the PEP/PDP
> some=20 explicit
> > >information about the = application. However - i'm not sure
> = > what the=20 PEP/PDP
> > >would do differently = based on=20 this information. Unless the
> > = PEP/PDP=20 does
> > >something useful and = different, i'm=20 not sure that this
> justifies the =
> > >additional protocol exchange.
> >
> > There is no = additional=20 protocol exchange.
> > =
>
> Sorry - by 'protocol = exchange' I=20 meant, 'additional
> information carried = in=20
> protocol messages which require additional = parsing,=20
> additional decision
>=20 making and may alter the progression of a protocol exchange'. =
>
> Regards,
>=20 Yoram
> =

------_=_NextPart_001_01C08D7E.05CA4121-- From owner-rap@ops.ietf.org Fri Feb 2 21:10:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09758 for ; Fri, 2 Feb 2001 21:10:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Os9m-000AkH-00 for rap-data@psg.com; Fri, 02 Feb 2001 18:10:30 -0800 Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by psg.com with esmtp (Exim 3.16 #1) id 14Os9l-000AkB-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 18:10:29 -0800 Received: from zrtpd00y.us.nortel.com by ertpg14e1.nortelnetworks.com; Fri, 2 Feb 2001 21:08:55 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1C1XG5VN>; Fri, 2 Feb 2001 21:08:55 -0500 Message-ID: From: "Ralph Santitoro" To: Ramesh Pabbati , "Weiss, Walter" , Yoram Bernet , Ron Cohen , rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 2 Feb 2001 21:08:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D86.40DA0D20" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08D86.40DA0D20 Content-Type: text/plain; charset="iso-8859-1" Walter, For IP telephony (IPT) applications, this draft addresses some particular problems related to call setup time during the RSVP reservation process. During the call admission control process, the IPT device needs to know whether a sufficient QoS level is available from the network prior to establishing the call. The sending device (caller) uses RSVP to signal the desired QoS level based on an SLA or enterprise network policies. If there are insufficient network resources to achieve this QoS level, then it is desirable to immediately send a response back to the sending device via a Path-Err rather than wait for the RSVP message to make its 'round trip' from the receiver back to the sender. The approach in the draft minimizes call setup time by providing a much quicker RSVP 'response' to the IPT device so it can quickly make alternate choices. (The IPT device may provide fast busy tones to the user, an IPT gateway may have a PSTN fallback connection or the IPT device may reinitiate the reservation with a low bandwidth codec.) I agree with Ramesh's point below that the receiver doesn't provide any additional information so there is no need to add the extra round trip delay of the ResvErr message. Regards, ..... Ralph -----Original Message----- From: Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com] Sent: Friday, February 02, 2001 5:10 PM To: Weiss, Walter; Yoram Bernet; Ron Cohen; rap Cc: Santitoro, Ralph [GUAR:1482-M:EXCH] Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Walter, One of the main aims of this draft is let the a class of sender know ASAP when there are no resources available to meet this requirements of this session. One such example is IP phones which operate with a fixed flowspec and receiver just a copy of sender Tspec. The PDP will return this specific error based on the application sending (i.e., receiver is not going provide PDP any more information beyond what is in the PATH message). By sending a ResvErr back to receiver and receiver sending this ResvErr indication using another control channel will add to delay in setting up the call. Some class of applications can not tolerate this delay, for those applications PDP will return this error code in PathErr message. Ralph can provide more details on this class of applications. Ramesh -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Friday, February 02, 2001 3:36 PM To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards, -Walter > -----Original Message----- > From: Yoram Bernet [ mailto:yoramb@microsoft.com ] > Sent: Wednesday, January 17, 2001 12:23 PM > To: Ron Cohen; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for the comments. This is getting complicated enouhg > to warrant some > face to face discussion. In any case, some responses below: > > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the > sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > > The application may or may not know this. For example - an > application might > (in response to failed admission control, but not the 'do not > send' message) > defer to the user, with a UI of the form: "You will not be > granted QoS for > this session. You may: 1) try your call again later 2) > proceed with no qos > 3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > T-1 button). > > > (2) Whether it supports the new instructions. > > As i'll explain below - an application could tell you this, > but I don't > think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > > I beleive that - if you add to a protocol - you must be able > to explain > specifically how the addition will change the behaviour of > the peers that > participate in the protocol. You do take a stab at this > below, but - as I > will show, i'm not sure that the behaviours you propose > really work. If we > conclude that there are no valuable behavioural changes that > result from the > protocol addition, then I don't think it can be justified on > the abstract > basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. > Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > This approach suffers from a number of problems. > > First of all - it largely removes the incentive for an > application to be > well-behaved. If the application is not upgraded, it at least > gets to try to > get service. If it's upgraded - it gets completely denied. > Why should an > application upgrade? > > Second - if you have the means in the network to provide > traffic separation, > then you should apply this means regardless of what the app > says or does not > say it will do. In other words - the signaling provides you with the > classification information that you need to recognize the > flow of interest. > If you have the ability to use this classification info to > downgrade the > priority of the traffic in the WAN, then you should do so - > regardless. Thus > - your behaviour would not change because the app claims to > be well behaved. > > The 'do not send' policy is primarily intended for networks > that do not have > the ability to offer traffic separation between b/e and lbe. On these > networks, the choice of the netadmin is to 1) allow the app > to be deployed, > regardless of its behaviour, thereby running the risk that > the wan resources > will be trashed. 2) refuse to deploy the app on the wan. 3) > allow the app to > be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > > Indeed, the hypothetical parameter could tell the pdp that > the app would or > would not do something. but - i maintain that you still would > have to apply > the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the > Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > > I imagined that there would be one resource counter for each > service level > (except b/e and lbe). The counter would be conditionally > debited as soon as > a path message is seen. The debit could be reversed if the > reservation is > denied. This does result in brief underestimations of > available resources, > but - this situation occurs in many scenarios and doesn't > strike me as a > problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > > If the sender is going to send without a reservation, the > sender will not > consume resources at a prioritized service level. The > sender's traffic will > be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > > As I proposed the protocol exchanges, there would be no additional > information in the 'query' or the application's message to > the network (the > path message in this case). The additional information would > be only in the > 'response' (the path_err message). As you propose it, there would be > additional info in both. If you were to for example, build a protocol > simulator/tester, your approach is more complex to model (and > therefore, to > implement, to test and to operate). Unless you can show a > concrete benefit > of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before > sending the > > traffic. It can send this information in the Path message. > > > > As stated in my earlier comments, the application may defer > this choice to > the user. The network should not need to behave differently > on this basis. > > > >It is true that this alternative would give the PEP/PDP > some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this > justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > > Sorry - by 'protocol exchange' I meant, 'additional > information carried in > protocol messages which require additional parsing, > additional decision > making and may alter the progression of a protocol exchange'. > > Regards, > Yoram > ------_=_NextPart_001_01C08D86.40DA0D20 Content-Type: text/html; charset="iso-8859-1" RE: draft-santitoro-rap-policy-errorcodes-01.txt
Walter,
 
For IP telephony (IPT) applications, this draft addresses some particular problems related to call setup time during the RSVP reservation process.  During the call admission control process, the IPT device needs to know whether a sufficient QoS level is available from the network prior to establishing the call.   
 
The sending device (caller) uses RSVP to signal the desired QoS level based on an SLA or enterprise network policies.  If there are insufficient network resources to achieve this QoS level, then it is desirable to immediately send a response back to the sending device via a Path-Err rather than wait for the RSVP message to make its 'round trip' from the receiver back to the sender.
 
The approach in the draft minimizes call setup time by providing a much quicker RSVP 'response' to the IPT device so it can quickly make alternate choices.  (The IPT device may provide fast busy tones to the user, an IPT gateway may have a PSTN fallback connection or the IPT device may reinitiate the reservation with a low bandwidth codec.) 
 
I agree with Ramesh's point below that the receiver doesn't provide any additional information so there is no need to add the extra round trip delay of the ResvErr message.
 
Regards,
 
..... Ralph
 
-----Original Message-----
From: Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com]
Sent: Friday, February 02, 2001 5:10 PM
To: Weiss, Walter; Yoram Bernet; Ron Cohen; rap
Cc: Santitoro, Ralph [GUAR:1482-M:EXCH]
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Walter,
 
One of the main aims of this draft is let the a class of sender know ASAP when there are no resources available to meet this requirements of this session. One such example is IP phones which operate with a fixed flowspec and receiver just a copy of sender Tspec. The PDP will return this specific error based on the application sending (i.e., receiver is not going provide PDP any more information beyond what is in the PATH message). By sending a ResvErr back to receiver and receiver sending this ResvErr indication using another control channel will add to delay in setting up the call. Some class of applications can not tolerate this delay, for those applications PDP will return this error code in PathErr message. Ralph can provide more details on this class of applications.
 
Ramesh
-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; rap@ops.ietf.org
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Ron:
>
> Thanks for the comments. This is getting complicated enouhg
> to warrant some
> face to face discussion. In any case, some responses below:
>
> > After thinking on this subject for a while, I agree that
> > there needs to be
> > a parameter (forget formats for a minute) returned to the
> sender that
> > differs between do-not-send and no-QoS-admission failures.
> > Otherwise the
> > solution is not flexible enough.
> >
> > I (still) think that its required to let the PDP know two
> > things in the
> > Path message.
> > (1) Its behavior (the fact that its going to send traffic in
> > the specified
> > TSPEC regardless of successful QoS admission).
>
> The application may or may not know this. For example - an
> application might
> (in response to failed admission control, but not the 'do not
> send' message)
> defer to the user, with a UI of the form: "You will not be
> granted QoS for
> this session. You may: 1) try your call again later 2)
> proceed with no qos
> 3) retry with a lesser codec (e.g. press the 56 Kbps button
> instead of the
> T-1 button).
>
> > (2) Whether it supports the new instructions.
>
> As i'll explain below - an application could tell you this,
> but I don't
> think it affords you to behave any differently...
> >
> > I'll try to give examples why these are needed below, but
> > regardless of
> > providing a set of persuading examples, I believe in smart
> > networks and
> > policy makers to allow flexible policy enforcement, and
> > therefore I believe
> > in the necessity to add this information to the Path message.
>
> I beleive that - if you add to a protocol - you must be able
> to explain
> specifically how the addition will change the behaviour of
> the peers that
> participate in the protocol. You do take a stab at this
> below, but - as I
> will show, i'm not sure that the behaviours you propose
> really work. If we
> conclude that there are no valuable behavioural changes that
> result from the
> protocol addition, then I don't think it can be justified on
> the abstract
> basis of "smart networks and felxible policy enforcement".
> 
> >
> > Example 1: transition period - why (2) is needed:
> >
> > Suppose we have a network environment where on some hosts an
> > application x
> > is upgraded to support the new standard and some are not.
> Suppose the
> > application is sending traffic regardless of successful RSVP
> > setup. The
> > administrator must control the application on both upgraded
> > an not-upgraded
> > hosts and make sure that these do not harm the WAN traffic. For the
> > upgraded applications Path-Err will instruct them to shut up.
> > For the older
> > ones, the only option is to map them to LBE. Therefore the
> > policy specified
> > would be something of the form:
> >
> > If (app=x AND upgraded) deny
> > If (app=x AND not-upgraded) admit and set DSCP to LBE.
>
> This approach suffers from a number of problems.
>
> First of all - it largely removes the incentive for an
> application to be
> well-behaved. If the application is not upgraded, it at least
> gets to try to
> get service. If it's upgraded - it gets completely denied.
> Why should an
> application upgrade?
>
> Second - if you have the means in the network to provide
> traffic separation,
> then you should apply this means regardless of what the app
> says or does not
> say it will do. In other words - the signaling provides you with the
> classification information that you need to recognize the
> flow of interest.
> If you have the ability to use this classification info to
> downgrade the
> priority of the traffic in the WAN, then you should do so -
> regardless. Thus
> - your behaviour would not change because the app claims to
> be well behaved.
>
> The 'do not send' policy is primarily intended for networks
> that do not have
> the ability to offer traffic separation between b/e and lbe. On these
> networks, the choice of the netadmin is to 1) allow the app
> to be deployed,
> regardless of its behaviour, thereby running the risk that
> the wan resources
> will be trashed. 2) refuse to deploy the app on the wan. 3)
> allow the app to
> be deployed only if it is well-behaved.
>
> >
> > The PDP can know if the app is upgraded if the additional
> > object/parameter
> > appears in the path message.
> > Any alternative would force the administrator to add a list
> > of hosts where
> > the application is upgraded and where it is not. This would
> > be a nightmare.
>
> Indeed, the hypothetical parameter could tell the pdp that
> the app would or
> would not do something. but - i maintain that you still would
> have to apply
> the same behaviour, regardless.
> >
> > Example 2: why (1) is needed:
> >
> > The policy I want to enforce on a WAN interface is the following:
> >
> > Don't admit QoS request beyond X kb/s
> > Don't allow sending beyond Y kb/s
> >
> > To implement this policy I have two counters in my PDP:
> > Counter x measures the amount of admitted bandwidth for QoS.
> > It is updated
> > for each successful Resv using the RSPEC carried in the
> Resv message.
> > Counter y measures the amount of traffic sent by the sender
> > as declared in
> > the Path TSPEC. When should I update this counter? If traffic
> > is sent only
> > after successful admission, I should update the counter with
> > the Path TSPEC
> > only after successful admission of the Resv message.
> > Otherwise, I will
> > reject Path messages sent by other hosts before I'm sure that
> > this is the
> > actual TSPEC used, and not the reduced TSPEC that can be negotiated
> > following admission failure.
>
> I imagined that there would be one resource counter for each
> service level
> (except b/e and lbe). The counter would be conditionally
> debited as soon as
> a path message is seen. The debit could be reversed if the
> reservation is
> denied. This does result in brief underestimations of
> available resources,
> but - this situation occurs in many scenarios and doesn't
> strike me as a
> problem.
>
> > If the sender is going to send traffic in any case, without
> > waiting for
> > successful Resv message, I should update the counter when the
> > Path message
> > arrives, as I must guard against a situation where a Resv
> > will not arrive
> > at all.
>
> If the sender is going to send without a reservation, the
> sender will not
> consume resources at a prioritized service level. The
> sender's traffic will
> be in be or lbe and therefore, need not be counted.
>
> > See some minor remarks inline as well
> >
> > >2. It would complicate the protocol exchange - instead of
> > relying solely on
> > >a response from the network indicating that the network does
> > not want the
> > >app to send, this would require both a query from the
> > application and a
> > >response from the network.
> >
> > I'm not sure what you mean by query and response. We are
> > talking on the
> > normal RSVP messages exchange. Path downstream, Resv or
> > Path-Err upstream.
> >
>
> As I proposed the protocol exchanges, there would be no additional
> information in the 'query' or the application's message to
> the network (the
> path message in this case). The additional information would
> be only in the
> 'response' (the path_err message). As you propose it, there would be
> additional info in both. If you were to for example, build a protocol
> simulator/tester, your approach is more complex to model (and
> therefore, to
> implement, to test and to operate). Unless you can show a
> concrete benefit
> of the added complexity, I oppose the added complexity.
>
> > >I'm not sure why it is necessary to pigeonhole applications
> > as one or the
> > >other. The same application may use different strategies at
> > different times.
> > >For example, an application might try lesser codecs until it
> > finds that none
> > >are acceptable by the network, at which time it would just
> > not send (or
> > >alternatively, send with best-effort). Such an application
> > is both of the
> > >type that is going to send anyhow (unless prohibited) and
> > simultaneously of
> > >the type that is going to renegotiate. Again - the
> > distinction you draw
> > >seems to just complicate the set of application behaviours.
> >
> > You don't pigeonhole applications, you describe their
> > behavior for each
> > flow they intend to send. In each round, the application
> > sends different
> > Path messages (different TSPECs according to codecs), it also
> > knows whether
> > it is going to wait for a successful Resv message before
> sending the
> > traffic. It can send this information in the Path message.
> >
>
> As stated in my earlier comments, the application may defer
> this choice to
> the user. The network should not need to behave differently
> on this basis.
>
> > >It is true that this alternative would give the PEP/PDP
> some explicit
> > >information about the application. However - i'm not sure
> > what the PEP/PDP
> > >would do differently based on this information. Unless the
> > PEP/PDP does
> > >something useful and different, i'm not sure that this
> justifies the
> > >additional protocol exchange.
> >
> > There is no additional protocol exchange.
> >
>
> Sorry - by 'protocol exchange' I meant, 'additional
> information carried in
> protocol messages which require additional parsing,
> additional decision
> making and may alter the progression of a protocol exchange'.
>
> Regards,
> Yoram
>

------_=_NextPart_001_01C08D86.40DA0D20-- From owner-rap@ops.ietf.org Sat Feb 3 02:25:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25559 for ; Sat, 3 Feb 2001 02:25:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ox3v-000Fz0-00 for rap-data@psg.com; Fri, 02 Feb 2001 23:24:47 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14Ox3u-000Fyi-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 23:24:46 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Feb 2001 15:52:31 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111DD5J5>; Fri, 2 Feb 2001 15:52:22 -0800 Message-ID: From: Yoram Bernet To: "Weiss, Walter" , Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 2 Feb 2001 15:51:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D73.1FF901C9" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08D73.1FF901C9 Content-Type: text/plain; charset="iso-8859-1" walter: expectations regarding rsvp have changed significantly. rsvp, as it was intially imagined to be deployed, with per-flow reservations at each hop and pure intserv services, was not well received. we've worked on adapting it (rfcs 2996. 2997, 2998). part of this adaptation is a change in the end-to-end semantics and a broadening beyond pure intserv. the draft should be considered in this context. yoram -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Friday, February 02, 2001 3:36 PM To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards, -Walter > -----Original Message----- > From: Yoram Bernet [ mailto:yoramb@microsoft.com ] > Sent: Wednesday, January 17, 2001 12:23 PM > To: Ron Cohen; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for the comments. This is getting complicated enouhg > to warrant some > face to face discussion. In any case, some responses below: > > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the > sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > > The application may or may not know this. For example - an > application might > (in response to failed admission control, but not the 'do not > send' message) > defer to the user, with a UI of the form: "You will not be > granted QoS for > this session. You may: 1) try your call again later 2) > proceed with no qos > 3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > T-1 button). > > > (2) Whether it supports the new instructions. > > As i'll explain below - an application could tell you this, > but I don't > think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > > I beleive that - if you add to a protocol - you must be able > to explain > specifically how the addition will change the behaviour of > the peers that > participate in the protocol. You do take a stab at this > below, but - as I > will show, i'm not sure that the behaviours you propose > really work. If we > conclude that there are no valuable behavioural changes that > result from the > protocol addition, then I don't think it can be justified on > the abstract > basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. > Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > This approach suffers from a number of problems. > > First of all - it largely removes the incentive for an > application to be > well-behaved. If the application is not upgraded, it at least > gets to try to > get service. If it's upgraded - it gets completely denied. > Why should an > application upgrade? > > Second - if you have the means in the network to provide > traffic separation, > then you should apply this means regardless of what the app > says or does not > say it will do. In other words - the signaling provides you with the > classification information that you need to recognize the > flow of interest. > If you have the ability to use this classification info to > downgrade the > priority of the traffic in the WAN, then you should do so - > regardless. Thus > - your behaviour would not change because the app claims to > be well behaved. > > The 'do not send' policy is primarily intended for networks > that do not have > the ability to offer traffic separation between b/e and lbe. On these > networks, the choice of the netadmin is to 1) allow the app > to be deployed, > regardless of its behaviour, thereby running the risk that > the wan resources > will be trashed. 2) refuse to deploy the app on the wan. 3) > allow the app to > be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > > Indeed, the hypothetical parameter could tell the pdp that > the app would or > would not do something. but - i maintain that you still would > have to apply > the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the > Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > > I imagined that there would be one resource counter for each > service level > (except b/e and lbe). The counter would be conditionally > debited as soon as > a path message is seen. The debit could be reversed if the > reservation is > denied. This does result in brief underestimations of > available resources, > but - this situation occurs in many scenarios and doesn't > strike me as a > problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > > If the sender is going to send without a reservation, the > sender will not > consume resources at a prioritized service level. The > sender's traffic will > be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > > As I proposed the protocol exchanges, there would be no additional > information in the 'query' or the application's message to > the network (the > path message in this case). The additional information would > be only in the > 'response' (the path_err message). As you propose it, there would be > additional info in both. If you were to for example, build a protocol > simulator/tester, your approach is more complex to model (and > therefore, to > implement, to test and to operate). Unless you can show a > concrete benefit > of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before > sending the > > traffic. It can send this information in the Path message. > > > > As stated in my earlier comments, the application may defer > this choice to > the user. The network should not need to behave differently > on this basis. > > > >It is true that this alternative would give the PEP/PDP > some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this > justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > > Sorry - by 'protocol exchange' I meant, 'additional > information carried in > protocol messages which require additional parsing, > additional decision > making and may alter the progression of a protocol exchange'. > > Regards, > Yoram > ------_=_NextPart_001_01C08D73.1FF901C9 Content-Type: text/html; charset="iso-8859-1" RE: draft-santitoro-rap-policy-errorcodes-01.txt
walter:
 
expectations regarding rsvp have changed significantly. rsvp, as it was intially imagined to be deployed, with per-flow reservations at each hop and pure intserv services, was not well received. we've worked on adapting it (rfcs 2996. 2997, 2998). part of this adaptation is a change in the end-to-end semantics and a broadening beyond pure intserv. the draft should be considered in this context. 
 
yoram
 -----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; rap@ops.ietf.org
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Ron:
>
> Thanks for the comments. This is getting complicated enouhg
> to warrant some
> face to face discussion. In any case, some responses below:
>
> > After thinking on this subject for a while, I agree that
> > there needs to be
> > a parameter (forget formats for a minute) returned to the
> sender that
> > differs between do-not-send and no-QoS-admission failures.
> > Otherwise the
> > solution is not flexible enough.
> >
> > I (still) think that its required to let the PDP know two
> > things in the
> > Path message.
> > (1) Its behavior (the fact that its going to send traffic in
> > the specified
> > TSPEC regardless of successful QoS admission).
>
> The application may or may not know this. For example - an
> application might
> (in response to failed admission control, but not the 'do not
> send' message)
> defer to the user, with a UI of the form: "You will not be
> granted QoS for
> this session. You may: 1) try your call again later 2)
> proceed with no qos
> 3) retry with a lesser codec (e.g. press the 56 Kbps button
> instead of the
> T-1 button).
>
> > (2) Whether it supports the new instructions.
>
> As i'll explain below - an application could tell you this,
> but I don't
> think it affords you to behave any differently...
> >
> > I'll try to give examples why these are needed below, but
> > regardless of
> > providing a set of persuading examples, I believe in smart
> > networks and
> > policy makers to allow flexible policy enforcement, and
> > therefore I believe
> > in the necessity to add this information to the Path message.
>
> I beleive that - if you add to a protocol - you must be able
> to explain
> specifically how the addition will change the behaviour of
> the peers that
> participate in the protocol. You do take a stab at this
> below, but - as I
> will show, i'm not sure that the behaviours you propose
> really work. If we
> conclude that there are no valuable behavioural changes that
> result from the
> protocol addition, then I don't think it can be justified on
> the abstract
> basis of "smart networks and felxible policy enforcement".
> 
> >
> > Example 1: transition period - why (2) is needed:
> >
> > Suppose we have a network environment where on some hosts an
> > application x
> > is upgraded to support the new standard and some are not.
> Suppose the
> > application is sending traffic regardless of successful RSVP
> > setup. The
> > administrator must control the application on both upgraded
> > an not-upgraded
> > hosts and make sure that these do not harm the WAN traffic. For the
> > upgraded applications Path-Err will instruct them to shut up.
> > For the older
> > ones, the only option is to map them to LBE. Therefore the
> > policy specified
> > would be something of the form:
> >
> > If (app=x AND upgraded) deny
> > If (app=x AND not-upgraded) admit and set DSCP to LBE.
>
> This approach suffers from a number of problems.
>
> First of all - it largely removes the incentive for an
> application to be
> well-behaved. If the application is not upgraded, it at least
> gets to try to
> get service. If it's upgraded - it gets completely denied.
> Why should an
> application upgrade?
>
> Second - if you have the means in the network to provide
> traffic separation,
> then you should apply this means regardless of what the app
> says or does not
> say it will do. In other words - the signaling provides you with the
> classification information that you need to recognize the
> flow of interest.
> If you have the ability to use this classification info to
> downgrade the
> priority of the traffic in the WAN, then you should do so -
> regardless. Thus
> - your behaviour would not change because the app claims to
> be well behaved.
>
> The 'do not send' policy is primarily intended for networks
> that do not have
> the ability to offer traffic separation between b/e and lbe. On these
> networks, the choice of the netadmin is to 1) allow the app
> to be deployed,
> regardless of its behaviour, thereby running the risk that
> the wan resources
> will be trashed. 2) refuse to deploy the app on the wan. 3)
> allow the app to
> be deployed only if it is well-behaved.
>
> >
> > The PDP can know if the app is upgraded if the additional
> > object/parameter
> > appears in the path message.
> > Any alternative would force the administrator to add a list
> > of hosts where
> > the application is upgraded and where it is not. This would
> > be a nightmare.
>
> Indeed, the hypothetical parameter could tell the pdp that
> the app would or
> would not do something. but - i maintain that you still would
> have to apply
> the same behaviour, regardless.
> >
> > Example 2: why (1) is needed:
> >
> > The policy I want to enforce on a WAN interface is the following:
> >
> > Don't admit QoS request beyond X kb/s
> > Don't allow sending beyond Y kb/s
> >
> > To implement this policy I have two counters in my PDP:
> > Counter x measures the amount of admitted bandwidth for QoS.
> > It is updated
> > for each successful Resv using the RSPEC carried in the
> Resv message.
> > Counter y measures the amount of traffic sent by the sender
> > as declared in
> > the Path TSPEC. When should I update this counter? If traffic
> > is sent only
> > after successful admission, I should update the counter with
> > the Path TSPEC
> > only after successful admission of the Resv message.
> > Otherwise, I will
> > reject Path messages sent by other hosts before I'm sure that
> > this is the
> > actual TSPEC used, and not the reduced TSPEC that can be negotiated
> > following admission failure.
>
> I imagined that there would be one resource counter for each
> service level
> (except b/e and lbe). The counter would be conditionally
> debited as soon as
> a path message is seen. The debit could be reversed if the
> reservation is
> denied. This does result in brief underestimations of
> available resources,
> but - this situation occurs in many scenarios and doesn't
> strike me as a
> problem.
>
> > If the sender is going to send traffic in any case, without
> > waiting for
> > successful Resv message, I should update the counter when the
> > Path message
> > arrives, as I must guard against a situation where a Resv
> > will not arrive
> > at all.
>
> If the sender is going to send without a reservation, the
> sender will not
> consume resources at a prioritized service level. The
> sender's traffic will
> be in be or lbe and therefore, need not be counted.
>
> > See some minor remarks inline as well
> >
> > >2. It would complicate the protocol exchange - instead of
> > relying solely on
> > >a response from the network indicating that the network does
> > not want the
> > >app to send, this would require both a query from the
> > application and a
> > >response from the network.
> >
> > I'm not sure what you mean by query and response. We are
> > talking on the
> > normal RSVP messages exchange. Path downstream, Resv or
> > Path-Err upstream.
> >
>
> As I proposed the protocol exchanges, there would be no additional
> information in the 'query' or the application's message to
> the network (the
> path message in this case). The additional information would
> be only in the
> 'response' (the path_err message). As you propose it, there would be
> additional info in both. If you were to for example, build a protocol
> simulator/tester, your approach is more complex to model (and
> therefore, to
> implement, to test and to operate). Unless you can show a
> concrete benefit
> of the added complexity, I oppose the added complexity.
>
> > >I'm not sure why it is necessary to pigeonhole applications
> > as one or the
> > >other. The same application may use different strategies at
> > different times.
> > >For example, an application might try lesser codecs until it
> > finds that none
> > >are acceptable by the network, at which time it would just
> > not send (or
> > >alternatively, send with best-effort). Such an application
> > is both of the
> > >type that is going to send anyhow (unless prohibited) and
> > simultaneously of
> > >the type that is going to renegotiate. Again - the
> > distinction you draw
> > >seems to just complicate the set of application behaviours.
> >
> > You don't pigeonhole applications, you describe their
> > behavior for each
> > flow they intend to send. In each round, the application
> > sends different
> > Path messages (different TSPECs according to codecs), it also
> > knows whether
> > it is going to wait for a successful Resv message before
> sending the
> > traffic. It can send this information in the Path message.
> >
>
> As stated in my earlier comments, the application may defer
> this choice to
> the user. The network should not need to behave differently
> on this basis.
>
> > >It is true that this alternative would give the PEP/PDP
> some explicit
> > >information about the application. However - i'm not sure
> > what the PEP/PDP
> > >would do differently based on this information. Unless the
> > PEP/PDP does
> > >something useful and different, i'm not sure that this
> justifies the
> > >additional protocol exchange.
> >
> > There is no additional protocol exchange.
> >
>
> Sorry - by 'protocol exchange' I meant, 'additional
> information carried in
> protocol messages which require additional parsing,
> additional decision
> making and may alter the progression of a protocol exchange'.
>
> Regards,
> Yoram
>

------_=_NextPart_001_01C08D73.1FF901C9-- From owner-rap@ops.ietf.org Sat Feb 3 02:49:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25931 for ; Sat, 3 Feb 2001 02:49:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OxRs-000GMU-00 for rap-data@psg.com; Fri, 02 Feb 2001 23:49:32 -0800 Received: from snipe.prod.itd.earthlink.net ([207.217.120.62]) by psg.com with esmtp (Exim 3.16 #1) id 14OxRs-000GMO-00 for rap@ops.ietf.org; Fri, 02 Feb 2001 23:49:32 -0800 Received: from pacbell.net (user-vcauror.dsl.mindspring.com [216.175.111.27]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA20470; Fri, 2 Feb 2001 23:49:20 -0800 (PST) Message-ID: <3A7BBA3D.9040907@pacbell.net> Date: Fri, 02 Feb 2001 23:58:53 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Ralph Santitoro CC: rap Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Can you provide some quantitative data here e.g. some units and values to go with "immediately", "quickly", "fast" etc. It's hard to make the right protocol design tradeoffs with people using such qualitative terminology. Thanks, Andrew Ralph Santitoro wrote: > Walter, > > > > For IP telephony (IPT) applications, this draft addresses some > particular problems related to call setup time during the RSVP > reservation process. During the call admission control process, the IPT > device needs to know whether a sufficient QoS level is available from > the network prior to establishing the call. > > > > The sending device (caller) uses RSVP to signal the desired QoS level > based on an SLA or enterprise network policies. If there are > insufficient network resources to achieve this QoS level, then it is > desirable to immediately send a response back to the sending device via > a Path-Err rather than wait for the RSVP message to make its 'round > trip' from the receiver back to the sender. > > > > The approach in the draft minimizes call setup time by providing a much > quicker RSVP 'response' to the IPT device so it can quickly make > alternate choices. (The IPT device may provide fast busy tones to the > user, an IPT gateway may have a PSTN fallback connection or the IPT > device may reinitiate the reservation with a low bandwidth codec.) > > > > I agree with Ramesh's point below that the receiver doesn't provide any > additional information so there is no need to add the extra round trip > delay of the ResvErr message. > > > > Regards, > > > > ..... Ralph > > > > -----Original Message----- > *From:* Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com] > *Sent:* Friday, February 02, 2001 5:10 PM > *To:* Weiss, Walter; Yoram Bernet; Ron Cohen; rap > *Cc:* Santitoro, Ralph [GUAR:1482-M:EXCH] > *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt > > Walter, > > > > One of the main aims of this draft is let the a class of sender know > ASAP when there are no resources available to meet this requirements > of this session. One such example is IP phones which operate with a > fixed flowspec and receiver just a copy of sender Tspec. The PDP > will return this specific error based on the application sending > (i.e., receiver is not going provide PDP any more information beyond > what is in the PATH message). By sending a ResvErr back to receiver > and receiver sending this ResvErr indication using another control > channel will add to delay in setting up the call. Some class of > applications can not tolerate this delay, for those applications PDP > will return this error code in PathErr message. Ralph can provide > more details on this class of applications. > > > > Ramesh > > -----Original Message----- > *From:* Weiss, Walter [mailto:wweiss@ellacoya.com] > *Sent:* Friday, February 02, 2001 3:36 PM > *To:* Yoram Bernet; Ron Cohen; rap@ops.ietf.org > *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt > > Yoram, > > The premise of IntServ is that both ends agree to a service > level. One of the main concerns I have with this proposal is > that only one side is being told of a specific (less > optimal)service alternative. In order to preserve the end-to-end > nature of RSVP, one alternative possiblity (suggested by Bob > B.), might be to send a ResvErr back to the receiver with a > flowspec that has a higher probability of success. This would > allow the receiver to send a revised Resv back to the sender > allowing for both a viable reservation (with all it's > properties), as well as the most ideal DSCP mapping. > > regards, > > -Walter > > > -----Original Message----- > > From: Yoram Bernet [mailto:yoramb@microsoft.com] > > Sent: Wednesday, January 17, 2001 12:23 PM > > To: Ron Cohen; rap@ops.ietf.org > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > Ron: > > > > Thanks for the comments. This is getting complicated enouhg > > to warrant some > > face to face discussion. In any case, some responses below: > > > > > After thinking on this subject for a while, I agree that > > > there needs to be > > > a parameter (forget formats for a minute) returned to the > > sender that > > > differs between do-not-send and no-QoS-admission failures. > > > Otherwise the > > > solution is not flexible enough. > > > > > > I (still) think that its required to let the PDP know two > > > things in the > > > Path message. > > > (1) Its behavior (the fact that its going to send traffic in > > > the specified > > > TSPEC regardless of successful QoS admission). > > > > The application may or may not know this. For example - an > > application might > > (in response to failed admission control, but not the 'do not > > send' message) > > defer to the user, with a UI of the form: "You will not be > > granted QoS for > > this session. You may: 1) try your call again later 2) > > proceed with no qos > > 3) retry with a lesser codec (e.g. press the 56 Kbps button > > instead of the > > T-1 button). > > > > > (2) Whether it supports the new instructions. > > > > As i'll explain below - an application could tell you this, > > but I don't > > think it affords you to behave any differently... > > > > > > I'll try to give examples why these are needed below, but > > > regardless of > > > providing a set of persuading examples, I believe in smart > > > networks and > > > policy makers to allow flexible policy enforcement, and > > > therefore I believe > > > in the necessity to add this information to the Path message. > > > > I beleive that - if you add to a protocol - you must be able > > to explain > > specifically how the addition will change the behaviour of > > the peers that > > participate in the protocol. You do take a stab at this > > below, but - as I > > will show, i'm not sure that the behaviours you propose > > really work. If we > > conclude that there are no valuable behavioural changes that > > result from the > > protocol addition, then I don't think it can be justified on > > the abstract > > basis of "smart networks and felxible policy enforcement". > > > > > > > > Example 1: transition period - why (2) is needed: > > > > > > Suppose we have a network environment where on some hosts an > > > application x > > > is upgraded to support the new standard and some are not. > > Suppose the > > > application is sending traffic regardless of successful RSVP > > > setup. The > > > administrator must control the application on both upgraded > > > an not-upgraded > > > hosts and make sure that these do not harm the WAN traffic. > For the > > > upgraded applications Path-Err will instruct them to shut up. > > > For the older > > > ones, the only option is to map them to LBE. Therefore the > > > policy specified > > > would be something of the form: > > > > > > If (app=x AND upgraded) deny > > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > > > This approach suffers from a number of problems. > > > > First of all - it largely removes the incentive for an > > application to be > > well-behaved. If the application is not upgraded, it at least > > gets to try to > > get service. If it's upgraded - it gets completely denied. > > Why should an > > application upgrade? > > > > Second - if you have the means in the network to provide > > traffic separation, > > then you should apply this means regardless of what the app > > says or does not > > say it will do. In other words - the signaling provides you > with the > > classification information that you need to recognize the > > flow of interest. > > If you have the ability to use this classification info to > > downgrade the > > priority of the traffic in the WAN, then you should do so - > > regardless. Thus > > - your behaviour would not change because the app claims to > > be well behaved. > > > > The 'do not send' policy is primarily intended for networks > > that do not have > > the ability to offer traffic separation between b/e and lbe. > On these > > networks, the choice of the netadmin is to 1) allow the app > > to be deployed, > > regardless of its behaviour, thereby running the risk that > > the wan resources > > will be trashed. 2) refuse to deploy the app on the wan. 3) > > allow the app to > > be deployed only if it is well-behaved. > > > > > > > > The PDP can know if the app is upgraded if the additional > > > object/parameter > > > appears in the path message. > > > Any alternative would force the administrator to add a list > > > of hosts where > > > the application is upgraded and where it is not. This would > > > be a nightmare. > > > > Indeed, the hypothetical parameter could tell the pdp that > > the app would or > > would not do something. but - i maintain that you still would > > have to apply > > the same behaviour, regardless. > > > > > > Example 2: why (1) is needed: > > > > > > The policy I want to enforce on a WAN interface is the > following: > > > > > > Don't admit QoS request beyond X kb/s > > > Don't allow sending beyond Y kb/s > > > > > > To implement this policy I have two counters in my PDP: > > > Counter x measures the amount of admitted bandwidth for QoS. > > > It is updated > > > for each successful Resv using the RSPEC carried in the > > Resv message. > > > Counter y measures the amount of traffic sent by the sender > > > as declared in > > > the Path TSPEC. When should I update this counter? If traffic > > > is sent only > > > after successful admission, I should update the counter with > > > the Path TSPEC > > > only after successful admission of the Resv message. > > > Otherwise, I will > > > reject Path messages sent by other hosts before I'm sure that > > > this is the > > > actual TSPEC used, and not the reduced TSPEC that can be > negotiated > > > following admission failure. > > > > I imagined that there would be one resource counter for each > > service level > > (except b/e and lbe). The counter would be conditionally > > debited as soon as > > a path message is seen. The debit could be reversed if the > > reservation is > > denied. This does result in brief underestimations of > > available resources, > > but - this situation occurs in many scenarios and doesn't > > strike me as a > > problem. > > > > > If the sender is going to send traffic in any case, without > > > waiting for > > > successful Resv message, I should update the counter when the > > > Path message > > > arrives, as I must guard against a situation where a Resv > > > will not arrive > > > at all. > > > > If the sender is going to send without a reservation, the > > sender will not > > consume resources at a prioritized service level. The > > sender's traffic will > > be in be or lbe and therefore, need not be counted. > > > > > See some minor remarks inline as well > > > > > > >2. It would complicate the protocol exchange - instead of > > > relying solely on > > > >a response from the network indicating that the network does > > > not want the > > > >app to send, this would require both a query from the > > > application and a > > > >response from the network. > > > > > > I'm not sure what you mean by query and response. We are > > > talking on the > > > normal RSVP messages exchange. Path downstream, Resv or > > > Path-Err upstream. > > > > > > > As I proposed the protocol exchanges, there would be no > additional > > information in the 'query' or the application's message to > > the network (the > > path message in this case). The additional information would > > be only in the > > 'response' (the path_err message). As you propose it, there > would be > > additional info in both. If you were to for example, build a > protocol > > simulator/tester, your approach is more complex to model (and > > therefore, to > > implement, to test and to operate). Unless you can show a > > concrete benefit > > of the added complexity, I oppose the added complexity. > > > > > >I'm not sure why it is necessary to pigeonhole applications > > > as one or the > > > >other. The same application may use different strategies at > > > different times. > > > >For example, an application might try lesser codecs until it > > > finds that none > > > >are acceptable by the network, at which time it would just > > > not send (or > > > >alternatively, send with best-effort). Such an application > > > is both of the > > > >type that is going to send anyhow (unless prohibited) and > > > simultaneously of > > > >the type that is going to renegotiate. Again - the > > > distinction you draw > > > >seems to just complicate the set of application behaviours. > > > > > > You don't pigeonhole applications, you describe their > > > behavior for each > > > flow they intend to send. In each round, the application > > > sends different > > > Path messages (different TSPECs according to codecs), it also > > > knows whether > > > it is going to wait for a successful Resv message before > > sending the > > > traffic. It can send this information in the Path message. > > > > > > > As stated in my earlier comments, the application may defer > > this choice to > > the user. The network should not need to behave differently > > on this basis. > > > > > >It is true that this alternative would give the PEP/PDP > > some explicit > > > >information about the application. However - i'm not sure > > > what the PEP/PDP > > > >would do differently based on this information. Unless the > > > PEP/PDP does > > > >something useful and different, i'm not sure that this > > justifies the > > > >additional protocol exchange. > > > > > > There is no additional protocol exchange. > > > > > > > Sorry - by 'protocol exchange' I meant, 'additional > > information carried in > > protocol messages which require additional parsing, > > additional decision > > making and may alter the progression of a protocol exchange'. > > > > Regards, > > Yoram > > > From owner-rap@ops.ietf.org Mon Feb 5 00:59:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18027 for ; Mon, 5 Feb 2001 00:59:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Peez-000C5j-00 for rap-data@psg.com; Sun, 04 Feb 2001 21:57:57 -0800 Received: from at.lannet.com ([194.90.94.231] helo=warp.lannet.com) by psg.com with esmtp (Exim 3.16 #1) id 14Peex-000C5M-00 for rap@ops.ietf.org; Sun, 04 Feb 2001 21:57:56 -0800 Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id IAA22514; Mon, 5 Feb 2001 08:06:27 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 07:57:09 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6141D72FB@itc-eml2.lannet.com> From: Dan Romascanu To: Andrew Smith , Ralph Santitoro Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 07:57:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Andy, If IP Telephony is the application, one measure of "quickly", "fast", etc. would be how much you would allow from a phone user perspective between the moment dialing ended until you hear the phone ringing ("call accepted'') or the network returning you a "busy" signal ("call rejected"). Regards, Dan > -----Original Message----- > From: Andrew Smith [SMTP:ah_smith@pacbell.net] > Sent: Sat February 03 2001 9:59 > To: Ralph Santitoro > Cc: rap > Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt > > Ralph, > > Can you provide some quantitative data here e.g. some units and values to > go > with "immediately", "quickly", "fast" etc. It's hard to make the right > protocol > design tradeoffs with people using such qualitative terminology. > > Thanks, > > Andrew > From owner-rap@ops.ietf.org Mon Feb 5 09:24:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06455 for ; Mon, 5 Feb 2001 09:24:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PmXq-000L7M-00 for rap-data@psg.com; Mon, 05 Feb 2001 06:23:06 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14PmXo-000L77-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 06:23:04 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 09:13:37 -0500 Message-ID: From: "Weiss, Walter" To: "'Ralph Santitoro'" , Ramesh Pabbati , Yoram Bernet , rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 09:13:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F7D.D4DE73AA" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F7D.D4DE73AA Content-Type: text/plain; charset="iso-8859-1" Having spent a few years at Lucent that included some work around IPT deployment solutions, I know all about Call Setup delay goals (there are no specific standards for this that I am aware of beyond some studies of use expectations). The truth is that I was always skeptical of using RSVP in conjunction with IPT because it required two sequenced round-trip negotiations (H.323/SIP + RSVP). However, that is not really the point. The main point is that IntServ and RSVP specifically imply a contract between sender and receiver. It makes no sense to me whatsoever to standardize a successful end2end reservation with the appropriate DSCP if the Tspec can be met and to convey a less optimal DSCP without a reservation when the Tspec can not be met. It would seem more reasonable to at least ensure that the receiver is aware that a less optimal service being delivered (say by sending a sub optimal Tspec). If you want to reduce setup delay, send a PathErr back with the less optimal Tspec that is more likely to result in a successful reservation. At least then you are getting consistent IntServ semantics and you are only adding incremental call setup delay. regards, -Walter -----Original Message----- From: Ralph Santitoro [mailto:rsantito@nortelnetworks.com] Sent: Friday, February 02, 2001 9:09 PM To: Ramesh Pabbati; Weiss, Walter; Yoram Bernet; Ron Cohen; rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Walter, For IP telephony (IPT) applications, this draft addresses some particular problems related to call setup time during the RSVP reservation process. During the call admission control process, the IPT device needs to know whether a sufficient QoS level is available from the network prior to establishing the call. The sending device (caller) uses RSVP to signal the desired QoS level based on an SLA or enterprise network policies. If there are insufficient network resources to achieve this QoS level, then it is desirable to immediately send a response back to the sending device via a Path-Err rather than wait for the RSVP message to make its 'round trip' from the receiver back to the sender. The approach in the draft minimizes call setup time by providing a much quicker RSVP 'response' to the IPT device so it can quickly make alternate choices. (The IPT device may provide fast busy tones to the user, an IPT gateway may have a PSTN fallback connection or the IPT device may reinitiate the reservation with a low bandwidth codec.) I agree with Ramesh's point below that the receiver doesn't provide any additional information so there is no need to add the extra round trip delay of the ResvErr message. Regards, ..... Ralph -----Original Message----- From: Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com] Sent: Friday, February 02, 2001 5:10 PM To: Weiss, Walter; Yoram Bernet; Ron Cohen; rap Cc: Santitoro, Ralph [GUAR:1482-M:EXCH] Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Walter, One of the main aims of this draft is let the a class of sender know ASAP when there are no resources available to meet this requirements of this session. One such example is IP phones which operate with a fixed flowspec and receiver just a copy of sender Tspec. The PDP will return this specific error based on the application sending (i.e., receiver is not going provide PDP any more information beyond what is in the PATH message). By sending a ResvErr back to receiver and receiver sending this ResvErr indication using another control channel will add to delay in setting up the call. Some class of applications can not tolerate this delay, for those applications PDP will return this error code in PathErr message. Ralph can provide more details on this class of applications. Ramesh -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Friday, February 02, 2001 3:36 PM To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping. regards, -Walter > -----Original Message----- > From: Yoram Bernet [ mailto:yoramb@microsoft.com ] > Sent: Wednesday, January 17, 2001 12:23 PM > To: Ron Cohen; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for the comments. This is getting complicated enouhg > to warrant some > face to face discussion. In any case, some responses below: > > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the > sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > > The application may or may not know this. For example - an > application might > (in response to failed admission control, but not the 'do not > send' message) > defer to the user, with a UI of the form: "You will not be > granted QoS for > this session. You may: 1) try your call again later 2) > proceed with no qos > 3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > T-1 button). > > > (2) Whether it supports the new instructions. > > As i'll explain below - an application could tell you this, > but I don't > think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > > I beleive that - if you add to a protocol - you must be able > to explain > specifically how the addition will change the behaviour of > the peers that > participate in the protocol. You do take a stab at this > below, but - as I > will show, i'm not sure that the behaviours you propose > really work. If we > conclude that there are no valuable behavioural changes that > result from the > protocol addition, then I don't think it can be justified on > the abstract > basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. > Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > > This approach suffers from a number of problems. > > First of all - it largely removes the incentive for an > application to be > well-behaved. If the application is not upgraded, it at least > gets to try to > get service. If it's upgraded - it gets completely denied. > Why should an > application upgrade? > > Second - if you have the means in the network to provide > traffic separation, > then you should apply this means regardless of what the app > says or does not > say it will do. In other words - the signaling provides you with the > classification information that you need to recognize the > flow of interest. > If you have the ability to use this classification info to > downgrade the > priority of the traffic in the WAN, then you should do so - > regardless. Thus > - your behaviour would not change because the app claims to > be well behaved. > > The 'do not send' policy is primarily intended for networks > that do not have > the ability to offer traffic separation between b/e and lbe. On these > networks, the choice of the netadmin is to 1) allow the app > to be deployed, > regardless of its behaviour, thereby running the risk that > the wan resources > will be trashed. 2) refuse to deploy the app on the wan. 3) > allow the app to > be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > > Indeed, the hypothetical parameter could tell the pdp that > the app would or > would not do something. but - i maintain that you still would > have to apply > the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the > Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > > I imagined that there would be one resource counter for each > service level > (except b/e and lbe). The counter would be conditionally > debited as soon as > a path message is seen. The debit could be reversed if the > reservation is > denied. This does result in brief underestimations of > available resources, > but - this situation occurs in many scenarios and doesn't > strike me as a > problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > > If the sender is going to send without a reservation, the > sender will not > consume resources at a prioritized service level. The > sender's traffic will > be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > > As I proposed the protocol exchanges, there would be no additional > information in the 'query' or the application's message to > the network (the > path message in this case). The additional information would > be only in the > 'response' (the path_err message). As you propose it, there would be > additional info in both. If you were to for example, build a protocol > simulator/tester, your approach is more complex to model (and > therefore, to > implement, to test and to operate). Unless you can show a > concrete benefit > of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before > sending the > > traffic. It can send this information in the Path message. > > > > As stated in my earlier comments, the application may defer > this choice to > the user. The network should not need to behave differently > on this basis. > > > >It is true that this alternative would give the PEP/PDP > some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this > justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > > Sorry - by 'protocol exchange' I meant, 'additional > information carried in > protocol messages which require additional parsing, > additional decision > making and may alter the progression of a protocol exchange'. > > Regards, > Yoram > ------_=_NextPart_001_01C08F7D.D4DE73AA Content-Type: text/html; charset="iso-8859-1" RE: draft-santitoro-rap-policy-errorcodes-01.txt
Having spent a few years at Lucent that included some work around IPT deployment solutions, I know all about Call Setup delay goals (there are no specific standards for this that I am aware of beyond some studies of use expectations). The truth is that I was always skeptical of using RSVP in conjunction with IPT because it required two sequenced round-trip negotiations (H.323/SIP + RSVP). However, that is not really the point. The main point is that IntServ and RSVP specifically imply a contract between sender and receiver. It makes no sense to me whatsoever to standardize a successful end2end reservation with the appropriate DSCP if the Tspec can be met and to convey a less optimal DSCP without a reservation when the Tspec can not be met. It would seem more reasonable to at least ensure that the receiver is aware that a less optimal service being delivered (say by sending a sub optimal Tspec).
 
If you want to reduce setup delay, send a PathErr back with the less optimal Tspec that is more likely to result in a successful reservation. At least then you are getting consistent IntServ semantics and you are only adding incremental call setup delay.
 
regards,
 
-Walter
-----Original Message-----
From: Ralph Santitoro [mailto:rsantito@nortelnetworks.com]
Sent: Friday, February 02, 2001 9:09 PM
To: Ramesh Pabbati; Weiss, Walter; Yoram Bernet; Ron Cohen; rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Walter,
 
For IP telephony (IPT) applications, this draft addresses some particular problems related to call setup time during the RSVP reservation process.  During the call admission control process, the IPT device needs to know whether a sufficient QoS level is available from the network prior to establishing the call.   
 
The sending device (caller) uses RSVP to signal the desired QoS level based on an SLA or enterprise network policies.  If there are insufficient network resources to achieve this QoS level, then it is desirable to immediately send a response back to the sending device via a Path-Err rather than wait for the RSVP message to make its 'round trip' from the receiver back to the sender.
 
The approach in the draft minimizes call setup time by providing a much quicker RSVP 'response' to the IPT device so it can quickly make alternate choices.  (The IPT device may provide fast busy tones to the user, an IPT gateway may have a PSTN fallback connection or the IPT device may reinitiate the reservation with a low bandwidth codec.) 
 
I agree with Ramesh's point below that the receiver doesn't provide any additional information so there is no need to add the extra round trip delay of the ResvErr message.
 
Regards,
 
..... Ralph
 
-----Original Message-----
From: Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com]
Sent: Friday, February 02, 2001 5:10 PM
To: Weiss, Walter; Yoram Bernet; Ron Cohen; rap
Cc: Santitoro, Ralph [GUAR:1482-M:EXCH]
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Walter,
 
One of the main aims of this draft is let the a class of sender know ASAP when there are no resources available to meet this requirements of this session. One such example is IP phones which operate with a fixed flowspec and receiver just a copy of sender Tspec. The PDP will return this specific error based on the application sending (i.e., receiver is not going provide PDP any more information beyond what is in the PATH message). By sending a ResvErr back to receiver and receiver sending this ResvErr indication using another control channel will add to delay in setting up the call. Some class of applications can not tolerate this delay, for those applications PDP will return this error code in PathErr message. Ralph can provide more details on this class of applications.
 
Ramesh
-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,

The premise of IntServ is that both ends agree to a service level. One of the main concerns I have with this proposal is that only one side is being told of a specific (less optimal)service alternative. In order to preserve the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob B.), might be to send a ResvErr back to the receiver with a flowspec that has a higher probability of success. This would allow the receiver to send a revised Resv back to the sender allowing for both a viable reservation (with all it's properties), as well as the most ideal DSCP mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; rap@ops.ietf.org
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Ron:
>
> Thanks for the comments. This is getting complicated enouhg
> to warrant some
> face to face discussion. In any case, some responses below:
>
> > After thinking on this subject for a while, I agree that
> > there needs to be
> > a parameter (forget formats for a minute) returned to the
> sender that
> > differs between do-not-send and no-QoS-admission failures.
> > Otherwise the
> > solution is not flexible enough.
> >
> > I (still) think that its required to let the PDP know two
> > things in the
> > Path message.
> > (1) Its behavior (the fact that its going to send traffic in
> > the specified
> > TSPEC regardless of successful QoS admission).
>
> The application may or may not know this. For example - an
> application might
> (in response to failed admission control, but not the 'do not
> send' message)
> defer to the user, with a UI of the form: "You will not be
> granted QoS for
> this session. You may: 1) try your call again later 2)
> proceed with no qos
> 3) retry with a lesser codec (e.g. press the 56 Kbps button
> instead of the
> T-1 button).
>
> > (2) Whether it supports the new instructions.
>
> As i'll explain below - an application could tell you this,
> but I don't
> think it affords you to behave any differently...
> >
> > I'll try to give examples why these are needed below, but
> > regardless of
> > providing a set of persuading examples, I believe in smart
> > networks and
> > policy makers to allow flexible policy enforcement, and
> > therefore I believe
> > in the necessity to add this information to the Path message.
>
> I beleive that - if you add to a protocol - you must be able
> to explain
> specifically how the addition will change the behaviour of
> the peers that
> participate in the protocol. You do take a stab at this
> below, but - as I
> will show, i'm not sure that the behaviours you propose
> really work. If we
> conclude that there are no valuable behavioural changes that
> result from the
> protocol addition, then I don't think it can be justified on
> the abstract
> basis of "smart networks and felxible policy enforcement".
> 
> >
> > Example 1: transition period - why (2) is needed:
> >
> > Suppose we have a network environment where on some hosts an
> > application x
> > is upgraded to support the new standard and some are not.
> Suppose the
> > application is sending traffic regardless of successful RSVP
> > setup. The
> > administrator must control the application on both upgraded
> > an not-upgraded
> > hosts and make sure that these do not harm the WAN traffic. For the
> > upgraded applications Path-Err will instruct them to shut up.
> > For the older
> > ones, the only option is to map them to LBE. Therefore the
> > policy specified
> > would be something of the form:
> >
> > If (app=x AND upgraded) deny
> > If (app=x AND not-upgraded) admit and set DSCP to LBE.
>
> This approach suffers from a number of problems.
>
> First of all - it largely removes the incentive for an
> application to be
> well-behaved. If the application is not upgraded, it at least
> gets to try to
> get service. If it's upgraded - it gets completely denied.
> Why should an
> application upgrade?
>
> Second - if you have the means in the network to provide
> traffic separation,
> then you should apply this means regardless of what the app
> says or does not
> say it will do. In other words - the signaling provides you with the
> classification information that you need to recognize the
> flow of interest.
> If you have the ability to use this classification info to
> downgrade the
> priority of the traffic in the WAN, then you should do so -
> regardless. Thus
> - your behaviour would not change because the app claims to
> be well behaved.
>
> The 'do not send' policy is primarily intended for networks
> that do not have
> the ability to offer traffic separation between b/e and lbe. On these
> networks, the choice of the netadmin is to 1) allow the app
> to be deployed,
> regardless of its behaviour, thereby running the risk that
> the wan resources
> will be trashed. 2) refuse to deploy the app on the wan. 3)
> allow the app to
> be deployed only if it is well-behaved.
>
> >
> > The PDP can know if the app is upgraded if the additional
> > object/parameter
> > appears in the path message.
> > Any alternative would force the administrator to add a list
> > of hosts where
> > the application is upgraded and where it is not. This would
> > be a nightmare.
>
> Indeed, the hypothetical parameter could tell the pdp that
> the app would or
> would not do something. but - i maintain that you still would
> have to apply
> the same behaviour, regardless.
> >
> > Example 2: why (1) is needed:
> >
> > The policy I want to enforce on a WAN interface is the following:
> >
> > Don't admit QoS request beyond X kb/s
> > Don't allow sending beyond Y kb/s
> >
> > To implement this policy I have two counters in my PDP:
> > Counter x measures the amount of admitted bandwidth for QoS.
> > It is updated
> > for each successful Resv using the RSPEC carried in the
> Resv message.
> > Counter y measures the amount of traffic sent by the sender
> > as declared in
> > the Path TSPEC. When should I update this counter? If traffic
> > is sent only
> > after successful admission, I should update the counter with
> > the Path TSPEC
> > only after successful admission of the Resv message.
> > Otherwise, I will
> > reject Path messages sent by other hosts before I'm sure that
> > this is the
> > actual TSPEC used, and not the reduced TSPEC that can be negotiated
> > following admission failure.
>
> I imagined that there would be one resource counter for each
> service level
> (except b/e and lbe). The counter would be conditionally
> debited as soon as
> a path message is seen. The debit could be reversed if the
> reservation is
> denied. This does result in brief underestimations of
> available resources,
> but - this situation occurs in many scenarios and doesn't
> strike me as a
> problem.
>
> > If the sender is going to send traffic in any case, without
> > waiting for
> > successful Resv message, I should update the counter when the
> > Path message
> > arrives, as I must guard against a situation where a Resv
> > will not arrive
> > at all.
>
> If the sender is going to send without a reservation, the
> sender will not
> consume resources at a prioritized service level. The
> sender's traffic will
> be in be or lbe and therefore, need not be counted.
>
> > See some minor remarks inline as well
> >
> > >2. It would complicate the protocol exchange - instead of
> > relying solely on
> > >a response from the network indicating that the network does
> > not want the
> > >app to send, this would require both a query from the
> > application and a
> > >response from the network.
> >
> > I'm not sure what you mean by query and response. We are
> > talking on the
> > normal RSVP messages exchange. Path downstream, Resv or
> > Path-Err upstream.
> >
>
> As I proposed the protocol exchanges, there would be no additional
> information in the 'query' or the application's message to
> the network (the
> path message in this case). The additional information would
> be only in the
> 'response' (the path_err message). As you propose it, there would be
> additional info in both. If you were to for example, build a protocol
> simulator/tester, your approach is more complex to model (and
> therefore, to
> implement, to test and to operate). Unless you can show a
> concrete benefit
> of the added complexity, I oppose the added complexity.
>
> > >I'm not sure why it is necessary to pigeonhole applications
> > as one or the
> > >other. The same application may use different strategies at
> > different times.
> > >For example, an application might try lesser codecs until it
> > finds that none
> > >are acceptable by the network, at which time it would just
> > not send (or
> > >alternatively, send with best-effort). Such an application
> > is both of the
> > >type that is going to send anyhow (unless prohibited) and
> > simultaneously of
> > >the type that is going to renegotiate. Again - the
> > distinction you draw
> > >seems to just complicate the set of application behaviours.
> >
> > You don't pigeonhole applications, you describe their
> > behavior for each
> > flow they intend to send. In each round, the application
> > sends different
> > Path messages (different TSPECs according to codecs), it also
> > knows whether
> > it is going to wait for a successful Resv message before
> sending the
> > traffic. It can send this information in the Path message.
> >
>
> As stated in my earlier comments, the application may defer
> this choice to
> the user. The network should not need to behave differently
> on this basis.
>
> > >It is true that this alternative would give the PEP/PDP
> some explicit
> > >information about the application. However - i'm not sure
> > what the PEP/PDP
> > >would do differently based on this information. Unless the
> > PEP/PDP does
> > >something useful and different, i'm not sure that this
> justifies the
> > >additional protocol exchange.
> >
> > There is no additional protocol exchange.
> >
>
> Sorry - by 'protocol exchange' I meant, 'additional
> information carried in
> protocol messages which require additional parsing,
> additional decision
> making and may alter the progression of a protocol exchange'.
>
> Regards,
> Yoram
>

------_=_NextPart_001_01C08F7D.D4DE73AA-- From owner-rap@ops.ietf.org Mon Feb 5 09:30:07 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06653 for ; Mon, 5 Feb 2001 09:30:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PmeY-000LE6-00 for rap-data@psg.com; Mon, 05 Feb 2001 06:30:02 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14PmeX-000LDs-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 06:30:01 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 09:20:35 -0500 Message-ID: From: "Weiss, Walter" To: "'Dan Romascanu'" , Andrew Smith , Ralph Santitoro Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 09:20:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F7E.CD09D9C0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F7E.CD09D9C0 Content-Type: text/plain; charset="iso-8859-1" Dan, A number of studies have been done that describe telephone user expectations. Interestingly enough, these expectations differ greatly depending on the situation (landline vs mobile, local vs international, etc.) I am aware of a specific target, but I don't recall the source. I recollection is vague on this but I seem to recall something like 300ms. Hence my prior concern over back to back H.323/SIP and RSVP negotiation overhead. regards, -Walter > -----Original Message----- > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: Monday, February 05, 2001 12:57 AM > To: Andrew Smith; Ralph Santitoro > Cc: rap > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Hi Andy, > > If IP Telephony is the application, one measure of "quickly", > "fast", etc. > would be how much you would allow from a phone user > perspective between the > moment dialing ended until you hear the phone ringing ("call > accepted'') or > the network returning you a "busy" signal ("call rejected"). > > Regards, > > Dan > > > > -----Original Message----- > > From: Andrew Smith [SMTP:ah_smith@pacbell.net] > > Sent: Sat February 03 2001 9:59 > > To: Ralph Santitoro > > Cc: rap > > Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt > > > > Ralph, > > > > Can you provide some quantitative data here e.g. some units > and values to > > go > > with "immediately", "quickly", "fast" etc. It's hard to > make the right > > protocol > > design tradeoffs with people using such qualitative terminology. > > > > Thanks, > > > > Andrew > > > ------_=_NextPart_001_01C08F7E.CD09D9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt

Dan,

A number of studies have been done that describe = telephone user expectations. Interestingly enough, these expectations = differ greatly depending on the situation (landline vs mobile, local vs = international, etc.) I am aware of a specific target, but I don't = recall the source. I recollection is vague on this but I seem to recall = something like 300ms. Hence my prior concern over back to back = H.323/SIP and RSVP negotiation overhead.

regards,

-Walter

> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]=
> Sent: Monday, February 05, 2001 12:57 AM
> To: Andrew Smith; Ralph Santitoro
> Cc: rap
> Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Hi Andy,
>
> If IP Telephony is the application, one measure = of "quickly",
> "fast", etc.
> would be how much you would allow from a phone = user
> perspective between the
> moment dialing ended until you hear the phone = ringing ("call
> accepted'') or
> the network returning you a "busy" = signal ("call rejected").
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From:       = Andrew Smith [SMTP:ah_smith@pacbell.net]
> > Sent:       = Sat February 03 2001 9:59
> > To: Ralph Santitoro
> > Cc: rap
> > Subject:    Re: = draft-santitoro-rap-policy-errorcodes-01.txt
> >
> > Ralph,
> >
> > Can you provide some quantitative data = here e.g. some units
> and values to
> > go
> > with "immediately", = "quickly", "fast" etc. It's hard to
> make the right
> > protocol
> > design tradeoffs with people using such = qualitative terminology.
> >
> > Thanks,
> >
> > Andrew
> >
>

------_=_NextPart_001_01C08F7E.CD09D9C0-- From owner-rap@ops.ietf.org Mon Feb 5 10:10:23 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08221 for ; Mon, 5 Feb 2001 10:10:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PnGz-000LsJ-00 for rap-data@psg.com; Mon, 05 Feb 2001 07:09:45 -0800 Received: from qnsgs000.nortelnetworks.com ([47.211.0.31] helo=qnsgs000.nortel.com) by psg.com with esmtp (Exim 3.16 #1) id 14PnGy-000LrX-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 07:09:44 -0800 Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Mon, 5 Feb 2001 15:09:00 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Feb 2001 15:08:59 -0000 Message-ID: From: "Mark Gibson" To: "'Weiss, Walter'" , "'Dan Romascanu'" , Andrew Smith , "Ralph Santitoro" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 15:08:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F85.8D5D7AF0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F85.8D5D7AF0 Content-Type: text/plain; charset="iso-8859-1" Sadly, when I put a proposal to the SIP wg that integrated route choice with SIP signalling, it got rejected out of hand in *favour* of the multi-round trip SIP then do RSVP approach that was championed by SIP-DCS. Everything helps when attempting to reduce the post-dial delay to a manageable level, though I would imagine the SIP signalling part would always consume the bulk of PDD time. However, this draft is good in that it permits early rejection of unsuitable TSpecs - if you don't have the capacity for a new session, why set the ADPSEC low to reflect this and wait for the called party to reject. Better is to reject it straight away thus saving the amount of Path state installed (and then removed) and then let the caller (software) decide how to handle things. Mark -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 2:21 PM To: 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH] Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Dan, A number of studies have been done that describe telephone user expectations. Interestingly enough, these expectations differ greatly depending on the situation (landline vs mobile, local vs international, etc.) I am aware of a specific target, but I don't recall the source. I recollection is vague on this but I seem to recall something like 300ms. Hence my prior concern over back to back H.323/SIP and RSVP negotiation overhead. regards, -Walter > -----Original Message----- > From: Dan Romascanu [ mailto:dromasca@avaya.com ] > Sent: Monday, February 05, 2001 12:57 AM > To: Andrew Smith; Ralph Santitoro > Cc: rap > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Hi Andy, > > If IP Telephony is the application, one measure of "quickly", > "fast", etc. > would be how much you would allow from a phone user > perspective between the > moment dialing ended until you hear the phone ringing ("call > accepted'') or > the network returning you a "busy" signal ("call rejected"). > > Regards, > > Dan > > > > -----Original Message----- > > From: Andrew Smith [SMTP:ah_smith@pacbell.net] > > Sent: Sat February 03 2001 9:59 > > To: Ralph Santitoro > > Cc: rap > > Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt > > > > Ralph, > > > > Can you provide some quantitative data here e.g. some units > and values to > > go > > with "immediately", "quickly", "fast" etc. It's hard to > make the right > > protocol > > design tradeoffs with people using such qualitative terminology. > > > > Thanks, > > > > Andrew > > > ------_=_NextPart_001_01C08F85.8D5D7AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt

S= adly, when I put a proposal to the SIP wg that integrated route choice with = SIP signalling, it got rejected out of hand in *favour* of the multi-round trip SIP then do RSVP approach that was championed = by SIP-DCS. Everything helps when attempting to reduce the post-dial delay to a = manageable level, though I would imagine the SIP signalling part would always = consume the bulk of PDD time.

<= ![if = !supportEmptyParas]> 

=

H= owever, this draft is good in that it permits early rejection of unsuitable TSpecs = – if you don’t have the capacity for a new session, why set the ADPSEC low = to reflect this and wait for the called party to reject. Better is to reject it = straight away thus saving the amount of Path state installed (and then removed) and = then let the caller (software) decide how to handle = things.

<= ![if = !supportEmptyParas]> 

=

M= ark

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Monday, February = 05, 2001 2:21 PM
To: 'Dan Romascanu'; = Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH]
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

 

Dan,

A number of studies have been = done that describe telephone user expectations. Interestingly enough, these = expectations differ greatly depending on the situation (landline vs mobile, local vs international, etc.) I am aware of a specific target, but I don't = recall the source. I recollection is vague on this but I seem to recall something = like 300ms. Hence my prior concern over back to back H.323/SIP and RSVP = negotiation overhead.

regards,

-Walter

> -----Original = Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]=
> Sent: Monday, February 05, 2001 12:57 = AM
> To: Andrew Smith; Ralph Santitoro
> Cc: rap
> Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Hi Andy,
>
> If IP Telephony is the application, one measure of "quickly",
> "fast", etc.
> would be how much you would allow from a phone user =
> perspective between the
> moment dialing ended until you hear the phone ringing ("call
> accepted'') or
> the network returning you a "busy" signal ("call rejected").
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From:       Andrew = Smith [SMTP:ah_smith@pacbell.net]
> > Sent:       Sat = February 03 2001 9:59
> > To: Ralph Santitoro
> > Cc: rap
> > Subject:    Re: draft-santitoro-rap-policy-errorcodes-01.txt
> >
> > Ralph,
> >
> > Can you provide some quantitative data here e.g. = some units
> and values to
> > go
> > with "immediately", = "quickly", "fast" etc. It's hard to
> make the right
> > protocol
> > design tradeoffs with people using such = qualitative terminology.
> >
> > Thanks,
> >
> > Andrew
> >
>

------_=_NextPart_001_01C08F85.8D5D7AF0-- From owner-rap@ops.ietf.org Mon Feb 5 10:55:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10149 for ; Mon, 5 Feb 2001 10:55:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Pnx9-000Mhq-00 for rap-data@psg.com; Mon, 05 Feb 2001 07:53:19 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14Pnx6-000MhY-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 07:53:17 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 10:43:49 -0500 Message-ID: From: "Weiss, Walter" To: "'Mark Gibson'" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 10:43:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F8A.6EBCCE20" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F8A.6EBCCE20 Content-Type: text/plain; charset="iso-8859-1" Mark, I would actually expect RSVP to consume more time than SIP. There are two factors to consider. First RSVP is a hop by hop protocol. While in practice most hops would have RSVP disabled, I would still expect 2 hops best case (at the LAN/WAN transition points) and 2 hops per DS domain (once at ingress and once at egress) worst case. Further, in the new model for RSVP, the protocol is used more as a policy proxy than to configure switches. As such, when a RSVP message is received, it is likely to be redirected to a PDP via COPS before propogating the message. The redirection and processing are also likely to add significantly to the delay. My main reason for suggesting this alternative is because there is no implicit binding between a DSCP and a service level. Let me be a little clearer. There is no well defined DSCP for voice, let alone a less optimal DSCP. Further, DSCPs are configured and have unique QoS semantics on a per domain basis. It is highly likely that IPT traffic will pass through at least three domains. As such any of them can not only demote a service, but potentially promote a service as well. Irrespective of the course taken, there are two things to be avoided. One is the exclusive reliance on DSCP mappings. If the Path is rejected on the ingress, but a specific alternate DSCP is offered, there is an inherent and flawed assumption that the DSCP will mapped properly across DS domains resulting in non-deterministic behaviour. Second, we should avoid inconsistencies in the expectations of the sender and the receiver. With a reservation in place (irrespective of the service level), both the sender and receiver understand the bounds the behaviour. Further, with a non-optimal reservation, the opportunity exists to only use the less optimal DSCP in those portions of the network where contention prevents the use of the optimal DSCP. In other words, the optimal DSCP in some portions of the network can improve overall service characteristics. regards, -Walter -----Original Message----- From: Mark Gibson [mailto:mrg@nortelnetworks.com] Sent: Monday, February 05, 2001 10:09 AM To: 'Weiss, Walter'; 'Dan Romascanu'; Andrew Smith; Ralph Santitoro Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Sadly, when I put a proposal to the SIP wg that integrated route choice with SIP signalling, it got rejected out of hand in *favour* of the multi-round trip SIP then do RSVP approach that was championed by SIP-DCS. Everything helps when attempting to reduce the post-dial delay to a manageable level, though I would imagine the SIP signalling part would always consume the bulk of PDD time. However, this draft is good in that it permits early rejection of unsuitable TSpecs - if you don't have the capacity for a new session, why set the ADPSEC low to reflect this and wait for the called party to reject. Better is to reject it straight away thus saving the amount of Path state installed (and then removed) and then let the caller (software) decide how to handle things. Mark -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 2:21 PM To: 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH] Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Dan, A number of studies have been done that describe telephone user expectations. Interestingly enough, these expectations differ greatly depending on the situation (landline vs mobile, local vs international, etc.) I am aware of a specific target, but I don't recall the source. I recollection is vague on this but I seem to recall something like 300ms. Hence my prior concern over back to back H.323/SIP and RSVP negotiation overhead. regards, -Walter > -----Original Message----- > From: Dan Romascanu [ mailto:dromasca@avaya.com ] > Sent: Monday, February 05, 2001 12:57 AM > To: Andrew Smith; Ralph Santitoro > Cc: rap > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Hi Andy, > > If IP Telephony is the application, one measure of "quickly", > "fast", etc. > would be how much you would allow from a phone user > perspective between the > moment dialing ended until you hear the phone ringing ("call > accepted'') or > the network returning you a "busy" signal ("call rejected"). > > Regards, > > Dan > > > > -----Original Message----- > > From: Andrew Smith [SMTP:ah_smith@pacbell.net] > > Sent: Sat February 03 2001 9:59 > > To: Ralph Santitoro > > Cc: rap > > Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt > > > > Ralph, > > > > Can you provide some quantitative data here e.g. some units > and values to > > go > > with "immediately", "quickly", "fast" etc. It's hard to > make the right > > protocol > > design tradeoffs with people using such qualitative terminology. > > > > Thanks, > > > > Andrew > > > ------_=_NextPart_001_01C08F8A.6EBCCE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
Mark,
 
I=20 would actually expect RSVP to consume more time than SIP. There are two = factors=20 to consider. First RSVP is a hop by hop protocol. While in practice = most hops=20 would have RSVP disabled, I would still expect 2 hops best case = (at the=20 LAN/WAN transition points) and 2 hops per DS domain (once at ingress = and once at=20 egress) worst case. Further, in the new model for RSVP, the = protocol is=20 used more as a policy proxy than to configure switches. As such, when a = RSVP=20 message is received, it is likely to be redirected to a PDP via COPS = before=20 propogating the message. The redirection and processing are also likely = to add=20 significantly to the delay.
 
My=20 main reason for suggesting this alternative is because there is no = implicit=20 binding between a DSCP and a service level. Let me be a little clearer. = There is=20 no well defined DSCP for voice, let alone a less optimal DSCP. Further, = DSCPs=20 are configured and have unique QoS semantics on a per domain basis. It = is highly=20 likely that IPT traffic will pass through at least three domains. As = such any of=20 them can not only demote a service, but potentially promote a service = as well.=20 Irrespective of the course taken, there are two things to be = avoided. One=20 is the exclusive reliance on DSCP mappings. If the Path is rejected on = the=20 ingress, but a specific alternate DSCP is offered, there is an inherent = and=20 flawed assumption that the DSCP will mapped properly across DS domains = resulting=20 in non-deterministic behaviour. Second, we should avoid inconsistencies = in the=20 expectations of the sender and the receiver. With a reservation in = place=20 (irrespective of the service level), both the sender and=20 receiver understand the bounds the behaviour. Further, with a = non-optimal reservation, the opportunity exists to only use the less = optimal=20 DSCP in those portions of the network where contention prevents the use = of the=20 optimal DSCP. In other words, the optimal DSCP in some portions of the = network=20 can improve overall service characteristics.
 
regards,
 
-Walter
-----Original Message-----
From: Mark Gibson=20 [mailto:mrg@nortelnetworks.com]
Sent: Monday, February 05, = 2001=20 10:09 AM
To: 'Weiss, Walter'; 'Dan Romascanu'; Andrew = Smith; Ralph=20 Santitoro
Cc: rap
Subject: RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

Sadly,=20 when I put a proposal to the SIP wg that integrated route choice with = SIP=20 signalling, it got rejected out of hand in *favour* of the multi-round = trip SIP then=20 do RSVP approach that was championed by SIP-DCS. Everything helps = when=20 attempting to reduce the post-dial delay to a manageable level, = though I would=20 imagine the SIP signalling part would always consume the bulk of PDD = time.=20

 

=

However,=20 this draft is good in that it permits early rejection of unsuitable = TSpecs –=20 if you don’t have the capacity for a new session, why set the = ADPSEC low to=20 reflect this and wait for the called party to reject. Better is to = reject it=20 straight away thus saving the amount of Path state installed (and = then=20 removed) and then let the caller (software) decide how to handle=20 things.

 

=

Mark

 

=

-----Original=20 Message-----
From: = Weiss,=20 Walter [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001 2:21=20 PM
To: 'Dan = Romascanu';=20 Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH]
Cc: rap
Subject: RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

 

Dan,

A number of = studies have=20 been done that describe telephone user expectations. Interestingly = enough,=20 these expectations differ greatly depending on the situation = (landline vs=20 mobile, local vs international, etc.) I am aware of a specific = target, but I=20 don't recall the source. I recollection is vague on this but I seem = to recall=20 something like 300ms. Hence my prior concern over back to back = H.323/SIP and=20 RSVP negotiation overhead.

regards,

-Walter

> = -----Original=20 Message-----=20
> From: Dan Romascanu [mailto:dromasca@avaya.com]=
> Sent: = Monday, February=20 05, 2001 12:57 AM=20
> To: Andrew Smith; Ralph=20 Santitoro=20
> Cc: = rap
> Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt
> =
> =
> Hi=20 Andy,=20
>
> If IP = Telephony is the=20 application, one measure of "quickly",
> "fast", = etc.
> would be = how much you=20 would allow from a phone user
> perspective between=20 the=20
> moment dialing ended = until you hear=20 the phone ringing ("call
> accepted'') = or
> the = network returning=20 you a "busy" signal ("call rejected").
>
>=20 Regards,=20
>
> = Dan
> =
> =
> > = -----Original=20 Message-----=20
> >=20 From:       Andrew Smith=20 [SMTP:ah_smith@pacbell.net]
> >=20 Sent:       Sat February 03 2001=20 9:59=20
> > To: Ralph=20 Santitoro=20
> > Cc: = rap
> >=20 Subject:    Re:=20 draft-santitoro-rap-policy-errorcodes-01.txt
> >=20
> > = Ralph,
> >=20
> > Can you provide = some=20 quantitative data here e.g. some units
> and values = to
> > go=20
> > with "immediately", = "quickly",=20 "fast" etc. It's hard to
> make the = right
> > = protocol=20
> > design tradeoffs = with people=20 using such qualitative terminology.
> >
> >=20 Thanks,=20
> >
> >=20 Andrew =
> >
> =

------_=_NextPart_001_01C08F8A.6EBCCE20-- From owner-rap@ops.ietf.org Mon Feb 5 11:19:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10880 for ; Mon, 5 Feb 2001 11:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PoLA-000NAT-00 for rap-data@psg.com; Mon, 05 Feb 2001 08:18:08 -0800 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14PoL9-000NAN-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 08:18:07 -0800 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA29318 for ; Mon, 5 Feb 2001 11:18:06 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA29298 for ; Mon, 5 Feb 2001 11:18:05 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 17:18:04 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B0E4494@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap Subject: IESG has approved 2 documents Date: Mon, 5 Feb 2001 17:18:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has now approved these documents: > draft-ietf-rap-signaled-priority-v2-00.txt > draft-ietf-rap-rsvp-newidentity-01.txt > We have added the attached notes to RFC-Editor: Thanks to the Authors/editors and the WG for your work and patience. Bert > ---------------------------------------------------- > Note to RFC-Editor: > > for document draft-ietf-rap-signaled-priority-v2-00.txt > > - On title page, pls change "replaces RFC 2751" with > "Obsoletes RFC 2751" > - Pls add a reference to RFC2571 as well. > > for document draft-ietf-rap-rsvp-newidentity-01.txt > > - add this IESG note to the title page > > > IESG NOTE: The use of digital signatures, as (for example) described > > in section 3.3.3 provides inadequate protection against a cut-and-paste > > form of replay attack, even when used in connection with the INTEGRITY > > object. This is due to the lack of cryptographic "freshness" guarantees > > in the AUTH_DATA object. In fact this weakness exists for any policy > > data object transported with this mechanism. > > A future version of this document and related documents will > > address this serious shortcoming. > > > - move last sentence of section 1. to abstract section > (make it last sentence in that section). > > - Pls add a reference to RFC2752 too. > > Thanks, > Bert > From owner-rap@ops.ietf.org Mon Feb 5 11:58:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11813 for ; Mon, 5 Feb 2001 11:58:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PowW-000Nuu-00 for rap-data@psg.com; Mon, 05 Feb 2001 08:56:44 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14PowT-000Ntn-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 08:56:42 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 11:47:10 -0500 Message-ID: From: "Weiss, Walter" To: "'Yoram Bernet'" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 11:47:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F93.4896E72C" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F93.4896E72C Content-Type: text/plain; charset="iso-8859-1" Yoram, In essence, I am both agreeing and disagreeing. I am agreeing that "it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains." I am disagreeing with the premise that a PathErr with an alternate DSCP achieves the aforementioned objective, particularly when considering the interdomain issues I raised previously. regards, -Walter -----Original Message----- From: Yoram Bernet [mailto:yoramb@microsoft.com] Sent: Monday, February 05, 2001 11:30 AM To: Weiss, Walter; 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 7:44 AM To: 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Mark, I would actually expect RSVP to consume more time than SIP. There are two factors to consider. First RSVP is a hop by hop protocol. While in practice most hops would have RSVP disabled, I would still expect 2 hops best case (at the LAN/WAN transition points) and 2 hops per DS domain (once at ingress and once at egress) worst case. Further, in the new model for RSVP, the protocol is used more as a policy proxy than to configure switches. As such, when a RSVP message is received, it is likely to be redirected to a PDP via COPS before propogating the message. The redirection and processing are also likely to add significantly to the delay. [Yoram Bernet] Just a minute - policies are cached. In the steady state, RSVP messages are not redirected to PDPs *before propagating the message*! My main reason for suggesting this alternative is because there is no implicit binding between a DSCP and a service level. Let me be a little clearer. There is no well defined DSCP for voice, let alone a less optimal DSCP. Further, DSCPs are configured and have unique QoS semantics on a per domain basis. It is highly likely that IPT traffic will pass through at least three domains. As such any of them can not only demote a service, but potentially promote a service as well. Irrespective of the course taken, there are two things to be avoided. One is the exclusive reliance on DSCP mappings. If the Path is rejected on the ingress, but a specific alternate DSCP is offered, there is an inherent and flawed assumption that the DSCP will mapped properly across DS domains resulting in non-deterministic behaviour. Second, we should avoid inconsistencies in the expectations of the sender and the receiver. With a reservation in place (irrespective of the service level), both the sender and receiver understand the bounds the behaviour. Further, with a non-optimal reservation, the opportunity exists to only use the less optimal DSCP in those portions of the network where contention prevents the use of the optimal DSCP. In other words, the optimal DSCP in some portions of the network can improve overall service characteristics. [Yoram Bernet] Are you saying that DSCPs cannot reliably invoke services? What is the "Serv" part in DiffServ then? With the correct admission control and the correct provisioning and traffic conditioning, DSCPs can invoke specific services. The network understands how it is provisioned and just what services DSCPs can offer through it. That's why the network must inform the user, which DSCP should be used for a particular service. I agree with you that interdomain issues are important and that a DSCP in one domain may mean something different than a DSCP in another domain, but - that is why it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains. Are you rejecting RFC2996-2998? Or do you agree witht he direction in those? ------_=_NextPart_001_01C08F93.4896E72C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
Yoram,
 
In=20 essence, I am both agreeing and disagreeing. I am agreeing that "it is = all the=20 more important to tie domains together through some higher layer = abstraction -=20 such as signaling for a certain type of service, across all intervening = domains." I am disagreeing with the premise that a PathErr with an = alternate=20 DSCP achieves the aforementioned objective, particularly when = considering the=20 interdomain issues I raised previously.
 
regards,
 
-Walter
-----Original Message-----
From: Yoram Bernet=20 [mailto:yoramb@microsoft.com]
Sent: Monday, February 05, = 2001 11:30=20 AM
To: Weiss, Walter; 'Mark Gibson'
Cc:=20 rap
Subject: RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

 
-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001 7:44=20 AM
To: 'Mark Gibson'
Cc: rap
Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

Mark,
 
I would actually expect RSVP to consume = more time=20 than SIP. There are two factors to consider. First RSVP is a hop by = hop=20 protocol. While in practice most hops would have RSVP disabled, I = would=20 still expect 2 hops best case (at the LAN/WAN transition = points) and 2=20 hops per DS domain (once at ingress and once at egress) worst = case.=20 Further, in the new model for RSVP, the protocol is used more as a = policy=20 proxy than to configure switches. As such, when a RSVP message is = received,=20 it is likely to be redirected to a PDP via COPS before propogating = the=20 message. The redirection and processing are also likely to add = significantly=20 to the delay.
[Yoram=20 Bernet] Just a minute -  policies are cached. In the = steady=20 state, RSVP messages are not redirected to PDPs *before propagating = the=20 message*!
 
My main reason for suggesting this = alternative is=20 because there is no implicit binding between a DSCP and a service = level. Let=20 me be a little clearer. There is no well defined DSCP for voice, = let alone a=20 less optimal DSCP. Further, DSCPs are configured and have unique = QoS semantics on a per domain basis. It is highly likely that IPT = traffic will=20 pass through at least three domains. As such any of them can not = only demote=20 a service, but potentially promote a service as well. Irrespective = of the=20 course taken, there are two things to be avoided. One is the = exclusive=20 reliance on DSCP mappings. If the Path is rejected on the ingress, = but a=20 specific alternate DSCP is offered, there is an inherent and flawed = assumption that the DSCP will mapped properly across DS domains = resulting in=20 non-deterministic behaviour. Second, we should avoid = inconsistencies in the=20 expectations of the sender and the receiver. With a reservation in = place=20 (irrespective of the service level), both the sender and=20 receiver understand the bounds the behaviour. Further, = with a=20 non-optimal reservation, the opportunity exists to only use the = less optimal=20 DSCP in those portions of the network where contention prevents the = use of=20 the optimal DSCP. In other words, the optimal DSCP in some portions = of the=20 network can improve overall service characteristics.
[Yoram=20 Bernet]  Are you saying that DSCPs cannot reliably invoke = services? What is the "Serv" part in DiffServ then? With the = correct=20 admission control and the correct provisioning and traffic = conditioning,=20 DSCPs can invoke specific services. The network understands how it = is=20 provisioned and just what services DSCPs can offer through it. = That's why=20 the network must inform the user, which DSCP should be used for a = particular=20 service. I agree with you that interdomain issues are important and = that a=20 DSCP in one domain may mean something different than a DSCP in = another=20 domain, but - that is why it is all the more important to tie = domains=20 together through some higher layer abstraction - such as signaling = for a=20 certain type of service, across all intervening domains. Are you = rejecting=20 RFC2996-2998? Or do you agree witht he direction in=20 those?
 
------_=_NextPart_001_01C08F93.4896E72C-- From owner-rap@ops.ietf.org Mon Feb 5 12:20:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12284 for ; Mon, 5 Feb 2001 12:20:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PpI1-000OMc-00 for rap-data@psg.com; Mon, 05 Feb 2001 09:18:57 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14PpHy-000OLz-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 09:18:54 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 12:09:27 -0500 Message-ID: From: "Weiss, Walter" To: "'Yoram Bernet'" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 12:09:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F96.651A648E" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F96.651A648E Content-Type: text/plain; charset="iso-8859-1" Yoram, I would agree that a simple response for Do-Not-Send and less than best-effort is valid. However, I don't believe that either of these do much for IPT or the goals of the errorcodes draft. In other words, what are the call setup delay requirements for a Do-Not-Send and less then best-effort response? regards, -Walter -----Original Message----- From: Yoram Bernet [mailto:yoramb@microsoft.com] Sent: Monday, February 05, 2001 12:10 PM To: Weiss, Walter Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt OK. I agree that there are problems that arise when the full path is not examined beofre returning a DSCP with a PathErr. I think that, at least in certain applications, the value of the mechanisms in the draft justifies work to investigate and address the problems. For example - while selecting the 'right' DSCP for a service might be difficult, returning a less than best-effort DSCP coul;d be easier. Certainly, retunring a DO_NOT_SEND can be doen without understanding the impact on downstream subnetworks. Y -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 8:47 AM To: Yoram Bernet Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, In essence, I am both agreeing and disagreeing. I am agreeing that "it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains." I am disagreeing with the premise that a PathErr with an alternate DSCP achieves the aforementioned objective, particularly when considering the interdomain issues I raised previously. regards, -Walter -----Original Message----- From: Yoram Bernet [mailto:yoramb@microsoft.com] Sent: Monday, February 05, 2001 11:30 AM To: Weiss, Walter; 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 7:44 AM To: 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Mark, I would actually expect RSVP to consume more time than SIP. There are two factors to consider. First RSVP is a hop by hop protocol. While in practice most hops would have RSVP disabled, I would still expect 2 hops best case (at the LAN/WAN transition points) and 2 hops per DS domain (once at ingress and once at egress) worst case. Further, in the new model for RSVP, the protocol is used more as a policy proxy than to configure switches. As such, when a RSVP message is received, it is likely to be redirected to a PDP via COPS before propogating the message. The redirection and processing are also likely to add significantly to the delay. [Yoram Bernet] Just a minute - policies are cached. In the steady state, RSVP messages are not redirected to PDPs *before propagating the message*! My main reason for suggesting this alternative is because there is no implicit binding between a DSCP and a service level. Let me be a little clearer. There is no well defined DSCP for voice, let alone a less optimal DSCP. Further, DSCPs are configured and have unique QoS semantics on a per domain basis. It is highly likely that IPT traffic will pass through at least three domains. As such any of them can not only demote a service, but potentially promote a service as well. Irrespective of the course taken, there are two things to be avoided. One is the exclusive reliance on DSCP mappings. If the Path is rejected on the ingress, but a specific alternate DSCP is offered, there is an inherent and flawed assumption that the DSCP will mapped properly across DS domains resulting in non-deterministic behaviour. Second, we should avoid inconsistencies in the expectations of the sender and the receiver. With a reservation in place (irrespective of the service level), both the sender and receiver understand the bounds the behaviour. Further, with a non-optimal reservation, the opportunity exists to only use the less optimal DSCP in those portions of the network where contention prevents the use of the optimal DSCP. In other words, the optimal DSCP in some portions of the network can improve overall service characteristics. [Yoram Bernet] Are you saying that DSCPs cannot reliably invoke services? What is the "Serv" part in DiffServ then? With the correct admission control and the correct provisioning and traffic conditioning, DSCPs can invoke specific services. The network understands how it is provisioned and just what services DSCPs can offer through it. That's why the network must inform the user, which DSCP should be used for a particular service. I agree with you that interdomain issues are important and that a DSCP in one domain may mean something different than a DSCP in another domain, but - that is why it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains. Are you rejecting RFC2996-2998? Or do you agree witht he direction in those? ------_=_NextPart_001_01C08F96.651A648E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
Yoram,
 
I=20 would agree that a simple response for Do-Not-Send and less than = best-effort is=20 valid. However, I don't believe that either of these do much for IPT or = the=20 goals of the errorcodes draft. In other words, what are the call setup = delay=20 requirements for a Do-Not-Send and less then best-effort=20 response?
 
regards,
 
-Walter
-----Original Message-----
From: Yoram Bernet=20 [mailto:yoramb@microsoft.com]
Sent: Monday, February 05, = 2001 12:10=20 PM
To: Weiss, Walter
Cc: rap
Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

OK.=20 I agree that there are problems that arise when the full path is not = examined=20 beofre returning a DSCP with a PathErr. I think that, at least in = certain=20 applications, the value of the mechanisms in the draft justifies work = to=20 investigate and address the problems. For example - while selecting = the=20 'right' DSCP for a service might be difficult, returning a less than=20 best-effort DSCP coul;d be easier. Certainly, retunring a DO_NOT_SEND = can be=20 doen without understanding the impact on downstream=20 subnetworks.
 
Y
-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001 8:47=20 AM
To: Yoram Bernet
Cc: rap
Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,
 
In=20 essence, I am both agreeing and disagreeing. I am agreeing that "it = is all=20 the more important to tie domains together through some higher = layer=20 abstraction - such as signaling for a certain type of service, = across all=20 intervening domains." I am disagreeing with the premise that a = PathErr with=20 an alternate DSCP achieves the aforementioned objective, = particularly when=20 considering the interdomain issues I raised = previously.
 
regards,
 
-Walter
-----Original Message-----
From: Yoram Bernet=20 [mailto:yoramb@microsoft.com]
Sent: Monday, February = 05, 2001=20 11:30 AM
To: Weiss, Walter; 'Mark Gibson'
Cc: = rap
Subject: RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

 
-----Original Message-----
From: Weiss, = Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Monday, February = 05, 2001=20 7:44 AM
To: 'Mark Gibson'
Cc: = rap
Subject:=20 RE: = draft-santitoro-rap-policy-errorcodes-01.txt

Mark,
 
I would actually expect RSVP to = consume more=20 time than SIP. There are two factors to consider. First RSVP is = a hop by=20 hop protocol. While in practice most hops would have RSVP = disabled, I=20 would still expect 2 hops best case (at the LAN/WAN = transition=20 points) and 2 hops per DS domain (once at ingress and once at=20 egress) worst case. Further, in the new model for RSVP, = the=20 protocol is used more as a policy proxy than to configure = switches. As=20 such, when a RSVP message is received, it is likely to be = redirected to=20 a PDP via COPS before propogating the message. The redirection = and=20 processing are also likely to add significantly to the = delay.
[Yoram=20 Bernet] Just a minute -  policies are cached. In = the=20 steady state, RSVP messages are not redirected to PDPs *before=20 propagating the = message*!
 
My main reason for suggesting this = alternative=20 is because there is no implicit binding between a DSCP and a = service=20 level. Let me be a little clearer. There is no well defined = DSCP for=20 voice, let alone a less optimal DSCP. Further, DSCPs are = configured and=20 have unique QoS semantics on a per domain basis. It is highly = likely=20 that IPT traffic will pass through at least three domains. As = such any=20 of them can not only demote a service, but potentially promote = a service=20 as well. Irrespective of the course taken, there are two = things to=20 be avoided. One is the exclusive reliance on DSCP mappings. If = the Path=20 is rejected on the ingress, but a specific alternate DSCP is = offered,=20 there is an inherent and flawed assumption that the DSCP will = mapped=20 properly across DS domains resulting in non-deterministic = behaviour.=20 Second, we should avoid inconsistencies in the expectations of = the=20 sender and the receiver. With a reservation in place = (irrespective of=20 the service level), both the sender and=20 receiver understand the bounds the behaviour. = Further, with a=20 non-optimal reservation, the opportunity exists to only use the = less=20 optimal DSCP in those portions of the network where contention = prevents=20 the use of the optimal DSCP. In other words, the optimal DSCP = in some=20 portions of the network can improve overall service=20 characteristics.
[Yoram=20 Bernet]  Are you saying that DSCPs cannot reliably = invoke=20 services? What is the "Serv" part in DiffServ then? With the = correct=20 admission control and the correct provisioning and traffic = conditioning,=20 DSCPs can invoke specific services. The network understands how = it is=20 provisioned and just what services DSCPs can offer through it. = That's=20 why the network must inform the user, which DSCP should be used = for a=20 particular service. I agree with you that interdomain issues = are=20 important and that a DSCP in one domain may mean something = different=20 than a DSCP in another domain, but - that is why it is all the = more=20 important to tie domains together through some higher layer = abstraction=20 - such as signaling for a certain type of service, across all=20 intervening domains. Are you rejecting RFC2996-2998? Or do you = agree=20 witht he direction in = those?
 
------_=_NextPart_001_01C08F96.651A648E-- From owner-rap@ops.ietf.org Mon Feb 5 12:38:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12641 for ; Mon, 5 Feb 2001 12:38:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PpZD-000Oiq-00 for rap-data@psg.com; Mon, 05 Feb 2001 09:36:43 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14PpZC-000Oht-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 09:36:42 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 09:10:57 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111D4DFH>; Mon, 5 Feb 2001 09:10:46 -0800 Message-ID: From: Yoram Bernet To: "Weiss, Walter" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 09:10:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F96.8A8E528D" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F96.8A8E528D Content-Type: text/plain; charset="iso-8859-1" OK. I agree that there are problems that arise when the full path is not examined beofre returning a DSCP with a PathErr. I think that, at least in certain applications, the value of the mechanisms in the draft justifies work to investigate and address the problems. For example - while selecting the 'right' DSCP for a service might be difficult, returning a less than best-effort DSCP coul;d be easier. Certainly, retunring a DO_NOT_SEND can be doen without understanding the impact on downstream subnetworks. Y -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 8:47 AM To: Yoram Bernet Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, In essence, I am both agreeing and disagreeing. I am agreeing that "it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains." I am disagreeing with the premise that a PathErr with an alternate DSCP achieves the aforementioned objective, particularly when considering the interdomain issues I raised previously. regards, -Walter -----Original Message----- From: Yoram Bernet [mailto:yoramb@microsoft.com] Sent: Monday, February 05, 2001 11:30 AM To: Weiss, Walter; 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 7:44 AM To: 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Mark, I would actually expect RSVP to consume more time than SIP. There are two factors to consider. First RSVP is a hop by hop protocol. While in practice most hops would have RSVP disabled, I would still expect 2 hops best case (at the LAN/WAN transition points) and 2 hops per DS domain (once at ingress and once at egress) worst case. Further, in the new model for RSVP, the protocol is used more as a policy proxy than to configure switches. As such, when a RSVP message is received, it is likely to be redirected to a PDP via COPS before propogating the message. The redirection and processing are also likely to add significantly to the delay. [Yoram Bernet] Just a minute - policies are cached. In the steady state, RSVP messages are not redirected to PDPs *before propagating the message*! My main reason for suggesting this alternative is because there is no implicit binding between a DSCP and a service level. Let me be a little clearer. There is no well defined DSCP for voice, let alone a less optimal DSCP. Further, DSCPs are configured and have unique QoS semantics on a per domain basis. It is highly likely that IPT traffic will pass through at least three domains. As such any of them can not only demote a service, but potentially promote a service as well. Irrespective of the course taken, there are two things to be avoided. One is the exclusive reliance on DSCP mappings. If the Path is rejected on the ingress, but a specific alternate DSCP is offered, there is an inherent and flawed assumption that the DSCP will mapped properly across DS domains resulting in non-deterministic behaviour. Second, we should avoid inconsistencies in the expectations of the sender and the receiver. With a reservation in place (irrespective of the service level), both the sender and receiver understand the bounds the behaviour. Further, with a non-optimal reservation, the opportunity exists to only use the less optimal DSCP in those portions of the network where contention prevents the use of the optimal DSCP. In other words, the optimal DSCP in some portions of the network can improve overall service characteristics. [Yoram Bernet] Are you saying that DSCPs cannot reliably invoke services? What is the "Serv" part in DiffServ then? With the correct admission control and the correct provisioning and traffic conditioning, DSCPs can invoke specific services. The network understands how it is provisioned and just what services DSCPs can offer through it. That's why the network must inform the user, which DSCP should be used for a particular service. I agree with you that interdomain issues are important and that a DSCP in one domain may mean something different than a DSCP in another domain, but - that is why it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains. Are you rejecting RFC2996-2998? Or do you agree witht he direction in those? ------_=_NextPart_001_01C08F96.8A8E528D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
OK. I=20 agree that there are problems that arise when the full path is not = examined=20 beofre returning a DSCP with a PathErr. I think that, at least in = certain=20 applications, the value of the mechanisms in the draft justifies work = to=20 investigate and address the problems. For example - while selecting the = 'right'=20 DSCP for a service might be difficult, returning a less than = best-effort DSCP=20 coul;d be easier. Certainly, retunring a DO_NOT_SEND can be doen = without=20 understanding the impact on downstream subnetworks.
 
Y
-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001 8:47=20 AM
To: Yoram Bernet
Cc: rap
Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

Yoram,
 
In=20 essence, I am both agreeing and disagreeing. I am agreeing that "it = is all the=20 more important to tie domains together through some higher layer = abstraction -=20 such as signaling for a certain type of service, across all = intervening=20 domains." I am disagreeing with the premise that a PathErr with an = alternate=20 DSCP achieves the aforementioned objective, particularly when = considering the=20 interdomain issues I raised previously.
 
regards,
 
-Walter
-----Original Message-----
From: Yoram Bernet=20 [mailto:yoramb@microsoft.com]
Sent: Monday, February 05, = 2001=20 11:30 AM
To: Weiss, Walter; 'Mark Gibson'
Cc:=20 rap
Subject: RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

 
-----Original Message-----
From: Weiss, Walter = [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001=20 7:44 AM
To: 'Mark Gibson'
Cc: = rap
Subject:=20 RE: = draft-santitoro-rap-policy-errorcodes-01.txt

Mark,
 
I would actually expect RSVP to = consume more time=20 than SIP. There are two factors to consider. First RSVP is a hop = by hop=20 protocol. While in practice most hops would have RSVP disabled, I = would=20 still expect 2 hops best case (at the LAN/WAN transition = points) and=20 2 hops per DS domain (once at ingress and once at = egress) worst case.=20 Further, in the new model for RSVP, the protocol is used more as = a policy=20 proxy than to configure switches. As such, when a RSVP message is = received, it is likely to be redirected to a PDP via COPS before=20 propogating the message. The redirection and processing are also = likely to=20 add significantly to the delay.
[Yoram=20 Bernet] Just a minute -  policies are cached. In = the steady=20 state, RSVP messages are not redirected to PDPs *before = propagating the=20 message*!
 
My main reason for suggesting this = alternative is=20 because there is no implicit binding between a DSCP and a service = level.=20 Let me be a little clearer. There is no well defined DSCP for = voice, let=20 alone a less optimal DSCP. Further, DSCPs are configured and have = unique=20 QoS semantics on a per domain basis. It is highly likely that IPT = traffic=20 will pass through at least three domains. As such any of them can = not only=20 demote a service, but potentially promote a service as well. = Irrespective=20 of the course taken, there are two things to be avoided. One = is the=20 exclusive reliance on DSCP mappings. If the Path is rejected on = the=20 ingress, but a specific alternate DSCP is offered, there is an = inherent=20 and flawed assumption that the DSCP will mapped properly across = DS domains=20 resulting in non-deterministic behaviour. Second, we should avoid = inconsistencies in the expectations of the sender and the = receiver. With a=20 reservation in place (irrespective of the service level), both = the sender=20 and receiver understand the bounds the behaviour. = Further, with=20 a non-optimal reservation, the opportunity exists to only use the = less=20 optimal DSCP in those portions of the network where contention = prevents=20 the use of the optimal DSCP. In other words, the optimal DSCP in = some=20 portions of the network can improve overall service=20 characteristics.
[Yoram=20 Bernet]  Are you saying that DSCPs cannot reliably = invoke=20 services? What is the "Serv" part in DiffServ then? With the = correct=20 admission control and the correct provisioning and traffic = conditioning,=20 DSCPs can invoke specific services. The network understands how = it is=20 provisioned and just what services DSCPs can offer through it. = That's why=20 the network must inform the user, which DSCP should be used for a = particular service. I agree with you that interdomain issues are = important=20 and that a DSCP in one domain may mean something different than a = DSCP in=20 another domain, but - that is why it is all the more important to = tie=20 domains together through some higher layer abstraction - such as = signaling=20 for a certain type of service, across all intervening domains. = Are you=20 rejecting RFC2996-2998? Or do you agree witht he direction in=20 those?
 
------_=_NextPart_001_01C08F96.8A8E528D-- From owner-rap@ops.ietf.org Mon Feb 5 12:47:38 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12809 for ; Mon, 5 Feb 2001 12:47:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PpiS-000OuD-00 for rap-data@psg.com; Mon, 05 Feb 2001 09:46:16 -0800 Received: from snipe.prod.itd.earthlink.net ([207.217.120.62]) by psg.com with esmtp (Exim 3.16 #1) id 14PpiR-000Ou6-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 09:46:15 -0800 Received: from pacbell.net (user-vcauror.dsl.mindspring.com [216.175.111.27]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id JAA18859; Mon, 5 Feb 2001 09:46:01 -0800 (PST) Message-ID: <3A7EE913.1080505@pacbell.net> Date: Mon, 05 Feb 2001 09:55:31 -0800 From: Andrew Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: "Weiss, Walter" CC: rap Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit But, again, you are using phrases like "add significantly" without any numbers to back them up: let's have some hard data please. How long do RSVP hops take in modern equipment? How long does a COPS-RSVP interaction take? How do these numbers compare to the click-click-click of uniselectors (or their solid-state equivalents) in the voice world? Are peoples' perceptions here based on real production implementations of RSVP or based on prototypes running ISI rsvpd (no offence intended, but I believe that that implementation is designed as a proof of concept). Andrew Weiss, Walter wrote: > Mark, > > > > I would actually expect RSVP to consume more time than SIP. There are > two factors to consider. First RSVP is a hop by hop protocol. While in > practice most hops would have RSVP disabled, I would still expect 2 hops > best case (at the LAN/WAN transition points) and 2 hops per DS domain > (once at ingress and once at egress) worst case. Further, in the new > model for RSVP, the protocol is used more as a policy proxy than to > configure switches. As such, when a RSVP message is received, it is > likely to be redirected to a PDP via COPS before propogating the > message. The redirection and processing are also likely to add > significantly to the delay. > > > > My main reason for suggesting this alternative is because there is no > implicit binding between a DSCP and a service level. Let me be a little > clearer. There is no well defined DSCP for voice, let alone a less > optimal DSCP. Further, DSCPs are configured and have unique QoS > semantics on a per domain basis. It is highly likely that IPT traffic > will pass through at least three domains. As such any of them can not > only demote a service, but potentially promote a service as well. > Irrespective of the course taken, there are two things to be avoided. > One is the exclusive reliance on DSCP mappings. If the Path is rejected > on the ingress, but a specific alternate DSCP is offered, there is an > inherent and flawed assumption that the DSCP will mapped properly across > DS domains resulting in non-deterministic behaviour. Second, we should > avoid inconsistencies in the expectations of the sender and the > receiver. With a reservation in place (irrespective of the service > level), both the sender and receiver understand the bounds the > behaviour. Further, with a non-optimal reservation, the opportunity > exists to only use the less optimal DSCP in those portions of the > network where contention prevents the use of the optimal DSCP. In other > words, the optimal DSCP in some portions of the network can improve > overall service characteristics. > > > > regards, > > > > -Walter > > -----Original Message----- > *From:* Mark Gibson [mailto:mrg@nortelnetworks.com] > *Sent:* Monday, February 05, 2001 10:09 AM > *To:* 'Weiss, Walter'; 'Dan Romascanu'; Andrew Smith; Ralph Santitoro > *Cc:* rap > *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt > > Sadly, when I put a proposal to the SIP wg that integrated route > choice with SIP signalling, it got rejected out of hand in > **favour** of the multi-round trip SIP then do RSVP approach that > was championed by SIP-DCS. Everything helps when attempting to > reduce the post-dial delay to a manageable level, though I would > imagine the SIP signalling part would always consume the bulk of PDD > time. > > > > However, this draft is good in that it permits early rejection of > unsuitable TSpecs ? if you don?t have the capacity for a new > session, why set the ADPSEC low to reflect this and wait for the > called party to reject. Better is to reject it straight away thus > saving the amount of Path state installed (and then removed) and > then let the caller (software) decide how to handle things. > > > > Mark > > > > -----Original Message----- > *From:* Weiss, Walter [mailto:wweiss@ellacoya.com] > *Sent:* Monday, February 05, 2001 2:21 PM > *To:* 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH] > *Cc:* rap > *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > Dan, > > A number of studies have been done that describe telephone user > expectations. Interestingly enough, these expectations differ > greatly depending on the situation (landline vs mobile, local vs > international, etc.) I am aware of a specific target, but I don't > recall the source. I recollection is vague on this but I seem to > recall something like 300ms. Hence my prior concern over back to > back H.323/SIP and RSVP negotiation overhead. > > regards, > > -Walter > > > -----Original Message----- > > From: Dan Romascanu [mailto:dromasca@avaya.com] > > Sent: Monday, February 05, 2001 12:57 AM > > To: Andrew Smith; Ralph Santitoro > > Cc: rap > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > Hi Andy, > > > > If IP Telephony is the application, one measure of "quickly", > > "fast", etc. > > would be how much you would allow from a phone user > > perspective between the > > moment dialing ended until you hear the phone ringing ("call > > accepted'') or > > the network returning you a "busy" signal ("call rejected"). > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Andrew Smith [SMTP:ah_smith@pacbell.net] > > > Sent: Sat February 03 2001 9:59 > > > To: Ralph Santitoro > > > Cc: rap > > > Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > Ralph, > > > > > > Can you provide some quantitative data here e.g. some units > > and values to > > > go > > > with "immediately", "quickly", "fast" etc. It's hard to > > make the right > > > protocol > > > design tradeoffs with people using such qualitative terminology. > > > > > > Thanks, > > > > > > Andrew > > > > > > From owner-rap@ops.ietf.org Mon Feb 5 14:35:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15564 for ; Mon, 5 Feb 2001 14:35:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PrNk-0000iZ-00 for rap-data@psg.com; Mon, 05 Feb 2001 11:33:00 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14PrNi-0000iL-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 11:32:59 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 09:23:42 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111D4HGK>; Mon, 5 Feb 2001 09:23:33 -0800 Message-ID: From: Yoram Bernet To: "Weiss, Walter" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 09:22:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F98.43DED79F" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F98.43DED79F Content-Type: text/plain; charset="iso-8859-1" Yoram, I would agree that a simple response for Do-Not-Send and less than best-effort is valid. However, I don't believe that either of these do much for IPT or the goals of the errorcodes draft. [Yoram Bernet] They certainly do satisfyt he goals of the errorcodes draft - tighter control over sender behaviour. In other words, what are the call setup delay requirements for a Do-Not-Send and less then best-effort response? [Yoram Bernet] As for satisfying the goals of the IPT case, this is debatable. I did not dismiss the value of returning DSCPs other than LBE. I just noted that this is more problematic than the simple cases. I think that it still warrants further discussion. I am not the IPT expert here... ------_=_NextPart_001_01C08F98.43DED79F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
Yoram,
 
I=20 would agree that a simple response for Do-Not-Send and less than = best-effort=20 is valid. However, I don't believe that either of these do much for = IPT or the=20 goals of the errorcodes draft.
[Yoram=20 Bernet] They certainly do satisfyt he goals of the errorcodes = draft -=20 tighter control over sender behaviour.
 
  In other=20 words, what are the call setup delay requirements for a Do-Not-Send = and less=20 then best-effort response?
[Yoram = Bernet] As for satisfying the goals of the IPT case, this is = debatable. I=20 did not dismiss the value of returning DSCPs other than LBE. I = just noted=20 that this is more problematic than the simple cases. I think that it = still=20 warrants further discussion. I am not the IPT expert=20 here...
------_=_NextPart_001_01C08F98.43DED79F-- From owner-rap@ops.ietf.org Mon Feb 5 17:52:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19902 for ; Mon, 5 Feb 2001 17:52:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PuSt-0004Ca-00 for rap-data@psg.com; Mon, 05 Feb 2001 14:50:31 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14PuSs-0004Ay-00 for rap@ops.ietf.org; Mon, 05 Feb 2001 14:50:30 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 08:30:32 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111DTW00>; Mon, 5 Feb 2001 08:30:16 -0800 Message-ID: From: Yoram Bernet To: "Weiss, Walter" , "'Mark Gibson'" Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 5 Feb 2001 08:30:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F90.E42F0F1B" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F90.E42F0F1B Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Monday, February 05, 2001 7:44 AM To: 'Mark Gibson' Cc: rap Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Mark, I would actually expect RSVP to consume more time than SIP. There are two factors to consider. First RSVP is a hop by hop protocol. While in practice most hops would have RSVP disabled, I would still expect 2 hops best case (at the LAN/WAN transition points) and 2 hops per DS domain (once at ingress and once at egress) worst case. Further, in the new model for RSVP, the protocol is used more as a policy proxy than to configure switches. As such, when a RSVP message is received, it is likely to be redirected to a PDP via COPS before propogating the message. The redirection and processing are also likely to add significantly to the delay. [Yoram Bernet] Just a minute - policies are cached. In the steady state, RSVP messages are not redirected to PDPs *before propagating the message*! My main reason for suggesting this alternative is because there is no implicit binding between a DSCP and a service level. Let me be a little clearer. There is no well defined DSCP for voice, let alone a less optimal DSCP. Further, DSCPs are configured and have unique QoS semantics on a per domain basis. It is highly likely that IPT traffic will pass through at least three domains. As such any of them can not only demote a service, but potentially promote a service as well. Irrespective of the course taken, there are two things to be avoided. One is the exclusive reliance on DSCP mappings. If the Path is rejected on the ingress, but a specific alternate DSCP is offered, there is an inherent and flawed assumption that the DSCP will mapped properly across DS domains resulting in non-deterministic behaviour. Second, we should avoid inconsistencies in the expectations of the sender and the receiver. With a reservation in place (irrespective of the service level), both the sender and receiver understand the bounds the behaviour. Further, with a non-optimal reservation, the opportunity exists to only use the less optimal DSCP in those portions of the network where contention prevents the use of the optimal DSCP. In other words, the optimal DSCP in some portions of the network can improve overall service characteristics. [Yoram Bernet] Are you saying that DSCPs cannot reliably invoke services? What is the "Serv" part in DiffServ then? With the correct admission control and the correct provisioning and traffic conditioning, DSCPs can invoke specific services. The network understands how it is provisioned and just what services DSCPs can offer through it. That's why the network must inform the user, which DSCP should be used for a particular service. I agree with you that interdomain issues are important and that a DSCP in one domain may mean something different than a DSCP in another domain, but - that is why it is all the more important to tie domains together through some higher layer abstraction - such as signaling for a certain type of service, across all intervening domains. Are you rejecting RFC2996-2998? Or do you agree witht he direction in those? ------_=_NextPart_001_01C08F90.E42F0F1B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt
 
-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, = 2001 7:44=20 AM
To: 'Mark Gibson'
Cc: rap
Subject: = RE:=20 draft-santitoro-rap-policy-errorcodes-01.txt

Mark,
 
I would actually expect RSVP to consume = more time=20 than SIP. There are two factors to consider. First RSVP is a hop by = hop=20 protocol. While in practice most hops would have RSVP disabled, I = would still=20 expect 2 hops best case (at the LAN/WAN transition points) and 2 = hops per=20 DS domain (once at ingress and once at egress) worst case. = Further, in=20 the new model for RSVP, the protocol is used more as a policy proxy = than to=20 configure switches. As such, when a RSVP message is received, it is = likely to=20 be redirected to a PDP via COPS before propogating the message. The=20 redirection and processing are also likely to add significantly to = the=20 delay.
[Yoram=20 Bernet] Just a minute -  policies are cached. In the = steady=20 state, RSVP messages are not redirected to PDPs *before propagating = the=20 message*!
 
My main reason for suggesting this = alternative is=20 because there is no implicit binding between a DSCP and a service = level. Let=20 me be a little clearer. There is no well defined DSCP for voice, let = alone a=20 less optimal DSCP. Further, DSCPs are configured and have unique QoS = semantics=20 on a per domain basis. It is highly likely that IPT traffic will pass = through=20 at least three domains. As such any of them can not only demote a = service, but=20 potentially promote a service as well. Irrespective of the course = taken, there=20 are two things to be avoided. One is the exclusive reliance on = DSCP=20 mappings. If the Path is rejected on the ingress, but a specific = alternate=20 DSCP is offered, there is an inherent and flawed assumption that the = DSCP will=20 mapped properly across DS domains resulting in non-deterministic = behaviour.=20 Second, we should avoid inconsistencies in the expectations of the = sender and=20 the receiver. With a reservation in place (irrespective of the = service level),=20 both the sender and receiver understand the bounds the = behaviour.=20 Further, with a non-optimal reservation, the opportunity exists to = only use=20 the less optimal DSCP in those portions of the network where = contention=20 prevents the use of the optimal DSCP. In other words, the optimal = DSCP in some=20 portions of the network can improve overall service = characteristics.
[Yoram=20 Bernet]  Are you saying that DSCPs cannot reliably invoke = services?=20 What is the "Serv" part in DiffServ then? With the correct admission = control=20 and the correct provisioning and traffic conditioning, DSCPs can = invoke=20 specific services. The network understands how it is provisioned and = just what=20 services DSCPs can offer through it. That's why the network must = inform the=20 user, which DSCP should be used for a particular service. I agree = with you=20 that interdomain issues are important and that a DSCP in one domain = may mean=20 something different than a DSCP in another domain, but - that is why = it is all=20 the more important to tie domains together through some higher layer=20 abstraction - such as signaling for a certain type of service, across = all=20 intervening domains. Are you rejecting RFC2996-2998? Or do you agree = witht he=20 direction in those?
 
------_=_NextPart_001_01C08F90.E42F0F1B-- From owner-rap@ops.ietf.org Tue Feb 6 12:24:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23801 for ; Tue, 6 Feb 2001 12:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QBpv-000MSU-00 for rap-data@psg.com; Tue, 06 Feb 2001 09:23:27 -0800 Received: from [166.60.14.81] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14QBpv-000MS1-00 for rap@ops.ietf.org; Tue, 06 Feb 2001 09:23:27 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14QBpP-0000T6-00 for rap@ops.ietf.org; Tue, 06 Feb 2001 12:22:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rap@ops.ietf.org Subject: Protocol Action: COPS Usage for Policy Provisioning to Proposed Standard Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 06 Feb 2001 09:23:27 -0800 Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'COPS Usage for Policy Provisioning' as a Proposed Standard. This document is the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This document describes the use of the COPS protocol [COPS] for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned (QoS, Security, etc.), but rather focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The protocol extensions described in this document do not make assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data. Working Group Summary The RAP WG has consensus on publication of this document as a Proposed Standard. Protocol Quality The specification has been reviewed for the IESG by Bert Wijnen. Notes to RFC-Editor: 1.Please in section 1.1, remove the last 2 paragraphs. So section 1.1 should read: 1.1. Why COPS for Provisioning? COPS-PR has been designed within a framework that is optimized for efficiently provisioning policies across devices, based on the requirements defined in [RAP]. First, COPS-PR allows for efficient transport of attributes, large atomic transactions of data, and efficient and flexible error reporting. Second, as it has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS. COPS uses reliable TCP transport and, thus, uses a state sharing/synchronization mechanism and exchanges differential updates only. If either the server or client are rebooted (or restarted) the other would know about it quickly. Last, it is defined as a real-time event-driven communications mechanism, never requiring polling between the PEP and PDP. 2.Pls replace the security section with this text: 8. Security Considerations The COPS protocol [COPS], from which this document derives, describes the mandatory security mechanisms that MUST be supported by all COPS implementations. These mandatory security mechanisms are used by the COPS protocol to transfer opaque information from PEP to PDP and vice versa in an authenticated and secure manner. COPS for Policy Provisioning simply defines a structure for this opaque information already carried by the COPS protocol. As such, the security mechanisms described for the COPS protocol will also be deployed in a COPS-PR environment, thereby ensuring the integrity of the COPS-PR information being communicated. Furthermore, in order to fully describe a practical set of structured data for use with COPS-PR, a PIB (Policy Information Base) will likely be written in a separate document. The authors of such a PIB document need to be aware of the security concerns associated with the specific data they have defined. These concerns MUST be fully specified in the security considerations section of the PIB document along with the required security mechanisms for transporting this newly defined data. From owner-rap@ops.ietf.org Tue Feb 6 16:36:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02698 for ; Tue, 6 Feb 2001 16:36:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QFkm-0000f7-00 for rap-data@psg.com; Tue, 06 Feb 2001 13:34:24 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.16 #1) id 14QFkl-0000f0-00 for rap@ops.ietf.org; Tue, 06 Feb 2001 13:34:23 -0800 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f16LXkg13831 for ; Tue, 6 Feb 2001 15:34:01 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Feb 2001 15:33:45 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LCGXF>; Tue, 6 Feb 2001 15:28:36 -0600 Message-ID: From: Man.M.Li@nokia.com To: rap@ops.ietf.org Subject: COPS - Query PEP for policy detail? Date: Tue, 6 Feb 2001 15:23:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, In SNMP, we may use "get" to query the values of attributes on PEP. It seems to me that we cannot do the same thing with COPS and COPS-PR. For example, can a PDP ask a PEP to send back its current policy in PIB format (PRID + data)? Comments are appreciated. Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-rap@ops.ietf.org Wed Feb 7 11:51:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03450 for ; Wed, 7 Feb 2001 11:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QXnh-000Ifk-00 for rap-data@psg.com; Wed, 07 Feb 2001 08:50:37 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemlsrv.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14QXng-000IfW-00 for rap@ops.ietf.org; Wed, 07 Feb 2001 08:50:36 -0800 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24002 for ; Wed, 7 Feb 2001 11:50:34 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA23990 for ; Wed, 7 Feb 2001 11:50:34 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 17:50:33 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B1D381C@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" Reply-To: confmgt@ops.ietf.org To: rap@ops.ietf.org Subject: Last Call: Publish draft-ops-ip-config-management-reqmnts-00.txt as Informational RFC Date: Wed, 7 Feb 2001 17:36:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Hi... http://www.ietf.org/internet-drafts/draft-ops-ip-config-management-reqmnts-0 0.txt I dropped the ball on this document. But I would like to get it publsihed as an Informational RFC, so that we capture the work we did and so that we can use it to evaluate other work when appropriate. Anyone who has an issue with this document, pls speak up before Feb 21 2001. You can send comments directly to me or (preferably) to the confmgmt mailing list: confmgt@ops.ietf.org This "Last Call" will be posted on: Policy FW WG RAP WG CONFMGT mailing list (discussion on THIS list pls) SNMPCONF WG OPS-AREA mailing list Bert Wijnen From owner-rap@ops.ietf.org Wed Feb 7 12:21:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04253 for ; Wed, 7 Feb 2001 12:21:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QYHJ-000JB1-00 for rap-data@psg.com; Wed, 07 Feb 2001 09:21:13 -0800 Received: from thalia.fm.intel.com ([132.233.247.11]) by psg.com with esmtp (Exim 3.16 #1) id 14QYHH-000JAv-00 for rap@ops.ietf.org; Wed, 07 Feb 2001 09:21:12 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA21700 for ; Wed, 7 Feb 2001 17:22:27 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 07 Feb 2001 17:21:02 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id <13B4TBN5>; Wed, 7 Feb 2001 09:21:00 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39D3C@FMSMSX34> From: "Durham, David" To: rap@ops.ietf.org Subject: RE: COPS - Query PEP for policy detail? Date: Wed, 7 Feb 2001 09:20:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > In SNMP, we may use "get" to query the values of attributes > on PEP. It seems > to me that we cannot do the same thing with COPS and COPS-PR. > For example, > can a PDP ask a PEP to send back its current policy in PIB > format (PRID + > data)? > [Dave] Well, COPS was optimized to do device provisioning/configuration and event-driven accounting, where SNMP is better at polling and getting data from a device. PIBs are algorithmically convertible to MIBs so that you can use SNMP to actually "get" the policies installed on a device (SNMP should already be on the device anyway). If one wanted to do it all with COPS, that's possible too. All you would need is a PIB PRC called "resynch" (or whatever you like) that the PDP can update (via DEC message). When the PDP wants to get a policy or all policies on a device, it can simply trigger the PEP's resynch variable, which would cause the PEP to send select policies via a Report message. No such standard resynch PIB exists today, however. -Dave From owner-rap@ops.ietf.org Wed Feb 7 19:30:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12914 for ; Wed, 7 Feb 2001 19:30:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QewY-0000Qr-00 for rap-data@psg.com; Wed, 07 Feb 2001 16:28:14 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14QewX-0000Qa-00 for rap@ops.ietf.org; Wed, 07 Feb 2001 16:28:13 -0800 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8E00E2PXA5JC@firewall.mcit.com> for rap@ops.ietf.org; Thu, 8 Feb 2001 00:27:41 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G8E00101XA2AO@dgismtp02.wcomnet.com>; Thu, 08 Feb 2001 00:27:41 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G8E00HHPX9VW0@dgismtp02.wcomnet.com>; Thu, 08 Feb 2001 00:27:31 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1NY38D80>; Thu, 08 Feb 2001 00:27:31 +0000 Content-return: allowed Date: Thu, 08 Feb 2001 00:27:29 +0000 From: "Rawlins, Diana" Subject: RE: COPS - Query PEP for policy detail? To: "'Durham, David'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A335@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk The PEP policy is controlled and installed/removed by the PDP. I don't see a lot of value for the PDP "getting" the policy it installed back. However, the ability for the PDP to evaluate the policy and get feedback on policy usage could be useful. This is addressed in the Framework of COPS-PR Policy Information Base for Accounting Usage draft. http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-00.txt -Diana -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Wednesday, February 07, 2001 11:21 AM To: rap@ops.ietf.org Subject: RE: COPS - Query PEP for policy detail? > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > In SNMP, we may use "get" to query the values of attributes > on PEP. It seems > to me that we cannot do the same thing with COPS and COPS-PR. > For example, > can a PDP ask a PEP to send back its current policy in PIB > format (PRID + > data)? > [Dave] Well, COPS was optimized to do device provisioning/configuration and event-driven accounting, where SNMP is better at polling and getting data from a device. PIBs are algorithmically convertible to MIBs so that you can use SNMP to actually "get" the policies installed on a device (SNMP should already be on the device anyway). If one wanted to do it all with COPS, that's possible too. All you would need is a PIB PRC called "resynch" (or whatever you like) that the PDP can update (via DEC message). When the PDP wants to get a policy or all policies on a device, it can simply trigger the PEP's resynch variable, which would cause the PEP to send select policies via a Report message. No such standard resynch PIB exists today, however. -Dave From owner-rap@ops.ietf.org Wed Feb 7 20:07:46 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13386 for ; Wed, 7 Feb 2001 20:07:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QfYC-00014h-00 for rap-data@psg.com; Wed, 07 Feb 2001 17:07:08 -0800 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com) by psg.com with esmtp (Exim 3.16 #1) id 14QfYB-00013t-00 for rap@ops.ietf.org; Wed, 07 Feb 2001 17:07:07 -0800 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 7 Feb 2001 19:43:28 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M3MBS6G; Wed, 7 Feb 2001 19:43:26 -0500 Received: from rdighe (amert128.ca.nortel.com [47.131.80.164]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id D8BDJX5J; Wed, 7 Feb 2001 19:43:25 -0500 Message-ID: <04a201c09168$21002da0$65d6802f@rdighe> Reply-To: "Rajiv Dighe" X-Sybari-Space: 00000000 00000000 00000000 From: "Rajiv Dighe" To: "Rawlins, Diana" , "'Durham, David'" , rap References: <492EB4A3F68CD411ABE800508B69362E31A335@RIPEXCH002.wcomnet.com> Subject: Re: COPS - Query PEP for policy detail? Date: Wed, 7 Feb 2001 19:43:14 -0500 Organization: Nortel Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Rawlins, Diana" To: "'Durham, David'" ; Sent: Wednesday, February 07, 2001 7:27 PM Subject: RE: COPS - Query PEP for policy detail? > > The PEP policy is controlled and installed/removed by the PDP. I don't see a > lot of value for the PDP "getting" the policy it installed back. > One benefit of this ability could be to add more value to synchronization. Current Synchronization mechanism leaves a lot to be desired. essentially it will just repeat past request that PEP had sent. this does not tell PDP much. however ability to get list of installed policies could actually tell PDP that even though it had sent policies p1 thru p11 to the PEP, PEP is only reporting presence of p1 thru p9. It could also aid backup PDP in determining what policies were downloaded by primary PDP before it went down. Regards, --Rajiv From owner-rap@ops.ietf.org Wed Feb 7 20:39:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13797 for ; Wed, 7 Feb 2001 20:39:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qg3M-0001do-00 for rap-data@psg.com; Wed, 07 Feb 2001 17:39:20 -0800 Received: from thalia.fm.intel.com ([132.233.247.11]) by psg.com with esmtp (Exim 3.16 #1) id 14Qg3L-0001dY-00 for rap@ops.ietf.org; Wed, 07 Feb 2001 17:39:19 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id BAA16800; Thu, 8 Feb 2001 01:40:26 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 08 Feb 2001 01:39:02 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 17:39:01 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39D42@FMSMSX34> From: "Durham, David" To: "'Rajiv Dighe'" , "Rawlins, Diana" , "Durham, David" , rap Subject: RE: COPS - Query PEP for policy detail? Date: Wed, 7 Feb 2001 17:38:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > > The PEP policy is controlled and installed/removed by the > > PDP. I don't see a > > lot of value for the PDP "getting" the policy it installed back. > > > > One benefit of this ability could be to add more value to > synchronization. > Current Synchronization mechanism leaves a lot to be desired. > essentially it > will just repeat past request that PEP had sent. this does > not tell PDP > much. however ability to get list of installed policies could > actually tell > PDP that even though it had sent policies p1 thru p11 to the > PEP, PEP is > only reporting presence of p1 thru p9. It could also aid backup PDP in > determining what policies were downloaded by primary PDP > before it went > down. > [Dave] Actually, the Framework PIB provides a Policy ID variable (in the incarnation table) from the last policy exchange. This is repeated back from the PEP to the PDP after a connection failure during the subsequent reconnect & COPS resynchronization procedure. From this incarnation value communicated via the subsequent Request message, the PDP will be able to figure out what state the PEP is in. Reducing this state keeping to a single value is more efficient than repeating back the whole list of currently installed policies, and achieves the desired result as well. From owner-rap@ops.ietf.org Thu Feb 8 09:49:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08546 for ; Thu, 8 Feb 2001 09:48:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QsMz-000DIN-00 for rap-data@psg.com; Thu, 08 Feb 2001 06:48:25 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14QsMz-000DI2-00 for rap@ops.ietf.org; Thu, 08 Feb 2001 06:48:25 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8G00DCH10NWV@firewall.mcit.com> for rap@ops.ietf.org; Thu, 8 Feb 2001 14:45:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8G0060110DZ2@pmismtp01.wcomnet.com>; Thu, 08 Feb 2001 14:45:59 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8G002EB106QC@pmismtp01.wcomnet.com>; Thu, 08 Feb 2001 14:45:42 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXXRRW4>; Thu, 08 Feb 2001 14:45:41 +0000 Content-return: allowed Date: Thu, 08 Feb 2001 14:45:40 +0000 From: "Iliff, Tina" Subject: RE: COPS - Query PEP for policy detail? To: "'Durham, David'" , "'Rajiv Dighe'" , "Rawlins, Diana" , rap Message-id: <492EB4A3F68CD411ABE800508B69362E14B5B6@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk I agree with David. The capability is there and the "how to use it" is just an implementation issue. The PibIncarnationId value can also be useful in a couple of other areas as well. Tina Iliff -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Wednesday, February 07, 2001 7:39 PM To: 'Rajiv Dighe'; Rawlins, Diana; Durham, David; rap Subject: RE: COPS - Query PEP for policy detail? > > The PEP policy is controlled and installed/removed by the > > PDP. I don't see a > > lot of value for the PDP "getting" the policy it installed back. > > > > One benefit of this ability could be to add more value to > synchronization. > Current Synchronization mechanism leaves a lot to be desired. > essentially it > will just repeat past request that PEP had sent. this does > not tell PDP > much. however ability to get list of installed policies could > actually tell > PDP that even though it had sent policies p1 thru p11 to the > PEP, PEP is > only reporting presence of p1 thru p9. It could also aid backup PDP in > determining what policies were downloaded by primary PDP > before it went > down. > [Dave] Actually, the Framework PIB provides a Policy ID variable (in the incarnation table) from the last policy exchange. This is repeated back from the PEP to the PDP after a connection failure during the subsequent reconnect & COPS resynchronization procedure. From this incarnation value communicated via the subsequent Request message, the PDP will be able to figure out what state the PEP is in. Reducing this state keeping to a single value is more efficient than repeating back the whole list of currently installed policies, and achieves the desired result as well. From owner-rap@ops.ietf.org Fri Feb 9 17:00:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03098 for ; Fri, 9 Feb 2001 17:00:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RLZe-0007ZL-00 for rap-data@psg.com; Fri, 09 Feb 2001 13:59:26 -0800 Received: from birch.ee.vt.edu ([128.173.88.34]) by psg.com with esmtp (Exim 3.16 #1) id 14RLZd-0007ZE-00 for rap@ops.ietf.org; Fri, 09 Feb 2001 13:59:25 -0800 Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id QAA08517 for ; Fri, 9 Feb 2001 16:59:21 -0500 (EST) Received: from localhost (kphanse@localhost) by yew.ee.vt.edu (8.9.1b+Sun/8.9.1) with SMTP id QAA22623 for ; Fri, 9 Feb 2001 16:59:20 -0500 (EST) Date: Fri, 9 Feb 2001 16:59:20 -0500 (EST) From: Kaustubh Phanse To: rap@ops.ietf.org Subject: LPDP<->PEP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi! all, Has any standard been proposed or suggested for the interface or communication between a Local Policy Decision Point (LPDP) and a Policy Enforcement Point (PEP)? Any pointers in this matter are greatly appreciated. Thank you sincerely, Kaustubh ----------------------------------------------------------------------------- Kaustubh S. Phanse Graduate Research Assistant Alexandria Research Institute Bradley Department of ECpE __ _________ Virginia Polytechnic Institute & State University \ \ / ___ __/ Alexandria,VA 22314 \ \/ / / / \ / / / Email:kphanse@ee.vt.edu \/ /_/ ----------------------------------------------------------------------------- \o/ \o __| \ / |__ o _ | /\ __\o \o | o/ o/__ /\ _/_\____|_\_____/)_|______(_\____/o\___/_)____|__(\__/_| From owner-rap@ops.ietf.org Fri Feb 9 21:45:23 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07456 for ; Fri, 9 Feb 2001 21:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RQ0S-000Br9-00 for rap-data@psg.com; Fri, 09 Feb 2001 18:43:24 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14RQ0O-000BqM-00 for rap@ops.ietf.org; Fri, 09 Feb 2001 18:43:22 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G8ISPQ01.702; Sat, 10 Feb 2001 10:39:26 +0800 Message-ID: <000d01c0930c$2f33fa00$6922690a@huawei.com.cn> From: "sunjian" To: "Kaustubh Phanse" Cc: References: Subject: Re: LPDP<->PEP Date: Sat, 10 Feb 2001 10:50:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think one way to realize the LPDP is to make a PIB which is a subset copy of the PDP's PIB, the Policy in this subset PIB is that the PEP request from the PDP. Then the device policy request procedure is always standard, just send the request to the Cops Client module and let the Cops Client decide which one(LPDP or PDP) to ask! Is my propose adoptable? Any pointers in this matter are greatly appreciated.^-^ Thanks Sunjian > > Hi! all, > > Has any standard been proposed or suggested for the interface or > communication between a Local Policy Decision Point (LPDP) and a Policy > Enforcement Point (PEP)? Any pointers in this matter are greatly > appreciated. > > Thank you > sincerely, > Kaustubh > > ----------------------------------------------------------------------------- > Kaustubh S. Phanse > Graduate Research Assistant > Alexandria Research Institute > Bradley Department of ECpE __ _________ > Virginia Polytechnic Institute & State University \ \ / ___ __/ > Alexandria,VA 22314 \ \/ / / / > \ / / / > Email:kphanse@ee.vt.edu \/ /_/ > ----------------------------------------------------------------------------- > \o/ \o __| \ / |__ o _ > | /\ __\o \o | o/ o/__ /\ > _/_\____|_\_____/)_|______(_\____/o\___/_)____|__(\__/_| > > > > > From owner-rap@ops.ietf.org Sat Feb 10 17:25:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29117 for ; Sat, 10 Feb 2001 17:25:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RiQo-0008BJ-00 for rap-data@psg.com; Sat, 10 Feb 2001 14:23:50 -0800 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.16 #1) id 14RiQn-0008Ah-00 for rap@ops.ietf.org; Sat, 10 Feb 2001 14:23:49 -0800 Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8K007MHBIT2L@firewall.mcit.com> for rap@ops.ietf.org; Sat, 10 Feb 2001 22:23:17 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8K00J01BIQRT@pmismtp03.wcomnet.com>; Sat, 10 Feb 2001 22:23:17 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8K00D6WBINCU@pmismtp03.wcomnet.com>; Sat, 10 Feb 2001 22:23:11 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFNXAM>; Sat, 10 Feb 2001 22:23:11 +0000 Content-return: allowed Date: Sat, 10 Feb 2001 22:23:09 +0000 From: "Rawlins, Diana" Subject: RE: LPDP<->PEP To: "'Kaustubh Phanse'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A35D@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Kaustubh, A draft has been written that describes a PIB that could be used to provision a COPS-RSVP LPDP. http://search.ietf.org/internet-drafts/draft-rawlins-rsvppcc-pib-00.txt -Diana -----Original Message----- From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] Sent: Friday, February 09, 2001 3:59 PM To: rap@ops.ietf.org Subject: LPDP<->PEP Hi! all, Has any standard been proposed or suggested for the interface or communication between a Local Policy Decision Point (LPDP) and a Policy Enforcement Point (PEP)? Any pointers in this matter are greatly appreciated. Thank you sincerely, Kaustubh ---------------------------------------------------------------------------- - Kaustubh S. Phanse Graduate Research Assistant Alexandria Research Institute Bradley Department of ECpE __ _________ Virginia Polytechnic Institute & State University \ \ / ___ __/ Alexandria,VA 22314 \ \/ / / / \ / / / Email:kphanse@ee.vt.edu \/ /_/ ---------------------------------------------------------------------------- - \o/ \o __| \ / |__ o _ | /\ __\o \o | o/ o/__ /\ _/_\____|_\_____/)_|______(_\____/o\___/_)____|__(\__/_| From owner-rap@ops.ietf.org Mon Feb 12 09:56:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08927 for ; Mon, 12 Feb 2001 09:56:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SKNM-0001y4-00 for rap-data@psg.com; Mon, 12 Feb 2001 06:54:48 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14SKNM-0001xm-00 for rap@ops.ietf.org; Mon, 12 Feb 2001 06:54:48 -0800 Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G8N00LESFZ1L9@firewall.mcit.com> for rap@ops.ietf.org; Mon, 12 Feb 2001 14:52:13 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8N00D01FYEHD@pmismtp03.wcomnet.com>; Mon, 12 Feb 2001 14:52:12 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8N00C4OFYAXK@pmismtp03.wcomnet.com>; Mon, 12 Feb 2001 14:51:47 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSF31LJ>; Mon, 12 Feb 2001 14:51:46 +0000 Content-return: allowed Date: Mon, 12 Feb 2001 14:51:35 +0000 From: "Iliff, Tina" Subject: RE: LPDP<->PEP To: "'sunjian'" , Kaustubh Phanse Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B5DC@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Sunjian, In my opinion, the PEP would have its own database which would include the entire DiffServ PIB or any other PIB (depending on the purpose). Now, how the PEP retrieves policy from the data store is implementation dependent. Tina Iliff -----Original Message----- From: sunjian [mailto:jians@huawei.com] Sent: Friday, February 09, 2001 8:50 PM To: Kaustubh Phanse Cc: rap@ops.ietf.org Subject: Re: LPDP<->PEP I think one way to realize the LPDP is to make a PIB which is a subset copy of the PDP's PIB, the Policy in this subset PIB is that the PEP request from the PDP. Then the device policy request procedure is always standard, just send the request to the Cops Client module and let the Cops Client decide which one(LPDP or PDP) to ask! Is my propose adoptable? Any pointers in this matter are greatly appreciated.^-^ Thanks Sunjian > > Hi! all, > > Has any standard been proposed or suggested for the interface or > communication between a Local Policy Decision Point (LPDP) and a Policy > Enforcement Point (PEP)? Any pointers in this matter are greatly > appreciated. > > Thank you > sincerely, > Kaustubh > > ---------------------------------------------------------------------------- - > Kaustubh S. Phanse > Graduate Research Assistant > Alexandria Research Institute > Bradley Department of ECpE __ _________ > Virginia Polytechnic Institute & State University \ \ / ___ __/ > Alexandria,VA 22314 \ \/ / / / > \ / / / > Email:kphanse@ee.vt.edu \/ /_/ > ---------------------------------------------------------------------------- - > \o/ \o __| \ / |__ o _ > | /\ __\o \o | o/ o/__ /\ > _/_\____|_\_____/)_|______(_\____/o\___/_)____|__(\__/_| > > > > > From owner-rap@ops.ietf.org Thu Feb 15 04:36:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11918 for ; Thu, 15 Feb 2001 04:36:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TKnV-000PX5-00 for rap-data@psg.com; Thu, 15 Feb 2001 01:33:57 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14TKmx-000PVf-00 for rap@ops.ietf.org; Thu, 15 Feb 2001 01:33:31 -0800 Received: from x16187 ([10.105.32.171]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G8SKY100.420 for ; Thu, 15 Feb 2001 17:27:37 +0800 Message-ID: <000501c09732$448ca1c0$ab20690a@x16187.huawei.com.cn> From: "xubo" To: Subject: Accounting RPT Date: Thu, 15 Feb 2001 17:32:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit 1¡¢As the function of Accounting RPT is to notify the PDP of changes in the PEP(Per PEP supports many Client-types,and there are many sessions),Why there is Client Handle Object in the RPT message£¿ 2¡¢When the PEP can send the Accounting RPT? After it had received a CAT £¨client-type != 0£©message? or After it had sent first solicited RPT? Thanks for you help! From owner-rap@ops.ietf.org Thu Feb 15 09:10:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17662 for ; Thu, 15 Feb 2001 09:10:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TP3v-0003rl-00 for rap-data@psg.com; Thu, 15 Feb 2001 06:07:11 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14TP3u-0003mk-00 for rap@ops.ietf.org; Thu, 15 Feb 2001 06:07:11 -0800 Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8S00IJGXTXJN@firewall.mcit.com> for rap@ops.ietf.org; Thu, 15 Feb 2001 14:05:57 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8S00B01XTVYD@pmismtp03.wcomnet.com>; Thu, 15 Feb 2001 14:05:56 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8S008E4XTHI7@pmismtp03.wcomnet.com>; Thu, 15 Feb 2001 14:05:42 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFRSP6>; Thu, 15 Feb 2001 14:05:42 +0000 Content-return: allowed Date: Thu, 15 Feb 2001 14:05:40 +0000 From: "Iliff, Tina" Subject: RE: Accounting RPT To: "'xubo'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B609@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=gb2312 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA17662 The timer for the Accounting Report Type is given in the CAT message (optionally). Therefore, the PEP may send these reports during the specified time intervals. The information provided is related to policy usage. I hope this helps. Tina Iliff -----Original Message----- From: xubo [mailto:swanbo@huawei.com] Sent: Thursday, February 15, 2001 3:33 AM To: rap@ops.ietf.org Subject: Accounting RPT 1¡¢As the function of Accounting RPT is to notify the PDP of changes in the PEP(Per PEP supports many Client-types,and there are many sessions),Why there is Client Handle Object in the RPT message£¿ 2¡¢When the PEP can send the Accounting RPT? After it had received a CAT £¨client-type != 0£©message? or After it had sent first solicited RPT? Thanks for you help! From owner-rap@ops.ietf.org Thu Feb 15 11:19:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22092 for ; Thu, 15 Feb 2001 11:19:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TR80-000Eip-00 for rap-data@psg.com; Thu, 15 Feb 2001 08:19:32 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14TR7z-000Ei7-00 for rap@ops.ietf.org; Thu, 15 Feb 2001 08:19:32 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8T00DI13XDSM@firewall.mcit.com> for rap@ops.ietf.org; Thu, 15 Feb 2001 16:17:38 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8T00K013X3WD@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 16:17:37 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8T00HKK3WR45@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 16:17:15 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXXXZDZ>; Thu, 15 Feb 2001 16:17:14 +0000 Content-return: allowed Date: Thu, 15 Feb 2001 16:17:12 +0000 From: "Rawlins, Diana" Subject: RE: Accounting RPT To: "'xubo'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A3BC@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=GB2312 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22092 Please see comments below. -Diana -----Original Message----- From: xubo [mailto:swanbo@huawei.com] Sent: Thursday, February 15, 2001 3:33 AM To: rap@ops.ietf.org Subject: Accounting RPT 1¡¢As the function of Accounting RPT is to notify the PDP of changes in the PEP(Per PEP supports many Client-types,and there are many sessions),Why there is Client Handle Object in the RPT message£¿ >>> djr The client-SI objects in the Accounting RPT are specific to a Client Type - just like the client-SI objects differ in the REQ and DEC, RPT for the outsourcing and provisioning client types. 2¡¢When the PEP can send the Accounting RPT? After it had received a CAT £¨client-type != 0£©message? or After it had sent first solicited RPT? >> djr For COPS-PR accounting type report, the request state which is identified by the Handle must be established to send the RPT. This would have involved a solicited RPT message being sent by the PEP to the PDP. PEP PDP ---REQ-----> <--DEC---- ---RPT OK--> solicited . . --RPT Acct--> Thanks for you help! From owner-rap@ops.ietf.org Thu Feb 15 12:08:02 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23525 for ; Thu, 15 Feb 2001 12:08:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TRsb-000FWc-00 for rap-data@psg.com; Thu, 15 Feb 2001 09:07:41 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14TRsW-000FW0-00 for rap@ops.ietf.org; Thu, 15 Feb 2001 09:07:36 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G8T00GBE65385@firewall.mcit.com> for rap@ops.ietf.org; Thu, 15 Feb 2001 17:05:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8T0000164OKJ@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 17:05:27 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G8T00LHH64K9I@pmismtp01.wcomnet.com>; Thu, 15 Feb 2001 17:05:08 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXXX6Y2>; Thu, 15 Feb 2001 17:05:07 +0000 Content-return: allowed Date: Thu, 15 Feb 2001 17:05:06 +0000 From: "Iliff, Tina" Subject: RE: Accounting RPT To: "'xubo'" , "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B60D@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=GB2312 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23525 Sorry, I did not answer both of your questions completely. The RPT of type Accounting is sent per Client Handle within the time interval specified by the optional ACCT Timer object in the CAT. Also, the RPT Accounting may only be sent after a Solicited RPT Success has been sent by the PEP (if you recall in my previous message I had stated that the RPT Accounting carries information regarding usage of installed policy). Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Thursday, February 15, 2001 8:06 AM To: 'xubo'; rap@ops.ietf.org Subject: RE: Accounting RPT The timer for the Accounting Report Type is given in the CAT message (optionally). Therefore, the PEP may send these reports during the specified time intervals. The information provided is related to policy usage. I hope this helps. Tina Iliff -----Original Message----- From: xubo [mailto:swanbo@huawei.com] Sent: Thursday, February 15, 2001 3:33 AM To: rap@ops.ietf.org Subject: Accounting RPT 1¡¢As the function of Accounting RPT is to notify the PDP of changes in the PEP(Per PEP supports many Client-types,and there are many sessions),Why there is Client Handle Object in the RPT message£¿ 2¡¢When the PEP can send the Accounting RPT? After it had received a CAT £¨client-type != 0£©message? or After it had sent first solicited RPT? Thanks for you help! From owner-rap@ops.ietf.org Fri Feb 16 11:42:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03527 for ; Fri, 16 Feb 2001 11:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TntR-0007MO-00 for rap-data@psg.com; Fri, 16 Feb 2001 08:38:01 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14TntQ-0007MI-00 for rap@ops.ietf.org; Fri, 16 Feb 2001 08:38:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14TWAV-000Kok-00 for rap@ops.ietv.org; Thu, 15 Feb 2001 13:42:27 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed From: Dinara Suleymanova To: Steve Moulton Cc: "Dale Francisco" , agenda@ietf.org, "Glenn Waters" , bwijnen@lucent.com, randy@psg.com, eos@ops.ietf.org Subject: Re: eos WG meeting slot request In-Reply-To: <200102152102.QAA25114@seymour39.SNMP.COM> References: X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 16 Feb 2001 08:38:01 -0800 Let me reply you later. I should check everything. Thanks for correcting my typo. Regards, Dinara At 04:02 PM 2/15/01 -0500, Steve Moulton wrote: >I'm taking the risk of expressing my opinion where it was not >requested here. As an aside, I realize that scheduling >is a tremendously difficult task, so my subsequent comments are >with all due respect to Dinara Suleymanova. > >On Thursday, February 15 2001, Dinara Suleymanova wrote: > > > --=====================_9442618==_.ALT > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > There is no possibility for you not to overlap with the OPS WG where Bert > > Wijnen is the AD because we have OPS slot with him as AD in each session. > >First, given this schedule, I am glad I am not Bert. > >I see a couple of possibilities: > >. There is no OPS area activity on Monday at 9 AM. Bert may > have a commitment here that I am not aware of. > >. It might be possible to move either rap or sming to make a two hour > session out of the Tuesday afternoon split sessions. I don't > think there will be a lot of interest from the dnsop folks > (no offense, Randy). > >. Worst case (but still better than assigned) - two one hour > sessions Tuesday afternoon. > >Of course, there are other constraints (room size, etc) that I am not >aware of. > >I would very much like to attend rap. > > > THURSDAY, March 22, 2001 > > 1530-1730 Afternoon Sessions II > > APP deltav Web Versioning and Configuration Management WG > > OPS oes Evolution of SNMP WG > > OPS rap Resource Allocation Protocol WG > >It would be good to change "oes" to "eos" in the agenda. > > > - Steve >--- >Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 >Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 >moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com > > > From owner-rap@ops.ietf.org Fri Feb 16 19:34:41 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12296 for ; Fri, 16 Feb 2001 19:34:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TvIm-0005Xx-00 for rap-data@psg.com; Fri, 16 Feb 2001 16:32:40 -0800 Received: from femail1.rdc1.on.home.com ([24.2.9.88]) by psg.com with esmtp (Exim 3.16 #1) id 14TvIl-0005Xp-00 for rap@ops.ietf.org; Fri, 16 Feb 2001 16:32:39 -0800 Received: from crete ([24.112.129.233]) by femail1.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010217003125.SZFE20132.femail1.rdc1.on.home.com@crete> for ; Fri, 16 Feb 2001 16:31:25 -0800 Message-ID: <05f701c09878$93c14bf0$e9817018@crete> From: "Andreas Polyrakis" To: References: <492EB4A3F68CD411ABE800508B69362E017F1B@RIPEXCH002.wcomnet.com> Subject: sppi EXTENDS and AUGMENTS clause Date: Fri, 16 Feb 2001 19:28:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am trying to define a small PIB, but I have some problems with the EXTENDS and AUGMENTS clauses... Unfortunatelly my experience with SPPI and SMI are very limited... Could someone please explain how these two clauses can be used? Suppose that I have a table A with columns (attributes) "a1" and "a2". What I want to do is to have two more tables, B and C, wirh attributres "b1,b2" and "c1,c2" respectively, so that every row in A will be assosiated with either a row in B or in C. In this case, do B,C EXTEND A or AUGMENT it? Also, since B,C have no index (hence no PRID, right?), how can I install/update a row in B or C? Finally, can more than one rows in B be assosiated the same row in A? I hope my questions were clear... Thanks in advance, Andreas From owner-rap@ops.ietf.org Mon Feb 19 12:24:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09756 for ; Mon, 19 Feb 2001 12:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Uu0q-0000D4-00 for rap-data@psg.com; Mon, 19 Feb 2001 09:22:12 -0800 Received: from menelao.polito.it ([130.192.3.30]) by psg.com with smtp (Exim 3.16 #1) id 14Uu0o-0000Cx-00 for rap@ops.ietf.org; Mon, 19 Feb 2001 09:22:11 -0800 Received: (qmail 4956 invoked from network); 19 Feb 2001 17:22:06 -0000 Received: from bagigio.polito.it (HELO polito.it) (130.192.31.16) by menelao.polito.it with SMTP; 19 Feb 2001 17:22:06 -0000 Message-ID: <3A9154AA.53DF3947@polito.it> Date: Mon, 19 Feb 2001 18:15:22 +0100 From: Riccardo Scandariato Reply-To: riccardo@athena.polito.it Organization: Politecnico di Torino (http://www.polito.it) X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,it MIME-Version: 1.0 To: IETF RAP WG CC: Patricia Lago , Fulvio Risso Subject: Question about COPS-PR model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If I well understood COPS and COPS-PR, the first bases on a "bottom-up" model where events arrive from the network (e.g. a RSVP req.), while the second bases on a "top-down" model where events arrive from a control system (e.g. a user interacting with a Web interface, or net-admin operations). The question is: how can I arrange a scenario where events arrive from both the control system and the network (e.g. a user dialing in an access router)? FOR EXAMPLE, let us think to an hypothetical "Security Client-Type". Let us suppose a router that must forward incoming traffic to many outgoing tunnels. The router is placed at the border of a network cloud and traffic arrives from statically attached sites. In my opinion, this is a typical COPS-PR scenario: - first I assign different labels (i.e. Roles) to incoming interfaces (i.e. the attachment points) - second, the router install a request-state (after having opened a COPS session) - third PDP asynchronously pushes the right PRIs (creation of outgoing tunnels, forwarding rules relative to existent roles). But what about a user that dials in the router? In this case user traffic must be directed to the correct tunnel on per-user basis. I guess the PEP should ask the PDP for a decision (which in turn can interrogate e.g. a radius server). How can I manage this issue in COPS-PR? Can the PEP install a new request state? I would like WG opinion on this point. Regards, -- Riccardo Scandariato _______________________________________________________________ Riccardo Scandariato riccardo.scandariato@polito.it ----------------------------------------------------------- Politecnico di Torino Dip. Automatica e Informatica Corso Duca degli Abruzzi, 24 I-10129 Torino, Italy _______________________________________________________________ From owner-rap@ops.ietf.org Tue Feb 20 16:52:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26539 for ; Tue, 20 Feb 2001 16:52:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VKh8-0003cu-00 for rap-data@psg.com; Tue, 20 Feb 2001 13:51:38 -0800 Received: from rumor.cps.intel.com ([192.102.198.242]) by psg.com with esmtp (Exim 3.16 #1) id 14VKh7-0003cW-00 for rap@ops.ietf.org; Tue, 20 Feb 2001 13:51:38 -0800 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id VAA14087; Tue, 20 Feb 2001 21:50:49 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 20 Feb 2001 21:50:52 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id <17GBSDP0>; Tue, 20 Feb 2001 13:50:51 -0800 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B6F9D@ORSMSX54> From: "Sahita, Ravi" To: "'Andreas Polyrakis'" , rap@ops.ietf.org Subject: RE: sppi EXTENDS and AUGMENTS clause Date: Tue, 20 Feb 2001 13:50:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Andreas, You would need to use EXTENDS in this case, since your requirement is that, an instance of class A could be of a part of an instance of class B OR C, ie B, C EXTENDS A. You use AUGMENTS when you want to add attributes, to a previously defined class(A), such that for every instance in A(the AUGMENTED class) you would have a corresponding instance in B and vice versae(1-1 mapping). In the EXTENDS relationship, an extended class(B) instance would have a corresponding instance in the Base class(A), but the reverse doesnt hold true, since A may be EXTENDED to form another derived class. Regarding your other question, when using EXTENDS, the index is controlled by the base class. So, you can install/update an extended PRC instance, by sending instances of the extended PRC's with the index of the base instance as shown, < .X > < Encoding of base attributes > < .X > < Encoding of derived attributes > (X is an InstanceId ) Regarding your last question, The EXTENDS semantics do not allow more than one row in the extension class to be associated with a row in the base class. But This sort of grouping semantics IS allowed by the TagId and TagInstance Textual Conventions, see section 8.11 in the SPPI. Ravi -----Original Message----- From: Andreas Polyrakis [mailto:apolyr@cs.toronto.edu] Hello, I am trying to define a small PIB, but I have some problems with the EXTENDS and AUGMENTS clauses... Unfortunatelly my experience with SPPI and SMI are very limited... Could someone please explain how these two clauses can be used? Suppose that I have a table A with columns (attributes) "a1" and "a2". What I want to do is to have two more tables, B and C, wirh attributres "b1,b2" and "c1,c2" respectively, so that every row in A will be assosiated with either a row in B or in C. In this case, do B,C EXTEND A or AUGMENT it? Also, since B,C have no index (hence no PRID, right?), how can I install/update a row in B or C? Finally, can more than one rows in B be assosiated the same row in A? I hope my questions were clear... Thanks in advance, Andreas From owner-rap@ops.ietf.org Tue Feb 20 18:23:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29118 for ; Tue, 20 Feb 2001 18:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VM6T-0005Jz-00 for rap-data@psg.com; Tue, 20 Feb 2001 15:21:53 -0800 Received: from femail3.rdc1.on.home.com ([24.2.9.90]) by psg.com with esmtp (Exim 3.16 #1) id 14VM6S-0005Jt-00 for rap@ops.ietf.org; Tue, 20 Feb 2001 15:21:52 -0800 Received: from crete ([24.112.129.233]) by femail1.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010220221756.OXDQ24578.femail1.rdc1.on.home.com@crete>; Tue, 20 Feb 2001 14:17:56 -0800 Message-ID: <004901c09b8a$97b7c850$e9817018@crete> From: "Andreas Polyrakis" To: "Sahita, Ravi" , Cc: "Andreas Polyrakis" References: <75F7304BB41CD411B06600A0C98414FC015B6F9D@ORSMSX54> Subject: Re: sppi EXTENDS and AUGMENTS clause Date: Tue, 20 Feb 2001 17:15:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ravi, thank you so much, everything seems much clearer now! I will have a look at TagId and TagInstance, as you propose. Thanks again! Andreas > Andreas, > You would need to use EXTENDS in this case, since your > requirement is that, an instance of class A could be of > a part of an instance of class B OR C, > ie B, C EXTENDS A. > > You use AUGMENTS when you want to add attributes, > to a previously defined class(A), such that for every > instance in A(the AUGMENTED class) you would have a > corresponding instance in B and vice versae(1-1 mapping). > In the EXTENDS relationship, an extended class(B) instance > would have a corresponding instance in the Base class(A), > but the reverse doesnt hold true, since A may be EXTENDED > to form another derived class. > > Regarding your other question, > when using EXTENDS, the index is controlled by the base > class. So, you can install/update an extended PRC instance, > by sending instances of the extended PRC's with the > index of the base instance as shown, > < .X > < Encoding of base attributes > > < .X > < Encoding of derived attributes > > (X is an InstanceId ) > > Regarding your last question, The EXTENDS semantics do not > allow more than one row in the extension class to be associated > with a row in the base class. But This sort of grouping > semantics IS allowed by the TagId and TagInstance Textual > Conventions, see section 8.11 in the SPPI. > > Ravi > From owner-rap@ops.ietf.org Wed Feb 21 03:44:38 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20881 for ; Wed, 21 Feb 2001 03:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VUsd-000FEh-00 for rap-data@psg.com; Wed, 21 Feb 2001 00:44:11 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.16 #1) id 14VUsd-000FEC-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 00:44:11 -0800 Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id A8004BF91; Wed, 21 Feb 2001 03:43:40 -0500 (EST) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E7485AA84 for ; Wed, 21 Feb 2001 03:43:39 -0500 (EST) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id <1VSVVRJD>; Wed, 21 Feb 2001 09:43:38 +0100 Message-ID: From: "Bouarich, Reda" To: "'rap@ops.ietf.org'" Subject: Ask for some informations Date: Wed, 21 Feb 2001 09:43:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hello All, I am a newcomer to COPS, so I would have some questions. First, when it is said that the protocol assumed a named data sturcture which is a PIB, could this PIB be a LDAP repositery for instance? Do the PEP understand COPS or do it need something like a proxy PEP for instance? Can the one PDP open a multiple COPS connection with several PEPs? I would surely have more questions while my working goes ahead, thanks a lot for your help!! I hope I 'll have maybe more interesting questions :) Regards, Reda Bouarich Compaq Telecom Engineering Sohia Antipolis From owner-rap@ops.ietf.org Wed Feb 21 09:12:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27105 for ; Wed, 21 Feb 2001 09:12:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VZzw-000JgJ-00 for rap-data@psg.com; Wed, 21 Feb 2001 06:12:04 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14VZzv-000Jfw-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 06:12:03 -0800 Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G9400B4F2304F@firewall.mcit.com> for rap@ops.ietf.org; Wed, 21 Feb 2001 14:11:24 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G9400G0122WGL@pmismtp03.wcomnet.com>; Wed, 21 Feb 2001 14:11:24 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G9400DJ222JI9@pmismtp03.wcomnet.com>; Wed, 21 Feb 2001 14:11:07 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id <1RSFVS5W>; Wed, 21 Feb 2001 14:11:07 +0000 Content-return: allowed Date: Wed, 21 Feb 2001 14:11:05 +0000 From: "Iliff, Tina" Subject: RE: Ask for some informations To: "'Bouarich, Reda'" , "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B639@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Reda, The answers to your questions are embedded below: Tina Iliff -----Original Message----- From: Bouarich, Reda [mailto:Reda.Bouarich@Compaq.com] Sent: Wednesday, February 21, 2001 2:44 AM To: 'rap@ops.ietf.org' Subject: Ask for some informations Hello All, I am a newcomer to COPS, so I would have some questions. First, when it is said that the protocol assumed a named data sturcture which is a PIB, could this PIB be a LDAP repositery for instance? Tina>> Yes, it is up to the implementer how he/she implements the PIB Do the PEP understand COPS or do it need something like a proxy PEP for instance? Tina>> Yes, the PEP understands the COPS protocol Can the one PDP open a multiple COPS connection with several PEPs? Tina>> Yes, the PDP can have multiple COPS connections with several PEPs...one for each PEP per client-type I would surely have more questions while my working goes ahead, thanks a lot for your help!! I hope I 'll have maybe more interesting questions :) Regards, Reda Bouarich Compaq Telecom Engineering Sohia Antipolis From owner-rap@ops.ietf.org Wed Feb 21 09:26:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27499 for ; Wed, 21 Feb 2001 09:26:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VaDE-000Jru-00 for rap-data@psg.com; Wed, 21 Feb 2001 06:25:48 -0800 Received: from mail5.registeredsite.com ([64.224.9.14]) by psg.com with esmtp (Exim 3.16 #1) id 14VaDD-000Jrn-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 06:25:47 -0800 Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217]) by mail5.registeredsite.com (8.11.1/8.11.1) with ESMTP id f1LEPiG18064 for ; Wed, 21 Feb 2001 09:25:44 -0500 Date: Wed, 21 Feb 2001 09:25:41 -0500 Message-Id: <200102210925.AA2678194486@mail.cominsights.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "sridhar" Reply-To: X-Sender: To: X-Mailer: Sender: owner-rap@ops.ietf.org Precedence: bulk In the COPS-RSVP model which object in the request message or which message object will hold policy data.what type of policy variables does these object hold. looking forward for a help with warm regards bamsi From owner-rap@ops.ietf.org Wed Feb 21 09:44:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28086 for ; Wed, 21 Feb 2001 09:44:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VaV4-000K8y-00 for rap-data@psg.com; Wed, 21 Feb 2001 06:44:14 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14VaV3-000K8P-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 06:44:13 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G94000293GQL9@firewall.mcit.com> for rap@ops.ietf.org; Wed, 21 Feb 2001 14:41:14 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G9400K013GL3E@pmismtp01.wcomnet.com>; Wed, 21 Feb 2001 14:41:14 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G9400J3B3GBAE@pmismtp01.wcomnet.com>; Wed, 21 Feb 2001 14:41:00 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id <1NXX6TAP>; Wed, 21 Feb 2001 14:40:59 +0000 Content-return: allowed Date: Wed, 21 Feb 2001 14:40:56 +0000 From: "Iliff, Tina" Subject: RE: To: "'bamsidhar@cominsights.com'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B63B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Are you referring to an RSVP object or a COPS object? Tina Iliff -----Original Message----- From: sridhar [mailto:bamsidhar@cominsights.com] Sent: Wednesday, February 21, 2001 8:26 AM To: rap@ops.ietf.org Subject: In the COPS-RSVP model which object in the request message or which message object will hold policy data.what type of policy variables does these object hold. looking forward for a help with warm regards bamsi From owner-rap@ops.ietf.org Wed Feb 21 14:13:43 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06413 for ; Wed, 21 Feb 2001 14:13:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VehP-000O6R-00 for rap-data@psg.com; Wed, 21 Feb 2001 11:13:15 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14VehN-000O4Y-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 11:13:14 -0800 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G94000MXFWZ8G@firewall.mcit.com> for rap@ops.ietf.org; Wed, 21 Feb 2001 19:10:11 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G9400101FWOLI@dgismtp01.wcomnet.com>; Wed, 21 Feb 2001 19:10:11 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G9400LD5FWIFV@dgismtp01.wcomnet.com>; Wed, 21 Feb 2001 19:09:54 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Feb 2001 19:09:54 +0000 Content-return: allowed Date: Wed, 21 Feb 2001 19:09:53 +0000 From: "Rawlins, Diana" Subject: RE: To: "'bamsidhar@cominsights.com'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A40D@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk bambi, The COPS Request clientSI contains the RSVP information used to base the policy decision. The COPS Decision message indicates whether the policy was granted. Additional RSVP objects can be included in the Decision Message Replacement Data object. One of these can be the Policy Object. The Policy object is an RSVP object that contains policy information. http://www.ietf.org/rfc/rfc2749.txt http://www.ietf.org/rfc/rfc2748.txt http://www.ietf.org/rfc/rfc2750.txt http://www.ietf.org/html.charters/rap-charter.html -Diana -----Original Message----- From: sridhar [mailto:bamsidhar@cominsights.com] Sent: Wednesday, February 21, 2001 8:26 AM To: rap@ops.ietf.org Subject: In the COPS-RSVP model which object in the request message or which message object will hold policy data.what type of policy variables does these object hold. looking forward for a help with warm regards bamsi From owner-rap@ops.ietf.org Wed Feb 21 14:14:09 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06425 for ; Wed, 21 Feb 2001 14:14:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VeiA-000O6r-00 for rap-data@psg.com; Wed, 21 Feb 2001 11:14:02 -0800 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=mmdf) by psg.com with smtp (Exim 3.16 #1) id 14Vei9-000O6d-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 11:14:01 -0800 Received: from godzilla.ics.uci.edu ( schakrav@godzilla.ics.uci.edu [128.195.1.58] ) by gremlin-relay.ics.uci.edu id aa09983 ; 21 Feb 2001 11:13 PST Date: Wed, 21 Feb 2001 11:13:29 -0800 (PST) From: Sanjeev Chakravarty To: "Iliff, Tina" cc: "'Bouarich, Reda'" , "'rap@ops.ietf.org'" Subject: RE: Ask for some informations In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B639@RIPEXCH002.wcomnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Reda, I've some additional comments on your questions. > First, when it is said that the protocol assumed a named data sturcture > which is a PIB, could this PIB be a LDAP repositery for instance? > > Tina>> Yes, it is up to the implementer how he/she implements the PIB Sanjeev>> You typically store your policies in LDAP repository as they are relatively static. PIB contents are dynamic and contains status and configuration information of the devices. It is a MIB that contains policy information. > > Do the PEP understand COPS or do it need something like a proxy PEP for > instance? > Tina>> Yes, the PEP understands the COPS protocol Sanjeev>> You need a proxy PEP if the devices are not COPS enabled. THe Proxy would use SNMP or CLI for example to enforce a policy on such devices. In one scenario, we were required to control thousands of Virtual routers(sitting on one physical device) and since it would be expensive to maintain thousands of TCP connections(one per Virtual router) we had a proxy to handle that for us. > > Can the one PDP open a multiple COPS connection with several PEPs? > > Tina>> Yes, the PDP can have multiple COPS connections with several > PEPs...one for each PEP per client-type > > I would surely have more questions while my working goes ahead, thanks a lot > for your help!! > I hope I 'll have maybe more interesting questions :) > Regards, > > Reda Bouarich > Compaq Telecom Engineering > Sohia Antipolis > > > From owner-rap@ops.ietf.org Thu Feb 22 02:10:47 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05518 for ; Thu, 22 Feb 2001 02:10:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Vpsn-000ATV-00 for rap-data@psg.com; Wed, 21 Feb 2001 23:09:45 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14Vpsl-000ASf-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 23:09:44 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G95D1N01.T1F for ; Thu, 22 Feb 2001 15:05:47 +0800 Message-ID: <002901c09c9f$837fd560$6922690a@huawei.com.cn> From: "sunjian" To: Date: Thu, 22 Feb 2001 15:17:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the COPS protocol RFC2748 ====================================================== 3.6 Client-Open (OPN) PEP -> PDP The Client-Open message can be used by the PEP to specify to the PDP the client-types the PEP can support, the last PDP to which the PEP connected for the given client-type, and/or client specific feature negotiation. A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes). ::= [] [] [] ===================================================== It is said that: "A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes)." The question is : 1. What's the mean of "in case of global state changes" Does there some examples of "case"? Does the "state" refer to the established request handle? If it is, then why not do each request handle respectivly just as the protocol said in 3.1 Request (REQ) PEP -> PDP " Once a stateful handle is established for a new request, any subsequent modifications of the request can be made using the REQ message specifying the previously installed handle. " 2.If it emphasize the word " global " then what's the following process will be? 1> PEP PDP OPN( ClientTypeA)-> <-CAT(ClientTypeA ) OPN( ClientTypeA)-> ---------------------------At this point, what should the PDP COPS do? 2> PEP PDP OPN( ClientTypeA)-> <-CAT(ClientTypeA ) REQ( ClientTypeA handle 1)-> <-DEC( ClientTypeA handle 1) RPT( ClientTypeA handle 1)-> REQ( ClientTypeA handle 2)-> <-DEC( ClientTypeA handle 1) RPT( ClientTypeA handle 2)-> OPN( ClientTypeA)-> ---------------------------At this point, what should the PDP COPS do? From owner-rap@ops.ietf.org Thu Feb 22 02:12:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05555 for ; Thu, 22 Feb 2001 02:12:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Vpuq-000AVe-00 for rap-data@psg.com; Wed, 21 Feb 2001 23:11:52 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14Vpuo-000AVE-00 for rap@ops.ietf.org; Wed, 21 Feb 2001 23:11:50 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G95D5700.41D for ; Thu, 22 Feb 2001 15:07:55 +0800 Message-ID: <003501c09c9f$cf741bc0$6922690a@huawei.com.cn> From: "sunjian" To: Subject: question about Client-type OPN Msg Date: Thu, 22 Feb 2001 15:19:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the COPS protocol RFC2748 ====================================================== 3.6 Client-Open (OPN) PEP -> PDP The Client-Open message can be used by the PEP to specify to the PDP the client-types the PEP can support, the last PDP to which the PEP connected for the given client-type, and/or client specific feature negotiation. A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes). ::= [] [] [] ===================================================== It is said that: "A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes)." The question is : 1. What's the mean of "in case of global state changes" Does there some examples of "case"? Does the "state" refer to the established request handle? If it is, then why not do each request handle respectivly just as the protocol said in 3.1 Request (REQ) PEP -> PDP " Once a stateful handle is established for a new request, any subsequent modifications of the request can be made using the REQ message specifying the previously installed handle. " 2.If it emphasize the word " global " then what's the following process will be? 1> PEP PDP OPN( ClientTypeA)-> <-CAT(ClientTypeA ) OPN( ClientTypeA)-> ---------------------------At this point, what should the PDP COPS do? 2> PEP PDP OPN( ClientTypeA)-> <-CAT(ClientTypeA ) REQ( ClientTypeA handle 1)-> <-DEC( ClientTypeA handle 1) RPT( ClientTypeA handle 1)-> REQ( ClientTypeA handle 2)-> <-DEC( ClientTypeA handle 1) RPT( ClientTypeA handle 2)-> OPN( ClientTypeA)-> ---------------------------At this point, what should the PDP COPS do? Thanks Sunjian From owner-rap@ops.ietf.org Thu Feb 22 20:26:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02441 for ; Thu, 22 Feb 2001 20:26:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14W701-000Bjc-00 for rap-data@psg.com; Thu, 22 Feb 2001 17:26:21 -0800 Received: from rumor.cps.intel.com ([192.102.198.242]) by psg.com with esmtp (Exim 3.16 #1) id 14W700-000BjU-00 for rap@ops.ietf.org; Thu, 22 Feb 2001 17:26:20 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id BAA14732; Fri, 23 Feb 2001 01:25:22 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 23 Feb 2001 01:25:25 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 17:25:23 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39D87@FMSMSX34> From: =?utf-8?B?RHVyaGFtLCBEYXZpZA==?= To: =?utf-8?B?J3N1bmppYW4n?= , rap@ops.ietf.org Subject: =?utf-8?B?UkU6IHF1ZXN0aW9uIGFib3V0IENsaWVudC10eXBlIE9QTiBNc2cg?= Date: Thu, 22 Feb 2001 17:25:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="utf-8" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: sunjian [mailto:jians@huawei.com] > > In the COPS protocol RFC2748 > ====================================================== > 3.6 Client-Open (OPN) PEP -> PDP > > The Client-Open message can be used by the PEP to specify > to the PDP > the client-types the PEP can support, the last PDP to which the PEP > connected for the given client-type, and/or client specific feature > negotiation. A Client-Open message can be sent to the PDP > at any time > and multiple Client-Open messages for the same client-type are > allowed (in case of global state changes). > ::= > > [] > [] > [] > ===================================================== > > It is said that: > "A Client-Open message can be sent to the PDP at any time > and multiple Client-Open messages for the same client-type are > allowed (in case of global state changes)." > > The question is : > 1. What's the mean of "in case of global state changes" > Does there some examples of "case"? [Dave] There is a ClientSI object in the COPS OPN Message, this object was intended to carry global state information, if any. As it turns out, no such global state has ever been defined for any standard Client Types to date. The statement above simply says *if* you had sent such global state information in a OPN message, you can update it by simply repeating the OPN message again with the new data. > Does the "state" refer to the established request handle? [Dave] No see above. > > 2.If it emphasize the word " global " then what's the > following process will be? > > 1> > PEP PDP > OPN( ClientTypeA)-> > <-CAT(ClientTypeA ) > OPN( ClientTypeA)-> ---------------------------At this point, > what should the > PDP COPS do? [Dave] <- CAT(ClientTypeA) (assuming the PDP still accepts the ClientType and any global data that might be part of the updated OPN message) > > 2> > PEP PDP > OPN( ClientTypeA)-> > <-CAT(ClientTypeA ) > REQ( ClientTypeA handle 1)-> > <-DEC( ClientTypeA handle 1) > RPT( ClientTypeA handle 1)-> > > REQ( ClientTypeA handle 2)-> > <-DEC( ClientTypeA handle 1) > RPT( ClientTypeA handle 2)-> > > OPN( ClientTypeA)-> ---------------------------At this point, > what should the > PDP COPS do? [Dave] <- CAT(ClientTypeA) ... And everything else would continue as normal. Really, there is no point in sending a repeated OPN message just for the hellofit, but it is not an error either. > > > Thanks > > Sunjian > > > From owner-rap@ops.ietf.org Thu Feb 22 20:43:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02703 for ; Thu, 22 Feb 2001 20:43:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14W7Fz-000C1H-00 for rap-data@psg.com; Thu, 22 Feb 2001 17:42:51 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14W7Fw-000C0T-00 for rap@ops.ietf.org; Thu, 22 Feb 2001 17:42:49 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G96SKE01.E0D for ; Fri, 23 Feb 2001 09:38:38 +0800 Message-ID: <010f01c09d3b$017bdd60$6922690a@huawei.com.cn> From: "sunjian" To: Subject: question about Security OPN Msg Date: Fri, 23 Feb 2001 09:50:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the COPS protocol RFC2748 ==================================================== 4.1 Security and Sequence Number Negotiation ............ Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the .......... ==================================================== It is said that : " If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " The first question : I think the "another Client-Type " here does not equal to 0. Then there are two cases corresponding with this statment. A. PEP PDP OPN 1(Client-Type = 0)-> <- CAT 1(Client-Type = 0) OPN 2(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 3(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 4(Client-Type = 0)->----------------------------I think when the PDP got this, then PDP can do just as the description in the RFC 2748 4.1 ================================ If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped. ================================ <- step1:CC 4(Client-Type = 0) step2: close all the Client-Type A,B(do not send CC(Client-Type AB)) step3:after some time,close the TCP connection. Dose the step right? B. PEP PDP OPN 1(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 2(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 3(Client-Type = 0)-> <- step1:CC 3(Client-Type = 0) step following should be what? I think in this case I should not close the Client-Type A,B, it's the responsibility of PEP to close the Client-Type A,B(send PDP the Client-Type A,B CC), then send OPN 3(Client-Type = 0). The Second question : Do not know if there's any other cases with the statement at the beginning of the letter, I really fall into some logic confusion with this statement! I think it can be controled all by PEP itself to decide when to send out the OPN (Client-Type = 0). If it want another security negotiate, why not close all the established Client-Type first or it will always get a CC (Client-Type = 0). Then the statement ======================================================== "If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " ======================================================== seems unecessary and cases in the first question will not exist. Can someone help me out? Thank you very much! Sunjian From owner-rap@ops.ietf.org Fri Feb 23 06:47:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27787 for ; Fri, 23 Feb 2001 06:47:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14WGfE-000Lgj-00 for rap-data@psg.com; Fri, 23 Feb 2001 03:45:32 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14WGfD-000LgP-00 for rap@ops.ietf.org; Fri, 23 Feb 2001 03:45:31 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27598; Fri, 23 Feb 2001 06:45:29 -0500 (EST) Message-Id: <200102231145.GAA27598@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-sppi-05.txt Date: Fri, 23 Feb 2001 06:45:29 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-05.txt Pages : 42 Date : 22-Feb-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-sppi-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-sppi-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222133226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-sppi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-sppi-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222133226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Feb 23 13:35:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14095 for ; Fri, 23 Feb 2001 13:35:57 -0500 (EST) From: owner-rap@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.16 #1) id 14WN2c-0001C6-00 for rap-data@psg.com; Fri, 23 Feb 2001 10:34:06 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14WN2b-0001C0-00 for rap@ops.ietf.org; Fri, 23 Feb 2001 10:34:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14WN2b-000Aiu-00 for rap@ops.ietf.org; Fri, 23 Feb 2001 10:34:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: To: rap-approval@psg.com Subject: BOUNCE rap@ops.ietf.org: Non-member submission from [The IESG ] Date: Fri, 23 Feb 2001 10:24:43 -0800 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >From scoya@cnri.reston.va.us Fri Feb 23 10:24:42 2001 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14WMtW-000155-00 for rap@ops.ietf.org; Fri, 23 Feb 2001 10:24:42 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13274; Fri, 23 Feb 2001 13:24:39 -0500 (EST) Message-Id: <200102231824.NAA13274@ietf.org> To: IETF-Announce: ; Cc: rap@ops.ietf.org From: The IESG SUBJECT: Last Call: Structure of Policy Provisioning Information (SPPI) to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 23 Feb 2001 13:24:38 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Resource Allocation Protocol Working Group to consider Structure of Policy Provisioning Information (SPPI) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 9, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt From owner-rap@ops.ietf.org Fri Feb 23 14:18:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16302 for ; Fri, 23 Feb 2001 14:18:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14WNiJ-0001mi-00 for rap-data@psg.com; Fri, 23 Feb 2001 11:17:11 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemlsrv.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14WNiJ-0001ma-00 for rap@ops.ietf.org; Fri, 23 Feb 2001 11:17:11 -0800 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA26768 for ; Fri, 23 Feb 2001 14:17:09 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA26739 for ; Fri, 23 Feb 2001 14:17:08 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 20:17:07 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B5C9021@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap Subject: Non-member submission from [The IESG ] Date: Fri, 23 Feb 2001 20:17:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk there we go. > ---------- > From: owner-rap@ops.ietf.org[SMTP:owner-rap@ops.ietf.org] > Sent: Friday, February 23, 2001 7:24 PM > To: rap-approval@psg.com > Subject: BOUNCE rap@ops.ietf.org: Non-member submission from [The > IESG ] > > >From scoya@cnri.reston.va.us Fri Feb 23 10:24:42 2001 > Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) > by psg.com with esmtp (Exim 3.16 #1) > id 14WMtW-000155-00 > for rap@ops.ietf.org; Fri, 23 Feb 2001 10:24:42 -0800 > Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13274; > Fri, 23 Feb 2001 13:24:39 -0500 (EST) > Message-Id: <200102231824.NAA13274@ietf.org> > To: IETF-Announce: ; > Cc: rap@ops.ietf.org > From: The IESG > SUBJECT: Last Call: Structure of Policy Provisioning Information (SPPI) > to Proposed Standard > Reply-to: iesg@ietf.org > Date: Fri, 23 Feb 2001 13:24:38 -0500 > Sender: scoya@cnri.reston.va.us > > > The IESG has received a request from the Resource Allocation Protocol > Working Group to consider Structure of Policy Provisioning Information > (SPPI) as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by March 9, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt > > > > > From owner-rap@ops.ietf.org Sat Feb 24 03:02:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17698 for ; Sat, 24 Feb 2001 03:02:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14WZed-000BvL-00 for rap-data@psg.com; Sat, 24 Feb 2001 00:02:11 -0800 Received: from tce-e-7-182-13.bta.net.cn ([202.106.182.13] helo=china.com) by psg.com with smtp (Exim 3.16 #1) id 14WZeb-000BvA-00 for rap@ops.ietf.org; Sat, 24 Feb 2001 00:02:10 -0800 Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jmd3a97853b; Sat, 24 Feb 2001 07:59:13 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm1143a96ada5; Fri, 23 Feb 2001 16:57:40 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA07747 for ietf-123-outbound.02@ietf.org; Fri, 23 Feb 2001 11:45:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA05636 for ; Fri, 23 Feb 2001 06:45:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27598; Fri, 23 Feb 2001 06:45:29 -0500 (EST) Message-Id: <200102231145.GAA27598@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-sppi-05.txt Date: Fri, 23 Feb 2001 06:45:29 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-05.txt Pages : 42 Date : 22-Feb-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-sppi-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-sppi-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222133226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-sppi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-sppi-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222133226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Feb 26 13:51:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21202 for ; Mon, 26 Feb 2001 13:51:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XShr-0009fm-00 for rap-data@psg.com; Mon, 26 Feb 2001 10:49:11 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14XShq-0009fF-00 for rap@ops.ietf.org; Mon, 26 Feb 2001 10:49:10 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9D00AIWO6HN4@firewall.mcit.com> for rap@ops.ietf.org; Mon, 26 Feb 2001 18:47:05 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9D00101O696B@pmismtp02.wcomnet.com> for rap@ops.ietf.org; Mon, 26 Feb 2001 18:47:05 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9D00M4IO5NTM@pmismtp02.wcomnet.com> for rap@ops.ietf.org; Mon, 26 Feb 2001 18:46:35 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Feb 2001 18:46:35 +0000 Content-return: allowed Date: Mon, 26 Feb 2001 18:46:26 +0000 From: "Rawlins, Diana" Subject: RE: I-D ACTION:draft-ietf-rap-sppi-05.txt To: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A45C@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk I have a couple of questions/comments which are focused on Section 7.1 "Mapping of the SUBJECT-CATEGORIES clause." What is the value of the COPS Header Client Type for a client connection of SUBJECT-CATEGORY QOS? Will this be the equal to the CATEGORY ID value of the DiffServ PIB? How are additional technology specific PIBs added to a client type applications? Are they assigned the same CATEGORY ID? How would an Accounting Usage PIB for the DiffServ be added to the DiffServ QoS Client Type application? What is the Category ID for SUBJECT-CATEGORIES QoS? Where is the category to client type mapping defined? Will it be called out in the individual PIB drafts? (Not finding that type of information in the current DiffServ PIB 02.) Quoting more from 7.1, "The namespace for these named numbers is global and therefore the labels should be assigned consistently across PIB modules. At present time, no more than one named-number enumeration should be specified." What organization is managing the global name space for the CATEGORY IDS? Where does one go to set this up or find out the mappings? Thanks, Diana -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, February 23, 2001 5:45 AM Cc: rap@ops.ietf.org Subject: I-D ACTION:draft-ietf-rap-sppi-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-05.txt Pages : 42 Date : 22-Feb-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-sppi-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-sppi-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-rap@ops.ietf.org Tue Feb 27 01:26:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18046 for ; Tue, 27 Feb 2001 01:26:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Xdah-000Ku5-00 for rap-data@psg.com; Mon, 26 Feb 2001 22:26:31 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14XdaU-000Kro-00 for rap@ops.ietf.org; Mon, 26 Feb 2001 22:26:28 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G9EKA600.L10 for ; Tue, 27 Feb 2001 14:20:30 +0800 Message-ID: <000b01c0a087$1c1a7920$6922690a@huawei.com.cn> From: "sunjian" To: Subject: question about Security OPN Msg Date: Tue, 27 Feb 2001 14:32:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the COPS protocol RFC2748 ==================================================== 4.1 Security and Sequence Number Negotiation ............ Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the .......... ==================================================== It is said that : " If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " The first question : I think the "another Client-Type " here does not equal to 0. Then there are two cases corresponding with this statment. A. PEP PDP OPN 1(Client-Type = 0)-> <- CAT 1(Client-Type = 0) OPN 2(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 3(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 4(Client-Type = 0)->----------------------------I think when the PDP got this, then PDP can do just as the description in the RFC 2748 4.1 ================================ If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped. ================================ <- step1:CC 4(Client-Type = 0) step2: close all the Client-Type A,B(do not send CC(Client-Type AB)) step3:after some time,close the TCP connection. Dose the step right? B. PEP PDP OPN 1(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 2(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 3(Client-Type = 0)-> <- step1:CC 3(Client-Type = 0) step following should be what? I think in this case I should not close the Client-Type A,B, it's the responsibility of PEP to close the Client-Type A,B(send PDP the Client-Type A,B CC), then send OPN 3(Client-Type = 0). The Second question : Do not know if there's any other cases with the statement at the beginning of the letter, I really fall into some logic confusion with this statement! I think it can be controled all by PEP itself to decide when to send out the OPN (Client-Type = 0). If it want another security negotiate, why not close all the established Client-Type first or it will always get a CC (Client-Type = 0). Then the statement ======================================================== "If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " ======================================================== seems unecessary and cases in the first question will not exist. Can someone help me out? Thank you very much! Sunjian From owner-rap@ops.ietf.org Tue Feb 27 02:38:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00948 for ; Tue, 27 Feb 2001 02:38:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Xei1-000LkU-00 for rap-data@psg.com; Mon, 26 Feb 2001 23:38:09 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14Xehv-000Lk8-00 for rap@ops.ietf.org; Mon, 26 Feb 2001 23:38:06 -0800 Received: from sunjian ([10.105.34.105]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G9E7D001.00E for ; Tue, 27 Feb 2001 09:41:24 +0800 Message-ID: <001701c0a060$1d53a720$6922690a@huawei.com.cn> From: "sunjian" To: Subject: question about Security OPN Msg Date: Tue, 27 Feb 2001 09:53:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the COPS protocol RFC2748 ==================================================== 4.1 Security and Sequence Number Negotiation ............ Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the .......... ==================================================== It is said that : " If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " The first question : I think the "another Client-Type " here does not equal to 0. Then there are two cases corresponding with this statment. A. PEP PDP OPN 1(Client-Type = 0)-> <- CAT 1(Client-Type = 0) OPN 2(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 3(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 4(Client-Type = 0)->----------------------------I think when the PDP got this, then PDP can do just as the description in the RFC 2748 4.1 ================================ If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped. ================================ <- step1:CC 4(Client-Type = 0) step2: close all the Client-Type A,B(do not send CC(Client-Type AB)) step3:after some time,close the TCP connection. Dose the step right? B. PEP PDP OPN 1(Client-Type A) -> <- CAT 2(Client-Type A) ........... OPN 2(Client-Type B) -> <- CAT 3(Client-Type B) ........... OPN 3(Client-Type = 0)-> <- step1:CC 3(Client-Type = 0) step following should be what? I think in this case I should not close the Client-Type A,B, it's the responsibility of PEP to close the Client-Type A,B(send PDP the Client-Type A,B CC), then send OPN 3(Client-Type = 0). The Second question : Do not know if there's any other cases with the statement at the beginning of the letter, I really fall into some logic confusion with this statement! I think it can be controled all by PEP itself to decide when to send out the OPN (Client-Type = 0). If it want another security negotiate, why not close all the established Client-Type first or it will always get a CC (Client-Type = 0). Then the statement ======================================================== "If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. " ======================================================== seems unecessary and cases in the first question will not exist. Can someone help me out? Thank you very much! Sunjian From owner-rap@ops.ietf.org Tue Feb 27 08:18:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07179 for ; Tue, 27 Feb 2001 08:18:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XjzY-000Pxa-00 for rap-data@psg.com; Tue, 27 Feb 2001 05:16:36 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.16 #1) id 14XjzX-000PxA-00 for rap@ops.ietf.org; Tue, 27 Feb 2001 05:16:35 -0800 Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 7FFB8B401; Tue, 27 Feb 2001 08:16:04 -0500 (EST) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 70F5DB435; Tue, 27 Feb 2001 08:16:03 -0500 (EST) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id <1VSVYJ9P>; Tue, 27 Feb 2001 14:16:02 +0100 Message-ID: From: "Bouarich, Reda" To: "'Sanjeev Chakravarty'" Cc: "'rap@ops.ietf.org'" Subject: RE: Ask for some informations Date: Tue, 27 Feb 2001 14:15:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hello Sanjeev, Thanks for your help. I would have something else to ask for. How can a PDP know for instance that a policy has been added by an operator to the LDAP DIT and apply it to a certain PEP? Is there something like a polling/triggering mechanism? How a Device know to which PDP should it send a config reqest? Do you know where can I find some COPS sample code or LDAP repositery content exemple?Cause it is really not easy to discover Policy Management stuffs and to apply all its principle the day after!!The released IETF/DMTF drafts are certainly so useful but it doesn't (I know it's not the goal!) show concrete example! Thanks a lot. Reda. From owner-rap@ops.ietf.org Tue Feb 27 21:42:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10831 for ; Tue, 27 Feb 2001 21:42:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XwXb-000DZH-00 for rap-data@psg.com; Tue, 27 Feb 2001 18:40:35 -0800 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=mmdf) by psg.com with smtp (Exim 3.16 #1) id 14XwXa-000DZB-00 for rap@ops.ietf.org; Tue, 27 Feb 2001 18:40:34 -0800 Received: from godzilla.ics.uci.edu ( schakrav@godzilla.ics.uci.edu [128.195.1.58] ) by gremlin-relay.ics.uci.edu id aa06548 ; 27 Feb 2001 18:40 PST Date: Tue, 27 Feb 2001 18:40:27 -0800 (PST) From: Sanjeev Chakravarty To: "Bouarich, Reda" cc: "'rap@ops.ietf.org'" Subject: RE: Ask for some informations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Reda, > How can a PDP know for instance that a policy has been added by an operator > to the LDAP DIT and apply it to a certain PEP? Is there something like a > polling/triggering mechanism? Sanjeev> When a PEP initiates a COPS connection, it provides a list of roles it supports to the PDP, eg., Campus Role, Ethernet Role. PDP on receiving a new policy from the PMT(or from the LDAP DIT using LDAP extensions) knows the role that this new policy is added and creates an instance of the Policy Rule Class(PRI) that is identified by Policy Rule Instance Identifier(PRID). Using COPS the PDP installs this PRI on to the PEP. > How a Device know to which PDP should it send a config reqest? Sanjeev> COPS is PEP initiated protocol and hence it is suppose to know to which PDP it wants to connect. It may use SNMP discovery process to get a list of PDP servers that it may possibly talk to. > Do you know where can I find some COPS sample code or LDAP repositery > content exemple?Cause it is really not easy to discover Policy Management > stuffs and to apply all its principle the day after!!The released IETF/DMTF > drafts are certainly so useful but it doesn't (I know it's not the goal!) > show concrete example! Sanjeev> How about you read my MS thesis draft, titled, "QoS in Policy-Based Networks: A Detailed Specification," and provide feedback on the topics you like to discuss further. Would really appreciate any feedback on my work which is close to completion. There a few examples considered in the thesis and the work will continue even after I graduate. Go to my website at "www.ics.uci.edu/~schakrav" and click on the thesis link. I'm currently reading the book "Policy-Based Networking:Architecture and Algorithms" by Dinesh C. Verma, which is so far the most comprehensive material I've found in any book on this topic. Thanks, Sanjeev Chakravarty Corona Networks From owner-rap@ops.ietf.org Wed Feb 28 06:25:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01792 for ; Wed, 28 Feb 2001 06:25:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Y4iy-000N1K-00 for rap-data@psg.com; Wed, 28 Feb 2001 03:24:52 -0800 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by psg.com with esmtp (Exim 3.16 #1) id 14Y4ix-000N01-00 for rap@ops.ietf.org; Wed, 28 Feb 2001 03:24:52 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 28 Feb 2001 16:59:23 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.0.14.17]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f1SGvBc28659 for ; Wed, 28 Feb 2001 22:27:11 +0530 Message-Id: <014701c0a178$2f7ad360$110e000a@future.futsoft.com> Reply-To: "Abdul Malick" From: "Abdul Malick" To: References: <492EB4A3F68CD411ABE800508B69362E31A45C@RIPEXCH002.wcomnet.com> Subject: FYI - COPS - PDP(Server) test application Date: Wed, 28 Feb 2001 16:48:32 +0530 Organization: Future Software Ltd., MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Sometime back in this mailing list people were searching for a COPS server implementation over Linux I was also in the hunt. I could find one server implementation for COPS-RSVP from the following link http://www.cs.technion.ac.il/Courses/Computer-Networks-Lab/projects/summer20 00/cops This implementation is a very simple one and supports very less functionality. Atleast we can test some basic functionality Both server and client implementations are available. The server part can be seperately complied. Known Bug: At some places the byte order is not taken care (eg KA time value in the message is not converted to network byte order before Tx). If anyone comes across any other bug please let me know. Hope it is useful. Cheers Malick From owner-rap@ops.ietf.org Wed Feb 28 18:21:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01160 for ; Wed, 28 Feb 2001 18:21:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YFsP-0009eN-00 for rap-data@psg.com; Wed, 28 Feb 2001 15:19:21 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.16 #1) id 14YFsO-0009do-00 for rap@ops.ietf.org; Wed, 28 Feb 2001 15:19:21 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 28 Feb 2001 18:09:09 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 18:09:10 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E80517BCF8@zwdld001.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'rap@ops.ietf.org'" Subject: 2 Internet-drafts submitted to the RAP WG Date: Wed, 28 Feb 2001 18:09:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A1DB.73BD00D0" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A1DB.73BD00D0 Content-Type: text/plain All, I would like to request your attention to 2 internet-drafts we have just submitted to the RAP WG. The first one is a framework draft on session setup with media authorization. http://www.ietf.org/internet-drafts/draft-hamer-rap-session-auth-00.txt This first draft describes the different models where our new policy element (described in our second draft) may be used. Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. Our second draft describes a new policy element called AUTH_SESSION. http://www.ietf.org/internet-drafts/draft-hkg-rap-rsvp-authsession-00.txt This document describes the representation of session authorization information in the POLICY_DATA object for supporting policy-based per-session authorization and admission control in RSVP. Please review both drafts and provide comments to the authors. Any comments will be greatly appreciated. Thanks and cheers, Louis-Nicolas Hamer ------_=_NextPart_001_01C0A1DB.73BD00D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable 2 Internet-drafts submitted to the RAP WG

All,

I would like to request your attention = to 2 internet-drafts we have just submitted to the
RAP WG.

The first one is a framework draft on = session setup with media authorization.
http://www.ietf.org/internet-drafts/draft-hamer-rap-se= ssion-auth-00.txt
This first draft describes the = different models where our new policy element (described in our second = draft)
may be used. Establishing multimedia = streams must take into account requirements
for end-to-end QoS, authorization of = network resource usage and
accurate accounting for resources = used. During session set up,
policies may be enforced to ensure = that the media streams being
requested lie within the bounds of = the service profile established
for the requesting host. Similarly, = when a host requests resources
to provide a certain QoS for a packet = flow, policies may be enforced
to ensure that the required resources = lie within the bounds of the
resource profile established for the = requesting host.

Our second draft describes a new = policy element called AUTH_SESSION.
http://www.ietf.org/internet-drafts/draft-hkg-rap-rsvp= -authsession-00.txt
This document describes the = representation of session authorization
information in the POLICY_DATA object = for supporting
policy-based per-session = authorization and admission control in
RSVP.


Please review both drafts and provide = comments to the authors. Any comments will be greatly = appreciated.

Thanks and cheers,
Louis-Nicolas Hamer

------_=_NextPart_001_01C0A1DB.73BD00D0--