Inter-networking MPLS and SelNet

Andreas WestlingExaminer: Arnold Pears

Supervisor: Richard Gold

2003-10-20

Abstract

The growing amount of traffic on the Internet has lead to regular IP switching tech-nique becoming more and more inadequate. Since more IP switching routers haveto be purchased in order to co-operate with the traffic the costs are rising for theISPs. This has lead to extensive research on how to lower the cost for the end-to-end computation. One of the ways in doing so is to use a tag-switching approach.This thesis will give a brief introduction to two tag-switching architectures, MPLSand SelNet, and show how these can co-operate despite their differences.

Contents

1 Introduction 51.1 Label switching technology . . . . . . . . . . . . . . . . . . . . . 51.2 What is MPLS? . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 What is SelNet? . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Accomplishments . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 82.1 Label switching vs. Datagram Routing . . . . . . . . . . . . . . . 82.2 Ad-hoc routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 MPLS 93.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 LSP control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Ordered Control . . . . . . . . . . . . . . . . . . . . . . 103.2.2 Independent control . . . . . . . . . . . . . . . . . . . . 113.2.3 Loop detection and prevention . . . . . . . . . . . . . . . 11

3.3 LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.1 LDP messages . . . . . . . . . . . . . . . . . . . . . . . 123.3.2 LDP session . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 MPLS forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.1 MPLS multicast . . . . . . . . . . . . . . . . . . . . . . 163.4.2 MPLS hierarchy routing . . . . . . . . . . . . . . . . . . 17

3.5 Code structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.1 MPLS Linux . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2 LDP portable . . . . . . . . . . . . . . . . . . . . . . . . 18

4 SelNet 194.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Overall design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1

4.3 XRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 SAPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5 Code structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Inter-networking MPLS and SelNet 235.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Area of concern . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1 Enabling label switching from MPLS to SelNet . . . . . . 245.2.2 Binding MPLS labels and SelNet SAPF selectors together 24

5.3 Coding effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3.1 MPLS module . . . . . . . . . . . . . . . . . . . . . . . 265.3.2 LDP module . . . . . . . . . . . . . . . . . . . . . . . . 285.3.3 SelNet module . . . . . . . . . . . . . . . . . . . . . . . 315.3.4 Bringing it together . . . . . . . . . . . . . . . . . . . . . 32

6 Testing 346.1 Testbed setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2 Testing TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Testing UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 Testing ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Conclusions and future work 387.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8 Glossary 40

2

List of Tables

1.1 Label Information Base (LIB) from MPLS . . . . . . . . . . . . . 6

3.1 Values in MPLS initialization messages . . . . . . . . . . . . . . 133.2 Tags used in figure 3.4 when V is sending a packet through do-

main A to Z. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 LIB entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 LIB entries for handling Label switching in and out to SelNet from

MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 SAPF table containing redirects and function pointers to use when

callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3

List of Figures

3.1 Exponential growth of labeled paths. (paths from and to one nodeonly is shown here) . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Session Initialization State transition diagram from RFC 3036 . . 153.3 Multicast scenario with MPLS . . . . . . . . . . . . . . . . . . . 163.4 Hierarchy of routing knowledge . . . . . . . . . . . . . . . . . . 18

4.1 Remote patching when host A is looking up host C . . . . . . . . 204.2 The SelNet architecture . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Desired MPLS and SAPF paths . . . . . . . . . . . . . . . . . . . 235.2 label translation from MPLS to SelNet . . . . . . . . . . . . . . . 255.3 label translation from SelNet to MPLS . . . . . . . . . . . . . . . 255.4 Modified XRP message with virtual IP address included . . . . . 315.5 Packet flow when sending a ICMP ping from a SelNet node . . . . 33

6.1 Test environment setup. . . . . . . . . . . . . . . . . . . . . . . . 356.2 Screen-dump from ethereal showing traffic when sending UDP

packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Screen-dump from ethereal showing MPLS labeled ICMP ping

packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4

Chapter 1

Introduction

Label switching or tag switching has been a hot topic in the research-world sincethe ATM architecture was introduced in the beginning of the 1990’s. This technol-ogy has several advantages over regular IP routing, such as higher speeds, moreflexibility, better scalability etc. These advantages have been gracefully acceptedby the Internet community and Internet Service Providers as a means for overcom-ing the obstacles that the regular IP forwarding introduced as the requirementsincreased in respect to speed and scalability.

1.1 Label switching technology

The idea of label switching is an old concept, used already in the first telephoneswitches. The goal is to establish a labeled path from the source to the destina-tion. The path is created once and then used for directing the traffic through thenetwork. When the path is created each packet will carry a label telling the nexthop router how to act and where to redirect and possibly duplicate the packet. Thealgorithm used for looking up a local label is faster than the regular IP routing al-gorithm since the information can be indexed in a better way and the switch doesnot have to hold as much information as the router. A label switch router can thusachieve greater throughput as well as higher flexibility.

1.2 What is MPLS?

MPLS, or Multi Protocol Label Switching is a label switching protocol that workson top of more than one Link layer protocol, in contrast to ATM. The goal ofMPLS is to remove the process of looking into the level 3 header in each hopalong the path. This enables wire-speed lookup and gives network trunk card

5

vendors an option to produce cards that only understand MPLS labeled packets,which will reduce the overall cost.

In order to achieve this goal a label is added to the packet when it enters aMPLS enabled network. This label identifies an action in the next hop LabelSwitch Router (LSR) telling it how to forward the labeled packet. When the packethas reached the boundary of the MPLS enabled network the label is removed andregular IP routing is performed at point.

The actual MPLS routing is done via a Label Information Base (LIB) that con-tains the incoming label and a number of outgoing segments with their outgoinginterfaces. In this way giving more than one outgoing label can create a multicastroute. The labels are distributed with an separate protocol such as the LDP (La-

In Array of out-segments

Incoming label Outgoing label Outgoing label ...Outgoing interface Outgoing interface ...

Table 1.1: Label Information Base (LIB) from MPLS

bel Distribution Protocol). The LDP includes functionality for traffic engineeringand fast repair if a router inside the network goes down. The protocol can run intwo different modes, one where a central Label Manager requests labels (OrderedControl) and the other one where the LSRs act on their own and send out labelmappings at any time (Independent control). This will be described in more detailin section 3.2

1.3 What is SelNet?

SelNet is an architecture that aims to create an abstraction layer that uses net-work pointers, or selectors as it is called to locate resources in a remote client.LUNAR (Lightweight Underlay Network Ad-Hoc Routing) is an application thatuses some of the concepts that were presented in the SelNet architecture. LUNARis used to perform ad-hoc routing between a small group of wireless clients, mean-ing that traffic can be routed through an intermediate client in order to reach thedestination if the destination is out of reach. The architecture inserts extra func-tionality between network and the link layer in the IP stack while leaving the restunchanged. SelNet builds a virtual network with the reachable nodes and the extrafunctionality is responsible for the routing and works in such a way that the abovelayers are unaware of the routing. SelNet uses a protocol called XRP (eXtendedResolution Protocol) to lookup hosts and reply to lookups. The ad-hoc routinginside the SelNet cloud is done by “remote patching” the neighbor, telling it thatit should route traffic to the destination. The “remote patch” is called a wormhole

