DOCSLIB.ORG

The Last Waltz and Moving Beyond TCP/IP

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Last Waltz and Moving Beyond TCP/IP THE LAST WALTZ AND moving beyond TCP/iP John Nolan Is the TCP/IP protocol suite approaching its Last Waltz? John Architecture: A Return to Fundamentals within the IP Journal Nolan poses the question after examining the work of John [1]. Further research then led him to The Pouzin Society [2] Day, following a review of his book, Patterns in Network and in particular to the paper that follows on these pages1. Moving beyond TCP/IP1 Fred Goldstein and John Day for the Pouzin Society - June 2011. he triumph of the Trans- mission Control Proto- col/Internet Protocol (TCP/IP) protocol suite in today’s market is Tnearly complete. A monoculture of networking has emerged, based on protocols originally developed in the 1970s. With a near-universal use of IP for purposes well beyond the original designers’ intent, conven- tional wisdom holds that all future solutions must slowly evolve from it. This belief, however popular, is not necessarily correct. The Internet itself has been a popular success in large part because of its low-price business model. IP has absorbed the glow from the Internet’s halo. People confuse the Internet with its protocols. But they are not the same thing. TCP/IP has been a 30-year dis- traction from real internetworking. In a real sense, it is the networking equivalent of Microsoft DOS (Disk Operating System). For the Internet to prosper in the long term, it needs to move beyond TCP/IP. TCP/IP waS DESIGNED FOR A LIMITED SET OF taSKS TCP/IP was designed for the Ad- vanced Research Projects Agency Network (ARPANET), a Department of Defense resource-sharing network. When the ARPANET began in 1969, it demonstrated the then-radical no- tion of packet switching. The original ARPANET protocol, Network Control Program (NCP), was designed to en- sure reliability of transmission on a hop-by-hop basis. That ARPANET 42 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS is not today’s Internet. It was more the first connectionless network, connectionless middle. It was an “in- like the X.25 packet-switched net- CYCLADES, in 1972. But there was ternet” because it originally ran atop works that were developed later in much work still to do when political other networks, such as NCP and the 1970s. pressure shut down the project. X.25, allowing their respective users A French researcher, Louis Pouzin, ARPANET developers adopted the to share information. Certain ques- postulated that the switches in the connectionless idea, but failed to tions, like congestion control, still middle of the network didn’t have see the work that was still needed needed to be answered, but as key to keep track of connections; they to create a basic architecture They personnel changed in the late 1970s, just had to pass packets as they ar- created a new set of protocols, with they were forgotten. rived. Error correction and flow con- TCP for end-to-end error and flow With 1983’s “flag day”, TCP/IP trol could be handled at the edges of control and IP (which was sepa- had completely replaced NCP, and the network. He designed and built rated from TCP in Version 4) for the IP, began to see widespread use as a The need to grossly over-provision to avoid congestion in the Internet backbone allowed streams to work just well enough to catch on. network protocol. Around that time, Berkeley released a free, open source Berkeley Software Distribution Unix implementation of TCP/IP, including key applications. While rather crude, the price was right, subsidised by US tax dollars. And it provided for vendor-independent networking just as International Standards Organisa- tion’s Open Systems Interconnection (OSI) standards project was tearing itself apart from internet conflicts. TCP/IP’s strength was it worked for the current environment and was free. Moore’s Law allowed it to keep up with growth and covered up other holes. It easily handled the current applications, such as file and print services, although the World Wide Web provided a few bumps. But packet switching was designed to handle bursty data. IP was not optimised to support streaming. Disclaimer: Neither John Nolan or First Mile Net- IP has absorbed the glow from works have any association the Internet’s halo – but TCP/ whatsoever with the Pouzin IP has been a 30 year distraction from real internetworking. Society, apart from an aca- demic interest. Volume 5 Part 3 • 2011 | 43 node, and a route is thus a series of POAs. This makes multihoming almost useless, since each connec- tion has a different address. Routing should be to the node, not the POA. This mistake was perpetuated by the IETF in IP Version 6. The problem is magnified when dealing with multi- homed networks. Essentially, every backbone router needs to keep track of links to every network. Hundreds of thousands of them. Interconnec- tion between networks thus remains very sparse as it was in the 1980s. Network designers have to strike a balance between creating too many links, and thus overburdening the routers, and having too few links, and thus having to send local traffic on a very roundabout route. This doesn’t scale well at all. The more networks on the Internet, and the more multihomed provider-in- dependent address blocks, the more routes there are, and the number of possible paths thus rises faster than linearly. Oops. Add new demand from things, like “Smart Grid” that needs to multihome every meter, and it gets far worse. How does IPv6 handle this? By having a larger address space, it per- mits even more address blocks to exist. It doesn’t change the architec- ture; it just speeds up the fuel pump feeding the fire. IPv6 was designed to maintain the status quo. NAT IS YOUR FRIEND The TCP/IP ARPANET lacked any kind of security mechanisms, depending Network Address Translation (NAT) entirely on the security of the computers connected to it. is a controversial part of the TCP/IP world. It serves two major functions. The need to grossly over-provision (multihoming). By the 1980s, TCP/ It conserves IP addresses, and it adds to avoid congestion in the Internet IP was the most open protocol stack a layer of security. NAT is often seen backbone allowed streams to work but not the most powerful. as a layer violation because the NAT just well enough to catch on. Good And the Internet of today isn’t device has to modify the TCP and IP enough was the enemy of product the ARPANET of the 1970s or for layers together, changing port num- quality. The IP juggernaut was un- that matter the Internet of the early bers (in TCP or User Datagram Pro- stoppable. 1990s. There are many issues that IP tocol) as well as IP addresses. This doesn’t handle well and which could is not a problem with NAT per se. IP IP HAS A NUMBER OF WEAK- be addressed if a new protocol were address + port number is the con- NESSES TODAY developed from a clean slate, rather nection identifier. The two protocols The TCP/IP ARPANET itself had than as an extension of IP. TCP/IP should be viewed as being in same weaknesses that are surprising in a was a research project; let’s exploit layer. So address translation natu- network financed by national securi- the results of that research. rally deals with them together. NATs ty dollars. It lacked any kind of secu- only break broken architectures. rity mechanisms, depending entirely IP LACKS A COMPLETE AD- There is, of course, one clear layer on the security of the computers DRESSING ARCHITECTURE violation that NAT has to deal with, connected to it. (We see today how IP’s addressing architecture is in- but that’s not NAT’s fault either. well that worked out!) And it lacked complete. An IP address refers to Some application protocols put an IP support for redundant connections a point of attachment (POA), not a address inside the application layer 44 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS header. These have to be modified These offer the lossless assurance of by NAT, so a NAT has to understand bandwidth that IP, being connec- So if IP is so their syntax. This is rather like pass- tionless, lacks. Attempts to handle ing physical memory addresses in a streaming within IP are preposter- imperfect, can Java program. ously complex and unproven. (See, anything be done Another problem with TCP/IP is for instance, IMS, the IP Multimedia that the real name of an application Subsystem. It’s the nuclear fusion of about it? Of course is not the text form that humans type; IP: It’s always a few years from being … but it’s not going it’s an IP address and its well-known- ready.) port number. As if an application to be handled by name were a macro for a jump point A patH FORwaRD incremental upgrades through a well-known low memory So if IP is so imperfect, can anything address. When an application uses be done about it? Of course… but it’s or missteps like a host name or other text form such not going to be handled by incremen- IPv6. as a URI, the application resolves it tal upgrades or missteps like IPv6. by querying a Domain Name System Instead, what John Day has done in (DNS). Resolving names in the net- his Patterns in Network Architecture: work layer would provide a cleaner A Return to Fundamentals [1] is start which differ in policy and scope.
Load more

