Implementing Restoration Routing in a LINUX

ginglyformweekNetworking and Communications

Oct 29, 2013 (3 years and 9 months ago)

70 views






Implementing Restoration Routing in a LINUX Router



i




Implementing Restoration Routing in a LINUX
Router





Fahad Rafique Dogar (2005
-
02
-
0293)


Lahore University of Management Sciences

May 12, 2005
GRO
UP
0510: Implementing Restoration Routing in a LINUX Router





Implementing Restoration Routing in a LINUX Router


ii

Statement Of Submission


I am submitting

this final r
eport for the project titled “
Implementing Restoratio
n Routing in a
LINUX Router” as fulfillment of my

Senior Project at LUMS for the academic year 2004
-
2005.




Implementing Restoration Routing in a LINUX Router


iii

Acknowledgements


I

would fi
rst of all like to acknowledge my

faculty advisors

for their extensive help, support,
and suggestions.
Also, I would

like

to thank the entire faculty of LUMS for providing a rich
set of courses whose content proved to be most usefu
l and relevant to this project. I would
also like to thank my

friends and families for being extremely supportive and und
erstanding
for all the ni
ghts I

had to spend in the
Networks
Labs.

Finally,
I would
like t
o thank God for
giving me

the strength to make
this project

a reality.




Implementing Restoration Routing in a LINUX Router


iv

Abstract



In this project, a traffic engineering test
-
bed has been established which can be used to test
various resto
ration routing schemes. To this end, various components of MPLS
-
TE were
either indigenously developed or existing open source implementations were used. Currently
the additional information required for traffic engineering is being propagated as per the
re
quirements specified in RFC 3630: Traffic Engineering (TE) Extensions to OSPF [3]. This
information is retrieved and processed by a constraint based routing application. This
application uses this additional information to calculate constraint based routes

which are
then signaled through RSVP
-
TE. The RSVP
-
TE module has been developed by IBCN [4]
and it can be integrated with OSPF
-
TE module and the constraint based routing application.





Implementing Restoration Routing in a LINUX Router


v

List of Figures


Figure 1
:
Design of OSPF API





Implementing Restoration Routing in a LINUX Router


vi

INDEX


1.

Introduction:

................................
................................
................................
...............

1

2.

Design Overview:

................................
................................
................................
.........

2

3.

OSPF
-
TE:

................................
................................
................................
....................

2

LSA Header:

................................
................................
................................
.........................

3

Propagation of LSAs:
................................
................................
................................
............

3

4.

Constraint Based Routing Application:

................................
................................
.......

4

5.

RSVP
-
TE:
................................
................................
................................
....................

4

6.

Implementation Details:
................................
................................
...............................

5

7.

Conclusions and Future Enha
ncements:

................................
................................
......

7





Implementing Restoration Routing in a LINUX Router


1

1.

Introduction:


The destination based forwarding paradigm employed in plain IP routing does not support
routing along explicit routes determined throu
gh constraint based routing
. The emergence of
Multi
-
Protocol
-
Label
-
Switching

(MPLS) has overcome this limitation of traditional shortest
path routing, by presenting the ability to establish a virtual connection between two points on
an IP network, maintaining the flexibility and simplicity of an IP network while exp
loiting the
ATM
-
like advantage of a connectio
n
-
oriented network [1
]
. Ingress routers of an MPLS
network classify packets into forwarding equivalence classes and encapsulate them with labels
before subsequently forwarding th
em along pre
-
computed paths
. The
path a packet takes as a
result of a series of label switch operations in an MPLS network is called a
label switched path

(LSP).
LSPs may be routed through constraint based routing that adapts to current network
state information (e.g. link utilization) an
d selects explicit routes that satisfy a set of
constraints. The ability to explicitly route network traffic using
traffic engineering capability
of MPLS

enables service providers to provision quality of service for network traffic and also
leads to ef
fici
ent network utilization.



An important application of constrained based routing is the provisioning of bandwid
th
guaranteed LSPs
. Furthermore, failure of network nodes and links lead to service disruption
which is undesirable especially in most real
-
time
applications such as voice over IP (VoIP)
and videoconferencing. Restoration mechanisms employed at the IP layer may take several
seconds and are inappropriate

for real
-
time applications [2
]
. Therefore, proposals have been
made to incorporate restorat
ion r
outing in MPLS
. This involves maintaining backup paths
with reserved bandwidth and redirecting traffic onto these pre
-
computed backup paths in case
of a failure.


In this project
,

