One document matched: draft-lee-l2vpn-ip2vpls-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:41 |