Access control and policy enforcement in internetworks. - Page 125 |
Save page Remove page | Previous | 125 of 148 | Next |
|
small (250x250 max)
medium (500x500 max)
Large (1000x1000 max)
Extra Large
large ( > 500x500)
Full Resolution
All (PDF)
|
This page
All
|
# of PG hops 2 3 4 5
Per-hop overhead 50 57 54 58
R oute com putation 20 20 30 30
Setup overhead 50 170 215 290
Total overhead 70 190 245 320
Table 5.2: P R setup overhead (in ms)
shows the average per PG setup overhead which is based on the to ta l overhead in row 4.
Because route com putation is a relatively expensive operation incurred only at the first
ihop, we decouple the overhead due to route com putation from the purely setup-related
overhead (as shown in row 3 and 4).
These results show th a t the per PG setup cost averages about 55ms. This number
is quite low considering th a t it includes th e following sequence of events at every transit
PG :
1. C ontext switch from Kernel to User mode to receive SETU P
2. MD4 digest com putation
3. Validity checking (including: timeliness, previous and next hop reachability and PT
validation)
4. C ontext switch from User to Kernel mode to forward SETU P
5. C ontext switch from Kernel to User mode to receive A C C E P T 6
6. MD4 digest com putation
7. P R table lookup to locate th e P R in question
8. C ontext switch from User to Kernel mode to forward A C C E PT
A lthough the results appear reassuring, a real-world, deployable im plem entation would
■include encryption-based signatures which will greatly increase the P R setup overhead.
Also, since the num ber of ADs in our concocted internetw ork is small and the topology
is simple, overhead due to route com putation and P T validation is kept artificially low.
On the other hand, this im plem entation was not tuned for perform ance.
6T h is does n ot occur im m ediately after the previous step.
Object Description
Description
| Title | Access control and policy enforcement in internetworks. - Page 125 |
| Repository email | cisadmin@lib.usc.edu |
| Full text | # of PG hops 2 3 4 5 Per-hop overhead 50 57 54 58 R oute com putation 20 20 30 30 Setup overhead 50 170 215 290 Total overhead 70 190 245 320 Table 5.2: P R setup overhead (in ms) shows the average per PG setup overhead which is based on the to ta l overhead in row 4. Because route com putation is a relatively expensive operation incurred only at the first ihop, we decouple the overhead due to route com putation from the purely setup-related overhead (as shown in row 3 and 4). These results show th a t the per PG setup cost averages about 55ms. This number is quite low considering th a t it includes th e following sequence of events at every transit PG : 1. C ontext switch from Kernel to User mode to receive SETU P 2. MD4 digest com putation 3. Validity checking (including: timeliness, previous and next hop reachability and PT validation) 4. C ontext switch from User to Kernel mode to forward SETU P 5. C ontext switch from Kernel to User mode to receive A C C E P T 6 6. MD4 digest com putation 7. P R table lookup to locate th e P R in question 8. C ontext switch from User to Kernel mode to forward A C C E PT A lthough the results appear reassuring, a real-world, deployable im plem entation would ■include encryption-based signatures which will greatly increase the P R setup overhead. Also, since the num ber of ADs in our concocted internetw ork is small and the topology is simple, overhead due to route com putation and P T validation is kept artificially low. On the other hand, this im plem entation was not tuned for perform ance. 6T h is does n ot occur im m ediately after the previous step. |