a traffic engineering test
-
bed has been established which can be used to tes
t
various restoration routing schemes. To this end,
various components of MPLS
-
TE were
either indigenously developed or existing open source implementations were used. Currently
the additional information required for traffic engineering is being propagate
d as per the
requirements specified in RFC 3630: Traffic Engineerin
g (TE) Extensions t
o OSPF [3
]. This
information is retrieved and processed by a constraint based routing application. This
application uses this additional information to calculate constrai
nt based routes which are
then signaled through RSVP
-
TE. The RSVP
-
TE module has been developed by IBCN

[4]

and it
can be integrated

with OSPF
-
TE module and the constraint based routing application.





The rest of the report is organized
as follows: Deta
ils of
the
overall design of the traffic
engineering modu
le are presented in Section II.
Details

of

OSPF
-
TE are discussed in Section
III.
Constraint based routing application and the subsequent signaling of paths through
RSVP
-
TE is discussed in Sections IV

and V respectively.

The implementation details are
discussed in Section VI.

Finally, conclusions and future enhancements are presented in
Section V
II
.






Implementing Restoration Routing in a LINUX Router


2

2.

Design Overview:


As mentioned earlier, implementation of any restoration routing scheme requires a w
orking
traffic engineering module having constraint based routing capability. The design of a traffic
engineering module

involves various distinct components

that work together to provide
constraint base
d routing facility. Additional l
ink information such
as the residual bandwidth
or the bandwidth reserved for backup paths must be propagated through OSPF
-
TE. Once this
information is propagated, it must be retrieved and subsequently used by a constraint based
routing application. This application must make u
se of this additional information to
calculate shortest paths that also satisfy the given constraint. Once such a route is calculated,
it must be signaled so that the required resources can be reserved. This signaling of the path
for resource reservation i
s done through RSVP
-
TE. Finally, the constraint based routing
application at all the nodes should ensure that update
d

link state information is again

propagated
through OSPF
-
TE. Thus, the constraint based routing application acts as an
interface between OS
PF
-
TE and RSVP
-
TE, in addition to calculating constraint based
shortest paths.


3.

OSPF
-
TE:


Traditional OSPF routing only allows calculation of IGP shortest paths. With Traffic
Engineering, there is a need for the computation of paths other than the IGP sho
rtest paths.
This is required so as to avoid congested routers and improve network utilization. Therefore
constraint based routing is needed in order to facilitate traffic engineering. The calculation of
paths
-

keeping in view their required constraints
-

needs additional information to be
propagated through OSPF. The requirement of additional information is provided in RFC
3630: Traffic Engine
ering (TE) Extensions to OSPF [3
].
The extensions specified in this
document capture the reservation
state of poi
nt
-
to
-
point links.

The additional information is propagated in the form of link state advertisements (LSA). To
this end, a new LSA


Traffic Engineering LSA


is proposed. These LSAs are identified
through their unique LSA id. The details of TE LSA are as
follows:




Implementing Restoration Routing in a LINUX Router


3


LSA Header:


The Traffic Engineering LSA starts with the standard LSA header:




0 1 2 3


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


| LS age | Options | 10 |


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


| 1 | Instance

|


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


| Advertising Router |


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


|

LS sequence number |


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


| LS checksum | Length |


+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+

Payload:


The LSA payload consists of one
or more nested Type/Length/Value
(TLV) triplets for
extensibility. The Link TLV describes a single link. It is constructed of a set of

s
ub
-
TLVs.
There are no ordering requirements for the sub
-
TLVs.

It is im
portant that o
nly one Link TLV
shall be carried in each LSA, allowing for fine

granularity changes in topology.


The following sub
-
TLVs of the Link TLV are defined:



1
-

Link type


2
-

Link ID


3
-

Local interface IP address


4
-

Re
mote interface IP address


5
-

Traffic engineering metric


6
-

Maximum bandwidth


7
-

Maximum reservable bandwidth


8
-

Unreserved bandwidth


9
-

Administrative group


Propagation of LSAs:


Routers shall originate Traffic Eng
ineering LSAs whenever the LSA

contents change, and
whenever otherwise required by OSPF (an LSA

refresh, for example). Note that this does
not mean that every

change must be flooded immediately; an implementation
may

set

thresholds (for example, a bandwid
th change threshold) that trigger

immediate flooding, and
initiate flooding of other changes after a

short time interval. Upon receipt of a changed



Implementing Restoration Routing in a LINUX Router


4

Traffic Engineering LSA (since these are used in traffic engineering calculations), the

router
should

update