6

and each wormhole is identified by a SAPF-selector [1] (Simple Active PacketFormat).

1.4 Goals

The work presented in this thesis were made to make the two protocols, SelNetand MPLS to seamlessly co-operate with each other. The SAPF selector and theMPLS label are both identifying a local operation in some way, and the protocolsto distribute them, LDP and XRP, have the same goals and methods. With this inmind a middle-ware that uses both protocols and does all translation is, in theory,simple.

1.5 Accomplishments

The running prototype that was created has a light-weight LDP-engine that com-municates with an real MPLS/LDP enabled switch running MPLS-Linux andLDP-portable [2]. A light weight LDP-engine was implemented and incorporatedinto the existing SelNet code and an API for the LDP part was also implemented.The program works in such a way that the clients on either side can initiate apath through the other network without knowing about the translation to and fromMPLS labels and SAPF selectors.

1.6 Overview

The organization of this thesis is as follows. In chapter 2 a brief background tothe thesis is presented. This is followed by a chapter on the theories of MPLS andhow it work in chapter 3. In chapter 4 the goals and achievements of the SelNetarchitecture are discussed.

Chapter 5 covers the work done in the project in order to combine the MPLSprotocol with SelNet. The testing of the prototype software is presented in chapter6 along with some comments on the results. Comments about the project andfuture work can be located in chapter 7.

7

Chapter 2

Background

2.1 Label switching vs. Datagram Routing

Every router on a network and in the Internet has a certain amount of state in orderto know about its surroundings. In the case of datagram routing this state is vastand difficult to handle in an efficient way. In addition to this the datagram routingneeds to look into the level three header which increases the computational costof routing a packet. The label switching technology is a way of making the statein the node easier to use and keep up-to-date.

Further benefits of label switching technology are possibly increased speedand the chance of reducing the cost on the hardware of the switch. On the otherside of the coin is the increased complexity associated with the label distributionprotocol, but this is an equal drawback on the datagram switching side as it re-quires protocols like BGP, OSPF and similar. In addition to this the concepts oflabel switching is a first vital step towards creating completely optical networks.

2.2 Ad-hoc routing

Ad-hoc routing is a hot topic in current computer network research. The increasedamount of wireless networks and hosts have made things even more interesting.Ad-hoc routing aims to give a group of wireless hosts the means to extend therange of the signal of a single host by allowing it to use other hosts to forward itstraffic in order to reach the destination. The complexity that is introduced therebyis how to find the best path and how to know that this path is the best one overtime since the topology of the wireless network can change quickly.

8

Chapter 3

MPLS

MPLS evolved from a set of similar techniques that were developed in the mid-1990s. The most well know of these were called IP-switching [4] invented byIpsilon. Several other companies also published similar schemes such as TagSwitching [5] by Cisco, IBM’s Aggregate Route-based IP Switching (ARIS) [6]and Toshiba’s Cell Switch Router (CSR) [7]. All of them use a simple label swap-ping technique to forward data and the already established control protocols suchas OSPF and BGP.

The Internet Task Force (IETF) then assigned a team to create a unified proto-col that would use the best of all of the above protocols and make this a standard.The team consisted of representatives from all of the above companies and sinceno one should be favored of the name of the protocol the name MPLS was chosen.

3.1 Goals

The goal of MPLS is to reduce the need for IP routing and replace this with thetechnology, faster label switching. MPLS is designed so that it can work on top ofany link layer protocol, including ATM. As mentioned before, doing IP routing iscomputationally expensive since each packet on every router has to be investigatedand a routing algorithm must be executed in order to find the next hop.

MPLS is also designed with scalability as a goal. As networks grow and moreswitches are inserted this should not flood the network with routing-informationthat has to be exchanged. The amount of routing information should not increaseby an exponential factor as shown in figure 3.1, but a linear factor.

9

Figure 3.1: Exponential growth of labeled paths. (paths from and to one nodeonly is shown here)

3.2 LSP control

The labeled path through a MPLS can be established in two different ways, or-dered control and independent control. Each of these has its advantages and draw-backs and therefore the MPLS architecture eventually settled on allowing both.

3.2.1 Ordered Control

In the ordered control mode the LSP (Label Switch Path) is created from theingress LSR or the egress LSR. The ingress LSR is the LSR that first receives theunlabeled packet while the egress LSR it the one that converts a labeled packet toa regular IP packet. This approach increases the overall complexity but has theadvantage of making loop detection easier, as well as giving the network admin-istrator greater control over the labeled paths. The biggest drawback is while thepath is propagated over the network all incoming packages have to be dropped orprocessed using regular IP routing algorithms.

10

Downstream on Demand Label Advertisement

In this mode label bindings can only be sent if a next-hop node has requested thelabel in question. The path is created from egress to ingress LSR.

Downstream Unsolicited Label Advertisement

This is the mode where a LSR can send a label mapping without being asked forit from the next-hop node. The path is created from the ingress LSR to the egressLSR.

3.2.2 Independent control

In independent control any LSR can make an independent decision when rec-ognizing a Forward Equivalence Class (FEC) to bind and distribute a new labelto the connected peers. This corresponds to the way that conventional datagramrouting works; each node makes an independent decision about how each packetshould be treated, and relies on the routing algorithm to converge rapidly in orderto ensure that each datagram is correctly delivered. The drawbacks of this controlmode is that there is a possibility for the LSRs in the network to be misconfig-ured so that they make different decisions when binding a FEC. The result mightbe that no label switched path can be created for some FECs. However, since aLSR does not have to wait for acknowledgment the network will converge fasterin independent control than ordered control.

3.2.3 Loop detection and prevention

Loop detection and prevention is a big concern in a label switched network. If aloop would occur in the network the risk is that the packages flowing in the loopwill prevent the LSRs from propagating routing information and thus the networkwill never converge to a functional state. There are two ways of preventing thisbehavior.

Loop prevention Prevent the forming of loops before any packages are sent onthe labeled path.

Loop mitigation If a loop has occurred take steps to minimize the effect on thenetwork.

Since some IP protocols can not prevent the formation of transient loops, IPforwarding has a mitigation approach with the time-to-live (TTL) field inside thepacket. The TTL is decremented at each hop and when the counter reaches zero

11

the packet is assumed to be trapped inside a loop and is thrown away. By doingthis the routers forming the loop will not be overwhelmed with the flow of loopingpackages and there will be enough bandwidth for exchanging and updating routingtables. Once the routing tables are stable the loop should be broken.

