8/13/2019 Di Serta Tie 2005
1/120
DEVELOPMENT OF MPLS TEST-BED FOR NETWORK TRAFFIC
ENGINEERING
MOHD TAUFIK BIN JUSOH @ TAJUDIN
A thesis submitted in fulfilment of the requirements for the award of the Degree of
Master of Engineering (Electrical-Electronic & Telecommunication)
Faculty of Electrical Engineering
Universiti Teknologi Malaysia
30 NOVEMBER 2005
8/13/2019 Di Serta Tie 2005
2/120
PSZ 19 :16 (Pind. 1/97)
UNIVERSITI TEKNOLOGI MALAYSIA
BORANG PENGESAHAN STATUS TESIS
JUDUL: DEVELOPMENT OF MPLS TEST-BED FOR NETWORK TRAFFICENGINEERING
SESI PENGAJIAN : 2005/2006
Saya MOHD TAUFIK BIN JUSOH @ TAJUDIN__________________( HURUF BESAR )
mengaku membenarkan tesis *( PSM / Sarjana / Doktor Falsafah )* ini disimpan di PerpustakaanUniversiti Teknologi Malaysia dengan syarat-syarat kegunaannya seperti berikut:
1. Tesis adalah hak milik Universiti Teknologi Malaysia.
2. Perpustakaan Universiti Teknologi Malaysia dibenarkan membuat salinan untuk tujuan pengajiansahaja.
3. Perpustakaan dibenarkan membuat salinan tesis ini sebagai bahan pertukaran antara institusipengajian tinggi.
4. * * Sila tandakan ( )
Disahkan oleh
__________________________________ __________________________________
( TANDATANGAN PENULIS ) ( TANDATANGAN PENYELIA)
Alamat Tetap :
LOT 749 LORONG CHEMBONG KECIL SATU, PROF. DR. NORSHEILA BINTI FISAL
KAMPUNG CHEMBONG KECIL, Nama Penyelia
71300 REMBAU, NEGERI SEMBILAN.
Tarikh : 30 NOVEMBER 2005 Tarikh : 30 NOVEMBER 2005
SULIT
TERHAD
TIDAK TERHAD
(Mengandungi maklumat yang berdarjah keselamatanatau kepentingan Malaysia seperti yang termaktub di
dalam AKTA RAHSIA RASMI 1972)
(Mengandungi maklumat terhad yang telah ditentukan
oleh organisasi / badan di mana penyelidikan dijalankan)
CATATAN : * Potong yang tidak berkenaan** Jika tesis ini SULIT atau TERHAD, sila lampirkan surat daripada pihak
berkuasa/organisasi berkenaan dengan menyatakan sekali sebab dan tempohtesis ini perlu dikelaskan sebagai SULIT atau TERHAD.
*** Tesis dimaksudkan sebagai tesis bagi Ijazah Doktor Falsafah dan Sarjana secara
penyelidikan, atau disertai bagi pengajian secara kerja kursus ataupenyelidikan, atau Laporan Projek Sarjana Muda (PSM).
8/13/2019 Di Serta Tie 2005
3/120
I hereby declared that I have read this thesis and in my opinion it is sufficient in
term of scope and quality for the award of the degree of Master of Engineering
(Electrical-Electronic & Telecommunication)
Signature :
Supervisors Name : Prof. Dr. Norsheila binti Fisal
Date : 30 November 2005
8/13/2019 Di Serta Tie 2005
4/120
ii
I declare that this thesis entitled Development of MPLS Test-Bed for Network Traffic
Engineering is the result of my own research except as clearly cited in the references.
The thesis has not been accepted for any degree and is not concurrently submitted in
candidature of any other degree.
Signature : .
Name : Mohd Taufik Bin Jusoh @ Tajudin
Date : 30 November 2005
8/13/2019 Di Serta Tie 2005
5/120
iii
To
My beloved Parents, Sisters and Brothers
for Their
Love, Sacrifices and Best Wished
8/13/2019 Di Serta Tie 2005
6/120
iv
ACKNOWLEDGEMENT
In the name of ALLAH S.W.T, the Most Beneficent and the Merciful,
praise be to ALLAH S.W.T for the incredible gift endowed upon me and for the
health and strength given to me in order to finish the project and to prepare this
thesis.
First of all, I would like to thank my supervisor, Prof. Dr. Norsheila Binti
Fisal for her keen effort, interest, advice, consistent guidance and insightful
comments throughout the period of this study. I also would like to take this opportunityto thank Mr. Adel and all masters student at Telekom Lab, Faculty of Electrical
Engineering and also not to forget a lot of thanks to all technicians at Switching Lab
and Acoustic Lab. Without their helps, this project could not be done.
Special words of gratitude are dedicated to my classmate batch 04/05 especially
to Miss Anis Shahida Niza Binti Mohktar and Mr. Kamaru for their help and advice. A
lot of thank to my best buddy, Mr. Ismail Ibrahim and Mr. Jack for his moral support on
me. To my entire clique, I deeply appreciate all your helps in finishing this project.
Finally, extraordinary thanks and love to my beloved parents, siblings and
relatives for their full support, encouragement and love throughout my studies in UTM.
With them, this life is very meaningful.
8/13/2019 Di Serta Tie 2005
7/120
v
ABSTRACT
Providing Quality of Service (QoS) and Traffic Engineering (TE) capabilities in
the Internet is essential, especially in supporting the requirement of real-time traffic, as
well as mission critical applications. For that reason, the current Internet must be
enhanced with new technology that enables it to offer capabilities for controlling its
behaviour as needed. Multiprotocol Label Switching (MPLS) is an emerging technology
that provides QoS and traffic engineering features in IP network. This study is mainly
concerned on how to develop MPLS test-bed in order to assess MPLS functionalities.
The goal is to develop MPLS test-bed using Linux operating system with kernel version
2.6.5 as the platform. In this work the MPLS test-bed consists of four MPLS routers andtwo host terminals. MPLS software package version 1.946 has been used to build up
routers similar to existing routers in MPLS domain called as Label Switched Router
(LSR). Once the routers are well configured, the connection between two routers is
established to create Label Switched Path (LSP). This LSP connection is also used to
create new LSP from ingress router to egress router. IP packets are sent from ingress
router to host terminals to validate the test-bed. These packets were encapsulated with
MPLS header and they are examined by using tcpdump command in Linux terminal
which shows that the test-bed is successfully developed. In order to enhance test-bed
functionalities, packet generator can be added to the test-bed so that UDP and TCP
throughput measurement can be done. Besides, RSVP and Diffserv can be integrated
into the test-bed for future study.
8/13/2019 Di Serta Tie 2005
8/120
vi
ABSTRAK
Menyediakan keupayaan Kualiti Perkhidmatan (QoS) dan Kejuruteraan Trafik
(TE) dalam Internet amatlah penting, lebih-lebih lagi bagi menyokong keperluan
aplikasi masa nyata seperti aplikasi-aplikasi yang lebih kritikal. Oleh itu, teknologi
Internet masa kini perlulah diperluaskan dengan teknologi terbaru untuk membolehkan
ia menyediakan keupayaan yang diperlukan bagi mengawal tingkahlakunya sendiri
seperti yang diinginkan. Pensuisan Label Pelbagai Protokol (MPLS) adalah satu
teknologi yang sedang berkembang dimana ia menyediakan ciri-ciri QoS dan TE dalam
rangkaian Protokol Internet (IP). Kajian tesis ini tertumpu bagaimana membangunkan
rangkaian-uji MPLS (MPLS test-bed) bagi menilai fungsi-fungsinya. Dengan objektifmembangunkan rangkaian-uji MPLS, sistem operasi Linux dengan kernel versi 2.6.5
diperlukan sebagai asas pembangunan. Dalam kajian ini pakej perisian MPLS versi
1.946 telah digunakan untuk membangunkan routeryang berfungsi sama seperti router
yang terdapat dalam domain MPLS dan ia dipanggil sebagaiRouterPensuisan Label
(LSR). Setelah routersiap dibina, penyambungan antara dua routerdilakukan untuk
menyediakan Laluan Label Tersuis (LSP). Penyambung LSP ini juga turut digunakan
untuk membina satu LSP baru yang menghubungkan ingress router danegress router.
Paket-paket IP dihantar dari ingress router ke terminal hostbagi mengesahkan
rangkaian-uji MPLS. Paket-paket IP yang telah digabungkan dengan kepala MPLS ini
akan diuji menggunakan arahan tcpdump yang terdapat dalam terminal Linux untuk
menunjukkan bahawa rangkaian-uji ini telah siap dibangunkan. Sebagai langkah untuk
memperluaskan fungsi rangkaian-uji ini, penjana paket boleh diganding bersama.
Dengan itu, kualiti penghantaran TCP dan UDP boleh ditentukan. Selain itu, RSVP dan
Diffserv boleh juga digabungkan bersama untuk kajian dimasa akan datang.
8/13/2019 Di Serta Tie 2005
9/120
vii
TABLE OF CONTENTS
CHAPTER TITLE PAGE
TITLE OF PROJECT i
DECLARATION ii
DEDICATION iii
ACKNOWLEDGEMENT iv
ABSTRACT v
ABSTRAK vi
TABLE OF CONTENTS viiLIST OF FIGURES xi
LIST OF ABBREVIATIONS xiv
LIST OF APPENDICES xvi
CHAPTER I INTRODUCTION
1.1 Overview of Internet Challenges 1
1.2 Project Background 3
1.3 Objectives of Research 4
1.4 Research Scopes 4
1.5 Thesis Outline 5
1.6 Project Flow Chart 6
8/13/2019 Di Serta Tie 2005
10/120
viii
CHAPTER II LITERATURE REVIEW
2.1 Introduction 8
2.2 MPLS Basics 9
2.2.1 MPLS Architecture 11
2.3 MPLS Applications 15
2.3.1 Virtual Private Network (VPN) 16
2.3.2 IP and ATM Integration 16
2.4 Traffic Engineering with MPLS 17
2.5 MPLS QoS 202.6 MPLS Future Technology 22
2.7 Linux as the Operating System (OS) 25
2.7.1 Linux Differences 26
2.8 Details of MPLS Forwarding Basics
Implemented in Linux OS 27
2.8.1 MPLS Label 28
2.8.2 MPLS Label Stacking 29
2.8.3 MPLS Data Structures 30
2.8.3.1 Incoming Label Map (ILM) 30
2.8.3.2 The Next Hop Label
Forwarding Entry (NHLFE) 31
2.8.3.3 FEC-to-NHLFE Map (FTN) 31
2.9 MPLS Details 32
2.9.1 MPLS ILM Details 34
2.9.2 MPLS Receive Processing 35
2.9.3 MPLS FTN Details 36
2.9.4 MPLS NHLFE Details 37
2.9.5 MPLS Transmit Processing 37
2.9.10 MPLS Commands in Linux OS 38
8/13/2019 Di Serta Tie 2005
11/120
ix
CHAPTER III DESIGN AND PROCEDURE
3.1 Introduction 40
3.2 Kernel Recompilation 40
3.2.1 Non-RPM System 41
3.2.2 RPM System 47
3.3 Kernel IP Forwarding 48
3.4 Ethernet Card Drivers 49
3.5 Assigning Ethernet Device with IP Address 50
3.5.1 ifconfig 513.5.2 ip route 51
3.5.3 Assigning IP Address in the
Test-bed 52
3.6 Enabling MPLS 54
3.7 Label Switching Path Set Up 55
3.7.1 LSP R-4 to R-1 57
3.7.2 LSP R-1 to R-4 59
3.7.3 LSP R-1 to R-2 60
3.7.4 LSP R-2 to R-1 62
3.7.5 LSP R-1 to R-3 62
3.7.6 LSP R-3 to R-1 64
3.7.7 LSP R-2 to R-3 64
3.7.8 LSP R-3 to R-2 66
3.8 Label Switched Path 1 68
3.9 Label Switched Path 2 69
CHAPTER IV RESULT AND ANALYSIS
4.1 Introduction 71
4.2 Result of LSP Set Up Between Two Routers 71
4.2.1 LSP between R-4 to R-1 73
8/13/2019 Di Serta Tie 2005
12/120
x
4.2.2 LSP between R-1 and R-2 74
4.2.3 LSP between R-1 and R-3 75
4.2.4 LSP between R-2 and R-3 76
4.3 Result of LSP 1 77
4.4 Result of LSP 2 81
4.5 Round Trip Time (RTT) 86
CHAPTER V CONCLUSIONS AND FUTURE WORKS
5.1 Conclusions 895.2 Proposed Future Works 90
REFERENCES 92
APPENDIX A 94
APPENDIX B 96
APPENDIX C 99
APPENDIX D 101
8/13/2019 Di Serta Tie 2005
13/120
xi
LIST OF FIGURES
FIGURE NO TITLE PAGE
2.1 MPLS in OSI Model 12
2.2 MPLS Architecture 13
2.3 The format of LDP messages 14
2.4 Shim Label 14
2.5 MPLS Domain 19
2.6 MPLS main structure 332.7 ILM structure 34
2.8 FTN structure 36
2.9 NHLFE structure 37
2.10 MPLS commands in Linux terminal 39
3.1 Kernel option before compilation; no MPLS option 43
3.2 Kernel option after compilation; MPLS is selected 44
3.3 Kernel options before kernel compilation; no Special
Next Hop option 45
3.4 Kernel option after compilation; Special Next Hop is
selected 46
3.5 Test-bed 52
3.6 The connection between R-4 and R-1 57
3.7 Label 36 is assigned for network 10.0.5.0/24 58
8/13/2019 Di Serta Tie 2005
14/120
xii
3.8 Label 56 is assigned for network 10.0.6.0/24 58
3.9 The connection between R-1 and R-2 61
3.10 The connection between R-1 and R-3 63
3.11 The connection between R-2 and R-3 65
3.12 Label 21 is assigned for network 10.0.1.0/24 67
3.13 Label 27 is assigned for network 10.0.1.0/24 67
3.14 Label Switched Path 1 68
3.15 Label Switched Path 2 69
4.1 LSP between R-4 and R-1 73
4.2 LSP between R-1 and R-2 744.3 LSP between R-1 and R-3 75
4.4 LSP between R-2 and R-3 76
4.5 Pinging 10.0.5.2 (sending IP packets into the MPLS
domain) 77
4.6 Packets addressed to 10.0.5.2 are attached with label
36 at Ingress LSR 78
4.7 Packets labeled with 36 are received by eth0 at R-1 78
4.8 Packets labeled with 36 are swapped with label 26 at
R-1 79
4.9 Packets labeled with 26 are received by eth2 at R-3 79
4.10 Label 26 is removed at R-3, IP packets are
forwarded to destination 80
4.11 IP packets are received at destination without MPLS
header 80
4.12 Pinging 10.0.6.2 (sending IP packets into the MPLS
domain) 81
4.13 Packets addressed to 10.0.6.2 are attached with label
56 at Ingress LSR 82
4.14 Packets with label 56 are received by eth0 at R-1 82
4.15 Label 56 is swapped with label 18 at R-1 83
4.16 Packets with label 18 are received by eth0 at R-2 84
8/13/2019 Di Serta Tie 2005
15/120
xiii
4.17 Packets with label 18 are swapped with label 20 at R-2 84
4.18 Packets labeled with 20 are received by eth0 at R-3 85
4.19 Label 20 is removed at R-3, IP packets are
forwarded to destination 85
4.20 IP packets are received at destination without MPLS
header 86
4.21 RTT for LSP 1 87
4.22 RTT for LSP 2 87
4.23 Comparison of RTT between LSP2 and LSP1 88
8/13/2019 Di Serta Tie 2005
16/120
xiv
LIST OF ABBREVIATIONS
ATM - Asynchronous Transfer Mode
CoS - Class of Service
CR-LDP - Constraint-based Routing Label Distribution
Protocol
DLCI - Data Link Connection Identifier
DWDM - Dense Wavelength Division Multiplexing
FEC - Forwarding Equivalent Class
FSF - Free Software Foundation
GMPLS - Generalized Multiprotocol Label SwitchingGPL - General Public License
IETF - Internet Engineering Task Force
IGP - Interior Gateway Protocol
IntServ - Integrated Services
IP - Internet Protocol
IS-IS - Intermediate System-Intermediate System
LDP - Label Distribution Protocol
LER - Label Edge Router
L-LSP - Label inferred Label Switched Path
LMP - Link Management Protocol
LSR - Label Switching Router
LSP - Label Switched Path
MEM - Micro-Electric Mechanical Systems
8/13/2019 Di Serta Tie 2005
17/120
xv
MPLS - Multiprotocol Label Switching
MPS - Multiprotocol Lambda Switching
OADM - Optical Add-Drop Multiplexer
OS - Operating System
OSI - Open System Interconnection
OSPF - Open Shortest Path First
OXC - Optical Cross-Connects
PXC - Photonic Cross-Connect
PVC - Permanent Virtual Circuits
PC - Personal Computer QoS - Quality of Service
RSVP - Resource Reservation Protocol
RSVP-TE - Reservation Protocol with Traffic Engineering
RTT - Round Trip Time
SONET - Synchronous Optical Network
TDM - Time Division Multiplexing
TE - Traffic Engineering
TLV - Type Length Value
TTL - Time to Live
VCI - Virtual Circuit Identifier
VoIP - Voice over IP
VPI - Virtual Path Identifier
VPN - Virtual Private Network
WAN - Wide Area Network
WWW World Wide Web
8/13/2019 Di Serta Tie 2005
18/120
xvi
LIST OF APPENDICES
APPENDIX TITLE PAGE
A Kernel Script for R-4 94
B Kernel Script for R-1 96
C Kernel Script for R-2 99
D Kernel Script for R-3 101
8/13/2019 Di Serta Tie 2005
19/120
CHAPTER I
1.1 Overview of Internet Challenges
The overwhelming growth of the Internet and the growing popularity of real-time
applications set new challenges to the Internet community. Big Internet service
providers are growing ever larger and supporting increasingly a variety of services, with
different requirements both from different applications and their customers. Service
providers need for a commercially viable and scalable tools to make the most of their
networks in order to increase their revenues by supporting the needs of time or andmission critical applications [24]. This is because different applications have varying
needs for delay, delay variation (jitters), bandwidth, and packet loss.
For example, real-time applications such as Voice over IP (VoIP) and video
conferencing are extremely latency-dependent. Here, the timeliness of data delivery is an
issue of utmost importance. But in the Internet, where there is no predictable traffic
control, these applications do not run effectively. Service differentiation for traffic flows
and performance optimization of the operational networks are very critical for the
Internet to remain as successful as before. However, the Internet, particularly its core
protocol IP (Internet Protocol) was never designed with Quality of Service (QoS) in
mind. Instead it was originally designed as a research and educational resource, and thus
the underlying technology that forms the backbone of today's Internet is largely based on
8/13/2019 Di Serta Tie 2005
20/120
2
that philosophy [24]. But times have changed a lot since, and service differentiation
using QoS mechanisms while optimizing the operational network has become quite an
important issue in the Internet for these applications to run effectively and efficiently.
On the other hand, as the Internet is required to support different types of
services, effective and efficient bandwidth management tools in IP networks becomes
increasingly important, especially when dealing with how to allocate the available
network resources in order to optimize the overall performance of the networks. And
yet, when the network has to sustain heavy traffic load, and has limited resources, thesituation of having some congested links, while others remain underutilized is almost an
inevitable phenomenon [24]. One of the main reasons to cause such congestion events in
IP networks is that of the destination based forwarding paradigm.
In IP networks, the Interior Gateway Protocols (IGPs), such as Open Shortest
Path First (OSPF), and Intermediate System-Intermediate System (IS-IS) routing
protocols use destination-based forwarding algorithm, without considering other
network parameters, such as the available bandwidth. In effect, all traffic between any
two nodes traverses across the IGP shortest path. Hence, it is obvious that such situation
can create hot spots on the shortest distance between two points, while other alternative
routes may still be underutilized. As a result, degradation of throughput, and long delay,
and packet losses can be noticed. In such situation, minimizing the effects of congestion
by optimizing the performance of the operational networks becomes more critical.
Traffic Engineering (TE) is very important in this regard [11], and plays a key
role in that it offers service providers a means for performance optimization and
bandwidth provisioning. In fact, without TE, it is also difficult to support QoS on a large
scale and at reasonable cost [12]. Therefore, the key to address the problem of traffic
engineering is to have the ability to place the traffic onto the network as flexibly as
8/13/2019 Di Serta Tie 2005
21/120
3
needed, so that the congestion in the network can be minimized before it leads to poor
network performance. Because minimizing congestion by optimizing the distribution of
traffic on a given network is the central goal of TE [13].
In order to address the QoS issue, however, the ability to introduce connection-
oriented forwarding techniques to connectionless IP networks becomes necessary. In
effect, this allows IP networks to reserve resources, such as bandwidth over
predetermined paths for service differentiation in order to provide QoS guarantees.
1.2 Project Background
Multiprotocol Label Switching (MPLS) is an emerging technology, which plays
a key role in IP networks by delivering QoS, as well as traffic engineering features.
MPLS has been developed and standardized by the Internet Engineering Task Force
(IETF) to address these issues, in a more scalable and cost effective way.
A lot of research has been done on MPLS performance study, and MLPS does
provide QoS and TE. In University Teknologi Malaysia, MPLS test-bed not yet been
developed and used. Hence, this project is prominent since it would be a pioneer in
MPLS study in our university.
8/13/2019 Di Serta Tie 2005
22/120
4
1.3 Objectives of Research
Internet nowadays is facing a lot of challenges due to the gigantic numbers of
users and fast growing of Internet applications. One way to overcome this problem is to
provide QoS. However QoS cannot be achieved without having TE along. Due to these
challenges, this project aim is to develop MPLS test-bed for network traffic engineering
and to preserve QoS through explicit routing in Internet using MPLS.
1.4 Research Scopes
In order to develop MPLS test-bed, the components in MPLS domain itself need
to be set up previously. For this project, four routers are needed to provide alternative
routes between routers in MPLS network. Routers in MPLS test-bed which are able to
forward IP packets in MPLS domain are called Label Switching Router (LSR). The
routers basically based on Linux operating system since this operating system is open-
source system, and the software to turn ordinary Linux PC into LSR are freely available
in the Internet. Other scopes of this project are to enable the connection between routers
and to create Label Switched Path (LSP). Finally IP packets passing through routers
using LSP are validated using Linux command.
8/13/2019 Di Serta Tie 2005
23/120
5
1.5 Thesis Outline
The contents of the project are further subdivided into chapters that described in
details. Chapter I discussed about the overviews of current challenges in Internet
technology. The factors why core network must provide new technology and must be
improved are also specified in details. This chapter also introduced project background,
objective of the research and scopes that are involved in order to finish the project. The
overall projects process flow chart also shown.
The Chapter II discussed literature studies and related works. The basic
fundamentals and architecture of MPLS are explained in details. Other MPLS
applications such as Virtual Private Network (VPN) and Asynchronous Transfer Mode
(ATM) with IP integration also discussed. How MPLS provides Traffic Engineering
(TE), Quality of service (QoS) and Class of Service (CoS) are elaborated in this chapter.
Moreover, operating system used in this project is explained briefly. Finally the
implementations of MPLS in Linux are explained in details such as its data structures
and the processes happened when Linux machines run MPLS.
Chapter III explained about design and procedures done for this project. The
steps to configure Linux machine into MPLS router are also explained. Label Switched
Path (LSP) establishment between routers are described step by step for easy
understanding.
In Chapter IV, results are shown and discussed. This chapter covers the results of
LSP set up between two routers and the results of LSP between ingress and ingress
router. Finally in this chapter, the results of Round Trip Time (RTT) for the test-bed are
shown.
8/13/2019 Di Serta Tie 2005
24/120
6
Lastly in Chapter V, the conclusions of this project are described. Some futureworks that can be done in order to enhance are explained.
1.6 Project Flow Chart
Literature reviews on MPLS
Upgrade knowledge in using LINUX
Progress of this study can be summarized into flow chart shown above. First of
all, literature reviews on MPLS need to be done to acquire basic knowledge about
MPLS. Journals and papers were referred to enhance the understanding and to get the
overview of the project. Since this project requires Linux operating system as the
MPLS software
Recompile Kernel
Install Binary Files
Enable Kernel IP Forwarding
Build Ethernet Driver
Assign IP Address
Develop Test-bed
Turn On MPLS
LSP set up between 2 PCs
Create LSP1 & LSP 2
Test-bed Testing
8/13/2019 Di Serta Tie 2005
25/120
7
platform, the knowledge using Linux must be enhanced. The understanding of Linux
critical scripts that exists in Linux kernel is also very important. MPLS software is taken
from Sourceforge homepage. This software package is still under development thus
MPLS package version 1.946 is chosen since it is the latest up date package. Before
Linux PC can be change into MPLS router, the kernel need to be compiled. The
appropriate binary files are installed in order to make MPLS router to function.
Furthermore, kernel IP forwarding in Linux machine has to be change into
enable state since it is disabled by default. Linux machines are connected together withappropriate IP addresses. But this can only be done when the ethernet cards driver is
installed in every Linux machine. Before LSP between two routers can be established,
each router must be MPLS enabled by turning on MPLS. The connection between two
routers is used again to create new LSP but now it connects ingress router to egress
router.
In this study, two LSP that are LSP 1 and LSP 2 which connects ingress to egress
are created. LSP 2 connects four routers while LSP 1 connects only three routers. The
test-bed is tested by sending IP packet into it. When the packets captured were
encapsulated with MPLS header it shown that the MPLS test-bed was well developed.
8/13/2019 Di Serta Tie 2005
26/120
CHAPTER II
LITERATURE REVIEW
2.1 Introduction
Due to the increasingly numbers of personal computers that are connected to the
Internet and the popularity of the World Wide Web (WWW), Internet use has gone
beyond all expectations. The adoption rate of the Internet has surpassed all other
preceding technologies such as telephone, radio, television, and computer. This
phenomenal growth has made the Internet Protocol (IP) suite the most predominant
networking technology. With the rapid growth of Internet services and the recent
advances in Dense Wavelength Division Multiplexing (DWDM) technology, an
alternative to Asynchronous Transfer Mode (ATM) for multiplexing multiple services
over individual circuits is needed. The once fast and high-bandwidth ATM switches are
not good enough because Internet backbone routers are outperforming them [10].
Multiprotocol Label Switching (MPLS) offers a simpler mechanism for packet-
oriented traffic engineering. The term multiprotocol implies that its techniques are
8/13/2019 Di Serta Tie 2005
27/120
9
applied to any network layer protocol; however, in this discussion IP is regard as the
network layer protocol.
MPLS is an extension to the existing IP architecture. It is the latest step in the
evolution of routing and forwarding technology for the Internet core. It is a new
technology being standardized by the Internet Engineering Task Force (IETF) designed
to enhance the speed, scalability, and service provisioning capabilities in the Internet. As
a technology for backbone networks, MPLS can be used for IP as well as other network-
layer protocols. It has become the prime candidate for IP-over-ATM backbone networks[10].
The next part of this thesis presents the basic features and architecture of MPLS. It
also discussed its popular applications such as Virtual Private Network (VPN), Traffic
Engineering (TE), IP and ATM integration. It introduced the next technology of existing
MPLS that is Multiprotocol Lambda Switching or MPS. Finally, the implementations of
MPLS in Linux operating system that covers from all perspectives are discussed.
2.2 MPLS Basics
Cisco has been working within the IETF to develop a standard for invented tag
switching since they first shipped it in 1998 [10]. That standard is MPLS. Thus, tag
switching is a pre-standard implementation of MPLS. MPLS provides a solid
framework that supports the deployment of advanced routing services because it solves
a number of complex problems. It addresses the scalability issues associated with the
8/13/2019 Di Serta Tie 2005
28/120
10
currently deployed IP-over-ATM overlay model and significantly reduces the
complexity of network operation [10].
MPLS is a means of forwarding information at a very high rate. It combines the
speed and performance of Layer 2 with the scalability and IP intelligence of Layer 3. It
separates an IP router's function into two parts; forwarding and control. It is also a
collection of distributed control protocols used in setting up paths in IP networks.
MPLS provides a mean to map IP addresses to simple, fixed-length, protocol-
specific identifiers known as label (i.e., it separates forwarding information [label]from the content of the IP header). MPLS also uses a single-forwarding paradigm
(label swapping) at the data plane to support multiple-routing paradigms at the
control plane. Furthermore, it eliminates the need for interrogating the IP header of
every packet at every intermediate router [10].
MPLS enables constraint-based routing, which allows the distribution of the
traffic load on alternate routes when the shortest path is over loaded. It is an
integration of Layer 2 and Layer 3 technologies. By making conventional Layer 2
features available to Layer 3, MPLS enables traffic engineering and independent of the
underlying link layer technology. It uses different technologies and link layer
mechanisms to realize the label swapping forwarding paradigm. In addition, MPLS
supports the IP, ATM, and frame relay Layer 2 protocols [10].
Moreover, MPLS provides flexibility in the delivery of new routing services.
It supports the delivery of services with QoS guarantees and thereby facilitates voice,
video, and data service integration. It facilitates scalability through traffic aggregation
and allows the construction of VPN in IP networks. Furthermore, MPLS offers a
standards-based solution that promotes multi-vendor interoperability [10].
8/13/2019 Di Serta Tie 2005
29/120
11
The aim of MPLS is to improve the scalability and performance of the prevalent
hop-by-hop routine and forwarding across packet networks. Its primary goal is to
standardize a technology that integrates the label switching forwarding paradigm with
network layer routing.
2.2.1 MPLS Architecture
MPLS is a connection-oriented protocol that appears between the link layer and
the network layer in Open System Interconnection (OSI) model, as ATM or frame relay,
but without a dependence on the link layer. Figure 2.1 shows the MPLS in OSI model.
The concept of label switching is keys to MPLS. The key function of MPLS is to perform
traffic aggregation.
In a conventional IP network, streams of traffic between two points in the
network are divided into many IP packets with each packet having its own header; the
source address and destination address. Along the way, each router inspects every
packet header in order to route it. The less time routers spend inspecting packets, the
more time they have to forward them. It is a waste of resources to inspect every IP
packet header when transferring a large number of packets destined for the same
destination from the same source. MPLS recognizes such packets and adds a special
label identifying them as a unified flow of information. In other words, a label is a short,
fixed length, locally significant identifier used to identify a stream. Intermediate routers
would then see the labels and forward them rapidly toward their destination [10].
8/13/2019 Di Serta Tie 2005
30/120
12
TCP
Physical (Optical - Electrical) 1
2
IP 3
4
Applications7to
5
UDP
PPP FR ATM (*)
MPLS
TCP
Physical (Optical - Electrical) 1
2
IP 3
4
Applications7to
5
UDP
PPP FR ATM (*)
MPLS
Physical (Optical - Electrical) 1Physical (Optical - Electrical) 1
2
IP 3IP 3
4
Applications7to
5
Applications7to
5
UDP
PPP FR ATM (*)PPP FR ATM (*)
MPLS
Figure 2.1: MPLS in OSI Model
At the ingress point of an MPLS network, router called as Label Edge Router
(LER) adds a label to each incoming IP packet according to its destination and the state
of the network. The label is embedded in the Layer 2 protocol header of the packet. The
basic task of the routers is to forward packets as efficiently as possible from source to
destination. To achieve this, each router needs information on the topology and status of
the network, and where the egress of the respective destination is located. Label
switching relies on the setup of switched paths through the network known as Label
Switching Paths (LSPs). In other words, LSP is an established logical MPLS connection,
which links an LER via a LSR to another LER, as illustrated in Figure 2.2. A key feature of
MPLS is that one or more flows can be assigned to the same label or LSP. When a packet is
sent on an LSP, a label is applied to the packet. On ATM links, for example, the label
may be carried as the Virtual Circuit Identifier (VCI) or Virtual Path Identifier (VPI)
applied to each ATM cell. A similar scheme has been proposed for Synchronous Optical
Network (SONET).
In an MPLS network, an LSP is set up for each path through the network. The
router examines the header to determine which LSP to use before adds the appropriate
LSP identifier (a Layer 2 label) to the packet and forwards it to the next hop. All the
subsequent nodes forward the packet along the LSP identified by the label. LSPs
8/13/2019 Di Serta Tie 2005
31/120
13
typically follow the shortest path from source to destination. Once the traffic is within
the MPLS network, only the label is used to make decisions on the next hop where the
packet is to be sent, in contrast to traditional destination-based hop-by-hop forwarding
used in IP networks. Each label has only hop-by-hop relevance. This feature allows for
an efficient resource usage and provides high-speed forwarding.
Figure 2.2: MPLS architecture [10]
Hence, an MPLS network consists of MPLS nodes called LSRs connected by circuits
called LSPs. The main component of MPLS architecture is the Label Distribution Protocol
(LDP), which is a set of protocols by which an LSR communicates with an adjacent peer by
means of exchanging labels. To establish an LSP, a signaling protocol such as LDP is
needed. Each LSP has a Forwarding Equivalent Class (FEC) associated with it. The
classification of packets into specific FEC identifies the set of packets that will be mapped
to a path through the network. At the ingress of an MPLS domain, all incoming packets
will be assigned to one of these FECs. Once a packet gets to the end of the last egress edge
router, the labels are popped and the packet is routed according to the conventional or
traditional IP forwarding rules.
8/13/2019 Di Serta Tie 2005
32/120
14
As mentioned before, label distribution among the various LSRs is done by the
LDP. The LDP protocol has four types of messages serving different purposes [10];
i. Discovery messages: to advertise the presence of LSRs
ii. Session messages : to establish and maintain LDP sessions
iii. Advertisement messages : to create, change, and delete label mappings for FECs
iv. Notification messages : to carry advisory and error information
U
1 bits
Message
Type
15 bits
Message
Length
16 bits
Message ID
32 bits
Mandatory
Parameters
Variable bit
Optional
Parameters
Variable bit
Figure 2.3: The format of LDP messages
The format of each LDP message is presented in Figure 2.3, where U (1 bit)
denotes unknown messages and is used to notify the sender in case an LSR fails to
recognize a message. The 15-bit message-type field is used to identify an LSP as one of
the 10 defined types. The 16-bit message-length field specifies the total length of the
message in bytes. The 32-bit message ID uniquely identifies the message. Mandatory
and optional parameters employ a special coding called Type-Length-Value (TLV).
Within the IETF, two candidate protocols for the LDP are Resource Reservation Protocol
(RSVP) and Constraint-based Routing Label Distribution Protocol (CR-LDP).
Labels exist within some transport media that MPLS nodes can use in making
forwarding decisions. Examples include ATM's Virtual Path Identifier/Virtual Circuit
Identifier (VPI/VCI) field and frame relay's Data Link Connection Identifier (DLCI).
Other transport media, such as Ethernet and point-to-point links, must use a shim label.
8/13/2019 Di Serta Tie 2005
33/120
15
The MPLS generic shim label format is illustrated in Figure 2.4. It consists of the
following fields.
Data Link layer
Layer 2 Header
MPLS Shim Label IP Header
Layer 3 Header
Packet Data
Label
20 bits
EXP
3 bits
S
1 bits
TTL
8 bits
Figure 2.4: Shim Label
The 32 bits shim label is used to identify an FEC and the details of this shim
label are discussed in section 2.8.1.
2.3 MPLS Applications
Multiprotocol Label Switching can be used for the Internet Protocol (IP) or any
other network-layer protocols. It can be deployed in corporate networks as well as in
backbone networks. Its greatest strength is perhaps its seamless coexistence with IP
traffic and its reuse of proven IP routing protocols. It addresses today's network
backbone requirements by providing a standards-based solution that supports network
scalability, builds interoperable networks, and integrates IP and ATM.
8/13/2019 Di Serta Tie 2005
34/120
16
MPLS may be regarded as a general-purpose tunneling protocol that enables
several network services, which are distinguished by LDPs they used to build tunnels and
what kind of traffic flows through the tunnels. Popular applications of MPLS are
discussed next.
2.3.1 Virtual Private Network (VPN)
MPLS supports Virtual Private Network (VPN) services [10]. VPNs share a
single infrastructure of routers or switches between multiple independent networks.
Using MPLS for VPNs is an attractive alternative to building VPNs using either ATM or
frame relay Permanent Virtual Circuits (PVCs), or various forms of tunnels, to
interconnect routers at customer premises. MPLS based VPNs have some advantages
over a PVC based model. They allow customers to choose their own addressing plans,
and encryption is usually not required. They also enable the development of extranets
using flexible policies. An MPLS based VPN employs LSPs to provide tunnel-like
isolation. The key benefits of MPLS based VPNs include increased scalability, QoS
support, and implicit data security mechanism.
2.3.2 IP and ATM Integration
MPLS enables IP and ATM integration [10]. In fact, MPLS is primarily a solution
for IP-over-ATM backbone. MPLS enables an ATM switch to perform virtually all of the
functions of an IP router. This is made possible by the fact that MPLS label swapping is
8/13/2019 Di Serta Tie 2005
35/120
17
the same as the forwarding paradigm provided by ATM switch hardware. MPLS is the
Internet's best long term solution to efficient, high performance forwarding and traffic
differentiation. Although MPLS can operate over any data link layer, ATM is by far the
most suitable technology due to its ability to transport data, voice, and video with the offer
of a defined QoS. MPLS has some advantages over a typical IP-over-ATM overlay
model. First, it offers simpler integration of control information. It also avoids complex
mechanisms to provide mapping from IP multicast addresses to multipoint virtual
circuits. Second, the scalability of IP routing is improved relative to an overlay model.
Third, it makes routing at the IP layer more likely to be optimal.
The selling point for MPLS is its ability to support LSPs from edge to edge. This
allows sophisticated load balancing, QoS, and MPLS based VPNs to be deployed by
service providers. Although MPLS is a technology designed for IP based terrestrial
networks, its capabilities can be made for satellite constellations where extensive routing is
required. It should be mentioned that, as great as MPLS is, not every network needs it.
Only large networks such as Wide Area Networks (WANs) with complex mesh
topology must engineer traffic.
2.4 Traffic Engineering with MPLS
The challenge of traffic engineering is how to make the most effective use of the
available bandwidth in a large IP backbone networks, or place the traffic over them so
that we can achieve the best performance characteristics from the same IP networks even
in the event of congestion. MPLS addresses the traffic engineering issue by setting up
explicit paths through the network using constraint based routing.
8/13/2019 Di Serta Tie 2005
36/120
18
MPLS traffic engineering dynamically establishes and maintains an LSP tunnel
across the MPLS domain using signaling protocols. The two signaling mechanisms used
for distributing labels across an MPLS domain, in the context of traffic engineering and
QoS, are Constraint-based Routing Label Distribution Protocol (CR-LDP) [15], and
Resource Reservation Protocol with Traffic Engineering extension (RSVP-TE) [16].
Explicit routing or constraint-based routing is particularly interesting for traffic
engineering purpose.
The label distribution protocols (both CR-LDP and RSVP) determine the pathacross which the LSP tunnel is established based on its resource requirements and
available network resources, such as bandwidth. Then, they move the label binding
information along a predefined route. At the ingress, LSRs assign label to packets as
they enter the network. Here, the label binding to packets is done based on FEC
membership. This feature of MPLS allows scalable aggregation of flows into a single
FEC based on their requirements. In fact, it also makes the task very simple for MPLS
traffic engineering to route traffic flows across an LSP tunnel by associating the
resources required by a given FEC (or LSP) with actual backbone capacity and
topology.
To illustrate how explicit LSPs are used to solve the traffic engineering problem,
let consider the example shown in Figure 2.5. In this figure, LSR 1 through LSR 3 are
label switching routers, while Host A through Host D are traffic sources and sinks.
Assume 100 Mbps PVC connections among all routers. Further assume the traffic from
Host A to Host C is 100 Mbps and that of the traffic from Host B to Host D is 100
Mbps.
8/13/2019 Di Serta Tie 2005
37/120
19
Figure 2.5: MPLS Domain [24]
With MPLS explicit routing capability, the traffic from Host B to Host D can be
assigned to LSP 2, which in turn traverses the path LSR 1-LSR 2-LSR 3, while the
traffic from Host A to Host C can be made to travel across LSP 1, which consists of path
LSR 1-LSR 3. As a result, the traffic flows between hosts one side (in this case, Host A
and Host B) and hosts on the other side (Host C and Host D) can be distributed over the
network according to their demands, such as bandwidth guarantees, by just establishing
different LSPs. This enables to attain efficient utilization of bandwidth, as well as a
significant performance gain.
8/13/2019 Di Serta Tie 2005
38/120
20
2.5 MPLS QoS
The important issue to overcome here is the need for QoS capability in the
Internet, which arises from the fact that the current Internet offers just best effort packet
delivery service, and thus all packets are treated equally, regardless of the needs of
applications for some levels of resource assurance. This is mainly because IP on which
the Internet is based, was not typically designed as a connection oriented protocol.
Instead IP is providing a connectionless or datagram service, thus no end to end
guarantees of packet delivery can be provided. But in order to provide QoS guarantees inthe Internet, all packets of a flow must traverse the same path, and some means for
reserving resources along that path must exist. At least, in this way, the Internet can have
the ability to differentiate between high priority and lower priority network traffic in
order to ensure guaranteed quality of service.
MPLS provides a robust QoS control feature in the Internet. In addition, MPLS
Class of Service (CoS) feature can work in conjunction with other QoS architectures for
IP networks defined by the IETF. Integrated Services (IntServ) [17] using Resource
Reservation Protocol (RSVP) [18] and Differentiated Services (DiffServ) [19] are the
two models defined by the IETF for providing QoS in IP networks. Combining MPLS
with DiffServ is particularly interesting, and provides the required levels of end to end
QoS management in a scalable way. MPLS does support for DiffServ [20]. In fact, both
MPLS and DiffServ are the real enhancements to IP networks. However, they do not
make any requirements about each other, so they can work independently.
The QoS feature of MPLS represents the capability to provide differentiated
levels of service and resource assurance across an MPLS network. This capability
typically includes a set of techniques necessary to manage network bandwidth, delay,
jitter, and packet loss. For example, the ability to mark packets with a certain priority
8/13/2019 Di Serta Tie 2005
39/120
21
combined with buffer management and queuing schemes ensures that voice traffic
remains within the acceptable bounds for packet loss, delay, and jitter. So, in an MPLS
network, when a packet arrives at a LSR, the label is used to determine outbound
interface and new outbound label, but the CoS (EXP) field value is used to determine the
type of treatments, such as queuing and scheduling.
With MPLS QoS, there are two approaches to mark traffic for controlling QoS
within an MPLS network. That means, when IP traffic enters an LSP tunnel, the CoS
bits in the MPLS header are set in one of two ways. In the first way, queuinginformation is encoded into the experimental (EXP) field of the MPLS shim header.
Since the EXP field allows eight different CoS markings, the marking is used as packet's
CoS value. Here, different packets might receive different markings depending on their
requirements, so that they can receive different treatments along the path. This approach
is referred to as Experimental bit inferred Label Switched Paths (E-LSPs), to indicate
that QoS information is inferred from the EXP field.
In the second method, the label associated with MPLS packet specifies how a
packet should be treated, and all packets entering the LSP will be marked with a fixed
CoS value. This means that all packets entering the LSP receive the same Class of
Service. This approach is known as Label inferred Label Switched Paths (L-LSPs), to
indicate that QoS information is inferred from the MPLS label.
Either way, MPLS offers an effective way to allocate network resources to traffic
according to their requirements with different granularity. Since MPLS also allows
dedicated paths to be set up and bandwidth reservation across the same path, QoS can be
guaranteed.
8/13/2019 Di Serta Tie 2005
40/120
22
2.6 MPLS Future Technology
The next logical step toward all optical networks is to employ a variation of
MPLS that supports different wavelengths for different data flows on the transport layer.
This technique is already under investigation and it is called Generalized Multiprotocol
Label Switching (GMPLS) [10], which is also an enhancement of Multiprotocol Lambda
Switching (MPS). It is a suite of protocol extensions that support multiple switching
types such as packet switching, Time-Division Multiplexing (TDM) switching, lambda
switching, and fiber switching. The basic features of GMPLS include the following:
i. It is a set of traffic engineering and optical extensions to existing MPLS routing
and signaling protocols.
ii. It is an optical networking standard that represents an integral part of next-
generation data and optical networks.
iii. It provides the necessary bridge between IP and optical layers, therefore enabling
networks to be both interoperable and scalable.
iv. It brings more intelligence to optical networks; more intelligent optical devices
help network operators do better restoration and better utilize bandwidth.
v. It is designed to allow edge networking devices such as routers and
switches to request bandwidth from the optical layer.
vi. It supports hierarchical LSPs and optical LSPs (or lightpaths).
vii. It is designed to handle multiple traffic types simultaneously. It creates a control
plane to support multiple switching layers:
a. Packet switching for forwarding based upon packet or cell headers
b. Time-division switching for forwarding based upon the data's
time slot in a repeating cycle (e.g., SONET/SDH, PDH)
c. Wavelength (lambda) switching for forwarding data based on the
wavelength on which it was received
8/13/2019 Di Serta Tie 2005
41/120
23
d. Spatial switching for forwarding data based on a position of the
data in real-world physical spaces (e.g., incoming port or fiber to
outgoing port or fiber)
The main focus of GMPLS is on the control plane of these various layers
because each of them can use physically diverse data or forwarding planes. The goal is
to cover both the routing and signaling portions of the control plane. GMPLS extends
MPLS to encompass time division, wavelength, and spatial switching. It extends the
proven MPLS LSP mechanisms to create generalized labels and generalized LSPs.These extensions of MPLS include [10]:
i. Enhancements to signaling protocols - The RSVP or CR-LDP are used as
signaling protocol. GMPLS requires that an LSP start and end on similar types of
devices. Although LPSs are unidirectional in MPLS architecture, they could be
unidirectional or bidirectional light paths in GMPLS. GMPLS signaling enables
an upstream node to suggest a label, although the suggestion may be overridden
by a downstreams node.
ii. Enhancements of routing - GMPLS enables many improvements to routing. With
GMPLS, explicit paths can be established across network layers. Open Shortest
Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) is used
as Interior Gateway Routing Protocol (IGP).
iii. Introduction of Link Management Protocol (LMP) - This is a new protocol
designed to resolve issues related to link management of optical networks. LMP
is what a router uses to decipher the availability of a link between itself and
another router. It provides four basic functions for a node pair; control channel
management, link connectivity verification, link property correlation, and fault
isolation.
8/13/2019 Di Serta Tie 2005
42/120
24
iv. Additional functionality to address issues related to MPLS control plane -
GMPLS allows the control to be physically diverse from the associated data
plane.
These extensions affect routing and signaling protocols for activities such as
label distribution, traffic engineering, protection, and restoration. They also enable rapid
provisioning and management of network services.
Although MPLS was designed exclusively for packet services, the primary goal
of GMPLS is to provide a single suite of protocols that would be applicable to all kinds
of traffic. By consolidating different traffic types, GMPLS permits simplification of
networks and improves their scalability in ways unheard of until now. It offers the
means by which networks can be scaled and simplified by deployment of a new class of
network element designed to handle multiple traffic types simultaneously.
GMPLS network architecture offers a common mechanism for routing, data
forwarding, and traffic engineering on transport networks with dense wavelength
division multiplexing (DWDM). Such a future network will consist of elements such as
routers, switches, DWDM systems, Optical Add-Drop Multiplexers (OADMs), Optical
Cross-Connects (OXCs), Photonic Cross-Connects (PXCs) so forth that will employ
GMPLS to dynamically provision resources and to provide network survivability using
protection and restoration techniques. These optical network elements will have full
control of the wavelengths and could create self connecting and self regulating networks.
The technology behind GMPLS is Micro-Electric Mechanical Systems (MEMs), which
can use micro-mirrors to redirect lambdas. This has opened the doors to a bandwidth
explosion. This will eventually enable networks that require less management and
overhead.
8/13/2019 Di Serta Tie 2005
43/120
25
GMPLS offers several key benefits to service providers to migrate their services
from their current model to the GMPLS unified control plane. First, GMPLS gives
network operators the freedom to design their networks to best meet their specific
objectives. Second, GMPLS provides accelerated service provisioning of any type of
service, at any time, with any level of QoS, and to any destination. Third, GMPLS
enables greater service intelligence and efficiency because it allows the network system
to view the entire network topology, network node switching capability, and network
resource status across all packet, TDM, and wavelength services. GMPLS will play a
major role in the deployment of next generation networks; it will provide a common
control mechanism across both the packet-switched and transport domain forestablishing label switched paths.
2.7 Linux as the Operating System (OS)
Linux is a free operating system that was created by Linus Torvalds when he was
a student at the University of Helsinki in 1991 [3]. It is a version of the UNIX operating
system that has become very popular over the last several years.
Linux has been copyrighted under the terms of the GNU General Public License
(GPL). This is a license written by the Free Software Foundation (FSF) that is designed
to prevent people from restricting the distribution of software. In brief, it says that
although money can be charged for a copy, the person who received the copy can not be
prevented from giving it away for free. It also means that the source code must be
available. This is useful for programmers. Anybody can modify Linux and even
distribute his/her modifications, provided that they keep the code under the same
copyright.
8/13/2019 Di Serta Tie 2005
44/120
26
In this project Linux Fedora Core 2 has been used since it has kernel of version
2.6.5 that is needed to support MPLS forwarding mechanism. Fedora Core 2 is operating
system that developed under Red Hat project and it is freely available. When this project
is done, Fedora has just released it Fedora Core version 4.
2.7.1 Linux Differences
Linux is generally cheaper than other operating systems and is frequently less
problematic than many commercial systems. But what makes Linux different is not its
price but its outstanding capabilities which are:
i. Linux is a true 32-bit multitasking operating system, robust and capable enough
to be used in organizations ranging from universities to large corporations.
ii. It runs on hardware ranging from low-end 386 boxes to massive ultra-parallel
machines in research centers.
iii. Out-of-the-box versions are available for Intel, Sparc, and Alpha architectures,
and experimental support exists for Power PC and embedded systems, among
others such as SGI, Ultra Sparc, AP1000+, Strong ARM, and MIPS
R3000/R4000.
iv. When it comes to networking, Linux is choice. Not only because networking is
tightly integrated with the Operating System (OS) itself and a plethora of
applications is freely available, but for the robustness under heavy loads that can
only be achieved after years of debugging and testing in an Open Source project
8/13/2019 Di Serta Tie 2005
45/120
27
v. Finally, Linux kernel has built-in support for routing functions. The kernel can
be configured to support many type of routing mechanism such as MPLS, RSVP
and other. A Linux box can acts either as an IP or IPX router for a fraction of the
cost of a commercial router. Recent kernels include special options for machines
acting primarily as routers.
2.8 Details of MPLS Forwarding Basics Implemented in Linux OS
The goal of Multiprotocol Label Switching (MPLS) is to remove the process of
layer three lookups at each hop of a network. This has many direct affects. MPLS
forwarding makes traffic engineering a more viable solution for network congestion.
MPLS forwarding may enable wire speed routing (switching). MPLS forward could
allow network hardware vendors to make cheaper trunk cards that only understand
labeled packets. MPLS abstracts the media specific qualities away from more complex
network engineering (QoS, CoS, DiffServ). MPLS forwarding can be used to make VPN
service more flexible and deployable without compromising the performance of edge
routers (switches). In addition to the above, the concepts used to setup MPLS forwarding
are the first step towards creating completely optical networks.
As a packet traverses an MPLS enabled network it must make three transitions.
First, is that it must go from its native Layer 3 forwarding into labeled MPLS
forwarding. This process entails the adding of a label to the head of the packet. Second,
a (now labeled) packet must be able to traverse an MPLS path. This path consists of all
the devices that know how this particular packet (and packets like it) needs to traverse a
network. This path is called a LSP. It is a connection oriented path that is setup ahead of
the forwarding of any packets. Finally a packet must make its way back into Layer 3
8/13/2019 Di Serta Tie 2005
46/120
28
forwarding. This process consists of removing the label from the head of the packet and
then sending it to the appropriate Layer 3 protocol for additional handling. In an MPLS
enabled network, Layer 3 forwarding is used by the edges of the network, and MPLS
forwarding is used in the core of the network.
2.8.1 MPLS Label
When a label is added to a packet this means that at minimum a 4 bytes "shim"
has been added to the packet. This shim is added between the Layer 3 header and Layer
2 header. Therefore an IP packet on Ethernet would add the shim before the IP header
but after the Ethernet header. MPLS forwarding is currently defined for the following
Layer 2 implementation: Ethernet, packet over SONET, ATM, frame-relay. MPLS has
also been defined for any medium that PPP runs on top of. On most of this Layer 2
implementation a label consists of a 20 bits number. The shim that is added to the packet
contains more then just a label.
As illustrated by Figure 2.4 in section 2.2.1, the label is 20 bits. This value is
used to determine how a packet will be label switched. The next 3 bits are called the
EXP bits. They are currently reserved for experimental purposes (although DiffServ
over MPLS has claimed these 3 bits for its use). The next bit is referred to as the
"bottom of stack bit" (S bit). Due to the fact that MPLS adds a shim to the packet, a LSR
needs to know if what follows this top shim is the Layer 3 header or another shim.
(Multiple shims are called a label stack and the purpose of a label stack will be
explained later). The S bit signifies that what follows this shim is the Layer 3 header.
For typical single shim MPLS forwarding the S bit is on. Finally the shim contains the
Time to Live (TTL) counter. This is used to allow current Layer 3 functions to occur
8/13/2019 Di Serta Tie 2005
47/120
29
even though an LSR cannot use the Layer 3 header. Some examples of these are
traceroute, loop detection, and multicast domains.
2.8.2 MPLS Label Stacking
When an LER adds a shim to a packet, it is feasible that is can add more thanone shim. This concept is called Label Stacking. The stack of shims is treated just as its
name sake data structure. A POP means that the top shim is removed, exposing either
another shim or the Layer 3 header (determined by the S bit). A PUSH adds a new
shim to the top of the stack or on top of the Layer 3 header. So standard label swapping
is defined as a POP followed by a PUSH.
In some cases a labeled packet may need to be tunneled across another MPLS
network. In the case the labeled packet gets another shim pushed on top without POPing
the original shim off. This results in a label stack of size 2. This operation can occur
multiple times by separate LSRs or a single LSR could add more then one shim. In
general any labeled packet has a label stack, although most have a label stack of size 1.
As one may expect a packet with a label stack greater then 1 may shrink in size as well.
This operation would be defined by a POP without a PUSH. The exact details of how
this occurs are explained in the next section.
8/13/2019 Di Serta Tie 2005
48/120
30
2.8.3 MPLS Data Structures
For MPLS forwarding to occur correctly some data structures need to exist to
assist in the interpretation of labels and the processing of them. In general there exists
three data structure. One data structure to help interpret incoming labels (labels from
packets that are entering an LSR or egress LER). A second data structure to assist in
adding out going labels (labels on packets that are leaving a LSR or ingress LER). A
third data structure is used by ingress LERs to figure out what label to add to a packet.
2.8.3.1 Incoming Label Map (ILM)
The common name for the data structure used to interpret incoming labels is
called the Incoming Label Map (ILM). The ILM table consists of all the incoming labels
that an LSR or egress LER will recognize. The contents of each ILM entry are: label,
opcode, FEC, and an optional link to an outgoing data structure. The general order of
operation for incoming label processing are:
i. extract label from top shim
ii. lookup the label in the ILM table
iii. further processing on the packet based on the opcode stored with the label
Details of ILM processing are explained in the section 2.9.1.
8/13/2019 Di Serta Tie 2005
49/120
31
2.3.8.2 The Next Hop Label Forwarding Entry (NHLFE)
As stated earlier there also exists a data structure to assist with outgoing labeling.
The common name for this data structure is the Next Hop Label Entry (NHLFE). The
NHLFE table consists of all the labels which can be push onto packets. Each NHLFE
entry contains: label, outgoing interface, and nexthop information. The general
processing that occurs when a packet reaches the NHLFE table are:
i. form new shim that contains the label
ii. push the shim onto the packet
iii. forward the packet to the nexthop via the outgoing interface
Details of NHLFE processing are discussed in section 2.9.4.
2.8.3.3 FEC-to-NHLFE Map (FTN)
A third data structure exists for the sole purpose of helping ingress LERs decide
what labels to add to a packet. For the explanation of this data structure we need to take
one step back and introduce the term Forwarding Equivalence Class (FEC). Up until
now we have referred to individual packet in terms of adding and removing labels. How
do we know what label to add to a packet? How do we know what type of packet I have
after removing a label?
8/13/2019 Di Serta Tie 2005
50/120
32
In general packets are labeled according to which FEC they belong to. For
example FEC A is defined to be the class of packets that are heading to the host with IP
address 1.1.1.1. Therefore all packets that have a destination of IP address 1.1.1.1 belong
to FEC A. In MPLS each FEC is assign a label and each label refers to a FEC (1:1
mapping). The definitions of FECs may change but the 1:1 mapping should always stay
constant. The data structure used to map FECs to labels is called a FEC to NHLFE or
FTN. An FTN table consists of all FECs which we know how to add labels too. An FTN
entry consists of FEC and NHLFE entry. The general orders of operation for FTN
processing are:
i. decide what FEC a packet belongs to
ii. find the FEC in the FTN table
iii. forward the packet to he NHLFE entry that corresponds to the FTN
Details FTN processing are explained in section 2.9.3.
2.9 MPLS Details
In this section the details about MPLS are explained in the sub-sections. Data
structures such as ILM and NHLFE are also explained. The process of receiving and
transmitting MPLS are also shown in the easy way to understand. Figure 2.6 shows the
main MPLS structure.
8/13/2019 Di Serta Tie 2005
51/120
33
struct mpls_label {
u32 label_res:1,
label_value:28,
label_type:3:
#define MPLS_LABEL_VPI ((label_value>>16)&0xFFF)
#define MPLS_LABEL_VCI (label_value&0xFFFF)
#define MPLS_LABEL_GEN (label_value&0xFFFFF)
#define MPLS_LABEL_DLCI_10 (label_value&0x3FF)
#define MPLS_LABEL_DLCI_17 (label_value&0x1FFFF)
#define MPLS_LABEL_DLCI_23 (label_value&0x7FFFFF)
};
#define MPLS_GEN_LABEL 0x01
#define MPLS_VPIVCI_LABEL 0x02
#define MPLS_VPI_LABEL 0x03
#define MPLS_VCI_LABEL 0x04
#define MPLS_FR10_LABEL 0x05
#define MPLS_FR17_LABEL 0x06
#define MPLS_FR23_LABEL 0x07
Figure 2.6: MPLS main structure
8/13/2019 Di Serta Tie 2005
52/120
34
2.9.1 MPLS ILM Details
Figure 2.7 shows the ILM structure.
struct ilm_ent {
struct mpls_label label;
struct route_ent* outgoing_rt;
u16 protocol;
u8 opcode;
};
Figure 2.7: ILM structure
Each logical interface needs to stores its own ILM table. MPLS packets that
arrive via that interface will do label lookups into that interfaces ILM table. The full lists
of opcodes that can be stored in a ILM entry are represented like below:
POP_AND_LOOKUP
Ifthe top shim has the S bit on:
Extract the protocol type from the ILM
POP the top shim
Copy the TTL to the layer 3 header
Using the protocol type, do a lookup on the layer 3 header that is exposed
Else
POP the top shim
Extract the label from the shim that is exposed
8/13/2019 Di Serta Tie 2005
53/120
35
Extract the S bit
Extract the EXP
Extract label and create ILM Index
Using the ILM Index Lookup the ILM Entry
Execute the opcode in the ILM Entry
End
POP_AND_FORWARD
Extract the outgoing route entry from the ILM
POP the top shim
If the outgoing route entry is a layer 3 route entry copy TTL to layer 3
header
Using the outgoing route entry forward the packet to the outgoing
interface
NO_POP_AND_FORWARD
Extract the outgoing route entry from the ILM Using the outgoing route entry forward the packet to the outgoing
interface
SEND_TO_RP
Send the entire packet to the Route Processor
2.9.2 MPLS Receive Processing
Ifinterface is of type ATM and VCC is of type MPLS_ENC
Use VPI, VCI to create ILM Index
8/13/2019 Di Serta Tie 2005
54/120
36
Else
Extract generic label from shim and create ILM Index
End
Extract TTL from top shim
Extract EXP from top shim
Extract S bit from top shim
Decrement TTL
If TTL
8/13/2019 Di Serta Tie 2005
55/120
37
2.9.4 MPLS NHLFE Details
The NHLFE is located on the transmission interface such as ethernet card.
Therefore the NHLFE entry does not need to store the outgoing interface. NHLFE
structure is shown in Figure 2.9.
struct mpls_nhlfe {
struct mpls_label **label;
u8 number_of_label;
struct sockaddr_un next_hop;
u8 exp;
};
Figure 2.9: NHLFE structure
2.9.5 MPLS Transmit Processing
If the route entry that the FTN point to is a NHLFE or the ILM refers to a
NHLFE then the following processing pertains.
Ifthe shim with an S bit on was POPed on ingress then make sure to add an S bit to the
bottom shim
Foreach label in the NHLFE
8/13/2019 Di Serta Tie 2005
56/120
38
Ifmore labels can be added
If the label is of type ATM then create a NULL shim and
add it to the packet make sure the shim with the S bit is on
the bottom of the stack extract VCC info from the ATM
label mark this packet will leave via this ATM VCC mark
that no more labels can be added.
Else
Create a shim from the generic label and add it to the
packet make sure the shim with the S bit is on the bottom
of the stackEnd
End
End
Forward the packet to the next hop stored in the NHLFE.
2.9.10 MPLS Commands in Linux OS
In order to display MPLS commands used in Linux, users have to type mpls in
Linux terminal. The resultant output is shown in Figure 2.10. There are many commands
can be used together with mpls to create Label Switched Path (LSP), assigning MPLS
packet receiver and transmitter device and also to create incoming label map (ILM).
Details of the functions are discussed in Chapter III.
8/13/2019 Di Serta Tie 2005
57/120
39
[root@localhost root]# mplsUsage: mpls ilm CMD label LABEL labelspace NUMBER [proto PROTO |instructions IN STR]
mpls nhlfe CMD key KEY [mtu MTU propagate_ttl | instructionsINSTR] mpls xc CMD ilm_label LABEL ilm_labelspace NUMBER nhlfe_key KEY
mpls labelspace CMD dev NAME labelspace NUMBERmpls tunnel CMD dev NAME key KEY
mpls ilm show [label LABEL labelspace NUMBER]mpls nhlfe show [key KEY]mpls xc show [ilm_label LABEL ilm_labelspace NUMBER]
mpls labelspace show [dev NAME]mpls monitor ...
Where:CMD := add | del | changeNUMBER := 0 .. 255TYPE := gen | atm | frVALUE := 16 .. 1048575 | / | 16 .. 1023LABEL := TYPE VALUEKEY := 0 for add | previously returned keyNAME := network device name (i.e. eth0)PROTO := ipv4 | ipv6ADDR := ipv6 or ipv4 addressNH := nexthop NAME [none | PROTO ADDR]
FWD := forward KEYPUSH := push LABELINSTR := NH | PUSH | pop | deliver | peek | FWD |
set-dscp | set-exp |set-tcindex | set-rx-if forward | expfwd ... |exp2tc ... | exp2ds ... |nffwd [ ... ] |nf2exp [ ... ] |tc2exp [ ... ] |ds2exp [ ... ] |dsfwd [ ... ]
Figure 2.10: MPLS commands in Linux terminal
8/13/2019 Di Serta Tie 2005
58/120
CHAPTER III
DESIGN AND PROCEDURE
3.1 Introduction
In order to enable MPLS in Linux operating system the right version of kernelmust be installed earlier. In this project, kernel of version 2.6.9 is required. Since this
project used Fedora Core 2 by Red Hat that has kernel of version 2.6.5, the Linux kernel
must be upgraded to version 2.6.9 or above. The next part discussed on how to compile
Linux kernel and so forth.
3.2 Kernel Recompilation
The prefer method of installing a MPLS enabled kernel is to use the RPMs file.
But if the system runs a non-RPM system developers might have to compile the kernel
by hand.
8/13/2019 Di Serta Tie 2005
59/120
41
Section 3.2.1 shows some quick steps how to recompile the kernel whereas in
section 3.2.2 the installation using RPM file is discussed.
3.2.1 Non-RPM System
Below are the steps to recompile kernel. But before the compilation can be done,developers are required to remember what his/her previous Linux config options.
Figure 3.1, Figure 3.2, Figure 3.3 and Figure 3.4 show the kernel options selected after
kernel is patched and before kernel compilation is done.
1) Get Linux kernel 2.6.9
2) Change directory to /usr/src
# cd /usr/src
3) Uncompress/untar linux-2.6.9.tar.gz
# tar -zxvf linux-2.6.9.tar.gz
4) Uncompress or untar mpls-linux-1.946.tgz
# tar -zxvf mpls-linux-1.946.tgz
5) Change directory to linux
8/13/2019 Di Serta Tie 2005
60/120
42
# cd linux
6) Patch Linux kernel for MPLS for Linux
# patch -p1 < ../mpls-linux/patches/linux-kernel.diff
7) Configure Linux kernel to turn on MPLS
# make menuconfig
These are the standard configurations of Linux option. Standard config:
Code maturity level options --->
[*]Prompt for development and/or incomplete code/drivers
Networking options --->
[*]Multi Protocol Label Switching - MPLS
For more advanced traffic mappings (in addition to Standard config):
[*]Network packet filtering (replaces ipchains)
IP: Netfilter Configuration --->
IP tables support (required for filtering/masq/NAT)
8/13/2019 Di Serta Tie 2005
61/120
43
spec_nh target support
8) Compile and install kernel
# make clean; make vmlinux
9) Reboot
# reboot
Figure 3.1: Kernel option before compilation; no MPLS option
8/13/2019 Di Serta Tie 2005
62/120
44
Figure 3.2: Kernel option after compilation; MPLS is selected
8/13/2019 Di Serta Tie 2005
63/120
45
Figure 3.3: Kernel options before kernel compilation; no Special Next Hop option
8/13/2019 Di Serta Tie 2005
64/120
46
Figure 3.4: Kernel option after compilation; Special Next Hop is selected
8/13/2019 Di Serta Tie 2005
65/120
47
3.2.2 RPM System
For RPM supported system, there is only one step must be taken before direct
installation of RPM files. The step is used to test the particular RPM file dependencies.
This is required to check either the system is already has the previous version of desired
RPM file or not. If yes, the upgrade command must be used instead of install command.
To check the file dependencies, test command must be used.
Command usage:
# rpm Uvh - - test
# rpm Uvh
Here are the steps to install RPM files.
1) # rpm Uvh - - test kernel-2.6.9-1.6_FC2mpls_1_946a.i686.rpm
# rpm Uvh kernel-2.6.9-1.6_FC2mpls_1_946a.i686.rpm
2) # rpm Uvh - - test quagga-0.97.3-1.FC3mpls1_946b.i386.rpm
# rpm Uvh quagga-0.97.3-1.FC3mpls1_946b.i386.rpm
3) # rpm Uvh - - test iptables-1.2.11-3.1.FC3mpls1_946.i386.rpm
# rpm Uvh iptables-1.2.11-3.1.FC3mpls1_946.i386.rpm
4) # rpm Uvh - - test iproute-2.6.9-3mpls1_946.i386.rpm
# rpm Uvh iproute-2.6.9-3mpls1_946.i386.rpm
8/13/2019 Di Serta Tie 2005
66/120
48
These RPM files are taken from MPLS package of version 1.946. These files are
prominent to enable MPLS on Linux machine. For example, the first file is needed to
adds MPLS functionality into Linux machine, the third file is used to add support for
SPEC_NH marking while last file is needed to add spec_nh that is a next hop option.
3.3 Kernel IP Forwarding
Before IP packets can be sent into the network, Linux router must be able to
forward IP packets. In Linux kernel, the option of IP packet forwarding is set to 0 by
default. So that, this set up need to be changed to enable IP packet forwarding in the
Linux kernel. There are two ways to set up IP forwarding capability. Initially this
capability can be set up for temporally. That means when the Linux machine restarted
the capability must be set up again. But for the second choice, it can be set up for
permanent. Below are the commands to enable IP packet forwarding.
1) For temporally
# echo 1 > /proc/sys/net/ipv4/ip_forward
2) For permanently
Edit sysctl.config script with this command:
# gedit /etc/sysctl.config
- change ipv4 forwarding to 1 and save the script
8/13/2019 Di Serta Tie 2005
67/120
49
Temporally command also can be used to make it permanently. Simply type this
command to rc.local script and this command will be run by Linux kernel just after
booted. The script can be found at this directory;/etc/rc.d/rc.local.
3.4 Ethernet Card Driver
This project required four routers to be connected to each order. Therefore at
each router more than one ethernet cards have to be assigned. Linux is a different
operating system environment compared to Windows operating system where in
Windows users can plug-and-play the ethernet cards. Current Windows has been
designed to find the ethernet driver within itself without requires users to install it.
Different with Linux since users are needed to compile his/her own driver by
him/herself.
One problem that always occurs in Linux; there is no driver source code for
particular network card. Hence for advanced Linux users, they have to design and
program their own source code.
This project used source code that is available in Internet. The source code has
been designed for Broadcom ethernet card version 5700. Below are the steps to compile
source code from RPM file.
a. Install the source RPM package:
i. # rpm -ivh bcm5700-.src.rpm
8/13/2019 Di Serta Tie 2005
68/120
50
b. Change directory to the RPM path and build the binary driver for Linux
kernel:
i. # cd /usr/src/{redhat,OpenLinux,turbo,packages,rpm ..}
ii. # rpmbuild -bb SPECS/bcm5700.spec
c. Install the newly built package (driver and man page):
i. rpm -ivh RPMS/i386/bcm5700-.i386.rpm
d. The driver will be installed in the following directory:i. /lib/modules//kernel/drivers/net/bcm5700.ko
e. Load the driver
i. # modprobe bcm5700
The version of Broadcom ethernet card driver used is bcm5700-8.1.55-1.
3.5 Assigning Ethernet Device with IP Address
There are two methods available to assign ethernet card with IP address in Linux
operating system. Users can either use ifconfig command or ip route command.
These two commands have to be typed in Linux terminal window that is similar with dos
prompt in Windows operating systems. The next sections discussed on these two
methods.
8/13/2019 Di Serta Tie 2005
69/120
51
3.5.1 ifconfig
This command requires inputs such as device name, IP address, broadcast
address and network mask.
1) Usage :
a. # ifconfig broadcast
netmask
2) Activate device :
a. # ifconfig dev up
3) Example :
a. # ifconfig eth0 10.0.1.1 broadcast 10.0.1.255 netmask 255.255.255.0
b. # ifconfig dev eth0 up
3.5.2 ip route
Differ with ifconfig, this command requires only IP address with prefix length
and device name. It does not require broadcast address.
1) Usage:
a. # ip route add / dev
8/13/2019 Di Serta Tie 2005
70/120
52
2) Example:
a. # ip route add 10.0.1.1/32 dev eth0
To activate device for ip route command, the same method with ifconfig is used.
3.5.3 Assigning IP Address in the Test-bed
The ip route command has been used to assign Linux PC with IP address. The
connection between Linux PCs for the test-bed with ethernet cards assigned to them is
shown in Figure 3.5. R-1 and R-2 functioned as intermediate routers while R-4 and R-3
functioned as edge routers. However R-5 and R-6 are the hosts attached to the test-bed.
Figure 3.5: Test-bed
8/13/2019 Di Serta Tie 2005
71/120
53
Below are IP addresses assigned to Linux PCs. Number of IP addresses assigned
to Linux PCs depends on how many connection they are connected. For example from
Figure 3.5, R-3 is connected to two routers (R-1 and R-2) and two hosts (R-5 and R-6).
So that it requires four ethernet cards and four IP addresses.
1) R-4
a. # ip route add 10.0.1.1/32 dev eth0
2) R-1a. # ip route add 10.0.1.2/32 dev eth0
b. # ip route add 10.0.3.1/32 dev eth1
c. # ip route add 10.0.2.1/32 dev eth2
3) R-2
a. # ip route add 10.0.2.2/32 dev eth0
b. # ip route add 10.0.4.2/32 dev eth1
4) R-3
a. # ip route add 10.0.4.1/32 dev eth0
b. # ip route add 10.0.5.1/32 dev eth1
c. # ip route add 10.0.3.2/32 dev eth2
d. # ip route add 10.0.6.1/32 dev eth3
5) R-5
a. # ip route add 10.0.5.2/32 dev eth0
6) R-6
a. # ip route add 10.0.6.2/32 dev eth1
8/13/2019 Di Serta Tie 2005
72/120
54
3.6 Enabling MPLS
When all Linux PCs are connected with proper IP addresses, then only the MPLS
can be enabled. The command shown is used to enable MPLS. This command has to run
at each Linux PC to change it to be MPLS router.
# echo 1 > /sys/mpls/debug
This command will produce MPLS debug equal to 1 that means MPLS is
already enabled. How the process looked like on Linux terminal is shown below.
[root@TJ-4 root]# echo "1" > /sys/mpls/debug
[root@TJ-4 root]# dmesg
ivering
MPLS DEBUG net/mpls/mpls_output.c:174:mpls_output2: enter
MPLS DEBUG net/mpls/mpls_output.c:192:mpls_output2: opcode PUSH
MPLS DEBUG net/mpls/mpls_opcode.c:117:mpls_push: enter
MPLS DEBUG net/mpls/mpls_opcode.c:131:mpls_push: using gap
MPLS DEBUG net/mpls/mpls_opcode.c:187:mpls_push: exit
MPLS DEBUG net/mpls/mpls_output.c:192:mpls_output2: opcode SET
MPLS DEBUG net/mpls/mpls_output.c:56:mpls_send: output device = eth0
MPLS mpls_skb_dump: from eth0 with len 88 (304)headroom=12 tailroom=28
6e02920088b84d0a01100000{|0003814045000054cd740000400192320a000101
#0a00060200001
dab5a103276114c3643233c000008090a0b0c0d0e0f101112131415161718191a1
b1c1d1e1f20212 2232425262728292a2b2c2d2e2f303132333435363700}
8/13/2019 Di Serta Tie 2005
73/120
55
MPLS DEBUG net/mpls/mpls_output.c:116:mpls_send: mpls_send result 0
MPLS DEBUG net/mpls/mpls_output.c:226:mpls_output2: exit
MPLS DEBUG net/mpls/mpls_input.c:274:mpls_skb_recv: exit(0)
MPLS DEBUG net/mpls/mpls_input.c:228:mpls_skb_recv: enterMPLS DEBUG
net/mpls/mpls_netlink.c:197:mpls_dump_ilm: Dump: idx 1
MPLS DEBUG net/mpls/mpls_netlink.c:197:mpls_dump_ilm: Dump: idx 2
MPLS DEBUG net/mpls/mpls_netlink.c:209:mpls_dump_ilm: Exit: idx 3
MPLS debug = 1
[root@TJ-4 root]#
3.7 Label Switching Path Set Up
After compiling and installing the MPLS enabled version of iproute, there will be
a new command in Linux terminal that is mpls and a new next-hop option for the ip
route command. This part described some examples on how to use mpls and the new
next-hop option available for ip route.
1) # mpls nhlfe add key 0 instrcutions push gen 16 nexthop eth0 ipv4
10.0.1.2
key: 0x00000002 (produced by kernel after upper line is typed)
This line notifies that entry (IP packet) for next hop will be assigned as
label 16 represented by key 0x2 in Linux kernel. This packet will be forwarded
to the next hop with address of 10.0.1.2 through device eth0.
8/13/2019 Di Serta Tie 2005
74/120
56
2) # ip route add 10.0.6.2/32 via 10.0.1.2 spec_nh 0x8847 0x2
This line adds IP routing table in Linux kernel. This route is assigned as
Label Switching Path (LSP) that means all packets that addressed with 10.0.6.2
will follow this route and will be encapsulated with MPLS header label 16.
0x8847 is the ethernet identification of unicast MPLS packets.
3) # mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttlpush gen 16 set eth0 ipv4 10.0.6.2 (0 bytes, 0 pkts, 0 dropped)
This command produced the output that
Top Related