U.S. patent application number 14/299585 was filed with the patent office on 2014-09-25 for multicast-enabled address resolution protocol (me-arp).
The applicant listed for this patent is ROCKSTAR CONSORTIUM US LP. Invention is credited to Simon David Bryden, Geoffrey Mattson, Robert Pluim, Marcel Wiget.
Application Number | 20140286335 14/299585 |
Document ID | / |
Family ID | 36794414 |
Filed Date | 2014-09-25 |
United States Patent
Application |
20140286335 |
Kind Code |
A1 |
Wiget; Marcel ; et
al. |
September 25, 2014 |
Multicast-Enabled Address Resolution Protocol (ME-ARP)
Abstract
A Multicast-Enabled Address Resolution Protocol (ME-ARP) is
disclosed. This ME-ARP allows the building of independent IP based
Virtual Private LAN segments (VPLS) over a multicast enabled IP
backbone using stateless tunnels and optimal VPLS traffic
forwarding. Each VPLS has an associated IP subnet which is
completely independent from other VPLS or the underlying IP
backbone itself. Each Customer Premises Equipment (CPE) device
needs only to be configured with a VPLS identifier and its serving
IP subnet per VPLS designated interface.
Inventors: |
Wiget; Marcel; (Antibes,
FR) ; Pluim; Robert; (Golfe Juan, FR) ;
Bryden; Simon David; (La Roquette sur Siague, FR) ;
Mattson; Geoffrey; (Antibes, FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
ROCKSTAR CONSORTIUM US LP |
Plano |
TX |
US |
|
|
Family ID: |
36794414 |
Appl. No.: |
14/299585 |
Filed: |
June 9, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13222900 |
Aug 31, 2011 |
8782288 |
|
|
14299585 |
|
|
|
|
12661895 |
Mar 24, 2010 |
8024474 |
|
|
13222900 |
|
|
|
|
10444397 |
May 23, 2003 |
7702808 |
|
|
12661895 |
|
|
|
|
09398370 |
Sep 17, 1999 |
6640251 |
|
|
10444397 |
|
|
|
|
60124066 |
Mar 12, 1999 |
|
|
|
Current U.S.
Class: |
370/390 |
Current CPC
Class: |
H04L 29/12783 20130101;
H04L 12/4645 20130101; H04L 12/185 20130101; H04L 12/4641 20130101;
H04L 61/35 20130101; H04L 29/12009 20130101; H04L 12/1886 20130101;
H04L 61/10 20130101; H04L 29/12018 20130101 |
Class at
Publication: |
370/390 |
International
Class: |
H04L 12/46 20060101
H04L012/46; H04L 12/18 20060101 H04L012/18 |
Claims
1-10. (canceled)
11. A method of forwarding traffic in a virtual private local area
network service (VPLS), the method comprising: assigning to a
virtual private local area network providing a VPLS a virtual
private network internet protocol (VPN-IP) multicast address that
is unique to the VPLS; joining an interface of customer premises
equipment (CPE) to a multicast group of a virtual private network
(VPN); encapsulating traffic with the VPN-IP multicast address; and
forwarding the encapsulated traffic based on the VPN-IP multicast
address.
12. The method according to claim 11, wherein the joining the
interface of the CPE to the multicast group comprises using
Internet Group Management Protocol (IGMP).
13. The method according to claim 12, wherein the joining the
interface of the CPE using IGMP comprises joining the interface of
the CPE to the multicast group by using the IGMP with a
multicast-capable routing protocol.
14. The method according to claim 13, wherein the multicast-capable
routing protocol comprises a distance vector multicast routing
protocol (DVMRP).
15. The method according to claim 13, wherein the multicast-capable
routing protocol comprises a multicast open shortest path first
(MOSPF) protocol.
16. The method according to claim 13, wherein the multicast-capable
routing protocol comprises a protocol independent multicast (PIM)
protocol.
17. The method according to claim 11, further comprising keeping
track of the joined interface of the CPE using the VPN-IP multicast
address.
18. The method according to claim 11, further comprising
configuring the CPE with configuration information comprising a
virtual private network multicast identifier associated with the
internet protocol address of the VPLS.
19. The method according to claim 11, further comprising
configuring the CPE with configuration information comprising an
internet protocol network mask.
20. The method according to claim 11, further comprising
configuring the CPE with configuration information comprising a
tunnel internet protocol address.
21. The method according to claim 11, further comprising
configuring the CPE with configuration information comprising a
media-access-control (MAC) address calculation algorithm.
22. The method according to claim 11, further comprising:
encapsulating an address resolution protocol (ARP) request matching
a customer's IP subnet; and forwarding the encapsulated ARP request
to the VPN-IP multicast address of the VPLS.
23. The method according to claim 22, further comprising: receiving
a forwarded encapsulated ARP request; decapsulating the received
encapsulated ARP request; and replacing a source hardware address
of the decapsulated ARP request with a calculated address
containing a tunnel source internet protocol address, a virtual
private network identifier and a customer premises equipment
identifier.
24. The method according to claim 11, further comprising creating
an entry in an address resolution protocol table (ARP table) for
caching, the ARP table being associated with the CPE.
25. The method according to claim 11, wherein the traffic is
encapsulated in an encapsulation-without-security format.
26. The method according to claim 11, wherein the traffic is
encapsulated in an encapsulation-with-authentication-only
format.
27. The method according to claim 11, wherein the traffic is
encapsulated in an encapsulation-with-encryption format.
28. The method according to claim 11, wherein the interface of the
CPE is an unnumbered VPN-IP interface.
Description
FIELD OF THE INVENTION
[0001] This invention relates to a scalable and server-less
solution to build Virtual Private LAN Segments (VPLS) based on a
multicast enabled IP backbone and more particularly to a
Multicast-Enabled Address Resolution Protocol (ME-ARP).
BACKGROUND OF THE INVENTION
[0002] The popularity of the Internet is driving requirements for
secure and segregated IP interconnection of remote sites. One
solution is to use the underlying network supporting virtual
connections i.e. 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. Any other
known layer 2 VPN (Virtual Private Network) solution used in the
prior art requires a centralized server where all CPE (Customer
Premises Equipment) and IP devices have to be statically or
dynamically registered, like LANE (Local-Area-Network Emulation);
NHRP (Next-Hop-Routing-Protocol) or Classical IP.
[0003] A need exists for building IP based virtual private LAN
segments (sharing one IP subnet) with complete transparency
regarding TCP/IP, site-independent CPE configuration and with
dynamic stateless tunnels to optimally forward unicast traffic
based on routing and policy per VPLS. VPLS with different
Identifiers can use overlapping IP subnets. With the method of the
present invention, a centralized server or a list of CPE devices
configured for each VPN is not required.
SUMMARY OF THE INVENTION
[0004] One aspect of the present invention is to provide a scalable
and server-less solution to build Virtual Private LAN Segments
(VPLS).
[0005] Another aspect of the present invention is to provide a
Multicast-Enabled Address Resolution Protocol (ME-ARP). This
invention allows the building of independent IP based Virtual
Private LAN segments (VPLS) over a multicast enabled IP backbone
using stateless tunnels and optimal VPLS traffic forwarding. Each
VPLS has an associated IP subnet which is independent from other
VPLS or the underlying IP backbone itself. Each Customer Premises
Equipment (CPE) device needs only to be configured with a VPLS
identifier and its serving IP subnet per VPLS designated interface.
In addition, each end station connected to a Physical LAN Segment
(PLS) does not need to be modified in order to be a member of the
VPLS. No other configuration parameters e.g. list of CPE devices,
their logical or physical locations nor their IP addresses are
required. The unique invention is ME-ARP (Multicast Enabled Address
Resolution Protocol) including the creation of constructed lower
layer address based on VPN (Virtual Private Network) Id and tunnel
endpoint. Advantages provided by the method of the present
invention include:
[0006] a) separation of customer IP address space from either the
service provider or another customer determined by policy not to be
in the same virtual private network (VPN);
[0007] b) capability for a remote site to belong to one or more VPN
as long as the VPN policy allows. To provide support for IPv4 based
applications at this point;
[0008] c) transparent or Routed VPN's (by use of external routers)
can be constructed independently or combined with this
architecture;
[0009] d) due to the use of an underlying IP multicast network to
forward VPN broadcast traffic in this solution, there is no need to
provide address or broadcast servers; and
[0010] c) VPN traffic forwarding is achieved via stateless and
optionally secured tunnels which are optimally routed using the
underlying IP network backbone routing architecture.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1a is a block diagram illustrating a physical view of a
Virtual Private LAN Segment (VPLS) network for use with the present
invention;
[0012] FIG. 1b is a diagram illustrating a logical view of the
network of FIG. 1a or as would be seen from the customer's
perspective;
[0013] FIG. 2a illustrates a packet format corresponding to an
IPsec Authentication Header (AH) encapsulation with
authentication;
[0014] FIG. 2b illustrates a packet format corresponding to an
IPsec Encapsulating Security Payload (ESP) with authentication
privacy;
[0015] FIG. 3 illustrates a standard ARP packet format on
Ethernet;
[0016] FIG. 4 is a block diagram of a IP Backbone network for
illustrating the ME-ARP request/reply packet flow according to the
present invention;
[0017] FIG. 5 is a block diagram illustrating the transfer of
ME-ARP packet information between a first and second end station
according to the method of the present invention; and
[0018] FIG. 6 is a table illustrating the content of the ARP tables
at various point during the transfer of ME-ARP packet
information.
[0019] Similar references are used in different figures to denote
similar components.
[0020] In order to facilitate the description of the invention, the
following abbreviations have been used. The terminology used in
this document is based on the definitions proposed by the Internet
Engineers Task Force (IETF).
[0021] CBT Core Based Tree Multicast Routing Protocol
[0022] CPE Customer Premises Equipment
[0023] DVMRP Distance Vector Multicasting Routing Protocol
[0024] GRE Generic Routing Encapsulation
[0025] IGMP Internet Group Management Protocol
[0026] LAN Local Area Network
[0027] MOSPF Multicast extensions for Open Shortest Path First
[0028] PA Provider Address
[0029] PIM Protocol Independent Multicast
[0030] PLS Physical LAN Segment
[0031] VPN Virtual Private Network
[0032] VPLS Virtual Private LAN
[0033] UVIP Unnumbered VPN Internet Protocol
[0034] The term "Client Address" (CA) space or network ranges is
used to describe the IP address space used by each VPN
customer.
[0035] The term "Customer Premises Equipment" (CPE) defines an edge
device (e.g., router, etc.), fully managed by the provider,
connecting a customers PLS to its VPN.
[0036] The term "Provider Address" (PA) space or network ranges is
used to describe the provider allocated IP addresses in his IP
backbone. (e.g., Tunnel endpoints have an address assigned out of
the PA range).
[0037] The term "Physical LAN Segment" (PLS) is used in this
document to describe a broadcast domain, like a shared or switched
ethernet segment, connecting hosts, servers and routers at each
site. Without the use of a VPN technology, the scope of these PLS
is limited per site.
[0038] A Virtual Private LAN Segment (VPLS) is the emulation of a
LAN segment using Internet facilities. A VPLS can be used to
provide what is sometimes known as a transparent LAN service, which
can be used to interconnect multiple CPE nodes. It can be seen as a
pure layer 2 bridged VPN solution.
[0039] 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.
[0040] The term "Unnumbered VPN IP" (UVIP) interface is used in
VPLS to describe the tunnel endpoint connecting a PLS on a first
site with all other PLS per VPN. In the scope of the customer's
PLS, this interface doesn't need to have an IP address assigned to
forward traffic (VPLS is a layer 2 VPN solution). The tunnel
endpoint itself must have an IP address assigned, out of the
providers address space.
DETAILED DESCRIPTION OF THE INVENTION
[0041] In order to take advantage of all the features of the
present invention, it is assumed that the providers of IP backbone
services are IP multicast capable. Similarly, it is assumed that
CPE devices are able to join a multicast group using IGMP. It is
not a requirement that all routers in the backbone have multicast
capabilities. It is possible to interconnect the CPE 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 unicast traffic.
[0042] Referring now to FIG. 1a, we have shown the physical view or
service provider's view of a Virtual Private LAN Segment (VPLS).
The IP backbone 10 and CPE devices 11, 12, 13 and 14 are managed
and typically owned by the service provider. CPE devices 11-14 are
typically comprised of routers, whereas each PLS is typically
comprised of several IP capable devices such as end stations (ES1,
ES2, etc.)
[0043] FIG. 1b is a diagram illustrating a logical view of the
network of FIG. 1a or as would be seen from the customer's
perspective. Whereas in FIG. 1a the CPE devices are visible from
the provider's perspective, LAN segments are transparent to the
customers as illustrated in FIG. 1b. Similarly, CPE devices which
are seen by the service provider are invisible to the customer.
[0044] Stateless tunnels or links are used in CPE (Customer
Premises Equipment) between connected sites. The remote tunnel
endpoint address information is directly mapped into the link layer
address. ME-ARP is used for IP address resolution inside a VPLS. As
a result, VPN connected IP devices will keep all relevant
information about the destination tunnel endpoint and VPN
membership in their own address resolution (ARP) table. Special
unnumbered IP LAN interfaces will generate the link layer address
based on a configured VPN identifier and dynamically learned tunnel
endpoints (via ME-ARP).
[0045] Again, as illustrated in FIGS. 1a and 1b, a VPLS can span
two or more sites, with all IP devices sharing 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
CPE devices, managed by the provider, are transparent to the
customer. This type of layer 2 VPN solution possesses the following
benefits for the customer:
[0046] Transparency. No IP addresses must be given to the
provider;
[0047] Flat IP subnet. The VPN can be seen as a VPLS, with
transparent support for broadcast protocols like DHCP/BOOTP
(Dynamic Host Configuration Protocol/BOOTstrap Protocol),
Netbios/IP etc; and
[0048] 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.
[0049] Each VPLS has a provider wide unique IP multicast address
assigned. A UVIP interface of a CPE device, shown at reference
numerals 15, 16, 17 and 18, configured for a particular VPLS, will
join the VPN's multicast group by using IGMP. All broadcast traffic
is then encapsulated and forwarded to the VPN's IP multicast
address. There is therefore no need for a central database to keep
track of all UVIP interfaces joining a customer's VPN. This is
handled by the IP multicast membership.
[0050] In order to forward IP unicast traffic, an enhanced version
of proxy ARP is used. The differences from the standard proxy ARP
are:
[0051] a) all ARP requests matching the customers IP subnet are
encapsulated and forwarded to all VPN members by sending them to
the VPN's IP multicast address. Note: The CPE device cannot
determine, if an IP device is connected to the local physical
segment or not.
[0052] b) a forwarded ARP request, after decapsulation, will
replace the source hardware address (MAC, Media-Access-Control or
physical Address) not with the routers own interface MAC address,
but by a calculated address containing the tunnel source IP
address, an interface unique VPN Id (e.g. VPN instance Id) and a
CPE Id (to avoid loops in case of CPE redundancy).
[0053] The result of this "multicast enhanced ARP" (ME-ARP) process
is that the customers IP devices will keep all relevant information
about the destination tunnel endpoint and VPN membership in their
ARP table. There is no overhead involved, if compared to a real
physical IP subnet.
Unique VPN Identifier
[0054] Each VPN has a unique identifier assigned. For VPLS built of
more than two physically separated sites this is a valid IP
multicast address. As each VPN has a unique IP multicast Id
assigned, IGMP and any multicast capable routing protocol (DVMRP
(Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open
Shortest Path First), PIM (Protocol Independent Multicast), are
used by a configured IP VPN interface connecting a Physical Segment
to join the VPNs multicast group.
[0055] Individual CPE devices are configured as follows:
[0056] Based on the VPLS membership using IP multicast, there is no
need for a central VPN membership database or protocol to
distribute this information. It is enough to configure a new VPN
member (physical segment) in the connecting CPE device. The
following minimal information is configured per UVIP (Unnumbered
VPN IP) interface:
[0057] a) VPN IP multicast Id;
[0058] b) IP Network/Mask. Assigned by the customer from the Client
Address (CA) space. This information is used to determine the
correct VPN, based on either source or destination IP address. This
is important to support multi-netting on the same physical
interface with many VPNs;
[0059] c) Tunnel IP address. This address from the Provider Address
(PA) space is used to forward VPN traffic over the IP backbone to
the correct tunnel end-point (bound to a VPN interface). The VPN
identifier in each encapsulated packet can be used to identify the
correct logical UVIP interface inside the CPE device;
[0060] d) MAC calculation algorithm. This optional, but
recommended, configuration parameter allows the support of
different MAC address calculation to prevent possible
duplicates.
[0061] Referring now to FIGS. 2a and 2b, in the preferred
embodiment of the invention, depending on the security
requirements, three different encapsulation formats can be used
without security, with authentication only or with encryption. The
encapsulated methods are based on IPsec tunnel mode [RFC2401 . . .
RFC2406]. The IP2 header contains the IP source and destination
address from the providers address space (tunnel endpoint IP
addresses or address as destination address). The IP1 header is the
original IP packet header.
[0062] In FIG. 2a, we have shown an IPsec AH encapsulation (with
authentication). FIG. 2b shows an IPsec ESP encapsulation (with
auth. privacy).
[0063] IP multicast and broadcast packets are encapsulated and
tagged with the VPN multicast Id in the SPI field of the IPsec
AH/ESP header and forwarded to the VPN IP multicast address (equal
to VPN multicast Id). All active members of the VPNs multicast
group receive the encapsulated packet and forward it to the
appropriate VPN's UVIP interface.
[0064] Referring now to FIGS. 3, we have shown an ARP Request/Reply
packet including Ethernet transmission layer. In FIG. 4, we have
shown a block diagram of an IP Backbone network and in FIG. 5, we
have shown a block diagram illustrating the transfer of packet
information between a first and second end station,
respectively.
[0065] In operation, with reference to FIGS. 3, 4, 5 and 6, end
station A wants to send an IP packet to end station B on the same
logical subnet but connected to different gateways. It is assumed,
that the ARP tables 80 and 81 from both end stations are empty.
Therefore end station A sends an ARP request 50 to the ethernet
broadcast address 51. CPE A, configured with the proper VPN
information, checks the source IP address 52 of the ARP request
packet 50 against its UVIP interfaces configured on the physical
interface. In case of a match, it encapsulates the whole,
unmodified, ARP request 50 into an IPsec packet 55 including the
VPN identifier 56(equals assigned IP multicast address) and
forwards packet 55 to the VPN's multicast address 57 using the
configured local IP tunnel-endpoint 58 as source address. CPE A
also adds a local ARP entry for end station A in its ARP table 72
for that UVIP interface. (CPE A will forward the ARP request, even
if end station B is connected to the same physical network).
[0066] All CPEs joining the VPN will receive this encapsulated ARP
request, unpack it, and forward out the local UVIP interface with
the following modification to the original ARP request 55:
[0067] replace the original HW source address 59 (MAC address from
end station A) with a calculated MAC address containing the tunnel
end-point IP address from CPE A(=source address from the received
IPsec packet) and an optional interface unique VPN Id.
[0068] This new HW source address 60 is replaced in the ethernet
header as well as in the ARP packet 61.
[0069] CPE B might add an entry to its ARP table 83 for caching.
End station B receives the ARP request 62 and respond to it with a
normal ARP reply containing its physical HW MAC address 64 as
source in the ethernet header and in the ARP reply packet 65. An
ARP entry for end station A with the source MAC address from the
ARP request is added on end station B. The ARP table 81 of end
station B now contains an entry for end station A with a
constructed MAC address containing the tunnel-endpoint IP address
and VPN Id. CPE B, configured to listen for constructed MAC
addresses, identifies the ARP reply 63 from end station B by
checking the source MAC address 64 as well as the source IP address
66 (part of VPN's IP network), encapsulate and forwards the ARP
reply 67 directly to the addressed tunnel endpoint (extract tunnel
endpoint IP address from destination MAC address).
[0070] CPE A decapsulates the ARP reply packet 67, checks the
destination or target IP address 68 and replaces the destination or
target MAC address 69 with the address found in its local ARP
cache, and sends the constructed ARP reply 70 out to end station A
on the local attached physical LAN segment. In addition, the source
MAC address 71(in the Ethernet header and ARP packet) is replaced
with a constructed MAC address 72 containing an optional interface
locally unique VPN Id and the IP address of CPE B (where the ARP
reply came from).
[0071] If the ARP table 82 from CPE A does not contain an entry for
end station A, then CPE A will have to send an ARP request out for
end station A with end station B's IP address before forwarding the
ARP reply packet out to end station A.
[0072] Finally, end station A receives the ARP reply packet 70 and
builds an entry in its ARP table 80 with an entry for end station B
and the MAC address containing the remote tunnel endpoint IP
address and VPN Id.
* * * * *