In MPLS a similar approach can be applied in many situations. The MPLSlabel structure that is appended to each packet might carry a TTL field just forthese purposes. However, since MPLS is designed to co-exist and co-operate withATM this imposes a new difficulty here; the ATM switches do not support thisTTL-field. This problem can, however, be solved in a number of different waysbut this is beyond the scope if this thesis.

3.3 LDP

The Label Distribution Protocol [8] is the most complex part of MPLS. The LDPshould take care of installing, distributing and keeping the labels updated in allLSRs in the network. Besides this the protocol has the responsibility to preventloops that could arise inside the MPLS network.

3.3.1 LDP messages

This section will cover the design of the messages and the three groups of mes-sages that exist in the LDP RFC document. All of the messages are exchangedbetween a local and a remote LDP session via a TCP connection.

TLV encoding

Every message and almost all of the components in the messages are encoded ina Type, Length, Value standard. The LDP TLV is encoded as a 4 octet field thatuses the first 2 bits for specifying the behavior when a LSR does not recognize thefollowing type. The following 14 bits is the type and this is followed by a 16 bitfield containing the length.

The TLV encoding provides flexibility for future enhancements and providesbackward compatibility at the same time.

Initialization messages

This group of messages are used to handle the initialization procedure as describedin section 3.3.2

The Hello message is sent at a fixed frequency and is used for other LSRsto find this LSR. The message is sent to a broadcast group with the address of

12

224.0.0.2 with port 646 and all connected LSRs can pick up these messages. Anextended version of discovery mechanism might be used too, allowing LSRs thatare not directly connected to discover the LSR.

The initialization message can negotiate a number of parameters between thetwo sessions. The message comprises a number of mandatory parameters and aset of optional parameters.

Mandatory ParametersKeep-Alive time The time in seconds before the session and all

related is deleted.Label Advertisement Disci-pline (A)

Indicates the type of label advertisement thatshould be used. 0 means downstream Unso-licited and 1 means Downstream On Demand.

Loop Detection (D) This bit requests that the loop-detection algo-rithms to be turned on. Note that in orderto loop-detection to work, all MPLS enabledswitches in the network must have this enabled.

Path Vector Limit (PVLim) Set the maximum number of Path Vectors.Max PDU length The maximum length that a LDP packet should

have in this session.

Optional ParametersATM session Parameters Used when an LDP session manages label ex-

change for an ATM link to specify ATM spe-cific session parameters. (The contents of thisTLV is beyond the scope of this thesis)

Frame relay Session Parame-ters

Used when a LDP session manages label ex-change for a Frame Relay link to specify FrameRelay-specific session parameters

Table 3.1: Values in MPLS initialization messages

The address and address withdraw messages are used to announce the activa-tion and deactivation of a local interface of an LSR. The message contains at leastone address in an array of interface addresses.

Keep-alive message

In order to tell the remote LDP session that the local session is still alive a specialkind of messages are sent between the two sessions. The KeepAlive time specifiedin the init-message and other LDP messages determines the frequency of these

13

messages. If a LDP message has not been sent during the KeepAlive time thiswill trigger a KeepAlive message to be sent.

Label related messages

The label messages group is composed of messages used to make operations on alabel such as label-mapping, label-request, label-withdraw and label-abort.

The label mapping message is used when a label is propagated through thenetwork. The message will contain a FEC with addresses or prefixes that shoulduse the following label. The message can also contain a number of optional pa-rameters giving the remote LSR more detailed information on how to handle thislabel and the related packages given by the FEC.

When the LSR is running in ordered control it will have to request labels fromthe surrounding LSRs. This message is used for this purpose and it is comprisedof a FEC TLV with the addresses and/or prefixes and a number of optional pa-rameters. The label request message might be sent if under any of the followingconditions:

� The LSR recognizes a new FEC via the forwarding table and the next hopis a LDP peer.

� The next hop for the FEC changes and the LSR does not already have amapping from that next hop for the given FEC.

� The LSR receives a Label Request for a FEC from an upstream LDP peerand the next hop is a LDP peer.

The label withdraw message is used to remove a label binding from the net-work. The withdraw message is triggered by any of the following conditions:

� The LSR no longer recognizes a previously known FEC for which it has anadvertised label.

� The LSR has been reconfigured and the FEC that were previously advertisedFEC should no longer exist.

If a LSR discovers a loop when receiving a label request it will report this tothe LSR that sent the label request by sending a label abort request message. Thismessage will contain the FEC list that were in the received label request message.

14

3.3.2 LDP session

Each LDP session is identified by a LSR-id and the current labelspace. The la-belspace is a number that is incremented on creation of a new session, giving theguarantee that all sessions can be distinguished from each other in the network.

Session initialization

Figure 3.2: Session Initialization State transition diagram from RFC 3036

15

3.4 MPLS forwarding

When a regular packet arrives at a MPLS network the ingress router uses thedestination address field in the packet to assign it to a FEC. Assuming that theMPLS enabled network is configured to route this packet and that the next hopnode is a MPLS enabled router, the FEC will be associated to a label, an outgoinginterface and the next hop. The switch will then use this label and insert a MPLSshim structure to the packet and then send it out on the given interface.

When the in-transit MPLS switch picks up the packet it will investigate theMPLS shim structure and find a label. This Label Information Base is searchedfor this label and a new label is found together with the outgoing interface andnext hop. The old label is overwritten with the new label and the packet is sent tothe next hop switch.

This procedure will continue at each hop until an egress router receives thepacket. The egress router will do the label lookup and find a empty entry thatindicated that the shim structure should be stripped from the packet and regular IPforwarding will be used at point.

3.4.1 MPLS multicast

Since every router inside the MPLS enabled network has a state associated witheach label a multicast group can be created with a small amount of additional labelbinding information. Recall that a LIB-entry can have a vector of outgoing labelsand interfaces attached to an incoming label. This feature is used in the multicastcase to insert extra forwarding semantics into a MPLS router, telling it to forwardthe packet to several destinations. In figure 3.3 the MPLS route B will have an

Figure 3.3: Multicast scenario with MPLS

entry with incoming label from A and out entries as A,C,D,E,F and G along withthe outgoing interfaces at which they can be reached.

16

3.4.2 MPLS hierarchy routing

One of the design goals of MPLS is to improve the scaling properties of the rout-ing system. This goal is addressed via the notion of hierarchical routing knowl-edge. The hierarchical routing knowledge is used in regular IP switching wherethe routers can be divided into intra-domain and inter-domain classifications.

Intra-domain routers route packages within the local domain meanwhile inter-domain routers route packages across multiple domains. One of the advantages ofthis approach is the reduction of routing information that has to be maintained byrouters.

However, the partitioning done at the level of routing protocols is simply notenough to achieve complete partitioning of the routing information. For instance,the routers in a transit domain (a domain that carries traffic that neither originatesin the domain nor is destined to a node in the domain) have to know about all theroutes provided by the inter-domain routing, regardless if it is an interior router ora border router. The routing information from the inter-domain routers is neces-sary in order to forward the transit traffic through the domain.

