Internet DRAFT - draft-wiget-dynamic-vpls

draft-wiget-dynamic-vpls



INTERNET DRAFT                                              Marcel Wiget
                                                            Simon Bryden
                                                            Geoff Mattson
                                                            Nortel Networks
                                                            December 1999

draft-wiget-dynamic-vpls-00.txt


        Dynamic VPLS solution over multicast enabled IP backbone

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an individual submission to the Internet Engineering
   Task Force (IETF). Comments should be submitted to the authors.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes an experimental serverless solution to build
   Virtual Private LAN Segments (VPLS) for TCP/IP over a multicast
   enabled IP backbone.  IP traffic is encapsulated in IPsec [RFC2401]
   tunnel mode. IP broadcast and multicast traffic is sent, after
   encapsulation in IPSec tunnel mode, to the VPN assigned IP multicast
   address. IP unicast traffic, after encapsulation,  is sent directly
   to the dynamically learned IP tunnel endpoint address.  Multicast
   Enabled ARP (ME-ARP) as defined in this document is used to
   dynamically build the mapping between IP addresses and remote tunnel
   endpoints. The tunnel endpoint information is hidden in the hardware
   address given to IP devices in the ARP reply. Therefore IP devices
   participating in a VPLS keep track of the remote locations of other
   VPLS members through their own ARP table without "knowledge".


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .   2



Wiget, et al               Expires: June 2000                   [Page 1]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Dynamic VPLS Overview  . . . . . . . . . . . . . . . . . . . . .   4
   2.1.  Multicast IP backbone Requirements . . . . . . . . . . . . . .   4
   2.2.  VPLS Identifier (Multicast IP Address) . . . . . . . . . . . .   4
   2.3.  VPLS Interfaces  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Multicast Enabled ARP (ME-ARP) . . . . . . . . . . . . . . . . .   4
   3.1.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .   4
   3.2.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.3.  ME-ARP operations  . . . . . . . . . . . . . . . . . . . . . .   6
   3.3.1.  ARP request intercepted from the PLS . . . . . . . . . . . .   6
   3.3.2.  Tunneled ME-ARP requests received from VPLS gateways . . . .   7
   3.3.3.  ARP replies intercepted from the PLS . . . . . . . . . . . .   7
   3.3.4.  Tunneled ME-ARP replies received from VPLS gateways  . . . .   7
   3.4.  Hardware address calculation algorithm . . . . . . . . . . . .   7
   4.  IP Encapsulation . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.1.  Multicast and broadcast IP packets received from the . . . . .   9
   4.2.  Unicast IP packets intercepted from the PLS  . . . . . . . . .   9
   4.3.  Tunneled IP packets received from VPLS gateways  . . . . . . .  10
   5.  VPLS examples  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.1.  CLE based Virtual Private LAN Segment (VPLS) . . . . . . . . .  10
   5.2.  Network based Virtual Private LAN Segment (VPLS) . . . . . . .  11
   5.2.1.  Functional Overview  . . . . . . . . . . . . . . . . . . . .  12
   5.3.  Interoperability between different types of PLS  . . . . . . .  13
   6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Intellectual Property Considerations . . . . . . . . . . . . . .  14
   10.  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . .  14
   11.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  14


1.  Introduction


1.1.  Goals

   The popularity of the Internet is driving requirements for secure and
   segregated IP interconnection of remote sites. One solution is to use
   an underlying network supporting virtual connections ie Frame Relay
   or ATM. These virtual connections can be separated by provisioning to
   form a Virtual Private Network which is Layer 3 protocol transparent.
   However if the underlying network is IP itself, as is the case with
   the Internet then IP tunnels can be used to interconnect two or more
   sites. The solution outlined in this document describes the following
   goals:

     ¸ Separation of IP address space between VPNs.

     ¸ To provide support for IPv4 based applications. Support for IPv6
       is outside the scope of this document. Ipv6 encapsulation in Ipv4
       will be supported by this solution as long as the encapsulation
       occurs before the VPN boundary.




Wiget, et al               Expires: June 2000                   [Page 2]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


     ¸ Transparent CLE (Customer Leased Equipment) or network based
       VPN's can be constructed independently or combined with this
       architecture.

     ¸ The use of IP multicast capabilities rather than address or
       broadcast servers.

     ¸ VPN traffic forwarding is achieved via tunnels which may option¡
       ally be secure. Traffic forwarded over these tunnels are opti¡
       mally routed using the underlying IP network backbone routing
       architecture.

