Optical networking for e-Science applications

1. Optical networking fore-Science applications Freek Dijkstra System and Network Engineering Group Universiteit van Amsterdam

2. Introduction • System- and Network Engineering group, Universiteit van Amsterdam • Five research tracks • Authentication, authorization and accounting (AAA) • Optical networking (circuit-switched networks) • Grid information management • Grid workflow management • Security (since this year) • Mostly funded by third parties: Dutch (BSIK), EU-projects. For example GigaPort project (SURFnet).

3. GLIF community A collaboration of national research & education networks (NRENs), promoting the paradigm of “lambda networking” http://www.glif.is/

4. Lamda Networking Also known as: • Optical Networking • Hybrid Networking • Transport Networks • Optical Private Networks (OPN) Providing circuit switched network connections to those applications/users that require so, while providing regular (routed) IP to most other applications/users. A LightPath can be a dedicated Ethernet connection from Amsterdam to Chicago

5. User Classes • Lightweight users, browsing, mailing, home use Need full Internet routing, one to many • Business apps, multicast, streaming, VPNs, mostly LAN Need VPN services and full Internet routing, several to several + uplink • Scientific applications, distributed data processing, grids Need very fat pipes, limited virtual organizations, few to few, OPN ΣC ≈ 100 Gb/s to 1 Tb/s number of users ΣB ≈ 300 Gb/s ΣA ≈ 160 Gb/s A C B 1-10 GigE ADSL Bandwidth requirements Source: Cees de Laat, UvA

6. Example Applications Physics • Nuclear Physics (LHC) • Astrophysics (mostly radio astronomy, e.g. e-VLBI, SCARI) Visualization • Remote Visualization (Dead Cat demo, UvA) • Remote Instrumentation (Electron Microscope) • High definition video streams (EVL, Cal-IT2) • Distribution of movies (CineGrid) • Analysis of video data (e.g. MultimediaN) Large file transfers • User-driven file transfers • Nightly backups • Transfer of medical data files (e.g. MRI) • Magneto encephalography (MEG) modeling; Current demand in SURFnet • Optical Private Networks (e.g. Hogescholen)

7. Example LightPath Landspeed record Single Stream TCP: Tokyo – Chicago – Amsterdam – – NY – Chicago – Tokyo

8. 2 days 5 days 5 days 3 days 2 days + A few weeks Getting a Lightpath in practice • Manual: e-mail your network provider or NREN (e.g. SURFnet) • Applications often don’t know what network they need/want. • Path finding • Usually done manually, by contacting other NRENs. More complex than Internet routing (more constraints) • Automatic path setup • SURFnet orders SARA to manually configure the path. • Fault detection • End user sees a problem with the connection, but it is unclear in which domain(s) causes the problem(s) • End node configuration • Which IP range to use? How to tune TCP?

9. End Node Configuration • Problem: After a LightPath has been created, end-users struggle to manually configure their end nodes. • TCP does not perform well for high bandwidth • delay product. • IP addressing: DHCP will not work out-of-the-box, since it is not clear which domain should run it. • Automated Solution for IP addressing • Use Zero Configuration: Automatic configuration of network without a central authority • Solution: use self-assigned IP addresses • Use multicast DNS to link IP address and hostname and visa versa • Use DNS Service Discovery to find out the host name where services are running Cluster domain 1 Cluster domain 2 LightPath

10. Zero Configuration • Use Zero Configuration protocols • Automatic configuration of IP addresses • RFC3927 for IPv4 or RFC2462 for IPv6 • Name lookup of hosts • Multicast DNS (mDNS) or Link-Local Multicast Name Resolution (LLMNR) • Discovery of services • DNS Service Discovery (DNS-SD), or Simple Service Discovery Protocol (SSDP, in UPnP), or Service Location Protocol (SLP) (or even UDDI, SDP, Salutation, or Jini) • Three software suites, used multiple implementations: • RFC3927: ZCIP and autoip for Linux, native in OS X and Windows • mDNS: mDNSResponder, tmdns, and Porchdog mDNS • hooking gethostby*() to use mDNS: tmdns and libnss_mdns

11. iGrid 2005 Demonstration • Demonstrated auto-matic IP configuration • Used broadcast ping to discover all hosts • Used multicast DNS and gethostbyaddr() hook to discover hostnames • Tested IP collisions • Also demonstrated service discovery through DNS

12. Applicability Grid 2005 demonstration taken as sample applications

13. Path Finding Many constraints (more than regular Internet)Need not only topology information, but also scheduling, and policy. In addition, technology incompatibilities may block a certain path. Network DescriptionNot as trivial as it seems (multi-domain, multi-layer). Due to changing technology, what you want to describe changes over time. Network generation to test efficiency of path finding algorithmsReal-world networks don’t look like a simple Erdős-Rényi random graph, but have a logarithmic or polynomial degree-distribution. It is yet unclear what the properties of real-world multi-layer networks are. Path finding algorithmMulti-domain GMPLS proposes a link state algorithm (OSPF-TE), but the only two successful multi-domain protocols (SS7 and BGP) use path vector algorithms.