The use of hierarchical routing information in MPLS removes the need forinterior routers to know about the inter-domain routing information. The inte-rior routers no longer have to keep routing information about the whole Internet,just the internal domain. The result of this is faster routing convergence in bothintra-domain and inter-domain routers. Another result of maintaining hierarchi-cal routing information is better fault isolation as the internal routers do not haveto bother about the state of external routers. Faster convergence and better faultisolation would result in improved scalability of the routing system.

MPLS achieves all this by using the label stack in the packet. When a packet isforwarded from one domain to another, the packet is only given one label. How-ever, when the packet is forwarded over a transit network the stack will containseveral labels and only the top label is used until the transit domain is crossed andthe topmost label is popped from the stack.

3.5 Code structure

This section briefly explains how the software that were used in this exjobb isorganized. The MPLS software consists of two parts, first there is the MPLS partthat takes care of the MPLS packet switching. In addition there is a LDP softwarethat feeds the local routing table with label bindings that it has got to know aboutusing the LDP protocol.

17

Figure 3.4: Hierarchy of routing knowledge

Node Incoming tag Outgoing tag next hop tags on packet

Node V 1 5 LSR T 5Node T 5 10,2 LSR X 10,2Node X 10 12 LSR Y 12,2Node Y 12 17 LSR W 17,2Node W 17 N/A (pop) 2Node W 2 6 LSR Z 6Node Z 6 100 ? 100

Table 3.2: Tags used in figure 3.4 when V is sending a packet through domain Ato Z.

3.5.1 MPLS Linux

The MPLS-Linux is developed by James R. Leu as a kernel “module”. The kernelis first patched with the MPLS-linux code and then recompiled in order to activatethe MPLS forwarding plane. A patch to the ip route command is also suppliedgiving the user means to manually add a LSP to the local routing information.

3.5.2 LDP portable

The LDP-portable is the LDP part of the MPLS suite. It is integrated into the zebra[3] routing platform. The LDP runs as a daemon that can be configured via theldpd.conf files or the zebra Command Line Interpreter (CLI) via telnet. The zebraCLI is used for modifying the configuration of a LSR and for getting informationabout the current label bindings that has been exchanged with neighbor LSRs.

18

Chapter 4

SelNet

SelNet [9] is an architecture that was recently developed at Uppsala university.The architecture uses tags called selectors to locate functions in a remote client.The SelNet architecture has taken many of the best properties from other ad-hocrouting work-groups and label routing architectures such as the MANET working-group [11] and MPLS [13].

The result is a very small and flexible architecture that uses label switchingtechnology to insert extra routing functionality into a client.

4.1 Goals

The goals of LUNAR are to provide an Ad-hoc routing environment for smallgroups of wireless hosts that want to participate in a virtual network in an easyway. The architecture was designed so that minimal configuring should be nec-essary before startup of the software and the rest of the configuration should bedone at run-time. Once a SelNet client has been started it will join the host ontoa virtual network at the default network of 192.168.42.0/24. Once some traffic issent the packages are picked up and routed towards the target, if the target can notbe reached in one hop. SelNet does all this by inserting the required functionalitybetween the link layer (layer 2) and the protocol layer (layer 3). The new layer,that is said to be at level 2.5, will allow the above layers to keep its assumptionsabout the network, thus being unaware of the ad-hoc routing that might occur.

4.2 Overall design

In the SelNet architecture a tag is called a selector and besides representing aforwarding function the selector can also represent a computing function. Theselector is purely a local resource with no global meaning. The encoding of the

19

selector is the approach taken in the SAPF [1] architecture. The selectors arecreated by a host and might then be distributed by via the eXtensible ResolutionProtocol (XRP).

When a SelNet host wants to start sending packages it starts by looking up thereceiving host via a XRP lookup request. This request is propagated through thenetwork while leaving a trail of reply-functions on each and every host. When thedestination is reached the reply-function that were sent by the neighbor SelNetclient is used to send a XRP reply to the originator. The traffic that then is sent bythe originator are given the selector received in the reply from the next-hop node.

Figure 4.1: Remote patching when host A is looking up host C

In figure 4.1 an example of how the lookup is performed inside the SelNet vir-tual network. It start with host A that initiates a lookup of host C. The lookup issent to host B along with a reply selector that is going to be used when the host isfound and reply is going to be sent. Host B at this case will continue to propagatethe lookup to host C. Host C creates a selector to deliver packages to the IP stackand sends this selector in a reply back to host B with the reply-selector given byB. When B receives the reply it finds out that the reply-selector is associated withthe selector given by A. The selector in the reply, B is replaced with the selectorgiven by A and then the packet is sent to A. When A now received the reply thepath to C is complete and ready to be used.

20

4.3 XRP

The XRP messages that are used to perform host lookup and several other tasksare composed of a number of ASCII-commands. Each command is executed onthe receiving host and the XRP works in such a way that the commands can triggerremote side-effects on the receiving host. When a XRP command that will triggera reply on the receiving host is sent, the sending host must first create the reply-channel that should be used for this reply. This reply-channel is created by givingthe selector that the reply is expected on and the ethernet hardware address in acommand prior to the reply-generating command. An XRP command can consistof a combinations of the following parameters:

scheme The requested address-resolution family.id The name that should be resolved.resolution style Indicate what type of reply to the resolution

that is expected.wh The selector that should be used when sending

a reply to the originator of this XRP message.resolution depth The number of hops that should be flooded

with this XRP request.ser Identifies the XRP request.

In figure 4.1 the following XRP message is sent from host A when it issuesthe lookup of host C.JEX LOOKUP IDscheme=sapf;id=LOOKUP ID;wh=0scheme=sapf/eth;id=HOST A SEL/HOST A HW;wh=HOST A REPLYscheme=ipv4;id=HOST C IP;rs=sapf/eth;rd=3;ser=LOOKUP ID

The first command, the JEX is used to avoid processing the same XRP requestseveral times. If the selector LOOKUP ID does exist the rest of the commandswill be ignored. The second command creates a redirect from the LOOKUP ID toa fixed selector with value 0 that is used to throw commands away. The third com-mand installs the reply-channel while the fourth command is the lookup requestof IP address HOST C IP with max resolution depth 3.

21

4.4 SAPF

The SAPF selector has a fixed length of 64 bits. All used selectors are locatedthe fib-structure as a hash table so that they can quickly be located. Each selectorin the fib can be redirected to another selector or a callback function along withsome arguments. When the packet is sent with a SAPF selector the selector willbe located between the link layer header and the protocol header.

4.5 Code structure

Figure 4.2: The SelNet architecture

