Subject: RE: [NSIS] QoS analysis draft: novel inter-domain approach

From: [email-masked]
Date: Wed, 16 Jul 2003 15:53:54 +0300

Hi Helena,

Send text to the mailing list & we will see if the WG is interested.

John

> -----Original Message-----
> From: ext HELENA RUTE SOFIA [mailto:[email-masked]]
> Sent: 16 July, 2003 12:02
> To: Jukka MJ Manner
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] QoS analysis draft: novel inter-domain approach
> 
> 
> Jukka,
> 
> > you feel that SICAP has some unique properties and 
> solutions that are not
> > addressed with existing protocols, you are more than 
> welcome to provide
> > text. I'll try to read the documents you provided and 
> evaluate myself the
> > usefulness of an evaluation of an additional protocol. 
> Still, the decision
> > to add new protocols is not mine but for the whole WG and 
> chair to decide.
> 
> the current analysis draft covers several protocols; however, and even
> though it provides input on e2e signaling protocols, there is 
> not an explicit
> division of solutions, in terms of scope (intra-domain, inter-domain).
> So, in the inter-domain context, only BGRP is presented; 
> hence, I believe
> SICAP does bring additional benefits:
> 1) it outperforms BGRP in state;
> 2) it presents another type of aggregation, showing that the 
> sink-tree is
> not the only solution.
> 
> Also, given that aggregation is to be included in the next 
> document on the
> QoS-NSLP proposal, and given also that aggregation is still 
> an open issue,
> I do believe that SICAP brings a significant contribution to 
> this field.
> So, I think it should be considered in the context of the analysis
> document...
> 
> Rute
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Rute C. Sofia" <[email-masked]>
Date: Thu, 17 Jul 2003 04:02:24 -0400 (EDT)

John,
here goes the description on SICAP. I tried to address the same issues
already being addressed on the analysis draft.

> Send text to the mailing list & we will see if the WG is interested.

.........................................................
SICAP (Shared-segment Inter-domain Control Aggregation protocol) is an
inter-domain signaling solution that performs shared-segment aggregation
on the Autonomous System (AS) level with the purpose of reducing state
required at Boundary Routers.
SICAP performs aggregation based on path segments that different
reservations  share.
Thus, reservations may be merged into aggregates that do not extend
necessarily all the way until the reservation's destination. The
motivation for creating "shorter" aggregates is, on the one hand, their
abilitity to more easily accomodate future requests, and on the other
hand, the minimization of aggregates created and consequently, the
reduction of state required to manage established reservations. However,
and in contrast to the sink-tree approach (used by BGRP),
the shared-segment approach
introduces intermediate deaggregation locations: these are ASes where
aggregates may experience "re-aggregation". At these locations, routers
that perform aggregation (AS egress routers) have to keep track of the
mapping between reservations and aggregates. One possible way of doing
this is to keep each reservation identifier and corresponding resources
stored at each aggregator. However, this solution incurs a high state
penalty on state. SICAP avoids this state penalty by keeping track of the
mapping between aggregates and reservations at the level of destination
domains rather than explicitly mapping individual reservations to
aggregates. In other words, SICAP maintains per aggregate a list of the
destination prefixes advertised by the destination AS an aggregate
provides access to.
In terms of messaging sequence, SICAP is very similar to BGRP: it is
sender-initiated in the sense that the first border router triggers the
process of reservation establishment; it establishes reservations using a
two-phase establishment mechanism: on the first phase, the path is probed
using a message that requires no state, and on the second phase, resources
are allocated. Message delivery is reliable, given that SICAP exchanges
messages over TCP connections.

SICAP and BGRP attain the same signaling load, given that they use three
similar messages to establish and to explicitely delete reservations. This
means that both proposals do not present any signaling load reduction when
compared to proposals that do not perform aggregation.
 In terms of bandwidth, both protocols provision aggregates with the exact
bandwidth required by their merged reservations. Hence, their
major difference is in
state required to manage reservations: we've shown, carrying out
simulations with the network simulator version 2, that SICAP
significantly reduces state required when compared to BGRP.
We consider this to be
of importance not so much to offer a better performing alternative to
BGRP, but to quantify the performance improvements that might still be
available in the research field of control path aggregation.
We have also performed a study, and devised a novel mechanism that can be
used to lower the signaling load of aggregation approaches.

Thanks,
Rute