Embedded MPLS Architecture

Transcription

1 Embedded MPLS Architecture Raymond Peterkin, Dan Ionescu School of Technology and Engineering (SITE) University of Ottawa 161 Louis Pasteur, P.O. Box 450, Station A, Ottawa, Ontario, K1N 6N5 CANADA Abstract This paper presents a hardware architecture for Multi Protocol Label Switching (MPLS). MPLS is a protocol used primarily to prioritize internet traffic and improve bandwidth utilization. Furthermore it increases the performance of internet applications and overall efficiency. However, most existing MPLS solutions are entirely software d. MPLS performance can be enhanced by executing core tasks in hardware while allowing other tasks to be executed in software to guard against performance degradation. This paper proposes a hardware/software design of MPLS on an FPGA for increased performance and efficiency. 1. Introduction Resource intensive Internet applications like voice over Internet Protocol (VoIP) and real-time streaming video perform poorly when the core network of the Internet is relatively congested. Increasing bandwidth provides temporary relief. However, bandwidth alone is not sufficient to provide an environment where internet applications can be executed efficiently due to delays. Long term relief can only be achieved through efficient prioritization of network resources and traffic. Traffic engineering (TE) and Quality of Service (QoS) can be used to address the viability of Internet applications [1]. Traffic engineering is the process of optimizing operational network performance by minimizing packet loss and delay while maximizing throughput. Avoiding congestion is paramount to successful traffic engineering as to ensure that there are relatively few underutilized routes for information to be sent. TE is best facilitated by explicit path specification, efficient maintenance of those paths, the aggregation (merging) and deaggregation (unmerging) of traffic. These attributes decrease overhead and increase response time. MPLS provides these characteristics and in doing so is practical alternative for traffic engineering [2]. Quality of Service (QoS) is the ability for a network to provide better service to selected traffic over different technologies including ATM, Ethernet and Frame Relay. QoS functions include packet classification, admission control, configuration management and congestion avoidance [ 3 ]. The integrated services QoS model is available through label distribution protocols that use MPLS like RSVP- TE and CR-LDP [4]. So label distribution protocols can be used to perform QoS more efficiently with a hardware/software architecture for Internet applications. This paper is organized into the following sections. Section 2 provides an overview of MPLS and how certain characteristics allow for improved traffic engineering, QoS, and other traits necessary to improve network efficiency. Section 3 discusses the proposed architecture including the hardware and software components. Greater emphasis is placed on the hardware design including relevant control units and data paths. Section 4 discusses results observed to date and the paper concludes with a summary of key points with respect to the architecture. 2. MPLS Overview MPLS operations are performed on two types of routers. Label Edge Routers (LERs) operate at the edge of an MPLS network and typically contain s to dissimilar networks. LERs route traffic and are used as an between layer 2 networks (ATM, Frame Relay or Ethernet) and an MPLS core network. When LERs receive a packet from layer 2 network, a label is then attached to that packet and sent into the MPLS core network. Subsequent interpretation of that packet is done on the basis of that label so depending on how other routers are configured, a packet will follow a specific path, called a label switched path (LSP), going from one LER to another. When an LER receive a packet from the MPLS network, the label is removed and the packet is sent to the appropriate layer 2 network.

