idnits 2.17.1
draft-ietf-l3vpn-end-system-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 11 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 2, 2014) is 3494 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Unknown state RFC: RFC 1027
** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012)
-- Obsolete informational reference (is this intentional?): RFC 5575
(Obsoleted by RFC 8955)
== Outdated reference: A later version (-11) exists of
draft-ietf-mpls-in-udp-05
== Outdated reference: A later version (-11) exists of
draft-ietf-l2vpn-evpn-08
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Marques
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track L. Fang
5 Expires: April 5, 2015 Microsoft
6 N. Sheth
7 Juniper Networks
8 M. Napierala
9 AT&T Labs
10 N. Bitar
11 Verizon
12 October 2, 2014
14 BGP-signaled end-system IP/VPNs.
15 draft-ietf-l3vpn-end-system-04
17 Abstract
19 This document describes a solution in which the control plane
20 protocol specified in BGP/MPLS IP VPNs is used to provide a Virtual
21 Network service to end-systems. These end-systems may be used to
22 provide network services or may directly host end-to-end
23 applications.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on April 5, 2015.
42 Copyright Notice
44 Copyright (c) 2014 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Applicability of BGP IP VPNs . . . . . . . . . . . . . . . . 4
63 4. Virtual network end-points . . . . . . . . . . . . . . . . . 7
64 5. VPN Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 9
65 6. XMPP signaling protocol . . . . . . . . . . . . . . . . . . . 11
66 7. End-System Route Server behavior . . . . . . . . . . . . . . 17
67 8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 18
68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
70 11. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . 22
71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
73 13.1. Normative References . . . . . . . . . . . . . . . . . . 24
74 13.2. Informational References . . . . . . . . . . . . . . . . 24
75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
77 1. Introduction
79 This document describes the requirements for a network virtualization
80 solution that provides an IP service to end-system virtual
81 interfaces. It then discusses how the BGP IP VPNs [RFC4364] control
82 plane can be used to provide a solution that meets these
83 requirements. Subsequent sections provide a detailed discussion of
84 the control and forwarding plane components.
86 In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider
87 Edge (PE) device which provides both the control plane and VPN
88 encapsulation functions required to implement a Virtual Network
89 service. This document decouples the control plane and forwarding
90 functionality of the PE device in order to enable the forwarding
91 functionality to be implemented in multiple devices. For instance,
92 the forwarding function can be implemented directly on the operating
93 system of application servers or network appliances.
95 1.1. Terminology
97 This document makes use of the following terms:
99 End-System: A compute node which primary function is to run
100 applications. It is assumed that end-systems support multiple
101 application instances (e.g. virtual-machines), each with its
102 independent network configuration.
104 End-System Route Server: A software application that implements the
105 control plane functionality of a BGP IP VPN PE device and a XMPP
106 server that interacts with VPN Forwarders.
108 Virtual Interface: An interface in an end-system that is used by a
109 virtual machine or by applications. It performs the role of a CE
110 interface in a BGP IP VPN network.
112 VPN Forwarder: The forwarding component of a BGP IP VPN PE device.
113 This functionality may be co-located with the virtual interface or
114 implemented by an external device.
116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
118 document are to be interpreted as described in RFC 2119 [RFC2119].
120 2. Requirements
122 Network Virtualization is used in both service provider as well as
123 enterprise networks to support multi-tenancy and network-based access
124 control. It may also be used to facilitate application instance
125 mobility.
127 Multi-tenancy allows a physical network to provide services to
128 multiple "customers" or "tenants", whether these are external
129 entities in the case of a Service Provider providing managed VPN
130 services or internal departments sharing an IT facility. Multi-
131 tenancy requires isolation of traffic and routing information between
132 tenants.
134 Within a tenant, it is often required to create multiple distinct
135 virtual networks, in order to be able to provide network-based access
136 control. In this service model, each virtual network behaves as a
137 "Closed User Group" (CUG) of virtual interfaces that are allowed to
138 exchange traffic freely, while traffic between virtual networks is
139 subject to access controls. This scenario can be found in both
140 enterprise campus networks, branch offices and data-centers.
142 It is often the case when network access control is used, that the
143 traffic patterns are such that there is significantly more traffic
144 crossing a CUG boundary than staying within such boundary. As an
145 example, in campus networks it is common to segregate users into CUGs
146 based on some classification such as the user's department. Campus
147 networks often see traffic patterns in which almost all the traffic
148 flows northbound to the data-center or internet boundaries. Similar
149 traffic patterns can be found in multi-tier applications in IT data-
150 centers.
152 Virtual interfaces are often configured to expect the concept of IP
153 subnet to match its closed user group. A network virtualization
154 solution should be able to provide this concept of IP subnet
155 regardless of whether the underlying implementation uses a multi-
156 access network or not.
158 Virtual interfaces should be able to directly access multiple closed
159 user groups without needing to traverse a gateway. Network access
160 policy should allow this access whether the source and destination
161 CUGs for a particular traffic flow belong to the same tenant or
162 different tenants. It is often the case that infrastructure services
163 are provided to multiple tenants. One such example is voice-over-IP
164 gateway services for branch offices.
166 Independently, but often associated with the previous two functions,
167 IP mobility is another network function that can be implemented using
168 network virtualization. By abstracting the externally visible
169 network address from the underlying infrastructure address, mobility
170 can be implemented without having to recur to home agents or large L2
171 broadcast domains.
173 IP Mobility requires the ability to "move" a virtual interface
174 without disrupting its TCP (or UDP) transport sessions. This
175 requires a mechanism that can efficiently communicate the mappings
176 between logical and physical addressing.
178 IP Mobility can be a result of devices physically moving (e.g., a
179 WiFi enabled laptop) or workload being diverted between physical
180 systems such as network appliances or application servers.
182 3. Applicability of BGP IP VPNs
184 BGP IP VPNs [RFC4364] is the industry de-facto standard for providing
185 "closed user group" functionality in WAN environments. It is used by
186 service providers in environments where several millions of routes
187 are present. It supports both isolated VPNs as well as overlapping
188 VPNs (often referred to as "extranets").
190 The BGP IP VPN control plane has been designed to be able to
191 distribute the mapping between virtual address and location (next-
192 hop) to the subset of network nodes for which this information is
193 relevant, whenever that mapping changes. This provides an efficient
194 mechanism to address IP mobility requirements as compared to methods
195 that depend on a (cached) mapping request from the end-systems.
197 In its traditional usage in Service Provider networks, BGP IP VPN
198 functionality is implemented in a Provider Edge (PE) device that
199 combines both BGP signaling as well as VRF-based forwarding
200 functions. In practice, most PE devices in current use are multi-
201 component systems with the signaling and forwarding functionality
202 actually implemented in different processors attached to an internal
203 network.
205 This document assumes a similar separation of functionality in which
206 software appliances, the End-System Route Servers, implement the
207 control plane functionality of a PE device and a VPN Forwarder
208 implements the forwarding function usually found in a PE device
209 "line-card". The VPN Forwarder functionality may be co-located with
210 the end-system (e.g., implemented in the hypervisor switch or host OS
211 network drivers) or it may be external. For instance, residing in a
212 data-center switch or specialized appliance.
214 Operationally, BGP IP VPN technology has several important
215 characteristics:
217 It has a high-level of aggregation between customer interfaces and
218 managed entities (Provider Edge devices).
220 It defines VPNs as policies, allowing an interface to directly
221 exchange traffic with multiple VPNs and allowing for the topology
222 of the virtual network to be modified by modifying the policy
223 configuration.
225 It scales horizontally in terms of event propagation. By
226 increasing the number of signaling devices implementing the PE
227 control plane, it is possible to decrease the load on each
228 signaling device when it comes to propagating events that
229 originate in a specific location and must be propagated across the
230 network.
232 The last point is particularly relevant to the convergence
233 characteristics required for large scale deployments. BGP's
234 hierarchical route distribution capabilities allow a deployment to
235 divide the workload by increasing the number of End-System Route
236 Servers.
238 As an example consider a topology in which 100 End-System Route
239 Servers are deployed in a network each serving a subset of the VPN
240 forwarding elements. The Route Servers inter-connect to two top-
241 level BGP Route Reflectors [RFC4456].
243 If an event (i.e. a VPN route change) needs to be propagated from a
244 specific end-system to 10,000 clients randomly distributed across the
245 network, each of the End-System Route Servers must generate 100
246 updates to its respective downstream clients.
248 By modifying this topology such that another 100 End-System Route
249 Servers are added, then each Route Server is now responsible to
250 generate 50 client updates. This example illustrates the linear
251 scaling properties of BGP: doubling the number of Route Servers (i.e.
252 the processing capacity) reduces in half the number of updates
253 generated by each (i.e. load at each processing node).
255 The same horizontal scaling techniques can be applied to the Route
256 Reflector layer in the example above by subsetting the VPN Route
257 space according to some pre-defined criteria (for instance VPN route
258 target) and using a pair of Route Reflectors per subset.
260 In the previous example we assumed a dense membership in which all
261 Route Servers have local clients that are interested in a particular
262 event. BGP also optimizes the route distribution for sparse events.
263 The Route Target Constraint [RFC4684] extension, builds an optimal
264 distribution tree for message propagation based on VPN membership.
265 It ensures that only the PEs with local receivers for a particular
266 event do receive it also decreasing the total load on the upstream
267 BGP speaker.
269 In the WAN environment, BGP IP VPN control plane scaling is focused
270 not primarily on route convergence times but on memory footprint of
271 embedded devices. While memory footprint does not have a similar
272 linear scaling behavior, memory technology available to software
273 appliances is often at 10x the scale of what is commonly found in WAN
274 environments.
276 The functionality present in the BGP IP VPN control plane addresses
277 the requirements specified in the previous section. Specifically, it
278 supports multiple potentially overlapping "groups", regular or "hub
279 and spoke" topologies and the scaling characteristics necessary.
281 The BGP IP VPN control plane supports not only the definition of
282 "closed user-groups" (VPNs in its terminology) but also the
283 propagation of inter-VPN traffic policies [RFC5575].
285 Note that the signaling protocol itself is rather agnostic of the
286 encapsulation used on the wire as long as this encapsulation has the
287 ability to carry a 20 bit label.
289 Several network environments use a network infrastructure that is
290 only capable of providing an IP unicast service. In order to support
291 them, implementations of this document should support the MPLS in GRE
292 [RFC4023] encapsulation. Other encapsulations are possible,
293 including UDP based encapsulations [I-D.ietf-mpls-in-udp].
295 4. Virtual network end-points
297 This document assumes that end-systems support one or more virtual
298 network interfaces in addition to a physical interface that is
299 associated with the underlying network infrastructure. Virtual
300 network interfaces can be associated with a restricted list of
301 applications via OS-dependent mechanisms, a Virtual Machine (VM), or
302 they can be used to provide network connectivity to all user
303 applications in the same way that a "VPN tunnel" interface is used to
304 provide access between an end-system (e.g., a laptop) and a remote
305 corporate network.
307 From an IP address assignment point of view, a virtual network
308 interface is addressed out of the virtual IP topology and associated
309 with a "closed user group" or VPN, while the physical interface of
310 the machine is addressed in the network infrastructure topology.
312 A virtual network interface is connected to a VPN Forwarder. This
313 VPN Forwarder MAY be co-located in the end-system or external.
315 Both static and dynamic IP address allocation can be supported. The
316 later assumes that the VPN Forwarder implements a DHCP relay or DHCP
317 proxy functionality.
319 Traffic that ingresses or egresses through a virtual network
320 interface is routed at the VPN Forwarder which acts as the first-hop
321 router (in the virtual topology). The IP configuration on the client
322 side of this virtual network interface (e.g., in the guest OS) can
323 follow one of two models:
325 point-to-point interface model.
327 multipoint interface model.
329 In a point-to-point interface model, the VPN client routing table
330 (e.g., on the guest OS) contains the following routing entries: a
331 host route to the local IP address, a host route to the first-hop
332 router via the virtual interface and a default route to the first-hop
333 router. This is the model typically used in "VPN tunnel"
334 configurations or other access technologies such as cable deployments
335 or DSL. When this model is used, the first-hop router IP address is
336 a link-local address that is the same on all first-hop routers across
337 a specific deployment. This first-hop IP address should not change
338 when a virtual interface moves between different machines.
340 In a multi-point interface model, the VPN client routing table (e.g.,
341 on the guest OS) contains the following routing entries: a host route
342 to the local IP address, a subnet route to the local interface and
343 optionally a default route to a specific router address within that
344 subnet. In this model, the VPN client IP stack will issue address
345 resolution requests for any IP addresses it considers to be directly
346 attached to the subnet. The VPN Forwarder shall answer all address
347 resolution requests via Proxy ARP [RFC1027].The same technique is
348 applicable when Neighbor Discovery is used to resolve IPv6 addresses.
349 Address resolution request should be answered using a virtual MAC
350 address which SHOULD be the same across all VPN Forwarders in a
351 specific deployment. This virtual MAC address SHALL default to the
352 VRRP [RFC5798] virtual router MAC address for Virtual Router
353 Identifier (VRID) 1.
355 When the virtual topology first-hop router resides on the same
356 physical machine, the host OS is responsible to map the virtual
357 interface with a VPN specific routing table (without taking L2
358 addresses into consideration). In this case the mac-addresses known
359 to the guest OS are not used on the wire.
361 When the virtual topology first-hop router resides in an external
362 system (e.g., the first hop-switch) the virtual interface shall be
363 identified by the combination of the mac-address assigned to physical
364 interface of the end-system and a 802.1Q VLAN tag. The first-hop
365 switch should use a virtual router MAC address to answer any address
366 resolution queries.
368 Whenever an external VPN Forwarder is used and resiliency is desired,
369 the external VPN Forwarder should be redundant. It is desirable to
370 use VRRP as a mechanism to control the flow of traffic between the
371 end-system and the external VPN Forwarder. VRRP already defines the
372 necessary procedures to elect a single forwarder for a LAN.
374 This specification uses the VRRP virtual router MAC address as the
375 default L2 address for the VPN Forwarder as a client virtual
376 interface may move between locations where redundancy may not be
377 present.
379 While the VRRP Virtual Router MAC will be used to answer any address
380 resolution request made by the virtual interface client (e.g., the
381 guest VM) this does not imply that a single default router is elected
382 per virtual IP subnet. The ingress VPN Forwarder will perform an IP
383 forwarding decision based on the destination IP address of the
384 (payload) traffic.
386 VRRP router election is only relevant in selecting the VPN Forwarder
387 associated with a specific machine, when external forwarders are in
388 use.
390 5. VPN Forwarder
392 In this solution, the Host OS/Hypervisor in the end-system must
393 participate in the virtual network service. Given an end-system with
394 multiple virtual interfaces, these virtual interfaces must be mapped
395 onto the network by the guest OS such that applications on one
396 virtual interface cannot send traffic to networks they are not
397 authorized to communicate with or using source addresses not assigned
398 to the virtual interface.
400 When VPN forwarder functionality is implemented by the Host OS/
401 Hypervisor, intermediate systems in the network do not require any
402 knowledge of the virtual network topology. This can simplify the
403 design and operation of the physical network.
405 When it is not possible or desirable to add the VPN forwarding
406 functionality to the end-system, it may be implemented by an external
407 system, typically located as close as possible to the end-system
408 itself.
410 Both models, co-located and external VPN Forwarder can co-exist in a
411 deployment.
413 In order to implement the BGP IP VPN Forwarder functionality a device
414 MUST implement the following functionality:
416 Support for multiple "Virtual Routing and Forwarding" (VRF)
417 tables;
419 VRF route entries map prefixes in the virtual network topology
420 to a next-hop containing a infrastructure IP address and a
421 20-bit label allocated by the destination Forwarder. The VRF
422 table lookup follows the standard IP lookup (best-match)
423 algorithm.
425 Associate an end-system virtual interface with a specific VRF
426 table;
427 When the the Forwarder is co-located with the end-system, this
428 association is implemented by an internal mechanism. When the
429 Forwarder is external the association is performed using the
430 mac-address of the end-system and a IEEE 802.1Q tag that
431 identifies the virtual interface within the end-system.
433 Encapsulate outgoing traffic (end-system to network) according to
434 the result of the VRF lookup;
436 Associate incoming packets (network to end-system) to a VRF
437 according to the 20-bit label contained in the packet;
439 The VPN Forwarder MAY support the ability to associate multiple
440 virtual interfaces with the same VRF. When that is the case, locally
441 originated routes, that is IP routes to the local virtual interfaces
442 SHALL NOT be used to forward outbound traffic (from the virtual
443 interfaces to the outside) unless a route advertisement has been
444 received that matches that specific IP prefix and next-hop
445 information.
447 As an example, if a given VRF contains two virtual interfaces,
448 "veth0" and "veth1", with the addresses 10.0.1.1/32 and 10.0.1.2/32
449 respectively, the initial forwarding state must be initialized such
450 that traffic from either of these interfaces does not match the
451 other's routing table entry. It may for instance match a default
452 route advertised by a remote system. Traffic received from other VPN
453 Forwarders, however, must be delivered to the correct local
454 interface. If at a subsequent stage a route is received from the
455 Route Server such that 10.0.1.2/32 has a next-hop with the IP address
456 of the local host and the correct label, the system may subsequently
457 install a local routing table entry that delivers traffic directly to
458 the "veth1" interface. This means that forwarding table entries
459 apply to downstream only by default. This capability can be used to
460 implement a hub-and-spoke topology, if required.
462 The 20-bit label which is associated with a virtual-interface is of
463 local significance only and SHOULD be allocated by the VPN Forwarder.
465 When an external VPN Forwarder is used the end-system MUST associate
466 each virtual interface with a VLAN [IEEE.802-1Q] that is unique on
467 the end-system. The switching infrastructure MUST be configured such
468 that multi-destination frames sourced from an end-system are only
469 delivered to VPN Forwarders used by this end-system and not to other
470 end-systems.
472 6. XMPP signaling protocol
474 End-System Route Servers must be aware of VPN membership on each
475 Forwarder as well as what IP addresses are currently associated with
476 each virtual interface.
478 VPN Forwarders must receive VPN route information from which to
479 populate their forwarding tables. External VPN Forwarders also need
480 to receive the virtual interface and IP address events from the end-
481 system for which they are VPN forwarders. In this case the end-
482 system assigns an 802.1Q VLAN tag to each virtual interface and
483 communicates that information to the Forwarder.
485 In order to exchange this information this specification uses the
486 XMPP [RFC6120] protocol along with the Publish-Subscribe [pubsub]
487 extension.
489 VPN forwarders (both co-located and external) establish XMPP sessions
490 with End-System Route Servers, acting as XMPP clients. When an
491 external VPN Forwarder is used, end-systems establish XMPP sessions
492 with VPN Forwarders. External VPN Forwarders act as XMPP servers for
493 end-systems which are associated with them.
495 A VPN Forwarder MAY connect to multiple End-System Route Servers for
496 reliability. In this case it SHOULD publish its information to each
497 of the Route Servers. It MAY choose to subscribe to VPN routing
498 information once only from one of the available gateways.
500 The information advertised by an XMPP client SHOULD be deleted after
501 a configurable timeout, when the session closes. This timeout should
502 default to 60 seconds.
504 +---------+ +--------+
505 | RS | ----------- | BGP |
506 +---------+ +--------+
507 // \ /
508 XMPP \ /
509 // \ /
510 +------------+ \ /
511 | end-system | \ /
512 +------------+ \/
513 \\ /\
514 XMPP / \
515 \\ / \
516 +---------+ / \ +--------+
517 | RS | ----------- | BGP |
518 +---------+ +--------+
520 The figure above represents a typical configuration in which an end-
521 system with a co-located VPN Forwarder is directly connected to two
522 End-System Routes Servers, which are in turn connected to multiple
523 BGP speakers which may be other L3VPN PEs or BGP route reflectors.
525 In deployment the number of End-System Route Servers used will depend
526 on the desired Route Server to VPN Forwarder ratio which affects the
527 convergence time of event propagation.
529 The XMPP "jid" used by the client shall be a string that uniquely
530 identifies it in its administrative domain. This specification
531 recommends the use of the hostname (when unique) or an IP address in
532 its string representation.
534 Each VPN shall be identified by a 128 octet ASCII character string.
536 When external Forwarders are used, its control software operates as a
537 XMPP server processing requests from end-systems and as a client of
538 one or more End-System Route Servers. The control software relays to
539 the End-System Route Server(s) VPN membership messages it receives
540 from the end-system. VPN routing information received from the Route
541 Server(s) SHOULD NOT be propagated to the end-system.
543 When a virtual interface is created on a end-system, the host
544 operating-system software shall generate an XMPP Subscribe message to
545 its server (the End-System Route Server or external VPN Forwarder).
547 Subscription request from co-located VPN Forwarder to Route Server:
549
553
554
555
556 1
557
558
559
561 The request above, instructs the End-System Route Server to start
562 populating the client's VRF table with any routing information that
563 is available for this VPN. The XMPP node 'vpn-customer-name' is
564 assumed to be implicitly created by the End-System Route Server.
565 Creation of a virtual interface may precede any IP address becoming
566 active on the interface, as it is the case with VM instantiation.
568 The optional "instance-id" element allows the VPN Forwarder to
569 specify a unique 16 bit index that can be used by the Route Server to
570 automatically assign a Route Distinguisher (RD) to any route
571 subsequently advertised by the VPN Forwarder. In a scenario where
572 the VPN Forwarder is advertising reachability information to multiple
573 Route Servers it is desirable for reachability information to have an
574 RD composed of the VPN Forwarder identifier (e.g. IPv4 address) and
575 the "instance-id".
577 Subscription request from end-system to external VPN Forwarder:
579
583
584
585
586
587 vlan-id
588
589
590
591
593 When an external VPN Forwarder is used, the end-system should include
594 the VLAN identifier it assigned to the virtual interface as a
595 subscription option.
597 When a IP address is added to a virtual interface, the end-system
598 will generate an XMPP Publish request.
600 Publish request from VPN Forwarder to End-System Route Server:
602
604 to='network-control@domain.org'
605 id='request1'>
606
607
608
609
610
611 1
612 'vpn-ip-address/32'
613
614
615
616 1
617 'infrastructure-ip-address'
618
619
620 gre
621 udp
622
623
624
625 1
626
627
628
629
630
632 The End-System Route Server will convert the information received in
633 a 'publish' request into the corresponding BGP route information such
634 that:.
636 It associates the specific request with a local VRF which it
637 resolves by using a combination of the originator jid and the
638 collection 'node' attribute.
640 It creates a BGP VPN route with a 'Route Distinguisher' (RD) which
641 contains a unique 32bit value per end-system plus a 16bit
642 instance-id, the specified IP prefix and 'label' received from the
643 VPN Forwarder as the Network Layer Reachability Information
644 (NLRI). The instance-id is either the value specified by the XMPP
645 client in the subscribe message for the specific pubsub node or a
646 locally generated value when that parameter is omitted.
648 The BGP next-hop address is set to the address of the VPN
649 Forwarder.
651 A BGP Tunnel Encapsulation Attribute [RFC5512] is generated for
652 each 'tunnel-encapsulation' element specified in the XMPP message.
654 It optionally associates the route with a MAC Mobility extended
655 community [I-D.ietf-l2vpn-evpn] containing a sequence number of
656 the route advertisement.
658 Conversely, when an interface operational status is determined to be
659 down or an IP address is unconfigured the VPN forwarder generates an
660 XMPP retract message to withdraw the route advertisement.
662 Retract request from VPN Forwarder to End-System Route Server:
664
668
669
670
671
672
673
674 Update notification from Route Server to VPN Forwarder:
676
677
678
679
680
681
682 1
683 'vpn-ip-address>/32'
684
685
686
687 1
688 'infrastructure-ip-address'
689
690
691
692 1
693
694
695
696 ...
697
698
699
700
702 Notifications should be generated whenever a VPN route is added,
703 modified or deleted. These notification messages contain only items
704 that have been added, modified or deleted since the previous
705 information sent to the VPN Forwarder. Notification messages can be
706 segmented at the convinience of the Router Server.
708 Note that the Update from the Route Server to the VPN Forwarder does
709 not contain the "jid" of the destination end-system. The "from"
710 attribute in the 'message' element contains a "jid" associated with
711 the Route Servers in the domain. The XMPP messages are point-to-
712 point in nature, between a Forwarder and Route Server. Even in the
713 case when one XMPP publish request from a Forwarder may cause the
714 Route Server to generate one or more event notifications.
716 The item "id" used in publish and retract messages must be unique
717 within the context of a XMPP pubsub node. This specification uses an
718 id format that corresponds to the string representation of the route
719 such that the leading part corresponds to an IP identifier of the
720 end-system, followed by the 'instance-id' for the specific VRF and
721 the IP prefix in its canonical string representation.
723 When multiple possible routes exist for a given VPN IP address within
724 a VRF it is the responsibility of the Route Server to select the best
725 path to advertise to the Forwarder.
727 A VPN Forwarder uses locally originated information to generate MPLS
728 label forwarding state, used to forward downstream traffic (i.e.
729 traffic received from the network). Upstream traffic (i.e. received
730 from a virtual-interface) is forwarded according to the routing
731 information received from one or more Route Servers that the VPN
732 forwarder has an XMPP session with. In the case where multiple
733 Router Servers are providing routing information for a specific NLRI
734 the VPN Forwarder SHOULD select the following algorithm:
736 Prefer the highest local-preference value;
738 Prefer the highest sequence-number;
740 Tie-break on the Route Server IP address.
742 When routes are withdrawn, the End-System Route Server generates an
743 item "retract" request.
745 Route advertisements can have an optional sequence-number which help
746 the route server determine the most recent route advertisement. The
747 sequence number is detemined by an mechanism external to this
748 document. One example is to use time synchronization between compute
749 nodes to have a globally coordinated timestamp. This timestamp can
750 be used to identify the time of interface creation on the compute
751 node.
753 Routes can also be associated with a "local-preference" attribute.
754 This attribute mapps to the BGP attribute of the same name for the
755 purposes of route selection.
757 7. End-System Route Server behavior
759 End-System Route Servers SHALL support the BGP address families: VPN-
760 IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 132)
761 [RFC4684].
763 When an End-System Route Server receives a request to create or
764 modify a VPN route it SHALL generate a BGP VPN route advertisement
765 with the corresponding information.
767 It is assumed that the End-System Route Servers have information
768 regarding the mapping between the tuple ('end-system', 'vpn-customer-
769 names') and BGP Route Targets used to import and export information
770 from the associated VRFs. This mapping is known via an out-of-band
771 mechanism not specified in this document.
773 Whenever the End-System Route Server receives an XMPP subscription
774 request, it SHALL consult its RT-Constraint Routing Information Base
775 (RIB). If the Route Server does not have a locally originated RT-
776 Constraint route that corresponds to the vpn-name present in the
777 request, it SHALL create one and generate the corresponding BGP route
778 advertisement. This route advertisement should only be withdrawn
779 when there are no more downstream XMPP clients subscribed to the VPN.
781 End-System Route Servers SHOULD automatically assign a BGP route
782 distinguisher per VPN routing table.
784 8. Operational Model
786 In the simplest case, a VPN is a collection of systems that are
787 allowed to exchange traffic with each other and only with each other.
788 Since all the forwarding tables in this VPN have the same routing
789 entries they are often referred to as symmetrical VPNs.
791 In order to better illustrate the operation of the protocol we
792 consider a simple example in which "host 1" and "host 2" both contain
793 a virtual interface that is a member of the same VPN.
795 Each of these hosts has an XMPP session with an End-System Route
796 Server, RS1 and RS2 our example, and these Route Servers are part of
797 the same BGP mesh.
799 When a virtual interface is created on "host 1", the local XMPP
800 client generates a XMPP subscription message to its respective Route
801 Server. This message contains a VPN identifier that has been
802 assigned by the provisioning system. The Route Server maps that
803 identifier to a BGP IP VPN configuration which contains the list of
804 import and export route targets to be used for that particular VRF.
806 Once the interface is operational, "host 1" will publish any IP
807 addresses that are configured on the respective virtual interface.
808 This will in turn cause the End-System Route Server to advertise
809 these (directly or indirectly) to any other BGP speaker on the
810 network which is connected to an attachment point of that VPN.
812 +--------+ +------------+ +----------+
813 | host 1 | <===> | End-System | <===> | BGP mesh |
814 +--------+ |Route Server| +----------+
815 +------------+
817 Figure 1
819 +----------------+-------------+-------+-----------+
820 | VPN IP address | NEXT-HOP | label | Known via |
821 +----------------+-------------+-------+-----------+
822 | 10.1.1.1/32 | 192.168.1.1 | 10000 | XMPP |
823 | | | | |
824 | 10.1.1.2/32 | 192.168.2.1 | 20000 | BGP |
825 +----------------+-------------+-------+-----------+
827 VPN Routing table on Route Server
829 Table 1
831 The figure above represents the contents of the VRF routing table on
832 RS1 after the IPv4 address 10.1.1.1 has been added to the virtual
833 interface on host 1. It assumes that there is another attachement
834 point for this VPN with the IPv4 address of 10.1.1.2. Host 1 has an
835 infrastructure IP address of 192.168.1.1 configured on its physical
836 interface while host 2 has IP address 192.168.2.1.
838 The contents of the VRF routing table in the End-System Route Servers
839 are advertised via XMPP Update notifications sent to host 1. This
840 information is the used by the host to populate the forwarding table
841 associated with that VPN.
843 +--------+ +--------+
844 app -- veth0 --| host 1 |=== [network] ===| host 2 |-- veth0 -- app
845 +--------+ +--------+
847 IP pkt ===> encap (GRE + label) ===> [IP net] ===> decap ===> IP pkt
848 [192.168.2.1, 20] map 20 to veth0
850 Figure 2
852 +----------------+--------------+-------+
853 | VPN IP address | Host address | label |
854 +----------------+--------------+-------+
855 | 10.1.1.1/32 | localhost | 10000 |
856 | | | |
857 | 10.1.1.2/32 | 192.168.2.1 | 20000 |
858 +----------------+--------------+-------+
860 VRF table on host1
862 Table 2
864 When an application that uses the virtual interface on host 1
865 generates packets with a destination IP address of 10.1.1.2 these are
866 routed by the VPN Forwarder implemented in the Host OS. The packets
867 are encapsulated with a header that contains a 20-bit label assigned
868 by host 2.
870 In the case the virtual interface on host is associated with a guest
871 OS, this guest OS has had its address resolution queries answered
872 with the Virtual Router MAC address. As a result, that is the
873 address it uses as the destination MAC address in packets it
874 originates. This MAC address is not present on the encapsulated
875 packet.
877 End-System Route Servers are software applications that implement
878 both the BGP IP VPN PE control plane as well as XMPP server
879 functionality. These applications are not in the forwarding plane
880 and do not need to be co-located with a network device.
882 Network devices MAY have direct BGP sessions to the End-System Route
883 Servers. For instance, a router or security appliance that supports
884 BGP/MPLS IP VPNs over GRE may use its existing functionality to
885 inter-operate directly with a collection of Virtual Machines or other
886 network appliances that support this specification.
888 End-System Route Servers implement the VRF import policy and export
889 policy functionality that is associated with PE routers in standard
890 BGP IP/VPN deployments. VPN Forwarders receive forwarding
891 information after policy and route selection is applied. These are
892 unqualified routes in a specific VRF rather than VPN routing
893 information qualified by a Route Distinguisher and with a set of
894 Route Targets.
896 A symmetrical VPN uses a vrf import and vrf export polices that
897 contain a single route target, where the route target used for both
898 import and export is the same.
900 Different VPN topologies can be created by manipulating the vrf
901 import and export configuration including "hub-and-spoke" topologies
902 or overlapping VPNs.
904 An example of a hub-and-spoke VPN configuration is one where all the
905 traffic from the VPN clients must be redirected though a middle-box
906 for inspection. Assuming that the virtual interfaces of a particular
907 user are configured to be in the VPN "tenant1". At an initial stage
908 this "tenant1" VPN is symmetrical and uses a single Route Target in
909 both its import and export policies. The middle-box functionality
910 can be incrementally deployed by defining a new VPN, "tenant1-hub",
911 and an associated Route Target. Accompanied with a change in the
912 End-System Route Server configuration such that VPN "tenant1" only
913 imports routes with the Route Target associated with the hub. The
914 "hub" VPN is assumed to advertise a prefix that covers all the VPN
915 clients IP addresses. The "hub" VPN imports the VPN routes in order
916 for it to be able to generate the XMPP updates to the "hub" end-
917 system. This information is required for the return traffic from the
918 hub to the spokes (the VPN clients). In such a scenario a single
919 physical interface can connect the middle-box to the clients in a
920 given VPN which appear logically as downstream from it. Such a
921 middle-box would often require connectivity to multiple VPNs, such as
922 for instance an "outside" VPN which provides external connectivity to
923 one or more "inside" VPNs.
925 The functionality defined in this document in which the BGP IP VPN PE
926 functionality is split into its control (End-System Route Servers)
927 and forwarding (VPN Forwarder) components is fully interoperable with
928 existing BGP IP VPN PEs.
930 This makes it possible to reuse existing systems. For example, at
931 the edge of a data-center facility it may be desirable to use an
932 existing router or appliance that aggregates IP VPN routing
933 information and/or provides IP based services such as stateful packet
934 inspection.
936 Such a system can be configured, based on existing functionality, to
937 suppress more specific routes than a specified aggregate while
938 advertising the aggregate with a BGP NEXT_HOP containing the PE's IP
939 address and a locally assigned label corresponding to a VRF where the
940 more specific routes are present.
942 9. IANA Considerations
944 This document has no IANA actions.
946 10. Security Considerations
948 The signaling protocol defines the access control policies for each
949 virtual interface and any guest application associated with it. It
950 is important to secure the end-system access to End-System Route
951 Servers and the BGP infrastructure itself.
953 The XMPP session between end-systems and the Route Servers MUST use
954 mutual authentication. One possible strategy is to distribute pre-
955 signed certificates to end-systems which are presented as proof of
956 authorization to the Route Server.
958 BGP sessions MUST be authenticated. This document recommends that
959 BGP speaking systems filter traffic on port 179 such that only IP
960 addresses which are known to participate in the BGP signaling
961 protocol are allowed.
963 As a security measure, it is recommended that virtual and
964 infrastructure topologies never be allowed to exchange traffic
965 directly. The infrastructure network containing the end-systems is
966 typically isolated from the outside world.
968 11. XML schema
970 The following schema defines the XML elements that are used to
971 communicate unicast reachability information between the Route Server
972 and VPN Forwarder:
974
978
979
980
981
982
983
984
986
987
988
991
992
994
995
996
997
998
999
1001
1002
1004
1005
1006
1008
1009
1010
1011
1012
1013
1014
1015
1016
1018
1019
1020
1021
1022
1023
1024
1025
1027
1028
1029
1030
1031
1033
1034
1035
1037
1038
1040
1042
1044 12. Acknowledgements
1046 Yakov Rekhter has contributed to this document by providing detailed
1047 feedback and suggestions. The authors would also like to thank
1048 Thomas Morin for his comments.
1050 Amit Shukla and Ping Pan contributed to earlier versions of this
1051 document.
1053 13. References
1054 13.1. Normative References
1056 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
1057 implement transparent subnet gateways", RFC 1027, October
1058 1987.
1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1061 Requirement Levels", BCP 14, RFC 2119, March 1997.
1063 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
1064 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
1065 4023, March 2005.
1067 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
1068 Networks (VPNs)", RFC 4364, February 2006.
1070 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
1071 Reflection: An Alternative to Full Mesh Internal BGP
1072 (IBGP)", RFC 4456, April 2006.
1074 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
1075 R., Patel, K., and J. Guichard, "Constrained Route
1076 Distribution for Border Gateway Protocol/MultiProtocol
1077 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
1078 Private Networks (VPNs)", RFC 4684, November 2006.
1080 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
1081 Subsequent Address Family Identifier (SAFI) and the BGP
1082 Tunnel Encapsulation Attribute", RFC 5512, April 2009.
1084 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
1085 Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
1087 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1088 Protocol (XMPP): Core", RFC 6120, March 2011.
1090 [pubsub] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
1091 Subscribe", XEP 0060, July 2010.
1093 13.2. Informational References
1095 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
1096 and D. McPherson, "Dissemination of Flow Specification
1097 Rules", RFC 5575, August 2009.
1099 [I-D.ietf-mpls-in-udp]
1100 Xu, X., Sheth, N., Yong, L., Pignataro, C., and F.
1101 Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in-
1102 udp-05 (work in progress), January 2014.
1104 [I-D.ietf-l2vpn-evpn]
1105 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
1106 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
1107 evpn-08 (work in progress), September 2014.
1109 [IEEE.802-1Q]
1110 Institute of Electrical and Electronics Engineers, "Local
1111 and Metropolitan Area Networks: Virtual Bridged Local Area
1112 Networks", IEEE Std 802.1Q-2005, May 2006.
1114 Authors' Addresses
1116 Pedro Marques
1117 Juniper Networks
1118 1133 Innovation Way
1119 Sunnyvale, CA 94089
1121 Email: roque@juniper.net
1123 Luyuan Fang
1124 Microsoft
1125 5600 148th Ave NE
1126 Redmond, WA 98052
1128 Email: lufang@microsoft.com
1130 Nischal Sheth
1131 Juniper Networks
1132 1133 Innovation Way
1133 Sunnyvale, CA 94089
1135 Email: nsheth@juniper.net
1137 Maria Napierala
1138 AT&T Labs
1139 200 Laurel Avenue
1140 Middletown, NJ 07748
1142 Email: mnapierala@att.com
1143 Nabil Bitar
1144 Verizon
1145 40 Sylvan Rd.
1146 Waltham, MA 02145
1148 Email: nabil.bitar@verizon.com