The document is split into four parts: Overview, protocol description of
ME-ARP (multicast enabled ARP), IP encapsulation and VPLS examples over
different lower layer technologies.


1.2.  Terminology

   The term virtual private networks (VPN) is widely used as a common
   description for any kind of network built over another network with
   limited scope.

   The terminology used in this document is based on the definitions
   found in [gleeson]:

   A Virtual Private LAN Segment (VPLS) is the emulation of a LAN seg¡
   ment using Internet facilities. A VPLS can be used to provide what is
   sometimes known as a transparent LAN service (TLS), which can be used
   to interconnect multiple physical LAN Segments (PLS). It can be seen
   as a pure layer 2 bridged VPN solution.

   The term "Physical LAN Segment" (PLS) is used in this document to
   describe a broadcast domain, like a shared or switched ethernet seg¡
   ment, connecting hosts, servers and routers at each site. Without the
   use of a VPN technology, the scope of these PLS is limited per site.
   The term is also used for segments simulating a broadcast domain like
   a WAN link configured for bridging or simulating an ethernet segment
   using SMDS or ethernet over HDLC.

   The term "Client Address" (CA) space or network ranges is used to
   describe the IP address space used by each VPN customer. It is abso¡
   lutely legal and very common for CA's from different VPN to overlap.

   The term "Provider Address" (PA) space or network ranges is used to
   describe the provider allocated IP addresses in his IP backbone. Tun¡
   nel endpoints e.g.  must have an address assigned out of the PA
   range.

   The term "Customer Leased Equipment" (CLE) defines an edge device
   (router), fully managed by the provider, connecting a customers PLS
   to its VPN.

   The term "Customer Premises Equipment" (CPE) defines an edge device



Wiget, et al               Expires: June 2000                   [Page 3]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   (router), either managed by the customer or provider, connected to a
   provider's VPN concentrator.

   The term "VPN Concentrator" is used to describe a provider managed
   network device interconnecting many Frame Relay attached customer
   managed network devices to build network based VPN's.



















































Wiget, et al               Expires: June 2000                   [Page 4]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


2.  Dynamic VPLS Overview


2.1.  Multicast IP backbone Requirements

   The providers IP backbone must be IP multicast capable. VPLS config¡
   ured devices must be able to join a multicast group using IGMP. It is
   not a requirement that all routers in the backbone must have multi¡
   cast capabilities. It is possible to interconnect the devices via a
   partially meshed or "star-like" multicast backbone, built using a mix
   of multicast routing protocols and tunnels to interconnect multicast
   islands. IP multicast is used to forward broadcast and multicast
   traffic and for IP address resolution, but not for forwarding of uni¡
   cast traffic.


2.2.  VPLS Identifier (Multicast IP Address)

   Each VPLS has a provider unique multicast IP address assigned. This
   address is used to send IP multicast, broadcast and special address
   resolution traffic to all participating VPLS gateways.

   If the VPLS consists only of 2 gateways, then an IP unicast address
   could be used instead as the VPLS identifier.


2.3.  VPLS Interfaces

   The following minimal configuration parameters are needed per VPLS
   interface:

     ¸ VPLS Identifier = multicast IP address assigned to each VPLS.

     ¸ Customer assigned IP subnet network address and mask. This is
       used to detect IP subnet broadcast packets.

     ¸ Pair of Security Associations (SA) (one for each direction).

     ¸ Hardware address calculation algorithm. Due to the limited size
       of hardware address length it is possible to use different algo¡
       rithm per VPLS interface.  The algorithm has only interface local
       significance.

The VPLS interface doesn't have to be identical to the IPSec interface.
It is possible to share the same IPSec interface with more than one VPLS
interface in the same device. A bidirectional mapping between the IPSec
and VPLS interface based on SA's is enough to forward VPLS packets.

It is not recommended to assign an IP address out of the client address
(CA) network range. Doing so will allow the client to access the VPLS
gateway from the provider. It is however possible to assign an IP
address out of the provider address (PA) network range in order to man¡
age the interface from the providers' backbone.




Wiget, et al               Expires: June 2000                   [Page 5]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


3.  Multicast Enabled ARP (ME-ARP)


