Distributed Router Field Trial. Product Requirements Document. IK2209. Communication System Design. Fall 2007. Project Coach. Maral Kalajian.
Distributed Router Field Trial Product Requirements Document
IK2209 Communication System Design Fall 2007
Project Coach Maral Kalajian
Project Principal Markus Hidell
Project Champion Peter Sjödin
Project Team Eneas Hunguana (30p) Stavros Kafouros (30p) Adil Razzaq (15p) Xueliang Ren (30p) Haruumi Shiode (30p) Yu Sun (24p)
Table of Contents 1. Introduction ....................................................................................................................... 3 1.1 Purpose of this Document ........................................................................................ 3 1.2 How to Use this Document ...................................................................................... 3 1.2.1 Intended Audience ......................................................................................... 3 1.2.2 Technical Background Required .................................................................... 3 1.2.3 Overview Sections......................................................................................... 4 1.2.4 Reader Specific sections ................................................................................ 4 1.3 Scope of the product ................................................................................................ 4 1.4 Business case for the product ................................................................................... 5 1.4.1 The market View ........................................................................................... 5 1.4.2 Product Justification ...................................................................................... 5 1.4.3 Risks ............................................................................................................. 6 2. General description............................................................................................................ 7 2.1 Product perspective .................................................................................................. 7 2.2 Product features ....................................................................................................... 7 2.3 User characteristics .................................................................................................. 7 2.4 General constraints .................................................................................................. 8 2.5 Assumptions and dependencies ................................................................................ 8 3. Functional requirements .................................................................................................. 10 3.1 Distributed router in general ................................................................................... 10 3.1.1 Operating Environment ............................................................................... 10 3.1.1 Usability Attributes ..................................................................................... 10 3.2 Interfaces ............................................................................................................... 10 3.2.1 User interface requirements ......................................................................... 10 3.2.2 Hardware interface requirements ................................................................. 11
7 January 2008
Product Requirements Document
1
3.3.3 Software interface requirements................................................................... 11 3.3.4 Communication interface requirements ........................................................ 11 3.3 Protocol support requirements ................................................................................ 12 3.3.1 BGPv4 ........................................................................................................ 12 3.3.2 OSPFv2 ....................................................................................................... 13 3.3.3 IS-IS ........................................................................................................... 13 3.3.4 VRRP.......................................................................................................... 13 3.3.5 Remote Monitoring ..................................................................................... 14 3.3.6 SNMPv2 ..................................................................................................... 14 4. Non-functional requirements ........................................................................................... 16 4.1 Security requirement .............................................................................................. 16 4.2 Performance requirement ....................................................................................... 16 5. Product roadmap ............................................................................................................. 17 6. References ....................................................................................................................... 18
7 January 2008
Product Requirements Document
2
1. Introduction 1.1 Purpose of this Document This document is intended to guide the development of the Distributed Router, which is a product based on a new concept of decentralized and modular router architecture.
Document Status: Final
1.2 How to Use this Document 1.2.1 Intended Audience The audience is divided into two different groups of people.
Engineer field: •
Software developers
•
Network designers
•
Network administrators
•
Researchers in the computer network field
Business field: •
Product development partners
•
IT manager of the potential customers
•
Market researchers
1.2.2 Technical Background Required To have a general understanding of this document, it requires the audience to have the general technical background, which includes: •
Basic understanding of computer networks (OSI model and IP network).
•
Basic concepts of routing protocols.
•
Basic concepts of network management.
7 January 2008
Product Requirements Document
3
In order to understand all the details this document specifies, there are special knowledge requirement for the audience: •
Router functionality.
•
Software development.
•
Network management applications.
1.2.3 Overview Sections The following sections provide an overall understanding of the requirements on the distributed prototype: •
Chapter 1 – Sections 1.3
•
Chapter 2 – Sections 2.1, 2.2
1.2.4 Reader Specific sections Listed below are the sections targeted to specific types of readers.
•
For Engineers: All except Chapter 1.4
•
For Business partners: Chapter 1, Chapter 2 (Section 2.1 and 2.2), and Chapter 5
1.3 Scope of the product Trends in the router market suggest a move from monolithic router architectures to a decentralized and modular one. However, none of the current products provides a solution in which control element and forwarding element reside in physically separated boxes. By doing so, our distributed router offers one of the answers to provide the modularized router architecture which brings scalability, flexibility and robustness. Having this flexible solution, the cost to extend the network capacity will be reduced compared to current centralized solution. This product is not intended to introduce new router hardware in the market, but it aims to establish the framework for distributed router and provides some basic software components for a router.
7 January 2008
Product Requirements Document
4
1.4 Business case for the product 1.4.1 The market View
The router market has been dominated by Cisco until 1994, when a new startup company emerged, called Juniper; it somehow shook Cisco’s control, and took some of its market share. Since then, both Cisco and Juniper, together have formed, the 95% of the router market share, Cisco’s holdings were 70% whereas Juniper’s 26%. With time, new companies and different technologies started to evolve, such as Huawei, Avici, Alcatel-Lucent, Vyattta and many others all formed the “what was left from” Cisco and Juniper, the 5% of the market. Yet, two of these companies could not be disregarded; Huawei and Vyatta.
Recently, Huawei was and still is stealing more market share and paving its way into the 5% spot separately. Huawei, is currently dominating the Chinese and most of the Asian market due to its lower price yet good quality solutions, and now it is expanding its shares into Europe and North America. This leaves Cisco with a range of >65% market share, Juniper with >25%, Huawei with >5% and the rest occupy the >7% of the market.
The other competitor is Vyatta founded in 2005 by Allan Leinwand, a former employee of Cisco. Although the company is only two years old, it has changed the way routers are marketed. With their open source router; they sell the hardware and software separately. Vyatta introduced a different routing technology to the market by introducing the open source concept into the routers’ world.
Basically, we can say that the routers’ market is divided into 3 categories: proprietary technologies, low cost technologies and open source technologies.
1.4.2 Product Justification Changes in telecommunication industry are a way of life to keep pace. Due to the rapid technological growth in information technology field, it is no longer a rare sight for telecom companies, service providers and/or carriers, to have dynamic changes of their infrastructure to provide a new communication services. Under this circumstance, those providers and carriers have been under the increasing pressure to deliver the services on time.
7 January 2008
Product Requirements Document
5
The challenges of the current operators are providing new attractive services, reducing the operational cost, constantly upgrading their network to meet current and future consumer demands, and keeping up with or lead the technological trends within their budget.
The distributed router technology opens a collaborative platform. Distributed router has a modularized architecture with a standard interface, on which decentralized components communicate each other over internal network. This modular design allows building more flexible, scalable and robust network. Moreover, the collaborative platform allows the multiple vendors to play together on the same standard, which possibly results in accelerating the development of router technology.
1.4.3 Risks The router market is a very mature market. Competing with giants like Cisco and Juniper and soon Huawei, is not an easy path, yet, not an impossible one. The distributed router will introduce a different architecture than the one available in the market today. The unique architecture of the router is open for different hardware and software companies (could be competitors) to partner and work together. On the other hand, the distributed router should define its target segment thoroughly, creating itself a niche market, and then penetrating that specific niche market as a first step. Two major threats to be aware of are the fact that these large companies could lower their prices to “kick out” the new entrants or they could even run their own research projects to come up with a similar solution.
7 January 2008
Product Requirements Document
6
2. General description 2.1 Product perspective This new product in the market represents an alternative for the currently used solutions with routers in the market.
It is designed in order to allow for modularization of routing components, by splitting the different router's logical components into separate physical devices, communicating over an internal network.
2.2 Product features This modularized router will allow network operators to perform routing of IPv4 traffic in a modularized fashion, but still seen as single router to the outside world. It will offer the following features: •
Routing protocols support: BGPv4 [1], OSPFv2 [2] (for IPv4)
•
Redundancy services: VRRP [3] for the first hop access and BGP-ECMP [4] among the Autonomous Systems
•
Remote Management: SNMPv2C [5] protocol and MIB-II [6]
•
Configuration management: Web-based GUI and CLI configuration, Centralized configuration of multiple internal elements.
•
In-operation plug/removal of internal elements.
2.3 User characteristics In order to better develop the product, the user’s characteristics should be analyzed, the intended user of the distributed router would be four groups of people: Network Administrator, network designer, software designer, and researchers. The characteristics of each group of people are shown in table 1.
7 January 2008
Product Requirements Document
7
Table 1: User characteristics of the intended user of the distributed router
Name of the group
Roles and Characteristics
Network administrator
Responsible for operating large scale networks.
Network designer
Responsible for planning large scale and core networks.
Software designer
Responsible for implementing the router's software.
Researcher
Interested on several research areas, such as router architectures and technologies.
2.4 General constraints Constraints in the development of the distributed router include: •
Network protocols are based only on Internet Protocol version 4 (IPv4), the current development is mainly focusing on IPv4, only when it is proofed to be stable, and we can proceed to develop the product to support Internet Protocol version 6 (IPv6).
•
In the modularized BGP: o
Failure handling is supported in Service Process but not in Session Manager
o
The support for multiple Service Processes is limited to a maximum number of 14.
•
Programming in C language is required due to the manipulation of the Linux kernel
2.5 Assumptions and dependencies The development of the product has the following assumptions and dependencies which form the basis for the decision makings in the development of this product:
Table 2: Assumptions and Dependencies for the Distributed Router
Assumptions: Internal network
•
development
The internal network link layer will be based on Gigabit Ethernet Standard for the Data network.
•
The internal network link layer will be based on Fast Ethernet Standard for the Control network.
•
The internal network topology will be based on a switched network solution.
7 January 2008
Product Requirements Document
8
Platform for the software
For both the control and forwarding element, Fedora 7 Linux
development
operating system will be used.
Routing software
Since this product should be an open source product which
development
enables the network administrator to plug and play the network component, all the software for the development of distributed router should be open sourced. These softwares should support the required routing protocols such as BGP and OSPF. Currently an Internal communication network will be based only on Internet Protocol version 4 (IPv4).
Network monitoring
The open source software for network monitoring for the
development
components of the distributed router might be net-snmp, which is mostly used network management and monitoring.
Internal configuration
The internal configuration of the distributed router will have a
development
user interface, which helps the network administer to plug forwarding elements dynamically. When a forwarding element is plugged in, it should get the configuration automatically and be able to function.
Dependencies Hardware dependency
The overall performance of the distributed router is depended on the specification of the hardware. The limitation of the network traffic speed is depended on the supported speed of the network card.
Operating system
The software for functionalities of the distributed router will be depended on the Linux kernel and distribution. There is a possibility that we have to choose different software because the Fedora 7 Linux does not support the first one.
The Forz protocol
The integration of the distributed router depends on the performance of the Forz protocol. Therefore good knowledge of this protocol and the corresponding implementation is essential.
Open source routing
The supported routing protocol of the distributed router is fully
software
depended on the features of the selected open source routing software.
7 January 2008
Product Requirements Document
9
3. Functional requirements 3.1 Distributed router in general 3.1.1 Operating Environment The product shall be designed to operate in the following environment: •
PC-based Linux platforms.
•
Physically separated data and control networks, for the internal network
3.1.1 Usability Attributes The extended prototype of the distributed router should make it possible the use of several open source routing software, available in Unix-like Operating Systems, in order to provide the user with: •
An already known Command Line Interface environment.
•
Access to freely available documentation and wide community based support.
The product should provide an interface to existing network management applications, enabling the user to: •
View and manage the distributed router as a single device.
Set, modify and display the configurations of each of the separate components.
3.2 Interfaces 3.2.1 User interface requirements A management interface should be integrated with the extended prototype in order to provide the necessary means for the interaction between the user and the distributed router. This interface should provide support for: •
Integration with existing network management applications (NMAs).
•
Necessary abstraction to hide the internal structure of the distributed router.
•
Performance of management tasks via Command Line Interface (CLI) based configuration via local and remote access (e.g. telnet, SSH).
•
Performance of management tasks via Web-based graphical user interface configuration and monitoring
7 January 2008
Product Requirements Document
10
3.2.2 Hardware interface requirements The minimum requirements for the PCs operating as CEs [8] are following: •
CPU 400 Mhz.
•
RAM 256 MB.
•
1 Gigabit Ethernet interface card.
•
1 Fast Ethernet interface card.
3.3.3 Software interface requirements The distributed router components should be enabled to support the following: •
Simple Network Management Protocol (SNMP), version 2c – SNMPv2C.
•
Management Information Base- MIB – II (RFC 1213).
•
Netlink protocol [9].
The integration of the distributed router software with the network management application should be achieved by means of an interface designed to: •
Read the configuration parameters supplied by the management application.
•
Parse and produce the configuration files according to the format used in the different elements.
•
Communicate the messages to the elements.
3.3.4 Communication interface requirements The following communication protocols support must be the provided by product: •
Forz protocol for communication between the CEs and the FEs.
•
SNMPv2C for remote monitoring.
•
TELNET/SSH for remote access.
•
HTTPS for configuration management.
7 January 2008
Product Requirements Document
11
3.3 Protocol support requirements The following tables describe the protocol related requirements for the distributed router.
3.3.1 BGPv4
Architecture and Technical Attributes Requirement
Auditor Instructions (What to look for)
Basic requirement of BGPv4
.Refer to RFC 4271.
Interaction with OSPF
Ability to export OSPF routes into BGP by redistributing the routes learnt via BGP protocol into OSPF route database. Ability to import BGP routes into OSPF by rredistributing the routes learnt via OSPF protocol to BGP routing table, and announce it to the eBGP peer. Refer to RFC 1403 [10].
Support for BGP
A community is a group of destinations which share some
Communities Attribute
common properties. Each autonomous system administrator may define which communities a destination belongs to. The Community Attribute aids in policy administration and reduces the management complexity of maintaining the Internet. Refer to RFC 1997 [11].
Support for Capability
The Capability is a new Optional Parameter for BGP. It can
Advertisement
facilitate the BGP by providing capability advertisements without the BGP peering being terminated. Refer to RFC 3392 [12].
Support for BGP Route
Route Reflection is an alternative in alleviating the need for a
Reflection
“full mesh” which requires many IBGP sessions. This approach allows a BGP speaker (known as "Route Reflector") to advertise IBGP learned routes. Refer to RFC 2796 [13].
Support for Autonomous
Autonomous System Confederation is an extension to BGP in
System Confederations
alleviating the need for a “full mesh” which requires many IBGP sessions. Refer to RFC 3065 [14].
Support for Route Flap 7 January 2008
Route Flap Damping is designed aiming to reduce the Product Requirements Document
12
Damping
excessive routing traffic passed between the routing peers. By the mean time it does not affect route convergence time for relatively stable routes. Refer to RFC 2439 [15].
3.3.2 OSPFv2
Architecture and Technical Attributes Requirement
Auditor Instructions (What to look for)
Basic requirement of OSPF
Refer to RFC 2328 [2].
3.3.3 IS-IS
Architecture and Technical Attributes Requirement
Auditor Instructions (What to look for)
Basic requirement of IS-IS
Refer to RFC 1195 [22], RFC 1142[23]
3.3.4 VRRP
Architecture and Technical Attributes Requirement
Auditor Instructions (What to look for)
Redundancy for the first hop
The Virtual Router Redundancy Protocol (VRRP) has an
access
election protocol that dynamically assigns a virtual router to be the default gateway on a LAN. A Master is a VRRP router which controls the IP addresses associated with virtual routers and answers ARP requests for these IP addresses. When the Master becomes unavailable, any of the virtual router’s IP address on the LAN can be used as the default first hop router. These virtual routers take over when Master fails are called Backup virtual routers.
VRRP provides high availability default path without requiring each end-host to configure dynamic routing such as RIB, OSPFv2 or router discovery protocols. Refer to RFC 3768.
7 January 2008
Product Requirements Document
13
3.3.5 Remote Monitoring
Architecture and Technical Attributes Requirement Monitor resource
the usages
Auditor Instructions (What to look for) hardware The Simple Network Management Protocol (SNMP) is used to of
the communicate management information between the network
distributed router elements. (The
required
management stations and the agents in the network elements.
hardware It uses a design where the available information is defined by
resource usages here are Management Information Base (MIB). The Object Identifier CPU usage, memory usage,
(OID) in the MIB identifies which information that can be
system load, network traffic read or set via SNMP. The MIB here should have the variables on each network interface)
that represent the CPU usage, memory usage, system load, and network traffic on each network interface. Refer to RFC 1157 [16], RFC 1156 [17], and RFC 1158 [18].
Support further extensions
The SNMP daemon should be able to import new MIB trees
for monitoring of distributed from a third party, and advertise the new variables via SNMP. router elements.
3.3.6 SNMPv2
Network Requirements SNMP is using the UDP port 161 for the agent and 162 for the manager. In order to send and receive management information, the network should allow packets with this destination port to be traversed.
Architecture and Technical Attributes Requirement
Auditor Instructions (What to look for)
Support community based The purpose of an administrative framework is to define an Administrative Framework
infrastructure through which effective management can be realized in a variety of environment and configurations. This framework associates each SNMP message with a "community", which increases the security level. Refer to RFC 1901 – RFC 1907 and RFC 1157.
Support SMI information The SNMPv2 Structure of Management Information (SMI) modules
specifies information modules, which specify a group of related definitions. There are three types of SMI information
7 January 2008
Product Requirements Document
14
modules: MIB modules, compliance statements, and capability statements. Refer to RFC 1155 [19], RFC 1212 [20], and RFC1157.
7 January 2008
Product Requirements Document
15
/4. Non-functional requirements 4.1 Security requirement For a secure operation of the product, the following features are recommended: •
Authentication between CEs and FEs.
•
Login-based access for local and remote configuration.
•
SNMPv3 [21] support
4.2 Performance requirement In order to obtain an acceptable performance of the product, it is recommended the use of the distributed router components with the following characteristics:
For Linux PC-Based Control Elements (CEs): •
Intel Pentium 4 processor 2GHZ.
•
2 GB RAM
•
Gigabit Ethernet network adapter.
For Linux PC-Based Forwarding Elements (FEs): •
Intel Pentium 4 Processor 2Ghz
•
1 GB RAM
•
Gigabit Ethernet network adapter.
7 January 2008
Product Requirements Document
16
5. Product roadmap The vision of this product is establishment of the framework which will enable the development of routers in a modular fashion, being components supplied by several players in the market. In order to accomplish this, the future lease of this product should support for the following: •
Modularized BGPv4, OSPFv2, and IS-IS [22, 23]
•
Compatibility with ForCES [24] protocol
•
IPv6
•
Portability of distributed router
Modularized BGPv4, OSPFv2, and IS-IS: At the current state of implementation of distributed router, the load of a single routing protocol can not be shared among multiple CEs. The routing application has to be modularized to support the load sharing. This extension for modularization is needed for BGPv4, OSPFv2, and IS-IS.
Compatibility with ForCES protocol: Compatibility with ForCES protocol: Since ForCES has been approaching the way to be the standard protocol for the communication among separated forwarding elements and control elements, the product should preferably comply with ForCES, which produced by an International standardization body.
IPv6: IPv6 is set to be the next generation internet protocol; therefore IPv6 support will be required in order to make the product ready to support the operation of the future Internet.
Portability of distributed router: The current implementation is Linux specific, thus the prototype can not be ported to any other platforms. It is desirable make the distributed router to be portable to other platforms, so that the needs of the different types of users can be addressed.
7 January 2008
Product Requirements Document
17
6. References [1] Y. Rekhter, T. Li, and S. Hares. "A Border Gateway Protocol 4 (BGP-4)", Request for Comments (RFC 4271), January 2006, available at: http://www.ietf.org/rfc/rfc4271.txt, last visited Jan 5th, 2008. [2] J. Moy. "OSPF Version 2", Request for Comments (RFC 2328), April 1998, available at: http://www.ietf.org/rfc/rfc2328.txt, last visited Jan 5th, 2008. [3] R. Hinden. "Virtual Router Redundancy Protocol (VRRP)", Request for Comments (RFC 3768), April 2004, available at: http://www.ietf.org/rfc/rfc3768.txt, last visited Jan 5th, 2008. [4] C. Hopps. "Analysis of an Equal-Cost Multi-Path Algorithm", Request for Comments (RFC 2992), November 2000, available at: http://www.ietf.org/rfc/rfc2992.txt, last visited Jan 5th, 2008. [5] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. "Introduction to Community-based SNMPv2", Request for Comments (RFC 1901), January 1996, available at: http://www.ietf.org/rfc/rfc1901.txt, last visited Jan 5th, 2008. [6] K. McCloghrie and M. Rose. "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", Request for Comments (RFC 1213), March 1991, available at: http://www.ietf.org/rfc/rfc1213.txt, last visited Jan 5th, 2008. [7] Net-SNMP, available at: http://net-snmp.sourceforge.net, last visited Jan 5th, 2008 [8] O. Hagsand, M. Hidell, and P. Sjodin. "Design and implementation of a distributed router", Signal Processing and Information Technology, Proceedings of the Fifth IEEE International Symposium, Dec. 2005 [9] J. Salim, H. Khosravi, A. Kleen, and A. Kuznetsov. "Linux Netlink as an IP Services Protocol", Request for Comments (RFC 3549), July 2003, available at: http://www.ietf.org/rfc/rfc3549.txt, last visited Jan 5th, 2008. [10] K. Varadhan. "BGP OSPF Interaction", Request for Comments (RFC 1403), January 1993, available at: http://www.ietf.org/rfc/rfc1403.txt, last visited Jan 5th, 2008. [11] R. Chandra, P. Traina, and T. Li. "BGP Communities Attribute", Request for Comments (RFC 1997), August 1996, available at: http://www.ietf.org/rfc/rfc1997.txt, last visited Jan 5th, 2008. [12] R. Chandra and J. Scudder. "Capabilities Advertisement with BGP-4", Request for Comments (RFC 3392), November 2002, available at: http://www.ietf.org/rfc/rfc3392.txt, last visited Jan 5th, 2008.
7 January 2008
Product Requirements Document
18
[13] T. Bates, R. Chandra, and E. Chen. “BGP Route Reflection -An Alternative to Full Mesh IBGP”, Request for Comments (RFC 2796), April 2000, available at: http://www.ietf.org/rfc/rfc2796.txt, last visited Jan 5th, 2008. [14] P. Traina, D. McPherson, and J. Scudder. “Autonomous System Confederations for BGP”, Request for Comments (RFC 3065), February 2001, available at: http://www.ietf.org/rfc/rfc3065.txt, last visited Jan 5th, 2008. [15] C. Villamizar, R. Chandra, and R. Govindan. “BGP Route Flap Damping”, Request for Comments (RFC 2439), November 1998, available at: http://www.ietf.org/rfc/rfc2439.txt, last visited Jan 5th, 2008. [16] J. Case, M. Fedor, M. Schoffstall, and J. Davin. "A Simple Network Management Protocol (SNMP)", Request for Comments (RFC 1157), May 1990, available at: http://www.ietf.org/rfc/rfc1157.txt, last visited Jan 5th, 2008. [17] K. McCloghrie and M. Rose. "Management Information Base for Network Management of TCP/IP-based internets", Request for Comments (RFC 1156), May 1990, available at: http://www.ietf.org/rfc/rfc1156.txt, last visited Jan 5th, 2008. [18] M. Rose. "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", Request for Comments (RFC 1158), May 1990, available at: http://www.ietf.org/rfc/rfc1158.txt, last visited Jan 5th, 2008. [19] M. Rose and K. McCloghrie. "Structure and Identification of Management Information for TCP/IP-based Internets", Request for Comments (RFC 1155), May 1990, available at: http://www.ietf.org/rfc/rfc1155.txt, last visited Jan 5th, 2008. [20] M. Rose and K. McCloghrie. "Concise MIB Definitions", Request for Comments (RFC 1212), March 1991, available at: http://www.ietf.org/rfc/rfc1212.txt, last visited Jan 5th, 2008. [21] D. Harrington, R. Presuhn, and B. Wijnen. "An Architecture for Describing SNMP Management Frameworks", Request for Comments (RFC 2571), April 1999, available at: http://www.ietf.org/rfc/rfc2571.txt, last visited Jan 5th, 2008. [22] R. Callon. "Use of OSI IS-IS for routing in TCP/IP and dual environments", Request for Comments (RFC 1195), December 1990, available at: http://www.ietf.org/rfc/rfc1195.txt, last visited Jan 5th, 2008. [23] D. Oran. "OSI IS-IS Intra-domain Routing Protocol", Request for Comments (RFC 1142), February 1990, available at: http://www.ietf.org/rfc/rfc1142.txt, last visited Jan 5th, 2008.
7 January 2008
Product Requirements Document
19
[24] L. Yang, R. Dantu, T. Anderson, and R. Gopal. "Forwarding and Control Element Separation (ForCES) Framework", Request for Comments (RFC 3746), April 2004, available at: http://www.ietf.org/rfc/rfc3746.txt, last visited Jan 5th, 2008.
7 January 2008
Product Requirements Document
20
