Re: [PCN] Signalling protocols for CL and SM modes

What are the RSVP messages corresponding to REPORT and REQUEST-REPORT?

On 25/06/2011 5:45 AM, Georgios Karagiannis wrote:
> Hi Tom,
>
> Please see in line!
>
>
> On 6/24/2011, "Tom Taylor"<tom111.taylor@bell.net>  wrote:
>
>> Rereading the signalling requirements document, I note that we actually
>> need two protocols:
>>
>> 1) A non-reliable protocol carrying reports from the PCN-egress-node to
>> the decision point, whether centralized or collocated with the
>> PCN-ingress-node.
>
> Georgios: I do not understand why should we define a new protocol for
> this purpose, since we can already use for this an existing IETF
> signaling protocol. For example RSVP.
>
> Please note that I have started modifying the following draft that
> can be used as an example of how a signaling protocol can be applied to
> support an PCN edge behaviour.
> http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01
>
> I will try to write a very preliminary version of this draft, which I
> will submit before/on the submission deadline (4th of July)!
>
>
>
>>
>> 2) A reliable request-response protocol between a centralized decision
>> point and a PCN-ingress-node.
>
> Georgios: Also for this protocol, please try to use and enhance an
> existing IETF protocol. What about DIAMETER. I think that you already
> worked on this, see below:
>
> draft-huang-dime-pcn-collection
>
> Best regards,
> Georgios
>
>
>>
>>
>> 1) Protocol between the PCN-egress-node and the decision point
>>     -----------------------------------------------------------
>>
>> This protocol would be based on UDP, subject to security analysis.
>> (Alternatives are UDP/IPSec or DTLS).
>>
>> For the first protocol, the question arises: do we need back-off in the
>> face of congestion? I argue not, since the very purpose of the protocol
>> is to carry information that may help to mitigate that congestion. (I
>> say "may" because the report path doesn't necessarily coincide with the
>> data path of the received PCN packets.)
>>
>> I await comments on that topic, but I suggest that the protocol itself
>> would consist of two message types. The first is REPORT, and would be
>> the only one used in normal operation. REPORT passes from the
>> PCN-egress-node to the decision point.
>>
>> The second message is REQUEST-REPORT. It is sent under the following
>> circumstances from the decision point to the PCN-egress-node:
>>
>>   -- possibly as part of a start-up sequence. Assuming that the decision
>> point knows the address of the PCN-egress-node, this message could push
>> the address of the decision point to the PCN-egress-node, avoiding the
>> need to configure it there.
>>
>>   -- possibly as part of a recovery attempt if the failure timer
>> T-rcvFail expires;
>>
>>   -- possibly as part of a manual debugging procedure.
>>
>> The response of the PCN-egress-node to a REQUEST-REPORT message would be
>> to immediately send a REPORT message with contents based on the latest
>> measurement interval.
>>
>> 2) Protocol between the decision point and the PCN-ingress-node
>>     ------------------------------------------------------------
>>
>> This one needs a bit of discussion to decide whether we actually want a
>> stand-alone protocol consisting of REQUEST and RESPONSE messages running
>> over TCP. The decision point already needs a protocol to install policy
>> on the PCN-ingress-node. If this protocol is COPS, the PIB could easily
>> be extended to request the estimated PCN-sent-rate from the
>> PCN-ingress-node. In general we should think about protocol integration.
>>
>> Comments?
>>
>> Tom
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcn
>
>