SelNet creates a new, virtual interface, tun0 and manipulates the routing tableso that all traffic will go through this interface. Netbox is a module inside SelNetthat will add hooks inside the Linux kernel so that it can pick up the packages sentto the IP stack. If the packet were sent to the tun0 interface the packet will be sentto SelNet. SelNet will insert the correct selector and send this packet out on theeth0 interface. However, if an ARR packet is picket up by the netbox this packetwill trigger an XRP request instead.

22

Chapter 5

Inter-networking MPLS and SelNet

In this chapter the issues and problems of inter-networking MPLS and SelNet willbe explained. The chapter will begin with the motivation why this project wascreated, followed by a section that covers some of the concerns that arose.

The rest of the chapter covers the different modules and their sub-modules inmore detail. The last section explains a scenario where a SelNet client start to pinga host in the MPLS network and explains how the packages are sent and what thedifferent hosts do.

Figure 5.1: Desired MPLS and SAPF paths

5.1 Motivation

The SAPF selector and the MPLS label are very similar with respect to the factthat they both represent a state in a remote note. In the case where a SelNet clientinitializes a packet flow to a destination that is several hops away it seems to thesource that the destination could be reached directly. In other words, as long asthe destination is within the maximum hop limit the source does not have to careabout doing any special computation and packet handling to reach the destination.

The theory behind inter-networking MPLS and SelNet is that neither of theprotocols should be aware that a translation has been performed at the intersectionof the two networks.

23

5.2 Area of concern

A concern that arose was the MPLS labeled path back to the SelNet client. InSelNet the mapping of labeled paths are 1 to 1, with respect to that one SAPFselector identifies one remote client, this has to be translated to the MPLS networktoo. The standard procedure in a MPLS network is that one MPLS label representsa whole network with all its clients. This is clearly not good enough since thiswould require additional checking in the IP header for the destination address andthen it simply is not label switching any more.

5.2.1 Enabling label switching from MPLS to SelNet

As mentioned previous, the standard approach in a MPLS network is not to mapa label to a host but to map a label to a certain subnet. As this approach is notgood enough when interacting SelNet with MPLS the MPLS network has to beforced to map labels to SelNet clients. This was done by sending label mappingmessages to the next hop router telling it to map a label with prefix length of 32.Since this label will be propagated to the destination the ingress MPLS router willuse this label when sending to the packet through the MPLS network.

The label used to send the packet to the MPLS network is obtained by the nexthop MPLS switch. In case no label exists to the subnet a label request messageis sent to the next hop switch and the packet is dropped. When the label mappingmessage is then received and the next package arrives this new label binding to thedestination network will be duplicated and modified to point at the specific hostrequested earlier. The duplicated message will contain the same out-label and thein-label will be a permanent SAPF-selector as discussed in the previous section.

In Destination / mask length Out�����[MPLS] ���� � ��� �� � ����� � [SAPF]

[UNASSIGNED] ����� ����� ��� ����� � �!��" #$�%� �'& ��� [MPLS]� ��� [SAPF] ����� � ��� �� �'& ��� [MPLS]

Table 5.1: LIB entries

5.2.2 Binding MPLS labels and SelNet SAPF selectors together

Since the SelNet SAPF selectors are highly volatile an intermediate step has tobe introduced in the translation to and from MPLS labels. This intermediate stepconsist of another SAPF selector, but this one is set to be permanent so that SelNetdoes not remove it. The permanent SAPF selector is the one that is inserted in theLIB together with the MPLS label.

24

Figure 5.2 shows the translation steps made when a non-SelNet package hasbeen picked up. Figure 5.3 show the steps taken when a SelNet package is crossingthe border to the MPLS network.

������� ��� �����// � � # � �� �� # �

�� ���� �// � �%��� �%����� �� ���� �

// # � � �%�� � �Figure 5.2: label translation from MPLS to SelNet

� � # � � �%�� � � # � � #����!�%�� ����oo � �%��� �%�����

� ��� �oo ������� ���

� ��� �oo

Figure 5.3: label translation from SelNet to MPLS

In Destination / mask length Out�����[MPLS] ���� � ��� �� � � ��� � [SAPF]

� ��� [SAPF] ����� � �� �� �'& � � [MPLS]

Table 5.2: LIB entries for handling Label switching in and out to SelNet fromMPLS

In type redirect or callback note

� & �"! REDIRECT � ����� � PERMANENT� ����� � CALLBACK l2sendto VOLATILE� � � � REDIRECT � � � VOLATILE� � � � CALLBACK mpls deliver PERMANENT

Table 5.3: SAPF table containing redirects and function pointers to use whencallback

5.3 Coding effort

Since the software in this exjobb is a hybrid between MPLS/LDP and SelNetthe thought was that it would be best to incorporate one of these into the other.Since MPLS-Linux that does take care of the actual MPLS forwarding is a kernelimplementation, the alternative of integrating SelNet into this software clearlywas not an option. The remaining alternative was then to use SelNet as a platformand build MPLS and LDP into it. The initial plan was to use the code from theLDP-portable and to get the LDP engine for free.

25

When digging into the LDP-portable it became clear that this path would bealmost impossible since the amounts of comments and structure is almost non-existent. It became clear that a LDP-engine had to be re-built from the scratch.The only code that could be re-used from the LDP-portable were the modulescontaining the structures that is being sent over the wire and some functions fordecoding and encoding these structures.

Since the final application will consist of several servers handling LDP peri-odic messages, LDP server, LDP sessions and the SelNet client a multi-threadedapproach was chosen. This however created a new problem since there are a num-ber of vectors shared between all these threads and this data should of course beprotected so that two threads can not tamper with, for instance, a vector at thesame time. In order to handle this in a clean way a new vector template was cre-ated that includes a Posix mutex lock to grant one thread exclusive access to avector.

5.3.1 MPLS module

The MPLS module is fairly small and mainly consists of the LIB-list and a LIB-entry class, the MPLS-shim, the generalized label used for handling both MPLSlabels and SAPF selectors and the mpls deliver functions that handles non-SelNetpackages and providing callback functions when receiving a SelNet package thatshould go out to the MPLS network.

The LIB has some changes from the original specification and now has toinclude SAPF selectors in all the entries. A simplification to the LIB has beenmade since the multicast functionality of MPLS should not be handled. Hence theoutgoing array of labels has been replaced with just one label or SAPF selector.

Generalized label, label. � cc, h �A generalized label had to be invented to handle both MPLS labels and SAPFselectors. The label has the following structure and was coded as a class of itsown.

class label �unsigned int labelID;identifier MPLS identifier;sapfsel t selector;label type t type; // UNASSIGNED, MPLS or SELNET... (functions)

� ;

26

When the label is of type MPLS the labelID and the MPLS identifier is used todetermine if the label is a local label or a label given by a remote LSR. In the casewhere the label is representing a SAPF SelNet label the type is set to SELNETand the only field that is initialized is the SAPF selector.

