Computer Networks Lecture #7 PDF
Document Details
Uploaded by CuteWatermelonTourmaline
Kangwon National University
Tags
Summary
This document is a lecture on computer networks, focusing on Software Defined Networking (SDN), internet control message protocol (ICMP), and network management. The lecture covers topics such as routing protocols and other network concepts.
Full Transcript
Computer Networks Lecture #7 In the last lecture Introduction to routing protocol in practice, Intra-ISP routing (OSPF) Routing among ISPs: BGP Today Control plane in SDN Internet Control Message Protocol (ICMP) Network management & con guration Simple Network Management Protocol (SN...
Computer Networks Lecture #7 In the last lecture Introduction to routing protocol in practice, Intra-ISP routing (OSPF) Routing among ISPs: BGP Today Control plane in SDN Internet Control Message Protocol (ICMP) Network management & con guration Simple Network Management Protocol (SNMP) Netconf / Yang fi Control plane in SDN Software Defined Networking (SDN) Internet network layer Historically implemented via distributed, per-router control approach Monolithic router Contains switching hardware Runs proprietary implementation of Internet standard protocol (IP, RIP, IS-IS, OSPF, BGP) in proprietary router OS (e.g, Cisco IOS) Di erent “middleboxes” for di erent network layer functions (e.g., rewall, load balancer, NAT boxes, etc.) ~ 2005 Renewed interest in rethinking network control plane ff ff fi Recap: per-router control plane Individual routing algorithm components in each and every router interact in the control plane, in order to computer forwarding tables Recap: SDN control plane Remote controller computes, installs forwarding tables in routers Software Defined Networking (SDN) Why do people think of a logically centralized control plane? Easier network management avoid router miscon gurations, greater exibility of tra c ows Table-based forwarding (recall OpenFlow API) allows “programmable” routers Centralized programming is easier - routing tables are computed in a centralized manner and then distributed Distributed programming is more di cult - compute tables as a result of distributed algorithm (protocol) implemented in each and every router Open (non-proprietary) implementation of control plane Foster innovation: let 1000 ows bloom fi fl ffi fl ffi fl SDN analogy: mainframe to PC revolution - Vertically integrated, - Horizontal closed, proprietary - Open interface - Slow innovation - Rapid innovation - Small industry - Huge industry Traffic engineering Di cult with traditional routing Q1) What if network operator wants u-to-z tra c to ow along the path u,v,w,z, rather than u,x,y,z? A1) need to rede ne link weight, so the routing algorithm computes route accordingly (or need a new routing algorithm!) Link weights are the only control knobs! ⇒ Not much control ffi fi ffi fl Traffic engineering Di cult with traditional routing Q2) What if network operator wants to split u-to-z tra c to ow along the paths u,v,w,z, and u,x,y,z (for load balancing) ? A2) can’t do it! (or a new routing algorithm is needed) Link weights are the only control knobs! ⇒ Not much control ffi ffi fl Traffic engineering Di cult with traditional routing Q2) What if w wants to route blue and red tra c di erently from w to z? A2) can’t do it! (with destination-based forwarding, and LS/DV routing) However, SDN can be used to any routing desired ffi ffi ff Software Defined Networking (SDN) Data plane switches in SDN Fast, simple, commodity switches implementing generalized data-plane forwarding in hardware Flow (forwarding) table computed, installed under controlled supervision API for table-based switch control (e.g., OpenFlow) De nes what is controllable, what is not Protocol for communicating with controller (e.g., OpenFlow) fi SDN controller (network OS) Maintains network state information Interacts with network control applications above via northbound API Interacts with network switches below via southbound API Implemented as distributed system for performance, scalability, fault-tolerance, robustness Network-control apps “Brain” of control Implements control function using lower-level services, API provided by SDN controller Unbundled Can be provided by 3rd party Distinct from routing vendor, or SDN controller Components of SDN controller OpenFlow protocol Operates between controller and switches TCP is used to exchange messages Optional encryption Three classes of OpenFlow messages Controller-to-switch Asynchronous (switch-to-controller) Symmetric (misc.) Distinct from OpenFlow API API is used to specify generalized forwarding actions Controller-to-switch messages Key controller-to-switch messages features : controller asks the switch about which feature it supports con gure : controller queries/sets switch con guration parameters modify-state : add, delete, modify ow entries in the OpenFlow tables packet-out : controller can send this packet out of a speci c switch port (topology discovery) read-state : collect statistics (counters) … fi fi fi fl Switch-to-controller messages Key switch-to-controller messages packet-in : transfer packet (and its controller) to controller ow-removed : ow table entry is deleted at switch port-status : inform controller of a change on a port error : error message from switch … Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead, use higher-level abstraction at controller fl fl Control/data plane interaction example Control/data plane interaction example OpenDayLight (ODL) controller ONOS controller Selected challenge in SDN Hardening the control plane: Dependable, reliable, performance-scalable, secure distributed system Robustness to failure: leverage strong theory of reliable distributed system for control plane Dependability, security: “baked in” from day one? Networks, protocols meeting mission-speci c requirements e.g., real-time, ultra-reliable, ultra-secure Internet-scaling: beyond a single AS SDN critical in 5G cellular networks fi SDN and the future of traditional network protocols SDN-computed vs. router-computed forwarding tables Just one example of logically-centralized-computed vs. protocol computed One could imagine SDN-computed congestion control Controller sets sender rates based on router reported (to controller) congestion level Internet Control Message Protocol (ICMP) ICMP Used by hosts & routers to communicate network- level information Error reporting (unreachable host, network, port, protocol) Echo request/reply (used by ping) Network layer “above” IP ICMP messages carried in IP datagram ICMP message Type, code, plus header, and rst 8 bytes of IP datagram causing error fi ICMP messages ICMP messages are identi ed by a combination of type and code fi ICMP messages Examples of ICMP message format Destination unreachable Time exceeded Source quench (not used) Bad parameters (redirection) ICMP messages Examples of ICMP message format Echo request / reply - “Are you alive? - used to check the operation of IP protocol Timestamp request / reply - used to know the time on the other machine ICMP and trace route Source sends a set of UDP segments to destination * Stopping criteria - UDP segment eventually arrives at 1st set has TTL=1 destination host 2nd set has TTL=2 - Destination returns ICMP port unreachable message (type 3, code 3) etc. - Source stop Datagram belonging to n-th set arrives at n-th router Router discards datagram and send source ICMP message (TTL expired, type 11, code 0) ICMP message possibly includes name and IP address of the router When ICMP message arrives at source → record RTT Network management & configuration What is network management Autonomous systems (a.k.a “network”) : 1000s of interacting hardware/software components Other complex systems requiring monitoring and control Jet airplane Nuclear power plant Others Components of network management Network operator approaches to management Command Line Interface (CLI) Operator issues (types, scripts) direct to individual devices (e.g., vis ssh) SNMP/MIB Operator queries/sets devices data (MIB) using Simple Network Management Protocol (SNMP) NETCONF/YANG More abstract, network-wide, holistic Emphasis on multi-device con guration management YANG: data modeling language NETCONF: communicate YANG-compatible actions/data to/from/among remote devices fi SNMP protocol Two ways to convey MIB info, commands SNMP protocol Message types SNMP protocol Message format SNMP: Management Information Base (MIB) Managed device’s operational (and some con guration) data Gathered into device MIB module 400 MIB module de ned in RFC’s Many more vendor speci c MIBs Structure of Management Information (SMI): data de nition language Example MIB variables for UDP protocol fi fi fi fi NETCONF overview Actively manage/con gure devices network-wide Operates between managing server and managed network devices Actions: retrieve, set, modify, activate con gurations Atomic-commit actions over multiple devices Query operational data and statistics Subscribe to noti cations from devices Remote Procedure Call (RPC) paradigm NETCONF protocol messages encoded in XML Exchanged over secure, reliable transport protocol (e.g., a session based on TCP with TLS) fi fi fi NETCONF initialization, exchange, close Selected NETCONF operations Sample NETCONF RPC message YANG Data modeling language used to specify structure, syntax, semantics of NETCONF network management data Built-in data types, like SMI XML document describing device, capability can be generated from YANG description Can express constraints among data that must be satis ed by a valid NETCONF con guration Ensure NETCONF con guration to satisfy correctness, consistency constraints fi fi fi YANG example Questions?