Computer Networks Lecture #4 PDF

Computer Networks Lecture #4 In the last lecture IP - the Internet Protocol Datagram format Addressing Network address translation & IPv6 Today Generalized forwarding, SDN Match + action OpenFlow: match + action in action Middleboxes Generalized forwarding, SDN recap: G...

Computer Networks Lecture #4 In the last lecture IP - the Internet Protocol Datagram format Addressing Network address translation & IPv6 Today Generalized forwarding, SDN Match + action OpenFlow: match + action in action Middleboxes Generalized forwarding, SDN recap: Generalized forwarding Each router contains a forwarding table (aka: ow table) “match plus action” abstraction Match bits in arriving packet, take action Generalized forwarding Many header elds can determine action Many actions possible : drop / copy / modify / log packet fi fl Flow table abstraction Flow: de ned by header eld values (in link-, network-, transport-layer elds) Generalized forwarding: simple packet-handling rules match - pattern values in packet header elds actions - for matched packet, drop/forward/modify matched packet or send matched packet to controller priority - disambiguate overlapping patterns counter - # of bytes, # of packets Router’s ow table de ne router’s match+ac on rules 4 1 3 2 fl fi ti fi fi fi fi Flow table abstraction Flow: de ned by header eld values (in link-, network-, transport-layer elds) Generalized forwarding: simple packet-handling rules match - pattern values in packet header elds actions - for matched packet, drop/forward/modify matched packet or send matched packet to controller priority - disambiguate overlapping patterns counter - # of bytes, # of packets 4 1 3 2 fi fi fi fi OpenFlow: flow table entry OpenFlow: example OpenFlow: example OpenFlow abstraction match+action abstraction - Abstraction uni es di erent kinds of devices Router match: longest destination IP pre x, action: forward out a link Switch match: destination mac address, action: forward or ood Firewall match: IP addresses and TCP/UDP port numbers, action: permit or deny NAT match: IP address and port, action: rewrite address and port fi fi fl ff OpenFlow example Orchestrated table can create network-wide behavior e.g., datagram from host h5 and h6 should be sent to h3 or h4, via s1 and from there to s2 OpenFlow example Orchestrated table can create network-wide behavior e.g., datagram from host h5 and h6 should be sent to h3 or h4, via s1 and from there to s2 Summary: generalized forwarding “match plus action” abstraction: match bits in arriving packet headers (in any layers), take action Matching over many elds (link-, network-, transport-layer) Local actions: drop, forward, modify, or send matched packet to controller Allows to “program” network-wide behaviors Simple form of “network programmability” Programmable, per-packet “processing” historical roots: active networking today: more generalized forwarding, P4 (see p4.org) fi Middleboxes Middleboxes Middleboxes everywhere! Middleboxes Initially: proprietary (closed) hardware solutions Move toward “whitebox” hardware implementing open API Move away from proprietary hardware solutions Programmable local actions via match+action Move toward innovation/di erentiation in software SDN: (logically) centralized control and con guration management often in public/private cloud Network Function Virtualization (NFV) Programmable services over whitebox networking, computation, storage ff fi Middlebox example: SDN & NFV The IP hourglass The IP hourglass Architectural principle of the Internet RFC 1958 says “… many members of the Internet community would argue that there is no architecture, but only a tradition, which was not written down for the rst 25 years (or at least not by IAB). However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end-to- end rather than hidden in the network.” Three cornerstone beliefs Simple connectivity IP protocol: that narrow waist Intelligence & complexity at the network edge fi End-to-end argument “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) We call this line of reasoning against low-level function implementation the “end-to-end argument.” Saltzer, Reed, Clark 1981 End-to-end argument “If a function can only be correctly implemented end-to-end, it must be implemented in the end systems. Implementing it in the network can, at best, only be an optimization.” End-to-end argument Some network functionality (e.g., reliable data transfer, congestion control) can be implemented in network, or at network edge. Where’s the intelligence? The last question How are forwarding tables (in destination-based forwarding) or ow table (in generalized forwarding) computed? “The answer will be discussed in the next class” fl Questions?