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

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Jun 2011 14:26:35 -0400

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.

2) A reliable request-response protocol between a centralized decision 
point and a PCN-ingress-node.

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

---

From: Michael Menth <[email-masked]>
Date: Fri, 24 Jun 2011 20:52:16 +0200

Hi Tom,

Am 24.06.2011 20:26, schrieb Tom Taylor:
> 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.
>
> 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 agree.

>  -- 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 useful only for the centralized approach, right? If the decision 
point is the PCN-ingress-node, then its address needs to be found out by 
the PCN-egress-node anyway for IEA classification of PCN packets. Correct?

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

> 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?
The protocols you mention are in place only for the centralized 
approach, right? Then I would expect at least a simple standalone 
protocol for the case when the PCN ingress node is the decision point to 
be independent of other technologies. Alternative: we make the use of 
the other protocol mandatory, but I do not know whether this is acceptable.

Michael

>
> Tom
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Jun 2011 15:45:35 -0400

Thanks for the response, Michael.

Answering your two points in reverse order:

(a) Protocol 1 is needed even when the decision point resides with the 
PCN-ingress-node. Protocol 2 is needed only in the centralized case. If 
you make Protocol 2 optional to implement, then by the same logic you 
would make the ability to send reports on multiple IEAs in the same 
message optional to implement in Protocol 1. My own preference would be: 
mandatory to implement, optional to deploy instead.

(b) Are we sure that the address of the PCN-ingress-node will be part of 
the IEA-classifier? Wouldn't that mean that the PCN-ingress-node changes 
the source of all incoming PCN-packets to its own address?

My intention was that the address of the decision point would be picked 
up from the source address of the REQUEST-REPORT message. This would 
provide some protection from NATs in the signalling path, however 
unlikely their presence might be in the interior of an operator's network.

On 24/06/2011 2:52 PM, Michael Menth wrote:
>> point knows the address of the PCN-egress-node, this message could
>> push the address of the decision point to the PCN-egress-node,

---

From: Michael Menth <[email-masked]>
Date: Fri, 24 Jun 2011 21:59:31 +0200

Hi Tom,

Am 24.06.2011 21:45, schrieb Tom Taylor:
> PCN-ingress-node. Protocol 2 is needed only in the centralized case. 
Sorry, you are so right! I forgot about that.

> If you make Protocol 2 optional to implement, then by the same logic 
> you would make the ability to send reports on multiple IEAs in the 
> same message optional to implement in Protocol 1. My own preference 
> would be: mandatory to implement, optional to deploy instead.
I prefer just mandatory to avoid different code bases.

>
> (b) Are we sure that the address of the PCN-ingress-node will be part 
> of the IEA-classifier? Wouldn't that mean that the PCN-ingress-node 
> changes the source of all incoming PCN-packets to its own address?
The address of the PCN-ingress-node is part of the denomination of an 
IEA. It is not part of the flow descriptor for classification of packet 
belonging to a specific IEA. The signalling requirements draft says:

    For the SM/CL edge behaviour, the report MUST contain:
    o the identifier of the PCN-ingress-node and the identifier of the
      PCN-egress-node (typically their IP addresses); together they
      specify the ingress-egress-aggregate to which the report refers,

>
> My intention was that the address of the decision point would be 
> picked up from the source address of the REQUEST-REPORT message. This 
> would provide some protection from NATs in the signalling path, 
> however unlikely their presence might be in the interior of an 
> operator's network.
That may be a good solution for the centralized approach as you 
suggested. I don't believe it's needed when PCN-ingress-node is the 
decision point.

Regards,

     Michael

---

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Jun 2011 22:17:17 -0400

Below.

On 24/06/2011 3:59 PM, Michael Menth wrote:
[PTT1]

>> changes the source of all incoming PCN-packets to its own address?
============
[MM]

>       specify the ingress-egress-aggregate to which the report refers,
==============
[PTT1]

>> however unlikely their presence might be in the interior of an
==============
[MM]

> suggested. I don't believe it's needed when PCN-ingress-node is the

[PTT2] The NAT aspect isn't my primary concern, just a by-product.

Would it not be brittle to build in the assumption that the node 
identifier is an address? What if the node is upgraded to dual stack or 
to pure IPv6 and thus gets a new address? I'd sooner have the address be 
drawn from the message IP header, and make the identifers opaque 
strings, up to the administrator to populate.

Tom

---

From: Michael Menth <[email-masked]>
Date: Sat, 25 Jun 2011 08:37:47 +0200

Hi Tom,

se below

Am 25.06.2011 04:17, schrieb Tom Taylor:
> identifier is an address? What if the node is upgraded to dual stack 
> or to pure IPv6 and thus gets a new address? I'd sooner have the 
> address be drawn from the message IP header, and make the identifers 
> opaque strings, up to the administrator to populate.
How does RSVP solve that? Nodes need to know the address of the previous 
hop.

