rfc2917.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

       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