its traffic engineering database.



4.

Constraint Based Routing

Application
:


The above extensions to OSPF only specify the additional information that needs to be
propagated and a mechanism for the proper dissemination of this information. It does not,
how
ever, specify the calculation of routes based on the additional information. Such
calculation depends on the requirements of the Network Administrator and the applicable
constraints. In the context of restoration routing, the applicable constraint is the a
vailability
of bandwidth. Therefore, the chosen route should be the shortest path that satisfies a
bandwidth constraint. The procedure for the constraint based route calculation can be
summarized in the following steps:


1)

Prune all links where Unreserved ba
ndwidth < bandwidth demand

2)

Compute shortest path using Dijkstra on the remaining topology


It is also important to consider that the application after calculating a constraint based route
must also be capable of establishing a path based on the earlier ro
ute calculation. It should
also be able to reserve bandwidth along those paths and then notify OSPF
-
TE to propagate
the updated link state information. Therefore, this application has to be aware of the critical
link state information and should be able to

make changes in it. The
subsequent
resource
reservation is done through RSVP
-
TE but is initiated by this application.


5.

RSVP
-
TE:


Resource Reservation Protocol (RSVP) was designed to provide resource guarantees which
can be adopted under different archite
ctures. It is a soft
-
state protocol having two basic types
of messages: the PATH message which contains details of the requested resources and each
node along the path forwards this message to the next hop if it has the required resources. If
all the nodes

have the required resources, the destination node returns a RESV message
which traverses all the way back to the source and ensures that each node along the path
actually reserves the required resources. With the arrival of MPLS, it was observed that
RSVP

could be extended into a label distribution protocol. Moreover, support could be
provided into RSVP for traffic engineering and constraint based routing. Therefore, RSVP
-
TE

[5]

was proposed which enhances RSVP by allowing label distribution and setting up

of
bandwidth guaranteed LSPs. Moreover, support for restoration routing, loop detection and
failure detection was also incorporated in this protocol.


The critical feature of RSVP
-
TE which is used by the constraint based routing application is
the suppor
t for explicit routing.
This feature allows
any arbitrary path to be signaled through



Implementing Restoration Routing in a LINUX Router


5

RSVP
-
TE. Therefore
,

rather than following the IGP shortest path, we can specify any valid
path, which in our case would be calculated on the basis of bandwidth availabili
ty, and then
signal it through RSVP
-
TE.


6.

Implementation Details
:


Extending OSPF to cater for traffic engineering extensions can be done in two ways: 1) to
change the original code base of OSPF so that traffic engineering extensions which are
propagated t
hrough OPAQUE LSAs are implemented. and 2) Use OSPF API to send
additional information that are required for traffic engineering. The second option entails
separation of d
evelopment of OSPF and OSPF
-
TE,
thus
keeping the original code preserved.
Also
,

it gi
ves the flexibility of easily adding other information to the existing traffic
engineering extensions.


The OSPF API

[6]

provides r
etrieval of the full or partial link
-
state database

(LSDB)

of the
OSPF daemon. This allows applications to obtain an exact c
opy of the LSDB including
router LSAs, network LSAs and so on. Whenever a new LSA arrives at the OSPF daemon,
the API module immediately informs the ap
plication by sending a message. Using this API
,

additional link state information required for TE
is

prop
agated. Each node
has

an application
running as a daemon which
does

the work of sending this additional information through the
API. In addition
,

this application since it has complete link state information
,

also act
s

as the
interface between RSVP
-
TE and
OSPF
-
TE. On receiving a request, it
is

able to calculate the
Constraint Based Route and signal
s

it through the Explicit Routing capability of RSVP
-
TE.
The updated network state information
is

again propagated through the OSPF API.


The implementation of O
SPF
-
TE required following all the requirements given in RFC 3630:
Traffic Engineering (TE)

Extensions to OSPF Version 2 [3
]. OS
PF
-
TE makes use of Opaque
LSA [7
] which has been proposed keeping in view the varying requirements of different
applications. The
se LSAs provide a common mechanism for applications to disseminate their
customized information. Currently various types of Opaque LSAs have been proposed
including TE Opaque LSAs.


The implementation broadly entailed the following steps:


1)

Registering a n
ew LSA

2)

Preparing a new TE LSA (as per requirements of RFC 3630)

3)

Propagating TE LSAs

4)

Receiving TE LSAs






Implementing Restoration Routing in a LINUX Router


6



Fig 1: Design of OSPF API


Once we have a constra
int based routing application
,

which not only
initiates

