Distributed Router Field Trial

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)

7 January 2008 Product Requirements Document 1

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


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


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.


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.


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.


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.


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.


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.


Platform for the software

development

For both the control and forwarding element, Fedora 7 Linux

operating system will be used.

Routing software

development

Since this product should be an open source product which

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

development

The open source software for network monitoring for the

components of the distributed router might be net-snmp, which

is mostly used network management and monitoring.

Internal configuration

development

The internal configuration of the distributed router will have a

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

software

The supported routing protocol of the distributed router is fully

depended on the features of the selected open source routing

software.


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


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.

https://www.researchgate.net/publication/4215157_Design_and_implementation_of_a_distributed_router?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==


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

Communities Attribute

A community is a group of destinations which share some

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.


Support for Capability

Advertisement

The Capability is a new Optional Parameter for BGP. It can

facilitate the BGP by providing capability advertisements

without the BGP peering being terminated.


Support for BGP Route

Reflection

Route Reflection is an alternative in alleviating the need for a

“full mesh” which requires many IBGP sessions. This

approach allows a BGP speaker (known as "Route Reflector")

to advertise IBGP learned routes.


Support for Autonomous

System Confederations

Autonomous System Confederation is an extension to BGP in

alleviating the need for a “full mesh” which requires many

IBGP sessions.


Support for Route Flap Route Flap Damping is designed aiming to reduce the


Damping excessive routing traffic passed between the routing peers. By

the mean time it does not affect route convergence time for

relatively stable routes.


3.3.2 OSPFv2



Basic requirement of OSPF Refer to RFC 2328 [2].

3.3.3 IS-IS



Basic requirement of IS-IS Refer to RFC 1195 [22], RFC 1142[23]

3.3.4 VRRP



Redundancy for the first hop

access

The Virtual Router Redundancy Protocol (VRRP) has an

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.


3.3.5 Remote Monitoring



Monitor the hardware

resource usages of the

distributed router elements.

(The required hardware

resource usages here are

CPU usage, memory usage,

system load, network traffic

on each network interface)

The Simple Network Management Protocol (SNMP) is used to

communicate management information between the network

management stations and the agents in the network elements.

It uses a design where the available information is defined by

Management Information Base (MIB). The Object Identifier

(OID) in the MIB identifies which information that can be

read or set via SNMP. The MIB here should have the variables

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

for monitoring of distributed

router elements.

The SNMP daemon should be able to import new MIB trees

from a third party, and advertise the new variables via SNMP.

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.



Support community based

Administrative Framework

The purpose of an administrative framework is to define an

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

modules

The SNMPv2 Structure of Management Information (SMI)

specifies information modules, which specify a group of

related definitions. There are three types of SMI information


modules: MIB modules, compliance statements, and capability

statements.

Refer to RFC 1155 [19], RFC 1212 [20], and RFC1157.

https://www.researchgate.net/publication/242480522_Structure_and_Identification_of_Management_Information_for_TCPIP-based_Internets?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==


/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.


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.

https://www.researchgate.net/publication/272788552_Forwarding_and_Control_Element_Separation_ForCES_Framework?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==


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.

https://www.researchgate.net/publication/239567102_Management_Information_Base_for_network_management_of_TCPIP-based_internets?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==








https://www.researchgate.net/publication/246702324_Linux_Netlink_as_an_IP_Services_Protocol?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/2881233_RFC_1997_BGP_Communities_Attribute?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/239061841_Analysis_of_an_Equal-Cost_MultiPath_Algorithm?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/234827081_Introduction_to_Community-based_SNMPv2?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==






[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.






https://www.researchgate.net/publication/238702190_Bgp_route_flap_damping?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/246753361_Management_information_base_network_management_of_TCPIP_based_internets_MIB-II?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/234775095_An_Architecture_for_Describing_SNMP_Management_Frameworks?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/234828290_Simple_network_management_protocol_SNMP?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/279503018_Autonomous_System_Confederations_for_BGP?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==





https://www.researchgate.net/publication/238750309_Bgp_route_reflection_an_alternative_to_full_mesh_i-bgp?el=1_x_8&enrichId=rgreq-f05f41e945895c4bcfc357ac9746eb3e-XXX&enrichSource=Y292ZXJQYWdlOzI0MjE4OTgxMztBUzoxNDc3MzgxNjM0MjExODRAMTQxMjIzNDkzMTI4OQ==






[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.






Documents

Distributed Router Field Trial