Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
Working from home, e.g. PPP connections More and more businesses have found then need for high speed Internet connections, in addition to previous private networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. Can leverage the existing IP backbone, packet switched network.
Although the idea of using Internet for private communication is not new, it's only recently that many IP mechanisms needed to meet customer requirements for VPNs all come together. Traffic carried within VPN may have no relation to the traffic on IP backbone (multiprotocol, private IP addressing etc.) Recent VPNs implementations converge to the use of IPSec latency and bandwidth guarantees (like ATM & Frame Relay)
2nd solution motivated by users seeking to reduce costs and ISPs seeking new revenues Some techniques are only applicable to Network based solutions Some mechanisms leverage tools that are only applicable to ISPs like routing protocols etc. as opposed to customers
I switched the order of the last two VPN types while I go over it, because VPRNs and VPLSs are very similar and both share some common issues that need to be addressed.
VLLs can also be thought of the “basis” for the remaining three types of VPNs Of all these protocols, MPLS is different. It is a specific link layer for IP, so the MPLS specific mechanisms apply only within the scope of an MPLS network, whereas IP based mechanisms extend to the extent of IP reachability.
Multiple VLLs may be needed between the same two IP endpoints. Traffic for different customers travels over separate VLLs between the same two physical devices. Have to distinguish which packets belong to which VLL. Actual tunnel establishment could be completed in two ways: management operation or signaling protocol that allows tunnels to be established dynamically. Using signaling protocol significantly reduce the management burden. It is used to negotiate tunneling attributes, not to specify how the tunnel is used (not to limit to specific link layer protocol). MPLS label distribution protocol. All the protocols except IPSec rely on the security of the underlying IP backbone at present only L2TP has such a sequencing field. IPSEC has a sequence number field, but is used by receiver to perform an anti-reply check, not to guarantee in-order delivery of packets
VLL tunnel instance occurs as a result of signaling exchange. It needs to be maintained until terminated either (a) when VLL tunnel is deleted or (b) when tunnel instance is not being used/idle timeout => reallocate resources from inactive tunnel Traffic sent through a VLL may often be opaque to the underlying IP backbone. Fragmentation can be done within the tunnel using tunnel sequence number and an end of message marker to avoid IP fragmentation. Security mechanism impose their own overhead Flow and congestion control are needed to provide performance over lossy networks, to accommodate devices with very little buffering. The mechanism used in L2TP are largely specific to the use of PPP and devices that terminate low speed dial-up lines. Customers may require VLLS yield similar behavior to physical leased lines or dedicated connections with respects to parameters like loss rates, latency and bandwidth guarantees. So, all the capabilities currently developed for traffic management (link sharing, differentiated services, and fair scheduling ) could be applied to the VLL.
IKE = Internet Key Exchange signaling protocol within IPSec that could be used to negotiate IP tunnel attributes, user authentication and specify security levels.
Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
burden are pushed to ISP, and all forwarding are done at Layer 3. For multiprotocol support, a separate VPRN for each network layer protocol could be used, or one protocol could be tunneled over another, or alternatively, the ISP network could be used to provide layer 2 connectivity only such as with VPLS. Multiple VPRNs may be instantiated over the same set of physical devices, and they might use the same or overlapping address spaces.
Since VPRN operates at the internetwork layer, the IP packets send over a tunnel will have their TTL field decrement in the normal manner, to prevent packets circulating indefinitely in the event of a routing loop within the VPRN.
Network based VPRNs may potentially span multiple autonomous systems, and multiple management domains. Need a unique VPN identifier that is unique across multiple Ass. Each stub link must be configured with the identify of the particular VPRN to which it belongs. Dissemination of this information can be done in different ways: Directory lookup put all information into a directory that other edge routers could query e.g. LDAP Explicit management configuration: A VPRN management information base (MIB) could be defined to allow a central management system to configure each edge router. Piggybacking in routing protocols: VPRN membership information could be piggybacked into the routing protocols run by each edge router across the IP backbone. Include at the minimum set of VPN identifiers associated with each edge router. Benefit: efficient way of disseminating information. Disadvantage: security issues. Everyone can read the piggybacked information. ISP only needs to know set of VPRN addresses reachable at the customer side. CPE case is more complicated need to know VPRN default route v.s. normal default route (for Internet connection)
Along with VPRN membership information, a central directory could maintain a listing of the address prefixes associated with each end point. Explicit configuration is a non-scalable solution. Because the address spaces associated with each edge router is explicitly configured into each other router. Each edge router runs a routing protocol per VPRN, running across VPRN tunnels to each peer edge router. Variation of MPLS LDP: send VPN ID and reachability information of each VPRN running across the tunnel between the two edge routers. Only good if it is a full mesh topology. Set of address prefixes associated with each stub interface is piggybacked into the routing advertisements from each edge router and propagated through the network. Tunneling: manual configuration is NOT scalable multipoint to point tunnels like MPLS.
AS with CPE routers, multicast routing protocols could be run on each VPRN edge router to determine the distribution tree for multicast traffic and reduce unnecessary flood traffic. Can run standard multicast routing protocols like PIM (Protocol Independent Multicast), Distance Vector Multicast Routing Protocol (DVMRP). For example, VPRN router could prefix multicast group address within each VPRN with the VPN ID of that VPRN, and then redistribute these, essentially treating this VPNID/Intra-VPRN multicast address tuple as a normal multicast address, within the backbone multicast routing protocols. Then MPLS labeldistribution mechanisms could be used to set up the appropriate multicast LSPs to interconnect those sites within each VPRN supporting particular multicast group addresses.
Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
Packet encapsulation CPE bridge: packets send to and from VPLS across stub links are link layer frames. CPE router: allow for alternative encapsulation Addressing and address resolution bridge CPE: packets forwarded based on link layer addresses (MAC addresses) Router CPE: same as previous case in VPRNs Edge node forwarding an reachability mechanisms bridge: link layer flooding and Mac address learning router: same as VPRNs
Right now, such connections are made through PSTN. PPP sessions are authenticated using AAAA systems running such standard protocols as RADIUS.
Call routing for compulsory tunnels requires that some aspect of initial PPP call set up can be used to allow the LAC to determine the identity of the LNS. Security: interaction between L2tP with AAAA systems L2TP support flow control. Multiple calls within a tunnel, identified by a call-id. LNS needs to support forwarding mechanisms to route traffic to and from the remote host. MTU of the VPDN tunnel is not necessarily less than or equal to that of the underlying IP route.
resources associated within each individual VPN are managed locally, by the customer. Traffic that has a specific QoS needs to use a share of the resources for that VPN. Mark packets and schedule within the core (hierarchical scheduling). Network provides a single hose. Allow customer to control the scheduling of resources by cooperating with the network for serving the different QoS classes. And end point can mark packets with an identifier for the individual QoS. Whenever a scheduling decision for a QoS class within the VPN hose has to be made, the QoS identifier is employed to make the appropriate decision (which one to be transmitted/dropped).
Full mesh connectivity in an MPLS environment can be provided by creating a sink tree (LSP tree) to each hose endpoint, from all other hose endpoints.