| :: [vpn] Some Solutions for VPN auto-discovery. :: | ||||
| HOME |
|
VPN discovery (Some
Solutions)
Mechanisms are needed to
acquire information that allows the
establishment and maintenance of VPNs. This may include, for example, information on VPN membership, topology, and VPN device capabilities. This information may be statically configured, or distributed by an automated protocol. As a result of the operation of these mechanisms and protocols, a device is able to determine where to set up tunnels, and where to advertise the VPN routes for each VPN. With a physical network, the equivalent problem can by solved by the control of the physical interconnection of links, and by having a router run a discovery/hello protocol over its locally connected links. With VPNs both the routers and the links (tunnels) may be logical entities, and thus some other mechanisms are needed. A number of different approaches are possible for VPN discovery. One scheme uses the network management system to configure and provision the VPN edge devices. This approach can also be used to distribute VPN discovery information, either using proprietary protocols or using standard management protocols and MIBs. Another approach is where the VPN edge devices act as clients of a centralized directory or database server that contains VPN discovery information. Another possibility is where VPN discovery information is piggybacked onto a routing protocol running between the VPN edge devices [VPN-DISC]. Network management for membership information SPs use network management extensively to configure and monitor the various devices that are spread throughout their networks. This approach could be also used for distributing VPN related information. A network management system (either centralized or distributed) could be used by the SP to configure and provision VPNs on the VPN edge devices at various locations. VPN configuration information could be entered into the network management application and distributed via SNMP, XML, CLI, or other means to the remote sites. This approach is most natural when all the devices that must be provisioned are within a single SP's network, since the SP has access to all VPN edge devices in its domain. Security and access control are important, and could be achieved for example using SNMPv3, SSH, or IPsec tunnels. Directory servers An SP typically needs to maintain a database of VPN configuration/membership information, regardless of the mechanisms used to distribute it. LDAPv3 [RFC3377] is a standard directory protocol which makes it possible to use a common mechanism for both storing such information and distributing it. To facilitate interoperability between different implementations, as well as between the management systems of different SPs, a standard schema for representing VPN membership and configuration information would have to be developed. LDAPv3 supports authentication of messages and associated access control, which can be used to limit access to VPN information to authorized entities. Augmented routing for membership information Extensions to the use of existing BGP mechanisms, for distribution of VPN membership information, are proposed in [VPN-2547BIS]. In that scheme, BGP is used to distribute VPN routes, and each route carries a set of attributes which indicate the VPN (or VPNs) to which the route belongs. This allows the VPN discovery information and routing information to be combined in a single protocol. Information needed to establish per-VPN tunnels can also be carried as attributes of the routes. This makes use of the BGP protocol's ability to effectively carry large amounts of routing information. It is also possible to use BGP to distribute just the membership/capability information, while using a different technique to distribute the routing. BGP's update message would be used to indicate that a PE is attached to a particular VPN; BGP's withdraw message would be used to indicate that a PE has ceased to be attached to a particular VPN. This makes use of the BGP protocol's ability to dynamically distribute real-time changes in a reliable and fairly rapid manner. In addition, if a BGP route reflector is used, PEs never have to be provisioned with each other's IP addresses at all. Both cases make use of BGP's mechanisms, such as route filters, for constraining the distribution of information. Augmented routing may be done in combination with aggregated routing, as discussed in section 4.4.4. Of course, when using BGP for distributing any kind of VPN-specific information, one must ensure that one is not disrupting the classical use of BGP for distributing public Internet routing information. For further discussion of this, see the discussion of aggregated routing, section 4.4.4. VPN discovery for Inter-SP VPNs When two sites of a VPN are connected to different SP networks, the SPs must support a common mechanism for exchanging membership/capability information. This might make use of manual configuration or automated exchange of information between the SPs. Automated exchange may be facilitated if one or more mechanisms for VPN discovery are standardized and supported across the multiple SPs. Inter-SP trust relationships will need to be established, for example to determine which information and how much information about the VPNs may be exchanged between SPs. In some cases different
service providers may deploy different
approaches for VPN discovery. Where this occurs, this implies that for multi-SP VPNs, some manual coordination and configuration may be necessary. The amount of information
which needs to be shared between SPs may
vary greatly depending upon the number of size of the multi-SP VPNs. The SPs will therefore need to determine and agree upon the expected amount of membership information to be exchanged, and the dynamic nature of this information. Mechanisms may also be needed to authenticate the VPN membership information. VPN information should be
distributed only to places where it needs
to go, whether that is intra-provider or inter-provider. In this way, the distribution of VPN information is unlike the distribution of inter-provider routing information, as the latter needs to be distributed throughout the Internet. In addition, the joint support of a VPN by two SPs should not require any third SP to maintain state for that VPN. Again, notice the difference with respect to inter- provider routing; in inter-provider routing: sending traffic from one SP to another may indeed require routing state in a third SP. As one possible example:
Suppose that there are two SPs A and C,
which want to support a common VPN. Suppose that A and C are interconnected via SP B. In this case B will need to know how to route traffic between A and C, and therefore will need to know something about A and C (such as enough routing information to forward IP traffic and/or connect MPLS LSPs between PEs or route reflectors in A and C). However, for scaling purposes it is desirable that B not need to know VPN-specific information about the VPNs which are supported by A and C. |