P O Z NA N UN I V E R S ITY O F TE C H N O LO GY A C A D E M IC J O U R N AL S
No Seria 2007
Paweł KACZMAREK*, Sylwester KACZMAREK**
DIDACTIC MODEL OF MPLS DOMAIN
Beginning of MPLS standardization goes back to the late nineties. Convergence of data transmission and real-time services networks and attempt to fade away differences between packet and circuit switching created new challenges. They concern scalability of IP-based networks and introducing to such networks connection-oriented services. In this article firstly all parts of implementation and their didactic goals will be introduced. Then we will move on to details to show how authors tried to achieve established goals. Presented exer-cises are a part of a project prepared for NGN didactic laboratory. Description of imple-mentation corresponds in major part with experiments that were performed during this project.
Keywords: MPLS, Core Networks, NGN, QoS, Linux, Education
1. INTRODUCTION
MultiProtocol Label Switching consists in label-based packet forwarding. An MPLS network as typical packet network consists of set of nodes, which are also called LSR (Label Switching Router), connected with links. Packets are forwarded along LSPs (Label Switched Paths).
LSR LSR LSR LSR LSR LSR LSR LSR Ingress router Egress router __________________________________________
Fig. 1. Basic elements of MPLS domain
2007
Poznańskie Warsztaty Telekomunikacyjne Poznań 6 - 7 grudnia 2007 POZNAN UNIVERSITY OF TECHNOLOGY ACADEMIC JOURNALS
Basic elements of MPLS domain are depicted in Figure 1. Highlighted nodes create LSP. LSPs are unidirectional, ingress and egress node can be defined for them. Where and how particular packet should be forward at each hop is determined by its FEC (Forwarding Equivalence Class). FEC is bind to label so each node on the path can derive it for each packet from its label [2,3]. In ISO-OSI model MPLS is situated between data-link and network layer (term layer 2.5 is also used). MPLS header can be “injected” between layer 2 and layer 3 header (e. g. in Ethernet). This is the reason why it is very often called shim. In case of Frame Relay or ATM label is mapped directly onto appropriate layer 2 header.
2. DIDACTIC OBJECTIVES
There were two objectives associated with creating a model of MPLS domain and planning tasks for students. First was to demystify functionalities and internal structure of LSR. Second was to show MPLS domain as a system through present-ing applications of this technology. Durpresent-ing designpresent-ing six logical parts were sepa-rated. First part is a presentation of basic concepts. It presents behavior of LSR, procedure of forming and internal structure of MPLS packet. Parts which follow are strongly making use of these important concepts and bind them together. Next four exercises should familiarize students with following MPLS applications:
– IP packets transport over MPLS domain, – layer 2 Virtual Private Network,
– QoS achieved through E-LSP, – QoS achieved through L-LSP.
IP packets transport is the most basic one. At the ingress to domain MPLS header is added to IP packets. Then they are forwarded hop by hop. Nodes in this process are using only labels. At the egress MPLS header is popped and for further trans-port IP addresses are used.
Layer 2 Virtual Private Network (L2VPN) is a system which provides exchange of data link layer frames (the most often Ethernet frames), between remote sites. To provide that functionality common network shared with other traffic is used [1]. Usually it belongs to provider while sites are client’s LANs. This third part should give students a general overview of VPN service over MPLS core network but also details of interactions between protocols of layer 2 to 3 in ISO-OSI model.
In the age of convergence IP network became a platform for services that were previously related with circuit switching networks (e. g. voice, videoconference). Thus migration of Internet from typical best-effort solutions to platform with guar-anteed Quality of Service (i. e. IP QoS) became a necessity [3]. IETF proposed two approaches:
– IntServ – architecture with integrated services.
In DiffServ architecture QoS is achieved by distinguishing a way in which packets belonging to different services are handled at nodes. Differentiating implicates existence of classes called PSC (Per Hop Behavior Scheduling Class), which de-termine behavior of packet on its way between to routers. In DiffServ information about class of service is carried by IP header. They are obscured for MPLS nodes that use labels, thus it is necessary to move that information to MPLS header [2,4]. IETF proposed two solutions:
– E-LSP (Exp-Inferred-PSC LSP), – L-LSP (Label-Only-Inferred-PSC LSP).
Part fourth and fifth are devoted to them. Their objective is not only to demystify MPLS mechanisms aiming to provide QoS, but also to introduce and consolidate a concept of quality.
Exercises should not be limited only to observation and drawing very important conclusions. The last part forces creating own configuration. It should consolidate knowledge about principles of operation of MPLS domain rather than skills of using particular configuration tools as they are strictly bind to used software. Also configuration dependencies should be observed. For instance, between a pair of nodes outgoing label for the first one is incoming label for the second.
3. IMPLEMENTATION
Discussed model was created on 6 PCs with i686 processors running Linux op-erating system. They are simulators of real network equipment. To provide MPLS node functionalities open source software was used. Open source applications have two main advantages. First, it is available for free, which is critical for universities. Second, it allows going through source, clarifying problematic issues or editing it. Choice of software was based on its features and capabilities of available hardware. From the list of three MPLS node implementations MPLS for Linux 1.950 was chosen. It was also necessary to chose operating system. Finally Fedora Core 4 was used, because compiled installation packages for it (RPM files) were available. Making use of other would have implicated a need to recompile kernel and other modules from source and spending more time on bringing up single MPLS node. Omitting that step created possibility to concentrate on more advanced configura-tions of routers and applicaconfigura-tions of MPLS.
Software which was used can be divided into two groups. The first group con-sists of four modules available within MPLS for Linux project implementing MPLS node functionalities. The most important was updated kernel. Others were addi-tional tools for configuring kernel settings (iproute), implementing extended bridg-ing (ebtables) and filterbridg-ing (iptables) [2]. In the second group measurement two
tools can be found. Ethereal (currently Wireshark) was used for purposes of cap-turing data units of layer 2 to 3 and bandwidth characteristics. On all PCs graphical environment was installed so all observations can be performed directly at nodes interfaces. Small application mgen was used as a UDP datagrams generator [2].
Topology of created MPLS domain can be seen in Figures 4 and 6. In Figure 7 it was slightly changed. It consists of four nodes. Additionally outside domain there are two workstations used as a traffic generator and receiver. Data link and physi-cal layer are based on Ethernet and UTP. All configurations are static which means that they are introduced by a set of appropriate commands manually. Their descrip-tion can be found in MPLS for Linux documentadescrip-tion [6]. Dynamic configuradescrip-tion requires that routing and signaling protocols must be implemented, which was be-yond the scope of the project. Configuration commands for each part were wrapped into bash scripts to make whole process easier and replicable.
3.1. MPLS node
MPLS packet contains header (label stack) and payload (transported network layer packet). Despite the fact that stack can have more than one label at each mo-ment only label at the top (sent as a first) is processed. In order to forward packet LSR performs one of following operations:
– pushing label onto stack, – popping label from stack, – swapping label on stack.
Pushing label onto stack takes place at the first LSR in path while popping from stack at the last. All nodes in the middle perform swapping. In the model stack has depth of one label, which means ingress and egress LSRs of paths are also edge routers of domain. In general this is not a rule (e. g. hierarchical LSPs) [2,5].
As refer to functional mechanisms inside of MPLS node or in other words to its internal architecture three blocks can be distinguished:
– NHLFE (Next Hop Label Forwarding Entry), – FTN (FEC to NHLFE),
– ILM (Incoming Label Map).
NHLFE is a single entry, containing whole information needed to forward MPLS packet (e. g. next hop IP address, outgoing label etc.). FTN mechanism is used to map FEC of incoming packet onto appropriate NHLFE when incoming packet is not labeled. In opposite situation LSR makes use of ILM as it maps incoming label to NHLFE. FTN is typical for domain ingress LSRs, while ILM for core and egress LSRs [5].
FTN NHLFE NHLFE NHLFE ILM NHLFE NHLFE NHLFE
Fig. 2. FTN and ILM mechanisms
In order to perform experiments ICMP test packets generation should be run. Then using Ethereal structure of label stack entry and whole MPLS packet can be observed as well as elementary operations preformed by LSR. Also configuration scripts should be carefully analyzed to find out which commands are responsible for setting which mechanism. This exercise is strictly connected with next one while traffic flow is needed to perform observations. They both use common set-tings but have different objects to analyze.
3.2. IP packets transport
IP packets transport, basic operations performed by node as well as packets structure are intended to be observed in configuration depicted in Figure 3. On the picture two LSPs (one in each direction) between workstations can be seen.
Fig. 3. IP packets transport over MPLS domain
Apart from packets forwarding, it can be observed how TTL is decremented hop by hop and how MPLS interacts with data link layer to forward packet. Although IP header does not need to be analyzed MPLS still needs IP address of next hop and ARP to resolve destination MAC address of Ethernet frame sent between two LSRs. This is the reason why NHLFE needs information about IP address of next hop.
3.3. L2VPN
Figure 4 reflects a general idea of L2VPN over MPLS service. Ethernet frames with headers are encapsulated in MPLS packets, which are called pseudo wire. Then they are transparently transported over LSP to destination site where they are extracted. In domain VPWS was implemented which is apart from VPLS one of possible approaches [1,2]. Their description is beyond the scope of this paper.
client’s LAN client’s LAN ER ER ER ER ER CR CR CR Ethernet frame PW PW Ethernet frame PW – pseudo wire Fig. 4. L2VPN service
This exercise presents Ethernet frames encapsulation and their transport between physically separated sites. Interesting can be also MAC address resolving proce-dure by encapsulated ARP protocol messages. Analyze of configuration scripts should show that core nodes settings are the same as for IP packets transport and they do not need to be changed to provide L2VPN functionality.
3.4. E-LSP
In E-LSP approach services are distinguished only by value of Exp (3 experi-mental bits) in MPLS header. This field keeps information about PSCs but also drop precedence which is used by RED mechanism in IP QoS nodes. A pair drop precedence and PSC is called gives full description about how packet should be handled at node. Size of field is insufficient to cover all 14 combinations. This disadvantage does not have L-LSP approach. In the implementation packets which
are sent on two UDP ports are handled differently along one LSP from generator to receiver. For that purpose HTB algorithm is used. As an experiment value of Exp field and bandwidth characteristics along crated LSP should be verified.
3.5. L-LSP
In L-LSP solution for each PSC separate LSP is created. Packets with this same destination node but belonging to different classes can be routed over the same sequence of nodes. It is not a rule as it was depicted in Figure 5. Information about drop precedence can be carried in Exp field.
Fig. 5. L-LSP implementation
As in previous exercise packets are generated on two UDP ports and sent along two paths with different forwarding capacities. To limit bandwidth also HTB algorithm was used. In this part forwarding packets along appropriate LSPs and bandwidth characteristics on LSRs and traffic receiver can be observed.
3.6. Reconfiguration
Figure 6 depicts idea of reconfiguration exercise. What is very important recon-figuration is not totally free as it is performed after introducing artificial damage on one of the links. This helps to avoid the situation when less important parameters are changed. At starting point domain model provides transport of IP packets. Then settings of nodes should be adopted to reflect new topology after. New settings can be verified by test ICMP packets.
Fig. 6. Reconfiguration of nodes settings
4. SUMMARY
In this paper model of MPLS domain was discussed. Presented exercises are general introduction to that technology although some of more sophisticated mechanisms are also demystified. Today it is known that MPLS is not miracle so-lution for all problems of nowadays telecommunications. For students it can be very good introduction to more complex GMPLS or GELS technologies. Costs of real equipment (especially optical) make it unavailable for Universities. This model can be a kind of alternative, however there are still some areas which could make it more attractive. The most important extension would be implementation of routing and signaling protocols.
REFERENCES
[1] Carugi M., DeClercq J., Virtual Private Network Services: Scenarios, Requirements and Architectural Constructs from Standarization Perspective, IEEE Network, Vol. 18, No. 2, March/April 2004.
[2] Kaczmarek P., Węzeł MPLS w środowisku Linux, Master thesis, PG WETI, Gdańsk 2006.
[3] Kaczmarek S., Next Generation Networks Architectures, Lecture materials, PG WETI, Gdańsk 2004.
[4] Le Faucheur F. et al., MPLS Support of Differentiated Services, RFC 3270, May 2002.
[5] Rosen E. et al., Multiprotocol Label Switching Architecture, RFC 3031, January 2001.
