NECP: the Network Element Control Protocol

1
NECP theNetwork ElementControl Protocol

• IETF WREC Working Group
• November 11, 1999

2
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

non-features

• Specific load balancing policies
• IP addresses of friendly servers/caches
• Configuration management

6
Backup Slides
7
udp (or snmp)why not use it?

• Initially, SNMP seemed perfect to us -- its a
  generic way for net devices to interoperate
• But, we found ourselves redesigning things that
  were already in TCP. We use TCPs
• 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 doesnt 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?