14. Routing: Example GE is adapted in STS-24c (SONET channel thru OC-192) U. Calgary CA*net Canada UvA GE OC-192 GE OC-192 Star Light Chicago MAN LAN New York NetherLight Amsterdam OC-192 OC-192 GE is adapted in STS-3c-7v (SONET channel thru OC-192)

15. Routing: Example GE is adapted in STS-24c (SONET channel thru OC-192) U. Calgary CA*net Canada UvA GE OC-192 GE is adapted in STS-24c (SONET channel thru OC-192) GE OC-192 Star Light Chicago MAN LAN New York NetherLight Amsterdam OC-192 OC-192 GE is adapted in STS-3c-7v (SONET channel thru OC-192) GE is adapted in STS-3c-7v (SONET channel thru OC-192)

16. Capability Announcement Does only understand GE U. Calgary CA*net Canada UvA GE Can only adapt GE in STS-24c OC-192 Does only understand GE GE OC-192 Star Light Chicago MAN LAN New York NetherLight Amsterdam OC-192 OC-192 Does only understand SONET/SDH Can only adapt GE in both STS-24c and STS-3c-7v Can only adapt GE in STS-3c-7v

17. Websites Autonomous Systems Internet World-Wide Web degree out-degree Fraction of words Film Actors Word co-occurance Collaborations of film actors degree degree Degree Distribution of Actual Networks Source: Mark Newman

18. Network Description We need network descriptions for: • Network advertisementA user can use the information to formulate a lightpath reservation request • Path findingA resource broker can use the information to handle a reservation request • VisualizationCreate maps of a topology, and correlate these maps across domains

19. Why Network Descriptions? iGrid 2005

20. Existing Languages Only few standards! • ITU-T recommendation G.805Only describes network connections, not networks.Excellent notion of layering • DMTF standard CIM (Common Information Model)Very geared towards hardware, not towards networks and network device capabilities (hardly a notion of layering) • GMPLS (OSPF-TE)Has concept of layering. Can’t describe all details (e.g. WAN PHY or LAN PHY is decided during signaling phase). Not easily human-readable. See also: http://www.science.uva.nl/research/sne/ndl/

21. Using RDF Our idea: Use Resource Description Framework (RDF, a W3C standard) and Semantic Web • Everyone publishes their own network descriptions • Correlations between domains are made by pointing from one repository to another, much like a URL can point to another web page. • Readable by computers and humans predicate Subject Object (property) hasInterface Device TDM1 Interface 12/1

22. NDL Basics • Network Description Language (NDL) basics, version 1 • Classes and properties defined in the NDL schema • This version is layer independent. We recently created a version with specific interworking between layers (adaptation and termination functions) Location Device Interface Link name description locatedAt hasInterface connectedTo capacity encodingType encodingLabel

23. NDL Example <ndl:Devicerdf:about="#tdm1"> <ndl:name>tdm1</ndl:name> <ndl:locatedAtrdf:resource="#NetherLight"/> <ndl:hasInterfacerdf:resource="#tdm1:12/1"/> <ndl:hasInterfacerdf:resource="#tdm1:6/1"/> </ndl:Device> <ndl:Interfacerdf:about="#tdm1:12/1"> <ndl:name>12/1</ndl:name> <ndl:connectedTordf:resource="#tdm3:501/2"/> <ndl:capacityrdf:resource="1250000"/> </ndl:Interface> <ndl:Locationrdf:about="#NetherLight"> <ndl:name>NetherLight</ndl:name> <geo:lat>52.3561</geo:lat> <geo:long>4.9527</geo:long> </ndl:Location> • Device, Interface and Location described in NDL. RDF allows to easily integrate other schemas, such as the geo schema. tdm1 tdm3 501/2 12/1

24. Vizualisation 1: NetherLight NetherLight is an Optical Exchange (called GOLE in the GLIF community), created by SURFnet. This picture was created from an NDL file, converted to a .dot file, opened with GraphViz.

25. Vizualisation 2: SURFnet 6 This picture shows all SDH devices in SURFnet. Source: SARA

26. Vizualisation 3: Google Maps Source: Jeroen van der Ham

27. CA*net Canada U. Calgary UvA GE OC-192 GE OC-192 Star Light Chicago MAN LAN New York NetherLight Amsterdam OC-192 OC-192 NDL Multilayer Extension • ITU-T G.805 describes functional elements (e.g. adaptation, termination functions, link connections, etc.) to describe network connections. • We extended these function elements (e.g. with potential adaptation functions) to describes networks. • We created a model to map actual network elements to functional elements. • Defined a simple algebra to define correctness of a connection • We created a NDL extension to describe these functional elements. Simplified model to map network elements to functional elements