Network2/Architecture: Difference between revisions
< Network2
Jump to navigation
Jump to search
m (New page: We want to offer maximally efficient and robust support for our ''ideal network scenarios'' (nos. 1 and 9, denoted with bold text, below) while offering seamless support for ''optional net...) |
mNo edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Network2 header}} |
|||
We want to offer maximally efficient and robust support for our ''ideal network scenarios'' (nos. 1 and 9, denoted with bold text, below) while offering seamless support for ''optional network enhancements'' like fancy links, routers, tunnel endpoints, and transit agreements that may be provided by the ''surrounding ecosystem'' of deployment organizations, universities, individuals, and commercial entities. |
|||
Prerequisite concepts: [[Network2/Concept/Link|link]], [[Network2/Concept/Layer|layer]], [[Network2/Concept/Network|network]], [[Network2/Concept/Address|address]], [[Network2/Concept/Internetwork|internetwork]], [[Network2/Concept/Name|name]] |
|||
Network Scenarios: |
|||
# '''access to at least one shared-media link.''' |
|||
# a more efficient link, like an 802.3 switch or an 802.11 access point. |
|||
# a bridge, like an XS or a good access point, between two or more otherwise separate single-link networks. |
|||
# a local router, like an XS, routing between two or more otherwise separate (but potentially complicated) local networks |
|||
# a restrictive local router which provides some IPv4 connectivity but which drops IPv6 traffic |
|||
# credentials for some sort of dedicated local tunnel endpoint (like a SOCKS proxy or an HTTP proxy) |
|||
# a remote router offering us some sort of access to a larger internetwork, typically via (perhaps restricted) IPv4 |
|||
# credentials for some sort of dedicated remote tunnel endpoint (like an SSL or IPsec VPN or a 6to4 tunnel, etc.) |
|||
# '''a remote router offering great access to a larger internetwork''' |
|||
Based on these scenarios, we imagine our network as being organized into three kinds of composable layers: |
Based on these scenarios, we imagine our network as being organized into three kinds of composable layers: |
||
| Line 17: | Line 6: | ||
# a ''link layer'', usually implemented via 802.3 wired Ethernet, 802.11b/g wifi in either ad-hoc or infrastructure mode, or various sorts of tunneling over IPv4, perhaps across NATs and firewalls, |
# a ''link layer'', usually implemented via 802.3 wired Ethernet, 802.11b/g wifi in either ad-hoc or infrastructure mode, or various sorts of tunneling over IPv4, perhaps across NATs and firewalls, |
||
# an ''internetworking layer'', based on [http://tools.ietf.org/html/rfc2460 IPv6] ([http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/ tutorial documentation]), and |
# an ''internetworking layer'', based on [http://tools.ietf.org/html/rfc2460 IPv6] ([http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/ tutorial documentation]), and |
||
# a ''naming |
# a ''naming layer'', based on [http://tools.ietf.org/html/rfc1034 DNS], for binding logical addresses from networks with different failure modes to stable human-memorable names |
||
We find this layered conceptual model helpful for estimating dependency ("what has to work before this layer can work?") and cost ("what does it cost to traverse this layer?"). |
We find this layered conceptual model helpful for estimating dependency ("what has to work before this layer can work?") and cost ("what does it cost to traverse this layer?"). |
||
Latest revision as of 05:58, 12 August 2009
Prerequisite concepts: link, layer, network, address, internetwork, name
Based on these scenarios, we imagine our network as being organized into three kinds of composable layers:
- a link layer, usually implemented via 802.3 wired Ethernet, 802.11b/g wifi in either ad-hoc or infrastructure mode, or various sorts of tunneling over IPv4, perhaps across NATs and firewalls,
- an internetworking layer, based on IPv6 (tutorial documentation), and
- a naming layer, based on DNS, for binding logical addresses from networks with different failure modes to stable human-memorable names
We find this layered conceptual model helpful for estimating dependency ("what has to work before this layer can work?") and cost ("what does it cost to traverse this layer?").