GSOC2012Projects

From Nsnam
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

GSoC 2012 Ideas

This webpage highlights project ideas for ns-3's Google Summer of Code 2012 effort.

GSOC 2012 Timeline is:

  • February 27 - 19:00 UTC: Mentoring organizations can begin submitting applications to Google.
  • March 9 - 23:00 UTC: Mentoring organization application deadline.
  • March 16 - 19:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2012 site.
  • March 17-25: Would-be student participants discuss application ideas with mentoring organizations.
  • March 26 - 19:00 UTC: Student application period opens.
  • April 6 - 19:00 UTC: Student application deadline.

Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2012

While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before March 16.

About the ns-3 project

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has been in development since 2005 and has been making quarterly releases since June 2008 (our last release was ns-3.10 in January 2011). ns-3 is replacing the popular ns-2 tool which was developed in the 1997-2000 timeframe but became out of date and unmaintained. The tool is coming into wide use; our web server logged almost 71000 successful downloads of our released software between January 2010 and January 2011, and we have a users mailing list of about 900 members now averaging 200-300 posts per month.

Our GSoC organizational admin is Lalith Suresh and our backup org admin is Tom Henderson.

Project Ideas

The following are project ideas which the ns-3 team has identified as important and is most interested in working on as part of the 2012 Google Summer of Code. Applicants are however free to propose their own ideas. In addition, please note that these ideas are not limited to GSoC, anyone is welcome to work on them. The project ideas have not been ordered in order of importance or priority. Please email the ns-developers list if you have an idea that you'd like to work on. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the ns-developers list. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the more stronger a proposal it will develop into, and the higher your chances of being accepted into the programme.

Each project idea has been tagged with the following properties:

  • Required Experience: Languages, concepts, or packages with which applicants must be familiar.
  • Bonus Experience: Other experience or familiarity which would be greatly helpful to applicants for this project.
  • Interests: Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
  • Difficulty: easy, medium or difficult
  • Recommended reading: pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.

Project area

Mentors:

  • Project name: Detailed description of project goes here.
  • Technical Requirements
    • Required Experience:
    • Bonus Experience:
    • Interests:
    • Difficulty:
    • Recommended reading:

Stream Control Transmission Protocol (SCTP)

Mentors: Tommaso Pecorella

  • SCTP implementation and testing: SCTP is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails. Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.
    • Required Experience: C++
    • Bonus Experience: L4 protocols understanding
    • Interests: L4 protocols modeling and simulation
    • Difficulty: medium
    • Recommended reading:
      • RFC 3286 An Introduction to the Stream Control Transmission Protocol
      • RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol
      • all the relevant RFCs about SCTP


Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd)

Mentors: Tommaso Pecorella

  • 6LoWPAN-nd implementation and testing: 6LoWPAN-nd is novel draft protocol from IETF's LoWPAN WG. The protocol aims at defining new and optimized methods to perform Neighbor Discovery and Node Bootstrap for Wireless Sensor Networks and it will be the counterpart of the 6LoWPAN IPv6 header compression strandard. 6LoWPAN-nd is not currently implemented in ns-3, while 6LoWPAN compression and 802.15.4 stacks are in advanced development status. In order to simulate a real Wireless Sensor Network 6LoWPAN-nd should be developed and tested.
    • Required Experience: C++, IPv6
    • Bonus Experience: WSN networking
    • Interests: WSN, IPv6, node bootstrap, efficient packet compression
    • Difficulty: medium
    • Recommended reading:
      • RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
      • 6LoWPAN-nd Neighbor Discovery Optimization for Low Power and Lossy Networks


Vehicular Ad-hoc Networks

