1 / 18

Dynamic Extensible Multi-Service Router

This presentation discusses the classification and routing capabilities of the Dynamic Extensible Multi-Service Router (MSR) developed by Fred Kuhns at Washington University Applied Research Laboratory.

renner
Download Presentation

Dynamic Extensible Multi-Service Router

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Packet Classification in the SPCarl/projects/msr/work/msrcfy.ppt Fred Kuhns Washington University Applied Research Laboratory

  2. flexsig OSPF ATM/Switch Lib (I/O and control) classify classify Dynamically Extensible, Multi-Service, Extreme Router The ARL DEMSER logical diagram CP - Control Processor MM – MSR Manager RA - Route Agents NMA - Network Management Agent DQ – Distributed Queuing DRR – Deficit Round Robin PP - Port Processor (SPC/FPX) PE – Processing Environment (SPC) FP – Forwarding Path (PX/SPC) Routing and Signaling MSR CP MM RA framework Configure Routing OSPF NOC NMA flexroutd OSPF++ Resource Net Manager App and GUI Logical Interfaces IP ATM PP PP PP PE MSR control PE plugin plugin plugin plugin WUGS DQ DQ classify/lookup classify/lookup FP DRR DRR FP PP PP PP PP PP

  3. command messages to/from CP add/update EM filter and reservation report and status General Match Exact Match Route lookup Queues 64 Dgram 256 Reserve process/update option shim forward packet: get output queue from pkt type, outVIN and reservation. perform necessary IP processing IP LFS option or protocol status to CP padding trailer ... plugin instances may modify packets monitor only input port: output queue from port number in outVIN. output port: output queue either one of 64 datagram queues or reserved queue. The outVIN’s subport value determines the VC a packet is sent on. Note, each queue in the packet scheduler may send a packet on any of the 4 output VCs. drop packet, return buffer to pool. input port: 4 input VCs, 50-53, from phop/hosts output port: 8 input VCS, 40-47, from the 8 input ports. Plugin Instances SW Classifier: Top-Level View LFS Module Classifier Packet Scheduler cmd processor input port output port or get route in shim ... classify packet Input Link/MAC Processing IP preprocessing ... PI0 PI1 PI2 PIn cmd processor Plugin Control Unit command messages to/from CP

  4. General Match Exact Match Route lookup shim IP padding trailer ... SW Classifier: Top-Level View LFS Module Classifier Packet Scheduler cmd processor command messages to/from CP add/update EM filter and reservation report and status input port output port Queues 64 Dgram 256 Reserve or get route in shim process/update option forward packet: get output queue from pkt type, outVIN and reservation. perform necessary IP processing LFS option or protocol ... status to CP classify packet Input Link/MAC Processing IP preprocessing plugin instances may modify packets monitor only input port: output queue from port number in outVIN. output port: output queue either one of 64 datagram queues or reserved queue. The outVIN’s subport value determines the VC a packet is sent on. Note, each queue in the packet scheduler may send a packet on any of the 4 output VCs. drop packet, return buffer to pool. ... input port: 4 input VCs, 50-53, from phop/hosts output port: 8 input VCS, 40-47, from the 8 input ports. PI0 PI1 PI2 PIn cmd processor Plugin Instances Plugin Control Unit command messages to/from CP

  5. Classifier Abstractions • The SW Classifier has three lookup engines and tables: • exclusive and non-exclusivegeneral match filters, each with a settable priority and sharing a common table. • exact match filters, with global priority. • destination prefix lookup (fipl and simple) with global priority • Each table contains a set of rules and a lookup strategy • Strategy includes order relation, matching/selection criteria and bindings. • Rule is composed of a predicate, action and data. • Predicate: set of one or more header fields and matching criteria. Depending on field, possible criteria include prefix match (value/length), all match (wildcard), range (i.e. port range), or exact value. • Actions: Explicit {Deny – drop packet, Active – send to R/W plugin, Reserve – reserved flow with BW reservation, Monitor – send to RO monitoring plugin} Implicit {Permit – absence of Deny action} • Data examples: plugin reference, priority, reservation

  6. General Match Filters • General Matchengine: compare packet fields (5-tuple), interface (input/output port) and priority. • Specifying the packet fields, i.e. the 5-tuple: • IP prefix/address, source and destination: Prefix/width • network prefix: 192.168.200.0/24; exact host: 192.168.204.2/32;any address: 0/0 • Ports, source and destination: exact, range or any • exact value: 22; range: 1,1024; any port: 0 • Protocol: exact or any • exact value: 6; any protocol: 0 • Interface specification:port implicit, direction explicit: • Direction: input or output • Priority: value between 1 and 255, inclusive. 0 is invalid – indicates that the default value should be used.

  7. General Match Behavior • Two filter types: Exclusive and Non-exclusive • Exclusive filters are intended to be used with plugins that must modify, delay, replace, add or drop traffic. Actions: may be Deny/Permit and Active.Expected use: fire wall functions or active processing • Non-exclusivefilters are used when either a net packet count or “read-only” (aka monitoring) plugins are needed. Actions: Implicit Permit and Monitor.Expected use: packet counts and passive traffic monitoring • The classifier will select the highest priority matching filter (only one) from each type. • Each GM filter has a type, packet count, priority and plugin binding(s).

  8. Exact Match Classifier • Exact match of the IP 5-tuple, global priority for all filtersActions: Deny/Permit, Reserve and Active.Expected use: Identify reserved flows, used by LFS • Current 12 bit hash, MSB == Byte 0, protocol not used:hash = ((destination address: low order 2 bits of Byte 2) << 10) | (source address: low order 3 bits of Byte 2) << 7) | (source port: low order bit from Byte 1) << 6) | (destination port: low order 6 bits from Byte 1)) Exact Match Classifier: hash Hash Table Flow Table 8 Bytes hash of ip header Version H-length TOS Total length Identification Flags Fragment offset TTL Protocol Header checksum Source Address Destination Address Destination Port Source Port Hash Field widths and offsets are configurable: msr/msr_classify.h FTE: qid pkt_cnt/ref_cnt reservation fwdkey (route) handler IP data (transport header and transport data) AAL5 padding (0 - 40 bytes) CPCS-UU (0) CPCS-UU (0) Length (IP packet + LLC/SNAP) CRC (APIC calculates and sets)

  9. EM Filters *fte *hlist filter *hlist ... Classifying a Packet • general match lookup –highest priority exclusive and non-exclusive filter matching packet • exact match lookup – reserved flow entry Flow Table GM Table Matching Exact Match filter priority (Pi) filter flags (Exclusive,...) *fte *handlers[5] (N/A) pkt_cnt *filter flags (EM,...) qid (Unique id) reservation route, *handler refcnt, pktcnt Highest priority, matching exclusive filter Hash Table hash (index) *head priority(Pj) filter flags (Non-Excl,...) *fte(Null) *handlers[5] pkt_cnt *filter flags (~EM,...) ~qid ~reservation ~route, *handler refcnt, pktcnt Highest priority, matching non-exclusive filter

  10. Classifying a Packet (2) • Why use the fte for both exact match and exclusive general match? • reuse the new plugin interface codee • permits extended semantics for exclusive GM filters: useful for tests and demos • limit the number of data structures in kernel • How does it work? • After classification a packet my have one or more of the following:Exact match FTEExclusive GM entry (GME), pointer to FTENon-Exclusive GME,Route: Input port: longest prefix route Output port: route from SHIM I will discuss the queue ID and reservations separately

  11. Classifying a Packet • Basic processing steps (bufhdr references matching entries):// check for monitoring plugins/packet counters if (Non-exclusive) increment its pkt_cnt and add its actions// set packet’s buff hdr to the correct fte and actionsif (Exclusive and Exact Match) { // then set fte, prio and add action from the higher priority entry if (exclusive entry priority > global exact match priority) use the exclusive GM entry/fte else the exact match entry} else // use the valid entryfte = exclusive ? exclusive fte : exact match fte entry// set buf hdr’s fwdkey (route)if output port then get route from packet shimelse {if (~fte || prio < rt_lookup priority || invalid fte->route)route = ip_prefix_lookup(pkt)else route = fte->route}

  12. Determining the QID • There are currently 64 Datagram queues defined and 256 reserved queues. qids between 0 and 255 are for reserved flows. Datagram qids fall between 256 and 319 • Reserved queue Ids are simply the corresponding FTE’s offset within the global Flow Table which has 256 entries. • Datagram Queue Ids are calculated form the packet header’s hash value: datagram qid = hash(pkt) % 64Since the last 6 bits of the hash value are simply the low order six bits of the destination point is – the dgram queue id is equal to the this value. • All values may be set in msr_classify.h

  13. Assigning the Queue ID • If an exact match entry is used then the queue ID is the corresponding fte offset (< 256 => reserved). • If there is no valid exact match entry and no exclusive match then the datagram value is used:hash % 64 + 256 • If the exclusive entry is used currently the qid is the fte’s offset – BUT Thas May Change: Options: • use the datagram queue is calculated for each matching packet • the offset qid • let the administrator specify correct behavior

  14. IP Packet buffer IP Packet buffer Classifier/PS Data Structures qlist used by packet scheduler to implement packet queues Buffer Header *qlist *pkt ... Buffer Header *qlist *pkt *gid *fte qid rxcid, txcid flags, fwdkey plen, atmlen PS Queue Table Flow Table GM Table EM Filters Hash Table priority (Pi) filter flags (Exclusive,...) *fte *handlers[5] (N/A) pkt_cnt *filter flags (EM,...) qid (Unique id) reservation route, *handler refcnt, pktcnt qid (index) *head *fte *hlist filter Hash Table Hash Table hash (index) *head *hlist ... priority(Pj) filter flags (Non-Excl,...) *fte(Null) *handlers[5] pkt_cnt *filter flags (~EM,...) ~qid ~reservation ~route, *handler refcnt, pktcnt

  15. Communicating with the Classifier cfy [global params] cmd [cmd options] Global Parameters: (-h, -v, -w, -p) -q qid : queue ID or Filter ID, 0-255 -c ctype :classifier type, gm em; default is gm -x prio : set gem/gnm filter priority to prio Actions and Flags: -d : Drop packets matching this rule, must be a GM, Exclusive filter -o : applies to an output port, default is input port/filter -n : Non-exclusive general match filter, default is Exclusive General Match Valid Commands: null : Null or no-op command. Can be used to verify connetivity addfltr : Add filter to classifier -sa ipaddr[/width]: Source Address or Net with prefix width -sp start[,end]: Source Port number or range -da ipaddr[/width]: Destination Address or Net with prefix width -dp start[,end]: Destination Port number or range -pr n|string: Protocol, can use numeric value or string -rt [sid/]port[/sub]: Statically set the forwarding key remfltr : Remove filter: requires global parameters {ctype, prio, qid} flist : List all installed filters: {ctype|prio|qid} i.e. ctype<<24 infofid: return status and parameters for filter id fid

  16. Current Default Filter Priorities • See $SYS/msr/msr_policy.h • Filter Priorities (1 <= prio <= 255), default values: • IP Longest Prefix Match: 32 • Non-Exclusive Match: 62 • Exclusive General Match: 62 • Exact Match: 126

  17. Example Filters • At output port 4, Drop all X-Windows traffic originating in subnet 192.168.204.0 (priority 60)cfy -p 4 -x 60 -q 0 -o -d addfltr -sa 192.168.204/24 –dp 6000,7000 -pr tcp • At input port 5, count all packets sent to net 192.168.0.0/16cfy -p 5 -n -q 1 addfltr -sa 192.168.0.0/16 • At input port 6, add exact match filter that will be bound to a plugin, accept default route (it will be pinned)cfy -p 6 -c em addfltr-sa192.168.224.2/32 -sp 3245 -da 192.168.208.2/32 -dp 1020 -pr tcp • Same as above but send packet to port 7, sub-port 2cfy -p 6 -c em addfltr-sa192.168.224.2/32 -sp 3245 -da 192.168.208.2/32 -dp 1020 -pr tcp -rt 7/2

  18. More examples – extended functions • At input port 4, send all traffic from source network 192.168.216.0/24 to output port 7/0, set priority to 127cfy -p 4 -x 127 -q 0 addfltr -sa 192.168.216.0/24 -rt 7/0 • At input port 4, permit all SSH traffic, drop all other TCP trafficcfy -p 4 -q 0 -x 130 addfltr -dp 22 -pr tcpcfy -p 4 -q 1 -x 100 -d addfltr -pr tcp

More Related