|
Archive
Flanagan Consulting
Network Analysts and Consultants
"We Have the Experience"
-------------------------------------------------------------------------
ViewsLetter on Provisioning
16 Dec 2002 #12
-------------------------------------------------------------------------
IN THIS ISSUE:
>> WIN-A-BOOK CONTEST Results
>> How MPLS fits into provisioning, Part 3: Labels and Tables
============ + ===== + ===== + ===== + ============
[WON-A-BOOK CONTEST
We have our winners. The carrier service that has been completely
discontinued is Morse code telegraphy, not ISDN or party lines or X.25.
A
copy of "T-1 Networking" by William A. Flanagan is on the way to each
of
the first three readers who emailed the answer (two of the three are in
Canada).
"It was fun; we'll do this again."
If you didn't win, order a copy from our web site, under Publications.]
============ + ===== + ===== + ===== + ============
>>Analysis
IN MPLS, WHERE DO LABELS COME FROM,
AND WHY DOES IT MATTER TO PROVISIONING?
Last time we looked at the way Multiprotocl Label Switching (MPLS) behaves
like a virtual circuit network; that is, like frame relay or ATM
(OK,
like X.25 in some cases).
-- The label is the packet address the switch uses to determine where
and
how to send that packet.
-- Each switch/router (in general) changes the label on every packet it
handles.
-- The previous point means labels have only local significance, on a
link
between adjacent Label Switching Routers (LSRs).
-- An LSR keeps track of connections, associated labels, and the treatment
each packet should receive in a forwarding table (FT).
The FT is just a list in memory that's organized for quick lookups.
It
might be indexed by the values of the labels expected to be on arriving
packets--that way it's easier to find the appropriate table entry when
a
packet shows up. The table entry contains the new label to replace
the
one just looked up, the port where the packet should be sent out, and
handling procedures associated with this connection--most likely the
prioritization class and which queue to place it in.
All this is very simple and works well. The main task is populating
all
the forwarding tables with all the proper information to create the
logically linked hops that constitute a virtual circuit with the desired
"handling" parameters for each connection.
LSRs offer two basic ways to create these entries in the FT:
1. Manually, by an operator at the command line interface.
These entries
are static--the router leaves them in the table until later commands
delete or change them.
2. Automatically, calculated by the router from information provided
by a
routing protocol such as RIP, OSPF, IS-IS, etc.
A third method relies on a separate Network Management System (NMS).
This
workstation calculates a physical route from an inventory that represents
the topology of the network and (ideally) the utilization of each
component. The NMS creates a connection by sending messages to all
nodes
on the new path, instructing them to place labels and parameters in their
forwarding tables.
This centralized method isn't favored by many as it doesn't fit the
distributed model of Internet routers. The central NMS also poses
several
problems in scaling up in size: discovering and maintaining the
inventory, calculating large numbers of paths quickly, and distributing
new table entries across large numbers of nodes from various vendors.
On
the other hand, one NMS to coordinate an entire network can ensure high
utilization, avoid stranding assets, and offer better control and
security. This method has been used successfully in private TDM
networks.
For the present, most development work is going into method 2, based on
a
routing protocol (most interest is in Border Gateway Protocol, BGP) and
a
Label Distribution Protocol (LDP). That is, the routing protocol
reports
the number of hops, or some other metric for distance or cost, to reach
each destination from each outbound port on the switch or LSR. Routing
protocols operate continually, letting all participating routers know
about changes to the topology and conditions in the network.
When asked to set up a connection, the LSRs pick the "best" path, based
on
whichever metric it is using, to the specified destination. On each
link,
he upstream LSR (upstream with respect to the direction of the connection
setup) signals to the adjacent (downstream) LSR with a connection request,
via LDP: "I want to reach destination 'X' with a connection that
has
parameters 'K, L, and M'." Common parameters to specify include
throughput, latency, and loss ratio.
The downstream LSR on this link may accept the request, returning a label
it selects for the two LSRs to use on this link for this connection.
The
same label value may be in use by these nodes for different connections
on
other links, even between themselves.
The downstream LSR will reject the request if it lacks the resources to
deliver the parameters requested. The downstream LSR passes the
connection request to a node further downstream, requesting the same
parameters and a new label value, and so on to the destination LSR.
After the connection is set up, packets may flow between the end points.
Note that the MPLS Label Switched Path (LSP) is the same physical route
(nodes, ports, links) taken by a routed IP packet between the same end
points--the same routing protocol determines both.
So, if packets take the same path whether "routed" or "on an MPLS
connection," tell me again why we wanted to set up the LSP?
Most observers will admit there is not much gain from LSPs based on
standard routing. This is particularly true if the network is not
heavily
loaded and all traffic is treated the same.
MPLS is not necessary to prioritize packet types for "real time"
applications such as voice, video, and TDM circuit emulations. Marking
packets by setting bits in the Type of Service (ToS) field of the IP
header (also known as the Differentiated Service, DifServ, field) is
enough for routers to recognize those packets and give them priority on
outbound ports.
But LSPs based on BGP are automatic--making provisioning easier.
LSPs are
more secure because the local address is difficult to guess and nearly
impossible to spoof by a third party. For virtual private networks
based
on LSPs, provisioning based on BGP is easy for the carrier and provides
the same isolation from intrusion as FR or ATM connections.
The odd aspect of MPLS/BGP is that carriers seem to be accepting this
automation on IP networks where they have insisted on manual configuration
of virtual circuits over frame relay and ATM. FR and ATM switches
have
for years offered "switched virtual circuits" (SVCs). That is, an
end
point can signal the network to request a connection, on-demand, just
by
specifying the other end (destination). The network will set up
the SVC,
automatically optimizing the use of system resources, honoring the service
parameters in the connection request (throughput, delay, etc.), and
possibly establishing a stand-by path for failure protection.
A question exists as to whether existing FR and ATM networks (ATM in the
core) will be adapted to MPLS. The DLCI and VCC fields are defined
as
labels, if that's what you want to call them. Frame and cell forwarding
engines can't tell the difference between a "normal" packet and one in
which a "label" occupies the address field. All that's necessary,
then,
is to add routing and label distribution protocols to the control modules
in the FR and ATM switches. Then the nodes can use these protocols
to set
up virtual circuits based on the "best" route. LDP replaces whatever
inter-node signaling method the switch vendor originally designed
for
SVCs (FR and ATM standards define the user interface, not how the network
operates internally).
Sounds very much like SVCs, regardless of the type of switch (or router)
that is the LSR. But if MPLS is what it takes to automate the process
of
provisioning virtual circuits, maybe that's the best way forward.
An added benefit is that Generalized MPLS extends automation to cover
optical wavelengths and TDM channels (as on SONET networks), two other
types of networks where manual provisioning has prevailed. Given
its wide
acceptance, MPLS may be the ONLY way forward.
One argument for keeping manual setup is the perceived need for an
operator to control the physical path of a connection. The basic
routing
protocol doesn't offer that ability. However, there are extensions
to
routing protocols that do let an operator pin a connection to a path.
More on that next time.
LINKS
-- Visit www.flanagan-consulting.com when you need to write a White Paper,
create/present a seminar/tutorial, or strategically position
your telecom
product. We have that experience.
-- Your input is encouraged--ask a question or suggest a topic--email
info@flanagan-consulting.com
-- Special thanks to www.webtorials.com for hosting ViewsLetter.
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: 11 June 2003
|