Label Information base, lib. � cc, h �The LIB used in the application is using the generalized label that can representboth a MPLS label and a SAPF selector. This gives the required flexibility so thata SAPF selector can be translated to a MPLS label and vice versa. In additionto this each LIB-entry contains the information from the FEC namely the targetaddress and the prefix length. If the prefix length is 32 the target’s address pointsto a host else the target address is a subnet that could be reached through thislabel. It is worth noting here that when the out-label is of type SELNET the targetaddress should refer to a host, not of the SelNet virtual subnet.

class LIB-entry �label inLabel;label outLabel;unsigned int target;unsigned char targetLength;... (functions)

� ;

Non-SelNet traffic switching, MPLS deliver. � cc, h �Two functions are advertised in the header file that should be used by the rest of theprogram; mpls DELIVER and mpls HANDLE. The first of these, the mpls DELIVER,is called when a SelNet package is redirected to a MPLS label. In this case thefunction has been added as a callback, along with the permanent selector thatpoints to the MPLS label. (Read more about this in Section 5.3.4)

The other function, mpls HANDLE is used when an packet is picked up with-out the SAPF ether-type of value 0x4242. This function will take different actionsdepending on the type of the packet.

In the case where the packet is carrying a MPLS label the LIB is searchedfor the label attached to the packet. If the lib-entry has an outgoing label of typeSELNET the label is stripped away from the packet and the packet is sent toSelNet together with the SAPF selector inside the outgoing label. If the outgoinglabel is of any other type the label is removed from the packet and the packet issent out to the interface in the hope that someone else knows what the packet isfor.

27

If the incoming packet is a regular IP-packet the destination address is re-trieved and the LIB is searched for the best match to this address. If the IP isresolved on the SelNet side the packet is sent to SelNet along with the SAPF se-lector that could be found in the result from the search in the LIB. This case wascreated since the MPLS-forwarding of the MPLS-Linux/LDP-portable softwaredoes not work at all, and hence is sending regular IP traffic back to the middle-ware.

5.3.2 LDP module

A substantial amount of work has been done in order to get a working LDP sessionestablished to a remote LDP-portable enabled host. As mentioned earlier the LDPprotocol is vast and has many subtle features that made implementation hard. Thefirst problem that arose was the decoding and encoding of the messages.

Encoding and decoding messages, ldp decenc � .cc, .h �All of the messages that are sent are passed through an encoding function and areall received through the decode function. These functions translate all values tonetwork byte order when encoding and to host byte order when decoding. Thismodule uses the functions in the file ldp nortel � .cc,.h � .

Periodic send thread and ldp-server, ldp � .cc, .h �This is a thread that will send out ldp hello messages as well as ldp keep-alivemessages. The ldp hello messages are used by the a LSR to identify the remoteLDP-session and gives the mean to determine if the LSR should act as a active orpassive server. In case the announced id in the hello message is bigger than the idof the local LSR is supposed to play an active role and a ldp session is created tothe remote LSR.

The LDP keep-alive messages are needed in order to keep the created sessionsalive when they are created. Both the hello messages and the keep-alive messagesare sent every 5th second, ignoring all the settings that can be introduced in aldp init package.

The LDP server is very simple and the sole meaning of its existence is to acceptconnections. When a connection is received the list of known LSR:s obtained bycollecting hello messages is searched. If a matching hello has been received aldp session is created, otherwise the socket is closed.

28

LDP identifier, identifier � .cc, .h �In the LDP specification a LDP identifier consists of the LSR id and the la-belspace. The LSR id is a 4 octet long value given to the LSR in the case whereordered control (See section 3.2.1) is used. In the case where independent control(Section 3.2.2) is used the id is retrieved from one of the interface-addresses. Thisidentifier is required to have this extra information about the label space since apair of LSR should be able to establish several sessions to each other.

In the software a class has been created in identifier � .cc, .h � and it has beendesigned to be in use with independent control only.

LDP session, ldp session � .cc, .h �This is by far the biggest sub-module within the LDP module. The ldp sessionclass will, upon creation check if it is supposed to act in an active or passivemode. In the active mode case it will try to connect to the remote LSR and thenstart the initialization of the session. The ldp session will also create anotherthread, handling all the messages sent to the session.

When the session is initialized there is a strict protocol that has to be followedas described in section 3.3.2.

Once the initialization is established and the state is set to OPERATIONALthe local LSR announces the local interfaces by sending an address message. Thisaddress message will contain every interface along with the length of the netmask.Once this message is sent label mapping messages of the different network inter-faces is sent to the remote node along with the corresponding label. In the casewhen SelNet is started there will be at least 2 interfaces. First there is the regularinterface e.g. eth0 and there will be the tap0-interface created by SelNet.

When a label mapping message is sent or received the label along with thenetwork address and network mask length is stored in the LIB.

LDP message buffer ldp buffer � .cc, .h �When a message is sent and received a special buffer is required in order to use thedecode and encode functions from LDP-portable. This class represents a bufferwith a current pointer that can be moved inside the allocated memory. When adecode function decodes a structure it will move the current pointer forward sothat the next function will start to decode the correct memory.

LDP api, ldp api � .cc, .h �This module contains functions for looking up and creating a path into the MPLSnetwork. It is called by the function that resolves IP version 4 request sent by a

29

SelNet client inside the XRP module. The desired bindings in the LIB and in theSAPF table are the ones described in Section 5.2.2.

The procedure of creating the paths is best described by the following pseudo-code:

function fix path(dst ip, src ip, src sel reply, src sel send)lib.lock()in from mpls = lib.search(src ip)out to mpls = lib.search(dst ip)lib.unlock()if( !out from mpls OR out from mpls->InlabelType != SAPF )

// no path exist to dst or path is not SAPF to MPLS typeif( !out from mpls )

session = find next hop for ip(dst ip)if( session )

// request path to destinationsession->LabelRequest(dst ip)drop packet = true

else// create pure SAPF to IP routeout from mpls = lib entry( in=SAPF permanent,

target=dst ip/32,out=UNASSIGNED )

// add label and bind callback-functionsapf addCallback( SAPF permanent,

mpls DELIVER ,arguments )

lib.add(lib entry)else // A path exists, but is not SAPF to MPLS type

out from mpls = lib entry( in=SAPF permanent,target=dst ip/32,out=out to mpls->Outlabel )

// add label and bind callback-function... (omitted)

if( out to mpls AND out to mpls->InlabelType == SAPF )// Create redirect from volatile SAPF to permanent// SAPF as described in Figure 5.3sapf REDIRECT( src sel send, out to mpls->Inlabel )

switch ( out to mpls->OutlabelType )case MPLS: // MPLS to SAPF translation

session = out to mpls->GetRemoteSession();if( !session )

30

returnif( !in from mpls OR in from mpls->OutlabelType != SAPF)

// no path exist from MPLS-side destination to// SelNet-side source or out type is not SAPFin from mpls = lib entry( in=new MPLS,