2 ETHERNET ATM NETWORK LER MPLS CORE NETWORK Figure 1 MPLS network LERs sending packets into the MPLS network are described as ingress while LERs sending packets to layer 2 networks are called egress. They participate in the establishment of LSPs prior to exchanging packets. Label Switch Routers (s) form the core of the MPLS network. They participate in forwarding packets to other MPLS routers and establishing LSPs. They receive packets from an LER or an, analyze the label and forward the packet to an or LER depending on the label contents. Figure 1 illustrates a typical MPLS network. Each LER is connected to one or more layer 2 networks and the MPLS network. While the figure only illustrates Ethernet and ATM networks, Frame Relay is also supported by MPLS. s are either connected to other s or LERs. Packets originate from a layer 2 network, are passed to an LER, then to one or many s before reaching an egress LER that forwards the data to a final layer 2 network. Figure 2 shows a set of packet exchanges from an ingress LER to an egress LER with intermediate communication. When the ingress LER receives layer 2 data, it is analyzed and a label is added to the packet. The new packet is then forwarded to the appropriate. Subsequent s analyze the label, remove it and attach a new label so the next MPLS router can correctly interpret the label information. When the packet reaches the egress LER, the label is removed and the packet is forwarded to the appropriate layer 2 network. The ability to support aggregate paths within a tunnel in an MPLS network is supported through the LER LER ETHERNET ATM NETWORK use of multiple labels for each packet. Figure 3 illustrates a tunnel and how it can be used to merge and unmerge data. The collection of labels for a given packet is called a label stack since labels are added (or pushed ) and removed (or popped ) like elements in a stack data structure. The most recent (or top most) label is processed at any given router. Depending on how the router has been configured a label is added to the stack or the top most label is swapped or removed. A packet with a label stack is depicted in Figure 4. A typical MPLS network does not use more than two or three levels of nested paths and consequently, label stacks do not normally exceed two or three labels [5]. Figure 5 illustrates the generic label format for a label stack entry as described in [6]. Each stack entry is 32 bits long with components for the label, Class of Service (denoted as CoS ), a bit to denote the bottom of the stack (denoted as S ) and a time to live (TTL) field. The label gives information needed to forward the packet and is the basis upon which MPLS switching operations occur. The CoS bits affect the scheduling and or discard algorithms applied to the packet as it is transmitted through the network. These bits are not modified by the embedded implementation of MPLS. The S bit is set to one for the last entry in the label stack and zero for all other label stack entries. As described in [7], the TTL is decremented by one each time the packet passes through a router. The packet is discarded when the TTL reaches zero. Label pairs are stored in a central area referred to as the. Every time a new packet is received for processing, the is Figure 3 MPLS tunnel LEVEL N LEVEL 2 LSP (TUNNEL) PACKET LEVEL 2 STACK LEVEL 1 DATA LAYER 2 NETWORK (generates L2 packet) LAYER 2 NETWORK (receives L2 packet) Figure 4 Label stack LER (INGRESS) LER (EGRESS) CoS S TIME TO LIVE (TTL) PACKET IN: PACKET OUT: LBL 1 LBL 1 LBL 2 LBL 2 LBL 3 LBL 3 20 BITS 3 BITS 1 BIT 8 BITS Figure 2 MPLS packet exchange Figure 5 MPLS generic label format

