Multi Protocol Label Switching

20010817
Future Software Limited

480-481, Mount Road, Nandanam,
Chennai - 600 035, India.
Tel : +91-(44)-433 0550
Fax : +91-(44)-434 4157
e-mail : info@futsoft.com
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.

MPLS White Paper

Copyright (c) 1999-2001 Future Software Limited, India. Page 1
1. Overview

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

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

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

Hop
Out
101 A1 100 A3
104 A4 100 A3
10.0.x.x

C

A3
102 A2 100 A3

Hop
Out
100 C2 - C1
10.0.x.x

C

C1
100 C3 - C1
- C1 200 C3
20.0.xx

D

C3
202 C2 200 C3
- C1 302 C2
? C2 ? C3
30.0.x.x

A

C2
303 C3 302 C2
- C1 402 C2
? C2 ? C3
40.0.x.x A C2
403 C3 402 C2

LSR E - Label Information Base
LSR A - Label Information Base
LSR C - Label Information Base
MPLS White Paper

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

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


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

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

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

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

8. Summary

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

MPLS White Paper

Future Softwares MPLS
Solution FutureMPLS

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


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

Americas Future Communications Software
4300 Stevens Creek, Blvd Suite 187,
San Jose, CA 95129, USA.
Tel : (408) - 243-3887
Fax : (408) - 243-0772

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

Multi Protocol Label Switching

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Multi Protocol Label Switching

Transféré par

Droits d'auteur :

Formats disponibles

20010817

Future Software Limited

Vous aimerez peut-être aussi