The document describes and compares two inter-domain control aggregation protocols: BGRP and SICAP. BGRP uses a sink-tree aggregation approach, aggregating reservation requests with the same destination AS. SICAP uses a shared-segment approach, allowing intermediate aggregation points upstream of the destination. The document outlines the motivation for inter-domain control aggregation, provides examples of how each protocol aggregates reservations, and compares their performance based on simulations evaluating state information and signaling load. It also describes an over-reservation approach that can help reduce signaling load for both protocols.

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

7. < >
SICAP, How to Aggregate
Enhanced-Weighted Deaggregation pointS, E-WDS
“Weights” each AS, based on the number of downstream BGP
neighbors
¤¦¥
§¨
©
¨
Special cases: ASes with same
¤¥
and leaf AS (no downstream
neighbors)
rsofia@seas.upenn.edu – p. 7/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

13. Test Scenario
34
33
32
31
30
29
28
27
9
26
8
25
7
24
6
23
5
22
4
21
3
20
19
2
18
1
17
0
16
15
14
13
12
11
10
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
AS level Internet-like topology
(BRITE)
50 ASes
Sources chosen randomly;
destinations placed using a real IP
address distribution on the Internet
Arrival of requests: Poisson process,
exponential holding times: short, long
and mixed-type requests
Number of requests in the system
kept constant while varying average
duration
rsofia@seas.upenn.edu – p. 10/16

