Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
a SICAP: Shared-Segment based Inter-domain Control Aggregation Protocol.
1. < >
SICAP, a Shared-segment Inter-domain Control
Aggregation Protocol
Siemens
Munich, July 2003
Rute Sofia (rsofia@seas.upenn.edu)1,2
Roch Guerin1 (guerin@ee.upenn.edu)
1University of Pennsylvania/
2
University of Lisbon
rsofia@seas.upenn.edu – p. 1/16
2. < >
Outline
1. Motivation
2. BGRP Example
3. SICAP Description
4. BGRP and SICAP Performance Comparison
5. Reducing the Signaling Load: Over-reservation
6. Conclusions
rsofia@seas.upenn.edu – p. 2/16
3. < >
The Motivation
QoS Data plane: covered by IntServ, DiffServ
QoS Control plane
Establishment and management of reservations works well
inside ASs: RSVP, YESSIR...
But what about between ASs?
Traffic Engineering, Over-provisioning
Reservation Aggregation
OUR FOCUS: Inter-Domain Control Aggregation
rsofia@seas.upenn.edu – p. 3/16
4. < >
Aggregation
GRANULARITY
Flow level: 1.09 bilion active IP addresses,
¡¢£
possible
combinations
Network prefix level: depends on the distribution of IPs per
network
AS level: in 2002, there were 13,000 active ASes
SCOPE:
one AS-hop, whole AS path; destination AS; AS path segments
GOAL: Compare two different aggregation approaches, shared-
segment and sink-tree
BGRP: sink-tree
SICAP: shared-segment
rsofia@seas.upenn.edu – p. 4/16
5. < >
BGRP Functional Example
Sender-initiated
Establishment in 2
phases:
probing/allocation
Aggregates requests
with same AS
destination
Only deaggregates at
destination AS (O(N))
Messages:
PROBE/GRAFT/TEAR
AS1
AS3
AS4
AS2
PROBE(1) GRAFT(1)
GRAFT(2)
AS6
AS5
R1
Sink−tree A
R2
R3
PROBE(2)
PROBE(3)
GRAFT(3)
Sink−tree B
S2
E6
S1
E1
E2
E3 E4
E5
D2
D1
rsofia@seas.upenn.edu – p. 5/16
6. < >
SICAP
Similar to BGRP BUT
Aggregate destination
might be upstream of
request destination
Intermediate
deaggregators (IDLs)
Shorter aggregates
might accomodate
more easily future
requests
Messages:
REQ/RESV/TEAR
AS1
AS3
RESV(1)REQ(1)
AS2
AS5
AS6
AS4
R1
A1A2
R2
A3
REQ(2) RESV(2)
S2
E1
E2
E3 E4
E5
S1 D1
D2
E6
rsofia@seas.upenn.edu – p. 6/16
8. SICAP, How to Aggregate
Enhanced-Weighted Deaggregation pointS, E-WDS
“Weights” each AS, based on the number of downstream BGP
neighbors
R1
W=2
IDL (D1)
Destination AS
Source AS
W=1 W=2 W=6 W=2 W=3
W=1
rsofia@seas.upenn.edu – p. 7/16
9. SICAP, How to Aggregate
Enhanced-Weighted Deaggregation pointS, E-WDS
“Weights” each AS, based on the number of downstream BGP
neighbors
IDL (D1) IDL (D2)
R1
W=0
W=2
A3
A2A1
Source AS
Destination AS
W=3 W=1
rsofia@seas.upenn.edu – p. 7/16
10. SICAP, State Information at Intermediate Aggregators
To manage resources properly, it is necessary to keep some mapping
between reservations and aggregates:
Option 1: Reservation Identifier (tuple, resources) mapped to corre-
sponding aggregates
r4
A3
A4
A2
A1
r3
r2
r1
r4
AS1
Deaggregated requests
A4
A3
r2
r1
r3
Aggregators
Deaggregators
BR
BR
BR
BR
rsofia@seas.upenn.edu – p. 8/16
11. SICAP, State Information at Intermediate Aggregators
To manage resources properly, it is necessary to keep some mapping
between reservations and aggregates:
Option 2: Destination ASes (network prefixes) mapped to aggregate
A3
A4
A2
A1
r3
r2
r1
r4
AS1
Deaggregated requests
A4
A3
Aggregators
Deaggregators
prefix A
prefix B
BR
BR
BR
BR
rsofia@seas.upenn.edu – p. 8/16
12. BGRP and SICAP Comparison
Evaluation parameters: state information, bandwidth utilization
efficiency, signaling load
Bandwidth utilization efficiency: additive bandwidth,
§
Signaling message load: both protocols use a message pair per
reservation establishment; optional TEAR per individual reserva-
tion
STATE ?
ns2 extended to support BGRP and SICAP
rsofia@seas.upenn.edu – p. 9/16
15. Some Remarks
Both protocols reduce significantly state required
SICAP outperforms BGRP in state
None of these protocols lowers the signaling load
Reduce the frequency of updates to aggregates
by provisioning each aggregate with more bandwidth than the required
sometimes
§
g
§
h
pi
rsofia@seas.upenn.edu – p. 11/16
17. Evaluation
ns2 simulations, different bandwidth distributions, long-lived,
short-lived requests (arrival is Poisson model)
Performance measured in terms of increase in the blocking
probabilities, and in signaling load reduction
Three different approaches:
Over-reserving (quantisation, dynamic function)
Delayed Release alone (two dynamic functions)
Hybrid approach: over-reserving and hybrid
rsofia@seas.upenn.edu – p. 13/16
19. Conclusions
SICAP: shared-segments; BGRP: sink-tree
SICAP outperforms BGRP in state management
Both protocols do not improve the signaling load required. A
solution can be over-reservation
Allows to reduce the signaling in more than 50% for both
protocols without attaining a high penalty in blocking
BGRP profits most of the use of a delayed release mechanism
SICAP profits most of the use of a hybrid approach
Is there a “best solution”? SICAP always achieves less blocking;
BGRP seems to reduce better the signaling at high intensities, BUT
this is also due to the blocking
rsofia@seas.upenn.edu – p. 15/16