Mentors: Guillaume Rémy

  • Wireless Access in Vehicular Environments (WAVE) The IEEE 1609 Family of Standards for Wireless Access in Vehicular Environments (WAVE) defines the architecture, communications model, management structure, security mechanisms, and physical access for wireless communications in the vehicular environment. Some components of this specification has already been implemented for ns-3. However, we are still far from the simulation of WAVE on ns-3. The current status is as follows and it is up to the student to decide how much he/she wants to implement: 1) The PHY is ready as-is: the 5 MHz and 10 Mhz channel options (i.e., 802.11p) are already implemented, with a corresponding error model. 2) As for the PHY-specific parameters (slot duration etc.), currently only coverage class 0 is supported [0]. 3) The MAC needs to be modified. First, some trivial reworking is needed [1], and the rest depends on what the student wishes to implement. One possible approach is to use [2] as a guideline for implementing what is discussed in [3]. The most complex piece to implement are the channel switch logic (the execution of the channel switch command is already implemented) 4) higher layers: nothing specific to WAVE is currently available. 5) mobility models: no mobility model specific for vehicular scenarios is included in ns-3. But given that ns-3 can work with ns-2 mobility traces, it should be possible to find a mobility trace generator for vehicular scenarios that can be reused with ns-3.


Realistic spatial models for wireless link simulations

Mentors: Tommaso Pecorella Nicholas Loulloudes

  • Spatial models for wireless links: Wireless system simulation is heavily dependant on the radio link assumptions. While several models exist for different scanarios (e.g., indoor, outdoor, etc.), radio-opaque obstacles are about always simulated with simple statistical assumptions. This is a suitable assumption only for some kind of scenarios, while in some other cases (e.g., vehicular networks, indoor low-power communications, etc.) this approach is not suitable. In order to increase the results accuracy it is needed to develop a link between spatial maps (2D and 3D) of radio-opaque objects so to properly calculate the link metrics, i.e., to properly adapt the link statistics. Two example scenarios could be: vehicular networks in a city and Wireless Sensor Netorks in a logistic area. The 2D / 3D maps should be read from scenario files, described in an open.source language chosen by the developer.
    • Required Experience: C++, 3D maps
    • Bonus Experience: radio link caracterization
    • Interests: wireless system realistic simulations
    • Difficulty: medium / hard
    • Recommended reading:
      • none


High-level architecture (HLA) interfaces for ns-3

Mentors: Tommaso Pecorella

  • High-level architecture interfaces: High-level architecture (IEEE 1516) is a standard system to define APIs between simulators, in order to achieve an effective simulator federation. Simulators federations are used to bind variousl kinds of simulators (e.g., scenario simulators, network simulators, phisical link simulators, etc.) into a powerful and flexible system able to perform complex analysis of high-level events (e.g., disaster recovery simulations). In such complex simulations it is impossible to build a single simulaiton tool, so simulators federation are mandatory. Ns-3 can play the role of an HLA element, provided that HLA support is added. This involves 1) applications level API, 2) mobility API, radio link quality API and possibly more.
    • Required Experience: C++
    • Bonus Experience: Simulators federation concepts
    • Interests: Complex scenarios simulations
    • Difficulty: hard
    • Recommended reading:


ns-3 Firewall model

Mentors: Adrian S.W. Tam

  • ns-3-netfilter: Complex network scenarios do require an high level of accuracy in order to effectively mimic a realistic network. Nowadays, firewalls are an integral part of any network, and with IPv6 deployment it is expected an even wider spread in their use. The effects of a firewall presence can not be simply simulated by dropping off packets at the source nodes, neither at the receivers nodes. It is then useful to include a firewalling module in ns-3. The module should mimic the Linux netfilter behaviour and accept common iptables configuration files, so to ease its configuration. Moreover it should be able to filter both IPv4 and IPv6 packets and be structured so to allow different future implementations (e.g., BSD IPFW). Early work on this topic is present in one of ns-3 repositories, and might useful as starting point.
    • Required Experience: C++
    • Bonus Experience: Linux netfilter (iptables)
    • Interests: Network Firewalls
    • Difficulty: medium
    • Recommended reading:


Node stop / start models

