Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Protocol is Hi to be replied by Hi Protocol is not Hi, Get lost : well until at least you are dealing with a nut Talk about packet transports, introduce packet headers, packet payload etc.
  • Talk about major hubs where you land and then take off. Point out similarity with networks
  • Give egs using services such as 1-800, call-waiting.
  • Explain distinction with the telco network here. Explain that you have services at end points. Though we now have mechanisms inside the network for QoS etc.
  • Routing implemented in network (eg for the second interpretation)
  • Give eg of voice, where the end users adjust for error correction.
  • If you want to ensure survivability then need to maintain state; this can be done either inside the network or at the end-hosts. If inside the network then we need to ensure replication of state to ensure survivability against routers or gateways. So this might not be a better option as compared to maintaining state at the end points. So if the end point dies then nothing lost.
  • At issue is the conventional understanding of the`Internet philosophy’ freedom of action user empowerment end-user responsibility for actions taken lack of control “in” the net that limit or regulate what users can do The end-end argument fostered that philosophy because they enable the freedom to innovate, install new software at will, and run applications of the users choice ” Bluementhal and Clark 2001
  • intro

    1. 1. TCOM 512 Course plan Fall 2003
    2. 2. Questions for first class? <ul><li>What is a protocol? </li></ul><ul><li>What is an API (application programming interface) ? </li></ul><ul><li>Why the concept of layering? </li></ul><ul><li>End-to-end argument </li></ul>
    3. 3. Why is communication important? <ul><li>Resource sharing: </li></ul><ul><ul><li>unique resources </li></ul></ul><ul><ul><li>location specific </li></ul></ul><ul><li>Load sharing: </li></ul><ul><ul><li>performance </li></ul></ul><ul><ul><li>economy of scale </li></ul></ul><ul><ul><li>reliability </li></ul></ul><ul><li>Information sharing: </li></ul><ul><ul><li>Communication </li></ul></ul>
    4. 4. <ul><li>Human protocol vs Computer network protocol: </li></ul><ul><li>A series of functions performed at different locations. </li></ul>What are protocols ? Hi Get lost?? TCP connection req. Hi Got the time? 2:00 TCP connection reply. Get <file> time
    5. 5. Protocols and protocol implementations <ul><li>Building blocks of a network architecture </li></ul><ul><li>Each protocol object has two different interfaces </li></ul><ul><ul><li>service interface : defines operations on this protocol </li></ul></ul><ul><ul><li>peer-to-peer interface : defines messages exchanged with peer </li></ul></ul>service interface peer interface L i+1 L i+1 L i L i
    6. 6. What is Layering? <ul><li>A technique to organize a system into a succession of logically distinct entities, such that the service provided by one entity is solely based on the service provided by the previous (lower level) entity </li></ul><ul><li>Decomposition of a complex system into an ordered series of distinct abstractions </li></ul><ul><li>Layering: </li></ul><ul><ul><li>Service: what a layer does (e.g. message delivery) </li></ul></ul><ul><ul><li>Interface: how to use the service </li></ul></ul><ul><ul><li>Protocol: how the service is implemented </li></ul></ul><ul><ul><li>Protocol stack: collection of protocols implementing a series of layers </li></ul></ul>
    7. 7. Divide and conquer Analogy: Organization of air travel <ul><li>Protocols: a series of functions performed at different locations </li></ul>Brd. pass (purchase) baggage (check) gates (load) runway takeoff airplane routing Brd. pass (complain) baggage (claim) gates (unload) runway landing airplane routing airplane routing
    8. 8. Organization of air travel: a different view <ul><li>Layers: each layer implements a service </li></ul><ul><ul><li>via its own internal-layer actions </li></ul></ul><ul><ul><li>relying on services provided by layer below </li></ul></ul>interface Brd.pass (purchase) baggage (check) gates (load) runway takeoff airplane routing Brd. pass (complain) baggage (claim) gates (unload) runway landing airplane routing airplane routing
    9. 9. Layered air travel: services Counter-to-counter delivery of person+bags baggage-claim-to-baggage-claim delivery people transfer: loading gate to arrival gate runway-to-runway delivery of plane airplane routing from source to destination Similarly, we organize computer systems into a bunch of layers! Each layer has a protocol to talk to its peer
    10. 10. Distributed implementation of layers ticket (purchase) baggage (check) gates (load) runway takeoff airplane routing ticket (complain) baggage (claim) gates (unload) runway landing airplane routing Departing airport arriving airport intermediate air traffic sites airplane routing airplane routing airplane routing
    11. 11. Encapsulation <ul><li>A layer can use only the service provided by the layer immediate below it </li></ul><ul><li>Each layer may change and add a header to data packet </li></ul>data data data data data data data data data data data data data data
    12. 12. Protocol layering and data <ul><li>Each layer takes data from above </li></ul><ul><li>adds header information to create new data unit (“encapsulation”) </li></ul><ul><li>passes new data unit to layer below </li></ul>source destination message segment datagram frame application transport network link physical application transport network link physical M M M M H t H t H n H t H n H l M M M M H t H t H n H t H n H l
    13. 13. ISO OSI Reference Model <ul><li>Seven layers </li></ul><ul><ul><li>Lower three layers are peer-to-peer </li></ul></ul><ul><ul><li>Next four layers are end-to-end </li></ul></ul>Application Presentation Session Transport Network Datalink Physical Application Presentation Session Transport Network Datalink Physical Network Datalink Physical Physical medium
    14. 14. Layering: logical communication <ul><li>E.g.: transport </li></ul><ul><li>take data from app </li></ul><ul><li>add addressing, reliability check info to form “datagram” </li></ul><ul><li>send datagram to peer </li></ul><ul><li>wait for peer to ack receipt </li></ul><ul><li>analogy: post office </li></ul>transport transport (Source: Kurose & Ross) application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical data data data ack
    15. 15. Example: Transport Protocol (Physical Communication) (Source: Kurose & Ross) application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical data data
    16. 16. Why Layering? <ul><li>No layering: each new application has to be re- implemented for every network technology! </li></ul>Telnet FTP NFS Coaxial cable Fiber optic Application Transmission Media (FTP – File Transfer Protocol, NFS – Network File Transfer, HTTP – World Wide Web protocol) Packet radio HTTP
    17. 17. Why Layering? <ul><li>Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies </li></ul>Telnet FTP NFS Coaxial cable Fiber optic Application Transmission Media Intermediate layer Packet radio HTTP
    18. 18. Layering <ul><li>Advantages </li></ul><ul><ul><li>Modularity – protocols easier to manage and maintain </li></ul></ul><ul><ul><li>Abstract functionality –lower layers can be changed without affecting the upper layers </li></ul></ul><ul><ul><li>Reuse – upper layers can reuse the functionality provided by lower layers </li></ul></ul><ul><ul><li>Encapsulation – functionality in a layer is self-contained; </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Information hiding – inefficient implementations </li></ul></ul><ul><ul><li>Introduces overhead –can lead to intentional layer violations </li></ul></ul>
    19. 19. Layered Protocol Architecture <ul><li>Protocol = rules and conventions for communication between peers including syntax, semantics, and timing </li></ul><ul><li>Service Interface = rules and conventions for communication between clients and service including syntax and timing </li></ul><ul><li>Service Model = semantics of interface operations offered by service to clients , and underlying channel characteristics (performance, reliability, etc.) </li></ul><ul><li>Recursive: service interface and model implemented internally by protocol </li></ul>
    20. 20. Protocols vs. APIs <ul><li>Protocols </li></ul><ul><ul><li>Needed for interoperability between platforms (possibly built by different vendors) </li></ul></ul><ul><ul><ul><li>A “vertical partitioning” between communicating entities </li></ul></ul></ul><ul><ul><li>Protocols as communicating finite state machines: </li></ul></ul><ul><ul><ul><li>Protocol = Finite State Machine + Message Set </li></ul></ul></ul><ul><ul><li>Specify not only what must be done but how it is done </li></ul></ul>
    21. 21. Protocols vs. APIs <ul><li>APIs </li></ul><ul><ul><li>Needed for portability of software across platforms (from different vendors) </li></ul></ul><ul><ul><ul><li>A “horizontal partitioning” of software on a platform </li></ul></ul></ul><ul><ul><li>Specify only what must be done, not how the implementation does it </li></ul></ul><ul><ul><li>Bottom-up view </li></ul></ul><ul><ul><ul><li>Coalesce related states of the protocol into objects with appropriate methods </li></ul></ul></ul><ul><ul><li>Top-down view </li></ul></ul><ul><ul><ul><li>Define objects that are logical units for the user of the API (i.e., the application or programmer) </li></ul></ul></ul><ul><ul><li>API can be defined without regard to protocols </li></ul></ul>
    22. 22. Architectural context for the API Local or Remote Access Mechanism (e.g., RMI, CORBA) Gateways Application API SIP Adapter API Implementation ISUP Adapter H.323 Adapter ...
    23. 23. APIs <ul><li>Application layer: </li></ul><ul><ul><li>JAIN JCC/JCAT, PARLAY, OSA, JTAPI </li></ul></ul><ul><ul><li>Web services : WSDL, UDDI, SOAP </li></ul></ul><ul><li>Middleware: </li></ul><ul><ul><li>CORBA, MOM, RPC, RMI </li></ul></ul><ul><li>Transport: </li></ul><ul><ul><li>Sockets, SIP API, JAIN SIP </li></ul></ul>
    24. 24. Interface Design <ul><li>Driven by three factors: </li></ul><ul><ul><li>Functionality : what features the customer wants, and is placed at a level due to e2e principle etc </li></ul></ul><ul><ul><li>Technology : what’s possible. Building blocks and techniques </li></ul></ul><ul><ul><li>Performance : How fast etc… User, Designer, Operator views of performance .. </li></ul></ul><ul><li>Interface design crucial because interface outlives the technology used to implement the interface. </li></ul>
    25. 25. Layered Protocol Architecture Local Area Network Host 1 Host 2 TELNET TCP IP LAN/MAC TELNET TCP IP LAN/MAC Protocols Interfaces
    26. 26. Layered Protocol Architecture Service view Local Area Network Host 1 Host 2 TELNET TCP IP LAN/MAC TELNET TCP IP LAN/MAC Protocols Interfaces
    27. 27. Layered Protocol Architecture Implementation <ul><li>Layered protocols, from the service point-of-view, are useful for building more complex systems out of simpler building blocks </li></ul><ul><li>… but does not imply that implementations should be strictly layered. </li></ul>
    28. 28. How do we architect a network? <ul><li>Layered model </li></ul><ul><ul><li>Lots of different problems to solve; complex </li></ul></ul><ul><ul><li>Solved it once --- why solve it again? </li></ul></ul><ul><ul><li>Three distinct aspects: </li></ul></ul><ul><ul><ul><li>Layers of encapsulation </li></ul></ul></ul><ul><ul><ul><li>Layers of services </li></ul></ul></ul><ul><ul><ul><li>Layers of software </li></ul></ul></ul><ul><li>Cultural wars: </li></ul><ul><ul><li>Computer Systems versus telecommunications </li></ul></ul><ul><ul><li>Least Common Denominator, Best characterization for optimal efficiency </li></ul></ul><ul><ul><li>packets vs. circuits, best-effort vs. reservations, </li></ul></ul>
    29. 29. Functionality placement <ul><li>Which functions belong at which layers? </li></ul><ul><ul><li>The end-to-end argument </li></ul></ul><ul><ul><li>Application layer framing (ALF) </li></ul></ul>
    30. 30. End to end argument
    31. 31. Key questions <ul><li>How to decompose the complex system functionality into protocol layers? </li></ul><ul><li>What functions to be placed at which levels? </li></ul><ul><li>Can a function be placed at multiple levels ? </li></ul>
    32. 32. Common View of the Telco Network Brick
    33. 33. Common View of the IP Network
    34. 34. End-to-End Argument <ul><li>“… functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level… ” </li></ul><ul><li>“… sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement … ” </li></ul><ul><li>This leads to a philosophy diametrically opposite to the telephone world which sports dumb end-systems (the telephone) and intelligent networks. </li></ul>
    35. 35. E2E Argument: Interpretations <ul><li>One interpretation: (limited possibly …) </li></ul><ul><ul><li>A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints </li></ul></ul><ul><li>Another: (more precise…) </li></ul><ul><ul><li>a system (or subsystem level) should consider only functions that can be completely and correctly implemented within it. </li></ul></ul><ul><li>Alternative interpretation: (also correct …) </li></ul><ul><ul><li>Think twice before implementing a functionality that you believe that is useful to an application at a lower layer </li></ul></ul><ul><ul><li>If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement </li></ul></ul>
    36. 36. Example: Reliable File Transfer <ul><li>Solution 1: make each step reliable, and then concatenate them </li></ul><ul><li>Solution 2: end-to-end check and retry </li></ul>OS Appl. OS Appl. Host A Host B OK
    37. 37. Discussion <ul><li>Solution 1 not complete </li></ul><ul><ul><li>What happens if the sender or/and receiver misbehave? </li></ul></ul><ul><li>The receiver has to do the check anyway! </li></ul><ul><li>Thus, full functionality can be entirely implemented at application layer; no need for reliability from lower layers </li></ul><ul><li>Is there any need to implement reliability at lower layers? </li></ul><ul><li>Yes, but only to improve performance </li></ul><ul><li>Example: </li></ul><ul><ul><li>assume a high error rate on communication network </li></ul></ul><ul><ul><li>then, a reliable communication service at datalink layer might help </li></ul></ul>
    38. 38. Trade-offs <ul><li>Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit) </li></ul><ul><li>A lower layer has more information about constraints in data transmission (e.g., packet size, error rate) </li></ul><ul><li>Note: these trade-offs are a direct result of layering! </li></ul>
    39. 39. End-to-End Argument: Critical Issues <ul><li>The end-to-end principle emphasizes: </li></ul><ul><ul><li>function placement </li></ul></ul><ul><ul><li>completeness and </li></ul></ul><ul><ul><li>overall system costs . </li></ul></ul><ul><li>Philosophy: if application can do it, don’t do it at a lower layer -- application best knows what it needs </li></ul><ul><ul><li>add functionality in lower layers iff (1) used by and improves performances of many applications, (2) does not hurt other applications </li></ul></ul><ul><ul><li>If implementation of function in higher levels is not possible due to technological/economic reasons (eg: telephone network in early 1900s), then it may be placed at lower levels </li></ul></ul><ul><li>allows cost-performance tradeoff </li></ul>
    40. 40. Performance Impact <ul><li>Consider reliability. Let p be the probability of losing a packet on a link </li></ul><ul><li>A n-hop path will result in (1-p)^n prob of successful delivery and prob of loss is 1-(1-p)^n </li></ul><ul><li>Assume a path with n=15 </li></ul><ul><ul><li>Let p=1e-5. Then prob(loss) = 1.5e-5 </li></ul></ul><ul><ul><li>Let p=0.01. Prob(loss) = 0.14 </li></ul></ul>
    41. 41. Internet & End-to-End Argument <ul><li>At network layer provides one simple service: best effort datagram (packet) delivery </li></ul><ul><li>Only one higher level service implemented at transport layer: reliable data delivery (TCP) </li></ul><ul><ul><li>performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP) which could provide their own error control </li></ul></ul><ul><ul><li>does not impact other applications (can use UDP) </li></ul></ul><ul><li>Everything else implemented at application level </li></ul>
    42. 42. Internet & End-to-End Argument <ul><li>Discussion: congestion control, flow control: why at transport, rather than link or application layers? </li></ul><ul><ul><li>claim: common functions should migrate down the stack </li></ul></ul><ul><ul><ul><li>Everyone shares same implementation: no need to redo it (reduces bugs, less work, etc…) </li></ul></ul></ul><ul><ul><ul><li>Knowing everyone is doing the same thing, can help </li></ul></ul></ul><ul><ul><li>congestion control too important to leave up to application/user: true but hard to police </li></ul></ul><ul><ul><ul><li>Tcp is “outside” the network; compliance is “optional” </li></ul></ul></ul><ul><ul><ul><li>We do this for fairness (but realize that people could cheat) </li></ul></ul></ul><ul><ul><li>Why flow control in tcp, not (just) in app </li></ul></ul><ul><ul><ul><li>shared tcp buffers at receiver mean want to control flow at tcp level (otherwise unfairness) </li></ul></ul></ul><ul><ul><ul><li>Shared resources is an important reason to push controlling functionality to point at which resources are shared </li></ul></ul></ul><ul><ul><li>Corollary: do active queue management (e.g., RED) in network </li></ul></ul>
    43. 43. Key Advantages <ul><li>The IP service can be implemented on top of a large variety of network technologies </li></ul><ul><li>Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is </li></ul><ul><ul><li>Robust </li></ul></ul><ul><ul><li>Scalable </li></ul></ul>
    44. 44. End-to-End Argument: Discussion <ul><li>end-end argument emphasizes correctness & completeness, not </li></ul><ul><ul><li>complexity: is complexity at edges result in a “simpler” architecture? </li></ul></ul><ul><ul><li>evolvability, ease of introduction of new functionality: ability to evolve because easier/cheaper to add new edge applications than change routers? </li></ul></ul><ul><ul><li>Technology penetration: simple network layer makes it “easier” for IP to spread everywhere </li></ul></ul>
    45. 45. Summary: End-to-End Arguments <ul><li>If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs </li></ul><ul><ul><li>add functionality in lower layers iff it is (1) used and improves performances of a large number of applications, and (2) does not hurt other applications </li></ul></ul><ul><li>Success story: Internet </li></ul>
    46. 46. Application layer framing
    47. 47. Application Layer Framing (ALF) <ul><li>Several processing bottlenecks may lie at the “ presentation ” layer which does not really exist in the TCP/IP stack </li></ul><ul><ul><li>These functions are absorbed partially in the transport layer and partly in the application layer. </li></ul></ul><ul><ul><li>Principle: the application-layer should have control of the syntax and semantics of the presentation conversions </li></ul></ul><ul><ul><li>Transport should provide only common functions </li></ul></ul><ul><li>Generalization of ALF: look for elegant ways to allow application visibility/participation in lower-level activities </li></ul><ul><ul><li>Eg: QoS – carry application intelligence to the point of QoS enforcement </li></ul></ul>
    48. 48. ALF <ul><li>A concept challenging traditional layering </li></ul><ul><li>Application needs may not be easily communicated across layers </li></ul><ul><li>Idea: Allow application to decide the frame size most convenient to it </li></ul><ul><li>Application breaks up data into suitable aggregates </li></ul><ul><li>The application data units (ADUs) may be processed by the application in any order </li></ul><ul><li>Lower layers preserve ADU boundaries </li></ul><ul><li>Application takes active role in the encapsulation of its data </li></ul><ul><ul><li>Can optimize for loss recovery via intelligent framing and fragmentation </li></ul></ul>
    49. 49. Architecture vs Implementation: ALF Principle <ul><li>Architecture: decomposition into functional modules, semantics of modules and syntax used </li></ul><ul><li>There should be no a priori requirement that the engineering design of a given system correspond to the architectural decomposition </li></ul><ul><ul><li>Eg: layering may not be most effective modularity for implementation </li></ul></ul><ul><li>Summary: </li></ul><ul><ul><li>Flexible decomposition </li></ul></ul><ul><ul><li>Defer engineering decisions to implementor. </li></ul></ul><ul><ul><li>Avoid gratuitous implementation constraints </li></ul></ul><ul><ul><li>Maximize engineering options for customization/optimization </li></ul></ul>
    50. 50. ILP: Integrated Layer Processing <ul><li>Modular functionality that is specified in layered form should not be implemented as such </li></ul><ul><li>Architecture must minimize gratuitous precedence or ordering constraints … </li></ul><ul><li>“Integrated processing loop” </li></ul><ul><ul><li>Loop over bytes in packet </li></ul></ul><ul><ul><li>Touch each byte at most once </li></ul></ul><ul><ul><li>Avoid multiple copies within memory </li></ul></ul><ul><ul><li>Massive integrated loop w/ all steps in-line </li></ul></ul>
    51. 51. System Design Rules of Thumb <ul><li>Design a system to tradeoff cheaper resources against expensive ones (for a gain) </li></ul><ul><li>When resources are cheap and abundant, waste them. Design focuses on cutting out any expensive resource that comes in the way! (eg: parallelism) </li></ul><ul><li>Apply principles like E2E and ALF to decide on right placement of functionalities in different system levels </li></ul><ul><li>Interfaces must outlive several generations of change in the components being interfaced. </li></ul><ul><ul><li>Three factors drive interface design: </li></ul></ul><ul><ul><ul><li>functionality demanded, </li></ul></ul></ul><ul><ul><ul><li>available technology, </li></ul></ul></ul><ul><ul><ul><li>performance tradeoff. </li></ul></ul></ul>
    52. 52. <ul><li>Functionality requirements can be understood by taking different views of the system (eg: designer, implementor, operator). </li></ul><ul><ul><li>Reduced functionality can result in cheaper, scalable, quickly engineered system </li></ul></ul><ul><ul><li>Placement of functionality is critical in system design </li></ul></ul><ul><li>No paradigm is going to work or functionality can be met if the available technology to implement it does not exist. </li></ul><ul><li>Performance is either relative or absolute and is usually modeled at the high level as a function from system parameters (input) to system metrics (output). </li></ul><ul><ul><li>Metrics must be design to reflect design tradeoffs. </li></ul></ul><ul><ul><li>Only sensitive parameters matter. </li></ul></ul><ul><li>Optimize the common case </li></ul><ul><ul><li>Solve 90% of the problem that matters, throw away the remaining 10% of the problem requirements! </li></ul></ul>System Design Rules of Thumb
    53. 53. Internet design philosophy
    54. 54. Internet Design Philosophy (Clark’88) <ul><li>Connect existing networks </li></ul><ul><ul><li>initially ARPANET and ARPA packet radio network </li></ul></ul><ul><li>Survivability </li></ul><ul><ul><li>ensure communication service even with network and router failures </li></ul></ul><ul><li>Support multiple types of services </li></ul><ul><li>Must accommodate a variety of networks </li></ul><ul><li>Allow distributed management </li></ul><ul><li>Allow host attachment with a low level of effort </li></ul><ul><li>Be cost effective </li></ul><ul><li>Allow resource accountability </li></ul>In order of importance: Different ordering of priorities would make a different architecture!
    55. 55. 1. Survivability <ul><li>Continue to operate even in the presence of network failures (e.g., link and router failures) </li></ul><ul><ul><li>as long as network is not partitioned, two endpoints should be able to communicate </li></ul></ul><ul><ul><li>any other failure (excepting network partition) should be transparent to endpoints </li></ul></ul><ul><li>Decision: maintain e-e transport state only at end-points </li></ul><ul><ul><li>eliminate the problem of handling state inconsistency and performing state restoration when router fails </li></ul></ul><ul><li>Internet: stateless network architecture </li></ul><ul><ul><li>No notion of a session/call at network layer </li></ul></ul><ul><ul><li>Grade: A- because convergence times are relatively slow </li></ul></ul><ul><ul><li>BGP takes minutes to coverge </li></ul></ul><ul><ul><li>IS-IS OSPF take ~ 10 seconds </li></ul></ul>
    56. 56. 2. Types of Services <ul><li>Need to support multiple types of services </li></ul><ul><ul><li>All combinations of delay, bandwidth, loss </li></ul></ul><ul><li>add UDP to TCP to better support other apps </li></ul><ul><ul><li>e.g., “real-time” applications </li></ul></ul><ul><li>arguably main reason for separating TCP, IP </li></ul><ul><li>datagram abstraction: lower common denominator on which other services can be built </li></ul><ul><ul><li>service differentiation was considered (remember ToS?), but this has never happened on the large scale (Why?) </li></ul></ul><ul><li>A- proven to allows many applications to be invented and flourish </li></ul>
    57. 57. 3. Variety of Networks <ul><li>Very successful (why?) </li></ul><ul><ul><li>because the minimalist service; it requires from underlying network only to deliver a packet with a “reasonable” probability of success </li></ul></ul><ul><li>…does not require: </li></ul><ul><ul><li>reliability </li></ul></ul><ul><ul><li>in-order delivery </li></ul></ul><ul><li>The mantra: IP over everything </li></ul><ul><ul><li>Then: ARPANET, X.25, DARPA satellite network.. </li></ul></ul><ul><ul><li>Now: ATM, SONET, WDM… </li></ul></ul><ul><li>A: can’t name a link layer technology that IP doesn’t run over (carrier pigeon RFC) </li></ul>
    58. 58. Other Goals <ul><li>Allow distributed management </li></ul><ul><ul><li>Administrative autonomy: IP interconnects networks </li></ul></ul><ul><ul><ul><li>each network can be managed by a different organization </li></ul></ul></ul><ul><ul><ul><li>different organizations need to interact only at the boundaries </li></ul></ul></ul><ul><ul><ul><li>… but this model complicates routing </li></ul></ul></ul><ul><ul><li>A for implementation, B for concept (disagreement) </li></ul></ul><ul><li>Cost effective </li></ul><ul><ul><li>sources of inefficiency </li></ul></ul><ul><ul><ul><li>header overhead </li></ul></ul></ul><ul><ul><ul><li>retransmissions </li></ul></ul></ul><ul><ul><li>… but “optimal” performance never been top priority </li></ul></ul><ul><ul><li>A </li></ul></ul>
    59. 59. Other Goals (Cont) <ul><li>Low cost of attaching a new host </li></ul><ul><ul><li>not a strong point  higher than other architecture because the intelligence is in hosts (e.g., telephone vs. computer) </li></ul></ul><ul><ul><li>bad implementations or malicious users can produce considerably harm (remember fate-sharing?) </li></ul></ul><ul><ul><li>C: but things are improving with dhcp, autocofigurations. Looks like a higher grade in future </li></ul></ul><ul><li>Accountability </li></ul><ul><ul><li>Internet gets an “F” </li></ul></ul>
    60. 60. Internet protocol stack <ul><li>application : supporting network applications </li></ul><ul><ul><li>ftp, smtp, http </li></ul></ul><ul><li>transport: host-host data transfer </li></ul><ul><ul><li>tcp, udp </li></ul></ul><ul><li>network: routing of datagrams from source to destination </li></ul><ul><ul><li>ip, routing protocols </li></ul></ul><ul><li>link: data transfer between neighboring network elements </li></ul><ul><ul><li>ppp, ethernet </li></ul></ul><ul><li>physical: bits “on the wire” </li></ul>application transport network link physical
    61. 61. Reference Models for Layering Application Transport Internetwork Host to Network FTP TCP IP Ether net Telnet HTTP UDP Packet Radio Point-to- Point TCP/IP Model OSI Ref Model TCP/IP Protocols Application Presentation Session Transport Network Datalink Physical
    62. 62. Internet (IP) Architecture <ul><li>“Hourglass” </li></ul><ul><li>Not strict layering </li></ul>TELNET FTP TFTP NTP TCP UDP IP Ethernet Wireless ArpaNet 1822 Serial
    63. 63. Internet applications <ul><li>Variations on three themes </li></ul><ul><ul><li>distinguish protocol vs. application behavior </li></ul></ul><ul><li>Messaging </li></ul><ul><ul><li>datagram model  no direct confirmation of final receipt </li></ul></ul><ul><ul><li>email (optional confirmation now) and IM </li></ul></ul><ul><ul><li>emphasis on interoperation (SMS, pagers, …) </li></ul></ul><ul><ul><li>delays measured in minutes </li></ul></ul><ul><li>Retrieval & query (request/response) </li></ul><ul><ul><li>“ client-server” </li></ul></ul><ul><ul><li>ftp, HTTP </li></ul></ul><ul><ul><li>RPC (Sun RPC, DCE, DCOM, Corba, XML-RPC, SOAP) </li></ul></ul><ul><ul><li>emphasis on fast & reliable transmission </li></ul></ul><ul><ul><li>delays measured in seconds </li></ul></ul>
    64. 64. Internet applications, cont’d <ul><li>Continuous media </li></ul><ul><ul><li>generation rate ~ delivery rate ~ rendering rate </li></ul></ul><ul><ul><li>audio, video, measurements, control </li></ul></ul><ul><ul><ul><li>Internet telephony </li></ul></ul></ul><ul><ul><ul><li>Multimedia conferencing </li></ul></ul></ul><ul><ul><li>related: streaming media  slightly longer timescales for rate matching </li></ul></ul><ul><ul><ul><li>video-on-demand </li></ul></ul></ul><ul><ul><li>emphasis is on timely and low-loss delivery  real-time </li></ul></ul><ul><ul><li>delays measured in milliseconds </li></ul></ul>
    65. 65. Internet protocols <ul><li>Protocols support these applications: </li></ul><ul><ul><li>data delivery </li></ul></ul><ul><ul><ul><li>HTTP, ftp data part, SMTP, IMAP, POP, NFS, SMB, RTP </li></ul></ul></ul><ul><ul><li>identifier mapping (id  id, id  data) </li></ul></ul><ul><ul><ul><li>ARP, DNS, LDAP </li></ul></ul></ul><ul><ul><li>configuration (= specialized version of identifier  data) </li></ul></ul><ul><ul><ul><li>DHCP, ACAP, SLP, NETCONF, SNMP </li></ul></ul></ul><ul><ul><li>control and setup </li></ul></ul><ul><ul><ul><li>RTSP, SIP, ftp control, RSVP, SNMP, BGP and routing protocols </li></ul></ul></ul><ul><li>May be integrated into one protocol or general service function (“middleware”?) </li></ul>
    66. 66. History of networking <ul><li>History of networking = non-network applications migrate </li></ul><ul><ul><li>postal & intracompany mail, fax  email, IM </li></ul></ul><ul><ul><li>broadcast: TV, radio </li></ul></ul><ul><ul><li>interactive voice/video communication  VoIP </li></ul></ul><ul><ul><li>information access  web, P2P </li></ul></ul><ul><ul><li>disk access  iSCSI, Fiberchannel-over-IP </li></ul></ul>
    67. 67. Network evolution <ul><li>Only three modes, now thoroughly explored: </li></ul><ul><ul><li>packet/cell-based </li></ul></ul><ul><ul><li>message-based (application data units) </li></ul></ul><ul><ul><li>session-based (circuits) </li></ul></ul><ul><li>Replace specialized networks </li></ul><ul><ul><li>left to do: embedded systems </li></ul></ul><ul><ul><ul><li>need cost(CPU + network) < $10 </li></ul></ul></ul><ul><ul><ul><li>cars </li></ul></ul></ul><ul><ul><ul><li>industrial (manufacturing) control </li></ul></ul></ul><ul><ul><ul><li>commercial buildings (lighting, HVAC, security; now LONworks) </li></ul></ul></ul><ul><ul><ul><li>remote controls, light switches </li></ul></ul></ul><ul><ul><ul><li>keys replaced by biometrics </li></ul></ul></ul>
    68. 68. New applications <ul><li>New bandwidth-intensive applications </li></ul><ul><ul><li>Reality-based networking </li></ul></ul><ul><ul><li>(security) cameras </li></ul></ul><ul><li>Distributed games often require only low-bandwidth control information </li></ul><ul><ul><li>current game traffic ~ VoIP </li></ul></ul><ul><li>Computation vs. storage vs. communications </li></ul><ul><ul><li>communications cost has decreased less rapidly than storage costs </li></ul></ul>
    69. 69. Transition of networking <ul><li>Maturity  cost dominates </li></ul><ul><ul><li>can get any number of bits anywhere, but at considerable cost and complexity </li></ul></ul><ul><ul><li>casually usable bit density still very low </li></ul></ul><ul><li>Specialized  commodity </li></ul><ul><ul><li>installed and run by 'amateurs' </li></ul></ul><ul><ul><li>need low complexity, high reliability </li></ul></ul>
    70. 70. Security challenges <ul><li>DOS, security attacks  permissions-based communications </li></ul><ul><ul><li>only allow modest rates without asking </li></ul></ul><ul><ul><li>effectively, back to circuit-switched </li></ul></ul><ul><li>Higher-level security services  more application-layer access via gateways, proxies, … </li></ul><ul><li>User identity </li></ul><ul><ul><li>problem is not availability, but rather over-abundance </li></ul></ul>
    71. 71. Scaling <ul><li>Scaling is only backbone problem </li></ul><ul><li>Depends on network evolution: </li></ul><ul><ul><li>continuing addition of AS to flat space  deep trouble </li></ul></ul><ul><ul><li>additional hierarchy </li></ul></ul>
    72. 72. Quality of Service (QoS) <ul><li>QoS is meaningless to users </li></ul><ul><li>care about service availability  reliability </li></ul><ul><li>as more and more value depends on network services, can't afford random downtimes </li></ul>
    73. 73. Textbook Internet vs. real Internet dominance of Ethernet, but also L2’s not designed for networks ( 1394 Firewire, Fibre Channel, MPEG2, …) multitude of L2 protocols (ATM, ARCnet, Ethernet, FDDI, modems, …) network address translation (NAT) globally unique and routable time-varying (DHCP) permanent interface identifier (IP address) middle boxes (proxies, ALGs, …) end-to-end (application only in 2 places)
    74. 74. Textbook Internet vs. real Internet layer splits 4 layers (link, network, transport, application) firewalls, L7 filters, “transparent proxies” transparent network grandma, frustrated if email doesn’t work technical users, excited about new technology Linksys, Dlink, Netgear, …, available at Radio Shack small number of manufacturers, making expensive boxes hackers, spammers, con artists, pornographers, … mostly trusted end users
    75. 75. Internet architecture documents (readings-hw) <ul><li> </li></ul><ul><li>RFC 1287 </li></ul><ul><li>RFC 2101 </li></ul><ul><li>RFC 2775 </li></ul><ul><li>RFC 3234 </li></ul>
    76. 76. The Internet Protocol Hourglass (Deering) email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio...
    77. 77. Why the hourglass architecture? <ul><li>Why an internet layer? </li></ul><ul><ul><li>make a bigger network </li></ul></ul><ul><ul><li>global addressing </li></ul></ul><ul><ul><li>virtualize network to isolate end-to-end protocols from network details/changes </li></ul></ul><ul><li>Why a single internet protocol? </li></ul><ul><ul><li>maximize interoperability </li></ul></ul><ul><ul><li>minimize number of service interfaces </li></ul></ul><ul><li>Why a narrow internet protocol? </li></ul><ul><ul><li>assumes least common network functionality to maximize number of usable networks </li></ul></ul>Deering, 1998
    78. 78. Putting on Weight email WWW phone... SMTP HTTP RTP ... TCP UDP… IP + mcast + QoS +... ethernet PPP… CSMA async sonet... copper fiber radio... <ul><li>requires more functionality from underlying networks </li></ul>
    79. 79. Mid-Life Crisis email WWW phone... SMTP HTTP RTP... TCP UDP… IP 4 IP 6 ethernet PPP… CSMA async sonet... copper fiber radio... <ul><li>doubles number of service interfaces </li></ul><ul><li>requires changes above & below </li></ul><ul><li>major interoper-ability issues </li></ul>
    80. 80. Layer splitting <ul><li>Traditionally, L2 (link), L3 (network = IP), L4 (transport = TCP), L7 (applications) </li></ul><ul><li>Layer 2: Ethernet  PPPoE (DSL) </li></ul><ul><li>Layer 2.5: MPLS, L2TP </li></ul><ul><li>Layer 3: tunneling (e.g., GPRS) </li></ul><ul><li>Layer 4: UDP + RTP </li></ul><ul><li>Layer 7: HTTP + real application </li></ul>
    81. 81. Layer violations <ul><li>Layers offer abstraction  avoid “Internet closed for renovation” </li></ul><ul><li>Cost of information hiding </li></ul><ul><li>Cost of duplication of information when nothing changes </li></ul><ul><ul><li>fundamental design choice of Internet = difference between circuit and datagram-oriented networks </li></ul></ul><ul><li>Assumption: packets are large and getting larger </li></ul><ul><ul><li>wrong for games and audio </li></ul></ul><ul><li>Cost prohibitive on wireless networks </li></ul><ul><ul><li>will see: 10 bytes of payloads, 40 bytes of packet header </li></ul></ul><ul><ul><li>header compression  compress into state index on one link </li></ul></ul>
    82. 82. Internet acquires presentation layer <ul><li>All learn about OSI 7-layer model </li></ul><ul><li>OSI: ASN.1 as common rendering of application data structures </li></ul><ul><ul><li>used in LDAP and SNMP (and H.323) </li></ul></ul><ul><li>Internet never really had presentation layer </li></ul><ul><ul><li>approximations: common encoding (TLV, RFC 822 styles) </li></ul></ul><ul><li>Now, XML as the design choice by default </li></ul>
    83. 83. Internet acquires session layer <ul><li>Originally, meant for data sessions </li></ul><ul><li>Example (not explicit): ftp control connection </li></ul><ul><li>Now, separate data delivery from session setup </li></ul><ul><ul><li>address and application configuration </li></ul></ul><ul><ul><li>deal with mobility </li></ul></ul><ul><ul><li>will see as RTSP, SIP and H.323 </li></ul></ul>
    84. 84. <ul><li>But that was yesterday </li></ul><ul><li>…… . what about tomorrow ? </li></ul>
    85. 85. What About the Future? <ul><li>Datagram not the best abstraction for: </li></ul><ul><ul><li>resource management,accountability, QoS </li></ul></ul><ul><li>new abstraction: flow (see IPv6) </li></ul><ul><ul><li>but no one knows what a flow is </li></ul></ul><ul><li>routers require to maintain per-flow state </li></ul><ul><li>state management: recovering lost state is hard </li></ul><ul><li>here we see the first proposal of “soft state”! </li></ul><ul><ul><li>soft-state: end-hosts responsible to maintain the state </li></ul></ul>
    86. 86. Rethinking Internet Design <ul><li>What’s changed? </li></ul><ul><li>operation in untrustworthy world </li></ul><ul><ul><li>endpoints can be malicious </li></ul></ul><ul><ul><li>If endpoint not trustworthy, but want trustworthy network -> more mechanism in network core </li></ul></ul><ul><li>more demanding applications </li></ul><ul><ul><li>end-end best effort service not enough </li></ul></ul><ul><ul><li>new service models in network (Intserv, diffserv)? </li></ul></ul><ul><ul><li>new application-level service architecture built on top of network core (e.g., CDN, p2p)? </li></ul></ul>
    87. 87. Rethinking Internet Design <ul><li>What’s changed? </li></ul><ul><li>ISP service differentiation </li></ul><ul><ul><li>ISP doing more (than other ISPs) in core is competitive advantage </li></ul></ul><ul><li>Rise of third party involvement </li></ul><ul><ul><li>interposed between endpoints (even against will) </li></ul></ul><ul><ul><li>e.g., Chinese gov’t, US recording industry </li></ul></ul><ul><li>less sophisticated users </li></ul>All five changes motivate shift away from end-end!
    88. 88. Technical response to changes <ul><li>Trust: emerging distinction between what is “in” network (us, trusted) and what is not (them, untrusted). </li></ul><ul><ul><li>ingress filtering </li></ul></ul><ul><ul><li>emergence of Internet UNI (user network interface, as in ATM)? </li></ul></ul><ul><li>Modify endpoints </li></ul><ul><ul><li>Harden endpoints against attack </li></ul></ul><ul><ul><li>Endpoints do content filtering: Net-nanny </li></ul></ul><ul><ul><li>CDN, ASPs: rise of structured, distributed applications in response to inability to send content (e.g., multimedia, high bw) at high quality </li></ul></ul>
    89. 89. Technical response to changes <ul><li>Add functions to the network core: </li></ul><ul><ul><li>filtering firewalls </li></ul></ul><ul><ul><li>application-level firewalls </li></ul></ul><ul><ul><li>NAT boxes </li></ul></ul><ul><ul><li>active networking </li></ul></ul><ul><li>… All operate within network, making use of application-level information </li></ul><ul><ul><li>which addresses can do what at application level? </li></ul></ul><ul><ul><li>If addresses have meaning to applications, NAT must “understand” that meaning </li></ul></ul>
    90. 90. Summary: Internet Architecture <ul><li>packet-switched datagram network </li></ul><ul><li>IP is the glue (network layer overlay) </li></ul><ul><li>IP hourglass architecture </li></ul><ul><ul><li>all hosts and routers run IP </li></ul></ul><ul><li>stateless architecture </li></ul><ul><ul><li>no per flow state inside network </li></ul></ul>IP TCP UDP ATM Satellite Ethernet IP hourglass
    91. 91. Summary: Minimalist Approach <ul><li>Dumb network </li></ul><ul><ul><li>IP provide minimal functionalities to support connectivity </li></ul></ul><ul><ul><li>addressing, forwarding, routing </li></ul></ul><ul><li>Smart end system </li></ul><ul><ul><li>transport layer or application performs more sophisticated functionalities </li></ul></ul><ul><ul><li>flow control, error control, congestion control </li></ul></ul><ul><li>Advantages </li></ul><ul><ul><li>accommodate heterogeneous technologies (Ethernet, modem, satellite, wireless) </li></ul></ul><ul><ul><li>support diverse applications (telnet, ftp, Web, X windows) </li></ul></ul><ul><ul><li>decentralized network administration </li></ul></ul>
    92. 92. <ul><li>Two ways of constructing a software design: </li></ul><ul><li>make it so simple that there are obviously no deficiencies, and </li></ul><ul><li>make it so complicated that there are no obvious deficiencies </li></ul><ul><li> --- CAR Hoare </li></ul>
    93. 93. Readings <ul><li>Reading : Saltzer, Reed, Clark: &quot;End-to-End arguments in System Design&quot; </li></ul><ul><li>Reading: Clark: &quot;The Design Philosophy of the DARPA Internet Protocols&quot;: </li></ul>
    94. 94. Standardization Henning Schulzrinne Dept. of Computer Science Columbia University Fall 2003
    95. 95. Standards <ul><li>Mandatory vs. voluntary </li></ul><ul><ul><li>Allowed to use vs. likely to sell </li></ul></ul><ul><ul><li>Example: health & safety standards  UL listing for electrical appliances, fire codes </li></ul></ul><ul><li>Telecommunications and networking always focus of standardization </li></ul><ul><ul><li>1865: International Telegraph Union (ITU) </li></ul></ul><ul><ul><li>1956: International Telephone and Telegraph Consultative Committee (CCITT) </li></ul></ul><ul><li>Five major organizations: </li></ul><ul><ul><li>ITU for lower layers, multimedia collaboration </li></ul></ul><ul><ul><li>IEEE for LAN standards (802.x) </li></ul></ul><ul><ul><li>IETF for network, transport & some applications </li></ul></ul><ul><ul><li>W3C for web-related technology (XML, SOAP) </li></ul></ul><ul><ul><li>ISO for media content (MPEG) </li></ul></ul>
    96. 96. Who makes the rules? - ITU <ul><li>ITU = ITU-T (telecom standardization) + ITU-R (radio) + development </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>14 study groups </li></ul></ul><ul><ul><li>produce Recommendations: </li></ul></ul><ul><ul><ul><li>E: overall network operation, telephone service (E.164) </li></ul></ul></ul><ul><ul><ul><li>G: transmission system and media, digital systems and networks (G.711) </li></ul></ul></ul><ul><ul><ul><li>H: audiovisual and multimedia systems (H.323) </li></ul></ul></ul><ul><ul><ul><li>I: integrated services digital network (I.210); includes ATM </li></ul></ul></ul><ul><ul><ul><li>V: data communications over the telephone network (V.24) </li></ul></ul></ul><ul><ul><ul><li>X: Data networks and open system communications </li></ul></ul></ul><ul><ul><ul><li>Y: Global information infrastructure and internet protocol aspects </li></ul></ul></ul>
    97. 97. ITU <ul><li>Initially, national delegations </li></ul><ul><li>Members: state, sector, associate </li></ul><ul><ul><li>Membership fees </li></ul></ul><ul><li>Now, mostly industry groups doing work </li></ul><ul><li>Initially, mostly (international) telephone services </li></ul><ul><li>Now, transition from circuit-switched to packet-switched universe & lower network layers (optical) </li></ul><ul><li>Documents cost SFr, but can get three freebies for each email address </li></ul>
    98. 98. IETF <ul><li>IETF (Internet Engineering Task Force) </li></ul><ul><ul><li>see RFC 3233 (“ Defining the IETF ”) </li></ul></ul><ul><li>Formed 1986, but earlier predecessor organizations (1979-) </li></ul><ul><li>RFCs date back to 1969 </li></ul><ul><li>Initially, largely research organizations and universities, now mostly R&D labs of equipment vendors and ISPs </li></ul><ul><li>International, but 2/3 United States </li></ul><ul><ul><li>meetings every four months </li></ul></ul><ul><ul><li>about 300 companies participating in meetings </li></ul></ul><ul><ul><ul><li>but Cisco, Ericsson, Lucent, Nokia, etc. send large delegations </li></ul></ul></ul>
    99. 99. IETF <ul><li>Supposed to be engineering, i.e., translation of well-understood technology  standards </li></ul><ul><ul><li>make choices, ensure interoperability </li></ul></ul><ul><ul><li>reality: often not so well defined </li></ul></ul><ul><li>Most development work gets done in working groups (WGs) </li></ul><ul><ul><li>specific task, then dissolved (but may last 10 years…) </li></ul></ul><ul><ul><li>typically, small clusters of authors, with large peanut gallery </li></ul></ul><ul><ul><li>open mailing list discussion for specific problems </li></ul></ul><ul><ul><li>interim meetings (1-2 days) and IETF meetings (few hours) </li></ul></ul><ul><ul><li>published as Internet Drafts (I-Ds) </li></ul></ul><ul><ul><ul><li>anybody can publish draft-somebody-my-new-protocol </li></ul></ul></ul><ul><ul><ul><li>also official working group documents (draft-ietf-wg-*) </li></ul></ul></ul><ul><ul><ul><li>versioned (e.g., draft-ietf-avt-rtp-10.txt) </li></ul></ul></ul><ul><ul><ul><li>automatically disappear (expire) after 6 months </li></ul></ul></ul>
    100. 100. IETF process <ul><li>WG develops  WG last call  IETF last call  approval (or not) by IESG  publication as RFC </li></ul><ul><li>IESG (Internet Engineering Steering Group) consists of area directors – they vote on proposals </li></ul><ul><ul><li>areas = applications, general, Internet, operations and management, routing, security, sub-IP, transport </li></ul></ul><ul><li>Also, Internet Architecture Board (IAB) </li></ul><ul><ul><li>provides architectural guidance </li></ul></ul><ul><ul><li>approves new working groups </li></ul></ul><ul><ul><li>process appeals </li></ul></ul>
    101. 101. RFCs <ul><li>Originally, “Request for Comment” </li></ul><ul><li>now, mostly standards documents that are well settled </li></ul><ul><li>published RFCs never change </li></ul><ul><li>always ASCII (plain text), sometimes PostScript </li></ul><ul><li>anybody can submit RFC, but may be delayed by review (“end run avoidance”) </li></ul><ul><li>see April 1 RFCs (RFC 1149, 3251, 3252) </li></ul><ul><li>accessible at and </li></ul>
    102. 102. IETF process issues <ul><li>Can take several years to publish a standard </li></ul><ul><ul><li>see draft-ietf-problem-issue-statement </li></ul></ul><ul><li>Relies on authors and editors to keep moving </li></ul><ul><ul><li>often, busy people with “day jobs”  spurts three times a year </li></ul></ul><ul><li>Lots of opportunities for small groups to delay things </li></ul><ul><li>Original idea of RFC standards-track progression: </li></ul><ul><ul><li>Proposed Standard (PS) = kind of works </li></ul></ul><ul><ul><li>Draft Standard (DS) = solid, interoperability tested (2 interoperable implementations for each feature), but not necessarily widely used </li></ul></ul><ul><ul><li>Standard (S) = well tested, widely deployed </li></ul></ul>
    103. 103. IETF process issues <ul><li>Reality: very few protocols progress beyond PS </li></ul><ul><ul><li>and some widely-used protocols are only I-Ds </li></ul></ul><ul><li>In addition: Informational, Best Current Practice (BCP), Experimental, Historic </li></ul><ul><li>Early IETF: simple protocols, stand-alone </li></ul><ul><ul><li>TCP, HTTP, DNS, BGP, … </li></ul></ul><ul><li>Now: systems of protocols, with security, management, configuration and scaling </li></ul><ul><ul><li>lots of dependencies  wait for others to do their job </li></ul></ul>
    104. 104. Other Internet standards organizations <ul><li>ISOC (Internet Society) </li></ul><ul><ul><li>legal umbrella for IETF, development work </li></ul></ul><ul><li>IANA (Internet Assigned Numbers Authority) </li></ul><ul><ul><li>assigns protocol constants </li></ul></ul><ul><li>NANOG (North American Network Operators Group) ( ) </li></ul><ul><ul><li>operational issues </li></ul></ul><ul><ul><li>holds nice workshop with measurement and “real world” papers </li></ul></ul><ul><li>RIPE, ARIN, APNIC </li></ul><ul><ul><li>regional IP address registries  dole out chunks of address space to ISPs </li></ul></ul><ul><ul><li>routing table management </li></ul></ul>
    105. 105. ICANN <ul><li>Internet Corporation for Assigned Names and Numbers </li></ul><ul><ul><li>manages IP address space (at top level) </li></ul></ul><ul><ul><li>DNS top-level domains (TLD) </li></ul></ul><ul><ul><ul><li>ccTLD: country codes (.us, .uk, …) </li></ul></ul></ul><ul><ul><ul><li>gTLDs (.com, .edu, .gov, .int, .mil, .net, and .org) </li></ul></ul></ul><ul><ul><ul><li>uTLD (unsponsored): .biz, .info, .name, and .pro </li></ul></ul></ul><ul><ul><ul><li>sTLD (sponsored): .aero, .coop, and .museum </li></ul></ul></ul><ul><li>actual domains handled by registrars </li></ul>
    106. 106. Introduction to IETF (readings-hw) <ul><li> </li></ul><ul><li>RFC 2026 </li></ul><ul><li>RFC 2028 </li></ul><ul><li>RFC 3160 </li></ul><ul><li>RFC 3869 </li></ul>