1 / 13

Diversified Internet Architecture

Diversified Internet Architecture. Jon Turner, Patrick Crowley, Sergey Gorinsky, John Lockwood www.arl.wustl.edu/~jst/reInventTheNet/. Project Overview. Enable diverse metanetworks within common substrate Substrate architecture data plane – flexible metalink support

hbruce
Download Presentation

Diversified Internet Architecture

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. Diversified Internet Architecture Jon Turner, Patrick Crowley, Sergey Gorinsky, John Lockwood www.arl.wustl.edu/~jst/reInventTheNet/

  2. Project Overview • Enable diversemetanetworks within common substrate • Substrate architecture • data plane – flexible metalink support • access provisioning – supporting dynamic connections • backbone provisioning – metanet planning and configuration • role of security – let metanets control how security is handled • communicating control information • Experimental metanetworks • dynamic publish-subscribe metanet for distributed simulation • omnidirectional multicast distribution trees with interest filters • high performance location-based filtering, fast filter configuration • large-scale science metanet • support for bulk data transfers (e.g. 10 GB to 100 TB) • advance scheduling – accept requests as prior commitments allow • reconsidering fairness for on-demand schedules

  3. Role of Substrate • Substrate provides resources to metanets • provide processing resources for metarouters • implement metalinks – both point-to-point and multipoint • not intended to provide end-to-end packet delivery • Support metanet backbone configuration • long-term reservations, generally coarse granularity • support for advance planning • Access metalink provisioning • on-demand (typically when host boots, or re-connects) • mechanisms that enable metanets to provide mobility • Multiple substrate domains • multi-domain metanets, inter-domain metalink routing • different trust levels for different substrate domains • Substrate Control Metanet (SCM) • control messages for substrate configuration

  4. Pnt2pnt metalinks on multi-access substrate link • high priority VLAN for provisioned substrate link • substrate router limits usage metalinks defined bymetalink id (MLI) shared highpriority VLAN Ethernetundernet • Best-effort multipoint metalinks • so metanets can use broadcast LAN features shared best-effort priority VLAN Metalink Implementation substrate link defined by VLAN or MPLS tag, or wavelength • Pnt2pnt metalinks over pnt2pnt substrate link

  5. PEs Switch LineCards Implementing Metarouters • Processing Engines (PEs) implement metarouters • Line Cards terminate external links, mux/demux metalinks • Shared PEs include substrate component • Dedicated PEs need not include substrate component • use switch and Line Cards for protection and isolation • PEs in larger metarouters linked by metaswitch • Larger metarouters may use dedicated Line Cards • allows metanet to define transmission format/framing • configured by lower-level transport network

  6. Current Development System • Network Processor blades • Dual IXP 2800 NPs • 1+16 RISC cores on each • 3xRDRAM, 3xSRAM, TCAM • Dual 10GE interfaces • 10x1GE IO interfaces • General purpose blades • Dual Xeons, quad GigE connections, SATA disk • 10 Gb/s Ethernet switch • VLANs for traffic isolation • Planetlab-compatible • NPs provide fast-path • multiple slices, code options on each NP

  7. substraterouter transportlayermetaswitch sharedtransportpaths dedicatedtransportpaths Flexible Transport Layer • Shared transport paths carry multiple metalinks • semi-static transport level configuration • dynamic configuration of metalinks within path • Dedicated transport paths serve larger metanets • more dynamic • Transport layer metaswitches give metanets more direct control over transport layer resources • allows metanet to shift capacity as traffic changes • may be implemented using a shared cross-connect • potentially highly dynamic

  8. substratedomains alternate accessmetalink routes Metanet Configuration • Metanet backbone provisioning • substrates advertise resource availability, cost information • metanet planner requests bids for metanet segments • iterate, as needed • Access metalink configuration • users may request connection from anywhere, at anytime • metanet determines termination point, domain-level route • substrate domains determine route segments

  9. Providing Metanet Planning Info • Substrates advertise so that metanets can use them • hosting capabilities advertisements • in region R, can host metarouters on type T substrate platforms • multi-scale region specifications • distance advertisements • distance from R1 to R2 within substrate is D • peering advertisements • D1 peers with D2 in region R, with capacity C • may also specify scope to indicate “relevance region”

  10. advertisedpeeringrelationship Metalink Routing • Metanet uses peering advertisements to identify paths • geographic information used to estimate distances • vertices of path are region center points • for substrates that supply internal region graph, use distances implied by region graph • Metanet requests route segments from substrate nets • request to domain D: metalink L, from D1 in R1 to D2 in R2 • request may include a provisioned capacity, latency bound • adjacent substrate domains use metalink identifier (L) to coordinate across domain boundary

  11. Metanet Backbone Configuration • Inputs to metanet planner • substrate domain adverts • expected users within regions • expected traffic among regions • Planner • selects regions for metarouters • typically driven by users in region • may also include transit metrouters • selects metanet topology • determination of metalink capacities • peering points for inter-domain metalinks • determines metarouter configurations • number and capacity of interfaces • number and type of PEs • Metanet issues requests to substrate domains • Substrate domains respond with cost to satisfy request • Metanet confirms agreement, withdraws or negotiates

  12. substratedomains privatedomains 3 1 2 Substrate Control Metanet (SCM) • Supports control communication • Instantiated in all substrate routers • Host connection process • discover local substrate router (returns MAC address) • establish access metalink to SCM • establish access metalink(s) to desired metanet(s) • Metanets also use SCM to communicate with substrate configuration services, authentication services

  13. Summary • Objectives • enable diverse metanetworks to co-exist • allow introduction of new network architectures at any time • stimulate development of applications • Key concerns for substrate architecture • enable maximum metanet diversity – architectural neutrality • postpone substrate ossification – let the metanets do it • enable secure metanets in context of multi-domain substrates • Preliminary design choices • including multi-scale geography into metanet provisioning • iterative backbone provisioning process involving metanet planner and multiple substrate domains • dynamic access metalink creation controlled by metanet • Substrate Control Metanet for control communication • mechanisms to protect metanets from DoS attacks

More Related