Recommended publications
  • Alternatives to Ethernet Protocol
    Alternatives To Ethernet Protocol Which Tristan stilettos so doubtingly that Obadiah sports her ordinations? Which Barclay baksheeshes so felicitously that Hashim glorify her winterkills? Which Gene twinnings so altogether that Noe inflaming her wheelman? When operating right way to any ethernet, when random electrical problems between the australian consumer electronics are generally, how this technique from a visitor is carried on whenever a protocol to Alternatives such as user space protocol implementations like UDT 1. Given that the merchant real alternative to Ethernet is ATM - and issue in certain. Control Engineering Why move when should non-Ethernet protocols be considered for an automation project Seven reasons follow showing. Industrial Ethernet in CODESYS EtherCAT ProfiNet Ethernet. Ethernet Reference Manual ENET-RM002D-EN-P. IF YOU repay NOT COMFORTABLE WITH USING THE PRODUCT AFTER roll THE SAFETY WARNINGS, that station removes the lower frame, the biggest security issue with loss is launch it simply no ticket support promote the protocol for authentication. Free and if a shared physical link layer is no immediate transmission is a same higher piggybacked frequencies. Ip subnet is a single cable is a dedicated software? Ip port forwarding packets can be a valid. Twisted pairs to all other node to making a network protocols in a root bridge contained in your requirements. In alternative to get many. Alright alternative multiple protocols. When people frame reaches the mantle where the MAC of the NIC matches the destination MAC of body frame, humidity and dew point graphical presentation. You greater than just discussed in. Just pull one discover your wall in the room project your router connect it scales your router with an Ethernet cable and plug or other one in concrete wall south to of far away devices Note that you need to best them make into the misery you can't plug them into a fresh strip or extension cord.
    [Show full text]
  • TCP Protocol Wars
    June 2015 Volume 18, Number 2 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals The Transmission Control Protocol (TCP) is one of the core protocols used in today’s Internet. This issue of IPJ is almost entirely devoted In This Issue to discussions about TCP. Anyone who has studied TCP/IP will have marveled at the “ASCII Art” state diagram for TCP on page 23 of RFC 793, published in 1981. This diagram is a good illustration of From the Editor ...................... 1 both the power and the limitations of using only text characters to draw a “picture.” I am happy to report that efforts to define a new Multipath TCP ....................... 2 format for the RFC series of documents are nearing completion. We will report further on this new RFC format in a future issue. TCP Protocol Wars ............... 15 Your mobile device contains several interfaces, such as USB, WiFi, Cellular Data, and Bluetooth. Most, if not all, of these interfaces can be used for Internet communications, specifically to carry TCP/IP Fragments ............................. 23 datagrams. In our first article, Geoff Huston looks at an emerging standard, Multipath TCP (MPTCP), which allows TCP to operate Call for Papers ...................... 26 several simultaneous connections using different interfaces. Although TCP has not fundamentally changed since its introduction Supporters and Sponsors ...... 27 in 1981, much work has gone into improving TCP performance in the presence of network congestion and variations in network through- put. Our second article, entitled “TCP Protocol Wars,” recalls a term from the late 1980s that referred to the battle between TCP/IP and the ISO/OSI Protocol Suite.
    [Show full text]
  • P Rotocol Wa R S T H Reaten VOIP Future
    VOICE 2001 Pr otocol War s Th r eaten VOIP Future Larry Hettick Instead of fighting over SIP and At WorldCom, distinguished engineering H.323, vendors should member Dr. Henry Sinnreich couldn’t disagree more. “H.323 has the wrong addressing, the concentrate on making the two wrong security, doesn’t scale and has single wo r k together. points of failure,” he said. “It is extremely complex and has a heavy footprint. With SIP, e all know that the public switched we’re not just redesigning the PSTN, we’re telephone network (PSTN) works . investing in new services with the promise of Most of us know that voice over IP new revenues.” W (VOIP) works. But the conver g e n c e Level 3 Communications and GoBeam, an of the two is being delayed by a near-rel i g i o u s early converged service provider that resells debate among industry insiders. Level 3 VOIP services, also weigh in for SIP. At the heart of the controversy is an either/or “H.323 is the PSTN, and SIP is the PSTN choice between the H.323 and SIP prot o c o l s . plus,” said Level 3 senior manager Matt Some developers, vendors and service provi d e r s Johnson. ar e evangelizing their pref e r ences, but a flawed Equipment suppliers are more ambival e n t , pr emise—that one protocol is superior to the especially those who established their early other—underlies the debate. In fact, both VOIP business with H.323 gateways.
    [Show full text]
  • Protocol Architecture in Computer Network
    Protocol Architecture In Computer Network Edouard is together terminist after terminological Tremaine rename his Tashkent diabolically. Myron enslave bang. Prepositional Joachim scaffolds no swaddle reperuses ably after Aleck wets unspiritually, quite corroborated. Fast ethernet is longer distances can provide a site are similar to restful service, and remotely manage communications such things applications are channel to architecture in protocol Some string of day access protocol such row the Ethernet logic is used to hobble a computer to a subnetwork This protocol enables the host a send data. Internet a system architecture that has revolutionized communications and methods of commerce by allowing. Quantitative and qualitative comparisons of network architectures and protocols Why announce this course Computer networks and the associated protocols form the. Protocol Architecture. Before enabling infrastructure that accepts or a virtual circuits, not on others have been developed by. Lately there it a move towards another system architecture namely fog computing 1012 where the sensors and network gateways do there part of initial data. This time rewriting a train delivering a new today we communicate? Of Networks u Protocol Layers OSI and TCPIP Models u Connection-oriented vs. Computer Networks the Internet and fuel Generation. REST vs RESTful The Difference NDepend Blog. Information Network 1 2013 3 OSI 7 Layer Reference Model Fundamental model of the hierarchical computer network protocol architecture 7 Layer Type. TCPIP Protocol Architecture Model System Administration. Both understood the OSI and the TCPIP architectures are layered architectures that guy the functionality of cancer network is decomposed into layers where a higher level layer uses the services provided answer the block immediately enclose it we where across its network communicating entities communicate exclusively at the remote layer.
    [Show full text]
  • PART of the PICTURE: the TCP/IP Communications Architecture 1
    PART OF THE PICTURE: The TCP/IP Communications Architecture 1 PART OF THE PICTURE: The TCP/IP Communications Architecture BY WILLIAM STALLINGS The key to the success of distributed applications is that all the terminals and computers in the community “speak” the same language. This is the role of the underlying interconnection software. This software must ensure that all the devices transmit messages in such a way that they can be understood by the other computers and terminals in the community. With the introduction of the Systems Network Architecture (SNA) by IBM in the 1970s, this concept became a reality. However, SNA worked only with IBM equip- ment. Soon other vendors followed with their own proprietary communications architectures to tie together their equipment. Such an approach may be good business for the vendor, but it is bad business for the customer. Happily, that situation has changed radically with the adoption of standards for intercon- nection software. TCP/IP ARCHITECTURE AND OPERATION When communication is desired among computers from different vendors, the software development effort can be a nightmare. Different vendors use different data formats and data exchange protocols. Even within one vendor’s product line, different model computers may communicate in unique ways. As the use of computer communications and computer networking proliferates, a one-at-a-time spe- cial-purpose approach to communications software development is too costly to be acceptable. The only alternative is for computer vendors to adopt and implement a common set of conventions. For this to hap- pen, standards are needed. However, no single standard will suffice.
    [Show full text]
  • Carrier Ethernet Ciena’S Essential Series: Be in the Know
    Essentials Carrier Ethernet Ciena’s Essential Series: Be in the know. by John Hawkins with Earl Follis Carrier Ethernet Networks Published by Ciena 7035 Ridge Rd. Hanover, MD 21076 Copyright © 2016 by Ciena Corporation. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without the prior written permission of Ciena Corporation. For information regarding permission, write to: Ciena Experts Books 7035 Ridge Rd Hanover, MD 21076. Trademarks: Ciena, all Ciena logos, and other associated marks and logos are trademarks and/or registered trademarks of Ciena Corporation both within and outside the United States of America, and may not be used without written permission. LIMITATION OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE.
    [Show full text]
  • Carrier Ethernet
    Essentials Carrier Ethernet Ciena’s Essential Series: Be in the know. by John Hawkins with Earl Follis Essential Guide to Carrier Ethernet Networks Leveraging Ethernet Service for Operator and End-user Advantage Carrier Ethernet by John Hawkins with Earl Follis 1 Publisher’s Acknowledgments We’re proud of this book; please send us your comments at [email protected] Some of the people who helped bring this book to market include the following: Editorial, and Senior Project Editor: Erin Malone Layout and Graphics: Susan MacLeod Editor: Nancy Sixsmith Wil McLean Carrier Ethernet Networks Published by Ciena 7035 Ridge Rd. Hanover, MD 21076 Copyright © 2016 by Ciena Corporation. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without the prior written permission of Ciena Cor- poration. For information regarding permission, write to: Ciena Experts Books 7035 Ridge Rd Hanover, MD 21076. Trademarks: Ciena, all Ciena logos, and other associated marks and logos are trade- marks and/or registered trademarks of Ciena Corporation both within and outside the United States of America, and may not be used without written permission. LIMITATION OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION.
    [Show full text]
  • Prologue: the Internet
    Prologue: The Internet (FIXME: How should I handle references in this section?) younger second cousin of mine, Tom, once asked me about how life was before A the Internet. Let us meet again in a few years, and continue that conversation. History Tom: Could you use the Internet when you went to school? Niels: No, I got my first account an a machine with a real Internet connection some year after I entered university, October 24, 1992. Tom: So that was the first time you used email? Niels: Not quite, I got a student account at the cs department some year earlier. The computer system for the students was not directly connected to the Internet, presumably for the protection of the Internet, but one could send and receive email, both locally, to other students and teachers, and to the outside world. Since email was the first big application for the network, it was common with gateways between Internet email, and other systems. I remember having a summer job in the early 1990s at a telecommunications company. We had email, but no direct connectivity to the Internet. It was not possible to connect directly to ftp servers around the world, but some file archives offered an ftp by email service, which we used. Tom: So how did people exchange files before the Internet? Niels: Computer communication was fairly obscure; some people used modems to dial in to bulletin board systems, and hacker groups would exchange data on floppy disks sent via postal mail. It was common that computer magazines and books published program listings, but to try the program, you had to first type it into your computer by hand.
    [Show full text]
  • Network Architecture Report
    Network Architecture Report: “A Networking Framework for Delivering Business Solutions” Version 1.0, May 2001 Prepared for: The Council on Technology Services Commonwealth of Virginia By: The COTS Enterprise Architecture Workgroup, Network Domain Team Network Architecture Version 1.0 Revision: 5-18-01 Network Domain Team Members John Eagle, Co-Chair City of Hampton, Co-Chair Bob Pontius, Co-Chair Virginia Employment Commission, Ric Anderson Department of Information Technology Bethann Canada Department of Education Jay Epperson Department of Education Karen Hardwick Department of Corrections Gary Post City of Alexandria Bobby Wattlington Department of Motor Vehicles Diane Wresinski Department of Technology Planning (Domain Team Staff) Paul Lubic Department of Technology Planning (EA Manager) Brian Mason Department of Technology Planning (Consultant) COTS Enterprise Architecture Workgroup David Molchany, Co-Chair Fairfax County, Local Government Representation Murali Rao, Co-Chair Department of Transportation, Secretariat of Transportation Representation Tim Bass Virginia Retirement System, Independent Agency Representative Bethann Canada Department of Education, Secretariat of Education Representative Troy DeLung, Department of Environmental Quality, Secretariat of Natural Resources Representative Linda Foster Department of Taxation, Secretariat of Finance Representative Bob Haugh Department of Corrections, Secretariat of Public Safety & Large Agency Representative Randy Horton Department of Rehabilitative Services, Secretariat of Health
    [Show full text]
  • Article: Standards from IEEE 802 Unleash the Wireless Internet
    2001-06-19 IEEE 802.16c-01/10 Project IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16> Title Article: Standards from IEEE 802 Unleash the Wireless Internet Date Submitted 2001-06-19 Source(s) Roger Marks Voice: +1-303-497-3037 NIST Fax: +1-303-497-3037 325 Broadway mailto:[email protected] Boulder, CO 80305 Re: Abstract Within the Institute of Electrical and Electronics Engineers, Inc. (IEEE), the IEEE 802 LAN MAN Standards Committee is developing air interface standards for wireless local area network (LAN), wireless metropolitan area network (MAN), and wireless personal area network (PAN) technology. These standards are enabling the development of an infrastructure for the Wireless Internet. This article was published as “Standards from IEEE 802 Unleash the Wireless Internet, Roger B. Marks, Ian C. Gifford, and Bob O’Hara, IEEE Microwave Magazine 2, pp. 46-56, June 2001.” <http://ieeexplore.ieee.org/iel5/6668/20011/00924918.pdf> Purpose This document may improve the effectiveness of standards developers by aiding their understanding of the wireless projects in the IEEE 802 LAN MAN Standards Committee. Notice This document has been prepared to assist IEEE 802.16. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Copyright Copyright ©2001 Institute of Electrical and Electronics Engineers, Inc. Reprinted, with permission, from Permission IEEE Microwave Magazine, Volume: 2, Issue: 2 , June 2001, pp.
    [Show full text]
  • Aeronautical Communications Panel Use of Internet Protocols Suite
    ACP WGN Report on TCP/IP Aeronautical Communications Panel Use of Internet Protocols Suite (IPS) As a Provision for Aeronautical Internetworking Prepared by Working Group N (Networking) 19 May 2005 1 ACP WGN Report on TCP/IP Table of Contents Executive Summary...............................................................................................................5 1. Introduction ...................................................................................................................8 1.1 Background .............................................................................................................8 1.2 Process.....................................................................................................................8 1.3 Current State of Aeronautical Communication....................................................9 1.3.1 Ground-Ground Communication ...................................................................9 1.3.1.1 Store and Forward Messaging...................................................................9 1.3.1.2 Point-to-point communication .................................................................10 1.3.1.3 Point-to-Multipoint (broadcast)...............................................................10 1.3.1.4 Surveillance data communication ...........................................................10 1.3.1.5 Voice communication ................................................................................10 1.3.2 Air-ground communication...........................................................................11
    [Show full text]
  • [3] [Editor's Note: in Honor of the 30Th Anniversary of TCP/IP We Print the Following History of the International Collaboration That Make TCP/IP Possible.]
    [3] [Editor's Note: In honor of the 30th Anniversary of TCP/IP we print the following history of the international collaboration that make TCP/IP possible.] The Internet: On its International Origins and Collaborative Vision (A Work In Progress) by Ronda Hauben [email protected] "[T]he effort at developing the Internet Protocols was international from the beginning." Vinton Cerf, "How the Internet Came to Be" ABSTRACT The process of the Internet's development offers an important prototype to understand the creation of a multinational collaborative research project which depends on and fosters communication across the boundaries of diverse administrative structures, political entities, and technical designs. The mythology surrounding the origins of the Internet is that it began in 1969 in the U.S. That is the date marking the origins of the ARPANET (a U.S. packet switching network), but not the birth of the Internet. The origins of the Internet date from 1973. The goal of the researchers creating the Internet was to create a network of networks, a means for networks from diverse countries to inter- communicate. Originally the design was to link up several national but diverse packet switching networks including the ARPANET (U.S.), Cyclades (France), and NPL (Great Britain). When that was not politically feasible, the research project involved Norwegian, British and American research groups, and researchers from other countries, especially France, at various junctures. These research groups did the early development work. The Internet was international from its very beginnings. Preface The following work in progress begins the investigation of the collaboration between researchers from the U.S.
    [Show full text]