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

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

Hi Tom,

Regarding RESV, please note that a new object has to be specified that
can carry PCN information. I assume that we can do this in tsvwg.
Please also note that RSVP is an on-path signaling protocol. If the
decision point is not located on the data path, then we migh not be able
to use the current RSVP protocol features.

In addiition to the features that you mentioned, a PCN feature is also
needed to set and maintain the IEA (Ingress Egress Aggregate) at the
PCN-ingress-node and the PCN-egress-node.

Therefore, I think that a combination of e2e RSVP and RSVP aggregation is
needed. I am currently working on specifying this. I estimate that a
draft and preliminary version of this will be ready by Monday.

Best regards,
Georgios

On 6/27/2011, "Tom Taylor" <[e-mail]> wrote:

>Not being terribly familiar with RSVP, I started my education with
>RFC2205. It seems to me that if the basic semantics of RSVP are to be
>respected, the initial message at start-up is a RESV coming from the
>egress node. That's not how I pictured it, but it might work.
>
>So what we get is a stream of RESV messages from the egress node. A
>return PATH message is an exceptional occurence -- basically an error
>condition in our application.
>
>Does RSVP give us the freedom to put the information we need to pass in
>the RESV message, and what mandatory fields do we have to fake to
>respect the requirements of the protocol?
>
>My studies continue.
>
>Tom
>
>On 25/06/2011 4:52 PM, Georgios Karagiannis wrote:
>> 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
>>>>
>>>>
>>
>>