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

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 2 Jun 2006 14:37:25 +0200

Hello Alexander, 

>> -----Original Message-----
>> From: Alexander Sayenko [mailto:[email-masked]] 
>> Sent: vendredi 19 mai 2006 15:16
>> To: Francois Le Faucheur (flefauch)
>> Cc: tsvwg
>> Subject: Re: Pre-established Aggregate Reservations = RE: 
>> [Tsvwg] WGLC for draft-ietf-tsvwg-rsvp-ipsec-00.txt NOW
>> 
>> Hi
>> 
>> 
>> > 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?
>> 
>> Sounds great!
 
Good. Change is included.

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

Good. Change is included.

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

Yes.

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

The E2E PathTear travel through the aggregation region with a protocol
ID of RSVP-E2E-IGNORE - see section 3.1 of RFC3175 (while the Aggregate
PathTear have a protocol ID of RSVP). Interior routers will thus
naturally ignore the E2E PathTear messages.

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

Yes. The model is that the aggregate reservation is controlled by Deagg.

For aggregate resa set-up: 
	* the Deag decides it needs a new Aggregate
	* Deagg sends the E2E PathErr 
	* in response, the Agg sends AggPath.

The simple equivalent approach for aggregare resa tear-down is:
	* Deag decides an aggregate is no longer needed
	* Deag sends Agg ResvTear
	* Agg sends Agg PathTear (because this aggregate is no longer
needed by Deagg)

Since RFC3175 is indeed less than explicit about that, we could add the
following text:
"
Based on relevant policy, the Deaggregator may decide at some point that
an aggregate reservation is no longer needed and should be torn down. In
that case, the Deaggregator MUST send an aggregate ResvTear. On receipt
of the aggregate ResvTear, the Aggregator SHOULD send an aggregate
PathTear (unless the relevant policy instructs the aggregator to do
otherwise ot to wait for some time before doing so, for example in order
to speed-up potential re-establishment of the aggregate reservation in
the future). 
"
Does that work?

Thanks

Francois

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