Subject: uploaded Generic Aggregation RSVP over PCN (v01)

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 11 Jul 2011 14:35:22 +0000

Hi all,

I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-01, see:
http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt

 This document specifies the extensions to the Generic Aggregated RSVP
 [RFC4860] for support of the PCN Controlled Load (CL) and Single
 Marking (SM) edge behaviors over a Diffserv cloud using Pre-
 Congestion Notification.

The main changes of this version compared to the previous version is that
the aggregation is mainly based on the Generic Aggregation RSVP
(RFC4860], instead of being based on the Agggation RSVP (RFC3175}.

Comments are welcome!

This draft is relevant for both WGs, PCN and tsvwg.

I would therefore very much like to also get an tsvwg agenda slot (of 15
minutes)!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Jul 2011 20:35:53 +0000

Hi all,

You might know that the following draft has been submitted to the PCN WG
and the tsvwg:

We solicit comments on this draft from the members of PCN WG and tsvwg,
since this draft might be relevant for both WGs.
Below we are providing some information regarding the motivation of
writing
this draft and the additions to RFC 4860 and the PCN edge behaviour
drafts, specified in this draft:

Motivation (problem statement):
-------------

o) All PCN charter items are fulfilled, except: Submit Encoding and
Transport of PCN from the Domain Egress to the Ingress to the IESG for
consideration as a Proposed Standard RFC:

o) Pairs of PCN-ingress-node and PCN-egress-node use
ingress-egress-aggregates (IEA): collection of PCN-packets from all
PCN-flows that travel in one direction between a specific pair of
PCN-boundary-nodes:

=> Need a signaling protocol to transport PCN information from
PCN-egress-node to PCN-ingress-node that is able to maintain
ingress-egress-aggregate between each pair of PCN-ingress-node and
PCN-egress-node

Possible IETF QoS signaling protocols to solve the above problem:
-----------------------------------

o) Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974,
RFC 5979)

o) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)

o) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
(RFC4860)

All can be used, but for time being we selected RFC 4860 due to:
o) possible deployment interest

o) Supports RFC 3175 and additonal features such as:
   *) support of multiple IEAs from same pair of PCN edge nodes

   *) support of bandwidth reduction for individual flows (RFC 4495)

Some augmentations needed for RFC 4860, see below:
----------------------------------------------------
o) Four new (2 for CL and 2 for SM) objects specified to include PCN
information to be transported from PCN-egress-node to PCN-ingress-node

o) Each Aggregator and Deaggregator support policies to initiate and
maintain for each combination of a PCN-boundary-node and all other
PCN-boundary-nodes of the same PCN domain one RSVP SESSION for generic
aggregated reservations
  *) RSVP SESSION for generic aggregated reservations can match to one or
more than one ingress-egress-aggregates.

o) For each supported IEA, PCN-egress-node, periodically (end of each PCN
measurement interval) generates Aggregated Resv messages and include
new PCN object and send it to associated PCN-ingress-node

o) PCN-interior-nodes are not using E2E RSVP or Generic Aggregated RSVP
messages, but treated as normal packets.

o) E2E RSVP session admission in PCN-domain:
  *) Each Aggregator support policies and PCN functionalities to admit or
reject an incoming e2e RSVP Path message (in RFC4086 this is done by
Deaggregator) and send a PathErr towards the sender.

o) E2E RSVP flow termination in PCN-domain:
  *) Each Aggregator support policies and PCN functionalities to support
the initiation of termination of one or more active E2E RSVP sessions
and/or to reduce the bandwidth of one or more active individual existing
RSVP sessions, in order to solve congestion in PCN-domain
 *) Same mechanisms for terminating or reducing bandwidth of an e2e RSVP
session can be followed as specified in [RFC4495]

Some augmentations might be needed for PCN CL and SM edge behavior
drafts, see below:
----------------------------------------------------

In order to use all the advanced features of the Generic aggregation
RSVP, minor augmentations on the CL and SM edge behavior drafts might be
needed:
Considered that PCN-ingress-node collocated with Decision point

o) More than one IEAs between the same pair of PCN edge nodes should be
supported, each of them using a different PHB-ID value

o) When IEA supported by a PCN-ingress-node is in PCN-admission state,
then based on a local policy, the requesting e2e RSVP session should be
either rejected or should be mapped to another IEA that is NOT in
PCN-admission-state

o) When for an IEA supported by a PCN-ingress-node incoming traffic needs
to be reduced (to reduce congestion in PCN-domain), then based on a
local policy and for same IEA, select a number of e2e RSVP sessions:
either to be terminated and/or to reduce the reserved bandwidth of e2e
RSVP sessions, in order to decrease total incoming amount of incoming
traffic associated with IEA by amount of traffic to be terminated

Best regards,
Georgios