3.1.  Protocol Overview

   The Address Resolution Protocol, ARP [RFC826], allows a host to find
   the physical address of a target host on the same physical network,
   given only the targets IP address. The goal of ME-ARP defined here is
   the expansion of ARP to work for Virtual Private LAN Segments (VPLS)
   connecting 2 or more Physical LAN Segments (PLS). The physical
   address for remote hosts is replaced by a pseudo-physical address
   containing the remote gateway identifier.  It is important to note
   that these pseudo-physical addresses only have significance within of
   a PLS.

   All ARP requests sent by hosts connected to a VPLS are translated
   into ME-ARP requests and forwarded to the VPN assigned IP multicast
   address.  These ME-ARP requests are then translated back into stan¡
   dard ARP requests with remote gateway or tunnel endpoint information
   encoded in the pseudo-physical address. The request is sent out the
   local PLS.  ARP replies are treated similarly but forwarded as uni¡
   cast packets using the remote gateway or tunnel endpoint information
   encoded in the destination physical address.

   A new IP protocol type is assigned to ME-ARP and used in IPSec proto¡
   col type field.


3.2.  Packet Format

   Request and reply packet have the same format.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Version    |  ProtoLength  |         Operation             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    Sender Protocol Address                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    Target Protocol Address                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Version

          This 8 bit field must be set to 1 for the packet format
          described in this RFC. It can be used for future expansion.

     ProtoLength

          This 8 bit field defines the byte length of the protocol
          address and is copied from the ARP packet field ar$pln (byte
          length of each protocol address) as defined in [RFC826].





Wiget, et al               Expires: June 2000                   [Page 6]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


     Operation

          This 16 bit field is copied from the ARP packet field ar$op
          and defines the ARP operation (REQUEST or REPLY).

     Sender Protocol Address

          This variable length field contains the protocol address of
          the sender and is copied from the ARP packet field ar$spa.

     Sender Protocol Address

          This variable length field contains the protocol address of
          the sender and is copied from the ARP packet field ar$spa.

     Target Protocol Address

          This variable length field contains the protocol address of
          the target and is copied from the ARP packet field ar$tpa.

A checksum is not needed as IPSec guarantees unmodified delivery of
packets and discards them otherwise.

There is no need to transfer hardware addresses as they have only local
significance inside a PLS. The hardware addresses are created by ME-ARP
based on the source IP address from the outer IPsec tunnel header
(equals to the remote tunnel endpoint).


3.3.  ME-ARP operations

   In all operations below there is no need to keep state of pending
   requests or replies as this is done by the hosts originating the ARP
   requests.  ME-ARP simply tunnels modified ARP packets to remote loca¡
   tions and process them as described below. This greatly simplifies
   the solution.

   Each VPLS interface must maintain a host table with the hardware
   address of local attached IP devices (no remote devices!). This table
   is identical to the ARP table needed for proxy ARP implementations.


3.3.1.  ARP request intercepted from the PLS

   Each ARP request sent by IP devices connected to a PLS are inter¡
   cepted by the VPLS interface. The tuple source hardware and protocol
   address are stored in an interface local host table. This table is
   accessed when VPLS traffic is received from remote VPLS gateways. The
   receiver uses table entry to map the protocol address in the header
   of incoming IP packets to the hardware address of a locally connected
   host.  A ME-ARP packet is created using data from the ARP request and
   sent over a tunnel-mode IPsec connection to the VPLS assigned multi¡
   cast IP address.




Wiget, et al               Expires: June 2000                   [Page 7]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


3.3.2.  Tunneled ME-ARP requests received from VPLS gateways

   IPSec encapsulated ME-ARP packets are sent to the VPLS interface
   based on the SPI index matching an incoming SA. The data of the ME-
   ARP request is used to build an ordinary ARP request packet and sent
   to the hardware broadcast address on the local PLS. The sender hard¡
   ware address is calculated based on the source outer IPSec tunnel IP
   header address.  The algorithm used for the hardware address calcula¡
   tion can be found in a separate chapter further down.


