Dynamics: Requirements specification

Dynamics
Requirements specification	$Revision: 1.3 $	State approved
Date 02-Nov-1998	Author Tom Weckström
Review date 04-Nov-1998	Reviewed by Jouni Malinen
Approval date 04-Nov-1998	Approved by Jouni Malinen

$Id: req_spec.html,v 1.3 1998/11/04 18:50:10 jkmaline Exp $

Executive summary

This is the Requirements specification for the Dynamic IP-tunnel software project carried out on a HUT course Tik-76.115 during the academic year 1998-1999. The project concentrates on mobility management and IP-protocol tunneling of a mobile computer using IPv4-protocol in network connections. The requirements of the customer have been listed, separated into different requirement types and prioritized. A specific Quality plan naming the most important requirements is at the end of the document. In brief: the goal of the project is to produce a software prototype for hierarchical, transparent, dynamic IPv4-tunneling with slight optimization of the tunnel updates.

Index

1. Introduction
    1.1 Project overview
    1.2 Terminology, definitions and acronyms
    1.3 Document structure
2. General description
    2.1 Environment, external interfaces and users
    2.2 General constraints
3. Requirements
    3.1 Functional requirements
    3.2 Product requirements
    3.3 External requirements
    3.4 Other requirements
4. Quality plan
5. References

1. Introduction

This chapters gives a brief introduction to the Dynamic IP-tunnel project and describes the contents of this requirements specification.

1.1 Project overview

Wireless LANs, protocol tunneling and mobility management are areas of growing interest these days. Mobile users, no matter what foreign network they are roaming in with their laptop computers, are willing to get the same services on the move as they would get when attached to their office LAN using Ethernet and IP-protocol.

The Dynamic IP-tunnel project will be carried out at the HUT course Tik-76.115, Software project during the academic year 1998-1999.

In the Dynamic IP-tunnel project (from this on called "project" in this document) a group of software components (from this on "the software") is developed to enable mobile users using personal computers with IPv4-protocol to access the Internet via IP-protocol tunneling system.

The software to be developed in the project shall be used in the MART-project represented by Jari T. Malinen. The software may also be used in other projects.

The goal of the system is to make it easier to move with a computer attached to IPv4-network, provide a scalable solution for IP-tunneling, reduce the tunneling system administration effort from that of maintaining the tunnels manually, provide analysis possibilities for administrators and configurability to both users and administrators.

Project manager Tom Weckström is responsible for the consistency of this document with the current situation in the project.

For a more general insight into the project, please refer to the Project plan document.

1.2 Terminology, definitions and acronyms

The terminology of this document and the whole project will follow the terminology used in the RFCs (Requests For Comments) of the mobile IP and IP-tunneling field, especially [RFC2002]. The used terminology is specified in the terminology specification.

In this document the requirements are classified according to Sommerville's ideas of requirements classes [SOMM96]. They are prioritized using a scale from 1 to 5. Table 1 defines the priorities. The verbs describing the need of a requirement are defined as shall, should and may according to the descending priority level.

Priority	Explanation
1	A mandatory requirement.
2	A strongly recommended important requirement.
3	A relatively important requirement.
4	A fairly unimportant requirement.
5	An extra requirement that would be nice to have.

Table1. Requirements priorities

1.3 Document structure

Chapter 1 (Introduction) gives general objectives of the system and some background for reading and understanding the Requirements specification document. Chapter 2 (General description) describes the interfaces between the system using the software and other parts of the network. The users and environment of the software are discussed. This chapter also covers the general constraints in the project. Chapter 3 (Requirements) is the core of this document. It concentrates on the actual requirements. The requirements are categorized and prioritized. The requirements are represented in the following sections. Section 3.1 (Functional requirements) lists the functionality required from the software. Section 3.2 (Product requirements) characterizes the requirements bound closely to the entire product. Section 3.3 (External requirements) presents the requirements stated for inter operability, costs and related issues. Section 3.4 (Other requirements) lists the features not categorizable to any of the above requirement classes. Chapter 4 (Quality plan) lists the most crucial goals of the project. These goals have been agreed together with the customer and the project team. Since these requirements have a strong influence on the product quality, also means for measuring the quality have been suggested. The goals have been prioritized. Chapter 5 (References) lists the references used in forming the document outline, learning about requirements management and getting to know IP-tunneling.

2. General description

This chapter gives the general description of the system. System's interfaces to the external environment are discussed. The intended user groups are represented. General constraints of the project are discussed.

2.1 Environment, external interfaces and users

