ViewsLetter(SM) on Provisioning

Site Map



 Flanagan Consulting                 Network Analysts and Consultants
                                                  "We Have the Experience"
ViewsLetter on Provisioning                 19 May 2003                #23
A fortnightly look at provisioning automation--chips to business software.

-- Automating IP VPNs:  Isolation by the Service Provider
-- This issue sponsored by [information, links at end]:
    = Primal Technologies automated phone conferencing platform for carriers
    = MPLScon--The Enterprise-Focused MPLS Event, NYC, 19-22 May 2003


    --By William A. Flanagan, Editor and Publisher

Last time we noted that much of the hope for automated provisioning lies on the assumption that the carrier's network will be "IP-based."  Carriers and hardware vendors have sold the "IP Virtual Private Network" (IP VPN) on a public (shared) network as the next big idea.  The previous ViewsLetter described VPN "Privacy" based on encryption.  This issue deals with operational methods that isolate one VPN user's traffic from all others'. 


Not long ago, a private line--that is, a dedicated or leased line--was considered secure for most applications.  Banks, brokers, the military, and "spooks" added encryption, but most enterprises believed separate circuits offered sufficient protection from other users of a public transmission network. 

Private lines are private because outsiders can't read from or write to them.  Only the service provider (or in some cases, such as dial-up, the end user) can create them or connect to them.  Time Division Multiplexing (TDM) and circuit switching offer strong separation for every connection.

In an IP VPN, packet switching present a quite different situation.  IP routers and switches touch all the packets of all connections passing through.  In a sense, all the connections mingle with each other.  Isn't that a "security risk"?  Maybe.

What can service providers do?  They apply several separation techniques. 


One of the earlier methods, still in use, is to fall back on TDM privacy and put each customer's IP traffic on a separate set of TDM circuits.  In practice, the SP places bridges and routers on dedicated local loops linked by TDM circuits to make a virtual LAN service.  This approach makes it easy to add data to a traditional synchronous digital network designed for voice.  On the other hand, the method doesn't scale up to large data networks because the core offers only point-to-point circuits. 

Switching packets tends to mix them, particularly with bridges that broadcast packets and don't filter or learn where connections go (Layer 2 broadcast methods are little used any more--service providers today operate mostly at the IP layer, Layer 3).  A Virtual Local Area Network (vLAN, defined by IEEE 802.1 p and q) puts identifiers in a field of each IP packet header.  A physical port is associated with a specific vLAN.  If a router knows about vLANs, it can prevent packets that don't have the proper identifier from reaching a particular port.  That's pretty good separation.  But if the router isn't configured for a vLAN, or is misconfigured, the result isn't necessarily what's wanted.   VLANs also have a smallish address space, limiting the number of separate customers to about 4000. 

Frame Relay and ATM (cell) networks extend virtual circuits (VCs) to the customer premises equipment (CPE), which is how some SPs create VPNs with managed routers.  The customer sees only Ethernet ports into a routed IP service;  inside the public network, each customer connection is a different VC so they stay separated. 

Multiprotocol Label Switching (described in ViewsLetter 10 last November) offers Label Switched Paths (LSPs) similar to VCs in most respects. 

Any type of virtual circuit (FR, ATM, MPLS) separates customers, but may face the same scalability problem that TDM circuits have.  To grow a data network more efficiently, the core needs to switch IP packets. 

Next time we'll look at where in a network each VC type operates and how a VPN does IP routing and switching.

This Issue's Sponsors:
============ + ===== + ===== + ===== + ============

    Can't bill?  Why bother!  Primal understands carriers' needs
to generate revenue as well as provide a service.  The family of
Primal Service Node products not only supports multiple applications,
it generates Call Detail Records for your existing billing system. 
Flexible conferencing has dial in and out, prepaid, toll free access--
all under real-time control of each conference chairman. 
    All PSN models give each customer a unique conference bridge number,
And a choice of many other applications, including voice mail, Prepaid,
IVR, unified messaging, and voice over IP.
    Get details at

============ + ===== + ===== + ===== + ============

MPLScon - May 19-22, 2003 - New York City
    MPLScon brings together service providers, end-users, and industry experts to explore the present, and future of MPLS and MPLS-based services.  Hear from organizations including AT&T, EDS, WorldCom, Cisco, Juniper, Equant, Infonet, Sprint, Savvis, HP, Alcatel, Lucent, The MPLS Forum, The VPN Consortium, NTT, British Telecom, Greenwich Technology Partners, SBC, Deloitte Consulting, Nortel, Extreme, and more. 
    The complete program is now on-line at:
MPLScon is focused on bringing enterprises the information they need to evaluate MPLS services as well as MPLS for use in their own networks. Make your plans today to join us for this event. Register today at and take advantage of early bird pricing:

============ + ===== + ===== + ===== + ============

-- Visit when you need independent review
   and verification of network architecture, product positioning, or
   your marketing message.
-- The archive of past ViewsLetters is available from the web site.
-- Special thanks to for hosting ViewsLetter. 

"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
 Updated:  7 July  2003

Flanagan ConsultingSM
W. A. Flanagan, Inc.
45472 Holiday Drive, Dulles, VA 20166
Ph:  +1.703.242.8381
Fx:  +1.703.242.8391