Trong mạng IP thông thường, các công trình mạng lưới khách hàng được kết nối với đường trục thông qua bộ định tuyến biên (Hình 1). Có rất nhiều loại mạng lưới khách hàng; Ví dụ, các mạng cục bộ (LAN), mạng lưới hoạt động truy cập công cộng để truy cập dialup (như công mạng điện thoại, PSTN), mạng truy nhập cố định cho người dùng tại nhà (như ADSL, ADSL), và LAN trong hạch ISP. Các bộ định tuyến biên được kết nối với nhau bởi một mạng lõi của thiết bị định tuyến và liên kết trong một ogy topol phù hợp với các nhu cầu giao thông. Các hệ thống tự trị (AS) là những tên miền mạng do nhà khai thác độc lập hoặc các bộ phận của một nhà điều hành mạng lớnđó, ví dụ, do hạn chế trong các giao thức định tuyến nội miền, đã được chia thành các phần độc lập. Các gói dữ liệu được chuyển qua các mạng dựa trên địa chỉ IP và các thông tin khác được mang theo trong header của mỗi gói. Các địa chỉ bao gồm một mạng lưới (prefix) và một phần máy. Mỗi mạng lưới khách hàng được xác định bởi một tiền tố địa chỉ duy nhất.
Trang 1Initially, the Internet was a tool for a
limit-ed community of agencies and R&D organi-zations, where such services as file transfer, e-mail and remote logon dominated How-ever, personal computers and the World Wide Web (WWW) have increased the use
of the Internet beyond all expectations Its widespread use and continuous growth are putting demands on the network’s ability to handle rapidly increasing traffic volumes
New types of application, such as video-conferencing, introduce new quality-of-service (QoS) requirements User groups with different requirements for availability and quality of service demand a differentia-tion of service offerings and tariffs
Given current technologies, the Internet cannot support these requirements Instead,
it offers a no-guarantees-given, best-effort service with software-based network-layer routing The potential of traffic engineering and aggregation is limited The multipro-tocol label-switching (MPLS) technology addresses these requirements:
• It integrates the label-swapping para-digm—switching cells when ATM is used as the underlying link layer—with network-layer routing
• It improves the price-per-performance of network-layer routing
• It facilitates scaleability through traffic aggregation
• It provides greater flexibility in the de-livery of new routing services, thereby im-proving the potential of traffic engineer-ing
• It supports the delivery of services with QoS guarantees
MPLS over view
Multiprotocol label switching, which is a technology for backbone networks, can be used for the Internet protocol (IP) as well as
for other network-layer protocols It can be deployed in corporate networks as well as in public backbone networks operated by Internet service providers (ISP) or telecom network operators
Conventional IP networks
In conventional IP networks, client net-works are connected to the backbone via edge routers (Figure 1) There are many kinds of client network; for example, local area networks (LAN), public access net-works for dial-up access (such as the public switched telephone network, PSTN), fixed-access networks for residential users (such as asymmetric digital subscriber line, ADSL), and LAN in ISP nodes
The edge routers are interconnected by a core network of routers and links in a topol-ogy that suits the traffic needs Autonomous systems (AS) are network domains run by independent operators or parts of a large operator network—which, for example, due
to constraints in the intra-domain routing protocols, has been divided into autonomous parts Data packets are routed through the network based on the IP address and other information carried in the header
of each packet The address consists of a net-work (prefix) and a host part Each client network is identified by a unique address prefix
The basic task of the routers is to forward packets as efficiently as possible from source
to destination To do this, each router needs information on the topology and status of the network, and where the egress of the re-spective destination is located (identified by the address prefix) Routing protocols are used for distributing such information within the network Common protocols for intra-domain routing are:
• RIP—a distance-vector protocol When distance-vector protocols are used, the nodes solely see the destinations that can
be reached through their respective neighbors as well as the cost of reaching them;
• OSPF—a state protocol When link-state protocols are used, each router dis-tributes information on itself, its neigh-boring routers, and attached client net-works throughout the autonomous sys-tem; thus, each node gets a complete pic-ture of the topology of the domain
Border routers with links to other domains (for example, to another ISP network) com-municate routing information across the border (where the border gateway protocol,
Multiprotocol label switching in ATM networks Göran Hågård and Mikael Wolf
The Internet, which is growing very fast, struggles to cope with an
ever-increasing number of users and traffic volume New applications and
com-mercial usage are introducing new requirements for quality of service and
service availability Multiprotocol label switching is a new technology being
standardized by the IETF that addresses these requirements While MPLS is
independent of the underlying link-layer technology, ATM cell switching
effectively supports the label-swapping paradigm of MPLS MPLS has also
become the prime candidate for IP-over-ATM backbone networks
Label switching is an application on Ericsson’s new ATM switch, the
AXD 301 The application is also used in the first product from a family of
label-switching routers from Ericsson
The authors describe the MPLS technology, and the implementation of a
label-switching router based on the AXD 301
Access network
AS1 AS2
AS3
LAN
LAN LAN
IP backbone network
Figure 1
Simplified model of a conventional IP
back-bone network.
Trang 2BGP, is the standard inter-domain routing
protocol) and distribute aggregated
infor-mation on the destinations that can be
reached through each respective
inter-domain link within its autonomous system
To allow different routes for traffic with
different service requirements, information
on the service-related properties of each link
can also be distributed A router that detects
any change in the network that affects
rout-ing information distributes information on
that change, thereby allowing other routers
to adapt their routing information to the
new conditions
With this routing information, each
router can calculate the optimal path or
route (and more specifically, the next hop)
for each forwarding equivalence class (FEC)
This term was introduced in the MPLS
stan-dards to denote packet-forwarding classes
A forwarding equivalence class may
com-prise traffic to a particular destination
(ad-dress prefix) or it may be more specific,
com-prising traffic to a destination with distinct
service requirements Thus, each router
builds up and maintains a forwarding
in-formation base (FIB), which is a table with
one row per forwarding equivalence class
One key attribute of a forwarding
equiv-alence class is the address prefix; however,
the key may also include other attributes
such as type of service (TypeOfService)
Using fields from the packet header as a
key, the forwarding function looks up data
stored in the forwarding information base in
order to determine the next hop, what link
to use, and which queue to use for that link
MPLS basics
The forwarding function of a conventional router involves a capacity-demanding pro-cedure that is executed per packet in each router in the network As line speeds in-crease, the forwarding function may consti-tute a bottleneck More efficient algorithms and data structures, faster processors and memory, and dedicated, application-specific integrated circuits (ASIC) are techniques for coping with this challenge in the forwarding engines of con-ventional routers
Multiprotocol label switching takes an-other approach, by simplifying the for-warding function in the core routers; that is,
by introducing a connection-oriented mech-anism inside the connectionless IP net-works In an MPLS network, a label-switched path (LSP) is set up for each route
or path through the network The edge routers
• analyze the header to decide which label-switched path to use;
• add a corresponding LSP identifier, in the form of a label, to the packet as it is for-warded to the next hop
Once this is done, all subsequent nodes may simply forward the packet along the label-switched path identified by the label at the front of the packet
AAL ATM adaptation layer
ABR Available bit rate
ADSL Asymmetric digital subscriber line
API Application program interface
AS Autonomous system
ASIC Application specific integrated
circuit
ATM Asynchronous transfer mode
BGP Border gateway protocol
CBR Constant bit rate
CLP Cell loss priority
CoS Class of service
ER-LSP Explicitly routed label-switched
path
ERO Explicit route object
FEC Forwarding equivalence
class
FIB Forwarding information base
GSMP General switch management
protocol
IETF Internet Engineering Task Force
IP Internet protocol ISP Internet service provider LAN Local area network LANE LAN emulation LDP Label distribution protocol LER Label edge router LIB Label information base LSP Label switched path LSR Label switch router MARS Multicast address resolution server
MPLS Multiprotocol label switching MPOA Multiprotocol over ATM mp-p Multipoint-to-point (path or con-nection)
NHRP Next-hop resolution protocol OSPF Open shortest path first OTP Open telecom platform p-mp Point-to-multipoint (path or con-nection)
PNNI Private network-network interface
PSTN Public switched telephone network QoS Quality of service
REH Resource handler RFC Request for comment RIP Routing information protocol RSVP Resource reservation protocol rt-VBR Real-time variable bit rate SPF Shortest path first STM Synchronous transfer mode STM-4 Synchronous transfer mode,
622 Mbit/s link TCP Transmission control protocol UBR Unspecified bit rate
UDP User datagram protocol UNI User network interface VBR Variable bit rate
VC Virtual channel VCI VC identifier
VP Virtual path VPI VP identifier WWW World Wide Web
LER
LSR LER
LER
LER
LER
LSR LSR
Figure 2 Label-edge routers and label-switch routers.
Box A
Abbreviations
Trang 3The connection-oriented principles in-troduced with MPLS not only allow the im-provment of the forwarding capacity of conventional routers, but also enable ATM and frame relay switches to be deployed as forwarding devices (Figure 2)
Establishing label-switched paths
Label-switched paths are controlled in a dis-tributed fashion Each node negotiates a label for each forwarding equivalence class with its upstream and downstream neigh-bors along the path By default, the down-stream node allocates a label for the for-warding equivalence class and informs its upstream peer This procedure makes use of the label-distribution protocol (LDP) of the MPLS framework As a result, each router builds a table, called a label information base (LIB), that maps the relationship between the link-specific label of each label-switched path and the corresponding forwarding equivalence class Whenever a change occurs
in the forwarding information base, the MPLS application re-negotiates the label-FEC binding and updates the label infor-mation base
In first-generation multiprotocol label-switching ATM networks, the default mode
of operation will be label binding on request from the upstream node The ingress node of each label-switched path then initiates the label-binding requests, which are
propagat-ed along the route to the egress node; the label-switched path is created as label bind-ings are propagated in the reverse direction
As a node negotiates labels with upstream and downstream nodes, it also stores infor-mation on outgoing links and labels for the forwarding equivalence class of the incom-ing links (Figure 4) Thus, a label-switched path is created for each forwarding equiva-lence class through the MPLS domain Be-cause each node may have many upstream nodes for the same destination or forward-ing equivalence class, the label-switched paths are typically multipoint-to-point paths
Forwarding principles
The ingress label-edge routers encapsulate the packets with an MPLS header, which contains the link-specific label at the front
of the packets The downstream nodes then
• use the label as an index to the label in-formation base for finding the outgoing link and the label for that link;
• swap the label in the MPLS header;
• forward the packet
The MPLS network architecture consists of label-switch routers (LSR), in the core of the network, and label-edge routers (LER) at the edge The label-edge routers have the task
of analyzing the IP header of each packet, in order to find the corresponding forwarding equivalence class and label-switched path, which facilitates the label-swapping func-tion in the label-switch router nodes The label-switched paths are established
as the result of the routing topology All traffic is forwarded along these paths This method differs from other IP-over-ATM technologies, where cut-through ATM con-nections are established for traffic flows identified by nodes in the network
MPLS in ATM networks
Conventional IP networks may be built by routers whose link technology is based on ATM The MPLS technology also enables node products to use ATM switches for the forwarding function Label-switch router nodes of this kind consist of an MPLS con-trol component (LSR-CC) and an ATM switch The LSR-CC handles network-layer functionality, such as routing protocols, and label-management functions, which in-clude the label-distribution protocol The forwarding information base and the label information base also compose part of the LSR-CC
An ATM connection is set up for each label-switched path The labels are used as virtual-channel-identifier (VCI) values, as virtual-path-identifier (VPI) values, or both, on each link along the path When the upstream and downstream label-FEC bind-ing is complete for a label-switched path, the LSR-CC can request a corresponding ATM connection through its node between upstream and downstream label or virtual channel identifier While this is performed
in the nodes along the path, the ATM con-nection is set up from the ingress to the egress edge routers along the switched path Therefore, only the label-edge routers at the end of the label-switched
C A
LAN
R3 R1
R2
R4
B
1 2
3
Figure 3
Illustration of the use of the forwarding
infor-mation base and the label inforinfor-mation base.
Figure 4
Example label information base and
forward-ing information base for R4 in Figure 3.
IL Incoming label
OL Outgoing label
IIf Incoming interface
OIf Outgoing interface
A
B
B
C
FIB
X
X
Y
X
A1 B1 B2 C1
R1 R2 R2 R3
1 2 2 3
LIB
A1
A1
B1
B2
B1
B2
C1
C1
BL1
CL1
AL1
AL2
CL2
CL3
BL2
AL3
2 3 1 1 3 3 1 2
AL1 AL2 BL1 BL2 BL3 BL4 CL1 CL2
1 1 2 2 2 2 3 3
Trang 4path are required to perform layer-3
for-warding
Label-switched paths are typically
point-to-point (mp-p) paths In a
multi-protocol label-switching ATM network,
this translates into multipoint-to-point
connections without interleaving cells from
different frames—a facility called
virtual-connection merging This type of
connec-tion has not yet been defined in standards
The present generation of ATM switches
will use point-to-point label-switched
paths from each ingress node As
virtual-connection merging is introduced,
the scaleability of multiprotocol
label-switching ATM will improve
Label stacks and tunnels
To allow label-switched paths to cross one
or more autonomous systems, the MPLS
ar-chitecture provides a mechanism for
tun-neling an inter-domain label-switched path
between two border routers through an
intra-domain label-switched path The
tun-nel LSP is set up via intra-domain routing
mechanisms, such as OSPF, whereas the
tunneled inter-domain label-switched path
is set up via the inter-domain routing
func-tions in the border routers While in
tran-sit through the tunnel, the MPLS packet
header contains a stack of two labels: one for
the intra-domain routing, and one for
car-rying the inter-domain label through the
tunnel In multiprotocol label switching
ATM networks, the tunnel label is mapped
onto the VPI field and the inter-domain
label is mapped onto the VCI field The core
routers of the autonomous systems switch
the virtual paths for the tunnel LSPs, and
the border nodes switch the virtual
chan-nels
Traffic management and QoS support
For the label-switched paths of
best-effort traffic, the unspecified bit rate (UBR)
or available bit rate (ABR) service classes
provide suitable service When ABR is used,
a minimum bandwidth may be allocated to
each label-switched path, if needed
In some cases, best-effort traffic is
divided into classes in order to provide some
kind of differentiated treatment in the
net-work Traffic classes may be defined for
traf-fic with specitraf-fic delay requirements (for
example, for real-time applications,
interac-tive applications and file transfers) or for
allocating a share of the resources along the
path In MPLS, these traffic classes are
identified through a class-of-service (CoS)
code associated with the label-switched path
Ingress label-edge routers use filters to as-sociate traffic with service classes These fil-ters, which are defined when the network is configured, operate on IP header fields such
as type of service (TypeOfService), protocol, port, and source address The derived class-of-service value is then included in the MPLS encapsulation header together with the label
In multiprotocol label-switching ATM domains, the class-of-service values inside the ATM-adaptation-layer (AAL) frames are not readily available for the forwarding function of the label-switch router Instead, parallel label-switched paths and the corre-sponding ATM connections are set up with properties suitable for the service class The class-of-service value of the label-switched paths is communicated via the label-distribution protocol when the label is bound The real-time variable bit rate (rt-VBR) may be used for delay-sensitive ser-vice classes; ABR may be used for support-ing link sharsupport-ing
Explicit routes
Label-switched paths typically follow the shortest path from source to destination In some cases, for reasons of administrative pol-icy or for traffic engineering, operators may want to control the routing of traffic By means of an explicit routing facility, the MPLS architecture enables operators to de-fine in detail the path of specific traffic The ingress label-edge router then sets up a cor-responding label-switched path through the MPLS domain According to current pro-posals, the label-distribution protocol or the resource-reservation protocol (RSVP) may
be used to set up explicitly routed label-switched paths (ER-LSP) Two new object types are introduced in RSVP for operation
in MPLS networks: an explicit route object (ERO), which carries the explicit route de-scription; and a label object for binding the label of the RSVP-controlled path The se-lection criteria, which define what traffic is
Figure 5 Label-switched paths established from edge
to edge.
Trang 5mapped onto the label-switched path, need only be known by the ingress label-edge router The use of the resource reservation protocol also implies that RSVP mecha-nisms may be used for allocating resources and QoS properties to the explicitly routed label-switched paths
RSVP in MPLS networks
An integrated-services framework has been specified by the Internet Engineering Task Force (IETF) for sessions whose quality-of-service requirements exceed best-effort ser-vice The framework includes the RSVP pro-tocol for reserving resources for session flows and a set of services The services that have been specified to date are controlled load and guaranteed quality of service
Two basic message types have been de-fined for the resource-reservation protocol
A PATH message is sent from the source to announce a flow It conveys a traffic de-scriptor (in the form of token bucket para-meters—much the same as for ATM), and
is routed through the nodes of the IP net-work to the destination To reserve resources for the flow (for example, bandwidth on links), the recipient returns an RESV mes-sage along the same path
The RSVP messages are processed by the MPLS nodes—edge routers and label-switch routers—along the path As a result
of the RESV messages, a label-switched path and a corresponding ATM connection are set up through the MPLS domain As the RESV message is processed, the label-edge router and LSR-CC
• transform the RSVP traffic descriptors into the corresponding ATM parameters (CBR, VBR and ABR provide appropri-ate service for these connections);
• allocate a label before the message is prop-agated upstream to the source;
• connect the label-switched path ATM connection through the node
The label is propagated to the upstream node in a label object contained in the RESV message
Although the RSVP specification has been available for some time, it is not yet widely deployed The present generation of routers, which are optimized for best-effort traffic forwarding, are not suited for han-dling large amounts of flows in a connection-oriented fashion Multiprotocol label-switching ATM, however, offers a highly scaleable RSVP solution
Real-time multicast sessions are expected
to become one of the first applications to use the resource reservation protocol In multi-protocol label-switching ATM networks, the ATM point-to-multipoint connection will be used in much the same way as for multicast functions The branching nodes may be situated at the label-edge router as well as at label-switch router nodes The RSVP framework also comprises sessions with multiple senders; that is, multipoint-to-multipoint sessions Until support is pro-vided for multipoint-to-point connections
in ATM, merge points will have to be lo-cated outside the multiprotocol label-switching ATM domains or in label-edge router nodes
Box B
MPLS standardization work
The MPLS working group within the IETF is
standardizing the basic technology for
using the label swapping forwarding
para-digm in conjunction with network layer
rout-ing and for implementrout-ing that technology
over various link-level technologies, which
may include packet-over-Sonet, frame
relay, ATM, Ethernet (in all its forms), and
token ring.
Their work includes procedures and
proto-cols for the distribution of labels between
routers, encapsulations, multicast
consid-erations, use of labels for supporting
high-layer resource reservation and QoS
mech-anisms, and the definition of host behavior.
Their objectives are:
• to specify standard protocol(s) for the
maintenance and distribution of label-binding information, to support unicast destination-based routing with forwarding based on label-swapping;
• to specify standard protocol(s) for the maintenance and distribution of label-binding information to support multicast routing with forwarding based on label-swapping;
• to specify standard protocol(s) for the maintenance and distribution of label-binding information, to support the hier-archy of routing knowledge (for example, the complete segregation of intra- and inter-domain routing) with forwarding based on label-swapping;
• to specify standard protocol(s) for the maintenance and distribution of label-binding information, to support explicit paths that differ from the path con-structed by destination-based forwarding
with forwarding based on label-swapping;
• to specify standard procedures of carry-ing label information over various link-level technologies;
• to specify a standard way of using the ATM user plane,
a) allowing operation/coexistence with a standard (ATM Forum, ITU, etc.) ATM control plane and/or standard ATM hardware;
b) specifying a label-swapping control plane;
c) taking advantage of possible modifi-cations/improvement in ATM hard-ware; for example, the ability to merge virtual channels;
• to discuss support for QoS (for example, through the RSVP);
• to define standard protocol(s), to allow direct host participation (for example, by
a server).
Trang 6Differentiated services
Given the problems of scaleability
current-ly found in the integrated-services
frame-work, a new set of services is being studied
by the IETF The objective is to provide
ser-vice and the corresponding tariff
differenti-ation with which to fulfill the immediate
needs of business and residential users The
work has just begun, but the service model
will most likely be based on static service
profiles of users, defining the capabilities of
the subscriptions (such as bandwidth),
network-edge functions that police the
pro-file, and tag packets as they enter the
net-work The tagging of packets, which
classi-fies traffic according to delay requirements
and by value or importance, is used by core
routers for scheduling, handling congestion,
and so forth
MPLS flows with different delay
require-ments may be mapped onto label-switched
paths and the corresponding LSP-ATM
con-nections with different classes of service and
priority Tags that denote value and
impor-tance may be translated into cell-loss
prior-ity tags
Multicast functions
To support distributive and multiparty
ser-vices, IP networks provide multicast
capa-bilities A separate address suite has been
dedicated to multicast services A main
ob-jective of these service is to save network
re-sources by creating copies of each packet as
close to the receivers as possible Therefore,
multicast trees are built up for each service
as recipients announce themselves During
configuration, the trees may be rooted at the
sender or at defined root node for the
mul-ticast group A separate set of routing
pro-tocols, optimized for different network and
multicast situations, has been defined for
this purpose The nodes—label-edge
routers and label-switch routers
(LSR-CC)—of an MPLS network that is to be used
as part of multicast trees must implement
the multicast routing protocols used in the
network
As the topology of a multicast tree is
cre-ated and changes, a point-to-multipoint
label-switched path is built up in a similar
manner as for a unicast label-switched path
In multiprotocol label-switching ATM, a
corresponding ATM point-to-multipoint
connection is also created using the same
principles as for unicast label-switched
paths and using the ATM
point-to-multipoint capability found in the
branch-ing label-switch router nodes
Ships in the night
Multiprotocol label switching can also be deployed in an ATM network that is used for other ATM services that use user-network-interface (UNI) or private-network-network-interface (PNNI) signal-ing for connection control In the MPLS lit-erature, this kind of configuration is named
ships in the night Resources must be
dedi-cated to the MPLS application through con-figuration in each node The allocation of resources is accomplished with different de-grees of granularity Nodes can be
dedicat-ed to function as label-switch routers In mixed nodes, interfaces or even partitions of interfaces (bandwidth and VCI/VPI ranges) may be allocated to the MPLS service
Implementation
In the AXD 301, multiprotocol label switching is implemented as a software sub-system, allowing nodes to run as either a pure MPLS node, or as a ships-in-the-night node
The MPLS subsystem, which is divided into several blocks (Figure 7), has two im-portant interfaces to the underlying system:
one interface is used for controlling the switch via the basic ATM connection-control services module1; the other interface uses AAL5 for traffic to and from MPLS peers
MPLS
Basic AXD 301 system modules Fig 6
Multiprotocol label switching and other appli-cations on top of the basic AXD 301.
TCP/IP Routing
protocol
L3F FIB
LDP
AAL5
REH
Basic ATM connection control services module
LIM
Fig 7 System structure.
Trang 7Connection control API
The connection-control application pro-gram interface (API) of the AXD 301 allows the MPLS subsystem to control the switch:
it allows multiprotocol label switching to establish and release point-to-point connec-tions across the switch, add and delete leaves
on point-to-multipoint connections,
speci-fy quality-of-service requirements for the connections, and receive port status infor-mation
Several switch vendors support the gen-eral switch management protocol (GSMP).2
The connection-control API of the AXD 301 contains primitives similar to those supported by the general switch-management protocol, which makes it pos-sible to port the MPLS application to other switches—provided they support GSMP
However, the AXD 301 implementation deviates somewhat from the GSMP, which presupposes that the controller and the ATM switch are two separate boxes con-nected via an ATM link Therefore, in the AXD 301, the adjacency protocol for syn-chronizing the controller and switch has been cut out
The GSMP is a single protocol for control plane and management plane operations
Since the management of the MPLS subsys-tem adheres to the management of the AXD 301, the GSMP primitives that relate
to operation and maintenance are not im-plemented in the API
Moreover, the GSMP does not differenti-ate between point and point-to-multipoint connections, although in most existing ATM switches, including the AXD 301, resource requirements differ for the two types of connection Therefore, to fully exploit the switch, the API offers a primitive for establishing pure point-to-point connections
The GSMP approach to quality of service assigns a level of priority to each connection For virtual-channel connections that share the same output port, it is assumed that an ATM cell on a high-priority connection is more likely to exit the switch before an ATM cell on a low-priority connection, provided they are in the switch at the same time Clearly, this approach is inadequate if throughput and delay-related guarantees must be given to a label-switched path; therefore, the API augments the QoS capa-bilities of the GSMP
Initially, the AXD 301-based implemen-tation of the interface will map all best-effort traffic to the UBR traffic category Since control traffic, such as routing-protocol traffic and label-distribution-protocol traffic, must get through—espe-cially when the network is congested—it will be possible to map control traffic to high-priority traffic classes; for example, to the CBR traffic class
The resource handler (REH), which keeps track of available bandwidth and VPI and VCI values for the switch interfaces, offers primitives for setting up and releasing con-nections through the switch Since the re-source handler serves other subsystems be-sides MPLS, it can be used as a coordinator for running ships-in-the-night; that is, co-existing applications In that case, a small amount of available capacity is allocated to each UBR connection, thereby ensuring that the other subsystems do not use up all available bandwidth
Label distribution and LSP establishment
The label-distribution protocol is used for distributing label bindings Drafts pub-lished to date indicate that the user data-gram protocol (UDP) is used for carrying a neighbor discovery protocol while the trans-mission control protocol (TCP) is used for distributing the label bindings
The routing protocol that runs on the MPLS node may vary depending on how the node is deployed Initially, OSPF is used for intra-domain routing
Routing computations are often quite ex-pensive OSPF uses the shortest-path-first (SPF) algorithm (also known as Dijkstra's algorithm) to compute the best route for each destination The algorithm puts a com-putational burden on the system, which may potentially interfere with the establishment
of the label-switched path
The FIB block generates events that
cor-Box C
IP over ATM
Many solutions have been proposed for
run-ning IP over ATM:
• Classical IP, defined by the IETF, is a way of
building logical LANs on top of ATM.
• LAN emulation (LANE), defined by the ATM
Forum, is a way for an ATM network to
emu-late a logical Ethernet or a token ring
seg-ment.
• Next-hop resolution protocol (NHRP), defined by the IETF, is a way of intercon-necting logical LANs over ATM.
• Multicast address resolution server (MARS), defined by the IETF, supports mul-ticast over ATM.
• Multiprotocol over ATM (MPOA), defined by the ATM Forum, integrates LANE and NHRP into a unified whole for use within private networks.
Several attempts have been made at pro-moting proprietary solutions.
Trang 8respond to changes in topology When the
routing protocol inserts a new entry, deletes
an entry, or updates an existing entry in the
forwarding information base, the FIB block
generates a corresponding event The event
is received by the label-distribution
proto-col, which then acts accordingly; that is,
• if a new entry has been added, it
estab-lishes a new label-switched path;
• if an entry has been deleted, it releases the
corresponding label-switched path;
• if an entry has been updated, indicating a
new route to the destination, it
re-establishes the label-switched path
The LIM block manages the label
informa-tion base, keeping track of the relainforma-tionship
between a label binding at an incoming
in-terface and a label binding at the outgoing
interface for each forwarding equivalence
class This relationship corresponds to a
con-nection through the switch—from the
VPI/VCI of the binding at the incoming
in-terface to the VPI/VCI of the binding at the
outgoing interface The LIM block keeps
these connections current with existing
label bindings
Layer-3 forwarding
The L3F block is responsible for forwarding
unlabeled traffic In normal operation, all
traffic in the MPLS network runs over
es-tablished label-switched paths However,
there are situations where unlabeled traffic
may enter the network:
• When the edge router has not yet
estab-lished a label-switched path for traffic and
the router permits unlabeled traffic to pass
• An interface fails, making it impossible
for labeled traffic to exit the node through
the interface; therefore, to avoid
black-holing packets, they are handled by the
L3F block
• A node in the core network has
aggregat-ed several prefixes that exit the network
through different edge routers—in which
case the L3F block must look up the
layer-3 address to find the correct
outgo-ing interface at the node
All unlabeled traffic runs over a default
VPI/VCI Thus, the task of the L3F block is
to look up the layer-3 address of incoming
packets in the routing table in order to
de-termine which outgoing interface the
pack-et should use for exiting the node By
ex-tending the look-up function to return both
the outgoing interface and the outgoing
VPI/VCI, the L3F block effectively performs the role of an edge router
The layer-3 forwarding function is con-nected to the TCP/IP block for traffic that terminates in the node itself and for unla-beled traffic that originates in the node
Availability
The AXD 301 gives the MPLS subsystem traditional telecom characteristics, such as robustness and high availability
The use of the Erlang programming lan-guage and the open telecom platform (OTP) lay the foundation for a system with high-quality software
The dual central processors and control system of the AXD 301 distribute func-tionality so that the capacity-demanding routing-protocol computations do not in-terfere with the establishment of label-switched paths; that is, the routing-protocol block and the LDP block are allo-cated to different central processors
The forwarding information base is repli-cated on each central processor Thus, if one processor fails, the MPLS blocks running on that processor move to the other processor without having to build up the forwarding information base from scratch (which would
be comparable to restarting the MPLS node)
When the failed processor is taken back into service, the routing-computation function moves to it, leaving the label-switched-path handling undisturbed
Conclusion
Offering support of emerging new services with requirements for throughput and the bounds of delay, and by offering extended traffic-engineering possibilities, multipro-tocol label switching addresses many of the problems currently inherent in the Internet
By using ATM as a link technology, the fundamental label-swapping paradigm is supported by hardware The forwarding functions in MPLS networks can then lever-age the price-per-performance properties, throughput, and quality-of-service features
of ATM switching
Multiprotocol label switching is primar-ily a solution for IP-over-ATM backbones
Its implementation on the AXD 301 gives MPLS nodes traditional telecom character-istics, such as robustness and high avail-ability
References
1 Blau, S and Rooth, J.: AXD 301—A new generation ATM switching system Ericsson Review 75(1998):1,
pp 10-17
2 Newman et al.: Ipsilon’s General Switch Management Protocol Specifica-tion, RFC 1987, August 1996.