480-481, Mount Road, Nandanam, Chennai - 600 035, India. Tel : +91-(44)-433 0550 Fax : +91-(44)-434 4157 e-mail : [email protected] Website: http://www.futsoft.com
White Paper
Multi Protocol Label Switching Copyright 1999-2001 Future Software Limited, India. All rights reserved. No part of this publication may be reproduced, photocopied, stored in a retrieval system, or transmitted without the express consent of Future Software. Future Software reserves the right to revise this document and make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Trademarks and registered trademarks of other companies, if any, are for identification purposes only.
Copyright (c) 1999-2001 Future Software Limited, India.
The rapid growth of the Internet presents various challenges on current IP based carrier networks: New applications require services which are deterministic in nature. The specific service characteristics required by the applications must be guaranteed across the complete path of the network in which the application data traverses. Providing the deterministic service using the non- deterministic IP network presents a major challenge. Current routing technology utilizes the best available path information based only on the destination address; the application datas attributes, however, are not considered. As the network grows there is an increased demand on the routers to handle huge amounts of routing information in addition to applications data. Besides, the forwarding decision made at each hop as a packet travels from one router hop to another inhibits scalability and performance.
Multi Protocol Label Switching (MPLS) is a technology which addresses some of these issues. This White Paper presents an overview of MPLS, its applications and deployment. It also includes a brief introduction to Future Softwares implementation of the MPLS solution.
2. MPLS The New Paradigm
In the MPLS paradigm, packets are forwarded based on short labels. The traditional IP header analysis is not performed at each hop of the packet -- each packet is assigned to a flow only once when it enters the network. MPLS label switching utilizes the Layer 3 routing information while performing the switching at Layer 2 (using hardware support). Hence, MPLS results in high-speed routing of data through the network based on parameters such as QoS and application requirements.
Table 1. Label Switching vs. Conventional IP Routing Conventional Routing Label Switching Entire IP Header Analysis Performed at each hop of the packets path in the network Performed only once at the Ingress of the packets path in the network. Support for Unicast and Multicast Data Requires special multicast routing and forwarding algorithms Requires only one forwarding algorithm. Routing Decisions Based on destination address in the IP header Based on the number of parameters including destination address in the IP header like QoS, data types (voice) etc.
3. MPLS Components
MPLS can be logically and functionally divided into two components to provide the label switching functionality. 3.1 MPLS Forwarding/Label Switching The primary component of MPLS is the Forwarding/Label Switching function. This is an advanced form of packet forwarding which replaces the conventional longest address match forwarding with a more efficient label-swapping algorithm.
The IP header analysis is performed once at the Ingress of the Label Switched Path (LSP) for the classification of packets. The packets that are forwarded via the same next hop, are grouped into a Forwarding Equivalence Class (FEC) based on one or more parameters such as:
MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 2 1. Address prefix 2. Host Address 3. Host Address and Quality of Service (QoS).
The FEC to which the packet belongs is encoded as a short fixed length value known as a label. When the packet is forwarded to its next hop, the label is sent along with it. During subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table, which specifies the next hop, and a new label. The old label is replaced with this new label, and the packet is forwarded to its next hop.
Labels usually have a local significance and are used to identify FECs based on the type of the underlying network. For instance in ATM networks, the Virtual Path Identifier (VPI) and Virtual Channel Identifier (VCI) are used in arriving at the label. Similarly, in Frame Relay networks, the Data Link Control Identifier (DLCI) is used.
Label Switching has been designed to leverage the Layer 2 switching function done in the current data link layers such as ATM and FR. In ATM Label Switched Routers (LSRs), the labels assigned to the FECs (packets) are the VPI/VCI of the Virtual circuits established as a part of the LSP whereas in FR, the labels to the FECs (packets) are the DLCI. Hence, the MPLS Forwarding component should be able to update the Switching fabric(s) in the ATM and FR hardware in the LSR for the relevant sets of LSPs, which can be switched at the hardware.
In the Ethernet and FDDI networks, the labels are short headers placed between the data link headers and the data link layer PDUs. The MPLS Forwarding component in the Ethernet and FDDI LSRs must be placed in a separate firmware/hardware to gain performance advantage during forwarding. 3.2 Label Distribution The distribution of labels in MPLS is accomplished in one or more ways: Extending routing protocols such as Border Gateway Protocol (BGP) to support label distribution Using the Resource ReSerVation Protocol (RSVP) signaling mechanism to distribute labels mapped to the RSVP flows Using the Label Distribution Protocol (LDP) as defined by the IETF. 3.2.1 Label Distribution using BGP
When a pair of LSRs that maintain BGP peering with each other exchange routes, they also need to exchange label mapping information for these routes. The exchange is accomplished by piggybacking the label mapping information for a route in the same BGP Update message used to exchange the route 1 . 3.2.2 Label Distribution using RSVP
RSVP defines a session to be a data flow with a particular destination and transport-layer protocol. When RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP can use a variety of means to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the flow through the LSP. Such an LSP is referred to as an LSP tunnel because the traffic flowing through it is opaque to intermediate nodes along the label switched path. The label request information for the labels associated with RSVP flows will be carried as part of the RSVP Path messages and the label mapping information for the labels associated with RSVP flows will be carried as part of the RSVP Resvmessages.
3.2.3 Label Distribution Protocol
The Label Distribution Protocol (LDP) is a set of procedures and messages by which LSRs establish LSPs through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes.
1 The label mapping information will be carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes of the BGP PDUs. MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 3 LDP associates an FEC with each LSP it creates. The FEC associated with an LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each LSR splices incoming labels for an FEC to the outgoing label assigned to the next hop for the given FEC. The messages exchanged between the LSRs are classified into the following four categories: 1. Discovery messages are used to announce and maintain the presence of an LSR in a network. 2. Session messages are used to establish, maintain, and terminate sessions between LDP peers. 3. Advertisement messages are used to create, change, and delete label mappings for FECs. 4. Notification messages are used to provide advisory information and to signal error information.
Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending the Hello message periodically. This is transmitted as a UDP packet to the LDP port at the all routers on this subnet group multicast address. When an LSR chooses to establish a session with another LSR learned via the Hello message, it uses the LDP initialization procedure over TCP transport. Upon successful completion of the initialization procedure, the two LSRs are LDP peers, and may exchange advertisement messages. The LSR requests a label mapping from a neighboring LSR when it needs one, and advertises a label mapping to a neighboring LSR when it wishes the neighbor to use a label. The LDP uses the Transmission Control Protocol (TCP) transport for session, advertisement and notification messages as the TCP provides reliable and in order delivery of messages.
Figure 1. Lable Assignment Process in LDP Figure 1 depicts a typical MPLS Deployed network and Figure 2 gives the label information base for LSR A, LSR C and LSR E
Figure 2. Label Information Base of LSDR A, LSR C and LSR E
The black arrows in Figure 1indicate that Node C sends to Node A an LDP message that the packets for IP Network 10.0.x.x should be assigned a label of 100. Node A in turn, sends Node E an LDP message that the packets for the IP Network 10.0.x.x should be assigned a label value of 101. The gray rows indicate that the label assignment is completely a local issue and the same label MAY be advertised to two peers on different interfaces. The black rows indicate a possible looping of packets if sufficient care is not taken during label assignment.
3 2 2 3 3 2 3 4 1 3 2 1 1 1 1 Net. 40.0 Net. 30.0 Net. 10.0 Net. 20.0 ATM LSR A Edge LSR E Edge LSR B Edge LSR C Edge LSR D Routing Table Label Table Incoming Outgoing FEC Next Hop Out Port label port label port - E1 103 E3 X E2 103 E3 10.0.x.x
A
E3 ? E3 ? E2
Routing Table Label Table Incoming Outgoing FEC Next Hop Out Port label port label port 101 A1 100 A3 104 A4 100 A3 10.0.x.x
C
A3 102 A2 100 A3
Routing Table Label Table Incoming Outgoing FEC Next Hop Out Port label port label port 100 C2 - C1 10.0.x.x
LSR E - Label Information Base LSR A - Label Information Base LSR C - Label Information Base MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 4 4. Benefits of MPLS 4.1 Multiprotocol Support MPLS is capable of multiprotocol support since the FEC classifications can be based on the network layer protocols and their associated routing protocol information. Though the initial effort in the standardisation of MPLS has been focused on IPv4 and IPv6, the MPLS working group aims to extend the support to network layer protocols also such as IPX, AppleTalk, DECnet and CLNP. 4.2 Link Layer Independence MPLS is intended to work with any type of link layer medium such as ATM, Frame Relay, Packet-over- SONsET, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring and FDDI. However, the labels for FEC classification in each of these cases would be link layer specific.
Figure 3. MPLS Deployment in Various Networks 4.3 Increased Performance MPLS enables higher performance due to simplified packet forwarding and switching decisions. MPLS based routers can implement look-up and forwarding capabilities using hardware techniques. 4.4 Explicit Routes One of the important features of MPLS is its support for explicit routes. An explicit route is a route that has not been set-up by normal IP hop-by-hop routing; rather an ingress/egress node has specified all or some of the downstream nodes of that route. Though this is very similar to IP source routing, the benefit of MPLS is that there is no overhead of header processing for each packet. In addition, explicit routes also provide some of the functionality needed for Traffic Engineering, QoS/constraint routing etc.
R R R R R R R R ATM FR Ethernet R LER LSR MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 5 4.5 Traffic Engineering Traffic engineering refers to the process of selecting the paths chosen by data traffic in order to balance the traffic load on the various links, routers, and switches in the network. This has gained importance because of the rapid growth of the Internet and the corresponding demand for bandwidth.
The key performance objectives of traffic engineering can be classified as 1. Traffic oriented, which includes those aspects that enhance the QoS of traffic streams and 2. Resource oriented, which includes those aspects that pertain to the optimization of resource utilization. Today in IP over ATM networks, traffic engineering is typically done by manually configuring the path of each PVC, in order to optimize the traffic levels on different links in the network.
The nature of MPLS by its definition can be exploited for achieving effective Traffic Engineering. The explicit routed label switched paths (each mapping to a particular traffic trunk) can be easily created through manual administrative action or through automated action by the underlying protocols. Some of the inherent advantages of MPLS for TE are: 1. The explicit routed LSPs can be associated with one of the many traffic trunk attributes available in MPLS for supporting different type of traffic. 2. The basic operations such as establishing, activating, deactivating, modifying attributes, rerouting and destroying a traffic trunk can be performed on an explicitly routed LSP. 3. Streams from any ingress node to any egress node can be individually identified. This provides a straightforward mechanism to measure the traffic flow between each ingress-egress node pair and hence meets the accounting requirement of Traffic Engineering.
4.6 Aggregation of Streams Normally, when multiple streams have to be aggregated for forwarding into a switched path, processing is required at both Layer 2 and layer 3. In MPLS, however, the Label stacking mechanism can be used to perform the aggregation within Layer 2 itself.
The top label of the MPLS label stack is used to switch packets along the label switched path. The rest of the label stack is "application specific" and could be used to switch packets at the ingress and egress of the label switched path.
Virtual Private Networks is one such application which uses the Label stacking mechanism (see Figure 4). At the VPN ingress node, the VPN Label is mapped onto the MPLS Label stack (L B ) and packets are label- switched along the LSP within the VPN (using L T1 , L T2
etc.), until they emerge at the egress. At the egress node, the label stack (L B ) is used to determine further forwarding of the packets. Thus, the label switched path mechanism is used to establish a tunnel through the MPLSaware network.
MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 6
Figure 4. VPN Realisation with MPLS Label Stacking 4.7 Scalability of Network Layer Routing
One of the basic requirements considered in the definition of the MPLS solution was to achieve a better and efficient transfer of datagrams in the current IP networks. Today, a number of current IP networks are being upgraded for ATM for increased performance (refer Figure 5). However, since this implies an overlay model, there are issues of scalability, network performance and administration overheads: Each router must form an adjacency with the other routers. This results in less than optimal performance of the routing protocols. A large number of control ATM Virtual Circuits (VCs) also need to be established for creating a fully meshed network to enable connectivity between each routers. The maintenance of these VCs is a major overhead. Figure 5. IP Over ATMOverlay Model
Combining the routing knowledge at Layer 3 with the ATM Switching capability in ATM devices result in a better solution. In the MPLS scenario (refer Figure 6), it is sufficient to have adjacencies with the immediate peers. The Label Edge Router (LER) interacts with the adjacent LSR and this is sufficient for the creation of LSPs for the transfer of data. In this model, the overhead of the Control VC creation and its maintenance does not exist, the number of peer adjacencies are fewer and routing tables are smaller. Figure 6. IP Over ATM using MPLS
R R R R MPLS LSP1 MPLS LSP2 PDU LB LT5 PDU LB LT1 PDU LB LT2 PDU LB LT4 PDU LB LT3 R LER LSR R R R R R Router ATM Switch R R R R R LER LSR MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 7 4.8 Support for Multiple Types of Traffic MPLS supports all types of forwarding: unicast unicast with type of service multicast packets.
It also improves upon the various methods that are used for integrating IP with ATM-based subnetworks. 5. Deployment Scenarios
MPLS deployment is required both in the backbone devices (routers and switches) and the edge devices of the network. MPLS support at the backbone device enables faster transfer of the application data (IP packets) by utilizing the Layer 2 Switching support, as well as providing the required QoS. MPLS support at the edge devices provides the classification of the application data into suitable FECs and ensures that LSPs are created for different FECs. Hence, when the application data leaves an edge device, it is label switched along the complete data path until its destination.
The MPLS in the Edge device and the Backbone devices can be configured to label Switch data flows based on 1. The packets destination address 2. Destination address and service qualities like Best of Effort required for the data 3. Explicit routes 4. Constraint-based routes.
A few examples of where the MPLS deployment can be leveraged are included below: 5.1 Enabling Different Applications with different QoS The initial deployment of the MPLS is expected to be over the ATM backbones. In these MPLS networks, the LSRs and LERs being ATM in nature, can allocate QoS to the different user requirements and map them to the ATM QoS.
As the LER is the ingress to the ATM cloud, it is responsible for efficiently classifying the IP flows and mapping to the ATM QoS. The flow classification being the critical requirement, it can be designed and used as an ASIC in an LER.
Figure 7.MPLS NetworkApplications Requiring Different QoS
The applications requiring QoS can be generally classified into High-priority services: mission critical services that are high priority and delay sensitive in nature. This type of traffic can be sent on ATM VCs having Constant Bit Rate (CBR). Normal-priority services: constant rate, interactive, delay-sensitive voice; variable rate, interactive delay-sensitive IP-telephony; and variable rate, non-interactive non-delay-sensitive WWW file transfer. This type of traffic can be sent on ATM VCs having Variable Bit Rate (VBR). Best-effort lower-priority services: variable rate, non-interactive, non-delay-sensitive voice mail, email, and file transfer. This type of traffic can be sent on ATM VCs having Unspecified Bit Rate (UBR). 5.2 Traffic Engineering and MPLS The data path in a network traversed by an application data from the source to the destination is determined by the routing protocols. The routing protocols (RIP, OSPF, IS-IS, BGP etc.), determine the best path(s) to reach a destination. At times, the best path determined by these protocols become overloaded. Since the parameters (link costs) used by the routing protocols in
R R R R R LER LCR MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 8 the calculation of the best path(s) are generally configured by the Network Manager, there is a considerable overhead in dynamically configuring the parameters to determine the best path(s), to circumvent this overloading.
The Network Manager can selectively avoid this problem by creating explicit data paths. The explicit path is usually different from the best path computed by the routing protocols. Explicit path definition is done for effective load balancing and to provide the QoS support required by the application.
MPLS inherently provides support for the creation of explicitly routed paths called Constraint Routed Label Switched Paths (CRLSP). It is possible to create and maintain Label Switched paths utilising a series of explicit next hop LSRs or a series of LSRs that support a specified QoS. The Label Edge Router (LER), must have the knowledge to classify the FECs suitably and map them to the CRLSPs. The following figure illustrates an example of the CRLSP. Data from Application 1 is sent via the normal routed path. The data from Application 2 is sent via CRLSP.
Figure 8. MPLS DeploymentTraffic Engineering 5.3 VPNs and MPLS Virtual Private Networks is a solution typically offered by ISPs to enable corporate members to access their corporate network in a secure way from remote locations. A VPN network consists of authenticated and encrypted tunnels over shared networks such as the Internet. The tunnels are set up between a network access point and a tunnel-terminating device on the destination network. The function of the network access point is to encapsulate packets sent by the remote/mobile user so that the data travels securely over the shared network. Point-to-Point Tunneling Protocol (PPTP), Layer Two Forwarding (L2F) and Layer Two Tunneling Protocol (L2TP) are used to transfer data over the Internet in the VPN scenario.
The packets that travel in the VPN tunnels are IP packets (the packet destination address being the corporate network) and are forwarded on a hop by hop basis. The use of MPLS in the VPN scenario requires MPLS Tunnels (Label Switched Paths) created for the VPN data. The packets that are identified to traverse the VPN tunnel are now label switched based on the MPLS labels instead of hop by hop routing (refer Figure 4). The network access point device (from which the VPN tunnel originates), maintains a mapping between the VPN tunnel identifier and the ingress MPLS label of the LSP and forwards the packets into the tunnel as labeled packets. 6. Other IP Switching Solutions
Many proprietary solutions have been defined to address some of the problems the IP network faces today. All these solutions are primarily based on the following schemes: 6.1 Topology Based Solutions Examples of IP Switching defined on topology-based schemes are Cabletron's SFVN (Secure Fast Virtual Networking), Cascade's IP Navigator, Cisco's Tag Switching, DEC's IP packet switching, Frame Relay Technologies' Framenet Virtual WAN switching, and IBM's ARIS (Aggregate Route-based IP Switching). Products from all these vendors make forwarding decisions using either the destination IP address or a combination of the source and destination address in the IP header. As discussed, the Layer 3 address is mapped to a new header (either a MAC address or a VCI/VPI), and that header is used to forward the information at Layer 2 (in other words, all data is switched).
R R Application 1 Application 2 R LER LSR LSP CRLSP MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 9 6.2 Flow Based Solutions Examples of IP Switching defined on flow based schemes are ATM Forums MultiProtocol Over ATM (MPOA), Ipsilons Ipsilon Flow Management Protocol (IFMP) combined with General Switch Management Protocol (GSMP) and NECs IPSOFACTO- IP Switching Over Fast ATM Cell Transport.
The Interoperability of the MPLS solution with the above mentioned IP switching solutions has not been explored much in the industry. However, the experiences derived in the above mentioned flow based IP Switching schemes are utilised in enhancing MPLS capabilities. For example, IPSOFACTO is being used in defining a data-driven scheme for label assignment to set-up LSPs for both the dense-mode and the sparse mode multicast data. 7. MPLS and IETF
The Internet Engineering Task Force (IETF) has formed a working group (MPLS Working Group-MPLSWG) to define the architecture for MPLS. According to IETF, the architecture should be capable of enabling the MPLS solution to perform the following functions: To operate over any data link technologies and providing optimization for particular media if required To work with the existing inter-network technologies and routing protocols To operate independently of the underlying routing protocol and to suggest enhancements of the existing protocols to support MPLS in its label distribution To perform switch based labeling on a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations To be easily configured and maintained using Network Management To detect and prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops To operate in a hierarchical network.
The MPLS WG has come up with Internet Drafts 1. Defining the MPLS Framework 2. Describing the MPLS Architecture 3. Specifying the Generic Label distribution Protocol (LDP) to be used by the Label Switching Routers (LSRs) to exchange label information 4. Specifying the Label encapsulation technique to be adopted in Ethernet, PPP, ATM and Frame Relay networks 5. Specifying the State Event Machine to be adopted for the label bindings 6. Specifying the Constraint Routed Label Distribution Protocol (CRLDP) to handle conditions for the establishment of Constraint based Routed Label Switched Paths (CRLSPs) 7. Specifying the extensions to be made in the Resource ReSerVation Protocol (RSVP) towards the establishment of RSVP Tunnels and binding of labels with respect to the tunnels. 8. Specifying the extensions to the Border Gateway Protocol (BGP) for piggy backing MPLS Labels in BGP PDUs. 9. Specifying steps to be followed to ensure loop free LSP creation. 10. Specifying the Management Information Base for Label Distribution Protocol.
Most of the above mentioned drafts have stabilized considerably and are intended to be made into final specifications by the Working group. For additional information on the IETF MPLS Working group, refer http://www.ietf.org/html.charters/mpls-charter.html The IETF WG is working towards enabling MPLS solution To support Multicast data packets in addition to the Unicast packets To support QoS Requirements To be utilized in effective VPN realization
Though IETF WG drafts are not available for the above functionalities, several individual contributions have been made in this direction. For additional information on the individual drafts as well as for comparisons of MPLS with other IP switching solutions, refer to http://infonet.ainst-nara.ac.jp/member/nori-d/mr/ MPLS White Paper
In an effort to provide faster and reliable services for the exponentially growing IP networks, efforts are being made to reduce packet/data header processing when the data is forwarded. In the current MPLS solution, the entire IP header is processed at each router hop for forwarding.
MPLS enables the data flows to be grouped into FECs and assigns unique labels for each FEC. The data, when it flows in the network, will be switched/forwarded based on the short labels. MPLS enables the FEC classification to be done using several parameters including QoS expected by the user. Apart from offering the advantage of short label lookup, the MPLS solution is independent of the networking protocol at Layer 3 and the Layer 2 Data Link Layers as well. MPLS Support can thus be added to the existing IP devices with minimal hardware upgrades, thus enabling Internet Service Providers to offer more efficient services with less overhead.
Abbreviations and Acronyms
ATM Asynchronous Transfer Mode BGP Border Gateway Protocol CBR Constant Bit Rate CRLSP Constraint Routed Label Switched Path DLCI Data Link Control Identifier FDDI Fibre Distributed Data Interface FEC Forwarding Equivalence Class FR Frame Relay IETF Internet Engineering Task Force IP Internet Protocol IS-IS Intermediate System to Intermediate System ISP Internet Service Provider LDP Label Distribution Protocol LER Label Edge Router LSP Label Switched Path LSR Label Switched Router MPLS MultiProtocol Label Switching OSPF Open Shortest Path First PVC Permanent Virtual Circuit QoS Quality of Service RIP Routing Information Protocol RSVP Resource ReSerVation Protocol TCP Transmission Control Protocol UBR Unspecified Bit Rate UDP User Datagram Protocol VBR Variable Bit Rate VC Virtual Circuit VCI Virtual Channel Identifier VPI Virtual Path Identifier VPN Virtual Private Network
FutureMPLS source code product provides an efficient Label Switching component coupled with a robust implementation of the Label Distribution Protocol component. The product supports the following features: Basic Label Distribution Protocol (LDP) mechanisms: LDP neighbor detection LDP session initiation, maintenance and termination, including multiple links Loop detection. Supports all modes of label distribution: Downstream Unsolicited Independent Control Downstream Unsolicited Ordered Control Downstream On Demand Independent Control Downstream On Demand Ordered Control. Supports multiple Forwarding Equivalence Class (FEC) classifications based on: IP Address Prefix Host Address Host Address and Quality of Service. Supports efficient forwarding by choosing the best Label Switched Path (LSP) in case of multiple LSPs existing for a packet that is being forwarded. Supports both Basic Discovery and Extended Discovery mechanisms. Supports both Conservative and Liberal Label Retention mode. Supports Loop detection using Path vector and Hop counts. Supports creation and maintenance of constraint- based routed LSP (CRLSP). Supports interfaces to ATM and Ethernet networks Provides interfaces to RSVP to obtain Label assigned to RSVP flows assigned by RSVP. Provides Windows based simulation test tool that enables simulation, faster integration and debugging.
FutureMPLS Benefits
The Label Switching component of FutureMPLS derives the MPLS LabelsFEC binding information by choosing the required label distribution method either from LDP or from RSVP or from both. The LDP component of the FutureMPLS product provides support in the generic LSP creation in addition to the CRLSP creation. The RSVP component of the FutureMPLS product provides support for RSVP extensions to carry label binding information in RSVP messages and in the creation of the LSPs associated with the RSVP flows. FutureMPLS provides extensive SNMP Management support for easier configuration and maintenance of the FutureMPLS stack. FutureMPLS integrates seamlessly with other Future Software source code products like FutureIP/RIP, FutureOSPF, FutureTCP, etc. Conforms to the Future Software Architecture for Portability (FSAP2) architecture. FSAP2 provides flexible OS, buffer and timer management libraries which can be easily ported to any target. A Windows-based Test tool provides a set of test cases which are used to test the functionality of the FutureMPLS product. It also provides an effective graphical demonstration of the product features. Provides ongoing customized solutions for FutureMPLS based on customer based value- added specific requirements. The FutureMPLS source code product conforms to the latest IETF MPLS Drafts. The product will be constantly upgraded to conform to changed specifications if any. The product has been designed with generic interfaces and thus ensures backward compatibility with the earlier versions provided to the customers.
MPLS White Paper
Copyright (c) 1999-2001 Future Software Limited, India. Page 12
For More Information
Established in 1985, Future Software develops and markets a range of ATM, WAN access, IP Switching/Routing, Telecom signaling and Internet products along with Porting and Customization Services. Future also offers quality Software Project Services. A number of prominent equipment vendors from USA, Europe and Asia figure in Futures list of customers.
For more information, contact us at: Asia and rest of the world Future Software Limited 480-481 Mount Road, Nandanam Chennai 600 035 INDIA Tel: +91-(44)-433 0550 Fax: +91-(44)-434 4157 e-mail : [email protected] Website: http://www.futsoft.com
Americas Future Communications Software 4300 Stevens Creek, Blvd Suite 187, San Jose, CA 95129, USA. Tel : (408) - 243-3887 Fax : (408) - 243-0772 e-mail : [email protected] Website: http://www.futsoft.com
Europe Future Communications Software Limited Knyvett House, Suite 106, The Causeway, Staines, Middlesex, TW18 3BA, United Kingdom Tel: +44-(0)- 1784 898-590 Fax: +44-(0)- 1784 898-592 e-mail : [email protected] Website: http://www.futsoft.com