Mentors: Tommaso Pecorella Vedran Miletić

  • Node stop / start: In wireless systems (but in wired systems as well) sometimes a node can fail due to general shutdown, software error or external force. This is pretty common in wireless systems, where nodes are battery-operated, however the same applies to wired systems, e.g., when a computer does a reboot. Currently in ns-3 there's no standardized way to handle this, and despite the presence of an Energy module, when the energy is depleted the node will not stop operating. A real module should as well handle the case of a node restarting, e.g., when the batteries are recharged or the reboot is finished. The module should interface with the Energy module and allow a general applications to all the other relevant modules, ranging from Applications to MAC modules. Optionally, code should be generalized to allow modelling of link failures.


Network Address and Port Translation (NAT) models

Mentors: Adrian S.W. Tam

  • ns-3-NAT NATs should burn. IPv6 rules and IPv4 should be declared as obsolete. Those statements could be true but the reality is different, we'll have to cope with NATs for some time more. Since we'll have to bear with NATs and private address spaces, it can be a good idea to be able to evaluate their effects in a complex network. The ns-3 NAT module should mimic the Linux NAT behaviour at minimum, and possibly be able to be configured so to behave like any other NAT variant. The compliance with PCP (Port Control Protocol) is a premium, but it's not strictly required.


Deep Space networking: Licklider Transmission Protocol (LTP)

Mentors: Tommaso Pecorella

  • ns-3-LTP Licklider Transmission Protocol (LTP) is a point to point protocol for the use in deep space links. It have a number of interesting properties, mainly related to the constraints found in space links, like ultra-high round trip delay and so on. LTP is currenlty under revision as a proposed standard by the Consultative Committee for Space Data Systems (CCSDS), however its principles are well-known to the satellite networking community, RFCs and reference Linux implementations are available. An ns-3 implementation should comply with the already existing IETF specification and with the CCSDS one.


IPv6 stack validation and improvements

Mentors: Tommaso Pecorella

  • IPv6 stack validation and improvements: IPv6 use is going to increase dramatically in the next years. Various international projects are required to use IPv6 (e.g., EU FP7, EU 2020, etc.). Hence, simulations should be run on IPv6 rather than IPv4, and it is becoming an imperative action to have a reliable, full-featured IPv6 stack for ns-3. IPv6 stack for ns-3 works, but it lacks a number of interesting and useful features. A few missing features are (the list is not exhaustive):
    1. There is no path MTU discovery see also RFC 1981.
    2. Flow Monitor module does not work on the IPv6 stack
    3. FlowLabel header field is not currenly used
    4. IPSec is not supported
  • The candidate should check the missing features and select a set to develop and test. A general test of the IPv6 stack to be done against a reference Linux implementation is a premium.


Deep Space networking: Bundle Protocol (BP)

Mentors: Tommaso Pecorella

  • ns-3-BP Delay Tolerant Networks (DTN) are a class of networks resilient to either ultra-high delays or link disruptions. Common examples are sensor networks, vehicular networks, military networks and Deep Space networks. To provide the end-to-end network services the DTN protocols, also known as bundle protocols, sit above the link or transport layers of the constituent internets, forming a store-and-forward overlay network. Currently BP has been used for specific projects, but its performances on large-scale topologies is still under evaluation. BP is an application protocol, and should be able to use whatever Layer4 protocol is available, ranging from TCP/IP to LTP. An ns-3 implementation should comply with the already existing IETF specification and with the CCSDS one.


PackMime-HTTP

Mentors: Michele Weigle

  • PackMime-HTTP: PackMime-HTTP is a module for generating synthetic web traffic based on a traffic model developed at Bell Labs. The main parameter controlling traffic intensity is rate, the average number of new TCP connections started each second. The goal of this project is to port the PackMime-HTTP web traffic generation code from ns-2 to ns-3. The implementation of PackMime-HTTP in ns-3 can borrow significantly from the implementation of Tmix in ns-3, as the ns-2 version of Tmix was based on PackMime-HTTP.
    • Required Experience: C++
    • Bonus Experience: knowledge of HTTP, TCP, familiarity with PackMime-HTTP in ns-2
    • Interests: application-level and transport-level modeling and simulation
    • Difficulty: medium
    • Recommended reading:
      • packmime
      • Stochastic Models for Generating Synthetic HTTP Source Traffic, J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay, F.D. Smith, and M.C. Weigle, Proceedings of IEEE INFOCOM, Hong Kong, March 2004, available at INFOCOM04.pdf