The software developed in the project will enable hierarchical IP-tunneling. Hierarchical tunneling makes the tunneling system more flexible and more easily maintainable than current solutions with fixed, manually updated, nonhierarchical tunnels. The tunnel will reach from the mobile node to its home network. The software handles data on the network layer, IP-protocol level. The working environment of the software will be a network of computers and routers using IPv4 as their network level protocol. The computers on the network may be attached to it by any way that will not prevent the use of standard IP-routing as far as the link layer interface is transparent to IP-layer protocols.

The tunneling environment will consist of mainly the elements described in [RFC2002]. In addition to mobile node, foreign node (also known as access point) and home node, there may also be an element called intermediate node that acts as a combining entity between the elements of a hierarchical tunnel. A general view of the tunneling system is shown in figure 1.

Figure 1. Mobile Node changes the Foreign Agent.

The users willing to utilize the software should have the Linux operating system installed on their computer.
The intended users of the software are:

End users

anyone willing to be connected to the Internet while roaming in a foreign network.

Service providers

anyone willing to provide tunneling service for mobile computers trying to connect to their home networks.

Administrators of the home network

providing the forwarding of tunneled data from the home network to the Internet.
providing connections from Internet to mobile computers roaming in foreign networks that offer tunneling services.

The tunnel will be hierarchical and the endpoints of the tunnel will be the mobile computer and a node that lies in the home network of the mobile computer.

2.2 General constraints

The implementation will be constrained by the tools and environment of the Linux operating system.
The operation of the software will be restricted to networks using IPv4.
Attaching and registrating to the foreign network may cause some constraints. E.g. IP-address allocation via DHCP causes some delays.
The time for the project is limited to the schedule of the course Tik-76.115.

3. Requirements

In this chapter each requirement is stated, described and prioritized. To have an overview of all the requirements, see the table of prioritized requirements.

3.1 Functional requirements

Requirement:

Tunneling shall be hierarchical.

Description:

Priority:

Requirement: The system shall update only those elements that need to be updated.
Description: The entire tunnel must not be broken and re-established because of the software when the mobile node moves from one access point to another in the foreign network inside the same subnetwork.
Priority: 1

Requirement: The length of the tunnel shall not be explicitly restricted by the system architecture.
Description: The number of elements of which the tunnel is constructed is not restricted by any definitions of the system. The system will be able to handle tunnels of finite length.
Priority: 1

Requirement: The tunnel configuration information updates shall be dynamic.
Description: The tunnel parameters in the home network, mobile computer and tunnel elements must be automatically updated as the mobile computer moves.
Priority: 1

Requirement: Further development and inter operability shall be supported.
Description: The inter operability of different software versions in the same tunneling environment shall be possible. The elements of the system should be capable of recognizing which version can be used.
Priority: 1

Requirement: The functionality should be transparent to the mobile user.
Description: The mobile user should not need to configure anything as he detaches from one lowest foreign agent and attaches to another. The restrictions caused by other than IP-protocol are outside the scope of the project.
Priority: 2

Requirement: The lowest foreign agents should use broadcasting to advertise availability.
Description: The lowest foreign agents in the foreign network should broadcast information about its availability for mobile users.
Priority: 2

Requirement: The mobile node shall select the lowest foreign agent.
Description: Based on the information about available access points, the mobile node shall decide, which lowest foreign agent it will use. No additional guidance from the network shall be needed.
Priority: 2

Requirement: The home elements shall handle several concurrent users.
Description: The elements of the home network shall support several concurrent mobile users. The number of concurrent mobile users allowed by the home node shall be at least 255.
Priority: 2

Requirement: Mobility management information updates shall be secure.
Description: The mobile node shall authenticate itself with the home network part of the software. Only the right mobile node shall be able to change the mobility management information.
Priority: 3

Requirement: The system should support logging.
Description: Administrators should be able to monitor the tunnel configuration. The software should keep log of the mobile nodes. The logged parameters are not defined yet.
Priority: 3

Requirement: Resource allocation should be optimized.
Description: The system should be able to drop the connections that fulfill certain criteria. E.g. The node in the home network should be able to drop the connection if no packets are delivered to or from the mobile node in a specified time.
Priority: 3

Requirement: There may be multiple modes for tunneling.
Description: Support for optimal encapsulation may be implemented. In different modes the decapsulation may be done in different parts of the tunneling system.
Priority: 5

3.2 Product requirements

Requirement:

The product maturity level shall be a working prototype.

Description:

Priority:

Requirement: The software shall have an installation mechanism.
Description: The system should be easily installable in a sense that the installation is relatively short in duration, the system has clear installation documentation and the installation follows the common installation conventions of the operating environment. In this context "installation mechanism" does not mean automatic installation.
Priority: 2

Requirement: The mobility management security design should be modular.
Description: It should be possible to provide another way of secure mobility management. This can be done by adding e.g. a new module. The change should be possible without changing the code considerably.
Priority: 3

