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

[Tom Taylor <[e-mail]>]

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