Tmix and DelayBox

Mentors: Michele Weigle

  • Tmix and DelayBox: Tmix is a module for generating synthetic Internet traffic based on collected traces that have been converted into "connection vectors". Much of the implementation has already been completed, but it needs to be validated and updated to work with the latest version of ns-3. Completing this project also includes completing the DelayBox module that Tmix relies on. The implementation of DelayBox in ns-3 has also been started, but not yet fully completed.
    • Required Experience: C++
    • Bonus Experience: knowledge of HTTP, TCP, familiarity with Tmix and DelayBox in ns-2
    • Interests: application-level and transport-level modeling and simulation
    • Difficulty: medium
    • Recommended reading:
      • Tmix
      • Michele C. Weigle, Prashanth Adurthi, Felix Hernandez-Campos, Kevin Jeffay and F. Donelson Smith, "Tmix: A Tool for Generating Realistic Application Workloads in ns-2," Computer Communication Review, Vol. 36, No. 3, July 2006, pp. 67-76, available at ccr06.pdf
      • Prashanth Adurthi and Michele C. Weigle, "Realistic TCP Traffic Generation in ns-2 and GTNetS," Tech Report, June 2006, available at adurthi-tmix-TR06.pdf


XORP support by Direct Code Execution

Mentors: Hajime Tazaki

  • XORP support by Direct Code Execution: This project aims to provide the integration of XORP [1] and ns-3 to simulate active running protocol implementation. XORP is an open-source routing protocol implementation that supports various protocols such as OSPF, RIP, BGP, OLSR, VRRP, PIM, IGMP, MLD, etc. Using existing implementation enables us to conduct reliable protocol simulations and help researchers/network operators to reveal the problems of existing network incident, for example. With previous contributions for Direct Code Execution (DCE) [2], XORP could be integrated with necessary system call, library call emulation and helper library to generate configuration file for the execution of XORP protocol implementation.
    • Required Experience: C++, C?, debugger experience
    • Bonus Experience: network protocol design, implementation, XORP development experience, Routing protocol development
    • Interests: routing protocol stack, socket application development
    • Difficulty: difficult
    • Recommended reading:


Sensor Networks Operating System Over ns-3 (Contiki - ns-3)

Mentors: Daniel Câmara

  • Contiki – ns-3: Contiki is a popular open source Operating System for sensor networks. It provides all the functionalities a sensor application could need e.g. access to the sensor hardware, file system, network stack. All that with a really small footprint, and for a series of different platforms. The idea of this project is to be able to use the power of ns-3 to simulate realistic sensor networks running real applications over Contiki. The advantage of this is that developers can test their applications, the real ones, before deploying them on real sensors. The general sensor networks research community can also profit from that, since people will be able to make much more realistic simulations. Simulations will be actually running over the code of a real sensor network operating, powered by ns-3. Simulations will be more realistic and, on contrast to testbeds, they will be fully reproducible and larger scale networks can be easily tested. What could be more attractive to people working on the sensor networks field than being able to follow, and even debug, the whole data exchange process of a massive sensor network from the “comfort” of its preferred debugger? Not only the project is interesting from an engineering point of view, since the idea is to enable the use of a real sensor networks operating system over ns-3, but it can also be extremely useful for the networks community. Contiki is written in C and has a series of well-defined interfaces for enabling the code to run in new sensor architectures. What we intend is to develop a new “sensor architecture” that will be, in fact, a ns-3 node that implements the required interfaces from Contiki. On the other side, we will create a nw-3 sensor node that will run the Contiki OS.


Allow ns-3 native applications to use the ns-3-linux linux kernel stack

