Internet ArchitectureToday’s ReadingFundamental GoalFundamental Goal: SharingType of Packet Switching: DatagramsAn Age-Old DebateStopping Unwanted Traffic is HardResearch: Stopping Unwanted TrafficThe Design Goals of Internet, v1Fundamental Goal: InterconnectionThe “Curse of the Narrow Waist”Interconnection: “Gateways”Network Address TranslationNAT TraversalGoal #2: SurvivabilitySlide 16Goal #3: Heterogeneous ServicesTopic: Voice and Video over NetworksGoal #3b: Heterogeneous NetworksResearch: Network Anomaly DetectionGoal #4: Distributed ManagementNo Owner, No Responsible PartySlide 23Goal #5: Cost EffectivenessGoal #6: Ease of AttachmentGoal #7: AccountabilityWhat’s Missing?Slide 28Design Goal ShakeupSlide 30Clark’s Paper and This CourseInternet ArchitectureCPS 214(Nick Feamster)January 14, 2008Today’s Reading•Design Philosophy of the DARPA Internet Protocols. Dave Clark, 1988.•Conceptual Lessons–Design principles/priorities were designed for a certain type of network. As the Internet evolves, we feel the sting of some of these choices.Examples: Commercialization–Engineering/Realization is key to testing an idea.•Technical Lessons–Packet switching–Fate Sharing/Soft stateFundamental Goal•“technique for multiplexed utilization of existing interconnected networks”•Multiplexing (sharing)–Shared use of a single communications channel•Existing networks (interconnection)Fundamental Goal: Sharing•No connection setup•Forwarding based on destination address in packet•Efficient sharing of resourcesTradeoff: Resource management potentially more difficult.Packet SwitchingType of Packet Switching: Datagrams•Information for forwarding traffic is contained in destination address of packet•No state established ahead of time (helps fate sharing)•Basic building block•Minimal assumption about network serviceAlternatives•Circuit Switching: Signaling protocol sets up entire path out-of-band. (cf. the phone network)•Virtual Circuits: Hybrid approach. Packets carry “tags” to indicate path, forwarding over IP•Source routing: Complete route is contained in each data packetAn Age-Old Debate•Resource control, accounting, ability to “pin” paths, etc.It is held that packet switching was one of the Internet’s greatest design choices.Of course, there are constant attempts to shoehorn the best aspects of circuits into packet switching.Examples: Capabilities, MPLS, ATM, IntServ QoS, etc.Circuit SwitchingPacket Switching•Sharing of resources, soft state (good resilience properties), etc.Stopping Unwanted Traffic is HardFebruary 2000 March 2006Research: Stopping Unwanted Traffic•Datagram networks: easy for anyone to send traffic to anyone else…even if they don’t want it!Possible Defenses•Monitoring + Filtering: Detect DoS attack and install filters to drop traffic.•Capabilities: Only accept traffic that carries a “capability”cnn.com“This set of goals might seem to be nothing more than a checklist of all the desirable network features. It is important to understand that these goals are in order of importance, and an entirely different network architecture would result if the order were changed.”The Design Goals of Internet, v1•Interconnection/Multiplexing (packet switching)•Resilience/Survivability (fate sharing)•Heterogeneity–Different types of services–Different types of networks•Distributed management•Cost effectiveness•Ease of attachment•AccountabilityThese goals were prioritized for a military network. Should priorities change as the network evolves?DecreasingPriorityFundamental Goal: Interconnection•Need to interconnect many existing networks•Hide underlying technology from applications•Decisions:–Network provides minimal functionality–“Narrow waist”Tradeoff: No assumptions, no guarantees.TechnologyApplications email WWW phone...SMTP HTTP RTP...TCP UDP…IP ethernet PPP…CSMA async sonet... copper fiber radio...The “Curse of the Narrow Waist”•IP over anything, anything over IP–Has allowed for much innovation both above and below the IP layer of the stack–An IP stack gets a device on the Internet•Drawback: very difficult to make changes to IP–But…people are trying –NSF GENI project: http://www.geni.net/Interconnection: “Gateways”•Interconnect heterogeneous networks•No state about ongoing connections–Stateless packet switches•Generally, router == gateway•But, we can think of your home router/NAT as also performing the function of a gatewayHome NetworkInternet192.168.1.51192.168.1.5268.211.6.120:5087868.211.6.120:50879Network Address Translation•For outbound traffic, the gateway: –Creates a table entry for computer's local IP address and port number–Replaces the sending computer's non-routable IP address with the gateway IP address.–replaces the sending computer's source port •For inbound traffic, the gateway:–checks the destination port on the packet –rewrites the destination address and destination port those in the table and forwards traffic to local machineNAT Traversal•Problem: Machines behind NAT not globally addressable or routable. Can’t initiate inbound connections.•One solution: Simple Traversal of UDP Through NATs–STUN client contacts STUN server–STUN server tells client which IP/Port the NAT mapped it to–STUN client uses that IP/Port for call establishment/incoming messagesMore next time.Home Network 1Home Network 2Relay nodeGoal #2: Survivability•Network should continue to work, even if some devices fail, are compromised, etc.•Failures on the Abilene (Internet 2) backbone network over the course of 6 monthsThanks to Yiyi HuangHow well does the current Internet support survivability?Goal #2: Survivability•Replication–Keep state at multiple places in the network, recover when nodes crash•Fate-sharing–Acceptable to lose state information for some entity if the entity itself is lostTwo OptionsReasons for Fate Sharing•Can support arbitrarily complex failure scenarios•Engineering is easierSome reversals of this trend: NAT, Routing Control PlatformGoal #3: Heterogeneous Services•TCP/IP designed as a monolithic transport–TCP for flow control, reliable delivery–IP for forwarding•Became clear that not every type of application would need reliable, in-order delivery–Example: Voice and video over networks–Example: DNS–Why don’t these applications require reliable, in-order