Internet Engineering Task Force Chandrasekar Kathirvelu
INTERNET-DRAFT Karthik Muthukrishnan
Expires January 2002 Tom Walsh
Lucent Technologies
Andrew Malis Fred Ammann
Vivace Networks, Inc. COMMCARE telecommunications
July 2001
A Core MPLS IP VPN Link Broadcast And Virtual Router Discovery
<draft-kathirvelu-corevpn-disc-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
An IPVPN consists of many routers, some physically discrete and
some virtual, housed in a Provider Edge router. The problem that
presents itself is that these virtual routers need to find each
other over a virtual topology and they need to send broadcast
datagrams as mandated in routing protocols [such as the neighbor
discovery datagram and routing updates in OSPF, the routing
updates in RIPV2 etc] and user data over this virtual topology.
This memo presents an approach for solving these problems.
1. Acronyms
Kathirvelu, et al. Expires January 2002 [Page 1]
INTERNET-DRAFT Link Broadcast & VR Discovery July 2001
ARP Address Resolution Protocol
CE Customer Edge router
LSP Label Switched Path
PNA Private Network Administrator
SLA Service Level Agreement
SP Service Provider
SPED Service Provider Edge Device
SPNA SP Network Administrator
VL Inter VR Virtual Link
VMA VPN Multicast Address
VPNID VPN Identifier
VR Virtual Router
VRC Virtual Router Console
2. Introduction
The two problems that need to be addressed are link level
broadcast and inter VR discovery over a virtual topology.
Broadly we can classify the solutions as static and dynamic. The
static approach calls for manually configuring the neighbor
address. This, while easy to articulate and effective for small
VPNs, is a configuration nightmare. Alternatively, this memo
describes an approach using an IP multicast infrastructure or ARP
servers for virtual routers to discover other virtual routers in a
given VPN and for supporting link level broadcast over a virtual
topology.
3. Static Approach
In this approach, we expect the user to configure a given VR's
neighbors in that VR. The exact mechanism is static ARP.
Basically, the user configures a static ARP entry for each
neighboring VR. The static ARP entry provides a mapping from the
neighboring VR's interface on the virtual link (VL) to the
backbone visible IP address of the neighbor's hosting PE. If this
methodology is used and the routing protocol(s) configured to run
over the VL require link broadcast, it has to be implemented using
non-native multicast forwarding paradigms; this is obviously less
than optimum from a network utilization standpoint.
4. Dynamic Approach
When the VPN is large with a large number of VRs associated with
it, a dynamic, automated method is preferable to static
configuration. This draft presents a IP multicast based approach
whereby dynamic ARP is used to discover the neighbor VR's PE
address and link broadcast is achieved using encapsulation of VPN
Kathirvelu, et al. Expires January 2002 [Page 2]
INTERNET-DRAFT Link Broadcast & VR Discovery July 2001
link broadcast packets in the multicast address assigned to the
VPN.
4.1. Using ARP for VR Discovery
In a physical LAN with a number of routers, when a data packet
needs to be forwarded to one of the other routers, an ARP request
is broadcast to the LAN. The router with the logical address
queried in the ARP request responds with an ARP response with its
MAC address. In identical fashion, the dynamic approach described
in this draft sends an ARP request to the multicast address
assigned to the VPN. The other VRs associated with this VPN
receive the ARP request and the appropriate VR responds with its
MAC address, i.e., its PE's backbone visible IP address. In order
to achieve this, we need to have a new hardware type field in the
ARP Req and Response. This enjoys the advantage that ARP is
implemented in almost all the SPEDs and CPEs and it is independent
of any routing protocols.
When we discuss the methods of carrying ARP, again it may depend
on the SP's network configuration. We discuss few methods here.
4.1.1. ARP over Multicast
If we assume that the SP's network supports multicast then each
VPN can subscribe to one multicast group as described in RFC 2917
and exchange the neighbor information.
4.2. Using Multicast For Link Broadcast
Some routing protocols, most notably IGPs, require link level
multicast facilities. For example, OSPF in broadcast mode uses
224.0.0.5 to discover other OSPF routers and to send route
updates, RIPv2 uses 224.0.0.9 to send route updates. If the
optimizations achieved with the use of these modes is desirable
over the VL, this approach calls for sending these routing
datagrams over the VPN's multicast address. This ensures that only
the VRs that participate in a given VPN receive these datagrams.
5. Intellectual Property Considerations
Lucent technologies may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or
become protected by one or more patents assigned to Lucent
Technologies. Lucent Technologies intends to disclose those
patents and license them on reasonable and non-discriminatory
terms.
Kathirvelu, et al. Expires January 2002 [Page 3]
INTERNET-DRAFT Link Broadcast & VR Discovery July 2001
6. References
[muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture",
RFC 2917 September 2000.
7. Authors' Addresses
Chandrasekar Kathirvelu
Lucent Technologies
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-7116
EMail: ck32@lucent.com
Karthik Muthukrishnan
Lucent Technologies
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-1368
EMail: mkarthik@lucent.com
Tom Walsh
Lucent Technologies
10 Lyberty Way
Westford, MA 01886
Phone: (978) 392-2311
EMail: tdwalsh@lucent.com
Fred Ammann
COMMCARE Telecommunications
Turmstrasse 8
CH-8952 Schlieren
Switzerland
Phone: +41 1 738 61 11
Email: fa@commcare.ch
Andrew Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Phone: (408) 383-7223
EMail: Andy.Malis@vivacenetworks.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Kathirvelu, et al. Expires January 2002 [Page 4]
INTERNET-DRAFT Link Broadcast & VR Discovery July 2001
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Kathirvelu, et al. Expires January 2002 [Page 5]