|
Archive
Flanagan Consulting
Network Analysts and Consultants
"We Have the Experience"
---------------------------------------------------------------------------
ViewsLetter on Provisioning
7 July 2003 #24
---------------------------------------------------------------------------
A fortnightly look at provisioning automation--chips to business software.
IN THIS ISSUE:
-- Back On-Line with a New List Server
-- Virtual Circuits and IP Routing
/============ + ======= + ======= + ======= + ============
|
| VIEWSLETTER HAS ITS OWN SITE: WWW.VIEWSLETTER.COM
|
| We're back after a hiatus to set up a new list
server.
| As a preferred subscriber, you have been put on the new list and
| will receive future issues by email. You may unsubscribe or
| renew a subscription at any time:
| http://www.viewsletter.com/SubUnsubVLprov.html
|
| If you received this message from a friend, you can
| pick up each issue from our archive or through
| www.Webtorials.com, but it's easier to subscribe--and
| you'll get your copy earlier, too.
|
| Registered Webtorials.com users can subscribe
with "2 clicks" at
| http://www.webtorials.com/main/newsletters/viewsletter/index.htm
| If these text URLs are not 'clickable,' cut and paste into a browser.
|
| NOTE: subscriptions are confirmed by email (double opt-in).
\============ + ======= + ======= + ======= + ============
>>Analysis
ROUTING IP AMONG VIRTUAL CIRCUITS
--By William A. Flanagan, Editor and Publisher
Welcome back. Last issue (#23, available on the web site) described
various forms of virtual circuits that can isolate users of a network from
each other, ensuring the "privacy" of a VPN. This issue we continue
our description of Virtual Private Netowrks by looking at where in a network
each VC type operates and how a VPN does IP routing.
BPNs based on Virtual LANs provide the least physical separation because
they add relatively little to normal IP routing. vLAN packets carry
a standard IP header, with source and destination IP addresses, so a vLAN
router forwards them in the normal way--but only on the vLAN. Unfortunately,
if the packet reaches a router that is not configured for that vLAN, the router
may still forward the packet normally. This is not usually what you
want--you want to limit the movement of packets so they don't stray from the
vLAN.
Virtual Circuits (VCs) provide tighter control. While on the MPLS,
frame relay, or ATM portion of the path, an IP packet (encapsulated in a "frame"
or "cells") moves forward based only on its VC address, not its IP address.
A frame doesn't go astray easily because the paths on the switches are configured
only by the service provider (SP). Once a connection is working, it
remains essentially static.
Routing IP, on the other hand, often must be dynamic. Flexibility
for IP requires IP routers in the network of VCs. Good examples are
the mixed services known as IP-enabled frame relay, frame-aware IP, or similar
names.
When positioned as VPNs, these services dedicate routers to each customer.
VCs on a shared packet/cell network interconnect the routers. Usually
routers are "virtual" or software instances--hundreds can run on one large,
shared hardware platform. Thus each customer has a set of routers and
circuits (all of them virtual) dedicated to his VPN and thus "private" within
the carrier's network Privacy may extend to the customer premises
in the form of VCs or dedicated leased local loops (private lines for access).
Isolation on a VPN has implications for routing protocls and IP addresses.
If there is no connection to the public Internet, a VPN can use any IP address
range, for example the private network space 10.x.x.x, or any arbitrary range.
Connecting those users to the Internet would require a Network Address Translation
(or Network and Port Address Translation), where the 10.x.x.x is changed to
a valid public ("routable") address before the packet leaves the VPN, and
back to the private range as the VPN delivers packets to the customer sites.
When a VPN service provider wants to offer secure access to people on the
Internet, it often considers encryption. However, when combined with
private IP addresses and NAT, encryption can be awkward. Some modes
of IPsec and other tunneling protocols will encrypt the original IP address
(10.x.x.x or 192.168.x.x for example) and keep it in the payload. Going
through NAT does not change this address. When the packet reaches the
far end, the public (NAT'ed) address is removed, the payload is decrypted,
and the original address emerges--but it may not be recognized by the recipient
or may conflict with local IP addresses there.
Conflicts are avoidable. If one end of a connection (usually the server)
has a public IP address, the other end (a remote PC) can have a private IP
address. A direct encrypted session between two hosts with private IP
addresses (both of which use NAT) is the most difficult situation.
The other consideration is a routing protocol. VPN customers who provide
their own routers can choose to peer with the VPN service using any interior
routing protocol supported by the SP on the virtual routers: OSPF, IS-IS,
iBGP, eIGP, etc. However, many users prefer static routes from small
sites that have a single access link, as a routing protocol offers little
benefit when there is no alternate path. They leave the "route finding"
up to the SP within its core network.
VPN networks based on MPLS in the core are generally transparent from the
user's demarcation point to the far side of the SP's network--the entire network
appears as one hop to the customer's router. This condition allows
the customer to run any routing protocol among its own routers.
============ + ===== + ===== + ===== + ============
>>Next Time
-- The Key to Encryption VPNs Is Key Management
To ensure timely receipt of future issues,
subscribe now. See information at the top.
============ + ===== + ===== + ===== + ============
This Issue's Sponsor:
============ + ===== + ===== + ===== + ============
SELF-SERVICE CONFERENCING LETS CARRIERS GENERATE NEW REVENUE;
PRIMAL TECHNOLOGIES' PLATFORM BILLS FOR IT WITH STANDARD CDRs
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 http://www.primaltech.com/ConferencingASP.php
============ + ===== + ===== + ===== + ============
MORE LINKS
-- Visit www.flanagan-consulting.com when you need independent review,
validation, or verification of network architecture, product positioning,
or your marketing message.
-- The archive of past ViewsLetters is available from the web site.
-- Special thanks for supporting ViewsLetter to www.webtorials.com, your
best source for communications tutorials and white papers.
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: 7 July 2003
|
