optimising internet access control lists vic grout, and stuart cunningham centre for applied...
TRANSCRIPT
Optimising InternetAccess Control Lists
Vic Grout, and Stuart Cunningham
Centre for Applied Internet Research (CAIR)University of WalesNEWI Plas Coch Campus, Mold RoadWrexham, LL11 2AW, UKwww.cair-uk.org
[email protected]@cair-uk.org
NEWI North East Wales Institute of Higher Education - Centre for Applied Internet Research
Department of Computer Science and Engineering, University of Nevada, Reno15th November 2006
Access Control Lists (ACLs)
“Packet filters”
Access Control Lists (ACLs)
“Packet filters”
Interfaces: in and out (permit/deny)
Access Control Lists (ACLs)
“Packet filters”
Interfaces: in and out (permit/deny) Also selecting packets for traffic policies
Access Control Lists (ACLs)
“Packet filters”
Interfaces: in and out (permit/deny) Also selecting packets for traffic policies Across an internet
Access Control Lists (ACLs)
“Packet filters”
Interfaces: in and out (permit/deny) Also selecting packets for traffic policies Across an internet Can add considerable packet latency
Access Control Lists (ACLs)
ACL Uses and Applications
Blocking and passing traffic security/privacy/protection commercial restrictions/preferences
Selecting packets for traffic policies Network Address Translation (NAT) traffic shaping bandwidth allocation/provisioning/reservation routing/switching VPNs/tunnelling logging etc.
Packet Lookups
There are different forms of (subtly different) packet lookup scenarios Packet classification
• e.g., routing tables• find the longest prefix matching a packet
Packet matching• e.g., ACLs• find the first rule matching a packet
Some, but not all, approaches work, sometimes partially, for both
This talk concentrates on packet matching in ACLs
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Sequence of ‘permit’and ‘deny’ rules
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Sequence of ‘permit’and ‘deny’ rules
Each rules tries to matchsome feature of the packet
being processed
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Sequence of ‘permit’and ‘deny’ rules
Each rules tries to matchsome feature of the packet
being processed
Rules processedsequentially …
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Sequence of ‘permit’and ‘deny’ rules
Each rules tries to matchsome feature of the packet
being processed
Rules processedsequentially …
… until a rule matchesthe packet (stop) …
Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
Sequence of ‘permit’and ‘deny’ rules
Each rules tries to matchsome feature of the packet
being processed
Rules processedsequentially …
… until a rule matchesthe packet (stop) …
… or the last ruleis reached
ACL Optimisation How can the matching of packets against an ACL be
optimised? It depends on ACL implementation
Where are ACLs stored? Where does optimisation take place
Are ACLs implemented in hardware? software? a combination?
Are ACLs searched linearly? in parallel (TCAMs) or using trees/tries? using cache?
Hardware Implementations
Using TCAMs Ternary Content Addressable Memory
A TCAM takes a rule and outputs the lowest indexed rule that matches the
packet i.e. the first rule in the ACL stored in the TCAM
TCAM
Packet
RuleACL
CAMs and TCAMs
CAM (Content Addressable Memory) A kind of ‘RAM in reverse’ Accepts data and returns the address (say) Binary match on 1s and 0s Used in switch MAC address tables for example
TCAM (Ternary CAM) Allows 1, 0 or ? ? – wildcard to match either 1 or 0 Used (in slightly different ways) for
• routing tables• ACLs
TCAM Example
Packet: ip 10.0.0.3 192.168.0.211100 0000101000000000000000000000001111000000101010000000000000010101
deny ip 10.0.0.0 0.0.0.255 any
1 1010 1101010101010101010110011000101 01110111???????????????????????0 0001 1101111100 :1 1100 00001010???????????????????????? ???????????????????????????????? :1 1010 10110111111001110101010101010101 0101?????????1111010110?????????0 ???? 1111???????????????????????????? 0000011101010110101?????????????1 ???? ???????????????????????????????? ????????????????????????????????
1 1100 00001010???????????????????????? ????????????????????????????????
Rule
ACL
TCAM
CAM/TCAM Implementation
Hardware version of an associative array Semiconductor
complex circuitry• expensive• power dissipation/cooling
Emulated trees/hashing/pipelining slower
Not just a question of searching TCAMs How are they maintained?
• eg, how is a new rule inserted?
Only really viable for top-end routers
Optimisation in Software
(Implementation can still be in hardware) Control in software
Binary Search Trees (BSTs) Tries
• ‘prefix trees’ Reordering (optimising) linear list
All have advantages/disadvantages. Generally: the faster to search, the harder to maintain
• processing overhead how about responding to changing traffic patterns?
• ‘stable’/’unstable’ traffic
‘Algorithmics’
Tries
Re’trie’val An improvement over BSTs
0 1
0 10 1
10
0 0 0 1 1
1 1 1 1
0 1 0 1 1
0 1 1 1 0 1
0000
11111
0000100 0000101 … … … 1101111
rules stored as keys on branches, not nodes
Tries vs. Trees
Advantages of tries Faster (O(rulelength) vs. O(log numberofrules)) Fast array indexing Smaller for large numbers of short rules Balancing not necessary
Disadvantages of tries Can only order on given structure Larger for small numbers of large rules More complex to maintain
Cisco Turbo ACLs (2003/2004)
Reordering (Optimising) a Linear List
What if hardware implementation or tries are impractical? eg, lower range routers
Can we optimise directly on the ACL? eg, change the rule order in the (linear) list
Possible objections algorithms too complex to be implemented? algorithms take longer to run than savings gained? linear optimisation only worthwhile for large lists?
• which we don’t get on small routers some rules can’t be reordered …
Rule Order access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
It takes time to processeach packet againstthe rules in a list …
Rule Order access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
It takes time to processeach packet againstthe rules in a list …
… and there may be a better list,with the rules in a different order,
that can be processed faster
Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
It takes time to processeach packet againstthe rules in a list …
However, some rules aredependent and cannot
be reordered
… and there may be a better list,with the rules in a different order,
that can be processed faster
Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
However, some rules aredependent and cannot
be reordered
The same packet couldmatch both these rules
Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
This order woulddeny the packet …
Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any
… but this orderwould permit it
Linear ACL Latency
(Simplified notation) n rules in list L Hit-rate hi(L)
• probability that packets match rule i in list L Latency i(L)
• time taken to process rule i in list L Cumulative latency i(L)
• time taken to process list up to and including i in list L
Expected latency E(L)• average time to process List L
i
jii LL
1
)()(
)()()(1
LLhLEn
iii
Linear ACL Optimisation Problem
Expected latency E(L) average time to process List L
Dependency Matrix D = (dij)
Problem: Minimise E(L) subject to D NP-complete (Grout et al., JoH, 2005)
)()()(1
LLhLEn
iii
:0
:1ijd
Rules i and j are dependent
otherwise
ACL Optimisation - Background
2000: Hari et al. analysis to resolve rule conflicts
2001: Stocia model for packet classification
2002: Cisco ACL optimizer and hits optimizer
2003/2004: Bukhatwa & Patel various optimisation techniques for simplified problems
2003/2004: Cisco ACL Manager
2004: Al-Shaer & Hamed complete model for avoiding conflict
ACL Optimisation - Background
2000: Hari et al. analysis to resolve rule conflicts
2001: Stocia model for packet classification
2002: Cisco ACL optimizer and hits optimizer
2003/2004: Bukhatwa & Patel various optimisation techniques for simplified problems
2003/2004: Cisco ACL Manager
2004: Al-Shaer & Hamed complete model for avoiding conflict
OFF-LINE
ON-LINE
Online ACL Optimisation
2005: IEEE/IFIP IM (& Jnl. Heuristics): Grout et al. complete model of optimisation problem shown to be NP-complete simple (inefficient) heuristics
2005: INC: Grout et al. improved (efficient) heuristics analysis incomplete
2006: Computer Communications: Grout et al. complete analysis different ACL and traffic types
2006: WWW/Internet: Grout et al. fine-tuning of parameters
Exact ACL Optimisation
Exhaustive Search Dynamic Programming Linear Programming Branch and Bound
All ideally suited to static optimisation may struggle to deal with changing traffic
characteristics
Exhaustive Search
Generate each permutation of the rules in turn Check whether dependencies (D) satisfied Evaluate E(L) Record successive minima
Computationally infeasible Time complexity, O(n!) Space complexity, O(n)
Dynamic Programming
‘Sequence to Minimise Expected Latency’ (SMEL) Variation of Held & Karp (1962) TSP algorithm
Initial ACL: Z = {r1, r2, …, rn} (with rn fixed)
For Y = {r1, r2, …, rn-1} and r Y, let |SMEL|(Y, r) be the minimum
expected latency of the sublist Y {rn}
Then
SMEL can then be calculated as min r |SMEL|(Z, r) + (r(Z))
Only useful as a benchmark for (very small) problem instances Time complexity, O(2n) Space complexity, O(2n)
LP and B & B
3: Linear Programming (LP) Formulation of SMEL as LP non-trivial but possible not appropriate for embedded implementation some value in small-scale testing
4: Branch and Bound (B&B) eg, Applegate & Cook (2003/2004) TSP often involve human intervention not appropriate for embedded implementation some value in comparison for small numbers of larger
problem instance
Approximations and Heuristics
k-opt simple rule swaps
Lin and Kernighan (1973) nested rule swaps
Constrained Sort (Grout et al., 2005) a form of ‘immediate promotion’
-opt (Grout et al., 2006) local swap operation
May manage dynamic optimisation better more responsive to changing traffic characteristics
2-opt
L := IZ;
repeat
max := 0;
for i := 1 to n-2 do
for j := i+1 to n-1 do
if dij = 0 then
begin
:= E(L,T) – E(L<ij>,T); if > max then
begin
max := ; i* := i;
j* := j
end
end;
if max > 0 then
swap(ri*(L), rj*(L))
until
max = 0
3-opt
L := IZ;
repeat
max := 0;
for i := 1 to n-3 do
for j := i+1 to n-2 do
for k := j+1 to n-1 do
if (dij = 0) and (djk = 0) and (dik = 0) then
begin
:= E(L,T) – E(L<ijk>,T); if > max then
begin
max := ; i* := i;
j* := j;
k* := k
end
end;
if max > 0 then
permute(ri*(L), rj*(L), rk*(L))
until
max = 0
LK-opt
Various forms, eg …
L := IZ;
repeat
repeat
single_smel_2-opt
until
max = 0;
single_smel_3-opt
until
max = 0
Constrained Sort (C-Sort)
L := IZ;
repeat
:= 0; for i := 1 to n-2 do
if di i+1 = 0 then
if E(L,T) – E(L<i i+1>,T) > 0 then
begin
:= 1; swap(ri(L), ri+1(L))
end
until
= 0
Comparing Heuristics
2-opt Fairly fast and reasonably accurate
3-opt Slower but more accurate
LK-opt Slowest but most accurate
C-Sort Fastest but not particularly accurate
All must be reapplied at intervals as traffic characteristics change … which leads us to some further analysis of the
problem – and, in particular, hit-rates
A Deeper Analysis
None of 2-opt, 3-opt, LK-opt or C-sort are fast enough to justify their use in real time unless only applied infrequently which negates their effectiveness The main problem is having to recalculate the expected
latency for each permutation
Where do hit-rates come from? They are counted as packets arrive They must all start equal
• when the list is configured/reconfigured• zero?• or normalised probabilities?
A Deeper Analysis
In fact, in comparing rule order for a list L, the significance of rule hit-rates is only relative. It is not necessary for them to be normalised (i.e. summing to 1) probabilities. This implies that the hit-rate of a newly hit rule, i, can increase without changing the hit-rates of the other rules.
Following an increase in a rule i’s hit-rate, the only possible change in rule order (to reduce E(L)) is to promote i up the list. The most likely candidate with which to exchange it is rule i-1, immediately above it.
A Deeper Analysis
The potential saving in expected latency in swapping rules i-1 and i is given by
a simple, local calculation.
Considering rule promotions continuously in this manner is entirely responsive to dynamically changing traffic patterns. This suggests the following …
iiii
iiiiiiiiii
n
ikkkiiii
i
kkk
n
ikkkiiii
i
kkk
hh
hhhh
hhhhhhhh
11
11111
111
2
1111
2
1
)()(
Simple ACL Optimisation (-opt)
Three-part heuristic:
Step 1: Initialisation (following manual ACL configuration)
for i := 1 to n do
hi := 1 \ hit rates equal at start
Step 2: Promotion (on a packet matching rule i)
hi := 2hi \ exponentially increase matched hit-rate
if di-1 i=0 and hiλi-1 > hi-1λi then
Swap(i-1, i) \ promote if E(L) reduced
Step 3: Reduction (periodically to prevent overflow)
for i := 1 to n do
hi := hi / max j hj
Calculating Effectiveness
Cost of optimisation against value Value
: percentage decrease in expected latency• simulation/testing
Cost
B: size (bits) of registers
100
4 n
B
n212
ACL Optimisation Effectiveness
ACL characteristics: DI (dependency index) probability of two rules being dependent
Traffic self-similarity: S (self-similarity index) Probability that a packet matches the same rule as the
previous packet Minimum number of rules (n*) for -opt to work:
DI = 0.00 0.25 0.50 0.75 1.00
S = 0.00 19 21 23 33
0.25 16 19 21 29
0.50 13 15 19 26
0.75 9 10 13 21
1.00 8 9 12 17
Refining the Dependency Index
In reality, DI can never be as large as 1 Dependencies can only exist between opposite types
permit/deny x permits, y denys n = x + y
P: Permit D: Deny X – No dependencies ? – Possible dependencies
RULE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 & TYPE P P D D D D D D P P P P P P P P P P P P P P P D
1 P 2 P 3 D 4 D 5 D 6 D 7 D 8 D 9 P
10 P 11 P 12 P 13 P 14 P 15 P 16 P 17 P 18 P 19 P 20 P 21 P 22 P 23 P 24 D
Figure 2. Rule Dependencies.
X – No ? - Possibledependencies dependencies
? – Possibledependencies
X – No ?dependencies
X
X ?
?
X
?
X – No dependencies ?
X ? – Possible dependencies
X
Refining the Dependency Index So number of dependencies bounded by n2 – x2 – y2
and DI bounded by
So 0 ≤ DI ≤ 0.5
However, in -opt, swaps are not considered between non-contiguous blocks
2
222
n
yxn
0
0.1
0.2
0.3
0.4
0.5
0.6
1 3 5 7 9 11 13 15 17 19 21 23 25
Upper bound for DI
x: Number of Permits
x + y = n n = 24
n2 – x2 – y2
n2
Re-refining the Dependency Index Suppose L has bx blocks of permits Xj and by blocks of
denys Yk
Number of invalid swaps is then … and the fragmented dependency index, FDI, bounded by
So 0 ≤ FDI < 1
yx
b
kk
b
jj YXyxn
11
yx
b
kk
b
jj YXn
1
2
1
22
yxb
kk
b
jj YXn
n 1
2
1
222
1
0
0.2
0.4
0.6
0.8
1
1.2
1 3 5 7 9 11 13 15 17 19 21 231 2 3 4 6 8 12 24
Upper bound for FDI
yxb
kk
b
jj YXn
n 1
2
1
222
||||1
bx + by
|Xj| = |Yk| = n / (bx + by) 1 j bx and 1 k by
ACL Case Studies
ACL n x y bx by Xj Yk DI * FDI*
A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74
B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81
C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65
D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87
E 19 7 12 1 2 7 6, 6 0.47 0.66
F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73
G 111 29 82 1 2 29, 80, 2 0.39 0.41
H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60
I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70
J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83
K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76
* upper bound
ACL Case Studies
ACL n x y bx by Xj Yk DI * FDI*
A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74
B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81
C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65
D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87
E 19 7 12 1 2 7 6, 6 0.47 0.66
F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73
G 111 29 82 1 2 29, 80, 2 0.39 0.41
H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60
I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70
J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83
K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76
* upper boundA,E: SOHO environments B,C,D: College/UniversityF,G,H: Company networks I,J,K: Standard templates
ACL Case Studies
ACL n x y bx by Xj Yk DI * FDI*
A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74
B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81
C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65
D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87
E 19 7 12 1 2 7 6, 6 0.47 0.66
F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73
G 111 29 82 1 2 29, 80, 2 0.39 0.41
H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60
I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70
J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83
K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76
* upper bound
Comparing Dependency Bounds
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
A B C D E F G H I J K
Upper bound for FDI
Upper bound for DI
Comparing Dependency Bounds
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
A B C D E F G H I J K
Upper bound for FDI
Upper bound for DI
FDI is generally amore pessimistic(i.e. allowing fewerswaps) bound thanDI. They can beclose in exceptionalcases.
Effectiveness of Simple Optimisation
ACL S = 0.00 0.25 0.50 0.75 1.00
A DI* / FDI* 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0
B 1 / 0 1 / 0 1 / 1 1 / 1 1 / 1
C 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
D 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
E 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1
F 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0
G 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
H 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
I 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
J 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1
K 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
0: -opt notworthwhile
1: -optworthwhile
Effectiveness of Simple Optimisation
ACL S = 0.00 0.25 0.50 0.75 1.00
A DI* / FDI* 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0
B 1 / 0 1 / 0 1 / 1 1 / 1 1 / 1
C 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
D 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
E 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1
F 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0
G 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
H 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
I 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
J 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1
K 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1
0: -opt notworthwhile
1: -optworthwhile
Instances inwhich DI orFDI makes adifference.
Conclusions
ACL Optimisation in hardware is very fast but also very expensive TCAMS
• only on top-end models Tries
• not quite as expensive• but not as fast• a compromise
Conclusions
ACL optimisation in software may have some potential in restricted environments conventional static methods
• too complex• not reactive to changing traffic
simpler process may be the solution• very fast• reacts to changing traffic• is worthwhile to implement
• savings in latency outweigh time to implement
Thank you …
… Any Questions?
NEWI North East Wales Institute of Higher Education - Centre for Applied Internet Research
Vic Grout, and Stuart Cunningham
Centre for Applied Internet Research (CAIR)University of WalesNEWI Plas Coch Campus, Mold RoadWrexham, LL11 2AW, UKwww.cair-uk.org
[email protected]@cair-uk.org
Department of Computer Science and Engineering, University of Nevada, Reno15th November 2006