3.3.3.  ARP replies intercepted from the PLS

   ARP replies are sent by IP device to the target hardware address. The
   VPLS interface must check each of these target hardware address if it
   is a constructed address created by this VPLS interface. The detec¡
   tion algorithm is directly related to the hardware address calcula¡
   tion algorithm defined below.

   If the destination hardware address originated from this VPLS inter¡
   face (created by the calculation algorithm) then it is translated
   into a ME-ARP reply packet, encapsulated in IPsec and sent to the
   destination gateway.  The destination gateway IP address is extracted
   from the hardware address using the hardware address calculation
   algorithm as described in section 3.4.



3.3.4.  Tunneled ME-ARP replies received from VPLS gateways

   IPSec encapsulated ME-ARP reply packets are sent to the VPLS inter¡
   face based on the SPI index matching an incoming SA. The data of the
   ME-ARP reply is used to build a conventional ARP reply packet. The
   hardware destination address look-up is performed on the local host
   table maintained for this VPLS interface. If an entry is not found,
   then the packet is discarded, otherwise it is sent to the hardware
   address associated with the IP sender address. The source hardware
   address and target hardware address are calculated based on the
   source outer IPsec tunnel IP header address. The algorithm used for
   the hardware address calculation is described in section 3.4.

   [If the local host table doesn't contain an entry to forward the ARP
   reply, then it is ok to discard the packet because it might have
   reached this gateway as a result of an error (e.g. ARP request didn't
   come from this gateway) or the table was cleared between the request
   and the reply. However the requesting IP device will resend another
   ARP request if needed.]



3.4.  Hardware address calculation algorithm

   Data to pack into the hardware address are:




