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

["Georgios Karagiannis" <[e-mail]>]

Hi Tom,


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

The REPORT message can be provided by the RESV message.

Regarding the features that a REQUEST-REPORT should support see below:


>>>   -- 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.

This is supported by RSVP, using the PATH message in combination with the
Previous HOP object carried by a PATH message.


>>>
>>>   -- possibly as part of a recovery attempt if the failure timer
>>> T-rcvFail expires;

This is supported by RSVP using the PATH message in combination with soft
state principle of RSVP.

>>>
>>>   -- possibly as part of a manual debugging procedure.

I am not sure if this feature is necesary to be supported by such a
protocol. I think that this procedure can be supported by network
management protocols.

Best regards,
Goergios


>
>On 25/06/2011 5:45 AM, Georgios Karagiannis wrote:
>> Hi Tom,
>>
>> Please see in line!
>>
>>
>> On 6/24/2011, "Tom Taylor"<[e-mail]>  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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pcn
>>
>>