Requirement: Each piece of the software should be configurable.
Description: The software elements should provide a way to configure all the static user information that is crucial from the mobility management point of view.
Priority: 3

Requirement: There should be monitoring tools for the software.
Description: It should be possible to monitor the system behavior.
Priority: 3

Requirement: There should be a programming API for the software.
Description: There should be a useful administrative API giving interfaces to system monitoring.
Priority: 3

3.3. External requirements

Requirement:

The mobility of the mobile node shall be transparent to an external observer.

Description:

Priority:

Requirement: The IP-protocol version shall be 4.
Description: IPv4 must be used since it's widely used and the current standard.
Priority: 1

Requirement: The platform should be Linux.
Description: The platform for the software should be Linux. The use of any specific version
is not required, however.
Priority: 2

3.4 Other requirements

Requirement:

Tunneling should be possible with minimum firewall openings.

Description:

Priority:

Requirement:

The software should not be a clear bottleneck.

Description:

Priority:

Requirement: The portability should be taken into account.
Description: The software should be implemented so that it is portable with tolerable effort, apart from operating system specific parts.
Priority: 4

4. Quality plan

This chapter introduces the most crucial requirements agreed by both the customer and the project team. Some requirements concerning the end product, software development process and methods have been added to the requirements of the customer. Internal order of the requirements is suggestive at this stage. Attention has also been paid on the verification and measurement methods of these crucial requirements.

Requirement types:
    F    Functional
    E    External
    T    Team requirement

The quality objectives and their criteria, meters:

Type Requirement Priority Meter Criteria

F Tunneling shall be hierarchical. 3 Goal achieved? Goal achieved.

F The system shall update only those elements that need to be updated. 4 Goal achieved? Goal achieved.

F The length of the tunnel shall not be explicitly restricted by the system architecture. 6 Goal achieved? Goal achieved..

F The tunnel configuration information updates shall be dynamic. 5 Goal achieved? Goal achieved..

F Further development and inter operability shall be supported. 2 Modularity of design. Features can be enhanced by replacing a module.

E The IP-protocol version shall be 4. 10 Is the version 4? Version is 4.

E The mobility of the mobile node shall be transparent to an external observer. 7 What's the impact of movement to external observer. Observer won't notice anything.

T The end product shall be good enough for further development. 1 Clear and complete documentation.
Will the project actually be used? All design and architechture issues are documented.
Project can be used in later projects.

T The scheduling shall be proactive. 11 Were the documents ready in advance? 75% of documents are ready in advance

T Important documents and the code shall be reviewed. 8 Percentage of documents reviewed. 100% of important docs & code are reviewed.

T CVS version control shall be used. All the deliverables shall be versioned. 9 Used/not used? CVS is used.

5. References

[SOMM96]	Sommerville, Ian, Software Engineering, 5th Edition, Addison-Wesley 1996, ISBN 0-201-42765-6.
[RFC2002]	Perkins, C., IP Mobility Support, IBM, October 1996 <URL: ftp://ftp.funet.fi/pub/standards/RFC/rfc2002.txt >
	MART-project WWW-pages. <URL: http://www.cs.hut.fi/~mart/ >
	Kontio, Jyrki, Tik-76.601 Requirements management lecture slides, 1998. <URL: http://www.cs.hut.fi/opinnot/tik76601/Tik-76601_reqmgmt_2pp.PDF >

Type	Requirement	Priority	Meter	Criteria
F	Tunneling shall be hierarchical.	3	Goal achieved?	Goal achieved.
F	The system shall update only those elements that need to be updated.	4	Goal achieved?	Goal achieved.
F	The length of the tunnel shall not be explicitly restricted by the system architecture.	6	Goal achieved?	Goal achieved..
F	The tunnel configuration information updates shall be dynamic.	5	Goal achieved?	Goal achieved..
F	Further development and inter operability shall be supported.	2	Modularity of design.	Features can be enhanced by replacing a module.
E	The IP-protocol version shall be 4.	10	Is the version 4?	Version is 4.
E	The mobility of the mobile node shall be transparent to an external observer.	7	What's the impact of movement to external observer.	Observer won't notice anything.
T	The end product shall be good enough for further development.	1	Clear and complete documentation. Will the project actually be used?	All design and architechture issues are documented. Project can be used in later projects.
T	The scheduling shall be proactive.	11	Were the documents ready in advance?	75% of documents are ready in advance
T	Important documents and the code shall be reviewed.	8	Percentage of documents reviewed.	100% of important docs & code are reviewed.
T	CVS version control shall be used. All the deliverables shall be versioned.	9	Used/not used?	CVS is used.