3 consulted to determine the appropriate action for the label and determine the new label value if applicable. Entries can be added, modified, or removed from the keeping in mind that label values must be consistent among all MPLS routers to ensure that packets follow the desired LSPs. Concepts like label path creation and label distribution are beyond the scope of this paper and are not discussed in further detail: Label path creation: Several protocols exist (LDP, OSPF, RSVP, etc.) that are typically used with MPLS to determine the LSPs that will exist in an MPLS network. Each protocol has advantages and disadvantages with respect to traffic engineering and QoS. Creating and distributing labels: Once LSPs have been established, the labels must be distributed among the various nodes in the network. Included with this task is the creation of tables to store labels. Only those issues most pertinent to the architecture of the MPLS processor are discussed in this paper. Consult [8] for a full description of all issues regarding MPLS architecture and implementation. 3. Embedded MPLS Architecture The MPLS protocol stack illustrated in [9] and [10] suggests that all packet forwarding, label lookups and label manipulation be performed in hardware while routing protocol functionality be done in software to avoid potential performance degradation. That methodology is followed in the proposed architecture, keeping in mind that certain s could be implemented in either hardware or software. Figure illustrates a high level description of the embedded MPLS architecture. The architecture consists of two packet processing s, and a separate to modify the label stack described in the previous section. The packet processing s are used to process packets that enter or leave the MPLS router. The ingress packet processing is used to deliver the label stack and a packet identifier to the label stack modifier. The packet identifier is a number that is arbitrarily chosen to distinguish different packets from each other so an LER can push a label onto an empty label stack. For IP packets, the packet identifier is typically the destination address. Once the label stack has been modified, it is delivered to the egress packet processing that replaces the label stack in the initial packet and generates the new packet. Routing functionality interacts with the MPLS by reading and storing information in the label stack modifier. The routing functionality is assumed to be software d while the packet processing s could be implemented in hardware or software. However, the label stack modifier is implemented in hardware in the given architecture. Consequently, the hardware architecture of the label stack modifier is described next. Figure 7 illustrates the architecture of the label stack modifier. The architecture is separated into a control unit and a data path. The control unit is used to coordinate signals for label stack modification and management. The data path stores all relevant information, most notably the information and the modified label stack Label Stack Modifier Control Unit The control unit of the label stack modifier is composed of four state machines. Those state machines are the label stack,, search and main illustrated in Figure 7. To simplify the state machine diagrams, the signals between the s and the data path are not explicitly shown. A description of the activity is given instead and all the signals are described in tables that accompany the diagrams. The clock, reset, and enable signals are also not explicitly shown but in each case the enable signal must be high for the state machine to leave its idle state. The state machine for the main is shown in enable operation MPLS ARCHITECTURE CONTROL UNIT Packet In INGRESS PACKET PROCESSING Packet Identifier Label Stack In Control STACK MODIFIER Label Stack Out Control EGRESS PACKET PROCESSING Packet Out Router type STACK INTERFACE doneoperation enable MAIN doneoperation enable INFORMATION BASE INTERFACE Info Base Operations Control Label and Configuration INFORMATION BASE SEARCH ROUTING FUNCTIONALITY Data in Data type Packet identifier DATA PATH Data Out Stack level Figure 6 Architecture for embedded MPLS Figure 7 Label stack modifier architecture

4 LABLE INTERFACE ACTIVE enablelabelinterface labelstackready IDLE enableinfobaseinterface infobaseready Figure 8 Main state machine INFO BASE INTERFACE ACTIVE Figure 8. It is used to ensure that the remaining state machines are not working at the same time and possibly generate inconsistent results. When the main is not active, it has enabled the label stack or the and waits for the in question to finish its activity before allowing subsequent operations to happen. A full description of the input and output signals for the main is shown in Table 1. The state machine for the label stack is shown in Figure 9. The label stack is used to insert label entries directly into the stack and to update the stack given the existing state of the information. The packet is discarded (i.e. the label stack is reset) if the relevant entries are not found in the or if the TTL has expired. The label stack remains idle until it is enabled by the main when it is prompted to perform the operation desired by the user. Commands to push or pop the label stack directly are promptly executed and the label stack returns to idle. Updating the label stack first involves searching the for the desired new label (if necessary) and operation. The packet is immediately discarded if no information is found. If information is found the top entry in the stack is removed and the TTL is updated before information verification takes place. If there are any inconsistencies in the information or if the TTL is expired, the packet is immediately discarded. Once the information has been successfully verified the remaining operations are performed to complete the desired operation. Those operations include modifying the new top stack entry for pop, immediately pushing the new stack entry for swap and pushing the old and new stack entries for the push operation. Each USER PUSH push from external user pop from external user USER POP IDLE update stack command from user SEARCH ENABLE No item found DISCARD PACKET Label and operation found REMOVE TOP UPDATE TTL Inconsistent operation or expired TTL VERIFY INFO pop from push from information swap from UPDATE TOP PUSH OLD PUSH NEW Table 1 Signals for the main Signal Name Description Connecting clk Clock signal enable enableibint operations Used to enable the label stack Base Interface/ Data Path Label Stack Interface enablelblint Used to enable the label stack extoperation Indicates the desired operation from the user. ibready Indicates that the has finished an operation lblstckready Indicates that the label stack has finished an operation readdata Indicates that data should be read from the processor reset Reset signal savedata Indicates that data should be saved in the processor updatelblstk Indicates that the label stack should be updated Base Interface Label Stack Interface transition to the IDLE alerts the main that the operation is complete. A full description of the signals for the label stack is given in Table 2 and Table 3. Figure 10 illustrates the state machine for the. It remains idle until it is enabled by the main and proceeds to either search or save data to the. To search the, the search is enabled and the waits until WRITE PAIR Save Label Pair Label Pair Saved IDLE Read data Search Complete SEARCH ENABLE Figure 9 Label stack Figure 10