target=src ip/32,out=SAPF permanent )

lib.add(lib entry)session->SendLabelMapping( lib entry )

case UNASSIGNED: // pure IP to SAPF translationif( !in from mpls OR in from mpls->target != src ip/32 )

in from mpls = lib entry( in=UNASSIGNED,target=src ip/32,out=SAPF permanent )

lib.add(lib entry)

if( in from mpls )sapf REDIRECT( in from mpls->Outlabel, src sel reply )

if( out to mpls AND drop packet == false )// send XRP reply back to source indicating lookup successXRP SendReply( src sel reply )

5.3.3 SelNet module

The XRP message that required to be changed is the one where the SelNet nodeannounces local target along with the hardware address. In the case when a mes-sage like this is going to trigger a MPLS path the virtual IP address from theSelNet client is needed. Hence the XRP message has changed to the following:

"scheme=sapf/eth;id=.../.../$IP ADDRESS;wh=..."

Figure 5.4: Modified XRP message with virtual IP address included

Besides this change to the XRP message a mapping of hardware addresses ofSelNet clients to their virtual IP numbers when receiving the above mentionedXRP message. This information is then used when updating the redirect from theMPLS-side SAPF selector. See figure 5.2 for more details.

The netbox itself has not been changed, but hooks has been added orderingit to pick up MPLS and regular IP traffic. When traffic like this is received theMPLS function that handles it will be called and appropriate actions are taken.

31

5.3.4 Bringing it together

In the scenario where a SelNet client wants to send a package to a host on theMPLS side these are the actions taken in the middle-ware. First a XRP messageis sent by the SelNet client and this message is picked up and a MPLS path iscreated as described earlier.

When a SelNet package that should cross the MPLS-SelNet border arrivesand the MPLS path is established, the SAPF selector attached to the package isredirected to the permanent selector created during the MPLS path creation. Thisselector has a callback function attached and this function is now called with theSAPF selector as an argument. The function now takes care of looking up theSAPF selector in the LIB and when the appropriate entry is found the packet isgiven an MPLS label according to the entry and sent out to the next hop.

If a reply is sent by the receiver this packet will arrive with the announcedlabel created just for sending packages to the source SelNet client. This labelis located in the LIB and an outgoing SAPF selector is found as out-label. Thepacket is then inserted into the SelNet function sapf demux along with the SAPFselector and the SelNet modules will see to it that the selector is redirected towardthe selector chosen by the source client as a receive-wormhole. This selector hasa callback function attached and this function will now take care of delivering thereply to the SelNet client.

The following diagram shows all the packages sent in the above scenario.

32

Figure 5.5: Packet flow when sending a ICMP ping from a SelNet node

33

Chapter 6

Testing

When testing the middle-ware that had been developed, three different protocolswere chosen, ICMP, TCP and UDP. The ICMP was chosen because it is an easyway of verifying that packets can traverse the MPLS-SelNet border. TCP uses aconnection oriented setup which requires the receiver to acknowledge the pack-ages that it has received, while the UDP does not have this feature. In the testingthe TCP was expected to take care of resending the packet when the reply hadbeen lost, while in UDP scenario this were not necessary because no reply was is-sued from the receiving host. Given these facts about TCP and UDP the behaviorof the middle-ware was expected to be different and thus both of these protocolsare important for the verification of the middle-ware.

6.1 Testbed setup

The test-environment used to verify that the prototype program works was createdusing two laptops with Debian Linux, pennywise and snowcrash and a stationarycomputer, dumburk with Redhat Linux version 9. Snowcrash was chosen to actas a MPLS router, running a MPLS-enabled kernel and the program mplsd thatuses the LDP protocol. The stationary computer was used to host the middle-waresoftware while pennywise is running the SelNet client.

SelNet and the Middle ware will form the virtual subnet of 192.168.0.0/24,while the physical subnet is at 192.168.0.240/28. In order for the test-environmentto work some steps has to be taken to ensure that the traffic will end up in thecorrect places. First of all snowcrash has to be aware of how to reach the SelNetclients that are on the other side of dumburk. The routing table on snowcrashis given a new entry telling the kernel that packages going to the virtual SelNetnetwork should be sent to dumburk for further processing. Second, the dumburkhad to be able to join the MPLS multicast group so that it can locate snowcrash.

34

Figure 6.1: Test environment setup.

This multicast group is located at 224.0.0.2 and these packages should not bepicked up by the SelNet-side netbox. Therefore a special route is inserted into thelocal routing table forcing these packages to be sent on eth0.

Finally all traffic from pennywise should go through the tun0 interface. Thusthe current routing entry that sends these to eth0 has to be removed.

snowcrash# ip route 192.168.0.0/24 via 192.168.0.243snowcrash# ip route 192.168.0.0/24 via 192.168.0.243snowcrash# ./zebra.sh start

dumburk# ip route add 224.0.0.0/8 dev eth0dumburk# ./selnet-mpls -i eth0 -l eth0 192.168.0.100interface ’tap0’ 192.168.0.100 netmask: 255.255.255.0 type: SelNet192.168.0.100lsr address on device eth0: 192.168.0.243lsr hw_addr on device eth0: 00:04:ac:66:67:2cinterface ’eth0’ 192.168.0.243 netmask: 255.255.255.0 type: MPLS

ldp_session created to lsr: mpls_identifier[192.168.0.242:0]Session is active with local address: 192.168.0.243Connection established to lsr 192.168.0.242

pennywise# ip route del 192.168.0.240/28pennywise# ./selnet -i eth0 192.168.0.101pennywise# ping -i0.5 192.168.0.242

6.2 Testing TCP

This test were done by connecting to the zebra mplsd command line virtual termi-nal on snowcrash on port 2609.

pennywise#: telnet 192.168.0.242 2609

35

Trying 192.168.0.242...Connected to 192.168.0.242.Escape character is ’ˆ]’.

Hello, this is zebra (version 0.94)Copyright 1996-2002 Kunihiro Ishiguro.

User Access Verification

Password:

6.3 Testing UDP

When testing the UDP protocol the netcat program was used. Snowcrash wasrunning the netcat in listening mode while pennywise was sending a small stringevery second. Since no reply-channel has to be re-created every third second noloss of packages occurred in this scenario.

pennywise#: netcat -u -l -p7777 -zsnowcrash#: send.sh | netcat -u -p7777 192.168.0.242

Figure 6.2: Screen-dump from ethereal showing traffic when sending UDP pack-ets.

Figure 6.2 show the packages that flow from pennywise to snowcrash. Thefirst two packages are XRP lookup messages from pennywise. The third messageis the label mapping message sent by dumburk in order to force snowcrash to usethe given FEC and label. The next message, number 4, are the XRP reply sentback to pennywise. Message number 5 is the XRP request that is forwarded intothe SelNet cloud again. Message 6 is the TCP ack on the label mapping messageand message 7 is the actually UDP message sent by pennywise. This message isforwarded to snowcrash with a MPLS label (message 8). The next message is aLDP hello message. The following 4 messages are UDP messages sent by pen-nywise (those with protocol 0x4242) and forwarded by dumburk (UDP protocol).The last message is another LDP message from snowcrash telling dumburk not todelete the ldp session that exists between them.

