[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11                           
Network working group                                             X. Xu
Internet Draft                                      Huawei Technologies
Category: Standard Track
Expires: July 2011                                     January 24, 2011


        Virtual Subnet: A Scalable Data Center Network Architecture

                        draft-xu-virtual-subnet-04


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on July 22, 2011.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.






Xu                     Expires July 24, 2011                 [Page 1]


Internet-Draft               Virtual Subnet                January 2011

Abstract

   This document proposes a new IP-only L2VPN solution which uses
   BGP/MPLS IP VPN technology [RFC4364] with some extensions, together
   with some other proven technologies including ARP proxy
   [RFC925][RFC1027] to provide a more scalable IP-only L2VPN services
   across a MPLS/IP backbone. This solution is intended to be a
   scalable data center network architecture which can be deployed
   today as an alternative to the spanning tree protocol bridge
   technology.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents


   1. Problem Statement...........................................3
   2. Terminology.................................................3
   3. Design Goals................................................3
   4. Architecture Description....................................4
      4.1. Unicast................................................5
         4.1.1. Unicast inside a Service Domain...................5
         4.1.2. Unicast outside a Service Domain..................6
      4.2. Multicast/Broadcast....................................7
      4.3. CE Host Discovery......................................8
      4.4. CE Host Multi-homing and Mobility......................8
      4.5. APR Proxy..............................................9
      4.6. DHCP Relay Agent.......................................9
   5. Comparison..................................................9
      5.1. VS vs VPLS.............................................9
      5.2. VS vs IPLS............................................10
   6. Conclusion.................................................11
   7. Future work................................................11
   8. Security Considerations....................................11
   9. IANA Considerations........................................11
   10. Acknowledgements..........................................11
   11. References................................................12
      11.1. Normative References.................................12
      11.2. Informative References...............................12
   Authors' Addresses............................................13






Xu                     Expires July 24, 2011                 [Page 2]


Internet-Draft               Virtual Subnet                January 2011


1. Problem Statement

   With the popularity of cloud services, the scale of today's data
   centers expands larger and larger. In addition, virtual machine
   migration technology, which allows a virtual machine to be able to
   migrate to any physical server while keeping the same IP address, is
   becoming more and more prevalent for achieving service agility in
   data centers. As a result, large Layer 2 networks are needed for
   server-to-server connectivity. Meanwhile, due to the huge-volume
   traffic exchanged between servers, the Layer 2 networks SHOULD
   provide enough capacity for server-to-server interconnections.

   Unfortunately, today's data center network using the Spanning-Tree
   Protocol (STP) bridge technology, can not address the above
   challenges facing today's large-scale data centers in several ways.
   First, STP can calculate out only one single forwarding tree for all
   connected servers of a particular Virtual Local Area Network (VLAN)
   and it can not support multi-path routing, e.g., Equal Cost Multi-
   Path (ECMP), hence the available network capacity in data center
   networks can't be highly utilized so as to provide enough bandwidth
   between servers; Second, since the bridge forwarding is based on the
   flat MAC addresses, the scalability of the bridge forwarding table
   would become a big issue, especially when the existing large Layer 2
   network scales even larger; Third, broadcast storm impacts imposed
   by some protocols, e.g., Address Resolution Protocol (ARP) and the
   flooding of unknown destination unicast frames become much more
   serious and unpredictable in the continually growing large-scale STP
   bridge networks.

2. Terminology

   This memo makes use of the terms defined in [RFC4364], [MVPN],
   [RFC2236] and [RFC2131]. Below are provided terms specific to this
   document:

      - Service Domain: A group of servers which are dedicated for a
      given service and are usually located on a separate IP subnet.

3. Design Goals

   To overcome the limitations of the STP bridge networks as mentioned
   above, this document describes Virtual Subnet (VS), a new IP-only
   L2VPN solution which is intended to be a practical and scalable data
   center network architecture meeting the following objectives:

      - Bandwidth Utilization Maximization



Xu                     Expires July 24, 2011                 [Page 3]


Internet-Draft               Virtual Subnet                January 2011

   To provide enough bandwidth between servers, the server-to-server
   traffic SHOULD always be delivered along the shortest paths while
   multi-path routing is used for load-balancing purpose.

      - Layer 2 Connectivity

   To be backwards compatible with existing applications and protocols
   running in today's data centers (e.g., virtual machine migration),
   servers of a given service domain SHOULD be connected as if they
   were on a Local Area Network (LAN) or an IP subnet.

      - Domain Isolation

   To achieve performance and security isolation, servers belonging to
   different service domains SHOULD be isolated just as if they were
   located on separate Virtual LANs (VLAN) or IP subnets.

      - Forwarding Table Scalability

   To accommodate tens to hundreds of thousands of servers in a single
   data center network, the forwarding tables of those forwarding
   devices (e.g., routers or bridges) SHOULD be scalable enough.

      - Broadcast Storm Suppression

   To alleviate the serious impacts on network performance which are
   imposed by broadcast storms, broadcast domains SHOULD be limited to
   their smallest scopes.

4. Architecture Description

   VS uses BGP/MPLS IP VPN technology [RFC4364] with some extensions,
   together with other proven technologies including ARP proxy
   [RFC925][RFC1027] to provide scalable IP-only L2VPN services across
   a MPLS/IP backbone.

   Since VS constructs large-scale IP subnets, rather than real LANs,
   across the MPLS/IP backbone, the non-IP traffic would not be
   supported in VS anymore. However, given that IP traffic is the
   predominant type of traffic in today's data center networks and the
   non-IP traffic will disappear from the data center networks with the
   elapse of time, we believe that VS can be used as a practical data
   center network solution in most cases.

   The following sections describe VS in detail.





Xu                     Expires July 24, 2011                 [Page 4]


Internet-Draft               Virtual Subnet                January 2011

   4.1. Unicast

   4.1.1. Unicast inside a Service Domain

                          +--------------------+
    +-----------------+   |                    |   +------------------+
    |VPN_A:10/8       |   |                    |   |VPN_A:10/8        |
    |                 |   |                    |   |                  |
    |    +------+    ++---+-+                +-+---++    +------+     |
    |    |Host A+----+ PE-1 |                | PE-2 +----+Host B|     |
    |    +------+    ++-+-+-+                +-+-+-++    +------+     |
    |   10.1.1.1/8    | | |  IP/MPLS Backbone  | | |    10.1.1.2/8    |
    +-----------------+ | |                    | | +------------------+
                        | +--------------------+ |
                        |                        |
                        |                        |
                        V                        V
    +-------+------------+--------+     +-------+------------+--------+
    |VRF ID |Destination |Next Hop|     |VRF ID |Destination |Next Hop|
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.1.1.1/32 |  Local |     | VPN_A |10.1.1.2/32 |  Local |
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.1.1.2/32 |  PE-2  |     | VPN_A |10.1.1.1/32 |  PE-1  |
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.0.0.0/8  |  NULL  |     | VPN_A |10.0.0.0/8  |  NULL  |
    +-------+------------+--------+     +-------+------------+--------+

                 Figure 1: Unicast inside a Service Domain

   As shown in Figure 1, BGP/MPLS IP VPN technology with some
   extensions is deployed in a data center network. To maintain proper
   isolation of one service domain from another, each service domain is
   mapped to a distinct VPN and servers of a given service domain, as
   Customer Edge (CE) hosts, are attached to Provider Edge (PE) routers
   directly or through one or more Ethernet bridges. In addition, to
   build large IP subnets across the MPLS/IP backbone, different sites
   of a particular VPN are associated with an identical IP subnet. PE
   routers create host routes for their local CE hosts automatically
   according to the corresponding ARP entries. Instead of distributing
   the routes for the configured VPN subnets, PE routers distribute
   host routes for their local CE hosts to each other. In addition,
   each PE router automatically creates a route for the configured VPN
   subnet whose next-hop is pointed to a null interface. With such
   special route, packets destined for the nonexistent hosts of that
   subnet will be discarded directly by the ingress PE routers. APR
   proxy is implemented on PE routers for every attached VPN, thus,
   upon receiving from a local CE host an ARP request for a remote CE



Xu                     Expires July 24, 2011                 [Page 5]


Internet-Draft               Virtual Subnet                January 2011

   host, the PE as an ARP proxy returns its own MAC address as a
   response.

   Assume host A broadcasts an ARP request for host B before
   communicating with B, upon the receipt of this ARP request, PE-1
   lookups the associated VRF to find the host route for B. If found
   and the route is learnt from a remote PE, PE-1 acting as an ARP
   proxy returns its own MAC address in the response to that ARP
   request. Otherwise, no ARP reply SHOULD be sent. After obtaining the
   ARP reply from PE-1, A sends an IP packet to B with destination MAC
   address of PE-1's MAC address. Upon receiving this packet, PE-1
   acting as an ingress PE, tunnels the packet towards PE-2 which in
   turn, as an egress PE, forwards the packet to B.

   4.1.2. Unicast outside a Service Domain

                          +--------------------+
    +-----------------+   |                    |   +-------------+
    |VPN_A:10/8       |   |                    |   |VPN_A:10/8   |
    |                 |   |                    |   |             |
    |    +------+    ++---+-+                +-+---++       +----+--+
    |    |Host A+----+ PE-1 |                | PE-2 +-------+   GW  |
    |    +------+    ++-+-+-+                +-+-+-++       +----+--+
    |   10.1.1.1/8    | | |  IP/MPLS Backbone  | | |10.1.1.2/8   |
    +-----------------+ | |                    | | +-------------+
                        | +--------------------+ |
                        |                        |
                        |                        |
                        V                        V
    +-------+------------+--------+     +-------+------------+--------+
    |VRF ID |Destination |Next Hop|     |VRF ID |Destination |Next Hop|
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.1.1.1/32 |  Local |     | VPN_A |10.1.1.2/32 |  Local |
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.1.1.2/32 |  PE-2  |     | VPN_A |10.1.1.1/32 |  PE-1  |
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |10.0.0.0/8  |  NULL  |     | VPN_A |10.0.0.0/8  |  NULL  |
    +-------+------------+--------+     +-------+------------+--------+
    | VPN_A |0.0.0.0/0   |  PE-2  |     | VPN_A |0.0.0.0/8   |   GW   |
    +-------+------------+--------+     +-------+------------+--------+

                 Figure 2: Unicast between Service Domains

   As shown in Figure 2, for a CE host (e.g., host A) to communicate
   with other hosts outside its subnet, the PE router (e.g., PE-2)
   which is connected to the default gateway router (e.g., GW) for that
   VPN SHOULD be configured with a default route with the next-hop of



Xu                     Expires July 24, 2011                 [Page 6]


Internet-Draft               Virtual Subnet                January 2011

   the default gateway router and then advertise such default route to
   other PE routers of the same VPN. Now host A sends an ARP request
   for its default gateway (i.e., GW) before sending a packet to a host
   outside its subnet. Upon receiving this ARP request, PE-1 lookups
   the associated VRF to find the host route for GW. If found and that
   found host route is learnt from a remote PE, PE-1 as an ARP proxy,
   returns its own MAC address in the ARP reply. Host A then sends an
   IP packet for the destination host with destination MAC address of
   PE-1's MAC. Upon receiving this packet, PE-1 as an ingress PE,
   tunnels it towards PE-2 according to the best route (i.e., the
   default route learnt from PE-2) for the destination host. PE-2 as an
   egress PE, in turn, forwards the received packet towards the default
   gateway router (i.e., GW). Due to the null route for the subnet,
   packets destined for those nonexistent CE hosts of that subnet would
   not be mistakenly forwarded to the default gateway router of that
   subnet.

   In the scenario where more than one default gateway router running
   Virtual Router Redundancy Protocol (VRRP) [RFC2338] is connected to
   a given VPN for redundancy purpose, only the PE router which is
   connected to the Virtual Router Master SHOULD be allowed to announce
   a default route into that VPN. To achieve that goal, a default route
   with the next-hop of the corresponding Virtual Router IP address is
   configured for that VPN instance on each of the PE routers which are
   connected to the VRRP routers. In addition, the default route SHOULD
   not be deemed as valid until there is an active host route for its
   next-hop address. Since only the Virtual Router Master is allowed to
   respond to ARP requests for the Virtual Router IP address and
   broadcast gratuitous ARP requests containing the Virtual Router IP
   address, only the PE router which is connected to the Virtual Router
   Master could have an active ARP entry for the Virtual Router IP
   address and therefore could have an active host route for the
   Virtual Router IP address (i.e., the next-hop address of the
   configured default route). In this way, all packets destined for the
   outside would be sent to the corresponding Virtual Router Master.

   4.2. Multicast/Broadcast

   The MVPN technology [MVPN], in particular, the Protocol-Independent-
   Multicast (PIM) tree option with some extensions, is partially
   reused here to support IP multicast and broadcast between CE hosts
   of the same VPN. For example, PE routers attached to a given VPN
   join a default provider multicast distribution tree which is
   dedicated for that VPN. PE routers receiving customer multicast or
   broadcast traffic from local CE hosts forward such traffic to other
   remote PE routers over the corresponding default provider multicast
   distribution tree. When customer multicast or broadcast traffic is



Xu                     Expires July 24, 2011                 [Page 7]


Internet-Draft               Virtual Subnet                January 2011

   received from a provider multicast distribution tree, PE routers
   forward such traffic to the associated VRF attachment circuits.

   For the customer multicast group of a particular VPN which carries
   high-volume traffic and not all sites of that VPN need the traffic
   of that customer multicast group, a dedicated provider multicast
   distribution tree other than the default provider multicast
   distribution tree for that VPN can be assigned optionally. As a
   result, those PE routers of that VPN that have no local CE hosts
   which are interested in that customer multicast group will not
   receive such traffic from remote PE routers anymore.

   More details about how to support multicast and broadcast traffic in
   VS will be explored in a later version of this document.

   4.3. CE Host Discovery

   To discover all local CE hosts including gateway routers, PE routers
   SHOULD perform at least once ARP scan on the attached VPN subnet
   after rebooting. For example, a PE broadcasts an ARP request for
   each IP address within the subnet of each attached VPN.
   Alternatively, this PE could also broadcast an ARP request for a
   directed broadcast address (i.e., 255.255.255.255) or an ALL-Systems
   multicast group address (i.e., 224.0.0.1), that is to say, the
   target protocol address field is filled with 2555.255.255.255 or
   224.0.0.1. Any CE host receiving this ARP request SHOULD respond
   with an ARP reply containing its IP and MAC addresses. After a round
   of such ARP scan, the PE will discover all local CE hosts and cache
   their ARP entries in its ARP table. After that, the PE could send
   ARP requests in unicast to each already-learnt local CE host
   periodically so as to check whether the CE host is still present on
   the subnet. Using unicast ARP requests has the advantage that it is
   quieter than using the broadcast because it won't be received by all
   CE hosts on the subnet. When receiving a gratuitous ARP from a local
   CE host, the PE SHOULD cache the ARP entry of that CE host in its
   ARP table immediately if no ARP entry for that CE host exists yet.
   Otherwise, the PE SHOULD just update the corresponding ARP entry of
   that CE host. Most operating systems generate a gratuitous ARP
   request when the host boots up, the host's network interface or
   links comes up, or an address assigned to the interface changes. In
   the scarce scenarios where a host does not generate a gratuitous ARP,
   the PE would have to perform ARP scan periodically.

   4.4. CE Host Multi-homing and Mobility

   When a given PE receives a host route for one of its local CE hosts
   from a remote PE, it SHOULD immediately send an ARP request for that



Xu                     Expires July 24, 2011                 [Page 8]


Internet-Draft               Virtual Subnet                January 2011

   CE host to the attached VPN subnet so as to determine whether that
   CE host is still connected locally. If an ARP reply is received in a
   short amount of time (imaging the CE host multi-homing scenario),
   the PE just needs to update the ARP entry for that CE host as normal.
   Otherwise (considering the virtual machine migration scenario), the
   PE SHOULD delete the ARP entry corresponding to that host from its
   APR table. Meanwhile, the PE SHOULD broadcast a gratuitous ARP on
   the attached VPN subnet on behalf of that CE host, with the sender
   hardware address field being filled with one of its own MAC
   addresses. As a result, the ARP entry for that CE host which has
   been cached on other local CE hosts is updated.

   4.5. APR Proxy

   The PE, acting as an ARP proxy, SHOULD only respond to the ARP
   requests for those CE hosts which have been learnt from other remote
   PE routers. Especially, the PE SHOULD not respond to ARP requests
   for local CE hosts. Otherwise, in case that the ARP reply from the
   PE covers that from the requested CE host, the packet for that local
   CE host which is sent from another local CE would be unnecessarily
   relayed by the PE.

   When VRRP, together with ARP proxy is enabled on multiple PE routers
   which are attached to the same VPN site, only the PE acting as
   Virtual Router Master is delegated to perform ARP proxy function on
   the shared VPN subnet. In addition, it SHOULD use the Virtual Router
   MAC address in any ARP packet it sends.

   4.6. DHCP Relay Agent

   To avoid flooding Dynamic Host Configuration Protocol (DHCP)
   [RFC2131] broadcast messages through the data center network, DHCP
   Relay Agent can be implemented on PE routers for each attached VPN.
   Thus, DHCP broadcast messages received from DHCP clients on local CE
   hosts would be relayed by DHCP Relay Agents on PE routers to DHCP
   servers in unicast.

5. Comparison

   5.1. VS vs VPLS

   Virtual Private LAN Service (VPLS) [RFC4761, RFC4762] provides
   private LAN services for IP as well as other protocols. Since PE
   routers in VPLS work much similar as STP bridges, broadcast storm
   issues are intactly inherited from traditional STP bridge networks
   to VPLS.




Xu                     Expires July 24, 2011                 [Page 9]


Internet-Draft               Virtual Subnet                January 2011

   At the cost of being lacking in support for non-IP traffic, VS
   alleviates the broadcast storm issues by using Layer 3 routing and
   ARP proxy technologies on PE routers.

   In addition, if CE hosts of multiple VPNs are attached to a PE
   router through an intermediate Ethernet bridge, in VPLS, this
   intermediate bridge would have to learn the MAC addresses of both
   local CE hosts and remote CE hosts of these attached VPNs. However,
   in VS, such intermediate bridge only needs to learn MAC addresses of
   local CE hosts and local PE routers due to the ARP proxy implemented
   on PE routers.

   5.2. VS vs IPLS

   Both VS and IP LAN Service (IPLS) [IPLS] are IP only L2VPN
   technologies.

   However, IPLS is different from VS in several aspects. First, in
   IPLS, ARP packets even including the unicast ARP reply packets are
   forwarded from attachment circuits to "multicast" PWs and the
   received APR packets from the "multicast" PWs will be flooded to all
   CE hosts (although broadcast ARP request packets can be suppressed
   by PE routers on which there are matching ARP entries for the ARP
   requests in their ARP caches). As a result, the broadcast storm
   imposed by ARP traffic is worsened to some extent, rather than being
   alleviated. In contrast, by using ARP Proxy on PE routers in VS, ARP
   traffic is limited within small network scopes. Second, as said in
   [IPLS], "An IP frame received over a unicast PW is prepended with a
   MAC header before transmitting it on the appropriate attachment
   circuits and the source MAC address is the PE router's own local MAC
   address or a MAC address which has been specially configured on the
   PE router for this use." However, the destination MAC address of the
   packet to a remote CE host which is sent from a local CE host is the
   MAC of the remote CE host, rather than the local PE router's MAC.
   Thus, flooding unknown destination unicast frames on the above
   Ethernet bridges would not be avoided anymore unless these
   intermediary bridges are configured to not age out the learned MAC
   entries (whether such configuration has any side-effects is
   uncertain). In contrast, such intermediate bridges in VS only need
   to learn MAC addresses of local CE hosts and local PE routers. Third,
   IPLS prohibits connection of a common LAN or VLAN to more than one
   PE router. In other words, IPLS can not allow CE hosts to be multi-
   homed to multiple PE routers for redundancy and load-balancing. In
   contrast, VS can support CE multi-homing easily.






Xu                     Expires July 24, 2011                [Page 10]


Internet-Draft               Virtual Subnet                January 2011

6. Conclusion

   By using Layer 3 routing on the backbone of the data center network
   to replace the STP bridge forwarding, traffic between any two
   servers is forwarded along shortest paths between them and multi-
   path routing is easily achieved. Thus, the totally available
   bandwidth in data center networks is utilized to the maximum extent.

   By reusing the BGP/MPLS IP VPN technology to build large IP subnets
   across the backbones of data center networks, servers of a given VPN
   are allowed to communicate with each other just as if they were on
   the same subnet.

   Due to the BGP/MPLS IP VPN technology, forwarding tables of P
   routers are sized to the number of PE routers rather than the total
   number of CE hosts. Meanwhile, forwarding tables of PE routers can
   also scale well by distributing VPN instances and their
   corresponding routing tables among multiple PE routers. Especially,
   thanks to the Outbound Route Filtering (ORF) capability of BGP, PE
   routers only needs to maintain the routing tables of their attached
   VPN instances. Thus, the forwarding table scalability issues with
   today's data center networks are largely alleviated.

   By enabling APR proxy function on PE routers, ARP broadcast messages
   from local CE hosts are blocked by local PE routers. Thus, APR
   broadcast messages will not flood the whole data center network.
   Besides, by enabling DHCP Relay Agent function on PE routers, DHCP
   broadcast messages from local CE hosts are intercepted by DHCP Relay
   Agents and forwarded to DHCP servers in unicast. Thus, the broadcast
   storms in data center networks are largely suppressed.

7. Future work

   How to support IPv6 CE hosts in VS is for future study.

8. Security Considerations

   TBD.

9. IANA Considerations

   There is no requirement for IANA.

10. Acknowledgements

   Thanks to Dino Farinacci for his valuable comments.




Xu                     Expires July 24, 2011                [Page 11]


Internet-Draft               Virtual Subnet                January 2011

11. References

11.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2. Informative References

   [RFC4364] Rosen. E and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.

   [MVPN] Rosen. E and Aggarwal. R, "Multicast in MPLS/BGP IP VPNs",
             draft-ietf-l3vpn-2547bis-mcast-10.txt (work in progress),
             Janurary 2010.

   [MVPN-BGP] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter,  C.
             Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP
             VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt (work in
             progress), September 2009.

   [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or
             Converting Network Protocol Addresses to 48-bit Ethernet
             Addresses for Transmission on Ethernet Hardware", RFC-826,
             Symbolics, November 1982.

   [RFC925] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC
             Information Sciences Institute, October 1984.

   [RFC1027] Smoot Carl-Mitchell, John S. Quarterman, "Using ARP to
             Implement Transparent Subnet Gateways", RFC 1027, October
             1987.

   [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol",
             RFC 2338, April 1998.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997.

   [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
             2", RFC 2236, November 1997.

   [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
             (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
             4761, January 2007.





Xu                     Expires July 24, 2011                [Page 12]


Internet-Draft               Virtual Subnet                January 2011

   [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
             (VPLS) Using Label Distribution Protocol (LDP) Signaling",
             RFC 4762, January 2007.

   [IPLS] H. Shah., et. al., "IP-Only LAN Service (IPLS)", draft-ietf-
             l2vpn-ipls-09.txt (work in progress), February 2010.



Authors' Addresses

   Xiaohu Xu
   Huawei Technologies,
   Hai-Dian District, Beijing 100085, P.R. China
   Phone: +86 10 82882573
   Email: xuxh@huawei.com


































Xu                     Expires July 22, 2011                [Page 13]