1 / 22

CLayer: Cross-Layer Packet Classification with Explicit Coordination

Implementing a novel cross-layer classification approach, CLayer enhances packet classification performance with explicit coordination between entities. Authored by Mosharaf Chowdhury, Sameer Agarwal, Dilip Joseph, and Ion Stoica.

newtonl
Télécharger la présentation

CLayer: Cross-Layer Packet Classification with Explicit Coordination

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. CLayer Packet classification with explicit coordination Mosharaf Chowdhurywith Sameer Agarwal, Dilip Joseph, and Ion Stoica

  2. Motivation Packet classification is everywhere INTERNET Google GRAD CS Forum @ Mountainview

  3. Problems 1 Existing approaches are point solutions for specific layer/service Packet classification is expensive • Computation and memory requirements • Power hungry Configuration complexity • Lack of coordination between entities involved Semantic gap 3 2 4 5 Google GRAD CS Forum @ Mountainview

  4. Solution CLayer is a cross-layer classification primitive • Generic mechanism to configure and implement capability-driven classification offloading • Explicit coordination between classifiers and helpers Label-based per-flow classification • Labels are verifiable, confidential, and non-transferable “Classify once, verify thereafter” Google GRAD CS Forum @ Mountainview

  5. Outline CLayer classification model Fate-carrying labels (FCLs) Implementation Results Google GRAD CS Forum @ Mountainview

  6. Classification model Google GRAD CS Forum @ Mountainview

  7. QoS:q1 Capability TCPFLow, WebSess ClassReq Control plane ClassReq QoS:q1, WebSess:1 2b ClassRsp QoS:q1, WebSess:1 1 2a Web server 1 QoS enabled router Load balancer End host A Web server 2 3 Google GRAD CS Forum @ Mountainview

  8. Data plane 4b 4a Web server 1 QoS:q1, WebSess:1 QoS:q1, WebSess:1 Payload Payload QoS enabled router Load balancer End host A Web server 2 Google GRAD CS Forum @ Mountainview

  9. Fate-carrying labels Google GRAD CS Forum @ Mountainview

  10. FCL basics A label in CLayer is an opaque bag of bits • Issued by a classifier for a particular flow • Meaningful only to the issuer • ‹label→action› lookup A fate-carrying label carries the action itself • No ‹label→action› lookup • No states in classifiers Google GRAD CS Forum @ Mountainview

  11. Requirements Authenticity and Integrity • Verifiable and non-transferable • Unforgeable and single-use only Confidentiality • Impossible to infer Performance • Not better off without CLayer HMAC Checksum Obfuscation Periodic Invalidation Line-speed hashing Low overhead Google GRAD CS Forum @ Mountainview

  12. Placement Application Layer 4 Bits 8 Bits 32 Bits Transport Layer RESIG CLayer N HANDLE MSG Network Layer INFO 0 … INFO (N – 1) 4 Bits 32 Bits 16 Bits CLayer Header TYPE ID LEN CHECKSUM ACTION HMAC (5-tuple, ACTION, SECRET) FCL Google GRAD CS Forum @ Mountainview

  13. Implementation Google GRAD CS Forum @ Mountainview

  14. Implementation stats C++ Implementation using user level Click software router Core components: • CLayer socket library and daemon (4025 lines) • Layer 4 firewall (308 lines) • Layer 4 load balancer (190 lines) Ported applications: • lighttpd, httperf, wget, nuttcp, elinks (< 50 lines) Google GRAD CS Forum @ Mountainview

  15. Results Google GRAD CS Forum @ Mountainview

  16. Overheads CLayer overheads at helpers: • State: ~10 bytes per connection • Processing: less than 1 μs At classifiers: • No state overheads • Processing: varies in s/w and h/w implementations Per-packet overheads: • Proportional to the number of labels • Potential bottleneck Google GRAD CS Forum @ Mountainview

  17. Performance attractiveness threshold Google GRAD CS Forum @ Mountainview

  18. Multiple classifiers hash overhead software implementation overhead (Each with 7500 rules) Google GRAD CS Forum @ Mountainview

  19. Summary Packet classification requires a dedicated layer CLayer provides significant performance gain • 2-4 times increase in classifier throughput • Additional ~100% increase in throughput in trusted domains or with line-speed h/w hashing CLayer adoption requires minimal change • Most suitable for controlled environments like data center and enterprise networks Google GRAD CS Forum @ Mountainview

  20. Questions ? ? ? Google GRAD CS Forum @ Mountainview

  21. Backup Google GRAD CS Forum @ Mountainview

  22. Router E End host B End host A CLayer handshaking 2 CL_SYN CL_SYN 1 Capability: [A,TCPFlow,Label] Capability: [A,TCPFlow,Label] ClassReq: [E, A, TCPFlow,Label:q1] 3 4 CL_SYNACK CL_SYNACK Control Plane Capability: [B,TCPFlow,Label] Capability: [B,TCPFlow,Label] EchoReq: [E, A, TCPFlow,Label:q1] EchoReq: [E, A, TCPFlow,Label:q1] ClassReq: [E, B, TCPFlow,Label:q2] CL_ACK1 6 5 CL_ACK1 EchoReq: [E, B, TCPFlow,Label:q2] EchoReq: [E, B, TCPFlow,Label:q2] Results: [E, TCPFlow,Label:q1] Results: [E, TCPFlow,Label:q1] 7 8 CL_ACK2 CL_ACK2 Results: [E, TCPFlow,Label:q2] Results: [E, TCPFlow,Label:q2] DATA DATA Results: [E, TCPFlow,Label:q1] Results: [E, TCPFlow,Label:q2] Data Plane Google GRAD CS Forum @ Mountainview

More Related