Multicast 202 Broadcast Routing Deliver packets from srce to all other nodes Source duplication is inefficient: duplicate R1 duplicate creation/transmission R1 R2 R2 duplicate R3 R4 R3 R4 source in-network duplication duplication Source duplication: how does source determine recipient addresses Network Layer 4-203 1
In-network duplication Flooding: when node receives brdcst pckt, sends copy to all neighbors Problems: cycles & broadcast storm Controlled flooding: node only brdcsts pkt if it hasn t brdcst same packet before Node keeps track of pckt ids already brdcsted Or reverse path forwarding (RPF): only forward pckt if it arrived on shortest path between node and source Spanning tree No redundant packets received by any node Network Layer 4-204 Spanning Tree First construct a spanning tree Nodes forward copies only along spanning tree A A c B c B F E D F E D G (a) Broadcast initiated at A (b) Broadcast initiated at D G Network Layer 4-205 2
Spanning Tree: Creation Center node Each node sends unicast join message to center node Message forwarded until it arrives at a node already belonging to spanning tree F 1 c A 3 4 E 2 B D (a) Stepwise construction of spanning tree 5 G A B c D F E G (b) Constructed spanning tree Network Layer 4-206 Multicast Groupe: adresse IP de classe D Un hôte peut joindre un groupe Protocole pour établir les groupes (IGMP) Protocole et algorithme pour le routage Network Layer 4-207 3
IGMP IGMP (internet Group Management Protocol Entre un hôte et son routeur (multicast) Membership_query: du routeur vers tous les hôtes pour déterminer quels hôtes appartiennent à quels groupe Membership_report: des hôtes vers le routeur Membership_leave: pour quitter un groupe (optionnel) Network Layer 4-208 Multicast Routing: Problem Statement Goal: find a tree (or trees) connecting routers having local mcast group members tree: not all paths between routers used source-based: different tree from each sender to rcvrs shared-tree: same tree used by all group members Shared tree Source-based trees 4
Approaches for building mcast trees Approaches: source-based tree: one tree per source shortest path trees reverse path forwarding group-shared tree: group uses one tree minimal spanning (Steiner) center-based trees we first look at basic approaches, then specific protocols adopting these approaches Shortest Path Tree mcast forwarding tree: tree of shortest path routes from source to all receivers Dijkstra s algorithm S: source R1 2 1 R2 3 4 R3 R6 R4 5 R5 6 R7 LEGEND i router with attached group member router with no attached group member link used for forwarding, i indicates order link added by algorithm 5
Reverse Path Forwarding rely on router s knowledge of unicast shortest path from it to sender each router has simple forwarding behavior: if (mcast datagram received on incoming link on shortest path back to center) then flood datagram onto all outgoing links else ignore datagram Reverse Path Forwarding: example S: source LEGEND R1 R4 router with attached group member R2 router with no attached R5 group member R3 datagram will be R6 R7 forwarded datagram will not be forwarded result is a source-specific reverse SPT may be a bad choice with asymmetric links 6
Reverse Path Forwarding: pruning forwarding tree contains subtrees with no mcast group members no need to forward datagrams down subtree prune msgs sent upstream by router with no downstream group members S: source R1 R2 R3 R6 R4 P R5 P R7 LEGEND P router with attached group member router with no attached group member prune message links with multicast forwarding Shared-Tree: Steiner Tree Steiner Tree: minimum cost tree connecting all routers with attached group members problem is NP-complete excellent heuristics exists not used in practice: computational complexity information about entire network needed monolithic: rerun whenever a router needs to join/leave 7
Center-based trees single delivery tree shared by all one router identified as center of tree to join: edge router sends unicast join-msg addressed to center router join-msg processed by intermediate routers and forwarded towards center join-msg either hits existing tree branch for this center, or arrives at center path taken by join-msg becomes new branch of tree for this router Center-based trees: an example Suppose R6 chosen as center: LEGEND R3 R2 R1 1 3 R6 R4 2 R5 R7 1 router with attached group member router with no attached group member path order in which join messages generated 8
Internet Multicasting Routing: DVMRP DVMRP: distance vector multicast routing protocol, RFC1075 flood and prune: reverse path forwarding, source-based tree RPF tree based on DVMRP s own routing tables constructed by communicating DVMRP routers no assumptions about underlying unicast initial datagram to mcast group flooded everywhere via RPF routers not wanting group: send upstream prune msgs DVMRP: continued soft state: DVMRP router periodically (1 min.) forgets branches are pruned: mcast data again flows down unpruned branch downstream router: reprune or else continue to receive data routers can quickly regraft to tree following IGMP join at leaf odds and ends commonly implemented in commercial routers Mbone routing done using DVMRP 9
Tunneling Q: How to connect islands of multicast routers in a sea of unicast routers? physical topology logical topology mcast datagram encapsulated inside normal (non-multicast-addressed) datagram normal IP datagram sent thru tunnel via regular IP unicast to receiving mcast router receiving mcast router unencapsulates to get mcast datagram PIM: Protocol Independent Multicast not dependent on any specific underlying unicast routing algorithm (works with all) two different multicast distribution scenarios : Dense: group members densely packed, in close proximity. bandwidth more plentiful Sparse: # networks with group members small wrt # interconnected networks group members widely dispersed bandwidth not plentiful 10
Consequences of Sparse-Dense Dichotomy: Dense Sparse: group membership by no membership until routers assumed until routers explicitly join routers explicitly prune receiver- driven data-driven construction construction of mcast on mcast tree (e.g., RPF) tree (e.g., center-based) bandwidth and nongroup-router processing router processing bandwidth and non-group- profligate conservative PIM- Dense Mode flood-and-prune RPF, similar to DVMRP but underlying unicast protocol provides RPF info for incoming datagram less complicated (less efficient) downstream flood than DVMRP reduces reliance on underlying routing algorithm has protocol mechanism for router to detect it is a leafnode router 11
PIM - Sparse Mode center-based approach router sends join msg to rendezvous point (RP) intermediate routers update state and forward join after joining via RP, router can switch to source-specific tree increased performance: less concentration, shorter paths R3 R2 R1 join join R6 all data multicast from rendezvous point join R4 R5 R7 rendezvous point PIM - Sparse Mode sender(s): unicast data to RP, which distributes down RP-rooted tree RP can extend mcast tree upstream to source RP can send stop msg if no attached receivers no one is listening! R3 R2 R1 join join R6 all data multicast from rendezvous point join R4 R5 R7 rendezvous point 12
Multicast Géré par les routeurs Pas de garantie Importance du ttl (Évaluation) Local:0 Sous-réseau local:1 Pays:48 Continent:64 Le monde:255 Network Layer 4-226 Multicast Un groupe est identifié par une adresse IP (classe D) entre 224.0.0.0 et 239.255.255.255 Une adresse multicast peut avoir un nom Exemple ntp.mcast.net 224.0.1.1 Network Layer 4-227 13
Sockets multicast Extension de DatagramSocket public class MulticastSocket extends DatagramSocket Principe: Créer une MulticastSocket Rejoindre un group: joingroup() Créer DatagramPacket Receive() leavegroup() Close() M2 internet H. Fauconnier 228 Création try { MulticastSocket ms = new MulticastSocket( ); // send datagrams... }catch (SocketException se){system.err.println(se);} ------- try { SocketAddress address = new InetSocketAddress("192.168.254.32", 4000); MulticastSocket ms = new MulticastSocket(address); // receive datagrams... }catch (SocketException ex) {System.err.println(ex);} M2 internet H. Fauconnier 229 14
Création try { MulticastSocket ms = new MulticastSocket(null); ms.setreuseaddress(false); SocketAddress address = new InetSocketAddress(4000); ms.bind(address); // receive datagrams... }catch (SocketException ex) { System.err.println(ex);} M2 internet H. Fauconnier 230 Rejoindre try { MulticastSocket ms = new MulticastSocket(4000); InetAddress ia = InetAddress.getByName("224.2.2.2"); ms.joingroup(ia); byte[] buffer = new byte[8192]; while (true) { DatagramPacket dp = new DatagramPacket(buffer, buffer.length); ms.receive(dp); String s = new String(dp.getData( ), "8859_1"); System.out.println(s); } }catch (IOException ex) { System.err.println(ex);} M2 internet H. Fauconnier 231 15
send try { InetAddress ia = InetAddress.getByName("experiment.mcast.net"); byte[] data = "un packet \r\n".getbytes( ); int port = 4000; DatagramPacket dp = new DatagramPacket(data, data.length, ia, port); MulticastSocket ms = new MulticastSocket( ); ms.send(dp,64); }catch (IOException ex) {System.err.println(ex);} M2 internet H. Fauconnier 232 Chapter 2 Application Layer Http Thanks and enjoy! JFK/KWR All material copyright 1996-2005 J.F Kurose and K.W. Ross, All Rights Reserved Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. 2: Application Layer 233 16
Chapter 2: Application layer 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server 2: Application Layer 234 Chapter 2: Application Layer Our goals: conceptual, implementation aspects of network application protocols transport-layer service models client-server paradigm peer-to-peer paradigm learn about protocols by examining popular application-level protocols HTTP FTP SMTP / POP3 / IMAP DNS programming network applications socket API 2: Application Layer 235 17
Some network apps E-mail Web Instant messaging Remote login P2P file sharing Multi-user network games Streaming stored video clips Internet telephone Real-time video conference Massive parallel computing 2: Application Layer 236 Creating a network app Write programs that run on different end systems and communicate over a network. e.g., Web: Web server software communicates with browser software application transport network data link physical application transport network data link physical application transport network data link physical 2: Application Layer 237 18
Chapter 2: Application layer 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server 2: Application Layer 238 Application architectures Client-server Peer-to-peer (P2P) Hybrid of client-server and P2P 2: Application Layer 239 19
Client-server architecture server: always-on host permanent IP address server farms for scaling clients: communicate with server may be intermittently connected may have dynamic IP addresses do not communicate directly with each other 2: Application Layer 240 Pure P2P architecture no always-on server arbitrary end systems directly communicate peers are intermittently connected and change IP addresses example: Gnutella Highly scalable But difficult to manage 2: Application Layer 241 20
Hybrid of client-server and P2P Napster File transfer P2P File search centralized: Peers register content at central server Peers query same central server to locate content Instant messaging Chatting between two users is P2P Presence detection/location centralized: User registers its IP address with central server when it comes online User contacts central server to find IP addresses of buddies 2: Application Layer 242 Processes communicating Process: program running within a host. within same host, two processes communicate using inter-process communication (defined by OS). processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted Note: applications with P2P architectures have client processes & server processes 2: Application Layer 243 21
Sockets process sends/receives messages to/from its socket socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process host or server process socket TCP with buffers, variables controlled by app developer controlled by OS Internet host or server process socket TCP with buffers, variables API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) 2: Application Layer 244 Addressing processes For a process to receive messages, it must have an identifier A host has a unique32- bit IP address Q: does the IP address of the host on which the process runs suffice for identifying the process? Answer: No, many processes can be running on same host Identifier includes both the IP address and port numbers associated with the process on the host. Example port numbers: HTTP server: 80 Mail server: 25 2: Application Layer 245 22
App-layer protocol defines Types of messages exchanged, e.g., request & response messages Syntax of message types: what fields in messages & how fields are delineated Semantics of the fields, i.e., meaning of information in fields Rules for when and how processes send & respond to messages Public-domain protocols: defined in RFCs allows for interoperability e.g., HTTP, SMTP Proprietary protocols: e.g., KaZaA 2: Application Layer 246 What transport service does an app need? Data loss some apps (e.g., audio) can tolerate some loss other apps (e.g., file transfer, telnet) require 100% reliable data transfer Timing some apps (e.g., Internet telephony, interactive games) require low delay to be effective Bandwidth some apps (e.g., multimedia) require minimum amount of bandwidth to be effective other apps ( elastic apps ) make use of whatever bandwidth they get 2: Application Layer 247 23
Transport service requirements of common apps Application Data loss Bandwidth Time Sensitive file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5mbps same as above few kbps up elastic no no no yes, 100 s msec yes, few secs yes, 100 s msec yes and no 2: Application Layer 248 Internet transport protocols services TCP service: connection-oriented: setup required between client and server processes reliable transport between sending and receiving process flow control: sender won t overwhelm receiver congestion control: throttle sender when network overloaded does not provide: timing, minimum bandwidth guarantees UDP service: unreliable data transfer between sending and receiving process does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: why bother? Why is there a UDP? 2: Application Layer 249 24
Internet apps: application, transport protocols Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Vonage,Dialpad) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP 2: Application Layer 250 Chapter 2: Application layer 2.1 Principles of network applications app architectures app requirements 2.2 Web and HTTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server 2: Application Layer 251 25
Web and HTTP First some jargon Web page consists of objects Object can be HTML file, JPEG image, Java applet, audio file, Web page consists of base HTML-file which includes several referenced objects Each object is addressable by a URL Example URL: www.someschool.edu/somedept/pic.gif host name path name 2: Application Layer 252 HTTP overview HTTP: hypertext transfer protocol Web s application layer protocol client/server model client: browser that requests, receives, displays Web objects server: Web server sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC running Explorer Mac running Navigator HTTP request HTTP response HTTP request HTTP response Server running Apache Web server 2: Application Layer 253 26
HTTP overview (continued) Uses TCP: client initiates TCP connection (creates socket) to server, port 80 server accepts TCP connection from client HTTP messages (applicationlayer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) TCP connection closed HTTP is stateless server maintains no information about past client requests aside Protocols that maintain state are complex! past history (state) must be maintained if server/client crashes, their views of state may be inconsistent, must be reconciled 2: Application Layer 254 HTTP connections Nonpersistent HTTP At most one object is sent over a TCP connection. HTTP/1.0 uses nonpersistent HTTP Persistent HTTP Multiple objects can be sent over single TCP connection between client and server. HTTP/1.1 uses persistent connections in default mode 2: Application Layer 255 27
Nonpersistent HTTP Suppose user enters URL www.someschool.edu/ somedepartment/home.index (contains text, references to 10 jpeg images) 1a. HTTP client initiates TCP connection to HTTP server (process) at www.someschool.edu on port 80 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object somedepartment/home.index 1b. HTTP server at host www.someschool.edu waiting for TCP connection at port 80. accepts connection, notifying client 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time 2: Application Layer 256 Nonpersistent HTTP (cont.) time 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4. HTTP server closes TCP connection. 2: Application Layer 257 28
Response time modeling Definition of RRT: time to send a small packet to travel from client to server and back. Response time: one RTT to initiate TCP connection one RTT for HTTP request and first few bytes of HTTP response to return file transmission time total = 2RTT+transmit time initiate TCP connection RTT request file RTT file received time time time to transmit file 2: Application Layer 258 Persistent HTTP Nonpersistent HTTP issues: requires 2 RTTs per object OS overhead for each TCP connection browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP server leaves connection open after sending response subsequent HTTP messages between same client/server sent over open connection Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1 client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects 2: Application Layer 259 29
HTTP request message two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) header lines GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr Carriage return, line feed indicates end of message (extra carriage return, line feed) 2: Application Layer 260 30