NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.
-
Upload
ralph-fitzgerald -
Category
Documents
-
view
212 -
download
0
Transcript of NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.
NECP: theNetwork ElementControl Protocol
IETF WREC Working Group
November 11, 1999
where is NECP needed?
ISP UserNetwork
Servers(Origin Servers,Proxy Caches,
etc.)
Router
L4 Switch(load balancing,or intercepting fortransparent proxies)
Note that a Server usually knowswhat it wants, but the Switch
is feeding it the packetsInternet
(Large Backbone ISP)
the role of NECP
Servers(load balanced groups,
transparent proxies)
L4 Switch
NECP allows the cache and switch to exchange control traffic
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)
key features
• Specific load balancing policies
• IP addresses of friendly servers/caches
• Configuration management
• Minimal
• Assumes per-flow state available on switch
• Extensible load metrics
• Authentication
non-features
Backup
Slides
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
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
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
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?