36

6.4 Testing ICMP

During this test ICMP pings were sent from pennywise to snowcrash. As seenbelow there are a number of packages that are lost and this is due to the recreationof the routing path every third second. Thus, the first ping is lost when the path iscreated, ping number 4, 7 and 11 are lost when it is rebuilt.

As seen in figure 6.3 the packet sent by dumburk is carrying a MPLS labelwith the value 10007.

pennywise#: ping 192.168.0.242PING 192.168.0.242 (192.168.0.242) 56(84) bytes of data64 bytes from 192.168.0.242: icmp_seq=2 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=3 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=5 ttl=64 time=1.74 ms64 bytes from 192.168.0.242: icmp_seq=6 ttl=64 time=1.72 ms64 bytes from 192.168.0.242: icmp_seq=8 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=9 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=10 ttl=64 time=1.65 ms64 bytes from 192.168.0.242: icmp_seq=12 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=13 ttl=64 time=1.71 ms64 bytes from 192.168.0.242: icmp_seq=14 ttl=64 time=1.71 ms

--- 192.168.0.242 ping statistics ---14 packets transmitted, 10 received, 28% packet loss, time 13107msrtt min/avg/max/mdev = 1.656/1.712/1.742/0.020 ms

Figure 6.3: Screen-dump from ethereal showing MPLS labeled ICMP ping packet

37

Chapter 7

Conclusions and future work

7.1 Achievements

The goal of the project was to implement a prototype that would translate SelNetXRP and selectors into MPLS LDP and labels. The working prototype was testedusing some simple scenarios thus stating the fact that a translation between thetwo protocols could be made. In the meantime, while exploring the aspects ofMPLS and SelNet, a comparison has been made and some of the benefits anddisadvantages has been revealed.

7.2 Conclusions

The experience learned from this project is that simplicity pays off in the end. TheMPLS work group has invested much time and effort into making a protocol thatsurly works fine, but is ever so hard to implement and learn. The MPLS suite im-plementation is enormous and it is almost impossible to learn how things are doneby looking at the source code. To further complicate matters the documentationand the number of comments are almost non-existent.

In contrast to the MPLS suite we have the SelNet project. The authors of Sel-Net has put some effort in keeping the architecture simple and easy to understand.In the planning stage the hardest and most time-consuming part of the project wasexpected to be the interaction between SelNet and MPLS. This, however, provedto be wrong. The complexity of LDP and the relative simplicity if SelNet led tothat the LDP part required the most time.

Many things can be said about simplicity and the importance of keeping thingssimple, but I like the following immortal words from Albert Einstein: “Thingsshould be made as simple as possible, but not simpler”.

38

7.3 Future work

As the work on this project progressed only the most necessary messages wereimplemented, leaving many opportunities for future work. For example the LDPsession module that was created does not handle nor send all LDP specified mes-sages. If this product here to be stress-tested it would probably become clear thatthe label information base is pretty slow. An ideal and fast approach here wouldto use a hash-table to store the different entries. In addition to this the lack of timerequired me to do a simplification and remove the multi hop MPLS path. If thedestination is several hops away a way of fetching the hardware-address must beimplemented into the ldp api module. There are also some bugs left to find andfix in order to prevent the program from crashing and giving more stability.

What is left to be done is to investigate the behavior of the MPLS hosts so thatthey start to send MPLS labeled traffic back to the middle ware.

39

Chapter 8

Glossary

ARIS Aggregate Route-based IP-SwitchingATM Asyncronus Transfer modeBGP Border Gateway ProtocolCLI (zebra) Command Line InterpreterFEC Forward Equivalence ClassICMP Internet Control Message ProtocolIETF Internet Task ForceLDP Label Distribution ProtocolLER Label Edge router, last MPLS router in a LSPLIB Label Information BaseLIR Label Ingress router, first MPLS router in a LSPLSP Label Switch PathLSR Label Switch RouterLUNAR Lightweight Underlay Network Ad-Hoc RoutingMPLS Multi Protocol Label SwitchingOSPF Open Shortest Path FirstRFC Request For CommentSAPF Simple Active Packet FormatTCP Transmission Control Protocol,TLV Type Length ValueTTL Time To LiveUDP User Datagram ProtocolXRP eXtended Resolution Protocol

40

Bibliography

[1] Christian Tschudin and Dan Decasper, “Active Networks Request ForComment: Simple Active Packet Format (SAPF)”URL: http://www.docs.uu.se/t̃schudin/pub/cft-1998-sapf.txt

[2] James R. Leu, “MPLS-Linux and LDP-portable”URL: http://sourceforge.net/projects/mpls-linux/

[3] GNU zebra routing softwareURL: http://www.zebra.org/

[4] Ipsilon IP switching RFCURL: http://www.faqs.org/ftp/rfc/pdf/rfc1953.txt.pdfURL: http://www.faqs.org/ftp/rfc/pdf/rfc1954.txt.pdfURL: http://www.faqs.org/ftp/rfc/pdf/rfc1987.txt.pdf

[5] Cisco tag switching RFCURL: http://www.faqs.org/ftp/rfc/pdf/rfc2105.txt.pdf

[6] IBM Aggregate Route-Based IP SwitchingURL: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-marsmcs-01.txt

[7] Toshiba Cell Switch Router (CSR) RFCURL: http://www.faqs.org/ftp/rfc/pdf/rfc2095.txt.pdf

[8] L. Andersson, P. Doolan, N. Felman, A. Fredette, B. Thomas,“Request for comments (RFC) 3036, LDP specification”, January 2001URL: http://www.faqs.org/ftp/rfc/pdf/rfc3036.txt.pdf

[9] Christian Tschudin, Richard Gold “SelNet: A Translating UnderlayNetwork”, Technical Report 2003-020, November 2001URL: http://www.it.uu.se/research/reports/2003-020/

[10] Christian Tschudin, Richard Gold “LUNAR: Lightweight UnderlayNetwork Ad-Hoc Routing”, Technical Report 2003-021, January 2002URL: http://www.it.uu.se/research/reports/2003-021/

41

[11] IETF MANET Working Group. MANET Charter, 2000URL: http://www.ietf.org/html.charters/manet-charters.html

[12] Christian Tschudin, Richard Gold “Network Pointers”URL: www.docs.uu.se/selnet/hotptr submit.pdf

[13] E. Rosen, A. Viswanathan, R. Collon “Request for comments (RFC) 3031,Multiprotocol Label Switching Architecture”, January 2001URL: http://www.faqs.org/ftp/rfc/pdf/rfc3031.txt.pdf

42