Regards,

     Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 25 Jun 2011 09:45:38 +0000

Hi Tom,

Please see in line!

>the decision point, whether centralized or collocated with the

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

>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

---

From: Tom Taylor <[email-masked]>
Date: Sat, 25 Jun 2011 07:42:24 -0400

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"<[email-masked]>  wrote:
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 25 Jun 2011 20:52:47 +0000

Hi Tom,

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

The REPORT message can be provided by the RESV message.

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

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jun 2011 08:55:49 -0400

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 28 Jun 2011 05:21:44 +0000

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

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2011 08:36:14 -0400

I'm not sure I follow all this. Are you sure you are not mixing up the 
piggybacking case with the CL and SM modes of operation? I'll wait to 
see your draft, but basically, with CL and SM the end-to-end RSVP (if 
any) would be handled at the ingress node but at no other node in the 
PCN domain.

> draft and preliminary version of this will be ready by Monday.
...

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 28 Jun 2011 13:00:06 +0000

Hi Tom,

The solution that I was talking about is indeed related to the
piggybacking edge behaviour:
draft-taylor-pcn-piggybacking-edge-behaviour-01

However, this piggybacking edge behaviour is very much depending on the
SM and CL behaviours.

My proposal is to somehow integrate each of the CL and SM edge behaviours
with the piggybacking edge behaviour. This can be e.g., done by
including in each SM and CL drafts an additional section that will
describe how each of the CL and SM behaviours can be used when the
decision point is co-located with the PCN-ingess-node. In this case the
enhanced RSVP can be applied as the signaling protocol used to exchange
information between the PCN edge nodes.

In addition to this we could also add a section on each CL and SM drafts
that describe how each of the CL and SM behaviours can be used when the
decision point is not co-located with the PCN-ingess-node.
In this case DIAMETER can be used as the signaling protocol for
exchanging information between the PCN-egress-node and decision point
and between the decision point and the PCN-ingress-node. I think that
you already described this solution some tinme ago.

Best regards,
Georgios

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2011 10:04:54 -0400

The piggybacking edge behaviour shares the marking behaviours with the 
CL and SM modes. Where it differs is that the decision point for 
admission effectively lies with the egress node. That way, the RSVP 
signalling and the admission decision share a common fate -- a very 
natural integration of PCN with RSVP. Less natural is the message 
autonomously generated by the egress node when flow termination is 
required, but as we know, with the specification of a new object to 
represent the IEA, this can be done.

(The fact is that I suspect the piggybacking method is far more 
deployable than the CL and SM methods because far fewer messages have to 
be transmitted through the network.)

I can see the possibility of using RSVP as a transport for PCN reports 
in the CL and SM cases, but it is a really unnatural use of the 
protocol. In the first place, the RESV is initiated at a router (the 
egress node) rather than an end point or a proxy for an end point. I am 
a bit dubious that the message format for this message would conform in 
any but the most artificial sense to the specifications in RFC 2205. And 
the Path message, the normal response to the RESV, is unnecessary in 
normal operation in the CL and SM cases.

I would feel much more comfortable defining a simple and light-weight 
protocol that could be used regardless of whether the decision point is 
centralized or decentralized.

...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2011 10:31:50 -0400

As an afterthought, in the CL and SM edge behaviours, it would be much 
more natural for the RESV to come from the decision point (the receiver) 
and the reports from the egress node (the sender) to be carried by the 
PATH message.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 28 Jun 2011 14:43:46 +0000

Hi Tom,

Please see in line!

On 6/28/2011, "Tom Taylor" <[email-masked]> wrote:

>admission effectively lies with the egress node. 

Georgios: the decision point for admission control could also lie on the
PCN-ingress-node. The PCN-ingress-node could decide whether an e2e RSVP
PATH message (of a flow that belongs to a IEA) is admitted and forwarded
towards the PCN-egress-node or not.

>That way, the RSVP

Georgios: This periodical notification from PCN-egress-node to
PCN-ingress-node may also be realised using the RSVP aggregation
messages (as I mentioned a combination of e2e RSVP (RFC 2205) and RSVP
aggregation (RFC3175) is required. Note that the RSVP aggregated
messages are started/ended at the aggregator (in this case is the
PCN-ingress-node) or the deaggregator (PCN-egress-node).

>normal operation in the CL and SM cases.

Georgios: I amk working on this, but I think that if the PCN-ingress-node
is collocated with the decision point then the SM and CL can use RSVP in
combination with the RSVP aggregation as signaling protocols.
Note that the RSVP aggregated messages are started/ended at the
aggregator (in this case is the PCN-ingress-node) or the deaggregator
(PCN-egress-node).

>centralized or decentralized.

Georgios: In my opinion we will spend more time on specifying and
standardizing such a protocol, than just enhancing an existing IETF
signaling protocol.

Best regards,
Georgios