1 / 34

Storia di ARPAnet

Alla fine degli anni '60 nasce il progetto ARPAnet, su iniziativa della Defense Advanced Research Project Agency (DARPA).

kat
Download Presentation

Storia di ARPAnet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alla fine degli anni '60 nasce il progetto ARPAnet, su iniziativa della Defense Advanced Research Project Agency (DARPA). ARPAnet utilizza minicomputers della BBN detti Packet Switched Nodes (PSN), collegati da linee punto-punto. Gli host si collegano ai PSN con una speciale interfacia, detta 1822. In segiuto viene reso possibile anche il collegamento host-PSN tramite linea seriale con protocollo HDLC/LAPB. Nel 1984 il DoD separa ARPAnet (che continua ad esistere per ricerche sperimentali) MILnet, utilizzata regolarmente per le comunicazioni del DoD. Le due sottoreti rimangono interconnesse. Nel 1990 termina il progetto ARPAnet e scompare la sottorete che portava il suo nome. La tecnologia ARPAnet è tuttora utilizzata in parti di MILnet. Storia di ARPAnet

  2. Negli anni '70 DARPA promuove anche studi sulla commutazione di pacchetto via satellite o via radio. Nasce l'esigenza di interconnettere reti eterogenee (1978-79). Ciò porta alla definizione dell'architettura TCP/IP. Primi esperimenti: 1980. Nel 1983 DARPA impone ad ogni host connesso ad ARPAnet di usare il TCP/IP. Nasce così un insieme di reti interconnesse per mezzo di protocolli TCP/IP. Questo insieme prende il nome di Internet. L'Inclusione dei protocolli TCP/IP nel Berkeley Unix ne provoca una rapidissima diffusione, anche al di fuori di Internet. Nascita di Internet

  3. Attualmente il nucleo della rete Internet negli Stati Uniti è gestito e finanziato da cinque agenzie governative: National Science Foundation (NSF). Defense Advanced Research Project Agency (DARPA). Department of Energy (DOE). National Aeronautics and Space Administration (NASA). Department of Health and Human Services (DHHS). Internet negli Stati Uniti

  4. Le cinque agenzie governative sono coordinate dal Federal Networking Committee (FNC). Le altre reti di Internet possono utilizzare la dorsale del FNC purché si impegnino a farlo per soli scopi di ricerca. L'insieme delle reti statunitensi autorizzate a usare la dorsale forma la National Research and education Network (NREN). I contatti fra il FNC e gli organismi analoghi di altri paesi sono tenuti dal Coordinating Committee for International Research Networking (CCIRN). Comitati di Coordinamento

  5. Già nella prima metà degli anni '80 vengono stabiliti i primi collegamenti transatlantici fra sedi europee e il resto dell'Internet statunitense. In seguito, su iniziativa soprattutto di EUnet (la rete UUCP europea) e dei fisici delle alte energie, vengono creati alcuni collegamenti TCP/IP europei internazionali. Nel 1989 i gestori dell'embrione di rete TCP/IP europea creano un gruppo di lavoro, detto RIPE (Réseaux IP Européens), con lo scopo di creare l'inrastruttura organizzativa necessaria alla crescita di Internet in Europa. RIPE è tuttora una associazione di volontari, la cui utilità è tuttavia riconosciuta da tutti gli enti che finanziano le reti per la ricerca in Europa e in USA. È allo studio la proposta di creazione di un centro operativo di RIPE finanziato dalla Comunità Europea e da altre fonti. Internet in Europa

  6. Il primo collegamento italiano viene realizzato nel maggio '86: il CNUCE di Pisa avvede alla rete via satellite SATnet (una delle reti che formano Internet). Lo sviluppo di Internet in Italia è attualmente coordinato da EUnet e dal Gruppo Armonizzazione Reti per la Ricerca, di cui fanno parte: CILEA, CINECA, CNR, ENEA, INFN, Tecnopolis-CSATA. Attualmente le seguenti linee internazionali collegano l'Italia al resto di Internet: CNAF (Bologna) - CERN (Ginevra) (collegamento GARR), DIST (Genova) - INRIA (Sophia-Antipolis) (collegamento EUnet). Internet in Italia

  7. Tutti i documenti ufficiali di Internet e le informazioni utili per il suo utilizzo sono ottenibili via rete collegandosi con il Network Information Systems Center (NIC o SRI-NIC), che si trova presso lo SRI International a Menlo Parl (California). SRI-NIC svolge anche funzioni di Registrar, assegnando indirizzi etc. Alcuni documenti ottenibili dallo SRINIC sono identificati dalla sigla RFCnnnn. RFC sta per Request for Comments. Il contenuto degli RFC è di varia natura, ma alcuni di questi contengono le specifiche dei protocolli ufficiali della rete Internet (e quindi dell'architettura TCP/IP). Informazioni su Internet sono reperibili anche presso NIS.NSF.NET, NIS.EU.NET e altri server. Documenti ufficiali di Internet

  8. Il coordinamento della proettazione, l'evoluzione e la gestione di Internet è condotto dall'Internet Activity Board (IAB). Possono far parte dell'IAB tutti i volontari che abbiano qualche incarico di rilievo correlato con le attività di Internet. Alcuni compiti dell'IAB sono Approvare gli standard di Internet, Coordinare il processo di pubblicazione degli RFC, Fare piani a lunga scadenza per l'evoluzione di Internet, Rapresentare la comunità Internet a livello internazionale per tutte le questioni tecnico-politiche. Tutte le decisioni dell'IAB vengono rese pubbliche per mezzo di RFC. L'Internet Activity Board

  9. L'interconnessione delle reti in Internet avviene in modo conforme al modello Catenet. Il modello Catenet è descritto nel documento IEN 48: "The Catenet Model for Internetworking" scritto da Vint Cerf nel 1978. IEN significa Internet Engineering Note. Anche gli IEN sono ottenibili dallo SRI-NIC. Il modello Catenet

  10. Il sistema di indirizzamento è unico per tutto l'insieme di reti interconnesse. I dati vengono trasmessi dal mittente al destinatario in forma di datagram, ossia pacchetti contenenti nell'intestazione gli indirizzi del mittente e del destinatario. Le reti sono interconnesse da gateway, ossia da macchine che ricevono il datagram da una rete e lo ritrasmettono su un'altra dopo aver consultato opportune tabelle di routing. I gateway fanno parte del sistema di indirizzamento globale. L'inoltro di un datagram su una rete può richiedere l'inserimento del datagram in uno o più pacchetti del tipo utilizzato sulla sottorete. Talvolta la trasmissione di un datagram su una sotorete può richiederne la suddivisione in più datagram. In tal caso la ricostruzione del datagram originario viene fatta dal computer destinatario. Caratteristiche del modello Catenet

  11. Il sistema di indirizzamento golbale della rete Internet utilizza indirizzi di 4 bytes. Si è soliti rappresentare gli indirizzi di Internet come quattro numeri decimali separati da punti. Ogni numero decimale rappresenta il valore di un byte dell'indirizzo. Ad esempio, l'indirizzo x'020B80FE' viene comunemente rappresentato come 2.11.128.254. La parte iniziale di un indirizzo Internet identifica una rete, la parte rimanente un host su tale rete. Secondo questa terminologia anche i gateway sono host. Un host connesso a più reti ha almeno un indirizzo Internet per rete. Ciò è vero in particolare per i gateway. L'indirizzamento di Internet

  12. In un indirizzo Internet, il confine fra indirizzo di rete e indirizzo di host è determinato dal valore dei primi due bit. Se il primo bit è 0, la rete è di classe A. Il primo byte identifica la rete, i tre successivi l'host. Se il valore dei primi due bit è 10, la rete è di clase B. I primi fue bytes identificano la rete, i due successivi l'host. Se il valore dei primi due bit è 11, la rete è di classe C. I primi tre bytes identificano la rete, l'ultimo l'host. Un indirizzo Internet in cui la porzione host ha tutti i bit a 0 ha il significato di "questo" host. Un indirizzo Internet in cui la porzione host ha tutti i bit a 1 ha il significato di "tutti gli host di questa rete" (broadcast address). Una rete di classe C può avere al massimo 254 host. Classificazione degli indirizzi Internet

  13. Per il suo corretto funzionamento, un gateway di Internet ha bisogno delle seguenti tabelle: Una tabella delle reti adiacenti, contenente l'indicazione del tipo di rete e dell'indirizzo Internet che il gateway ha su tale rete. La tabella delle "route", che per ogni indirizzo di rete indica l'indirizzo di un host su una rete adiacente a cui passare i datagram. Per le reti non di tipo punto-punto, una tabella di mapping da cui ricavare l'indirizzo nativo di ogni host sulla rete adiacente. Generalmente è necessario costruire manualmente solo la tabella delle reti adiacenti e quella del mapping per le reti multihost senza possibilità di broadcasting (p. es. X.25). Informazioni per un gateway

  14. Mapping Ethernet L'host 192.12.192.1 ha indirizzo MAC 0800.89A0.2170 192.12.192.4 0260.8C58.2733 ..... ..... Esempio delle informazioni di un gateway Tabella delle reti adiacenti 1. Tipo: Ethernet Indirizzo IP: 192.12.192.1 2. X.25 131.24.6.125 3. Point-to-point 193.2.28.1 Tabella delle route Rete 24 via 131.24.1.1 197.25.123 193.2.28.2 ........ ....... Mapping X.25 L'host 131.24.1.1 ha indirizzo X.25 026245050211304 131.24.20.111 25510045230 ..... .....

  15. La proliferazione del numero di reti in Internet causa problemi di memoria sui gateway e una cattiva utilizzazione delle linee di trasmissione, che vengono monopolizzate dai gateway per scambiare informazioni di routing. L'RFC950 (Internet Standard Subnetting Procedure) consente di avere insiemi di reti adiacenti aveti tutte lo stesso indirizzo di rete. Alcuni dei bit della parte locale dell'Internet address vengono utilizzati per distinguere una sottorete da un'altra. Solo gli host adiacenti ad almeno una delle reti "subnetted" devono sapere quali sono i bit che identificano le sottoreti. Subnetting

  16. L'RFC791, pubblicato nel 1981, definisce l'Internet Protocol (IP), che viene utilizzato per trasportare i datagram su Internet. Campi importanti del datagram IP sono: Un identificatore di 16 bit assegnato al datagram dal mittente. L'Internet address del mittente. L'Internet address del destinatario (può essere un indirizzo di broadcast). L'identificatore del protocollo di livello superiore a cui è destinato il datagram (Protocol Number). Il "time to live": si tratta di un valore di 16 bit che deve essere decrementato almeno di 1 da ogni gateway. Permette di evitare che un datagram resti in circolazione per sempre. Su tutti gli host su cui esiste l'IP deve esistere l'ICMP (Internet Control Message Protocol, RFC792), usato soprattutto per lo scambio di informazioni di controllo co i gateway. Internet Protocol

  17. Protocollo Nome esteso RFC IP-ARPA Internet Protocol on ARPAnet BBN 1822 IP-WB Internet Protocol on Wideband Network 907 IP-X25 Internet Protocol on X25 Networks 877 IP-E Internet Protocol on Ethernet Networks 894 IP-EE Internet Protocol on Exp. Ethernet Nets 895 IP-IEEE Internet Protocol on IEEE 802 1042 IP-DC Internet Protocol on DC Networks 891 IP-HC Internet Protocol on Hyperchannel 1044 IP-ARC Internet Protocol on ARCNET 1051 IP-SLIP Transmission of IP over Serial Lines 1055 IP-NETBIOS Transmission of IP over NETBIOS 1088 IP-FDDI Transmission of IP over FDI 1103 Reti su cui è standardizzato il trasporto di datagram IP

  18. Oltre alle possibilità elencate nela precedente tabella, esistono soluzioni proprietarie per il trasporto di datagram IP su reti particolari. Queste soluzioni richiedono in genere l'utilizzo di un prodotto (HW e/o SW) ben preciso. Fra le soluzioni proprietarie vale la pena di ricordare: SNALINK E' la soluzione IBM per il trasporto di ip su SNA. D-Bridge. E' la soluzione Wollongong per il trasporto di IP su reti DECnet. TCP/IP Portal. E' la soluzione DEC per il trasporto di IP su reti DECnet. L'RFC1171 descrive il Point to Point Protocol (PPP), un proposed standard per trasportare più protocolli di tipo datagram sulla stessa linea seriale. Fra i protocolli previsti ci sono IP, DECnet e CLNS OSI. Attualmente non è ancora ufficiale lo standard per il trasporto di IP su linee seriali sincrone. Lo SLIP (RFC1055) è solo per linee asincrone. Soluzioni non standard per il trasporto di datagram IP

  19. Decimale Sigla Protocollo 1 ICMP Internet Control Message 6 TCP Transmission Control Protocol 8 EGP Exterior Gateway Protocol 9 IGP any private interior gateway 17 UDP User Datagram Protocol 29 ISO-TP4 ISO Transport Protocol Class 4 88 IGRP IGRP Lista parziale di Protocol Numbers La seguente tabella è un estratto di quella completa, disponibile sull'RFC1060 (Assigned Numbers).

  20. Generamente i gateway costruiscono e aiornano le tabelle di routing scambiando informazioni con i gateway che si trovano sulle reti adiacenti. Esistono vari protocolli che descrivono il modo in cui devono avvenire gli scambi di informazioni fra gateway. In un messaggio di routing normalmente un gateway invia ad altri gateway una lista di coppie (rete, distanza), che mostra quanto ciascuna "dista" dal gateway. I vari protocolli di routing differiscono fra loro soprattutto per il modo in cui viene calcolata e interpretata la distanza. Il Routing Information Protocol (RIP) è molto diffuso perchè fa parte della distribuzione Unix di Berkeley, ma è adatto solo a reti piccole con collegamenti a velocità omogenee. Alcuni Routing Protocol sono descritti sugli RFC, altri sono proprietari. Protocolli di routing

  21. I gateway di Internet sono raggruppatti in Autonomous Systems (AS), costititi da gateway che comunicano con lo stesso Routing Protocol. Per lo scambio di informazioni di routing fra gateway di AS distinti esiste l'Exterior Gateway Protocol (EGP, RFC904). L'EGP era stato pensato per una Internet costituita da un AS centrale (il Core) e tanti AS connessi direttamente al Core. E' estremamente difficile gestire l'attuale topologia di Internet con l'EGP. Il Border Gateway Protocol (BGP, RFC1105) non ha le limitazioni dell'EGP, ma è ancora nella fase sperimentale. Suddividendo Internet in vari AS si riesce, fra l'altro, a ridurre il numero di reti che deve essere mantenuto nelle tabelle di ciascun gateway. Autonomous Systems

  22. L'Address Resolution Protocol (ARP, RFC826) permette di evitare la costruzione manuale di tabelle di mapping sulle reti su cui esiste possibilità di broadcasting. Un host che vuole conoscere l'indirizzo nativo corrispondente ad un indirizzo Internet di un host su una rete adiacente invia la richiesta sulla rete con un pacchetto di broadcast. L'host che ha l'indirizzo Internet richiesto invia una risposta all'host richiedente. L'host richiedente trova l'indirizzo cercato nel campo Sender Address del pacchetto di risposta. ARP

  23. Il protocollo IP non garantisce la consegna dei datagram al destinatario. Per consentire la consegna della corretta succesione di dati al destinatario è stato definito il Transmission Control Protocol (TCP, RFC793). Varie applicazioni possono utilizzare i servizi TCP contemporaneamente sullo stesso host. Vengono distinte per mezzo del port number (16 bit). Alcuni Port Numbers sono riservati per determinate applicazioni. TCP

  24. Un'applicazione che intenda servirsi del TCP deve: 1. Mettersi in contatto col il programma TCP locale specificando il proprio Port Number. 2. Chiedere l'apertura di una connessione con un'applicazione TCP remota, specificandone Internet Address e Port Number (caso "Client") oppure Attendere l'arrivo di una richiesta di connessione dall'applicazione remota (caso "Server"). 3. Scambiare dati con il partner fino alla chiusura della connessione. 4. Provocare o prendere atto della chiusura della connessione. Utilizzo del TCP

  25. Alcune applicazioni particolari (es.: la consultazione del directory) possono funzoinare con un servizio di tipo datagram, senza l'overhead introdotto dal TCP per garantire l'affidabilità di un servizio Connection Oriented. Per queste applicazioni è stato definito lo User Datagram Protocol (UDP, RFC768). I pacchetti UDP, come i pacchetti TCP, sono trasportati nel campo dati dei datagram IP. Un campo importante dell'header UDP è il Port Number, che permette di distinguere fra più applicazioni UDP sullo stesso host. Le stazioni UDP, come quelle TCP, devono farsi conoscere al programma UDP locale specificando un Port Number. UDP

  26. Normalmente gli utenti identificano gli host remoti con un nome simbolico anziché con l'indirizzo Internet. In Internet i nomi simbolici vengono assegnati da autorità organizzate secondo una struttura gerarchica e vengono detti "domini". L'organizzazione gerarchica si riflette nella forma stessa del nome. es.: nome3.nome2.nome1.nome0 "nome0" viene detto "top level domain" e deve essere registrato presso lo SRI-NIC. L'autorità che ha registrato "nome0" è libera di assegnare nomi del tipo "*.nome0" e può a sua volta assegnare ad autorità di livello inferiore il dirito di assegnare nomi del tipo "*.nome1.nome0". Questo schema per l'assegnazione dei nomi è detto Domain Style Addressing ed è descritto nell'RFC920. Il DomainName System

  27. Sono accettati come top level domains i seguenti nomi: 1. I codici ISO di due lettere delle nazioni (es.: IT per l'Italia), 2. Codici di tre lettere che identificano la categoria dell'ente cui appartengono le risorse (es.: EDU per education, COM per commercial, ORG per organization, MIL per military, GOV per government, etc.). Il secondo tipo di calssificazione è particolarmente diffuso in Nord America, il primo nel resto del mondo. Il top level domain dell'Italia (IT) è stato registrato dall'istituto CNUCE di Pisa. Top Level Domains

  28. Anticamente la traduzione fra nomi simbolici e indirizzi Internet avveniva consultando un file (HOSTS.TXT) che doveva essere aggiornato periodicamente su tutti gli host della rete. Questo metodo è ancora usato su molte LAN che usano il TCP/IP senza essere su Internet. Su Internet la traduzione viene fatta consultando un archivio distribuito, cui accedono processi detti Name Server (RFC1032, RFC1033, RFC1034 e RFC1035). Ogni Name Server possiede gli archivi relativi a un sottoinsieme connesso dell'albero dei nomi (la "zona"). L'archivio di una zona contiene anche gli indirizzi dei Name Server delle zone subordinate. Name Server

  29. Ogni zona è un sottoalbero. Con il termine "Name Server di X.Y.Z" si indica un Name Server responsabile di un sottoalbero con radice X.Y.Z. La stessa zona è gestita usualmente da più di un Name Server. In questo caso gli archivi vengono aggiornati manualmente su un solo Name Server, detto primario. Gli altri Name Server, detti secondari, richiedono periodicamente al primario copie aggiornate degli archivi. I Name Server che conoscono l'indirizzo dei Name Server dei top level domain sono detto Root Name Server. I non-root Name Server devono conoscere l'indirizzo di qualche Name Server gerarchicamente superiore. Le Zone

  30. Un programma che deve tradurre un nome simbolico in indirizzo di Internet ricorre al Name Resolver locale. Il Name Resolver conosce gli indirizzi di uno o più Name Server non troppo distanti a cui inviare le interrogazioni. Se la interrogazione riguarda una risorsa fuori della zona del Name Server consultato, questo deve consultare i suoi archivi per scoprire il nome di un Name Server più vicino alla risorsa nell'albero gerarchico. L'interrogazione può essere passata a questo secondo Name Server, o il nome di questo può essere restituito al Name Resolver perché prosegua nella ricerca. Tutte le risposte dei Name Server hanno un "time to live" che indica per quanto tempo possono essere ritenute valide. Ciò permette ai Name Server di conservare le risposte relative a risorse di altre zone e di utilizzarle per rispondere a interrogazioni successive. Name Resolver

  31. Alcune applicazioni TCP particolarmente note sono: TELNET Telnet Protocol (RFC854). Permette il logon su host remoti. TN3270 È un TELNET Client presente su molti host ASCII, che provvede alla traduzione TTY-3270, consentendo il logon su host IBM. FTP File Transfer Protocol (RFC959). Permette di collegarsi con host remoti per trasferire files fra archivi remoti e archivi locali. Normalmente per acceder all'archivio di un utente remoto ocorre conoscerne la password, ma su molti host esistono archivi accessibili senza password in sola lettura ("anonymous FTP"). SMTP Simple Mail Transfer Protocol (RFC821). Permette di inviare posta a utenti su host remoti. Tutte queste applicazioni richiedono la presenza sull'host remoto del server corrispondente. Applicazioni TCP

  32. Generalmente chi scrive un messaggio di posta elettronica non si connette con il server remoto, ma interagisce con un agente locale che deposita il messaggio sullo spazio disco locale. Il "Client" SMTP generalmente è un "daemon", che legge i messaggi da disco e li trasmette ai destinatari stabilendo connessioni TCP con i "Server" SMTP remoti. Il "Client" SMTP trove le informazioni necessarie al corretto instradamento dei messaggi nella loro intestazione. L'RFC822 (Standard for the Format of Internet Text Messages) descrive il formato delle intestazioni dei messaggi da mandare via SMTP. Un tipico indirizzo RFC822 ha la forma "localpart@globalpart", dove generalmente "localpart" è il nome di uno user e "globalpart" il nome di un host (in forma Domain Style). L'RFC822 descrive anche campi che interessano solo gli utenti finali, quali la data, l'oggetto, etc. SMTP e RFC822

  33. I "Client" SMTP, prima di chiedere al Name Server l'Indirizzo Internet corrispondente a un nome simbolico, cercano un record di tipo MX con quel nome. Il valore del record MX contiene il nome di un altro host Internet in grado di consegnare la posta al destinatario. I record MX sono descritti sull'RFC974 (Mail Routing and the Domain System). I record MX permettono di inviare posta da Internet ad altre reti (l'MX record deve puntare a un mail gateway) o a PC che si connetto a Internet saltuariamente. L'RFC987 (Mapping between X.400 and RFC822) descrive il funzionamento dei gateway fra posta RFC822 e posta X.400. Esistono già in funzione alcuni gateway RFC987. Record MX

  34. Sono stati definiti due protocolli di management per le reti TCP/IP: SNMP Simple Network Management Protocol (RFC1157). CMOT Common Management Information Services and Protocol over TCP/IP (RFC1095). Entrambi i protocolli prevedono un agent sull'oggetto da controllare e un manager sulla stazione che controlla la rete. Quasi tutti gli oggetti critici (es.: i router) di recente produzione contengono l'agent SNMP. Esiste già un certo numero di prodotti per fare il management SNMP. Il CMOT è il protocollo di management dell'OSI usato sopra il TCP. Attualmente è poco usato perché il MIB (Management Information Base) dell'OSI è solo parzialmente definito. Network Management

More Related