14. Test Scenario
!
###$$
%
%
%
%
%
%
%
%
%
%
''''''((((((
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)00000000000000000
1
1
1
1
1
1
2
2
2
2
2
2
3
34
555666
77778888
9999999@@@@@@
AAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBB
C
C
C
D
D
D
E
EF
F
G
G
G
GH
H
H
H
IIIIPPPP
QQQQQQQRRRRRRR
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
ST
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
U
U
U
U
U
U
V
V
V
W
WX
X
YY`
a
a
a
a
a
ab
b
b
b
b
b
c
c
c
c
c
c
c
c
c
c
c
cd
d
d
d
d
d
d
d
d
d
eeeeeeeeeeeeeeefffffffffffffff
0
500
1000
1500
2000
2500
100 1000 5000 10000 50000
StateUnits
Requests per second
Avg State
BGRP, 20s
BGRP, 50% 20s, 50% 120s
BGRP, 20% 20s, 80% 120s
BGRP, 20% 120s, 80% 20s
BGRP, 120s
SICAP, 20s
SICAP, 50% 20s, 50% 120s
SICAP, 20% 20s, 80% 120s
SICAP, 20% 120s, 80% 20s
SICAP, 120s
rsofia@seas.upenn.edu – p. 10/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

16. Over-reservation
AS4
AS5
b: 3/10
b: 5/5 b: 5/5
b: 5/5
PROBE(1,b=2)
PROBE(1,b=2)
GRAFT(1)
AS1
AS2
AS6
AS7
b: 10/10
A1b: 10/10
A2
R2, b=5 units
R1, b=2 units
S2
E2
E3
S1
E4E1 E6E5
E7
E8
D1
D2
AS2
AS6
AS7
AS1
AS3
AS4
AS5b: 10/10b: 3/10
A2
RESV(1)
RESV(1)
REQ(1,b=2)
REQ(1,b=2)
A4
A5
A1
A3
b: 3/3
REQ(1,b=2)
RESV(1)
b: 4/4
R2, b=5 units
R1, b=2 units
S2
D1
D2
E2
E3
S1
E4E1 E6E5
E7
E8
rsofia@seas.upenn.edu – p. 12/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

18. Approaches’ Comparison
qr
stuvtwxuy
€v‚
ƒ„…
†‡v…ˆ…vwv…‡„ux‰t
vƒ„yv‘€vƒv„wv
†‡v…ˆ…vwv…‡„ux‰t„t‘‘vƒ„yv‘…vƒv„wv
q’
q’
xt“…v„wv
”xt„ƒxt…v‘‚
“ux‰t
q’
xt“…v„wv
”xt„ƒxt…v‘‚
“ux‰t
q’xt“…v„wv
”xt„ƒxt…v‘‚
“ux‰t
•—–˜•™
˜••
•–••
•—–••
d–e˜
•—–••
˜d–fg
•—–••
hei–dg
˜•••
•–••
•—–••
hj–gh
•—–••
hd–fe
•—–••
ej–ej
j•••
•–••
•—–••
kl–˜•
•—–••
kei–lf
•—–••
jh–ek
˜••••
•–••
•—–••
kei–ge
•—–••
kj–g•
•—–••
jk–lk
–˜™nm˜™
˜••
•–••
•—–••
g–fd
•—–••
j–•e
•—–••
d–le
˜•••
•–••
•—–••
hj–˜•
•—–••
h˜–˜f
•—–••
hl–kh
j•••
˜˜–hl
k–dk
hd–kd
h•—–kk
e•—–dl
g–ef
kf–l˜
˜••••
hl–j˜
ei–ej
hj–˜l
hh–˜j
ef–˜j
˜k–d•
ek–kl
j•™–˜™
˜••
•–••
•—–••
g–fg
•—–••
˜ei–ed
•—–••
˜ei–ke
j•™˜™
˜•••
•–••
•—–••
hj–e•
•—–••
hf–•d
•—–••
hg–˜k
j•••
•–••
˜–ke
kk–˜e
f–lg
kg–kd
˜–k•
kj–j•
˜••••
l–˜e
ei–k˜
kk–˜j
˜f–je
ej–fj
j–˜j
e•—–•h
op
qrstruvsw
xtyz
{|}
~t}€}tut}|svr
‚t{|wtƒxt{t|ut
~t}€}tut}tƒ|rƒƒt{|wtƒ}t{t|ut
o„
o„
vr…}t|ut
†vyr|{vry}tƒz
…svr
o„
vr…}t|ut
†vyr|{vry}tƒz
…svr
o„vr…}t|ut
†vyr|{vry}tƒz
…svr
‡—ˆ‰‡Š
‰‡‡
‡ˆ‡‡
‡—ˆ‡‡
‰ˆ‹‡
‡—ˆ‡‡
‰Œˆ‹Œ
‡—ˆ‡‡
‰‰ˆŽ
‰‡‡‡
‡ˆ‡‡
‡—ˆ‡‡
‰ˆ‡
‡—ˆ‡‡
‘‹ˆŒ
‡—ˆ‡‡
‘ˆŒ‹
Ž‡‡‡
‡ˆ‡‡
‡—ˆ‡‡
Œˆ
‡—ˆ‡‡
’‰ˆ‡‘
‡—ˆ‡‡
‹‰ˆ’Ž
‰‡‡‡‡
‡ˆ‡‡
‡—ˆŒ’
ˆ’Ž
‡—ˆ‡‡
’’ˆ
‡—ˆ‡‡
‹ˆ‹
ˆ‰Šn“‰Š
‰‡‡
‡ˆ‡‡
‡—ˆ‡‡
‰ˆ‡
‡—ˆ‡‡
‰ˆŒ
‡—ˆ‡‡
‘ˆ‘‹
‰‡‡‡
‡ˆ‡‡
‡—ˆ‡‘
‰ŽˆŽŽ
‡—ˆ‡‡
ŒŽˆ’Œ
‡—ˆ’
Œ‹ˆ’‘
Ž‡‡‡
‰‰ˆŒ’
‰Œˆ‡‘
Œˆ‹Ž
‰‰ˆ‹Œ
Ž‡—ˆ‹
‰ˆ‡Ž
ŽŽˆŒ‘
‰‡‡‡‡
Œ’ˆŽ‰
‰‰ˆ
Œ’ˆŒ‘
‹ˆ‹
Ž‘ˆ‡’
‰iˆ‘
Ž‹ˆ‹
Ž‡Šˆ‰Š
‰‡‡
‡ˆ‡‡
‡—ˆ‡‡
‰ˆ‘‡
‡—ˆ‡‡
’ˆ’
‡—ˆ‡‡
iˆŽ
Ž‡Š‰Š
‰‡‡‡
‡ˆ‡‡
‡—ˆ‡‡
‰‹ˆ‘’
‡—ˆ‡‡
‘‡—ˆ‹‰
‡—ˆ‡‡
‘‰ˆ‰‰
Ž‡‡‡
‡ˆ‡‡
ŽˆŒ
‘ˆ‘
iˆ‹Ž
Žˆ‹Ž
ˆ
’‰ˆ‹‡
‰‡‡‡‡
’ˆ‰
‰‡—ˆ‰’
Œˆ
’ˆ‘
’’ˆ
‰‡—ˆ‘‡
’ˆŒŽ
rsofia@seas.upenn.edu – p. 14/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

20. Some References
http://rutesofia.no.sapo.pt/prese.html
http://einstein.seas.upenn.edu/mnlab/paper/
QUESTIONS?
rsofia@seas.upenn.edu – p. 16/16