5 Table 2 Signals for the label stack Signal Name Description Connecting bttmstckbit The bit of a label stack entry used to indicate if it s the top of the stack clk Clock signal cosbits The class of service bits that are part of the label stack entry cosbitssrc dpoperation donelblupdt enable extoperation indexsource itemfound lblop newlblsrc pktdcrd Indicates if the class of service bits for the stack entry should come from the stack entry or the The desire operation as indicated by the data path Indicates that the operation is complete operations Indicates the desired operation from the user. Used to indicate if the index in the data path should be read from memory or from a label stack entry Indicates if the search found an entry The operation to be performed on the stack Indicates the source of the label for a new entry Indicates if the packet has been discarded Main Main search the search operation is complete. Writing a label pair to the is done through direct manipulation of the data path. Once the operation is complete a transition back to the idle state occurs where the indicates that the Table 3 Additional signals for the label stack Signal Description Name reset Reset signal rtrtype srchdone srchenbl svstkval stckctrl stkentsrc stacksize ttl ttlcntctrl ttlsource ttlvalue Indicates the type of MPLS router. Logic low is interpreted as LER while logic high is interpreted as Indicates if a search of the information was successful searching the Used to save all values of a new stack entry Used to add or remove entries from the stack Indicates if an entry to the stack should come from external data or from the updated entry Used to indicate the current size of the label stack The current value of the TTL The counter containing the TTL is modified with this signal Used to indicate whether the TTL for the packet entry should come from a counter or the stack Indicates the value of the TTL for a stack entry. Connecting search search operation has completed. All the signals for the are described in Table 4. Figure 11 illustrates the state machine for the search that is enable by either the label stack or the. Once it has been enabled, the search iterates through the label pair entries of a specified level. If the corresponding

6 Table 4 Signals for Signal Name Description Connecting clk Clock signal dnibupdate enable savedata readdata Indicates that an operation has completed operations Indicates that data should be saved in the processor Indicates that data should be read from the processor label and operation are a delay occurs so the values can appear before returning to the idle state. All the signals for the search moduel are described in Table Label Stack Modifier Data Path Main Main reset Reset signal srchdone Indicates if a search of the was successful search srchenbl writecontrol IDLE Begin Search searching the Used to write values to the. READ INFO BASE Value does not exist WAIT FOR READ VALUE Update read address WAIT FOR INFO search Value Found Figure 11 Search state machine COMPARE VALUES Figure 12 gives a high level description of the data path for the label stack modifier. data enters the data path and is interpreted as a label stack entry (from a packet), a label pair (old label/new label) for the or a search index when the user wants to read the contents of the Signal Name Description Connecting aeb_10b Indicates if the values from a 10 bit comparator in the data path are equal aeb_20b Indicates if the values from a 20 bit comparator in the data path are equal aeb_32b Indicates if the values from a 32 bit comparator in the data path are equal clk Clock signal infoenbl item_found lsi_enable level level_source readaddrctrl readvals search Indicates that the desired entry was found. search Indicate the level being searched in the Used to indicate the source of the level for the information. Used to control the read address in the Used to read the index, label, and operation from the. Label stack / Label stack reset Reset signal searchdone Table 5 Signals for search Used to indicate that the search is complete. Label stack / directly. It should be noted that a label stack entry is 32 bits wide while a label pair is 40 bits wide (two 20 bit labels) and an index is 20 bits. When the data type is less than 40 bits the least significant bits are used

