Subject: Pre-established Aggregate Reservations = RE: [Tsvwg] WGLC for draft-ietf-tsvwg-rsvp-ipsec-00.txt NOW

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Thu, 18 May 2006 15:17:09 +0200

Hello Alexander, 

>> >> 
>> >> RFC 3175, section 1.4.12, describes a way of preestablishing 
>> >> the aggregate
>> >> reservations. It might be useful if there are no E2E 
>> >> signaling messages or
>> >> if we just want to preestablish an aggregate. According to 
>> >> RFC 3175, it is
>> >> the responsibility of the aggregator to send the appropriate 
>> >> PATH message,
>> >> the deaggregator will just respond with the RESV message.
>> >> 
>> >> This procedure should be revised for the generic RSVP 
>> >> aggregations. Since
>> >> the aggregator sends the PATH message with the SESSION 
>> >> object that the
>> >> deaggregator constructs, there no "simple" way to 
>> >> preestablish a session. To
>> >> my opinion, two solutions are available. The first one is 
>> to tell the
>> >> deaggregator to send the PATH_ERROR message with the 
>> >> necessary SESSION
>> >> object. It will trigger the PATH message at the aggregator, 
>> >> which in turn
>> >> will trigger the RESV message at the deaggregator. The 
>> >> second solution is
>> >> similar to the one described in RFC 3175. However, since the 
>> >> aggregator is
>> >> not aware of all the vDstPort values that the deaggregator 
>> >> has assigned or
>> >> may potentially assign in the future, there is no safe way 
>> >> to ensure the
>> >> consistency across all the vDstPort values that may be used. 
>> >> At the same
>> >> time, if the administrator knows what s/he is doing, there 
>> >> is no technical
>> >> obstacle for preestablishing the reservation in such a way. 
>> >> I think the new
>> >> document should elaborate on these possibilities and present 
>> >> the RECOMMENDED
>> >> way.

I vote for the second proposal (ie config based). This is because:
	* it feels off to rely on an E2E PathErr message when we may not
have any E2E flow in place yet.
	* in general, I think Aggregate pre-establishment will likely
involve some config on both Aggregator and Deaggregator anyways (eg the
size of the Aggregate reservation for example is more naturally
controlled on Deagg size).

To reflect this we could add, at the end of section 4, something like:

"
As discussed above, generic aggregate reservations may be established as
a result of the establishment of E2E reservations from outside the
aggregation region which are to be aggregated over the aggregation
region. However, generic aggregate reservations may also be used
end-to-end by end-systems directly attached to a Diffserv domain, such
as PSTN Gateways. In that case, the generic aggregate reservations may
be established by the end-systems in response to application-level
triggers such as voice call signalling. Alternatively, generic aggregate
reservations may also be used edge-to-edge to manage bandwidth in a
diff-serv cloud even if RSVP is not used end-to-end. A simple example of
such a usage would be the static configuration of a generic aggregate
reservation for a certain bandwidth for traffic from an ingress
(Aggregator) router to an egress (Deaggregator) router. 

In this case, the establishment of the generic aggregate reservations
would be controlled by configuration on the Aggregator and on the
Deaggregator. Configuration on the Aggregator would trigger generation
of the aggregate Path message and would provide sufficient information
to the Aggregator to derive the content of the generic aggregate
session. This may include Deaggregator IP address, DSCP and possibly
VDstPort. Configuration on the Deaggregator would instruct the
Deaggregator to respond to a received generic aggregate Path message and
would provide sufficient information to the Deaggregator to control the
reservation. This may include bandwidth to be reserved by the
Deaggregator (for a given Deaggregator/DSCP/VDstPort).

In the absence of E2E microflow reservations, the Aggregator can use a
variety of policies to set the DSCP of packets passing into the
aggregation region and how they are mapped onto generic aggregate
reservations, thus determining whether they gain access to the resources
reserved by the aggregate reservation. These policies are a matter of
local configuration, as usual for a device at the edge of a diffserv
cloud.
"

How does that sound?

Francois

---

From: "Alexander Sayenko" <[email-masked]>
Date: Fri, 19 May 2006 16:15:35 +0300

Hi

> How does that sound?

Sounds great!

> "
>  Extended vDstPort (Extended Virtual Destination Port)
>
>  A 32-bit identifier used in the SESSION that remains constant over
>  the life of the generic aggregate reservation.
>  A sender (or Aggregator) that wishes to narrow the scope of a
>  SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair)
>  SHOULD place its IPv4 address here as a globally unique identifier. A
>  sender (or Aggregator) that wishes to use a common session with other
>  sender (or Aggregators) in order to use a shared reservation across
>  senders (or Aggregators) MUST set this field to all zeros.
> "

I have no comments, now it is clear.

A few comments concerning the aggregate management. If aggregates are
established, then they can be also released. Section 2.10 of RFC 3175 tells
briefly that it is possible, but no clear steps how to do it correctly. I
assume that PATH_TEAR for the aggregated session should be enough. However,
I have faced a small inefficiency from the practical point of view. Since
there is no difference between the E2E and aggregated PATH_TEAR messages,
the core routers MUST look inside every PATH_TEAR message. Is it a problem?
Though the number of the PATH_TEAR messages is considerably less when
compared to the PATH messages, if there is a possibility to remove this
burden then why not to do it. Basically, the same concerns the RESV_TEAR
messages. It is possible to clear the Router Alert field of the E2E messages
as draft-ietf-tsvwg-rsvp-dste proposes for the E2E PATH messages. In any
case, it would be nice that the final solution is described in the generic
aggregate RSVP document.

Another comment concerning releasing aggregated sessions. Suppose, all the
E2E flows are gone and there is no obstacle for releasing the aggregated
session. Ok, I am not proposing to release the aggregated session
immediately, I just want to clearify steps if somebody wants to do it.
Should the aggregator send the PATH_TEAR message thus clearing all the PSBs
and RSBs? It is possible, but maybe the DEAGGREGATOR knows better. If it is
an entity that made a decision about mapping, then maybe the same entity
should make a decision about whether the aggregated session is necessary or
not. Unfortunately, the only message the deaggregator can send is RESV_TEAR
which will clear only RSBs. Maybe we should add the ERROR_SPEC object into
the RESV_TEAR message that will instruct the aggregator to send the
PATH_TEAR message in the same way as the deaggregator sends the PATH_ERROR
thus aksing for a new aggregate? The only obstacle I can see here is the
fact that RFC 2205 (RSVP protocol) does not list the ERROR_SPEC as a valid
object in the RESV_TEAR message. Comments?

Sincerely,
Alexander Sayenko (PhD)
Assistant
Telecommunication laboratory, MIT department
University of Jyvaskyla, Finland