Mentors: Hajime Tazaki, Frederic Urbani

  • Allow ns-3 native applications to use the ns-3-linux linux kernel stack: Simulating existing implementations without a bunch of modifications (patching) contributes the reality/credibility of the result of simulations. We can avoid re-implementations of the protocols with special version for ns-3 (or nasty #ifdefs). Direct Code Execution (DCE) [1] helps a lot supporting not only POSIX socket applications, but also linux network kernel stack (ns-3-linux) [2] in the ns-3 simulations. It is abstracted as layer 3 protocol implementation on top of ns-3 and has already integrated with existing applications such as Zebra [3], CCNx [4], UMIP [3]. However, existing applications using ns-3 native stack do not benefit this feature because of lack of bridging between ns-3 core and ns-3-linux. This project aims to integrate these two components, ns-3-linux and ns-3 core, to be able to utilize protocols implemented in linux kernel as simulated models. The design and implementation of this functionality might consist of several directions:
    1. provide new socket factories to interact with the linux tcp, udp, sctp, etc. sockets.
    2. introduce new L3protocol classes on top of ns-3-linux implementation to align the other pieces of ns-3 core.
    3. make this new stack close to other API of ns-3 core so that existing ns-3 applications can run without much pain.
    4. the bridge provided by this functionality will align the inconsistency of ns-3 core and ns-3-linux. For example of such a inconsistency, assigning an IP address in ns-3 core reflects the state of network stack while ns-3-linux will be configured after Simulator::Run () (see the example of IP address configuration (RunIp function) with ns-3-linux [5])


INSTOOLS for ns-3

Mentors: Tom Henderson

  • INSTOOLS for ns-3: INSTOOLS is a software instrumentation package for GENI experiments. It logs a lot of artifacts of experiments, such as ARP and IP routing tables, Netflow graphs, etc, to databases. The aim of this project is to instrument ns-3 nodes to capture as much of this data as is applicable. A bonus is to try to integrate further with ProtoGENI and INSTOOLS such as making the ns-3 data archived just like it was a GENI experiment.
    • Required Experience: Familiarity with Linux networking and with C++ programming.
    • Bonus Experience: Experience with GENI and/or Emulab
    • Interests: Simulator tool development, integration with testbed experiments
    • Difficulty: Medium
    • Recommended Reading: http://groups.geni.net/geni/wiki/InstrumentationTools


ns-3 in the cloud

Mentors: Tom Henderson

  • ns-3 in the cloud: We want to document how to run ns-3 in Amazon Web Services. The ns-3 project would pay for compute time in the cloud. This project will perform some benchmarks of the cloud services, and look at options for scaling to large ns-3 simulations. This project will use the MPI feature of ns-3 to construct large distributed simulations, and document how to distribute the simulation instances in the cloud. The outcome of this project will be clear documentation for how to use ns-3 in the cloud including the documentation of benchmarking results, and test and example programs that can be run in the cloud.
    • Required Experience: C++ programming
    • Bonus Experience: MPI-based programming
    • Interests: Large-scale simulations, parallel simulations.
    • Difficulty: Medium
    • Recommended Reading: Amazon Web Services and MPI for ns-3


LTE Scheduling with the FemtoForum MAC Scheduler API

Mentors: Nicola Baldo, Marco Miozzo

  • LTE Scheduling with the FemtoForum MAC Scheduler API: The ns-3 LTE module released by the LENA project supports the FemtoForum MAC LTE MAC Scheduler Interface Specification for the implementation of MAC schedulers. Currently, only simple Round Robin and Proportional Fair schedulers are supported. As part of this project, the student should implement one or more scheduling algorithms found in the literature on top of the FemtoForum MAC Scheduler API. A few example algorithms are listed below in the references; however, the choice of the algorithm is left to the student. In any case, we stress that the focus of this project should be on the implementation of an existing and well-defined algorithm (not on the design of a new algorithm).
    • Required experience: C++
    • Bonus experience: ns-3, 3GPP standards
    • Interests: LTE, dynamic packet scheduling, radio resource management
    • Difficulty: hard
    • Recommended reading
      • ns-3 LTE module released by the LENA project
      • FemtoForum MAC LTE MAC Scheduler Interface Specification
      • Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Rossella Fortuna, and Pietro Camarda, Two-level downlink scheduling for real-time multimedia services in LTE networks, IEEE Trans. Multimedia, vol. 13, no. 5, pp. 1052 - 1065, Oct., 2011, doi: 10.1109/TMM.2011.2152381 .
      • Stefania Sesia, Matthew P. J. Baker, Issam Toufik, Long Term Evolution: from theory to practice, John Wiley and Sons, 2009
      • B. Sadiq, R. Madan, and A. Sampath, Downlink scheduling for multiclass traffic in LTE, EURASIP Journal on Wireless Communications andNetworking, vol. 2009, Article ID510617, 2009
      • G. Monghal, K. I. Pedersen, I. Z. Kov´acs, and P. E. Mogensen, QoS oriented time and frequency domain packet schedulers for the UTRAN long term evolution, in Proceedings of the IEEEVehicular Technology Conference (VTC 2008), pp. 2532– 2536, 2008.
      • D. López-Pérez, A. Ladanyi, A. Jüttner, H. Rivano and J. Zhang, Optimization Method for the Joint Allocation of Modulation Schemes, Coding Rates, Resource Blocks and Power in Self-Organizing LTE Networks, IEEE INFOCOM (International Conference on Computer Communications), Shanghai, China, April 2011

Random Mobility in presence of Buildings

Mentors: Nicola Baldo, Marco Miozzo

  • Random Mobility in presence of Buildings: The ns-3 buildings module (currently under review for inclusion in ns-3-dev) provides means to simulate the presence of buildings in a wireless network topology, however it currently only support static users. As part of this project, the student should add support for random mobility models that explicitly deal with the presence of buildings.
    • Required experience: C++
    • Bonus experience: ns-3, mobility models
    • Interests: wireless networks
    • Difficulty: medium
    • Recommended reading


ns-3 optics module: models for WDM network components

Mentors: Vedran Miletić

  • ns-3 optics module: models for WDM network components: ns-3 presently doesn't include module for simulating (D)WDM optical networks, but one is being prototyped (code will be uploaded to code.nsnam.org repository). The goal of this module is to model interconnection, signal propagation delay and loss in fiber, coupler, splitter, multiplexer, demultiplexer, add-drop multiplexer and optical cross-connect. This will allow modelling of various optical node architectures composed of these components. In addition, the goal is to provide models for all devices that have an IP-based control plane with an interface for implementing one using GMPLS. GMPLS-based control plane can be implemented in ns-3 by extending already existing ns-3 MPLS module (not yet a part of official distribution). As part of this project, the student should do one or more of the following: add models for optical delay and loss in components, model for EDFA optical amplifier, and nonlinear effects; generalize MPLS module and implement GMPLS control plane (emphasis on usable routing and resource reservation implementation); extend module towards modelling optical access or local area networks.
  • Required Experience: C++, an undergraduate-level knowledge of computer networks and optical communication
  • Bonus Experience: Any experience with modelling electrical or optical components using a programming language
  • Interests: Optical communication, IP over WDM networks
  • Difficulty: medium to hard, depending on what the student proposes to implement
  • Recommended reading:
    • Rajiv Ramaswami, Kumar Sivarajan, Galen Sasaki, Optical Networks: A Practical Perspective, Morgan Kaufmann, 2009.
    • Thomas E. Stern, Georgios Ellinas, Krishna Bala, Multiwavelength Optical Networks: Architectures, Design, and Control, Cambridge University Press, 2008.
    • Martin Maier, Optical Switching Networks, Cambridge University Press, 2008.
    • John Zyskind, Atul Srivastava, Optically Amplified WDM Networks, Elsevier, 2011.
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC2012Projects&oldid=6624"