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

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

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