Subject: [Tsvwg] RE: Generic aggregate reservations

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 16 Jun 2006 09:00:35 +0200

Hello Alexander,

>> According to draft-ietf-tsvwg-rsvp-ipsec-00.txt, now the 
>> AGGREGATION-SESSION
>> object carries all the necessary information. However, 
>> section 4 (page 13)
>> does not specify clearly what the aggregator should do with 
>> this object. To
>> my opinion, it MUST be poped-out of the E2E RESV message so 
>> as not to expose
>> to much information of domain internals. In general, there 
>> is no need for
>> the end systems to know which DSCP the traffic was mapped to 
>> or deaggregator
>> identity. At the same time, as RFC 2996 presents, the end 
>> systems may be
>> informed of the mapping decision. It can be the case when 
>> the end system
>> pre-marks packets before they arrive to the ingress edge 
>> routers. Based on
>> this, I propose the following behaviour.
>> 
>> The aggregator MUST remove the AGGREGATION-SESSION object 
>> from the E2E RESV
>> message before forwarding the message towards the sender. If 
>> the aggregator
>> wants to inform the end system about the mapping decision, 
>> it MAY put the
>> DCLASS object into the E2E RESV message with the DSCP value 
>> taken from the
>> AGGREGATION-SESSION object.

The new version has already been sent to IETF for posting (should appear
on the server any time). But, believe it or not, the good news is that
we also realized last week that this needed to be discussed. So this is
the text you'll find:
"
The Aggregator MUST not include the SESSION-OF-INTEREST object when
sending an E2E Resv upstream towards the sender.  
"
(The "SESSION-OF-INTEREST" is simply the new name of the
"AGGREGATION-SESSION")

So this is basically what you are proposing....

I would rather we leave the DCLASS out altogether because it has
flexible applications (beyond Aggregation) and it can now be used for
whatever purposes without the Aggregation procedures interfering with
it.

Thanks

Francois

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