1 / 10

NECP: the Network Element Control Protocol

NECP: the Network Element Control Protocol. IETF WREC Working Group November 11, 1999. Internet (Large Backbone ISP). Servers (Origin Servers, Proxy Caches, etc.). ISP User Network. where is NECP needed?. Note that a Server usually knows what it wants, but the Switch

druggieri
Télécharger la présentation

NECP: the Network Element Control Protocol

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. NECP: theNetwork ElementControl Protocol IETF WREC Working Group November 11, 1999

  2. Internet (Large Backbone ISP) Servers (Origin Servers, Proxy Caches, etc.) ISP User Network where is NECP needed? Note that a Server usually knows what it wants, but the Switch is feeding it the packets Router L4 Switch (load balancing, or intercepting for transparent proxies)

  3. the role of NECP Servers (load balanced groups, transparent proxies) L4 Switch NECP allows the cache and switch to exchange control traffic

  4. what control traffic? • When servers come up, they can tell the switch: “add me to your group for Service X” • Servers can send load information; switch does better balancing • Switches immediately stop sending work to dead servers using periodic KEEPALIVEs • Transparent Proxy Caches can tell switches to allow direct connections for certain clients (e.g., on auth failure)

  5. key features • Minimal • Assumes per-flow state available on switch • Extensible load metrics • Authentication • Specific load balancing policies • IP addresses of friendly servers/caches • Configuration management non-features

  6. Backup Slides

  7. udp (or snmp):why not use it? • Initially, SNMP seemed perfect to us -- it’s a generic way for net devices to interoperate • But, we found ourselves redesigning things that were already in TCP. We use TCP’s: • stream demultiplexing • retransmission policy • segmentation & reassembly of large messages • flow control • congestion control • Like BGP, or ICP

  8. NAT and GRE • Earlier versions of the protocol include complex NAT queries in case the original IP dest addr was lost. • Why not encapsulate? • Generic Routing Encapsulation to tunnel application packets from proxy to cache • Now - no NAT problems; reduces complexity of design and implementation

  9. authentication • Both sides share a secret (say, a password) • Sender: • appends the secret to its message • calculates an SHA-1 hash • replaces the secret with the SHA-1 • Receiver: • Saves the SHA-1 • Replaces the SHA-1 with the secret • Calculates the SHA-1 (should match) • Sequence numbers to prevent replay attacks • Note: this is authentication, not encryption

  10. redirection semantics • If a server asks a switch to change its forwarding state (e.g., stop forwarding a dest port number), do existing flows break? • Do we add a “stop giving me dest port X, except for the following ethereal ports” command? (Complex; doesn’t work for start) • Ostrich Algorithm: let the connections break? • Do we assume that all switches keep per-flow state, and can redirect new connections without breaking old ones?

More Related