doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc2917.txt b/doc/rfc/rfc2917.txt
new file mode 100644
index 0000000..9c87fc6
--- /dev/null
+++ b/doc/rfc/rfc2917.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                    K. Muthukrishnan
+Request for Comments: 2917                            Lucent Technologies
+Category: Informational                                          A. Malis
+                                                    Vivace Networks, Inc.
+                                                           September 2000
+
+
+                    A Core MPLS IP VPN Architecture
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo presents an approach for building core Virtual Private
+   Network (VPN) services in a service provider's MPLS backbone.  This
+   approach uses Multiprotocol Label Switching (MPLS) running in the
+   backbone to provide premium services in addition to best effort
+   services. The central vision is for the service provider to provide a
+   virtual router service to their customers. The keystones of this
+   architecture are ease of configuration, user security, network
+   security, dynamic neighbor discovery, scaling and the use of existing
+   routing protocols as they exist today without any modifications.
+
+1. Acronyms
+
+        ARP     Address Resolution Protocol
+        CE      Customer Edge router
+        LSP     Label Switched Path
+        PNA     Private Network Administrator
+        SLA     Service Level Agreement
+        SP      Service Provider
+        SPED    Service Provider Edge Device
+        SPNA    SP Network Administrator
+        VMA     VPN Multicast Address
+        VPNID   VPN Identifier
+        VR      Virtual Router
+        VRC     Virtual Router Console
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 1]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+2. Introduction
+
+   This memo describes an approach for building IP VPN services out of
+   the backbone of the SP's network. Broadly speaking, two possible
+   approaches present themselves: the overlay model and the virtual
+   router approach. The overlay model is based on overloading some
+   semantic(s) of existing routing protocols to carry reachability
+   information.  In this document, we focus on the virtual router
+   service.
+
+   The approach presented here does not depend on any modifications of
+   any existing routing protocols. Neighbor discovery is aided by the
+   use of  an emulated LAN and is achieved by the use of ARP. This memo
+   makes a concerted effort to draw the line between the SP and the PNA:
+   the SP owns and manages layer 1 and layer 2 services while layer 3
+   services belong to and are manageable by the PNA. By the provisioning
+   of fully logically independent routing domains, the PNA has been
+   given the flexibility to use private and unregistered addresses. Due
+   to the use of private LSPs and the use of VPNID encapsulation using
+   label stacks over shared LSPs, data security is not an issue.
+
+   The approach espoused in this memo differs from that described in RFC
+   2547 [Rosen1] in that no specific routing protocol has been
+   overloaded to carry VPN routes.  RFC 2547 specifies a way to modify
+   BGP to carry VPN unicast routes across the SP's backbone. To carry
+   multicast routes, further architectural work will be necessary.
+
+3. Virtual Routers
+
+   A virtual router is a collection of threads, either static or
+   dynamic, in a routing device, that provides routing and forwarding
+   services much like physical routers. A virtual router need not be a
+   separate operating system process (although it could be); it simply
+   has to provide the illusion that a dedicated router is available to
+   satisfy the needs of the network(s) to which it is connected. A
+   virtual router, like its physical counterpart, is an element in a
+   routing domain. The other routers in this domain could be physical or
+   virtual routers themselves. Given that the virtual router connects to
+   a specific (logically discrete) routing domain and that a physical
+   router can support multiple virtual routers, it follows that a
+   physical router supports multiple (logically discreet) routing
+   domains.
+
+   From the user (VPN customer) standpoint, it is imperative that the
+   virtual router be as equivalent to a physical router as possible. In
+   other words, with very minor and very few exceptions, the virtual
+   router should appear for all purposes (configuration, management,
+   monitoring and troubleshooting) like a dedicated physical router. The
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 2]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   main motivation behind this requirement is to avoid upgrading or re-
+   configuring the large installed base of routers and to avoid
+   retraining of network administrators.
+
+   The aspects of a router that a virtual router needs to emulate are:
+
+   1. Configuration of any combination of routing protocols
+
+   2. Monitoring of the network
+
+   3. Troubleshooting.
+
+   Every VPN has a logically independent routing domain. This enhances
+   the SP's ability to offer a fully flexible virtual router service
+   that can fully serve the SP's customer without requiring physical
+   per-VPN routers. This means that the SP's "hardware" investments,
+   namely routers and links between them, can be re-used by multiple
+   customers.
+
+4. Objectives
+
+   1. Easy, scalable configuration of VPN endpoints in the service
+      provider network. At most, one piece of configuration should be
+      necessary when a CE is added.
+
+   2. No use of SP resources that are globally unique and hard to get
+      such as IP addresses and subnets.
+
+   3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. This
+      is an optional, but extremely valuable "keep it simple" goal.
+
+   4. Virtual Routers should be fully configurable and monitorable by
+      the VPN network administrator. This provides the PNA with the
+      flexibility to either configure the VPN themselves or outsource
+      configuration tasks to the SP.
+
+   5. Quality of data forwarding should be configurable on a VPN-by-VPN
+      basis.  This should translate to continuous (but perhaps discrete)
+      grades of service.  Some examples include best effort, dedicated
+      bandwidth, QOS, and policy based forwarding services.
+
+   6. Differentiated services should be configurable on a VPN-by-VPN
+      basis, perhaps based on LSPs set up for exclusive use for
+      forwarding data traffic in the VPN.
+
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 3]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   7. Security of internet routers extended to virtual routers. This
+      means that the virtual router's data forwarding and routing
+      functions should be as secure as a dedicated, private physical
+      router.  There should be no unintended leak of information (user
+      data and reachability information) from one routing domain to
+      another.
+
+   8. Specific routing protocols should not be mandated between virtual
+      routers. This is critical to ensuring the VPN customer can setup
+      the network and policies as the customer sees fit. For example,
+      some protocols are strong in filtering, while others are strong in
+      traffic engineering. The VPN customer might want to exploit both
+      to achieve "best of breed" network quality.
+
+   9. No special extensions to existing routing protocols such as BGP,
+      RIP, OSPF, ISIS etc. This is critical to allowing the future
+      addition of other services such as NHRP and multicast. In
+      addition, as advances and addenda are made to existing protocols
+      (such as traffic engineering extensions to ISIS and OSPF), they
+      can be easily incorporated into the VPN implementation.
+
+5. Architectural Requirements
+
+   The service provider network must run some form of multicast routing
+   to all nodes that will have VPN connections and to nodes that must
+   forward multicast datagrams for virtual router discovery. A specific
+   multicast routing protocol is not mandated. An SP may run MOSPF or
+   DVMRP or any other protocol.
+
+6. Architectural Outline
+
+   1.  Every VPN is assigned a VPNID which is unique within the SP's
+       network.  This identifier unambiguously identifies the VPN with
+       which a packet or connection is associated. The VPNID of zero is
+       reserved; it is associated with and represents the public
+       internet.  It is recommended, but not required that these VPN
+       identifiers will be compliant with RFC 2685 [Fox].
+
+   2.  The VPN service is offered in the form of a Virtual Router
+       service.  These VRs reside in the SPED and are as such confined
+       to the edge of the SP's cloud. The VRs will use the SP's network
+       for data and control packet forwarding but are otherwise
+       invisible outside the SPEDs.
+
+   3.  The "size" of the VR contracted to the VPN in a given SPED is
+       expressed by the quantity of IP resources such as routing
+       interfaces, route filters, routing entries etc. This is entirely
+       under the control of the SP and provides the fine granularity
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 4]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+       that the SP requires to offer virtually infinite grades of VR
+       service on a per-SPED level. [Example: one SPED may be the
+       aggregating point (say headquarters of the corporation) for a
+       given VPN and a number of other SPEDs may be access points
+       (branch offices). In this case, the SPED connected to the
+       headquarters may be contracted to provide a large VR while the
+       SPEDs connected to the branch offices may house small, perhaps
+       stub VRs]. This provision also allows the SP to design the
+       network with an end goal of distributing the load among the
+       routers in the network.
+
+   4.  One indicator of the VPN size is the number of SPEDs in the SP's
+       network that have connections to CPE routers in that VPN.  In
+       this respect, a VPN with many sites that need to be connected is
+       a "large" VPN whereas one with a few sites is a "small" VPN.
+       Also, it is conceivable that a VPN grows or shrinks in size over
+       time. VPNs may even merge due to corporate mergers, acquisitions
+       and partnering agreements. These changes are easy to accommodate
+       in this architecture, as globally unique IP resources do not have
+       to be dedicated or assigned to VPNs. The number of SPEDs is not
+       limited by any artificial configuration limits.
+
+   5.  The SP owns and manages Layer 1 and Layer 2 entities. To be
+       specific, the SP controls physical switches or routers, physical
+       links, logical layer 2 connections (such as DLCI in Frame Relay
+       and VPI/VCI in ATM) and LSPs (and their assignment to specific
+       VPNs).  In the context of VPNs, it is the SP's responsibility to
+       contract and assign layer 2 entities to specific VPNs.
+
+   6.  Layer 3 entities belong to and are manageable by the PNA.
+       Examples of these entities include IP interfaces, choice of
+       dynamic routing protocols or static routes, and routing
+       interfaces. Note that although Layer 3 configuration logically
+       falls under the PNA's area of responsibility, it is not necessary
+       for the PNA to execute it.  It is quite viable for the PNA to
+       outsource the IP administration of the virtual routers to the
+       Service Provider.  Regardless of who assumes responsibility for
+       configuration and monitoring, this approach provides a full
+       routing domain view to the PNA and empowers the PNA to design the
+       network to achieve intranet, extranet and traffic engineering
+       goals.
+
+   7.  The VPNs can be managed as if physical routers rather than VRs
+       were deployed.  Therefore, management may be performed using SNMP
+       or other similar methods or directly at the VR console (VRC).
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 5]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   8.  Industry-standard troubleshooting tools such as 'ping,'
+       'traceroute,' in a routing domain domain comprised exclusively of
+       dedicated physical routers.  Therefore, monitoring and .bp
+       troubleshooting may be performed using SNMP or similar methods,
+       but may also include the use of these standard tools. Again, the
+       VRC may be used for these purposes just like any physical router.
+
+   9.  Since the VRC is visible to the user, router specific security
+       checks need to be put in place to make sure the VPN user is
+       allowed access to Layer 3 resources in that VPN only and is
+       disallowed from accessing physical resources in the router.  Most
+       routers achieve this through the use of database views.
+
+   10. The VRC is available to the SP as well. If configuration and
+       monitoring has been outsourced to the SP, the SP may use the VRC
+       to accomplish these tasks as if it were the PNA.
+
+   11. The VRs in the SPEDs form the VPN in the SP's network. Together,
+       they represent a virtual routing domain. They dynamically
+       discover each other by utilizing an emulated LAN resident in the
+       SP's network.
+
+   Each VPN in the SP's network is assigned one and only one multicast
+   address. This address is chosen from the administratively scoped
+   range (239.192/14) [Meyer] and the only requirement is that the
+   multicast address can be uniquely mapped to a specific VPN. This is
+   easily automated by routers by the use of a simple function to
+   unambiguously map a VPNid to the multicast address.  Subscription to
+   this multicast address allows a VR to discover and be discovered by
+   other VRs. It is important to note that the multicast address does
+   not have to be configured.
+
+   12. Data forwarding may be done in one of several ways:
+
+      1. An LSP with best-effort characteristics that all VPNS can use.
+
+      2. An LSP dedicated to a VPN and traffic engineered by the VPN
+         customer.
+
+      3. A private LSP with differentiated characteristics.
+
+      4. Policy based forwarding on a dedicated L2 Virtual Circuit
+
+   The choice of the preferred method is negotiable between the SP and
+   the VPN customer, perhaps constituting part of the SLA between them.
+   This allows the SP to offer different grades of service to different
+   VPN customers.
+
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 6]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   Of course, hop-by-hop forwarding is also available to forward routing
+   packets and to forward user data packets during periods of LSP
+   establishment and failure.
+
+   13. This approach does not mandate that separate operating system
+       tasks for each of the routing protocols be run for each VR that
+       the SPED houses. Specific implementations may be tailored to the
+       particular SPED in use. Maintaining separate routing databases
+       and forwarding tables, one per VR, is one way to get the highest
+       performance for a given SPED.
+
+7. Scalable Configuration
+
+   A typical VPN is expected to have 100s to 1000s of endpoints within
+   the SP cloud.  Therefore, configuration should scale (at most)
+   linearly with the number of end points. To be specific, the
+   administrator should have to add a couple of configuration items when
+   a new customer site joins the set of VRs constituting a specific VPN.
+   Anything worse will make this task too daunting for the service
+   provider.  In this architecture, all that the service provider needs
+   to allocate and configure is the ingress/egress physical link (e.g.
+   Frame Relay DLCI or ATM VPI/VCI) and the virtual connection between
+   the VR and the emulated LAN.
+
+8. Dynamic Neighbor Discovery
+
+   The VRs in a given VPN reside in a number of SPEDs in the network.
+   These VRs need to learn about each other and be connected.
+
+   One way to do this is to require the manual configuration of
+   neighbors.  As an example, when a new site is added to a VPN, this
+   would require the configuration of all the other VRs as neighbors.
+   This is obviously not scalable from a configuration and network
+   resource standpoint.
+
+   The need then arises to allow these VRs to dynamically discover each
+   other.  Neighbor discovery is facilitated by providing each VPN with
+   a limited emulated LAN. This emulated LAN is used in several ways:
+
+   1. Address resolution uses this LAN to resolve next-hop (private) IP
+      addresses associated with the other VRs.
+
+   2. Routing protocols such as RIP and OSPF use this limited emulated
+      LAN for neighbor discovery and to send routing updates.
+
+   The per-VPN LAN is emulated using an IP multicast address.  In the
+   interest of conserving public address space and because this
+   multicast address needs to be visible only in the SP network space,
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 7]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   we would use an address from the Organizationally scoped multicast
+   addresses (239.192/14) as described in [Meyer]. Each VPN is allocated
+   an address from this range.  To completely eliminate configuration in
+   this regard, this address is computed from the VPNID.
+
+9. VPN IP Domain Configuration
+
+                                151.0.0.1
+                                ################
+                               #              #
+                              #  ROUTER 'A'  #
+                             #              #
+                            ################
+                                 #       #
+                                #         #
+                               #           #
+                              #             #
+                         #############    ###############
+                        #           #    #             #
+                       # ROUTER 'B'#    # ROUTER 'C'  #
+                      #           #    #             #
+                     #           #    #             #
+                    #############    ###############
+                    152.0.0.2         153.0.0.3
+
+                   Figure 1 'Physical Routing Domain'
+
+   The physical domain in the SP's network is shown in the above figure.
+   In this network, physical routers A, B and C are connected together.
+   Each of the routers has a 'public' IP address assigned to it. These
+   addresses uniquely identify each of the routers in the SP's network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 8]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+         172.150.0/18                                172.150.128/18
+ -----------------------             ---------------------------|
+             |                                       |          |
+             |                                       |     172.150.128.1
+             |               ROUTER 'A' (151.0.0.1)  |       |---------|
+             |               #############           |       |Parts DB |
+             |           ---#-----------#            |       /---------/
+             |    OSPF   | #           #     ISIS    |      /----------/
+             ------------|#  VR - A   #|--------------
+                         #-------|---#-|
+                        #############10.0.1/24
+             |----|------------#-#---------------|-----|
+                  |10.0.0.2/24#   #              |10.0.0.3/24
+           |------|-------|  #     #    ---------|-------|
+           |  ###############       #   |############### |
+           | #  VR - B    |#         #  #    VR - C   #  |
+           |#-------------# ROUTER 'B'##|------------#----
+(152.0.0.2)###############            ############### (153.0.0.3)
+      -------------------------       ROUTER 'C' |   Extranet
+            172.150.64/18                        V
+                                              Vendors
+
+                Figure 2 'Virtual Routing Domain'
+
+   Each Virtual Router is configurable by the PNA as though it were a
+   private physical router. Of course, the SP limits the resources that
+   this Virtual Router may consume on a SPED-by-SPED basis. Each VPN has
+   a number of physical connections (to CPE routers) and a number of
+   logical connections (to the emulated LAN). Each connection is IP-
+   capable and can be configured to utilize any combination of the
+   standard routing protocols and routing policies to achieve specific
+   corporate network goals.
+
+   To illustrate, in Figure 1, 3 VRs reside on 3 SPEDs in VPN 1. Router
+   'A' houses VR-A, router 'B' houses VR-B and router 'C' houses VR-C.
+   VR-C and VR-B have a physical connection to CPE equipment, while VR-A
+   has 2 physical connections. Each of the VRs has a fully IP-capable
+   logical connection to the emulated LAN.  VR-A has the (physical)
+   connections to the headquarters of the company and runs OSPF over
+   those connections. Therefore, it can route packets to 172.150.0/18
+   and 172.150.128/18. VR-B runs RIP in the branch office (over the
+   physical connection) and uses RIP (over the logical connection) to
+   export 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B
+   over the logical connection.  Vendors use VR-C as the extranet
+   connection to connect to the parts database at 172.150.128.1. Hence,
+   VR-C advertises a default route to VR-A over the logical connection.
+   VR-A exports only 175.150.128.1 to VR-C. This keeps the rest of the
+   corporate network from a security problem.
+
+
+
+Muthukrishnan & Malis        Informational                      [Page 9]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   The network administrator will configure the following:
+
+   1. OSPF connections to the 172.150.0/18 and 172.150.128/18 network
+      in VR-A.
+
+   2. RIP connections to VR-B and VR-C on VR-A.
+
+   3. Route policies on VR-A to advertise only the default route to
+      VR-B.
+
+   4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C.
+
+   5. RIP on VR-B to VR-A.
+
+   6. RIP on VR-C to advertise a default route to VR-A.
+
+10. Neighbor Discovery Example
+
+   In Figure #1, the SPED that houses VR-A (SPED-A) uses a public
+   address of 150.0.0.1/24, SPED-B uses 150.0.0.2/24 and SPED-C uses
+   150.0.0.3/24.  As noted, the connection between the VRs is via an
+   emulated LAN.  For interface addresses on the emulated LAN
+   connection, VR-A uses 10.0.0.1/24, VR-B uses 10.0.0.2/24 and VR-C
+   uses 10.0.0.3/24.
+
+   Let's take the case of VR-A sending a packet to VR-B. To get VR-B's
+   address (SPED-B's address), VR-A sends an ARP request packet with the
+   address of VR-B (10.0.0.2) as the logical address. The source logical
+   address is 10.0.0.1 and the hardware address is 151.0.0.1. This ARP
+   request is encapsulated in this VPN's multicast address and sent out.
+   SPED B and SPED-C receive a copy of the packet.  SPED-B recognizes
+   10.0.0.2 in the context of VPN 1 and responds with 152.0.0.2 as the
+   "hardware" address. This response is sent to the VPN multicast
+   address to promote the use of promiscuous ARP and the resulting
+   decrease in network traffic.
+
+   Manual configuration would be necessary if neighbor discovery were
+   not used. In this example, VR-A would be configured with a static ARP
+   entry for VR-B's logical address (10.0.0.1) with the "hardware"
+   address set to 152.0.0.2.
+
+11. Forwarding
+
+   As mentioned in the architectural outline, data forwarding may be
+   done in one of several ways. In all techniques except the Hop-by-Hop
+   technique for forwarding routing/control packets, the actual method
+
+
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 10]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   is configurable. At the high end, policy based forwarding for quick
+   service and at the other end best effort forwarding using public LSP
+   is used. The order of forwarding preference is as follows:
+
+   1. Policy based forwarding.
+
+   2. Optionally configured private LSP.
+
+   3. Best-effort public LSP.
+
+11.1  Private LSP
+
+   This LSP is optionally configured on a per-VPN basis. This LSP is
+   usually associated with non-zero bandwidth reservation and/or a
+   specific differentiated service or QOS class. If this LSP is
+   available, it is used for user data and for VPN private control data
+   forwarding.
+
+11.2 Best Effort Public LSP
+
+   VPN data packets are forwarded using this LSP if a private LSP with
+   specified bandwidth and/or QOS characteristics is either not
+   configured or not presently available. The LSP used is the one
+   destined for the egress router in VPN 0. The VPNID in the shim header
+   is used to de-multiplex data packets from various VPNs at the egress
+   router.
+
+12.  Differentiated Services
+
+   Configuring private LSPs for VPNs allows the SP to offer
+   differentiated services to paying customers. These private LSPs could
+   be associated with any available L2 QOS class or Diff-Serv
+   codepoints. In a VPN, multiple private LSPs with different service
+   classes could be configured with flow profiles for sorting the
+   packets among the LSPs. This feature, together with the ability to
+   size the virtual routers, allows the SP to offer truly differentiated
+   services to the VPN customer.
+
+13.  Security Considerations
+
+13.1  Routing Security
+
+   The use of standard routing protocols such as OSPF and BGP in their
+   unmodified form means that all the encryption and security methods
+   (such as MD5 authentication of neighbors) are fully available in VRs.
+   Making sure that routes are not accidentally leaked from one VPN to
+   another is an implementation issue. One way to achieve this is to
+   maintain separate routing and forwarding databases.
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 11]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+13.2  Data Security
+
+   This allows the SP to assure the VPN customer that data packets in
+   one VPN never have the opportunity to wander into another. From a
+   routing standpoint, this could be achieved by maintaining separate
+   routing databases for each virtual router. From a data forwarding
+   standpoint, the use of label stacks in the case of shared LSPs
+   [Rosen2] [Callon] or the use of private LSPs guarantees data privacy.
+   Packet filters may also be configured to help ease the problem.
+
+13.3  Configuration Security
+
+   Virtual routers appear as physical routers to the PNA. This means
+   that they may be configured by the PNA to achieve connectivity
+   between offices of a corporation. Obviously, the SP has to guarantee
+   that the PNA and the PNA's designees are the only ones who have
+   access to the VRs on the SPEDs the private network has connections
+   to. Since the virtual router console is functionally equivalent to a
+   physical router, all of the authentication methods available on a
+   physical console such as password, RADIUS, etc. are available to the
+   PNA.
+
+13.4 Physical Network Security
+
+   When a PNA logs in to a SPED to configure or monitor the VPN, the PNA
+   is logged into the VR for the VPN. The PNA has only layer 3
+   configuration and monitoring privileges for the VR. Specifically, the
+   PNA has no configuration privileges for the physical network. This
+   provides the guarantee to the SP that a VPN administrator will not be
+   able to inadvertently or otherwise adversely affect the SP's network.
+
+14.  Virtual Router Monitoring
+
+   All of the router monitoring features available on a physical router
+   are available on the virtual router. This includes utilities such as
+   "ping" and "traceroute". In addition, the ability to display private
+   routing tables, link state databases, etc. are available.
+
+15. Performance Considerations
+
+   For the purposes of discussing performance and scaling issues,
+   today's routers can be split into two planes: the routing (control)
+   plane and the forwarding plane.
+
+   In looking at the routing plane, most modern-day routing protocols
+   use some form of optimized calculation methodologies to calculate the
+   shortest path(s) to end stations. For instance, OSPF and ISIS use the
+   Djikstra algorithm while BGP uses the "Decision Process". These
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 12]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   algorithms are based on parsing the routing database and computing
+   the best paths to end stations. The performance characteristics of
+   any of these algorithms is based on either topological
+   characteristics (ISIS and OSPF) or the number of ASs in the path to
+   the destinations (BGP). But it is important to note that the overhead
+   in setting up and beginning these calculations is very little for
+   most any modern day router. This is because, although we refer to
+   routing calculation input as "databases", these are memory resident
+   data structures.
+
+   Therefore, the following conclusions can be drawn:
+
+   1. Beginning a routing calculation for a routing domain is nothing
+      more than setting up some registers to point to the right database
+      objects.
+
+   2. Based on 1, the performance of a given algorithm is not
+      significantly worsened by the overhead required to set it up.
+
+   3. Based on 2, it follows that, when a number of routing calculations
+      for a number of virtual routers has to be performed by a physical
+      router, the complexity of the resulting routing calculation is
+      nothing more than the sum of the complexities of the routing
+      calculations of the individual virtual routers.
+
+   4. Based on 3, it follows that whether an overlay model is used or a
+      virtual routing model is employed, the performance characteristics
+      of a router are dependent purely on its hardware capabilities and
+      the choice of data structures and algorithms.
+
+   To illustrate, let's say a physical router houses N VPNs, all running
+   some routing protocol say RP. Let's also suppose that the average
+   performance of RP's routing calculation algorithm is  f(X,Y) where x
+   and y are parameters that determine performance of the algorithm for
+   that routing protocol. As an example, for Djikstra algorithm users
+   such as OSPF, X could be the number of nodes in the area while Y
+   could be the number of links. The performance of an arbitrary VPN n
+   is f (Xn, Yn). The performance of the (physical) router is the sum of
+   f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is
+   independent of the chosen VPN approach (virtual router or overlay
+   model).
+
+   In the usual case, the forwarding plane has two inputs: the
+   forwarding table and the packet header. The main performance
+   parameter is the lookup algorithm. The very best performance one can
+   get for a IP routing table lookup is by organizing the table as some
+   form of a tree and use binary search methods to do the actual lookup.
+   The performance of this algorithm is O(log n).
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 13]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+   Hence, as long as the virtual routers' routing tables are distinct
+   from each other, the lookup cost is constant for finding the routing
+   table and O(log n) to find the entry. This is no worse or different
+   from any router and no different from a router that employs overlay
+   techniques to deliver VPN services. However, when the overlay router
+   utilizes integration of multiple VPNs' routing tables, the
+   performance is O(log m*n) where 'm' is the number of VPNs that the
+   routing table holds routes for.
+
+16. Acknowledgements
+
+   The authors wish to thank Dave Ryan, Lucent Technologies for his
+   invaluable in-depth review of this version of this memo.
+
+17.  References
+
+   [Callon] Callon R., et al., "A Framework for Multiprotocol Label
+            Switching", Work in Progress.
+
+   [Fox]    Fox, B. and B. Gleeson,"Virtual Private Networks
+            Identifier", RFC 2685, September 1999.
+
+   [Meyer]  Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
+            July 1998.
+
+   [Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
+            1999.
+
+   [Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol
+            Label Switching Architecture", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 14]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+18. Authors' Addresses
+
+   Karthik Muthukrishnan
+   Lucent Technologies
+   1 Robbins Road
+   Westford, MA 01886
+
+   Phone: (978) 952-1368
+   EMail: mkarthik@lucent.com
+
+
+   Andrew Malis
+   Vivace Networks, Inc.
+   2730 Orchard Parkway
+   San Jose, CA 95134
+
+   Phone: (408) 383-7223
+   EMail: Andy.Malis@vivacenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 15]
+
+RFC 2917                       Core VPNs                  September 2000
+
+
+19.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muthukrishnan & Malis        Informational                     [Page 16]
+