OSPF
-
TE
information but also retrieves it
,

then we can use this information to compute constraint
based routes. These routes are then signaled through RSVP
-
TE. Recall that RSVP
-
TE
supports two type
s

o
f path establishment mechanisms: one in which shortest path is followed
and the second one which is called the Explicit Route support
that

establishes any arbitrary
given
path between two nodes. Since the application is able to calculate the desired route
,

it
can use the explicit route support of RSVP
-
TE to establish this path.


The RSVP
-
TE implementation
is offered by IBCN under the title “RSVP
-
TE for DiffServ
over MPLS”

[
4
]
.

This implementation can be integrated with existing OSPF
-
TE and
constraint based

routing application to offer a complete traffic engineering module.
The
important details of
RSVP
-
TE
implementation are
as
follows:


The overall architecture consists of a number of components both in kernel space and user
space. These components have bee
n prepared under different projects and have been
integrated together to form one coherent implementation of MPLS with RSVP support. The
primary user space component is the RSVP daemon that is responsible for the RSVP
signaling and the maintenance of the M
PLS state. This daemon allocates and installs LSP
labels during LSP set up and freeing and removing labels on LSP tear down.


The RSVP daemon is accessed in the user space through an API


RAPI
-

which is
specifically designed for interaction with RSVP.
Using this API, the developers have
designed two applications: a client and a server which corresponds to an LSP ingress and
egress respectively. ‘rtest’ is the client application which corresponds to an LSP ingress; it
takes LSP requests and subsequently
passes it to the RSVP daemon. Therefore, Label
Request Objects are piggy backed on RSVP’s PATH messages. The RSVP daemon which is
running on subsequent hops forwards it to the next hop. Note that the path selection can be
based on IGP shortest path or the
path could be explicitly specified. On receiving the PATH
request, the egress on which ‘rapirecv’


the server application
-

is running would respond by



Implementing Restoration Routing in a LINUX Router


7

piggy backing the Label Object on the RESV messages which is sent back to the ingress via
the chosen ro
ute.


The important parts of the kernel that are used are netfilter to classify packets, QoS and fair
queuing to support differentiation between flows and the MPLS support in the form of a
kernel patch. Therefore, while the RSVP daemon takes care of LSP s
et up and LSP tear
down, the marking of packets and the routing of packets takes place within the kernel,
through the above mentioned modules.



7.

Conclusions and Future Enhancements:


In this project, implementation of OSPF
-
TE along with an application leve
l interface for
constraint based routing was done.
OSPF
-
TE was implemented using the proposed OSPF
API
,

thus providing a user friendly and robust mechanism for maki
ng changes to existing
protocol specifications
.

Further enhancements to OSPF
-
TE can be easil
y incorporated
through an application level interface.
This interface also provides the capability of retrieving
TE information and using this information to compute constraint based routes.

These
modules can be integrated with existing RSVP
-
TE implementa
tions to offer a complete
traffic engineering
solution
. The traffic engineering module can be used for a variety of
purposes including performance results for QoS analysis, implementation of various resource
al
location and scheduling schemes,
and most impo
rtantly
to implement
schemes that have
been proposed for restoration routing.





Implementing Restoration Routing in a LINUX Router


8

REFERENCES


[1
]


B.Davie and Y.Rekhter,
MPLS Technology and Applications
, Morgan Kaufmann, San
Francisco, CA, 2000.


[2
]

Jean Philippe Vasseur, Mario Pickavet and Piet Demeest
er,
Network Recovery:
Restoration and Protection of Optical, SONET
-
SDH, IP and MPLS
, Morgan Kaufmann,
Elsevier, 2004.


[3]
Dave Katz, Derek M. Yeung, and Kireeti Kompella.
Traffic engineering
extensions
to
OSPF
. RFC 3630, Internet Engineering Task Force, S
eptember 2003
.


[4]
“RSVP
-
TE for DiffServ over MPLS”
, IBCN,
http://dsmpls.atlantis.ugent.be/


[5]
Awduche D.O., Berger L., Gan D.
-
H., Li T., Srinivasan V., Swallow G. "RSVP
-
TE:
extensions to RSVP for LSP tu
nnels", RFC 3209, December 2001


[6]
An ext
ended Quagga/Zebra OSPF daemon supporting an API for external

applications
,
http://www.tik.ee.ethz.ch/~keller/ospfapi/


[7] R.Coultun
.
The OSPF Opaque
LSA Option
. RFC 2370, Internet Engineering Task
Force,
July 1998.