Wiget, et al               Expires: June 2000                   [Page 8]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


     Unicast Tunnel Endpoint IP address (4 Bytes)

          This IP address is used to forward unicast IP packets directly
          to the correct VPN tunnel endpoint. Ideally, the complete IP
          address is stored, however in some cases it might be possible
          to reduce it to the host address if all gateway devices share
          the same network (ie. network address is the same for all CLE
          devices).  This IP address is typically the address of the
          IPSec interface of the VPLS gateway.

     Interface local unique VPN Id

          This is used in case of IP multi-netted interfaces to distin¡
          guish the different VPN's configured on the same physical
          interface. It's enough to store an index for all configured
          VPN's per interface instead of the real VPN multicast Id.
          Therefore 4 bits might be enough (-> 16 VPN's per interface).

     Local gateway identification

          In case of CLE redundancy (2 or more CLE devices connected to
          the same physical shared media serving the same VPN), a shared
          media wide unique identifier must be present. This gives an
          easy solution to add redundancy:

          ARP request coming from a local connected client will be for¡
          warded by both CLE devices, as well as the ARP reply packet
          returning to the client. The client (host) however will store
          only one MAC address in its ARP table (whichever packet came
          last)

          A solution to this could be to use a 2 bit identifier to dis¡
          tinguish up to 4 CLE devices per VPN segment.

   Summary:

   32 Bit IP destination Gateway address
    4 Bit VPN Id index (16 VPN's max)
    2 Bit Gateway index (4 Gateways)
   ------------------------------------- 38 bits in use, leaving 10 Bits
   to identify a valid Ethernet address prefix.

   or, in case of using only the host portion of the gateway address
   (assuming class B), then we end up with

   16 bit IP destination Gateway host address
    4 Bit VPN Id Index
    2 Bit Gateway index ----- 22 Bit, leaving 26 Bits as ethernet prefix
   (24 bit needed) so use e.g.
           the IANA prefix 00005E plus 2 bits.

   The algorithm used to pack the information into the calculated MAC
   address is only relevant for the local attached VPN network. A dif¡
   ferent algorithm can be used on other CLE devices.



Wiget, et al               Expires: June 2000                   [Page 9]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   It must be determined, if it would be possible to use a prefix of
   04......, as this isn't assigned according to IEEE [Enet], it breaks
   however the rule, which identifies the vendor by the high-order 3
   octets.


4.  IP Encapsulation

   IP traffic between Physical LAN Segments (PLS) is encapsulated in IP
   using IPSec tunnel mode [RFC401]. ARP traffic is intercepted from the
   PLS, translated in ME-ARP packet, and encapsulated in IPSec with the
   protocol Id of ME-ARP.  Therefore all VPLS traffic is authenticated
   and optionally secured using IPSec.

   There must be one Security Association (SA) created per VPLS in each
   gateway (see chapter 'VPN Security Association') to link the SPI to a
   particular VPN. This indirection is used to fully map tunneled pack¡
   ets to their VPN.

   IPsec offers different levels of authentication, security and reply
   protection by using Authentication Header (AH) [RFC2402] and Encapsu¡
   lating Security Payload (ESP) [RFC2406]. If encryption is not needed
   or prevented by legal issues, then IPSec with NULL encryption algo¡
   rithm [RFC2410] can be used.

   IPSec must be able to forward IP and ME-ARP traffic (different proto¡
   col id) as well as support wildcard Security Associations (SA). A
   pair of SA's are defined per VPLS for bidirectional traffic inside a
   VPLS. A table linking VPLS Id and SA's in each gateway provides the
   binding between the VPLS IP multicast address and the current SPI
   used in each IPSec packet. Therefore there is no need to further
   encapsulate each VPLS packet to store the VPLS Id.


4.1.  Multicast and broadcast IP packets received from the

   Multicast and broadcast IP packets received by a VPLS interface must
   be sent to all members of the VPLS by sending them as IPSec tunneled
   packets to the multicast IP address assigned to the VPLS (VPLS Id).

   It is required to update the interface host table with the hardware
   and protocol source address of the packet. This ensures the proper
   delivery of reply traffic to the originating host, especially if the
   sending host used static host entries.


4.2.  Unicast IP packets intercepted from the PLS

   The VPLS interface must check each unicast packet for a constructed
   destination hardware address (originally created by this VPLS inter¡
   face).  The detection algorithm is directly related to the hardware
   address calculation algorithm defined below.

   If the destination hardware address originated from this VPLS



Wiget, et al               Expires: June 2000                  [Page 10]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   interface (created by the calculation algorithm) then it is sent as
   an IPSec tunnel packet to the remote gateway IP address reconstructed
   from the destination hardware address using the configured calcula¡
   tion algorithm.

   It is required to update the interface host table with the hardware
   and protocol source address of the packet. This ensures the proper
   delivery of reply traffic to the originating host, especially if the
   sending host used static host entries.


4.3.  Tunneled IP packets received from VPLS gateways

   IPSec encapsulated IP packets are sent to the local VPLS interface
   based on the SPI index matching an incoming SA. The IPSec tunnel
   source IP address is used to calculate the source hardware address of
   the packet.  The destination hardware address must be looked up in
   the interface host table. If no entry is found, then the packet is
   either discarded (not recommended) or handled according to the dis¡
   cussion below. The source hardware address is calculated based on the
   source outer IPsec tunnel IP header address. The algorithm used for
   the hardware address calculation can be found further below.

   Discussion: Contrary to the discard behavior of ARP replies, there
   might be a connectivity problem if the source IP device has a valid
   ARP entry for the destination protocol address but the host table of
   the remote VPLS interface got cleared. To recover from here there are
   basically two solutions:

     Local ARP for destination hardware address

          This would need a proper ARP handling by the VPLS interface
          and queue the packet until the hardware address is resolved.

     Send the packet to the broadcast hardware address

          This would ensure the delivery of the packet to the IP device
          (as well as all other devices which will discard the packet).
          This approach does increase the broadcast traffic but only
          until the local IP device sends any IP packet (broadcast, mul¡
          ticast or unicast) back to the originating host (connected to
          a remote PLS). Any of these packet will result in an update of
          the interfaces host table with the missing entry.


5.  VPLS examples


5.1.  CLE based Virtual Private LAN Segment (VPLS)


   Physical (Provider) View:

      PLS 1                                 PLS 2



Wiget, et al               Expires: June 2000                  [Page 11]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   |--------+---------|                  |---------+---------|
            |                .......               |
        +---+---+         .'         `.        +---+---+
        | CLE A +--------.             .-------+ CLE B |
        +-------+        .             .       +-------+
                         . IP Backbone .
        +-------+         .           .        +-------+
        | CLE C +----------.         .---------+ CLE D |
        +---+---+           `.......'          +---+---+
            |                                      |
   |--------+---------|                  |---------+---------|
      PLS 3                                   PLS 4

   The IP backbone and CLE devices A..D are managed (and typically owned)
   by the service provider.  The PLS 1..4 are managed (and typically owned)
   by the customer.


   Logical (Customer) View:

     PLS 1 + PLS 2 + PLS 3 + PLS 4 => VPLS
   |---------------------------------------------------------|
     1 flat IP subnetwork


   A layer 2 virtual private LAN segment can span two or more sites,
   with all IP devices do share the same IP subnet. The IP address and
   mask are chosen by the customer without any restrictions in relation
   to the provider or other customers. The CLE devices, managed by the
   provider, are completely transparent to the customer. This type of
   layer 2 VPN solution possesses the following benefits for the cus¡
   tomer:

     ¸ Transparency. No IP addresses must be given to the provider

     ¸ Flat IP subnet. The VPN can be seen as a VLAN, with transparent
       support for broadcast protocols like DHCP/BOOTP, Netbios/IP etc.

     ¸ Broadcast and Multicast support. The customer can extend the VPN
       with their own routers and run any routing protocol over the VPN
       without any coordination with the provider.

There are however also some drawbacks:

     ¸ Scalability. The number of IP devices participating in the VPN is
       limited, primarily by the percentage of broadcast and multicast
       traffic.


5.2.  Network based Virtual Private LAN Segment (VPLS)







Wiget, et al               Expires: June 2000                  [Page 12]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


5.2.1.  Functional Overview


   Physical (Provider) View:

        +-----+                                               +-----+
        |CPE A|-.                                           ,-|CPE B|
        +-----+  \   +------------+        +------------+  /  +-----+
                  `--+    VPN     |........|    VPN     +-'
                   ,-+Concentrator|        |Concentrator+-.
        +-----+   /  +------------+        +------------+  \  +-----+
        |CPE 1|--'         .          IP          .         `-|CPE C|
        +-----+            .       Backbone       .           +-----+
                           .                      .
                            .   +------------+   .
                             ...|    VPN     |...
                                |Concentrator|
                                +-+---+----+-+
                                  |   |    |
                       +-----+   /    |     \  +-----+
                       |CPE D|--'  +--+--+  `--|CPE 3|
                       +-----+     |CPE 2|     +-----+
                                   +-----+


   Logical (Customer) View:


        +-----+      +-----+                   +-----+      +-----+
        |CPE A|      |CPE B|                   |CPE 1|      |CPE 2|
        +-----+      +-----+                   +-----+      +-----+
               \    /                                \    /
            Frame Relay                            Frame Relay
              Network                                Network
               /    \                                   |
        +-----+      +-----+                         +--+--+
        |CPE C|      |CPE D|                         |CPE 3|
        +-----+      +-----+                         +-----+

            Customer ABCD                           Customer 123



   A typical VPN topology with Frame Relay edge connectivity is as fol¡
   lows:

   The provider network consists of an IP core with VPN concentrators on
   the edge. Customers have access routers on their premises which con¡
   nect to these edge routers using Frame Relay. Within a given VPN, CPE
   interfaces have configured IP addresses in the same subnet. CPE's are
   directly connected to the VPN concentrators (no Frame Relay switches
   in between). Therefore the VPN concentrator is providing DCE function
   in the data link management protocol (LMI, Q.933 Annex A/D, ...).




Wiget, et al               Expires: June 2000                  [Page 13]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   The VPN concentrator use ME-ARP as discussed in the previous chapter
   to resolve IP addresses in each VPLS on behalf of the connected
   CPE's.

   The Frame Relay interface of the CPE's are configured using IP
   addresses from the Client Address (CA) space. The VPN concentrator
   will learn these addresses using ARP as discussed in [RFC2427].

   The CPE will see the resulting VPN as a traditional Frame Relay net¡
   work and will be configured with multiple virtual circuits under each
   IP address per interface. The CPE device must be able to resolve IP
   addresses using ARP as described in [RFC2427].



5.3.  Interoperability between different types of PLS

   As ME-ARP doesn't transfer any hardware addresses to remote VPLS
   gateways and therefore hardware addresses do have only local signifi¡
   cance, it is absolutely possible to interconnect different types of
   PLS (ethernet, FR, SMDS, ...) into one VPLS and IP subnet.


6.  Security

   There are two distinct types of packet which are required to be pro¡
   tected; the ME-ARP requests and responses and the unicast tunnel data
   traffic. The ME-ARP messages are multicast, and so a manual SA should
   be configured with a wildcard destination address corresponding to
   the range of provider-side CLE addresses. If it is required to
   encrypt the ME-ARP messages, then the cipher key must be manually
   specified as part of the SA configuration. The key must be shared
   between all VPLS gateways. This does not provide a high level of
   security because of the long key lifetime, but in practice the data
   in these packets may be considered not to be particularly sensitive,
   the only potential issue being revealing the ip address of the pri¡
   vate destination device.

   For data traffic, which is generally much more sensitive, IKE
   [RFC2409] can be used to automate the creation of SAs. It defines two
   possibilities for authentication of tunnel endpoints, using either
   pre-shared keys or public key techniques. It is recommended that one
   of the public key mechanisms is used as this does not require shared
   keys to be distributed to all CLE devices, although note that even
   using pre-shared keys, it is inherently more secure than using a man¡
   ual SA because session keys are dynamically generated and rekeying
   takes place automatically.

   In addition to the above, user data security is further enhanced as
   VPLS interfaces can't be reached by a customer due to the lack of an
   assigned IP address. They don't respond to any IP traffic sent to
   them.

   Special considerations must be taken into account in cases where an



Wiget, et al               Expires: June 2000                  [Page 14]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   intruder can join a multicast group in the providers IP backbone.
   This is possible in networks where the provider gives native access
   to the IP backbone and IP multicast itself. Unfortunately IGMP
   [RFC2236] doesn't has security features defined, so either traffic or
   multicast policy filters SHOULD be used to prevent unauthorized joins
   to VPN multicast Id's.


7.  Scalability

   It is assumed, that VPLS networks will scale up to the size of single
   class C network, or, if only customer routers are interconnected
   which produce minimal broadcast traffic (routing protocol), it might
   scale even further. The scaling property is expected better for net¡
   work based VPLS as ME-ARP traffic is limited between the connected
   VPN concentrators on behalf of attached CPE's, which are most likely
   to be of static nature (compared to network devices attached to a
   physical LAN segment).


8.  Discussion

   An implementation might allow the usage of a list of unicast instead
   of a multicast IP address of the tunnel endpoints of a VPN (with one
   address chosen as VPN Id). This would reduce the number of assigned
   IP multicast addresses, especially for VPN's with only a few sites
   (2..5). The same IP unicast list must be maintained on all VPN joined
   CLE devices.


9.  Intellectual Property Considerations

   Nortel Networks may seek patent or other intellectual property pro¡
   tection for some of all of the technologies disclosed in this docu¡
   ment. If any standards arising from this document are or become pro¡
   tected by one or more patents assigned to Nortel, Nortel intends to
   disclose those patents and license them on reasonable and non-dis¡
   criminatory terms.


10.  Acknowledgments

   Many thanks for feedback and contributions from Mike Tate
   <mtate@nortelnetworks.com> and Robert Pluim <rpluim@nortelnet¡
   works.com>.


11.  References

   [Gleeson] Bryan Gleeson, Arthur Lin, Juha Heinanen, G. Armitage, A.
   Malis - "A Framework for IP Based Virtual Private Networks", draft-
   gleeson-vpn-framework-03.txt

   [Heinanen] Heinanen J., et al, "MPLS Mappings of generic VPN



Wiget, et al               Expires: June 2000                  [Page 15]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   mechanisms", draft-heinanen-generic-vpn-mpls-00.txt.

   [Meyer] Meyer D., "Administratively Scoped IP Multicast". RFC 2365.

   [RFC826] David C. Plummer, "An Ethernet Address Resolution Protocol",
   RFC 826, November 1982.

   [RFC2401]  S. Kent, R. Atkinson, "Security Architecture for the
   Internet Protocol",  RFC 2401, November 1998.

   [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
   (ESP)", RFC 2406, November 1998

   [RFC2410] R. Glenn, S. Kent, "The NULL Encryption Algorithm and Its
   Use With IPsec", RFC 2410, November 1998.

   [RFC2427] C. Brown, A. Malis, "Multiprotocol Interconnect over Frame
   Relay", RFC 2427, September 1998

Author's Addresses

   Marcel Wiget
   Nortel Networks EMEA, S.A.
   25, Allee Pierre Ziller
   06560 Valbonne - France

   EMail: mwiget@nortelnetworks.com

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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



Wiget, et al               Expires: June 2000                  [Page 16]

INTERNET DRAFT       draft-wiget-dynamic-vpls-00.txt     1 December 1999


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.























































Wiget, et al               Expires: June 2000                  [Page 17]