Network Working Group CY. Lee Internet-Draft L. Foster Expires: August 16, 2005 G. Govier A. Jansen Alcatel February 12, 2005 IP to VPLS Interworking draft-lee-l2vpn-ip2vpls-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 August 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes how standard IP devices connected to existing and heterogeneous access technologies can communicate with each other as if they were connected to a common LAN segment. In particular, it describes the interworking of IP and VPLS. Lee, et al. Expires August 16, 2005 [Page 1] Internet-Draft IP to VPLS Interworking February 2005 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IP Devices connected over multiple subnets . . . . . . . . . . 4 3. IP Devices connected over one subnet/broadcast network . . . . 6 4. Mechanisms required for IP to VPLS interworking . . . . . . . 7 5. Discovering the MAC address of a remote device - at Ethernet site . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Determining the MAC address of a destination IP address - at FR/ATM site . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Determining the MAC address of an unknown unicast IP address . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Traffic Encapsulation . . . . . . . . . . . . . . . . . . . . 11 7.1 Encapsulation of traffic from Ethernet site . . . . . . . 11 7.2 Encapsulation of traffic from FR/ATM site . . . . . . . . 11 8. Alternative Configuration . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Lee, et al. Expires August 16, 2005 [Page 2] Internet-Draft IP to VPLS Interworking February 2005 1. Overview This document describes how standard IP devices connected to existing and heterogeneous access technologies can communicate with each other as if they were connected to a common LAN segment. In particular, it describes the interworking of IP and VPLS. The document illustrates the interface between IP over X (where X is non-Ethernet) and VPLS, with examples of how a CE router with point-to-point interface such as Frame Relay or ATM access can appear as a node on the emulated LAN. This allows a CE to work with other CEs as if it is connected to the same LAN as the other CEs. Only one DLCI is required at a CE router with FR access to allow it to peer with other routers with Ethernet or FR/ATM access. This reduces the amount of provisoning required by end customers. For instance, instead of provisioning m point-to-point DLCIs and m subnets for routers to peer, an end customer only need one DLCI or Ethernet interface and an IP address for one subnet on a router, to allow the router to peer with other routers on the emulated LAN. When a new site is added, only the new router need to be provisioned and only one DLCI or one Ethernet interface is required. Note that the need for only one DLCI or Ethernet link does not prevent additional access interfaces to be used for redundancy. Alternatively, if there are existing FR CE devices configured with routed encapsulation and it is not feasible to reconfigure the FR CE devices (to peer on a broadcast network instead of a point-to-point network), some of the FR CE and Ethernet CE devices can be connected to different subnets instead. Additional provisioning is required on routers for the different subnets. Lee, et al. Expires August 16, 2005 [Page 3] Internet-Draft IP to VPLS Interworking February 2005 2. IP Devices connected over multiple subnets This method allows a CE with FR/ATM access to peer with a CE with Ethernet access over a different subnet than the emulated LAN used by CEs with Ethernet access, allowing an FR/ATM CE to maintain the existing configuration. For e.g. CE2 was connected to CE4 via a FR access link and both CE2 and CE4 was using a routed encapsulation. When CE2 access link is changed to Ethernet, 2 IP interfaces can be defined on the Ethernet interface, one for a VPLS connected to other Ethernet CE routers, the other is for a p2p link to CE4. No configuration change is required on CE4 in this case. Eth Eth CE1--------------+ +---------CE2 | <----EthoPSN-----> | + ------ | +----+ +----+ | | | | | | |-AC2a-+ | +--| PE1|----PSN----| PE2|-AC2b---+ +----+ Backbone +----+ ^ | ^ ^ | | EthoPSN| |IPoPSN/ EthoPSN | | | |EthoPSN | +----+ | | +----| |<-----+ | | PE3|<-------+ +----+ | | | +------+ | | | | | | FR Eth| | | CE4 | CE3 Figure 1 - IP Devices connected over multiple subnets a) AC2a is on the same subnet as CE1,CE3 (emulated LAN service) b) AC2b is on the same subnet as CE4 (p2p IP over Ethernet service) If the number of end customer sites are large, grouping sites into different subnets/emulated LAN would be a reasonable approach to scale the Virtual Private LAN or VPN design, while reducing the Lee, et al. Expires August 16, 2005 [Page 4] Internet-Draft IP to VPLS Interworking February 2005 provisioning required by peering routers over multiple emulated LAN or VPLS. The disadvantage is some CEs with Ethernet access would need to be configured to peer with multiple FR/ATM sites on separate subnets instead of with one subnet (as with other CEs with Ethernet sites), even for a VPN with a relatively smaller number of sites, as shown in the above figure. The next alternative overcomes this issue but requires configuration changes in CE routers. Lee, et al. Expires August 16, 2005 [Page 5] Internet-Draft IP to VPLS Interworking February 2005 3. IP Devices connected over one subnet/broadcast network This method allows all CEs to peer over the same emulated LAN or subnets, but require configuration changes on FR/ATM CEs routers (e.g. OSPF Interface Type is changed to broadcast mode). It allows CE devices which for whatever reason are not able to use bridged encapsulation instead of routed encapsulation, but desire to peer over the same emulated LAN, instead of over different subnets as in the previous case. .................................................... . . . . Eth Eth . CE1------AC1a----+ +---------CE2 . | <----EthoPSN-----> | . . | +----+ +----+ | . . | | | | |-AC2a-+ . . +--| PE1|----PSN----| PE2| . . +----+ Backbone +----+ . . ^ | ^ . . | | | . . EthoPSN | | |EthoPSN . . | +----+ | . . +----| | | . . | PE3|<-------+ . . +----+ . . | | . . | +------+ . . | | . . | | . . | | FR . . Eth| | . ......................|.......CE4.................... | Broadcast network CE3 Figure 2 - IP Devices over a Broadcast network Note: CE1,CE2,CE3,CE4 are all on the same subnet Lee, et al. Expires August 16, 2005 [Page 6] Internet-Draft IP to VPLS Interworking February 2005 4. Mechanisms required for IP to VPLS interworking The mechanisms required for the above mentioned methods are described in this section. These mechanisms can be provided by either PE3 or PE2. To simplfied the explanation, we shall consider only the case where PE3 is providing the IP to VPLS interworking functions. The common problem for both cases is one end of the service is point- to-point in nature and the other end is a shared media, and there are no Ethernet names/addresses (as in bridged encapsulation) provided from the point-to-point end, when routed encapsulation is used. Further, it cannot be assumed that PE2 can only see one MAC device on AC2a. An Attachment Circuit, AC2a at the Ethernet end at Site 2, may have more than one MAC device attached to it. CE2 may be a bridge and there may be more than one router connected to CE2 at the customer site. Lee, et al. Expires August 16, 2005 [Page 7] Internet-Draft IP to VPLS Interworking February 2005 5. Discovering the MAC address of a remote device - at Ethernet site To discover the MAC address of network address of CE4 router as shown in Figure 2, the following procedure takes place. The device sending the packet at Site 1 (CE1) shall use already defined specifications. For e.g. CE1 shall send an ARP request for CE4 router to the emulated LAN via AC1a. PE3 shall act as a Proxy ARP and respond with an assigned MAC address for CE4 IP address. PE3 shall be configured a priori with the IP addresses of attached FR/ATM CEs or alternatively PE3 may use Inverse ARP to discover the IP address of the FR/ATM CE. At PE3, a local MAC address (not IEEE allocated) is allocated for each FR CE. This allows PE3 to respond to ARP request for an FR CE with this assigned MAC address. Lee, et al. Expires August 16, 2005 [Page 8] Internet-Draft IP to VPLS Interworking February 2005 6. Determining the MAC address of a destination IP address - at FR/ATM site To illustrate the problem to be solved, Fig 2 shows CE4 connected to the emulated LAN. Traffic from CE4 is routed encapsulated at the FR/ATM access link. Only the destination IP address is available when the routed encapsulation traffic from CE4 is decapsulated at PE3. PE3 needs to determine or learn the corresponding destination MAC address of the destination IP address. It should be noted that they may be other MAC devices on AC2a in Fig 2. If the IP packet received from CE4 is multicast, the corresponding MAC address can be derived from the IP multicast address as is specified today. If the packet received from CE4 is unicast, there are two cases to be considered: 1) In the first case, if the packet from CE4 is unicast and the corresponding MAC address of the destination IP address have been learned already either from IP packets send by CE2 to CE4 prior to CE4 transmission to CE2, e.g via IP control plane messages such as ARP or IGP hello, or IP data packets routed by CE2 to CE4. In this case, PE3 has already learned the MAC address to send the IP packet to. The MAC address could be: - the MAC address of the remote device if the remote device is in the same subnet as the emulated LAN or - the MAC address of a router if the remote device is in a different subnet as the emulated LAN 2)In the second case, the packet from CE4 is unicast and the corresponding MAC address is not learned yet. The procedure to handle this case shall be described in the following section. PE3 keeps an IP address to MAC address mapping in an IP-MAC table. As PE3 learns new IP addresses which maps to the same MAC address, it shall aggregate the IP address to the shortest prefix learned, for e.g. if the IP-MAC table has 10.1.1.10 maps to aa:bb:cc:dd:ee:ff, and PE3 learns a new IP address, 10.1.1.20 mapping to the same MAC address, PE3 shall aggregate the IP addresses into one entry, 10.1.1.x. The implication is that only the aggregated routes of (mapped to the corresponding router MAC addresses) remote sites are cached. If aggregation is not performed, an IP-MAC entry is required for every remote device. Lee, et al. Expires August 16, 2005 [Page 9] Internet-Draft IP to VPLS Interworking February 2005 6.1 Determining the MAC address of an unknown unicast IP address PE3 sends an ARP request for the MAC address of the unknown unicast IP address on the VPLS. A CE responds with its MAC address. If it is a router, it is a Proxy ARP for other IP addresses it routes to. This method requires that CE routers (at Ethernet sites) are Proxy ARP enabled. This Proxy ARP function is provided by a PE at an FR/ATM site. Other alternative methods of determining the MAC address of an unknown unicast IP address is FFS. Lee, et al. Expires August 16, 2005 [Page 10] Internet-Draft IP to VPLS Interworking February 2005 7. Traffic Encapsulation 7.1 Encapsulation of traffic from Ethernet site This is as defined in [VPLS]. 7.2 Encapsulation of traffic from FR/ATM site PE3 shall decapsulate/encapsulate the IP traffic from/to CE4 as defined in [FR-MP] or [ATM-MP]. PE3 shall encapsulate an IP packet from CE4 in an Ethernet frame and shall set the source MAC address to the MAC address assigned to the FR CE and the destination MAC address as described in the Section "Determining the MAC address of a destination IP address - at FR/ATM site" PE3 shall encapsulate/decapsulate the Ethernet frame to other PEs as defined in [VPLS]. Lee, et al. Expires August 16, 2005 [Page 11] Internet-Draft IP to VPLS Interworking February 2005 8. Alternative Configuration In some deployment, it may not be feasible to upgrade the FR/ATM PE device. In this case, this the FR/ATM PE can be connected to a PE via an Attachment Circuit (AC) as shown below. The FR/ATM PE is not part of the VPLS PE mesh. All the MAC discovery functions described for PE3 is now provided by PE2 instead. PE4 merely relay IP frames from CE5 to PE2 and does not participate in VPLS functions. PE4 shall decapsulate/encapsulate the IP traffic from/to FR/ATM CE5 as defined in [FR-MP] or [ATM-MP]. PE4 shall encapsulate/decapsulate traffic to PE2 as IP over PW or routed encapsulation as defined in [FR-MP] or [ATM-MP]. .................................................... . . . . Eth Eth . CE1------AC1a----+ +---------CE2 . | <----EthoPSN-----> | . . | +----+ +----+ | . . | | | | |-AC2a-+ . . +--| PE1|----PSN----| PE2| . . +----+ Backbone +----+ . . ^ | ^ ^ . . | | Etho| | . . EthoPSN | | PSN | | . . | +----+ | AC5a . . +----| | | | . . | PE3|<-----+ | . . +----+ | . . | | | . . | +-----+ +---+ . . | | |PE4| . . | | +---+ . . | | |FR . . Eth| | | . ......................|......CE4...CE5.............. Broadcast network | CE3 Figure 3 - IP Devices over a Broadcast network Note: CE1,CE2,CE3,CE4, CE5 are all on the same subnet Lee, et al. Expires August 16, 2005 [Page 12] Internet-Draft IP to VPLS Interworking February 2005 9. Security Considerations This proposal does not introduce any new security issues in network-based VPN. Lee, et al. Expires August 16, 2005 [Page 13] Internet-Draft IP to VPLS Interworking February 2005 10. Acknowledgements This work has been adapted from the section on Routed Encapsulation in Hybrid VPLS, which benefited from suggestions by Jeremy deClercq and Ather Chaudhry. Thanks to Parker Moore for his helpful comments. 11. Normative References [ATM-MP] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, March 1997. [FR-MP] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, Sept 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Sept 1990. [VPLS] Lasseurre, M. and V. Kompella, "Virtual Private LAN Service", draft-ietf-l2vpn-vpls-ldp-05.txt, 2004. Authors' Addresses Cheng-Yin Lee Alcatel Phone: Email: Cheng-Yin.Lee@alcatel.com Lindsay Foster Alcatel Phone: Email: Lindsay.Foster@alcatel.com Glen Govier Alcatel Phone: Email: Glen.Govier@alcatel.com Lee, et al. Expires August 16, 2005 [Page 14] Internet-Draft IP to VPLS Interworking February 2005 Arnold Jansen Alcatel Phone: Email: Arnold.Jansen@alcatel.com Lee, et al. Expires August 16, 2005 [Page 15] Internet-Draft IP to VPLS Interworking February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee, et al. Expires August 16, 2005 [Page 16]