7 enable Index source Packet identifier Stack entry source Data type data In Label from memory Stack Control Signals Label from stack Label stack entry STACK Number of stack items Label Interface Control Signals Base Interface Control Signals Stack Operation CoS bits source CoS bits from stack Cos bits CoS Bits from control path Label from memory NEW Bottom of label stack bit REGISTER TTL from stack entry Counter control COUNTER TTL TTL from control path TTL source New or modified label entry Stack level Label Index Level 1 Level 2 Level 3 Level 2 Level 3 Level 1 Level 2 Level 3 Level 1 Level 2 Level 3 INFORMATION BASE INTERNAL CONNECTIONS LEVEL 1 LEVEL 2 LEVEL 3 Level 1 Index Data out Number of stack items TTL noted that the packet identifier is 32 bits while a label is 20 bits so the memory for level 1 must have different index memory than levels 2 and 3. That is why the packet identifier is an external input to the information in Figure while the other indices are not. Each memory component support 1 KB of label pairs. So the total memory use is easily supported by standard reconfigurable computing environments. The data path also contains three comparators of different data widths (32 bits, 20 bits, and 10 bits) so index and label values can be compared when performing computations. Packet identifier Level 1 Index Compare 32 BIT COMPARATOR Output Label from stack entry Index from memory Compare 20 BIT COMPARATOR Write index from memory Read index from memory Compare Figure 12 Label stack modifier data path 10 BIT COMPARATOR while the appropriate number of most significant bits is ignored. Label stack entries can be stored from external data or from a register that holds the label entry currently being modified. Modifications to the top level entry in the stack happen by modifying the TTL with a counter and the label entry with the. The CoS remains unchanged in the label stack entry. The is composed of multiplexing logic and memory s. Memory s are described as level 1 memory, level 2 memory and level 3 memory for each of the available levels in the label stack. The label, index, operation (push, pop, swap, or no operation) and stack level are all provided to. The format of a single memory element in the is shown in Figure 13. Separate memory components exist for an index, label value, and operation. Counters are used to address memory components so the index (the packet identifier or the first part of the label pair) can be associated with its corresponding label and operation. It should be Output Output 4. Results Results for the all operations pertaining to push and pop operations taken directly from the user are listed and analyzed here in addition to the swap operation for a label update. Figures 14, 15 and 16 show simulated results of the search, since searching the is the most computationally intensive task the architecture performs. It should be noted that some of the signal names in the simulations are different than those described in previous sections. The level signal refers to the level (1, 2 or 3) of the stack. The old_label and new_label signals constitute the label Figure 14 Simulation for level 1 label pair entries Index (packet identifier or label) Read Index Write Data In Enable Incr/Decr Load Clear COUNTER Read Address INDEX COMPONENT (32 or 20 bits wide, 1 KB long) Index out Data In Enable Incr/Decr Load Clear COUNTER Write Address Read index Write index Figure 15 Simulation for level 2 label pair entries Label Read Label Write Read Address Write Address COMPONENT (20 bits wide, 1 KB long) Label out Operation Read Operation Write Read Address Write Address OPERATION COMPONENT (2 bits wide, 1 KB long) Operation out Figure 13 memory component Figure 16 Simulation for packet discard

