Enviar pesquisa
Carregar
Dublin addressingtheproblem131224
•
1 gostou
•
1,317 visualizações
ICT PRISTINE
Seguir
RINA Workshop 2
Leia menos
Leia mais
Internet
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 51
Baixar agora
Baixar para ler offline
Recomendados
4 addressing theory130115
4 addressing theory130115
Eleni Trouva
Lost layer talk 2014
Lost layer talk 2014
ICT PRISTINE
3 addressingthe problem130123
3 addressingthe problem130123
Eleni Trouva
5 mngmt idd130115
5 mngmt idd130115
ARCFIRE ICT
6 security130123
6 security130123
ICT PRISTINE
RINA Introduction, part II
RINA Introduction, part II
ICT PRISTINE
1 lost layer130123
1 lost layer130123
ARCFIRE ICT
Dublin mngmt140120
Dublin mngmt140120
ICT PRISTINE
Recomendados
4 addressing theory130115
4 addressing theory130115
Eleni Trouva
Lost layer talk 2014
Lost layer talk 2014
ICT PRISTINE
3 addressingthe problem130123
3 addressingthe problem130123
Eleni Trouva
5 mngmt idd130115
5 mngmt idd130115
ARCFIRE ICT
6 security130123
6 security130123
ICT PRISTINE
RINA Introduction, part II
RINA Introduction, part II
ICT PRISTINE
1 lost layer130123
1 lost layer130123
ARCFIRE ICT
Dublin mngmt140120
Dublin mngmt140120
ICT PRISTINE
RINA: Recursive Inter Network Architecture
RINA: Recursive Inter Network Architecture
Miguel Ponce de Leon @ TSSG / Waterford Institute of Technology
RINA Tutorial @ IEEE Globecom 2014
RINA Tutorial @ IEEE Globecom 2014
Eleni Trouva
Lecture 1 4
Lecture 1 4
Hasam Panezai
P2P Seminar
P2P Seminar
CoRehab
Layers of tcpip.65 to 66
Layers of tcpip.65 to 66
myrajendra
Net essentials6e ch3
Net essentials6e ch3
APSU
Unit 4
Unit 4
Krishnakumar Btech
Scaling Streaming - Concepts, Research, Goals
Scaling Streaming - Concepts, Research, Goals
kamaelian
Internet architecture protocol
Internet architecture protocol
GLIM Digital
Tutorial Jaringan komputer
Tutorial Jaringan komputer
Agus Kurniawan
Bcs 052 solved assignment
Bcs 052 solved assignment
Indira Gnadhi National Open University (IGNOU)
protocol architecture
protocol architecture
Srinivasa Rao
PACE-IT: Introduction to IPv6 - N10 006
PACE-IT: Introduction to IPv6 - N10 006
Pace IT at Edmonds Community College
The TCP/IP and OSI models
The TCP/IP and OSI models
Jake Weaver
PACE-IT: DHCP in the Network - N10 006
PACE-IT: DHCP in the Network - N10 006
Pace IT at Edmonds Community College
PACE-IT: Intro to the DNS Service - N10 006
PACE-IT: Intro to the DNS Service - N10 006
Pace IT at Edmonds Community College
PACE-IT: Introduction to IPv4 (part 1) - N10 006
PACE-IT: Introduction to IPv4 (part 1) - N10 006
Pace IT at Edmonds Community College
Report
Report
Ranjitha Gurunath Kulkarni
Networking Basics - Ferdon
Networking Basics - Ferdon
Susan Ferdon
Pristine rina-tnc-2016
Pristine rina-tnc-2016
ICT PRISTINE
RINA Introduction, part I
RINA Introduction, part I
ICT PRISTINE
A Wake-Up Call for IoT
A Wake-Up Call for IoT
Ahmed Banafa
Mais conteúdo relacionado
Mais procurados
RINA: Recursive Inter Network Architecture
RINA: Recursive Inter Network Architecture
Miguel Ponce de Leon @ TSSG / Waterford Institute of Technology
RINA Tutorial @ IEEE Globecom 2014
RINA Tutorial @ IEEE Globecom 2014
Eleni Trouva
Lecture 1 4
Lecture 1 4
Hasam Panezai
P2P Seminar
P2P Seminar
CoRehab
Layers of tcpip.65 to 66
Layers of tcpip.65 to 66
myrajendra
Net essentials6e ch3
Net essentials6e ch3
APSU
Unit 4
Unit 4
Krishnakumar Btech
Scaling Streaming - Concepts, Research, Goals
Scaling Streaming - Concepts, Research, Goals
kamaelian
Internet architecture protocol
Internet architecture protocol
GLIM Digital
Tutorial Jaringan komputer
Tutorial Jaringan komputer
Agus Kurniawan
Bcs 052 solved assignment
Bcs 052 solved assignment
Indira Gnadhi National Open University (IGNOU)
protocol architecture
protocol architecture
Srinivasa Rao
PACE-IT: Introduction to IPv6 - N10 006
PACE-IT: Introduction to IPv6 - N10 006
Pace IT at Edmonds Community College
The TCP/IP and OSI models
The TCP/IP and OSI models
Jake Weaver
PACE-IT: DHCP in the Network - N10 006
PACE-IT: DHCP in the Network - N10 006
Pace IT at Edmonds Community College
PACE-IT: Intro to the DNS Service - N10 006
PACE-IT: Intro to the DNS Service - N10 006
Pace IT at Edmonds Community College
PACE-IT: Introduction to IPv4 (part 1) - N10 006
PACE-IT: Introduction to IPv4 (part 1) - N10 006
Pace IT at Edmonds Community College
Report
Report
Ranjitha Gurunath Kulkarni
Networking Basics - Ferdon
Networking Basics - Ferdon
Susan Ferdon
Mais procurados
(19)
RINA: Recursive Inter Network Architecture
RINA: Recursive Inter Network Architecture
RINA Tutorial @ IEEE Globecom 2014
RINA Tutorial @ IEEE Globecom 2014
Lecture 1 4
Lecture 1 4
P2P Seminar
P2P Seminar
Layers of tcpip.65 to 66
Layers of tcpip.65 to 66
Net essentials6e ch3
Net essentials6e ch3
Unit 4
Unit 4
Scaling Streaming - Concepts, Research, Goals
Scaling Streaming - Concepts, Research, Goals
Internet architecture protocol
Internet architecture protocol
Tutorial Jaringan komputer
Tutorial Jaringan komputer
Bcs 052 solved assignment
Bcs 052 solved assignment
protocol architecture
protocol architecture
PACE-IT: Introduction to IPv6 - N10 006
PACE-IT: Introduction to IPv6 - N10 006
The TCP/IP and OSI models
The TCP/IP and OSI models
PACE-IT: DHCP in the Network - N10 006
PACE-IT: DHCP in the Network - N10 006
PACE-IT: Intro to the DNS Service - N10 006
PACE-IT: Intro to the DNS Service - N10 006
PACE-IT: Introduction to IPv4 (part 1) - N10 006
PACE-IT: Introduction to IPv4 (part 1) - N10 006
Report
Report
Networking Basics - Ferdon
Networking Basics - Ferdon
Destaque
Pristine rina-tnc-2016
Pristine rina-tnc-2016
ICT PRISTINE
RINA Introduction, part I
RINA Introduction, part I
ICT PRISTINE
A Wake-Up Call for IoT
A Wake-Up Call for IoT
Ahmed Banafa
IRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OS
ICT PRISTINE
10 myths about cloud computing
10 myths about cloud computing
Ahmed Banafa
Assuring QoS Guarantees for Heterogeneous Services in RINA Networks with ΔQ
Assuring QoS Guarantees for Heterogeneous Services in RINA Networks with ΔQ
ICT PRISTINE
The hague rina-workshop-welcome-miguel
The hague rina-workshop-welcome-miguel
ICT PRISTINE
The hague rina-workshop-congestioncontrol-peyman
The hague rina-workshop-congestioncontrol-peyman
ICT PRISTINE
The hague rina-workshop-nfv-diego
The hague rina-workshop-nfv-diego
ICT PRISTINE
Congestion Control in Recursive Network Architectures
Congestion Control in Recursive Network Architectures
ICT PRISTINE
Rina sim workshop
Rina sim workshop
ICT PRISTINE
The hague rina-workshop-interop-deployment_vincenzo
The hague rina-workshop-interop-deployment_vincenzo
ICT PRISTINE
The hague rina-workshop-mobility-eduard
The hague rina-workshop-mobility-eduard
ICT PRISTINE
Th hauge rina-workshop-sdn-virtualisation_neil
Th hauge rina-workshop-sdn-virtualisation_neil
ICT PRISTINE
Rina acc-icc16-stein
Rina acc-icc16-stein
ICT PRISTINE
Pristine rina-sdk-icc-2016
Pristine rina-sdk-icc-2016
ICT PRISTINE
The hageu rina-workshop-security-peter
The hageu rina-workshop-security-peter
ICT PRISTINE
Pristine rina-security-icc-2016
Pristine rina-security-icc-2016
ICT PRISTINE
Irati goals and achievements - 3rd RINA Workshop
Irati goals and achievements - 3rd RINA Workshop
Eleni Trouva
Anomaly detection and root cause analysis in distributed application transact...
Anomaly detection and root cause analysis in distributed application transact...
Yuchen Zhao
Destaque
(20)
Pristine rina-tnc-2016
Pristine rina-tnc-2016
RINA Introduction, part I
RINA Introduction, part I
A Wake-Up Call for IoT
A Wake-Up Call for IoT
IRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OS
10 myths about cloud computing
10 myths about cloud computing
Assuring QoS Guarantees for Heterogeneous Services in RINA Networks with ΔQ
Assuring QoS Guarantees for Heterogeneous Services in RINA Networks with ΔQ
The hague rina-workshop-welcome-miguel
The hague rina-workshop-welcome-miguel
The hague rina-workshop-congestioncontrol-peyman
The hague rina-workshop-congestioncontrol-peyman
The hague rina-workshop-nfv-diego
The hague rina-workshop-nfv-diego
Congestion Control in Recursive Network Architectures
Congestion Control in Recursive Network Architectures
Rina sim workshop
Rina sim workshop
The hague rina-workshop-interop-deployment_vincenzo
The hague rina-workshop-interop-deployment_vincenzo
The hague rina-workshop-mobility-eduard
The hague rina-workshop-mobility-eduard
Th hauge rina-workshop-sdn-virtualisation_neil
Th hauge rina-workshop-sdn-virtualisation_neil
Rina acc-icc16-stein
Rina acc-icc16-stein
Pristine rina-sdk-icc-2016
Pristine rina-sdk-icc-2016
The hageu rina-workshop-security-peter
The hageu rina-workshop-security-peter
Pristine rina-security-icc-2016
Pristine rina-security-icc-2016
Irati goals and achievements - 3rd RINA Workshop
Irati goals and achievements - 3rd RINA Workshop
Anomaly detection and root cause analysis in distributed application transact...
Anomaly detection and root cause analysis in distributed application transact...
Semelhante a Dublin addressingtheproblem131224
3 addressingthe problem130123
3 addressingthe problem130123
ARCFIRE ICT
How it works internet networking icann53
How it works internet networking icann53
ICANN
Vtc keynote201110
Vtc keynote201110
Eduard Grasa
Pace IT - Introduction to IPv6
Pace IT - Introduction to IPv6
Pace IT at Edmonds Community College
IP address and Domain name
IP address and Domain name
University of Technology - Iraq
In Defence of NATs
In Defence of NATs
APNIC
What is IPv6?
What is IPv6?
E-Lins Technology Co. Ltd.
Computing powerpoint
Computing powerpoint
Charlotte Mort
Micheal O'Foghlu - TSSG
Micheal O'Foghlu - TSSG
IPv6 Summit 2010
IPv6 Connectivity: Why does my organization need it?
IPv6 Connectivity: Why does my organization need it?
SwiftTech Solutions, Inc.
How is the transition between IPv4 and IPv6 being handled Is it bei.pdf
How is the transition between IPv4 and IPv6 being handled Is it bei.pdf
fsenterprises
The Internet
The Internet
ajf0310
An IPv6 Primer
An IPv6 Primer
Carlos Martinez Cagnazzo
Evolution of network - computer networks
Evolution of network - computer networks
SabarishSanjeevi
4 addressing theory130115
4 addressing theory130115
ARCFIRE ICT
6 security130123
6 security130123
ARCFIRE ICT
Basic Foundation For Cybersecurity
Basic Foundation For Cybersecurity
Mohammed Adam
The internet
The internet
joseph0914
OSI ModelMany people use expressions or sentences to remember th.docx
OSI ModelMany people use expressions or sentences to remember th.docx
MARRY7
Introduction to Computer Networking
Introduction to Computer Networking
Amit Saha
Semelhante a Dublin addressingtheproblem131224
(20)
3 addressingthe problem130123
3 addressingthe problem130123
How it works internet networking icann53
How it works internet networking icann53
Vtc keynote201110
Vtc keynote201110
Pace IT - Introduction to IPv6
Pace IT - Introduction to IPv6
IP address and Domain name
IP address and Domain name
In Defence of NATs
In Defence of NATs
What is IPv6?
What is IPv6?
Computing powerpoint
Computing powerpoint
Micheal O'Foghlu - TSSG
Micheal O'Foghlu - TSSG
IPv6 Connectivity: Why does my organization need it?
IPv6 Connectivity: Why does my organization need it?
How is the transition between IPv4 and IPv6 being handled Is it bei.pdf
How is the transition between IPv4 and IPv6 being handled Is it bei.pdf
The Internet
The Internet
An IPv6 Primer
An IPv6 Primer
Evolution of network - computer networks
Evolution of network - computer networks
4 addressing theory130115
4 addressing theory130115
6 security130123
6 security130123
Basic Foundation For Cybersecurity
Basic Foundation For Cybersecurity
The internet
The internet
OSI ModelMany people use expressions or sentences to remember th.docx
OSI ModelMany people use expressions or sentences to remember th.docx
Introduction to Computer Networking
Introduction to Computer Networking
Mais de ICT PRISTINE
Benefits of programmable topological routing policies in RINA-enabled large s...
Benefits of programmable topological routing policies in RINA-enabled large s...
ICT PRISTINE
The hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduard
ICT PRISTINE
Eucnc rina-tutorial
Eucnc rina-tutorial
ICT PRISTINE
2016 06-10-ieee-sdn (1)
2016 06-10-ieee-sdn (1)
ICT PRISTINE
RINA essentials, PISA Internet Festival 2015
RINA essentials, PISA Internet Festival 2015
ICT PRISTINE
SFR: Scalable Forwarding with RINA for Distributed Clouds
SFR: Scalable Forwarding with RINA for Distributed Clouds
ICT PRISTINE
Pristine glif 2015
Pristine glif 2015
ICT PRISTINE
Reconstructing computer networking with RINA: how solid scientific foundation...
Reconstructing computer networking with RINA: how solid scientific foundation...
ICT PRISTINE
RINA as a Clean-Slate Approach to Software Networks
RINA as a Clean-Slate Approach to Software Networks
ICT PRISTINE
EC Net Tech FI Cluster meeting October 23 2014 PRISTINE
EC Net Tech FI Cluster meeting October 23 2014 PRISTINE
ICT PRISTINE
Mais de ICT PRISTINE
(10)
Benefits of programmable topological routing policies in RINA-enabled large s...
Benefits of programmable topological routing policies in RINA-enabled large s...
The hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduard
Eucnc rina-tutorial
Eucnc rina-tutorial
2016 06-10-ieee-sdn (1)
2016 06-10-ieee-sdn (1)
RINA essentials, PISA Internet Festival 2015
RINA essentials, PISA Internet Festival 2015
SFR: Scalable Forwarding with RINA for Distributed Clouds
SFR: Scalable Forwarding with RINA for Distributed Clouds
Pristine glif 2015
Pristine glif 2015
Reconstructing computer networking with RINA: how solid scientific foundation...
Reconstructing computer networking with RINA: how solid scientific foundation...
RINA as a Clean-Slate Approach to Software Networks
RINA as a Clean-Slate Approach to Software Networks
EC Net Tech FI Cluster meeting October 23 2014 PRISTINE
EC Net Tech FI Cluster meeting October 23 2014 PRISTINE
Último
Magic exist by Marta Loveguard - presentation.pptx
Magic exist by Marta Loveguard - presentation.pptx
MartaLoveguard
Elevate Your Business with Our IT Expertise in New Orleans
Elevate Your Business with Our IT Expertise in New Orleans
corenetworkseo
Q4-1-Illustrating-Hypothesis-Testing.pptx
Q4-1-Illustrating-Hypothesis-Testing.pptx
editsforyah
定制(AUT毕业证书)新西兰奥克兰理工大学毕业证成绩单原版一比一
定制(AUT毕业证书)新西兰奥克兰理工大学毕业证成绩单原版一比一
Fs
Call Girls In The Ocean Pearl Retreat Hotel New Delhi 9873777170
Call Girls In The Ocean Pearl Retreat Hotel New Delhi 9873777170
Sonam Pathan
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
rnrncn29
Blepharitis inflammation of eyelid symptoms cause everything included along w...
Blepharitis inflammation of eyelid symptoms cause everything included along w...
Excelmac1
young call girls in Uttam Nagar🔝 9953056974 🔝 Delhi escort Service
young call girls in Uttam Nagar🔝 9953056974 🔝 Delhi escort Service
9953056974 Low Rate Call Girls In Saket, Delhi NCR
SCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is predi
eusebiomeyer
办理多伦多大学毕业证成绩单|购买加拿大UTSG文凭证书
办理多伦多大学毕业证成绩单|购买加拿大UTSG文凭证书
zdzoqco
Film cover research (1).pptxsdasdasdasdasdasa
Film cover research (1).pptxsdasdasdasdasdasa
494f574xmv
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
rnrncn29
Top 10 Interactive Website Design Trends in 2024.pptx
Top 10 Interactive Website Design Trends in 2024.pptx
Dyna Gilbert
定制(Management毕业证书)新加坡管理大学毕业证成绩单原版一比一
定制(Management毕业证书)新加坡管理大学毕业证成绩单原版一比一
Fs
Font Performance - NYC WebPerf Meetup April '24
Font Performance - NYC WebPerf Meetup April '24
Paul Calvano
NSX-T and Service Interfaces presentation
NSX-T and Service Interfaces presentation
Marko4394
办理(UofR毕业证书)罗切斯特大学毕业证成绩单原版一比一
办理(UofR毕业证书)罗切斯特大学毕业证成绩单原版一比一
z xss
PHP-based rendering of TYPO3 Documentation
PHP-based rendering of TYPO3 Documentation
LinaWolf1
定制(Lincoln毕业证书)新西兰林肯大学毕业证成绩单原版一比一
定制(Lincoln毕业证书)新西兰林肯大学毕业证成绩单原版一比一
Fs
Call Girls Near The Suryaa Hotel New Delhi 9873777170
Call Girls Near The Suryaa Hotel New Delhi 9873777170
Sonam Pathan
Último
(20)
Magic exist by Marta Loveguard - presentation.pptx
Magic exist by Marta Loveguard - presentation.pptx
Elevate Your Business with Our IT Expertise in New Orleans
Elevate Your Business with Our IT Expertise in New Orleans
Q4-1-Illustrating-Hypothesis-Testing.pptx
Q4-1-Illustrating-Hypothesis-Testing.pptx
定制(AUT毕业证书)新西兰奥克兰理工大学毕业证成绩单原版一比一
定制(AUT毕业证书)新西兰奥克兰理工大学毕业证成绩单原版一比一
Call Girls In The Ocean Pearl Retreat Hotel New Delhi 9873777170
Call Girls In The Ocean Pearl Retreat Hotel New Delhi 9873777170
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
Blepharitis inflammation of eyelid symptoms cause everything included along w...
Blepharitis inflammation of eyelid symptoms cause everything included along w...
young call girls in Uttam Nagar🔝 9953056974 🔝 Delhi escort Service
young call girls in Uttam Nagar🔝 9953056974 🔝 Delhi escort Service
SCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is predi
办理多伦多大学毕业证成绩单|购买加拿大UTSG文凭证书
办理多伦多大学毕业证成绩单|购买加拿大UTSG文凭证书
Film cover research (1).pptxsdasdasdasdasdasa
Film cover research (1).pptxsdasdasdasdasdasa
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
Top 10 Interactive Website Design Trends in 2024.pptx
Top 10 Interactive Website Design Trends in 2024.pptx
定制(Management毕业证书)新加坡管理大学毕业证成绩单原版一比一
定制(Management毕业证书)新加坡管理大学毕业证成绩单原版一比一
Font Performance - NYC WebPerf Meetup April '24
Font Performance - NYC WebPerf Meetup April '24
NSX-T and Service Interfaces presentation
NSX-T and Service Interfaces presentation
办理(UofR毕业证书)罗切斯特大学毕业证成绩单原版一比一
办理(UofR毕业证书)罗切斯特大学毕业证成绩单原版一比一
PHP-based rendering of TYPO3 Documentation
PHP-based rendering of TYPO3 Documentation
定制(Lincoln毕业证书)新西兰林肯大学毕业证成绩单原版一比一
定制(Lincoln毕业证书)新西兰林肯大学毕业证成绩单原版一比一
Call Girls Near The Suryaa Hotel New Delhi 9873777170
Call Girls Near The Suryaa Hotel New Delhi 9873777170
Dublin addressingtheproblem131224
1.
© John Day,
2013 1 Rights Reserved The Pouzin Society We Got Trouble! Right Here in River City With a capital T and that Rhymes with P and That Stands for IP! John Day Dublin 2014 It doesn’t have to make sense. It’s religion! - Robbie Coltrane Nuns on the Run
2.
© John Day,
2013 2 Rights Reserved The Pouzin Society As the Song Says • Most of our Troubles start with IP • And the Lack of a Complete Addressing Structure • To Understand Why this is the case, we need to go back in time, back to . . .
3.
© John Day,
2013 3 Rights Reserved The Pouzin Society Addressing in the ARPANET The Root Cause of our Problems IMP 56K Trunk 56K Trunk 56K Trunk 56K Trunk Host Host Host Host Each ARPANet IMP (switch) had ports to support a maximum of 4 trunks and 4 hosts. Each IMP had a number. The host address (IP address) was the IMP # and the Host #, i.e. a port number. Maximum number of hosts was huge: 63. So a host’s address was its IMP Port Number.
4.
© John Day,
2013 4 Rights Reserved The Pouzin Society Was There a Reason? Was there a lot of thought given to how addressing should work? Not really. We were doing good to do this much! There were many much bigger problems to overcome: Like just moving data And addressing is a hard problem. Sure It was easy to build for an experimental network of this size.
5.
© John Day,
2013 5 Rights Reserved The Pouzin Society Did it take long to realize there was a problem? IMP 14 IMP 20 14, 1 20, 3 Host Nope. First time (~ 1972) one of the Air Force bases took us at our word that the network was suppose to be survivable and asked for links to two different IMPs to connect its host to the Network. Naming the hosts by the names of their interfaces meant that the two connections looked like two hosts to the Net. Still does.
6.
© John Day,
2013 6 Rights Reserved The Pouzin Society Address Spaces in Operating Systems (From my OS Course) An name space is defined as a set of identifiers with a given scope. An address space is a location-dependent name space. In Operating Systems, we have found a need for 3 such independent spaces. Virtually all uses of names in computing are for locating. Application Name Space Logical Name Space Physical Name Space Human use, relatively constant, not at all tied to the hardware, i.e. location-independent Location Dependent but Hardware Independent; Creates a logical address space larger than the physical memory; Allows processes to be re-locatable. Location-Dependent and Hardware Dependent
7.
© John Day,
2013 7 Rights Reserved The Pouzin Society Saltzer s View of Networks • Application names map to node addresses. • Node addresses map to points of attachment addresses. • Routes are sequences of points of attachments. – Just as in an operating system. Application Name Node Address Point of Attachment Address
8.
© John Day,
2013 8 Rights Reserved The Pouzin Society But Networks Are More General • Directory maintains the mapping between Application-Names and the node addresses of all Applications reachable without an application relay. • Routes are sequences of node addresses used to compute the next hop. • Node to point of attachment mapping for all nearest neighbors to choose path to next hop. (Even though Saltzer notices this case, he misses its importance.) • This last mapping and the Directory are the same: – Mapping of a name in the layer above to a name in the layer below of all nearest neighbors. Directory Route Path Here And Here
9.
© John Day,
2013 9 Rights Reserved The Pouzin Society Applying Results to Real Architectures: The Internet (This is a Data Comm Architecture) • The most striking feature is that half of the addressing architecture is missing. – No wonder there are addressing problems. – The only identifier we have for anything is the IP address. • There are no node addresses and no application names. – And the point of attachment is named twice! – If this is an Internet Protocol, where are the Network Addresses? (Lost Layer) – Domain Names are synonyms for IP addresses. URLs name a path to an arbitrary instance of an application. MAC Address IP Address Socket (local) Application Application Name Node Address Point of Attachment Address As if your computer worked only with absolute memory addresses.
10.
© John Day,
2013 10 Rights Reserved The Pouzin Society There is An Easier Way to See It. • Route on the address in your layer! – Well, duh! – Routing on the Interface is routing on the address in the layer below. • Learned a couple of other things along the way – Addresses only need to be unique within the scope of a layer – Addresses must generally be assigned by the network because it is the only one that knows where in the network the node is. – Don t concatenate an (N)-identifier with an (N-1) address to form an (N)- address. Physical Data Link Network Transport Application Host or End System Router Points of attachment Nodes
11.
© John Day,
2013 11 Rights Reserved The Pouzin Society If This Were an Internet Architecture, Then • There would be multiple Data Link Layers with limited scope. • Network Layers with greater scope that did intra-domain routing • Internet Layer with greater scope yet that did intra-domain routing. • Network Layer addresses would be interface addresses for the Internet nodes. • That brings us to the first Internet [sic] addressing crisis. Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host
12.
© John Day,
2013 12 Rights Reserved The Pouzin Society The First Great Internet Addressing Crisis • In 1992, we have the first addressing crisis. – IPv4 addresses are getting scarce • But the real problem is Router Table Size is increasing exponentially. • The IAB convenes the ROAD process – Recommends CLNP as IPv7 • Basically IP with variable length aggregateable addresses. • CLNP names the node. Hence, fixes the multihoming problem. – Oddly enough, OSI has an Internet architecture, but doesn’t draw attention to it. • The IETF goes berserk! – No OSI, no way, no how! • A model? We don’t need no stinking model. We ve got • Rough Consensus and Running Code!
13.
© John Day,
2013 13 Rights Reserved The Pouzin Society The IPng Process • The Rules were: – Fixed Length Address – Continue to Name the Interface. – At least 20 octets of address – Open Standard • Violá! IPv6! • or anything but CLNP. • Still no solution to multihoming – Problem is now 20 years old
14.
© John Day,
2013 14 Rights Reserved The Pouzin Society All is Not Well • Less than a Year later, light dawns (slightly)! – Name the Interface, but route aggregation is a must – Implies provider based assignment. – Means change providers, must renumber. WHAT!? • Kind of shot yourself in the foot, eh? • Transition is dual stack with a NAT – Once you have a NAT, you don t need v6 . . . oops. • How many feet do you have?
15.
© John Day,
2013 15 Rights Reserved The Pouzin Society Techs Play Architect • Finally around 2000, need to deal with multihoming, but – given negative reaction to naming the node, need a workaround • Ahh! The problem is that we have been overloading the semantics of the IP address with location and identifier information. – We need to split them. Loc/id split is the Answer. – A locator we can route on and a flat endpoint id (EID) • Psssst! Can’t identify something without locating it and vice versa – Saltzer [1977] defines resolve as in “resolving a name as “to locate an object in a particular context, given its name. • Got another foot? • Don’t bother me with pedantic terminology, – IPv6 is the future!
16.
© John Day,
2013 16 Rights Reserved The Pouzin Society Trouble is Not Much Interest in v6 • It offers no benefit to those who pay for adopting it – They just don’t know they want it. • For the next decade, there is the hype: – Better security, better QoS, better mobility – A desert topping and a floor wax! - Mike O’Dell • In fact, all of these are the same as IPv4 . . . no different • IPv6 has all the benefit of a minor technology change with all the disruption of a major fork-lift upgrade. - Geoff Huston, 2008. – Just switch to v6 and all will be well. • By 2000, dawning awareness the architecture is running out of steam – NEWARCH, Clean Slate, FIND and GENI are hot! – Starts to be a lot of talk about loc/id split. – This is clearly the answer . . . . (really?).
17.
© John Day,
2013 17 Rights Reserved The Pouzin Society Houston, We Have a Problem (The Second Great Internet Addressing Crisis) • October 2006, major presentation at IEPG. – Router table size is on the increase, due to multihoming. • It is either quadratic or exponential, can t tell yet. – (does it matter!?) – Moore’s Law won’t bail us out this time. • This is a big time crisis. We are in big trouble. • If not fixed, it is the end of the Internet as we know it. – Net will fragment. Costs in the core will skyrocket. – NetworkWorld sits on the story for a year. – Tons of papers written on loc/id split!
18.
© John Day,
2013 18 Rights Reserved The Pouzin Society But We Do Multihoming! (not really) • We kludge it. • Because we route on the interface, this forces route aggregation to be provider-based. – Addresses with a common prefix go to the same provider then we can store a single route (to the provider) rather than a route for every address on that provider. • To do multihoming, must assign provider-independent addresses or new AS numbers (same thing). – Can’t be aggregated Router table size increases – Remember what our problem is? Router table size is increasing
19.
© John Day,
2013 19 Rights Reserved The Pouzin Society So Why Wasn’t It Fixed? • Odd that a DoD network touted to survive nuclear attack didn’t support redundant links. Lots of good reasons: – Not that many hosts need to be multi-homed. • Not then, but the ones that did were the ones everyone wanted to get to. – Not everyone should have to bear the cost for a few. • Classic committee politics: Put a condition on the solution that guarantees any proposal will be rejected (asymmetry in this case) • Also assumes there is a cost. – Multihoming will be to different providers, so no point. • Assumption is wrong and even if right assumes a static network. – Remember, we tried to fix it but it was rejected by the IETF.
20.
© John Day,
2013 20 Rights Reserved The Pouzin Society But By This Time • Cisco and others start proposing solutions to the multihoming problem. – Mostly requiring patches involving NATs and a bevy of new protocols. – In particular, LISP or Loc/ID Split Protocol • This makes everyone nervous, but what else to do? • Well, we could work out a theoretical framework to see what is going on. • This is a crisis! We have to build something! • Best way known to stampede people to your view.
21.
© John Day,
2013 21 Rights Reserved The Pouzin Society November 2008 Houston, We have a Bigger Problem • Dave Meyer calls, I have an architectural issue to discuss. – He has come across two problems in implementing LISP. – Both require doing path discovery. – Path discovery doesn’t scale. – LISP won’t scale. QED – He suspects that any loc/id approach will have the same problem. • draft-meyer-loc-id-implications-01.txt • In case you didn’t notice, we just went to DefCon1 • Dave: Why hasn’t anyone noticed this in the last 15 years?
22.
© John Day,
2013 22 Rights Reserved The Pouzin Society Dave is Right • All proposals based on loc/id split have the same flaw. • Once put in the context of the RINA theory, it is obvious. • Let us look at it very carefully. What do the locator and the identifier name? Endpoint Identifier Locators The Locator Locates the Wrong Thing! The locator is part of the path, not the final destination. No wonder Dave ran into path discovery issues. (Beads-on-a-string again: wires connecting boxes!)
23.
© John Day,
2013 23 Rights Reserved The Pouzin Society Apply the e2e principle! (the answer to everything) Solve the Problem in the Hosts • There are poor misguided souls claiming this. – Mostly done by changing the definition of multihoming. – Ignore that it might take seconds if not minutes to do the failover. • Remember the fundamental problem is that the network doesn’t know that two paths go to the same place. – This is a problem of delivering, not sending. – There is no host-based solution. • There is no solution as long as one routes only on the interface address. Which means . . .
24.
© John Day,
2013 24 Rights Reserved The Pouzin Society If Loc/ID Doesn’t Scale • Then there is no solution involving routing on the interface that scales. • In other words, • But we saw that coming a long time ago. IP is Fundamentally Flawed (v4 or v6)
25.
© John Day,
2013 25 Rights Reserved The Pouzin Society Wanna Hear the Real P*sser? • We had the right answer in 1992. • The answer we had known since 1972. – It was rejected by the IETF. • And to add insult to injury, it was DEPLOYED and Operational in the routers. – We could have spent the last 15 years working on transition – Rather than 100s of millions on a small incremental step that provides no benefit to your bottom line and is fundamentally flawed. – You just can’t make this stuff up!
26.
© John Day,
2013 26 Rights Reserved The Pouzin Society The Problem was Never Separating Locator from Identifier. It was always about Separating Logical Location from Physical Location • It is impossible to locate something without also identifying it. • This pseudo-problem arises from not having a complete address architecture. – And creates enough epicycles upon epicycles to make Clavius proud • But we will give O’Dell the last word: – When all you have is a hammer, everything looks like your thumb • It is still more like DOS than anything else. Location dependent, Route independent Route Dependent Location Independence Application Name Space Logical Name Space Physical Name Space Application Name Node Address Point of Attachment
27.
© John Day,
2013 27 Rights Reserved The Pouzin Society Addressing In RINA • All identifiers are based on the nature of the application process or in this case, the IPC Process. • First, lets look in brief:
28.
© John Day,
2013 28 Rights Reserved The Pouzin Society Applications and Communication • The Application-Entity (AE) is that part of the application concerned with communication, i.e. shared state with its peer. • The rest of the Application Process is concerned with the reason for the application in the first place. • An Application Process may have multiple AEs, they assumed, for different application protocols. – An HTTP library linked into a web browser is an AE; FTP is another. Application Process Application-Entities
29.
© John Day,
2013 29 Rights Reserved The Pouzin Society Application Naming • Application-process names (APN) are globally unambiguous and location-independent, but system-dependent. – They may have synonyms of less scope from the same or different name space. – There may be multiple instances of the process in the same system. • APN-instance-identifiers are unambiguous within the scope of the Application Process. • Application-entity-identifiers are unambiguous within the application process. – There may be more than one Application-entity (AE) in a process. • Unambiguous within the scope of the Application Process. – There may be more than one instance of each type of Application-Entity. • AE-instance-identifiers are unambiguous within the scope of the AE. • Distributed Application Name is the name of a set of application processes and system- independent. • Few applications need all of these but a complete theory requires all of them. Application Process Application-Entities
30.
© John Day,
2013 30 Rights Reserved The Pouzin Society What Good is All This? • Many capabilities not possible today or that require specific protocols are a consequence of naming and enabled by a complete architecture. – Handing off a connection from one system to another; – The need to pass IP addresses among applications is avoided; – Opening multiple connections with different protocols to the same instance of an application process. – Connecting to an existing conference call, etc. – And probably 1000s of things we haven’t thought of yet. Application Process Application-Entities
31.
© John Day,
2013 31 Rights Reserved The Pouzin Society Naming in RINA • IPC Process-name is just an application-process-name – An address is a synonym for an IPC Process whosescope is restricted to the DIF and maybe structured to facilitate use within the DIF. • A port-id is a Flow-Allocator-Instance-Id, an AE instance. • A connection-endpoint-id (CEP-id) is an EFCP-instance-id, an AE instance. • Note that these are local to the IPC Process. • A connection-id is created by concatenating source and destination CEP-ids. • That’s It! IPC Management Common Application Protocol Resource Allocation RIB Daemon IRM RMT EFCP Flow Allocator IPC Process
32.
© John Day,
2013 32 Rights Reserved The Pouzin Society Routing at Different Layers • With a Recursive Model, there are levels of routing with border routers acting as the step-down function creating interior flows. • This tends toward a “necklace” configuration. Hosts Interior Routers Border Routers
33.
© John Day,
2013 33 Rights Reserved The Pouzin Society Implications of the Model Names (Routing Table Size) • Recursion either reduces the number of routes or shortens them. Backbone Regionals Metros
34.
© John Day,
2013 34 Rights Reserved The Pouzin Society Implications of the Model Names (Routing Table Size) • For the Internet O((6r)2 where r is the number of routers in the network. Non-topological T opological Metros-DIF 3 O ( ( 2 D n)2 ) O ( ( D m)2 ) where n is the number of hosts and m is the number of hosts and border routers on a single subnet. Regionals-DIF 2 O((2Dn2)2 ) O ( ( D m2)2 ) where n2 is the number of border routers around the outside and m2 is number of border routers at this level on a single subnet. Backbone-DIF 1 O((2Dn1)2 ) O ( ( 2 D n1)2 ) where n1 is the number of border routers on the backbone. Note that m n.
35.
© John Day,
2013 35 Rights Reserved The Pouzin Society Names Implications of the Model (Basics) • We have made a big deal of node and point of attachment, but they are relative, not absolutes. – An (N)-IPC-Process is a node in the (N)-DIF. • An (N-1)-IPC-Process is a node in the (N-1)-DIF – An (N-1)-IPC-Process is a point of attachment to an (N)-IPC-Process. – An (N)-address is a synonym for an (N)-IPC-Process. • So as long as we keep that straight, there is no point to making the distinction. • Note that it is the port-id that creates layer independence. With a port-id, No Protocol-Id Field is Necessary, or if there is such a field something is wrong. Address Port -id (N)-IPC-Process (N-1)-IPC-Process
36.
© John Day,
2013 36 Rights Reserved The Pouzin Society Names Implications of the Model (Multihoming) • Yea, so? What is the big deal? – It just works • PDU arrives at the (N-1)-IPC Process. If the address designates this IPC Process, the CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it passes it up. • The process repeats. If the address in the (N)-PCI is this IPC-Process, it looks at the CEP-id and pass it up as appropriate. • Normal operation. Yes, the (N-1)-bindings may fail from time to time. • Not a big deal. Address Port -id (N)-IPC-Process (N-1)-IPC-Process
37.
© John Day,
2013 37 Rights Reserved The Pouzin Society Names Implications of the Model (Mobility) • Yea, so? What is the big deal? – It just works just like multihoming only the (N-1)-port-ids come and go a bit more frequently. • O, worried about having to change address if it moves too far? Easy. • Assign a new synonym to it. Put it in the source address field on all outgoing traffic. Stop advertising the old address as a route to this IPC-Process. • Want to renumber the DIF for some reason? Same procedure. • Again, no special cases. No special protocols. No concept of a home router. Okay, policies in the DIF may be a bit different to accommodate faster changing points of attachment, but that is it. Address Port -id (N)-IPC-Process (N-1)-IPC-Process New Address
38.
© John Day,
2013 38 Rights Reserved The Pouzin Society The Skewed Necklace (A Typical Mobile Network) • Space does not permit drawing networks at each layer. There would be internal routers between the border routers in a real network. • It appears that one could make the mobile host appear stationary to the top layer, i.e. the top layer addresses don’t change because all the routing is handled in the lower layers. Base Station Metro Subnet Regional Subnet Mobile Infrastructure Network Traditional ISP Provider Network with normal necklace with an e-mall top layer.
39.
© John Day,
2013 39 Rights Reserved The Pouzin Society The Skewed Necklace (DIF view) • Clearly more layers could be used to ensure the scope allows sufficient time for updating relative to the time to cross the scope of the layer. – Space does not permit drawing networks. • It appears that one could make the mobile host appear stationary to the top layer, i.e. the top layer addresses don’t change because all the routing is handled in the lower layers. Base Station Metro Subnet Regional Subnet Mobile Infrastructure Network Traditional ISP Provider Network with normal necklace with an e-mall top layer.
40.
© John Day,
2013 40 Rights Reserved The Pouzin Society What New Is Needed? • Nothing – Enrollment in a new DIF follows normal procedures – Allocation of a flow follows normal procedures – Changing the address of an IPC Process with in a DIF follows the normal procedure. – New points of attachments, i.e. new lower layer DIFs, are acquired in the normal way. • There are specific cases to work out here. In general, expect that a wireless device will be probing for new PoAs. But then a system with a down wireline interface should be doing the same thing. – Current points of attachment are discarded when they can no longer provide an acceptable QoS (criteria and measurement is policy as it is in the wireline case).
41.
© John Day,
2013 41 Rights Reserved The Pouzin Society The Other Mobile “Cases” 1) Purely mobile with no connection to a fixed network and no external reference. 2) Purely mobile with no connection to a fixed network with external reference, e.g. GPS. – The DIFs for these networks look like stand-alone fixed networks. Again nothing new is required. For case 1) the rate of change in position may be too great to make the assignment of topological addresses or the use of traditional routing feasible. Case 2) has other possibilities that might mitigate these constraints to some degree. – Conjecture: Ad hoc networks with a high rate of mobility will be limited in the size that can be reasonably sustained. • Note: most ad hoc networks do routing on demand. • Purposely embedding some slower moving systems among the fast moving could vastly improve performance. – There are specific cases where the nature of the problem allows assumptions to be made so that these techniques can be applied.
42.
© John Day,
2013 42 Rights Reserved The Pouzin Society Even the Shim DIF was Enlightening • A Shim DIF creates the thinnest possible veneer to make a legacy layer service look like a DIF. • Both IP and Ethernet (without LLC) have a ‘protocol-id’ field – Historically (1982) a problem: (N+1)-protocol identified in an (N)-protocol • Without port-ids, there is no isolation and this implies that for each protocol type, there can only be one “user” of the “flow.” – There can be only one QoS-cube. • Conclusion: Port-ids are necessary to a well-formed layer/DIF. These are ill- formed layers. – Ethernet with LLC is well-formed. – Port-ids provide isolation. Dest Src Protocol-id Stuff User-Data DIF Boundary
43.
© John Day,
2013 43 Rights Reserved The Pouzin Society Implications of the Model Names (Choosing a Layer) • In building the IPC Model, the first time there were multiple DIFs (data link layers in that case), to maintain the API a task was needed to determine which DIF to use. I A P D i r Mux Flow Mgr – User didn t have to see all of the wires – But the User shouldn t have to see all of the Nets either. • This not only generalizes but has major implications.
44.
© John Day,
2013 44 Rights Reserved The Pouzin Society Implications of the Model Names (A DIF Allocator) • A DIF-Allocator incorporating a Name Space Management function determines via what DIFs applications are available. – If this system is a not member, it either joins the DIF as before – or creates a new one. • Which Implies that the largest address space has to be only large enough for the largest e-mall. • Given the structure, 32 or 48 bits is probably more than enough. • You mean? • Right. IPv6 was a waste of time . . . • Twice. DIF-Allocator
45.
© John Day,
2013 45 Rights Reserved The Pouzin Society So a Global Address Space is Not Required but Neither is a Global Application Name Space Inter-DIF Directory To Peers In Oher DIFs Actually one could still have distinct names spaces within a DIFs (synonyms) with its own directory database. • Not all names need be in one Global Directory. • Coexisting application name spaces and directory of distributed databases are not only possible, but useful. • Needless to say, a global name space can be useful, but not a requirement imposed by the architecture. • The scope of the name space is defined by the chain of databases that point to each other.
46.
© John Day,
2013 46 Rights Reserved The Pouzin Society Scope is Determined by the Chain of Places to Look • The chain of databases to look for names determines the scope of the name space. – Here there are 2 non-intersecting chains of systems, that could be using the same wires, but would be entirely oblivious to the other.
47.
© John Day,
2013 47 Rights Reserved The Pouzin Society Name Space Management • There is a common functional required to manage name spaces. It handles registration, query, and delegation of names and is incorporated found in both DIFs and DAFs. • There are two major uses: the DIF-Allocator and the Flow Allocator, as well as in many distributed database applications, etc. Repositories Registration Server Query Servers Registration Client Query Client
48.
© John Day,
2013 48 Rights Reserved The Pouzin Society DIF Allocator • A DIF Allocator is very similar to the Flow Allocator, both contain a NSM function for application names and addresses, respectively and operate at different granularities creating either DIFs or connections. Registration Server Query Servers Registration Client Query IRM DA-DAP NSM Repositories DIF Creation and RelayNSM- DAP DA-DAF
49.
© John Day,
2013 49 Rights Reserved The Pouzin Society Multicast and Anycast are Simpler Too • Generalized to Whatevercast: – A set and a rule that returns as many members of the set that satisfy the rule. • Unicast becomes a degenerate case of whatevercast. – Forwarding table entry maps Destination Address to a list of next hops. For unicast, the list has one element. • Primarily handled by hosts or border routers, where all whatevercast traffic is either: • On this subnet (only do spanning tree within subnet if there is a lot) or • Transit to another subnet, (both cases degenerate to point-to-point). • So we see Whatevercast devolves into Unicast.
50.
© John Day,
2013 50 Rights Reserved The Pouzin Society Multicast and Anycast are Simpler Too • Information in topological addresses imply an approximate spanning tree, which can be used to identify the border routers. Thus, in most cases obviating the need for a separate spanning tree (multicast) routing algorithm. • And also making it straightforward to multiplex whatevercasts with common sub-trees which will allow even greater efficiency. – Note that the common sub-trees do not have to be strict sub-trees but simply have a reasonable degree of commonality to be worthwhile.
51.
© John Day,
2013 51 Rights Reserved The Pouzin Society Like I Said What’s All the Fuss? ;-) Questions?
Baixar agora