idnits 2.17.1
draft-ietf-l3vpn-end-system-00.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 :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 2 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
** The abstract seems to contain references ([RFC4364]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
== 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.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 307: '... VPN Forwarder MAY be co-located in ...'
RFC 2119 keyword, line 337: '...irtual MAC address which SHOULD be the...'
RFC 2119 keyword, line 339: '... virtual MAC address SHALL default to the VRRP [RFC5798] virtual...'
RFC 2119 keyword, line 400: '... MUST implement the following functi...'
RFC 2119 keyword, line 426: '...he VPN Forwarder MAY support the abili...'
(18 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 2012) is 4208 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)
== Unused Reference: 'RFC4271' is defined on line 896, but no explicit
reference was found in the text
== Unused Reference: 'I-D.marques-sdnp-flow-spec' is defined on line 929,
but no explicit reference was found in the text
** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955)
Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Marques
3 Internet-Draft Contrail Systems
4 Intended status: Standards Track L. Fang
5 Expires: April 02, 2013 Cisco Systems
6 P. Pan
7 Infinera Corp
8 A. Shukla
9 Juniper Networks
10 M. Napierala
11 AT&T Labs
12 N. Bitar
13 Verizon
14 October 2012
16 BGP-signaled end-system IP/VPNs.
17 draft-ietf-l3vpn-end-system-00
19 Abstract
21 This document describes a solution in which the control plane
22 protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a
23 Virtual Network service to end-systems. These end-systems may be
24 used to provide network services or may directly host end-to-end
25 applications.
27 Status of this Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on April 02, 2013.
44 Copyright Notice
46 Copyright (c) 2012 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents (http://trustee.ietf.org/
51 license-info) in effect on the date of publication of this document.
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document. Code Components
54 extracted from this document must include Simplified BSD License text
55 as described in Section 4.e of the Trust Legal Provisions and are
56 provided without warranty as described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
62 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Applicability of BGP IP VPNs . . . . . . . . . . . . . . . . . 4
64 4. Virtual network end-points . . . . . . . . . . . . . . . . . . 6
65 5. VPN Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 8
66 6. XMPP signaling protocol . . . . . . . . . . . . . . . . . . . 10
67 7. End-System Route Server behavior . . . . . . . . . . . . . . . 15
68 8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 15
69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
72 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
73 11.2. Informational References . . . . . . . . . . . . . . . . 19
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
76 1. Introduction
78 This document describes the requirements for a network virtualization
79 solution that provides an IP service to end-system virtual
80 interfaces. It then discusses how the BGP IP VPNs [RFC4364] control
81 plane can be used to provide a solution that meets these
82 requirements. Subsequent sections provide a detailed discussion of
83 the control and forwarding plane components.
85 In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider
86 Edge (PE) device which provides both the control plane and VPN
87 encapsulation functions required to implement a Virtual Network
88 service. This document decouples the control plane and forwarding
89 functionality of the PE device in order to enable the forwarding
90 functionality to be implemented in multiple devices. For instance,
91 the forwarding function can be implemented directly on the operating
92 system of application servers or network appliances.
94 1.1. Terminology
96 This document makes use of the following terms:
98 End-System Route Server A software application that implements the
99 control plane functionality of a BGP IP VPN PE device and a XMPP
100 server that interacts with VPN Forwarders.
102 Virtual Interface An interface in an end-system that is used by a
103 virtual machine or by applications. It performs the role of a CE
104 interface in a BGP IP VPN network.
106 VPN Forwarder The forwarding component of a BGP IP VPN PE device.
107 This functionality may be co-located with the virtual interface or
108 implemented by an external device.
110 2. Requirements
112 Network Virtualization is used in both service provider as well as
113 enterprise networks to support multi-tenancy, network-based access
114 control. It may also be used to facilitate end-system mobility.
116 Multi-tenancy allows a physical network to provide services to
117 multiple "customers" or "tenants", whether these are external
118 entities in the case of a Service Provider providing managed VPN
119 services or internal departments sharing an IT facility. Multi-
120 tenancy requires isolation of traffic and routing information between
121 tenants.
123 Within a tenant, it is often required to create multiple distinct
124 virtual networks, in order to be able to provide network-based access
125 control. In this service model, each virtual network behaves as a
126 "Closed User Group" (CUG) of end-systems that are allowed to exchange
127 traffic freely, while traffic between virtual networks is subject to
128 access controls. This scenario can be found in both enterprise
129 campus networks, branch offices and data-centers.
131 It is often the case when network access control is used, that the
132 traffic patterns are such that there is significantly more traffic
133 crossing a CUG boundary than staying within such boundary. As an
134 example, in campus networks it is common to segregate users into CUGs
135 based on some classification such as the user's department. Campus
136 networks often see traffic patterns in which almost all the traffic
137 flows northbound to the data-center or internet boundaries. Similar
138 traffic patterns can be found in multi-tier applications in IT data-
139 centers.
141 End-systems are often configured to expect the concept of IP subnet
142 to match its closed user group. A network virtualization solution
143 should be able to provide this concept of IP subnet regardless of
144 whether the underlying implementation uses a multi-access network or
145 not.
147 End-system virtual interfaces should be able to directly access
148 multiple closed user groups without needing to traverse a gateway.
149 Network access policy should allow this access whether the source and
150 destination CUGs for a particular traffic flow belong to the same
151 tenant or different tenants. It is often the case that
152 infrastructure services are provided to multiple tenants. One such
153 example is voice-over-IP gateway services for branch offices.
155 Independently, but often associated with the previous two functions,
156 IP mobility is another network function that can be implemented using
157 network virtualization. By abstracting the externally visible
158 network address from the underlying infrastructure address, mobility
159 can be implemented without having to recur to home agents or large L2
160 broadcast domains. Alternative techniques that are used in both
161 Service Provider as well as enterprise networks.
163 IP Mobility requires the ability to "move" a device without
164 disrupting its TCP (or UDP) transport sessions. These sessions often
165 deploy second or sub-second keepalives to detect application failure.
166 Experience with failure restoration in Service Provider networks
167 shows that fast-failure restoration often requires the pre-
168 provisioning of a restoration path.
170 IP Mobility can be a result of devices physically moving (e.g., a
171 WiFi enabled laptop) or workload being diverted between physical
172 systems such as network appliances or application servers.
174 3. Applicability of BGP IP VPNs
176 BGP IP VPNs [RFC4364] is the industry de-facto standard for providing
177 "closed user group" functionality in WAN environments. It is used by
178 service providers in environments where several millions of routes
179 are present. It supports both isolated VPNs as well as overlapping
180 VPNs (often referred to as "extranets").
182 In its traditional usage in Service Provider networks, BGP IP VPN
183 functionality is implemented in a Provider Edge (PE) device that
184 combines both BGP signaling as well as VRF-based forwarding
185 functions. In practice, most PE devices in current use are multi-
186 component systems with the signaling and forwarding functionality
187 actually implemented in different processors attached to an internal
188 network.
190 This document assumes a similar separation of functionality in which
191 software appliances, the End-System Route Servers, implement the
192 control plane functionality of a PE device and a VPN Forwarder
193 implements the forwarding function usually found in a PE device
194 "line-card". The VPN Forwarder functionality may be co-located with
195 the end-system virtual interface (e.g., implemented in the hypervisor
196 switch or host OS network drivers). It may also be external to the
197 end-system residing in a data-center switch or specialized appliance.
199 Operationally, BGP IP VPN technology has several important
200 characteristics:
202 It has a high-level of aggregation between customer interfaces and
203 managed entities (Provider Edge devices).
205 It defines VPNs as policies, allowing an interface to directly
206 exchange traffic with multiple VPNs and allowing for the topology
207 of the virtual network to be modified by modifying the policy
208 configuration.
210 It scales horizontally in terms of event propagation. By
211 increasing the number of signaling devices implementing the PE
212 control plane, it is possible to decrease the load on each
213 signaling device when it comes to propagating events that
214 originate in a specific location and must be propagated across the
215 network.
217 The last point is particularly relevant to the convergence
218 characteristics required for large scale deployments. BGP's
219 hierarchical route distribution capabilities allow a deployment to
220 divide the workload by increasing the number of End-System Route
221 Servers.
223 As an example consider a topology in which 100 End-System Route
224 Servers are deployed in a network each serving a subset of the VPN
225 forwarding elements. The Route Servers inter-connect to two top-
226 level BGP Route Reflectors [RFC4456].
228 If an event (i.e. a VPN route change) needs to be propagated from a
229 specific end-system to 10.000 clients randomly distributed across the
230 network, each of the End-System Route Servers must generate 100
231 updates to its respective downstream clients.
233 By modifying this topology such that another 100 End-System Route
234 Servers are added, then each Route Server is now responsible to
235 generate 50 client updates. This example illustrates the linear
236 scaling properties of BGP: doubling the number of Route Servers (i.e.
237 the processing capacity) reduces in half the number of updates
238 generated by each (i.e. load at each processing node).
240 The same horizontal scaling techniques can be applied to the Route
241 Reflector layer in the example above by subsetting the VPN Route
242 space according to some pre-defined criteria (for instance VPN route
243 target) and using a pair of Route Reflectors per subset.
245 In the previous example we assumed a dense membership in which all
246 Route Servers have local clients that are interested in a particular
247 event. BGP also optimizes the route distribution for sparse events.
249 The Route Target Constraint [RFC4684] extension, builds an optimal
250 distribution tree for message propagation based on VPN membership.
251 It ensures that only the PEs with local receivers for a particular
252 event do receive it also decreasing the total load on the upstream
253 BGP speaker.
255 In the WAN environment, BGP IP VPN control plane scaling is focused
256 not primarily on route convergence times but on memory footprint of
257 embedded devices. While memory footprint does not have a similar
258 linear scaling behavior, memory technology available to software
259 appliances is often at 10x the scale of what is commonly found in WAN
260 environments.
262 The functionality present in the BGP IP VPN control plane addresses
263 the requirements specified in the previous section. Specifically, it
264 supports multiple potentially overlapping "groups", regular or "hub
265 and spoke" topologies and the scaling characteristics necessary.
267 The BGP IP VPN control plane supports not only the definition of
268 "closed user-groups" (VPNs in its terminology) but also the
269 propagation of inter-VPN traffic policies [RFC5575]. An application
270 of that mechanism to "end-system" VPNs is presented in [I-D.marques-
271 sdnp-flow-spec].
273 Note that the signaling protocol itself is rather agnostic of the
274 encapsulation used on the wire as long as this encapsulation has the
275 ability to carry a 20 bit label.
277 Several network environments use a network infrastructure that is
278 only capable of providing an IP unicast service. In order to support
279 them, implementations of this document should support the MPLS in GRE
280 [RFC4023] encapsulation. Other encapsulations are possible,
281 including UDP based encapsulations.
283 4. Virtual network end-points
285 This document assumes that end-systems support one or more virtual
286 network interfaces in addition to a physical interface that is
287 associated with the underlying network infrastructure. Virtual
288 network interfaces can be associated with a restricted list of
289 applications via OS-dependent mechanisms, a Virtual Machine (VM), or
290 they can be used to provide network connectivity to all user
291 applications in the same way that a "VPN tunnel" interface is used to
292 provide access between an end-system (e.g., a laptop) and a remote
293 corporate network.
295 From an IP address assignment point of view, a virtual network
296 interface is addressed out of the virtual IP topology and associated
297 with a "closed user group" or VPN, while the physical interface of
298 the machine is addressed in the network infrastructure topology. As
299 a security measure, it is recommended that virtual and infrastructure
300 topologies never be allowed to exchange traffic directly.
302 Both static and dynamic IP address allocation can be supported. The
303 later assumes that the VPN Forwarder implements a DHCP relay or DHCP
304 proxy functionality.
306 A virtual network interface is connected to a VPN Forwarder. This
307 VPN Forwarder MAY be co-located in the end-system or external.
309 Traffic that ingresses or egresses through a virtual network
310 interface is routed at the VPN Forwarder which acts as the first-hop
311 router (in the virtual topology). The IP configuration on the client
312 side of this virtual network interface (e.g., in the guest OS) can
313 follow one of two models:
315 point-to-point interface model.
317 multipoint interface model.
319 In a point-to-point interface model, the VPN client routing table
320 (e.g., on the guest OS) contains the following routing entires: a
321 host route to the local IP address, a host route to the first-hop
322 router via the virtual interface and a default route to the first-hop
323 router. This is the model typically used in "VPN tunnel"
324 configurations or other access technologies such as cable deployments
325 or DSL. When this model is used, the first-hop router IP address is a
326 link-local address that is the same on all first-hop routers across a
327 specific deployment. This first-hop IP address should not change
328 when a virtual interface moves between different machines.
330 In a multi-point interface model, the VPN client routing table (e.g.,
331 on the guest OS) contains the following routing entires: a host route
332 to the local IP address, a subnet route to the local interface and
333 optionally a default route to a specific router address within that
334 subnet. In this model, the VPN client IP stack will issue address
335 resolution requests for any IP addresses it considers to be directly
336 attached to the subnet. The VPN Forwarder shall answer all address
337 resolution requests with a virtual MAC address which SHOULD be the
338 same across all VPN Forwarders in a specific deployment. This
339 virtual MAC address SHALL default to the VRRP [RFC5798] virtual
340 router MAC address for Virtual Router Identifier (VRID) 1.
342 When the virtual topology first-hop router resides on the same
343 physical machine, the host OS is responsible to map the virtual
344 interface with a VPN specific routing table (without taking L2
345 addresses into consideration). In this case the mac-addresses known
346 to the guest OS are not used on the wire.
348 When the virtual topology first-hop router resides in an external
349 system (e.g., the first hop-switch) the virtual interface shall be
350 identified by the combination of the mac-address assigned to physical
351 interface of the end-system and a 802.1Q VLAN tag. The first-hop
352 switch should use a virtual router MAC address to answer any address
353 resolution queries.
355 Whenever an external VPN Forwarder is used and resiliency is desired,
356 the external VPN Forwarder should be redundant. It is desirable to
357 use VRRP as a mechanism to control the flow of traffic between the
358 end-system and the external VPN Forwarder. VRRP already defines the
359 necessary procedures to elect a single forwarder for a LAN.
361 This specification uses the VRRP virtual router MAC address as the
362 default L2 address for the VPN Forwarder as a client virtual
363 interface may move between locations where redundancy may not be
364 present.
366 While the VRRP Virtual Router MAC will be used to answer any address
367 resolution request made by the virtual interface client (e.g., the
368 guest VM) this does not imply that a single default router is elected
369 per virtual IP subnet. The ingress VPN Forwarder will perform an IP
370 forwarding decision based on the destination IP address of the
371 (payload) traffic.
373 VRRP router election is only relevant in selecting the VPN Forwarder
374 associated with a specific machine, when external forwarders are in
375 use.
377 5. VPN Forwarder
379 In this solution, the Host OS/Hypervisor in the end-system must
380 participate in the virtual network service. Given an end-system with
381 multiple virtual interfaces, these virtual interfaces must be mapped
382 onto the network by the guest OS such that applications on one
383 virtual interface are not allowed to impersonate another virtual
384 interface.
386 When VPN forwarder functionality is implemented by the Host OS/
387 Hypervisor, intermediate systems in the network do not require any
388 knowledge of the virtual network topology. This can simplify the
389 design and operation of the physical network.
391 When it is not possible or desirable to add the VPN forwarding
392 functionality to the end-system, it may be implemented by an external
393 system, typically located as close as possible to the end-system
394 itself.
396 Both models, co-located and external VPN Forwarder can co-exist in a
397 deployment.
399 In order to implement the BGP IP VPN Forwarder functionality a device
400 MUST implement the following functionality:
402 Support for multiple "Virtual Routing and Forwarding" (VRF)
403 tables;
404 VRF route entries map prefixes in the virtual network topology
405 to a next-hop containing a infrastructure IP address and a
406 20-bit label allocated by the destination Forwarder. The VRF
407 table lookup follows the standard IP lookup (best-match)
408 algorithm.
410 Associate an end-system virtual interface with a specific VRF
411 table;
413 When the the Forwarder is co-located with the end-system, this
414 association is implemented by an internal mechanism. When the
415 Forwarder is external the association is performed using the
416 mac-address of the end-system and a IEEE 802.1Q tag that
417 identifies the virtual interface within the end-system.
419 Encapsulate outgoing traffic (end-system to network) according to
420 the result of the VRF lookup;
422 Associate incoming packets (network to end-system) to a VRF
423 according to the 20-bit label contained immediately after the GRE
424 header;
426 The VPN Forwarder MAY support the ability to associate multiple
427 virtual interfaces with the same VRF. When that is the case, locally
428 originated routes, that is IP routes to the local virtual interfaces
429 SHALL NOT be used to forward outbound traffic (from the virtual
430 interfaces to the outside) unless a route advertisement has been
431 received that matches that specific IP prefix and next-hop
432 information.
434 As an example, if a given VRF contains two virtual interfaces,
435 "veth0" and "veth1", with the addresses 10.0.1.1/32 and 10.0.1.2/32
436 respectively, the initial forwarding state must be initialized such
437 that traffic from either of these interfaces does not match the
438 other's routing table entry. It may for instance match a default
439 route advertised by a remote system. Traffic received from other VPN
440 Forwarders, however, must be delivered to the correct local
441 interface. If at a subsequent stage a route is received from the
442 Route Server such that 10.0.1.2/32 has a next-hop with the IP address
443 of the local host and the correct label, the system may subsequently
444 install a local routing table entry that delivers traffic directly to
445 the "veth1" interface.
447 The 20-bit label which is associated with a virtual-interface is of
448 local significance only and SHOULD be allocated by the VPN Forwarder.
450 When an external VPN Forwarder is used the end-system MUST associate
451 each virtual interface with a VLAN [IEEE.802-1Q] that is unique on
452 the end-system. The switching infrastructure MUST be configured such
453 that multi-destination frames sourced from an end-system are only
454 delivered to VPN Forwarders used by this end-system and not to other
455 end-systems.
457 6. XMPP signaling protocol
459 End-System Route Servers must be aware of VPN membership on each
460 Forwarder as well as what IP addresses are currently associated with
461 each virtual interface.
463 VPN Forwarders must receive VPN route information from which to
464 populate their forwarding tables. External VPN Forwarders also need
465 to receive the virtual interface and IP address events from the end-
466 system for which they are VPN forwarders. In this case the end-
467 system assigns an 802.1Q VLAN tag to each virtual interface and
468 communicates that information to the Forwarder.
470 In order to exchange this information this specification uses the
471 XMPP [RFC6120] protocol along with the PubSub Collection Nodes
472 [pubsub] extension.
474 When an external VPN Forwarder is used, end-systems establish XMPP
475 sessions with VPN Forwarders. VPN forwarders (both co-located and
476 external) establish XMPP sessions with End-System Route Servers. VPN
477 Forwarders act as an XMPP clients of a End-System Route Server.
478 External VPN Forwarders act as XMPP servers for end-systems which are
479 associated with them. These sessions are persistent and MUST use the
480 XMPP Ping [xmpp-ping] extension in order to detect end-system
481 failures.
483 A VPN Forwarder MAY connect to multiple End-System Route Servers for
484 reliability. In this case it SHOULD publish its information to each
485 of the Route Servers. It MAY choose to subscribe to VPN routing
486 information once only from one of the available gateways.
488 The information advertised by an XMPP client SHOULD be deleted after
489 a configurable timeout, when the session closes. This timeout should
490 default to 60 seconds.
492 +---------+ +--------+
493 | RS | ----------- | BGP |
494 +---------+ +--------+
495 // \ /
496 XMPP \ /
497 // \ /
498 +------------+ \ /
499 | end-system | \ /
500 +------------+ \/
501 \\ /\
502 XMPP / \
503 \\ / \
504 +---------+ / \ +--------+
505 | RS | ----------- | BGP |
506 +---------+ +--------+
508 The figure above represents a typical configuration in which an end-
509 system with a co-located VPN Forwarder is directly connected to two
510 End-System Routes Servers, which are in turn connected to multiple
511 BGP speakers which may be other L3VPN PEs or BGP route reflectors.
513 In deployment the number of End-System Route Servers used will depend
514 on the desired Route Server to VPN Forwarder ratio which affects the
515 convergence time of event propagation.
517 The XMPP "jid" used by the client shall be a 6-byte value that
518 uniquely identifies it in its administrative domain. This
519 specification recommends the use of the MAC address of one of the
520 physical ethernet interfaces.
522 Each VPN shall be identified by a 128 octet ASCII character string.
524 When external Forwarders are used, its control software operates as a
525 XMPP server processing requests from end-systems and as a client of
526 one or more End-System Route Servers. The control software relays to
527 the End-System Route Server(s) VPN membership messages it receives
528 from the end-system. VPN routing information received from the Route
529 Server(s) SHOULD NOT be propagated to the end-system.
531 When a virtual interface is created on a end-system, the host
532 operating-system software shall generate an XMPP Subscribe message to
533 its server (the End-System Route Server or external VPN Forwarder).
535 Subscription request from co-located VPN Forwarder to Route Server:
537
541
542
543
544
546 The request above, instructs the End-System Route Server to start
547 populating the client's VRF table with any routing information that
548 is available for this VPN. The XMPP node 'vpn-customer-name' is
549 assumed to be a collection which is implicitly created by the End-
550 System Route Server. Creation of a virtual interface may precede any
551 IP address becoming active on the interface, as it is the case with
552 VM instantiation.
554 Subscription request from end-system to external VPN Forwarder:
556
560
561
562
563
564 vlan-id
565
566
567
568
570 When an external VPN Forwarder is used the end-system should include
571 the VLAN identifier it assigned to the virtual interface as a
572 subscription option.
574 When a IP address is added to a virtual interface, the end-system
575 will generate an XMPP Publish request.
577 Publish request from VPN Forwarder to End-System Route Server:
579
581 to='network-control.domain.org'
582 id='request1'>
583
584
585
586
587
588 1
589 'vpn-ip-address/32'
590
591
592 1
593 'infrastructure-ip-address'
594
595 1
596
597
598
599
600
601
603
607
608
609
610
611
612
614 The End-System Route Server will convert the information received in
615 a the 'publish' request into the corresponding BGP route information
616 such that:.
618 It associates the specific request with a local VRF which it
619 resolves by using a combination of the originator system-id and
620 the collection 'node' attribute.
622 It creates a BGP VPN route with a 'Route Distinguisher' (RD) which
623 contains the the end-system's 'system-id' value and the specified
624 IP prefix and 'label' received from the VPN Forwarder as the
625 Network Layer Reachability Information (NLRI).
627 The BGP next-hop address is set to the address of the VPN
628 Forwarder.
630 It optionally associates the route with an extended community TDB
631 containing a version number of the virtual-interface.
633 Update notification from Route Server to VPN Forwarder:
635
636
637
638
639
640
641 1
642 'vpn-ip-address>/32'
643
644
645 1
646 'infrastructure-ip-address'
647
648 1
649
650
651
652
653 ...
654
655
656
657
659 Notifications should be generated whenever a VPN route is added,
660 modified or deleted.
662 Note that the Update from the Route Server to the VPN Forwarder does
663 not contain the system-id of the destination end-system. The "from"
664 attribute in the 'message' element contains a "jid" associated with
665 the Route Servers in the domain. The XMPP messages are point-to-
666 point in nature, between a Forwarder and Route Server. Even in the
667 case when one XMPP publish request from a Forwarder may cause the
668 Route Server to generate one or more event notifications.
670 When multiple possible routes exist for a given VPN IP address within
671 a VRF it is the responsibility of the Route Server to select the best
672 path to advertise to the Forwarder.
674 When routes are withdrawn, the End-System Route Server generates both
675 a "collection disassociate" request as well as a node "delete"
676 request.
678 In situations where an automated system is controlling the
679 instantiation of virtual interfaces it may be possible to have that
680 system assign a non-decreasing version number for each instantiation
681 of that particular interface. In that case, this number, carried in
682 the 'version' field may be used to help gateways select the most
683 recent instantiation of an interface during the interval of time
684 where multiple routes are present.
686 7. End-System Route Server behavior
688 End-System Route Servers SHALL support the BGP address families: VPN-
689 IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 132)
690 [RFC4684].
692 When an End-System Route Server receives a request to create or
693 modify a VPN route it SHALL generate a BGP VPN route advertisement
694 with the corresponding information.
696 It is assumed that the End-System Route Servers have information
697 regarding the mapping between end-system tuple ('system-id', 'vpn-
698 customer-names') and BGP Route Targets used to import and export
699 information from the associated VRFs. This mapping is known via an
700 out-of-band mechanism not specified in this document.
702 Whenever the End-System Route Server receives an XMPP subscription
703 request, it SHALL consult its RT-Constraint Routing Information Base
704 (RIB). If the Route Server does not already have locally originated
705 route for the route target the corresponds to the vpn-name present in
706 the request, it SHALL create one and generate the corresponding BGP
707 route advertisement. This route advertisement should only be
708 withdrawn when there are no more downstream XMPP clients subscribed
709 to the VPN.
711 The 32bit route version number defined in the XML schema is
712 advertised into BGP as an Extended community with type TBD.
714 End-System Route Servers SHOULD automatically assign a BGP route
715 distinguisher per VPN routing table.
717 8. Operational Model
719 In the simplest case, a VPN is a collection of systems that are
720 allowed to exchange traffic with each other and only with each other.
721 Since all the forwarding tables in this VPN have the same routing
722 entries they are often referred to as symmetrical VPNs.
724 In order to better illustrate the operation of the protocol we
725 consider a simple example in which "host 1" and "host 2" both contain
726 a virtual interface that is a member of the same VPN.
728 Each of these hosts has an XMPP session with an End-System Route
729 Server, RS1 and RS2 our example, and these Route Servers are part of
730 the same BGP mesh.
732 When a virtual interface is created on "host 1", the local XMPP
733 client generates a XMPP subscription message to its respective Route
734 Server. This message contains a VPN identifier that has been
735 assigned by the provisioning system. The Route Server maps that
736 identifier to a BGP IP VPN configuration which contains the list of
737 import and export route targets to be used for that particular VRF.
739 Once the interface is operational, "host 1" will publish any IP
740 addresses that are configured on the respective virtual interface.
741 This will in turn cause the End-System Route Server to advertise
742 these (directly or indirectly) to any other BGP speaker on the
743 network which is connected to an attachment point of that VPN.
745 +--------+ +------------+ +----------+
746 | host 1 | <===> | End-System | <===> | BGP mesh |
747 +--------+ |Route Server| +----------+
748 +------------+
750 +----------------+-------------+-------+-----------+
751 | VPN IP address | NEXT-HOP | label | Known via |
752 +----------------+-------------+-------+-----------+
753 | 10.1.1.1/32 | 192.168.1.1 | 10000 | XMPP |
754 | 10.1.1.2/32 | 192.168.2.1 | 20000 | BGP |
755 +----------------+-------------+-------+-----------+
757 VPN Routing table on Route Server
759 The figure above represents the contents of the VRF routing table on
760 RS1 after the IPv4 address 10.1.1.1 has been added to the virtual
761 interface on host 1. It assumes that there is another attachement
762 point for this VPN with the IPv4 address of 10.1.1.2. Host 1 has an
763 infrastructure IP address of 192.168.1.1 configured on its physical
764 interface while host 2 has IP address 192.168.2.1.
766 The contents of the VRF routing table in the End-System Route Servers
767 are advertised via XMPP Update notifications sent to host 1. This
768 information is the used by the host to populate the forwarding table
769 associated with that VPN.
771 +--------+ +--------+
772 app -- veth0 --| host 1 |=== [network] ===| host 2 |-- veth0 -- app
773 +--------+ +--------+
775 IP pkt ===> GRE encap ===> [IP net] ===> GRE decap ===> IP pkt
776 [192.168.2.1, 20] map 20 to veth0
778 +----------------+--------------+-------+
779 | VPN IP address | Host address | label |
780 +----------------+--------------+-------+
781 | 10.1.1.1/32 | localhost | 10000 |
782 | 10.1.1.2/32 | 192.168.2.1 | 20000 |
783 +----------------+--------------+-------+
785 VRF table on host1
787 When an application that uses the virtual interface on host 1
788 generates packets with a destination IP address of 10.1.1.2 these are
789 routed by the VPN Forwarder implemented in the Host OS. The packets
790 are encapsulated with a GRE header that contains a 20-bit label
791 assigned by host 2.
793 In the case the virtual interface on host is associated with a guest
794 OS, this guest OS has had its address resolution queries answered
795 with the Virtual Router MAC address. As a result, that is the
796 address it uses as the destination MAC address in packets it
797 originates. This MAC address is not present on the GRE encapsulated
798 packet.
800 End-System Route Servers are software applications the implement both
801 the BGP IP VPN PE control plane as well as XMPP server functionality.
802 These application are not in the forwarding plane and do not need to
803 be co-located with a network device.
805 Network devices MAY have direct BGP sessions to the End-System Route
806 Servers. For instance, a router or security appliance that supports
807 BGP/MPLS IP VPNs over GRE may use its existing functionality to
808 inter-operate directly with a collection of Virtual Machines or other
809 network appliances that support this specification.
811 End-System Route Servers implement the VRF import policy and export
812 policy functionality that is associated with PE routers in standard
813 BGP IP/VPN deployments. VPN Forwarders receive forwarding
814 information after policy and route selection is applied. These are
815 unqualified routes in a specific VRF rather than VPN routing
816 information qualified by a Route Distinguisher and with a set of
817 Route Targets.
819 A symmetrical VPN uses a vrf import and vrf export polices that
820 contain a single route target, where the route target used for both
821 import and export is the same.
823 Different VPN topologies can be created by manipulating the vrf
824 import and export configuration including "hub-and-spoke" topologies
825 or overlapping VPNs.
827 An example of a hub-and-spoke VPN configuration is one where all the
828 traffic from the VPN clients must be redirected though a middle-box
829 for inspection. Assuming that the virtual interfaces of a particular
830 user are configured to be in the VPN "tenant1". At an initial stage
831 this "tenant1" VPN is symmetrical and uses a single Route Target in
832 both its import and export policies. The middle-box functionality
833 can be incrementally deployed by defining a new VPN, "tenant1-hub",
834 and an associated Route Target. Accompanied with a change in the
835 End-System Route Server configuration such that VPN "tenant1" only
836 imports routes with the Route Target associated with the hub. The
837 "hub" VPN is assumed to advertise a prefix that covers all the VPN
838 clients IP addresses. The "hub" VPN imports the VPN routes in order
839 for it to be able to generate the XMPP updates to the "hub" end-
840 system. This information is required for the return traffic from the
841 hub to the spokes (the VPN clients). In such a scenario a single
842 physical interface can connect the middle-box to the clients in a
843 given VPN which appear logically as downstream from it. Such a
844 middle-box would often require connectivity to multiple VPNs, such as
845 for instance an "outside" VPN which provides external connectivity to
846 one or more "inside" VPNs.
848 The functionality defined in this document in which the BGP IP VPN PE
849 functionality is split into its control (End-System Route Servers)
850 and forwarding (VPN Forwarder) components is fully interoperable with
851 existing BGP IP VPN PEs.
853 This makes it possible to reuse existing systems. For example, at
854 the edge of a data-center facility it may be desirable to use an
855 existing router or appliance that aggregates IP VPN routing
856 information and/or provides IP based services such as stateful packet
857 inspection.
859 Such a system can be configured, based on existing functionality, to
860 suppress more specific routes than a specified aggregate while
861 advertising the aggregate with a BGP NEXT_HOP containing the PE's IP
862 address and a locally assigned label corresponding to a VRF where the
863 more specific routes are present.
865 9. Security Considerations
867 The signaling protocol defines the access control policies for each
868 virtual interface and any guest application associated with it. It
869 is important to secure the end-system access to End-System Route
870 Servers and the BGP infrastructure itself.
872 The XMPP session between end-systems and the Route Servers MUST use
873 mutual authentication. One possible strategy is to distribute pre-
874 signed certificates to end-systems which are presented as proof of
875 authorization to the Route Server.
877 BGP sessions MUST be authenticated. This document recommends that
878 BGP speaking systems filter traffic on port 179 such that only IP
879 addresses which are known to participate in the BGP signaling
880 protocol are allowed.
882 10. Acknowledgements
884 Yakov Rekhter has contributed to this document by providing detailed
885 feedback and suggestions. The authors would also like to thank
886 Thomas Morin for his comments.
888 11. References
890 11.1. Normative References
892 [RFC4023] Worster, T., Rekhter, Y. and E. Rosen, "Encapsulating MPLS
893 in IP or Generic Routing Encapsulation (GRE)", RFC 4023,
894 March 2005.
896 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway
897 Protocol 4 (BGP-4)", RFC 4271, January 2006.
899 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
900 Networks (VPNs)", RFC 4364, February 2006.
902 [RFC4456] Bates, T., Chen, E. and R. Chandra, "BGP Route Reflection:
903 An Alternative to Full Mesh Internal BGP (IBGP)", RFC
904 4456, April 2006.
906 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
907 R., Patel, K. and J. Guichard, "Constrained Route
908 Distribution for Border Gateway Protocol/MultiProtocol
909 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
910 Private Networks (VPNs)", RFC 4684, November 2006.
912 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.
913 and D. McPherson, "Dissemination of Flow Specification
914 Rules", RFC 5575, August 2009.
916 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
917 Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
919 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
920 Protocol (XMPP): Core", RFC 6120, March 2011.
922 [xmpp-ping]
923 "XMPP Ping", XEP 0199, June 2009.
925 [pubsub] "PubSub Collection Nodes", XEP 0248, September 2010.
927 11.2. Informational References
929 [I-D.marques-sdnp-flow-spec]
930 Marques, P., Fang, L., Pan, P., Shukla, A. and M.
931 Napierala, "Traffic classification in end-system IP
932 VPNs.", Internet-Draft draft-marques-sdnp-flow-spec-01,
933 April 2012.
935 [IEEE.802-1Q]
936 Institute of Electrical and Electronics Engineers, "Local
937 and Metropolitan Area Networks: Virtual Bridged Local Area
938 Networks", IEEE Std 802.1Q-2005, May 2006.
940 Authors' Addresses
942 Pedro Marques
943 Contrail Systems
944 2350 Mission College Blvd.
945 Santa Clara, CA 95054
947 Email: roque@contrailsystems.com
949 Luyuan Fang
950 Cisco Systems
951 111 Wood Avenue South
952 Iselin, NJ 08830
954 Email: lufang@cisco.com
956 Ping Pan
957 Infinera Corp
958 140 Caspian Ct.
959 Sunnyvale, CA 94089
961 Email: ppan@infinera.com
963 Amit Shukla
964 Juniper Networks
965 1194 N. Mathilda Av.
966 Sunnyvale, CA 94089
968 Email: amit@juniper.net
970 Maria Napierala
971 AT&T Labs
972 200 Laurel Avenue
973 Middletown, NJ 07748
975 Email: mnapierala@att.com
976 Nabil Bitar
977 Verizon
978 40 Sylvan Rd.
979 Waltham, MA 02145
981 Email: nabil.bitar@verizon.com