8 pair being stored in the while operation_in is the accompanying operation. The packetid signal acts as the packet identifier and only applies to level 1 entries. The save and lookup signals are used to store and retrieve entries respectively. Signal label_lookup is used to indicate the label used to perform the lookup for levels 2 and 3. Signals r_index and w_index represent the internal read and write indices respectively. Simulation outputs are label_out, operation_out, lookup_done and packetdiscard. They are used to indicate the label and operation values, when a lookup attempt is finished and when a packet is discarded respectively. In Figure 12, level 1 is used exclusively for writing and reading label pair values and operations. Ten label pairs are written with packet identifiers of 600 through 609 inclusive and new label values of 500 through 509 inclusive. The operation is arbitrarily chosen for each label pair but no two consecutive entries are given the same operation for illustration purposes. As the values are entered we see w_index increment from 1 to 10, indicating the label pairs are being properly stored and not overwritten. Once the label pairs are written, the new label and operation for packet identifier 604 is requested (the packetid signals is changed to 604 and the lookup signal is high). Once the lookup begins, we see that r_index begins incrementing to search through the and stops at the index of the correct entry. When the entry is found, the lookup_done signal goes high for a clock cycle. The new label (504) and operation (3) then appear and the packetdiscard signal remains low. Figure 13 illustrates a similar scenario to Figure 12 but label pairs are entered for level 2 as opposed to level 1. The old label values take values 1 through 10 inclusive while the new label values go from 500 to 509 inclusive. Signal values for w_index and r_index iterate so all values are written and the correct values are read. Once again the lookup_done signal goes high after the read attempt and the packetdiscard signal remains low. Figure 14 demonstrates a situation where a label lookup occurs for a label that does not exist in the. The inputs are the same as those for Figure 13 but the label_lookup signal is changed to 27 and there are only labels for numbers 1 through 10 inclusive. When the lookup signal is made high, we see that the r_index signal iterates to process all label pairs stored at that level. After processing the last stored pair, no match has been found so the lookup_done and packetdiscard signals are sent high to indicate that the operation is complete and that no match was found. Signals label_out and operation_out remain unchanged. Table 6 Processing times for different tasks Operation Worst Case Number of Clock Cycles Reset 3 push from the user 3 pop from the user 3 Write label pair 3 Search information 3n + 5, n = total number of label pair entries swap from the 6 Table 6 illustrates the number of clock cycles required to perform various tasks. We see that a constant number of cycles is required to perform most of the tasks listed while a variable number of cycles is needed to search the. With these results, a worst case running time to update the label stack with a swap can be determined. Assuming that there are no delays between operations, the worst case number of cycles required to reset the architecture, push three stack entries, fill an entire level with 1024 label pairs and perform a swap would be 6167 cycles. Therefore, an FPGA like the Altera Stratix EP1S40F780C5 with a 50MHz clock could perform those operations in approximately ms. 5. Conclusions In this paper, an embedded architecture for the MPLS protocol was proposed. The design uses both hardware and software to implement different aspects of MPLS. The architecture proposed implementing routing functionality in software, label switching functionality in hardware and packet processing functions in either domain. A full description of label switching in hardware was provided including all components of the proposed control unit and data path. Preliminary results indicate that information can be retrieved from the in linear time and other operations are done in constant time. The architecture presented here satisfies the space requirements of most reconfigurable computing environments and can be implemented to achieve optimal performance of MPLS. References [1] Altera Corporation, Application Note 132: Implementing Multiprotocol Switching with Altera PLDs, version 1.0, January 2001, pg. 1.

9 [2] Gray, Eric W., MPLS: Implementing the Technology, Addison-Wesley, 2001, pg [3] Cisco Systems Inc., Cisco IOS 12.0 Quality of Service, Cisco Press, p xv, xvi. [4] Gray, Eric W., MPLS: Implementing the Technology, Addison-Wesley, 2001, pg [5] Jamoussi, Bilel, ed. Constraint-d LSP setup using LDP; a work in progress. [6] Gray, Eric W., MPLS: Implementing the Technology, Addison-Wesley, 2001, pg [7] Le Faucheur, Francois, IETF Multiprotocol Label Switching (MPLS) Architecture, IEEE. [8] Rosen, et al., Multiprotocol Label Switching Architecture, RFC 3031, January [9] International Engineering Consortium (IEC), Multiprotocol Label Switching, pg. 16. [10] Altera Corporation, Application Note 132: Implementing Multiprotocol Switching with Altera PLDs, version 1.0, January 2001, pg 8.