COMMUNICATION SYSTEMS DESIGN STARO 2002 The Parties involved in StaRo have reached an agreement to work in accordance with the attached project plan. All changes that will be made in the project plan from now until the completion of the project have to be negotiated separately among the Parties and have to be signed by all Parties. The coach is responsible for distribution one copy of this contract to all Parties involved and to distribute all future changes made.

Stockholm 2002-02-19

………………………………………..

………………………………………

The Principles Thomas Eriksson

The Main Coach Yong Jiang

………………………………………..

………………………………………

Student Johan Waessman

Student Lars Strid

………………………………………. Student Monica Åhlander

………………………………………. For The Teaching Team Björn Pehrson

StaRo’s Project Plan 2002-02-14

A project within the course 2G1319, Communication Systems Design, 2002

Written by Johan Waessman, Lars Strid, and Monica Åhlander

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

2(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

Contents 1

Introduction........................................................................................................................ 4

2

Background ........................................................................................................................ 4 2.1

Internet Topology....................................................................................................... 4

2.2

Routing Protocols ....................................................................................................... 4

2.3

Observed Problems .................................................................................................... 5

2.4

The Origin of The StaRo Project................................................................................ 5

2.5

The RIPE NCC........................................................................................................... 6

2.6

Problems in inter domain routing............................................................................... 6

3

Project Tasks ...................................................................................................................... 7

4

Goal.................................................................................................................................... 7

5

Implementation................................................................................................................... 8

6

Organization....................................................................................................................... 8 6.1

Project members in StaRo .......................................................................................... 8

6.2

Coaches for the StaRo project .................................................................................... 9

6.3

Sponsors from Telia Research AB............................................................................. 9

6.4

Course Credits............................................................................................................ 9

6.5

Related Projects .......................................................................................................... 9

6.6

Communication........................................................................................................ 10

6.7

Stakeholder analysis ................................................................................................. 10

7

Project model.................................................................................................................... 11

8

Deliverables...................................................................................................................... 12

9

Modules ............................................................................................................................ 12 9.1

The Telia-tool........................................................................................................... 12

9.1.1

The Receiver, Recvlog..................................................................................... 13

9.1.2

The Analyzer.................................................................................................... 13

9.1.3

The Database.................................................................................................... 13

9.1.4

Web-interface................................................................................................... 13

10

Comments of the time plan .......................................................................................... 13

11

Risk analysis................................................................................................................. 14 11.1

Risk matrix ............................................................................................................... 14

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

3(16) Version 4

Information Technology, KTH Project: StaRo [email protected] 11.2

Action list ................................................................................................................. 15

12

Document handling ...................................................................................................... 15

13

Appendixes ................................................................................................................... 15

14

Abbreviations ............................................................................................................... 15

15

References .................................................................................................................... 16

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

4(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

1 Introduction The StaRo, short for Stable Routing, project is a cooperation between Telia Research and the Department of Microelectronics and Information Technology (IMIT) at the Royal Institute of Technology (KTH) as a part of the IT-University in Kista, Stockholm. The team members attend the course Communication Systems Design during the spring term in 2002, which implements problem based learning driven by projects. This particular project is a part of the research that our coach, Yong Jiang, is involved in at Telia Research, a work related to his thesis at KTH.

2 Background The Internet has developed in a way that was never anticipated in its early years. It began in 1969 with ARPAnet, when four computers, located in four university campuses in the United States, were connected to each other. The purpose was to facilitate research institutions to use each other’s mainframes and to exchange information. Other similar networks followed and the next step was to connect these different networks to each other [1]. Today Internet is a huge cobweb of interconnected networks around the world. It has become a vital part in many aspects of modern life.

2.1 Internet Topology The Internet consists of thousands of areas called Autonomous Systems (AS). An AS is a network or a collection of routers administrated by one authority, usually running a single internal routing protocol. There are different kinds of ASes. Some are smaller enterprise networks and others are big Internet Service Provider (ISP) networks, which connect to each other to transit traffic for the Internet. They are also called backbone networks.

2.2 Routing Protocols There are several routing protocols being used for routing traffic within an AS, for example IS-IS (Intermediate System-to-Intermediate System) and OSPF (Open Shortest Path First). These are link state protocols, which means that the routers send topology information to all other routers about their adjacencies to other routers. Each router computes their own map of the network topology and the distance to the destinations they can reach. For routing traffic between ASes the BGP (Boarder Gateway Protocol) version 4 is the main protocol in use. BGP4 is a distance vector protocol called a path vector protocol. The routers establish a connection to their neighbors, called peering, and send routing information to each other frequently. The announcing router tells its neighbors what IP addresses or prefixes (aggregated addresses) it can reach. It also includes a list of which ASes to traverse, i.e. the path, to reach these destinations. This information is stored in the routers database and it can easily add up to over 100 000 entries. If the router receives more than one route to a

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

5(16) Version 4

Information Technology, KTH Project: StaRo [email protected] destination it selects the best path. This, together with the other learnt and accepted routes, will be put in the routers forwarding table. Whenever there is a change in the network, either an existing route becomes unavailable or a new route becomes available, update messages are sent and the router updates its routing table. The information in the routing table is further announced to the peering routers.

2.3 Observed Problems There is a growing concern about the future capacity of Internet to handle the very big growth of the route instances in the routing tables of backbone routers. The growth is faster than the allocation of prefixes or addresses. The development with more users and more services, places higher demands to the Internet. The routers can send update messages to each other, with changed or new information within a time period, usually 30-90 seconds. New information causes the router to recalculate its routing table (preferred routes). If the route entries advertised to the router become so many, that the process of selecting routes for the routing table isn’t finished until the next update comes, it will disrupt the traffic through that router. That would require routers with better CPUs (Central Processing Unit), which will make them more expensive. While backbone routers send and receive update messages with information about a change in the network topology and perform their selection process, it takes some time for the Internet to reach a consistent view of the network topology. This time is called the convergence time and it can be tens of minutes long. During this time part of the Internet may suffer loss of reachability. [5] In order to find solutions to these threats to a stable reliable connectivity in the Internet, several studies have focused on the character of the BGP4 protocol and how network administrators are using it. Measurements have been done to study what kind of routing information is advertised, why and if it is necessary or obsolete. The purpose is to discover if changes in the protocol or the manner in which it is being used, could decrease the amount of routing traffic in some substantial way.

2.4 The Origin of The StaRo Project A program called Babylon was created in 2001 for the purpose of revising the routing architecture and principles of Internet. The participating partners were Nortel Networks, Royal Institute of Technology (KTH) in Stockholm, Luleå University of Technology (LTU), Telia Research AB and Utfors Bredband AB. There were three projects in the program, Inter Domain Routing Requirements, Inter Domain Routing Design and Inter Domain Routing Data Collection and Analysis. The StaRo project emanates from the Inter Domain Data Collection and Analysis project. The work at Telia Research has begun and data has been collected from three probes, two in Telia's network and one in Nordunet's network. Two kinds of data has been collected, BGP

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

6(16) Version 4

Information Technology, KTH Project: StaRo [email protected] message logs from peering routers and snapshots from routers' routing tables. Parts of this data has been prepared and analysed so far. The next step planned is to use the RIPE database to access more data to analyse, compare the result with those already obtained and find explanations to observations made when analysing collected data.

2.5 The RIPE NCC RIPE NCC (Reseaux IP Europeen Network Coordination Center) is a Regional Internet Registry for Europe and surrounding areas. It is an organization for European Internet Service Providers (ISPs), providing administration and coordination for the operation of the European Internet. RIPE distributes Internet numbers, coordinates the Domain Name System (DNS) and maintains a network management database with information on IP (Internet Protocol) networks, DNS and IP routing policies. [4]

2.6 Problems in inter domain routing These are some of the known problems in inter domain routing that we will try to investigate: •

BGP message load on the Internet. There are a lot of BGP messages sent between routers. The question is if all of them are necessary?

•

BGP duplicates. Most of the update BGP messages that the routers receive are duplicates, 40% according to the Babylon report. [2]

•

Reasons behind peaks in the message load. If a route goes up and down the routing tables will have to update whether this route is available or not. To make this update a lot of BGP messages have to be sent between the routers. It is of interest if this kind of behavior is usual or not and how much it affects the Internet.

•

Up time. A prefix is up when there is a BGP announcement message received. A prefix is down when a withdrawal message has arrived. The time between an announcement message and a withdrawal message is the time when a prefix is up. Up time is a big problem though 13% of the total prefixes have a low reachability of 20%. [2] It is of interest to know how large impact uptime has on the routers and that the uptime might have decreased in the past years.

•

Flapping. This happens if a router sends withdrawals and announcement message within a short period of time. The cause of this can for example be router failure, link failure or a misconfiguration in the router.

•

Network napping. People are using addresses belonging to someone else. This can lead to inconsistencies in the routing. Different origins announce the same or longer prefix. It is hard to detect the problem today.

•

Erroneous networks (such as a /8 network announced by 10 ASes). One example is network that only exists some hours per day that make it hard for the routers to decide

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

7(16) Version 4

Information Technology, KTH Project: StaRo [email protected] if the network exists or not. The analysis here is to investigate the reasons behind these erroneous behaviors. •

Peer monitoring. Is the peering relation working well or is there any problem on the peer? There might be problems with for example flapping, convergence time, erroneous networks and others.

•

Convergence time between several exchange points. When a route is down it might take several minutes for it to converge and become available for data traffic.

3 Project Tasks 1. Define what information to get from the raw data. 2. Write scripts to get results from the RIPE database. 3. Set up a database storing all the results. Some of the problems that we can investigate are listed below. Problems that we will solve easily: •

BGP message load on the Internet.

•

BGP duplicates. How many BGP messages are duplicates?

•

Reasons to the peaks in the message load.

•

Up time. Some routes can be down for very long time intervals.

•

Flapping. Routes that goes up and down many times in a short period.

More difficult problems: •

Network napping. Napping of IP addresses.

•

Erroneous networks (such as a /8 network announced by 10 ASes)

•

Peer monitoring. To investigate if the Peering is used in a correct way.

•

Convergence time between several exchange points.

4 Goal The overall goal of the project is to identify indicators of impending network instability. It is presumed that there will be indicators of this in the BGP message flow or in the nature of routing table fluctuations, when the network is in the process of destabilizing. The specific goals of this project are: •

To quantify and identify causes for the five easy problems which are described under “Project Tasks”.

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

8(16) Version 4

Information Technology, KTH Project: StaRo [email protected] •

To quantify and identify causes for one or more of the difficult problems which are described under “Project Tasks”.

•

To maybe identify a new problem with inter domain routing and quantify and identify this problem.

5 Implementation The work in the project will be done as described below: 1. Define what information to get from the raw data. 2. Write scripts to get results from the RIPE database. 3. Set up a database storing all the results. 4. Check if the result corresponds to the earlier results from Telia measurements. 5. If the result does not correspond try to answer why. 6. Write scripts for analyzing one or more of the difficult problems described in the section “Project Tasks”. 7. Draw conclusions from the result of the work during the previous point (6). 8. Study the raw data to maybe identify new problems. 9. Write scripts to analyze the new problems 10. Draw conclusions from the result of the work during the previous point (9).

6 Organization Email-address to whole StaRo: [email protected]

6.1 Project members in StaRo Johan Waessman is Project manager and responsible for the StaRo web site. E- mail: [email protected]

Cellular phone: 073-33 23 845

Monica Åhlander is responsible for deliverables. E- mail: [email protected]

Cellular phone: 070-41 20 963

Lars Strid is responsible for project documents and the video presentation. E- mail: [email protected]

staro_pp_v4.doc

Cellular phone: 070-79 26 101

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

9(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

6.2 Coaches for the StaRo project Yong Jiang is Main Coach for this project. E- mail: [email protected]

Cellular phone: 070-34 87 200

Fredrik Lilieblad is Assistant Coach for this project. E- mail: [email protected]

Phone: 070-72 33 320

6.3 Sponsors from Telia Research AB Thomas Eriksson is the sponsor for the StaRo project. E- mail: [email protected]

Phone: 08-713 81 20

6.4 Course Credits Johan Waessman is going to take 10 credits. Lars Strid is going to take 10 credits. Monica Åhlander is going to take 16 credits. The extra work that Monica is going to do to earn 6 extra credits are: •

Try to explain the results and find the reasons behind them.

•

Literature survey of current Inter Domain routing problems.

6.5 Related Projects Parallel to this project there is one other projects running which are related to the StaRo project. Mozambique IX. The main objective of the project is to setup a low cost based Internet exchange. Given the lack of availability of cabled infrastructure that can offer high bandwidth at reasonable cost, a possibility of use of innovative technologies will be investigated and applied. Website: http://2g1319.ssvl.kth.se/%7Ecsd2002- mozambiqueix/

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

10(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

6.6 Communication •

The meetings will take place at least once a week at the Forum level 6 or at Telia Research AB in Farsta.

•

The project will every week deliver a progress report, including deviations, taken measures, suggested solutions and new risks.

•

Every one contributes important links and new ideas about the project on the homepage.

•

We share some important technical points among the team members by means of group emails. This is to help each other to understand the relevant principles and the progress of other members.

6.7 Stakeholder analysis There are a number of people who are interested in the project outside of the students. In table 1 we have listed them and the kind of interest or help they may provide the project. C is the current position of the stakeholder in the project and D is the desired position. The different positions are: •

Let: the stakeholder lets the team work as it wants

•

Block: the stakeholder blocks the project

•

Help: the stakeholder helps the project

•

Make: the stakeholder puts him in a position where he is of help to the team Stakeholders

Block

Let

Help

Make

Thomas Eriksson Telia Research AB

C

C

C

C

He has put up the preliminary specifications of the project and is interested in the result.

Principal Yong Jiang Coach Fredrik Lilieblad Co-coach Björn Pehrson Professor Table 1: Stakeholders Analysis.

staro_pp_v4.doc

C C

More specifications

D

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

11(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

7 Project model Date

Nr

Task

Tollgate/

Document

Participant

Milestone Feb. 13th (noon)

1

Project Plan

Milestone

Project Plan

StaRo

Feb. 21st (noon)

2

Project Plan signed

Tollgate

Contract

Telia Research AB and teaching team

Mar. 1st

3

Convert data and store in database

Milestone

Database

Team members

Mar. 16th

4

A lessons learned paper

Milestone

A lessons learned paper

Team members

Mar. 20-22nd (exact time TBD)

5

Midterm Presentation

Milestone

Apr. 5th

6

Writing scripts

Milestone

Finished scripts

Team members

May 3rd

7

Analyze the results

Milestone

Analysis finished

Team members

May 6th

8

Monica’s literature study

Milestone

Literature study finished

Monica

May 23rd

9

Final Project Report

Milestone

Project Report

StaRo

May 23rd

10

3 Minutes Video project presentation

Milestone

3 Minutes Video

Team members

May 28-29th (exact time TBD)

11

An oral presentation of the results at a concluding workshop

Milestone

An oral presentatio n

Team members

May. 30th

12

Exhibition

Milestone

A demonstration

Team members

Table 2: Project model.

staro_pp_v4.doc

StaRo

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

12(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

8 Deliverables Deliverable

Deadline

Project Plan

Feb. 13th (noon)

Project Plan/contract signed and approved by the project principal

Feb. 21st (noon)

A lessons learned paper (Problem Addressing)

Mar. 16th

Midterm Presentation

Mar. 20-22nd

Final Project Report

May. 23rd

3 Minutes Video project presentation

May. 23rd

An oral presentation of the results at a concluding workshop

May 28-29th (exact time TBD)

A demonstration at an exhibition associated with the workshop

May. 30th

Table 3: Project Deliverables

9 Modules The tools that are used in this project is primary a tool developed by Telia and scripts developed by this project. [2] The Te lia-tool will be used to do some analysis on the BGPupdate-traffic. To do further analyzes of things that are not covered by the Telia-tool the project will have to develop new scripts to do those analyses.

9.1 The Telia-tool The Telia-tool is a tool that analyzes BGP-update messages. The tool consists of a system with four parts. The first part is the receiver that notices when new data arrive and sends the data to the analyzer. The second is the analyzer that parses and analyzes the data and then puts the result in a database. The third part is the database that stores the result from the analyzer. The forth part is the web- interface that is located on a web-server and collects the data from the database and presents it to a user via a browser. To easier understand how the tool works all the parts will be further described below in the order that the data is processed in the tool.

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

13(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

9.1.1 The Receiver, Recvlog Recvlog is a simple script that will notice if there is new raw data to be collected from the working directory. If it notices new data it will send it both to the analyzer and an archive so old data can be viewed later on.

9.1.2 The Analyzer The analyzer program receives data from Recvlog and parses the data and then analyzes it. The analyses are done here instead of in the web-interface because of the amount of time that it takes to do analyzes from a database with all the BGP-update- messages. The analyzing can be divided in to two groups AS-statistics and Prefix-statistics. AS-statistics looks at the statistics concerning the autonomous systems like how many announcements were made by an AS per hour, how many withdrawals were made by an AS per hour and so on. Prefix-statistics looks at the statistics that tells how the different prefixes behave. An example of such statistics is the number of times every prefix goes up and down When the analyses are done the analyzer program sends the data to the database.

9.1.3 The Database The database is a MySQL-database that stores the data from the analyzer in separate tables for each analysis. If there are several probes that have collected data every probe gets an own database. The analyzed data from the database can be viewed via the web-interface.

9.1.4 Web-interface The web-interface is made with PHP (an HTML-embedded script language) pages that are located at an Apache web server. To get nice graphs and plots the web-interface uses a program called Ploticus. The PHP-pages can be viewed with a browser by connecting to the web server. In the web- interface the user can choose which analysis the user wants to look at and which type of statistics from that analysis the user wants to view. The data is then collected from the database, ran throw Ploticus if graphs is needed and then presented to the user by the browser.

10 Comments of the time plan Activities during the project time: 1. Project Plan: Making this document, deadline noon 13 February. 2. Project Plan signed: Deadline 21 February. 3. Data converted and stored in database. At this point we shall have all data ready to start working with. 4. Writing Lessons learned: Assignment paper to KTH, deadline 16 March.

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

14(16) Version 4

Information Technology, KTH Project: StaRo [email protected] 5. Midterm presentation (Preparing and participating): It takes place 20-22 March in Kista. StaRo will have a short presentation of the project. 6. Writing script that give us some interesting results from the raw data. 7. Analysis of the results ready. All analyses that we are supposed to do should be ready. 8. Writing individual contribution paper: Each member will deliver one copy to our main coach and one presented on our project's web page, not later than noon (12.00 hours). 9. Monica’s literature study that will be finished by the 6th of May. 10. Preparing of video: A short video presentation the StaRo project, deadline 23 May. 11. Writing a final report: technical report with the project results, deadline 23 May. 12. Preparing presentation: An oral presentation of the results, 28-29 May. 13. Preparing exhibition & demonstration: A demonstration at an exhibition associated with the workshop, 30 May.

11 Risk analysis 11.1 Risk matrix •

C: the consequence (on a scale from 1-5 where 5 is highest) that the risk may course.

•

P: the probability (on a scale from 1-5 where 5 is highest) that the risk will happen.

•

R: the total risk.

Nr

Risk

Consequence

C P

C*P=R Responsible

1

Members are not able to devote enough time in the project.

No good analyze result.

3

1

3

Johan Waessman

2

Problems making script that make it possible for us to draw conclusions from the raw data.

No analyze.

4

1

4

Lars Strid

3

The project becomes significantly delayed

No deliverables with interesting result.

3

2

6

Johan Waessman

Table 4: Risk matrix.

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

15(16) Version 4

Information Technology, KTH Project: StaRo [email protected]

11.2 Action list 1. Make sure that team members have enough time to devote for the project. 2. Study how to write scripts. If necessary ask Fredrik Lilieblad for help. 3. Follow the project plan and avoid doing things in the last minute.

12 Document handling All the documents will be available on the projects web page under the catalogue documents. The documents will be available both as Word- files and PDF-files. The documents will be named like: staro_[document type]_v[version number].[file extension] Ex.: staro_pp_v1.doc for the project plan version 1 saved as a Word- file. To upload new document the project members must use an FTP(File Transfer Protocol)program to connect to server, which holds the catalogues where the documents are stored. A backup of the files will be stored at Johan’s computer at home.

13 Appendixes Appendix 1: Activity List Appendix 2: Time Plan Appendix 3: Resource Plan Appendix 4: Activity Plan Appendix 5: Johan’s CV Appendix 6: Lars’ CV Appendix 7: Monica’s CV

14 Abbreviations Abbreviation Shorter for IS-IS

Intermediate System-to-Intermediate System)

OSPF

Open Shortest Path First

AS

Autonomous System

ISP

Internet Service Provider

DNS

Domain Name System

BGP

Border Gate Protocol

staro_pp_v4.doc

2G1319 Communication System Design

Project plan

Department of Microelectronics and

2002-02-14

16(16) Version 4

Information Technology, KTH Project: StaRo [email protected] RIPE NCC

Reseaux IP Europeen Network Coordination Center

FTP

File Transfer Protocol

IP

Internet Protocol

CPU

Central Processing Unit (Processor)

Table 5: Abbreviation list

15 References [1] Stora guiden om Internet, Jörgen Städje & Ahrvid Engholm, IDG AB, Stockholm 1994 [2] IDR Data collection and analysis report year 2001, Telia Research AB, Stockholm 2001 [3] BGP4 Inter-Domain routing in the Internet, John W. Stewart III, Addison-Wesley 4th printing 2001 [4] Internet Routing Architectures, Second Edition, Sam Halabi with Danny McPherson, Cisco Press, IN 46290 USA 2000. [5] Delayed Internet Routing Convergence. C. Labovitz, A. Ahuja, A. Bose and F. Jahanian, IEE/ACM Transactions on Networking, Vol. 9, No. 3, June 2001.

staro_pp_v4.doc

1(1)

Appendix 1: Activity list

Activity 1. Project Plan

Deadline / End of activity Deliverables 2002-02-13 Project plan

2. Project Plan signed

2002-02-21

3. Data converted and stored in database.

2002-03-01

4. Writing Lessons learned

2002-02-16

Lessons learned paper

5. Midterm presentation (Preparing and participating) 6. Writing script that give us some interesting

2002-03-20

Midterm presentation

results fromof thethe raw data.ready 7. Analysis results

2002-05-03

8. Writing individual contribution paper

2002-04-01

9. Monica will do her litterature study

2002-05-06

10. Preparing of video

2002-05-23

Project video

11. Writing a final report

2002-05-23

Final project report

12. Preparing presentation

2002-05-28

Oral presentation

13. Preparing exhibition & demonstration

2002-05-30

Exhibition

2002-04-05 Individual contribution paper

1(1)

Appendix 2: Time Plan January February Week

Date of change

2002-02-07

21

28

4

11

4

5

6

7

March 18

8 ∆2 o1

April

May

25

4

11

18

25

1

8

15

22

29

6

13

20

27

9

10

11

12

13

14

15

16

17

18

19

20

21

22

E o4

o5

H

o6

o7

o8

o3

X

O

A

L

M

I

S

D A Y

1. Project Plan 2. Project Plan signed 3. Data converted and stored in database. 4. Writing Lessons learned 5. Midterm presentation (Preparing and participating) 6. All script writing ready. 7. Analyse of the results ready. 8. Monica is finished with her litterature study 9. Preparing of video 10. Writing a final report 11. Preparing presentation 12. Preparing exhibition & demonstration

o9,o10 o11,o12

1(1)

Appendix 3: Resource Plan Week Participants Johan Lars Monica

Planed time

Johan AccounLars ted time Monica

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

50%

50%

50%

25%

25%

25%

0%

50%

50%

0%

0%

0%

50%

50%

75%

75%

75%

75%

50%

50%

100%

100%

50%

50%

25%

25%

100% 100%

50%

100%

25%

0%

100% 100%

50%

50%

0%

0%

0%

50%

50%

75%

75%

75%

75%

100%

100%

0%

0%

0%

100%

50%

50%

50%

50%

50%

Total number of hours 22 75% 320 75% 320 50% 520

50%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

50%

50%

50%

100%

100%

100%

0%

60 60 120

1400

Number of hours

1200 1000 800 600 400 200 0 3

4

5

6

7

8

9

10

11

12

13

Week

14

15

16

17

18

19

20

21

Planed time Accounted time

22

Appendix 4: Activity Plan February 4 11 Week 4 7

Activities Projct Plan Project Plan signed. Data converted and stored in database. Writing Lesson learned. Midterm presentation All script ready. Analyse of the result ready. Writing individual contribution paper. Prepering of video. Writing a final report. Prepering presentation. Preparing exhibition and demonstration. Monica will do her litterature study

18 8

25 9

March 4 11 10 11 E X A M S

18 12

25 13 H O L I D A Y

April 1 8 14 15

15 16

22 17

29 18

May 6 19

13 20

20 21

27 22

Appendix 5: Johan’s CV

1(1)

CV Personal information: Johan Waessman Erstagatan 17, 1 tr 116 36 Stockholm ID-number: 781122-0339 Telephone: 08-6400174 Mobile: 073-3323845 Educations: Electronics engineering, specializing in Communication-systems, 180 points, KTH, 1998Business economy 17 points, Stockholm’s University, spring 1998 3-year Science program, S:t Jacobi Gymnasium, Vällingby, 1995-1997 Jobs: Vaessman Data is my own company that works in the areas of Internet-programming and database-connected systems. These are some of the projects that I have done: - Booking-system for Swedpower AB, summer 2001 - Evaluation-system for Forsmarks nuclear power plant and Swedpower AB, spring 2001 - Jpskolnet.com web-page for BJP Infonet förlag AB, spring 2001 - Reference-database-system for Swedpower AB, summer 2000 - Helpdesc-system for Swedpower AB, spring 2000 - Pricelist-system for Swedpower AB, winter 1999 - Machine-reservation-program for TEMO finmekaniska AB, autumn1999 Swedpower AB, Easter and summer 1999 TEMO finmekaniska AB, autumn 1997 and summer 1998 Other: Active participant in Elektro’s exam- trip SRKA2003 as IT-manager, 2001-2003 Godfather for the Economics program on Stockholm’s University, autumn 1998, spring 1999 and autumn 1999 Reference: Robert Björkman, Systems development mana ger, Swedpower AB (I presuppose that I will be contacted before someone contacts my reference)

Appendix 6: Lars’ CV

1(1)

CURRICULUM VITAE Lars Erik Strid Date of birth: 21 March 1978 Nationality: Swedish

Education 1998 –

Graduate engineer elektroics (180 p), Kungliga Tekniska Högskolan, with datakommunication as individual choice. Extra courses: Management 5 p, Industriel economi 4p.

1997 – 98

Military service: Reconnaissance squad commander on athletic platoon in Kristinehamn.

1994 – 97

Science program, technical direction, Tumba gymnasium

Work experience 2001

Summer, measuretechnician at Stockholm Syd Mät och Data

2000

Summer, processoperator at Coca Cola Drycker Sverige AB.

1997-99

Summer, constructiontechnician at Ericsson Buisness Consulting.

1993-96

Summer, printeroperator at Ericsson Buisness Consulting.

Non-profit work 2001-

Team organizer in orienteering organisation Tumba-Mälarhöjden OK

1998-2000

Training organizer in orienteering organisation Tumba-Mälarhöjden OK

1995-1998

Editor-in -chief for organisation paper in orienteering organisation IFK Tumba OK

Computer skill Operativsystem:

UNIX, Windows

Programming: Language Skill

Java, VHDL Good

C, HTML Well

Language knowledge Swedish, english and some german.

Other Swedish driving licence type B.

Lars Strid Röntgenvägen 1 lgh 324 141 52 Huddinge tfn: 08 – 689 72 76 mobil: 070-7926101 [email protected]

Appendix 7: Monica’s CV

Curriculum Vitae for Monica Åhlander

Name: Monica Åhlander Address: Langelandsgatan 19, 164 43 Kista, Sweden

Phone: 08-752 87 42 Mob.: 070 412 09 63

E- mail: [email protected] , [email protected].

Education: Kungliga Tekniska Högskolan (Royal Institute of Technology) Bachelor of Science in Electrical Engineering, Specialized in Tele and Data Communication, 120 credits, 2001.

Thesis: “Improved Methology for error reports and handling of changes.” 10 credits.

Kungliga Tekniska Högskolan (Royal Institute of Technology) Tekniskt basår (One year Complementary Technical Education), 40 credits, 1997.

Socialhögskolan i Umeå (The Institute of Socialwork in Umeå) Socionom, social linje, degree in Social Work, social program, corresponding to 160 credits, 1975

S:t Jacobi Gymnasium, Vällingby, Stockholm

1(3)

Appendix 7: Monica’s CV Samhällsvetenskaplig linje, 3-årig Secondary school, 3 years, 1970

Courses:

Familjeterapicentrum, Göteborgs Socialpsykologiska Institut (Centre for Family Therapy, the Gothenburg Institute of Socialpsychology)

Basic Education in Family Therapy, 360 hours of lectures, 1993.

Psykologiska Institutionen vid Stockholms Universitet (Department of Psychology at Stockholm University) Barnpsykologi (Psychology of children), 10 credits, 1988.

Norra Latins Vuxengymnasium Finska C, (Finnish) 1977

Umeå Universitet (Umeå University) Basic course in Finnish, 20 credits, 1975

Work Experience: Ericsson Radio Systems AB, 2000-10-09 - 2001-09-30. Engineer at the unit for development of radio base stations for GSM. Worked as Configuration Manager, CM, with responsibilities concerning the process of documentation and storage of documents in databases.

Also thesis work about improved methology during May-August 2000.

Botkyrka kommun, 1975-09 – 2001-02

2(3)

Appendix 7: Monica’s CV (Botkyrka Municipality) Socialsekreterare. Social Welfare Secretary, making social investigations according to family law. Handling matters such as determination of paternity and maintenance contributions, investigations of adoption matters, name matters, guardian matters, marriage exemptions, assessments in custody and access matters and conducting talks between parents in dispute over custody and/or access matters.

Stockholms läns landsting (Hospitals) Beckomberga sjukhus, vik. mentalskötare (mental nursing attendant) during summer holidays 1973, 1974 and 1975 Åkeshovs sjukhus, sjukvårdbiträde (nursing attendant) during summer holidays 1969

Forsman Sightseeing AB, Stockholm Guide on regular sightseeing tours by bus and boat in Stockholm. Guiding in English, German and French. During summer season 1970 and 1971.

3(3)