Transcript presentation source

NECP: the
Network Element
Control Protocol
IETF WREC Working Group
November 11, 1999
where is NECP needed?
Note that a Server usually knows
what it wants, but the Switch
is feeding it the packets
Internet
(Large Backbone ISP)
Router
L4 Switch
Servers
(Origin Servers,
Proxy Caches,
etc.)
ISP User
Network
(load balancing,
or intercepting for
transparent proxies)
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
• Minimal
• Assumes per-flow state available on switch
• Extensible load metrics
• Authentication
non-features
• Specific load balancing policies
• IP addresses of friendly servers/caches
• Configuration management
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?