NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

10
NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999

Transcript of NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

Page 1: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

NECP: theNetwork ElementControl Protocol

IETF WREC Working Group

November 11, 1999

Page 2: NECP: the Network Element Control 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)

Page 3: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

the role of NECP

Servers(load balanced groups,

transparent proxies)

L4 Switch

NECP allows the cache and switch to exchange control traffic

Page 4: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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)

Page 5: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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

Page 6: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

Backup

Slides

Page 7: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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

Page 8: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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

Page 9: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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

Page 10: NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999.

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?