One document matched: draft-fang-l3vpn-end-system-requirements-01.txt
Differences from draft-fang-l3vpn-end-system-requirements-00.txt
Network Working Group
Internet Draft
Intended status: Informational Maria Napierala
Expires: May 2013 AT&T
Luyuan Fang
Cisco Systems
November 2012
Requirements for Extending BGP/MPLS VPNs to End-Systems
draft-fang-l3vpn-end-system-requirements-01.txt
Abstract
Service Providers commonly use BGP/MPLS VPNs [RFC 4364] as the
technology for providing wide-area virtual private network
services. This technology has proven to scale to a very large
number of VPNs and attachment points, and it is well suited for
extending VPN connectivity to end-systems operating in a multi-
tenant environments. Virtualized end-system environment imposes
additional requirements to MPLS/BGP VPN technology when applied to
end-system networking, which are defined in this document.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Napierala, Fang Expire May 2012 [Page 1]
Internet Draft November 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction 3
1.1. Terminology 3
2. Application of MPLS/BGP VPNs to End-Systems 4
2.1. End-System CE and PE Functions 4
2.2. PE Control Plane Function 5
3. VPN Communication Requirements 5
3.1. Unicast IPv4 and IPv6 5
3.2. Multicast/VPN Broadcast IPv4 and IPv6 5
3.3. IP Subnet Support 6
4. Multi-Tenancy Requirements 6
5. Decoupling of Virtualized Networking from Physical
Infrastructure 7
6. Decoupling of Layer 3 Virtualization from Layer 2 Topology 8
7. Requirements for Encapsulation of Virtual Payloads 8
7.1. Encapsulation Methods 9
7.2. Routing of Virtual Payloads 9
8. Optimal Forwarding of Traffic 10
9. IP Mobility 10
9.1. IP Addressing of Virtual Hosts 10
9.2. Network Layer-Based Mobility 11
9.3. Routing Convergence Requirements 11
10. Inter-operability with Existing MPLS/BGP VPNs 11
11. BGP Requirements in a Virtualized Environment 12
11.1. BGP Convergence and Routing Consistency 12
11.2. Optimization of Route Distribution 13
12. Security Considerations 13
13. IANA Considerations 14
14. Normative References 14
15. Informative References 14
16. Authors' Addresses 15
[Page 2]
Internet Draft November 2012
17. Acknowledgements 15
Requirements Language
Although this document is not a protocol specification, the key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [RFC
2119].
1. Introduction
Enterprise networks are increasingly being consolidated and
outsourced in an effort to improve the deployment time of services
as well as reduce operational costs. This coincides with an
increasing demand for compute, storage, and network resources from
applications.
In order to scale compute, storage, and network service functions,
physical resources are being abstracted from their logical
representation. This is referred as server, storage, and network
virtualization. Virtualization can be implemented in various layers
of computer systems or networks. The virtualized loads are executed
over a common physical infrastructure. Compute nodes running guest
operating systems are often executed as Virtual Machines (or VMs).
This document defines requirements for a network virtualization
solution that provides secure IP VPN connectivity to virtual
resources on end-systems operating in a multi-tenant shared
physical infrastructure. The requirements address the needs of
virtual resources, defined as Virtual Machines, applications, and
appliances that require only IP connectivity. Non-IP communication
is addressed by other solutions and is not in scope of this
document.
1.1. Terminology
AS Autonomous Systems
End-System A device where Guest OS and Host OS/Hypervisor reside
IaaS Infrastructure as a Service
RT Route Target
ToR Top-of-Rack switch
VM Virtual Machine
Hypervisor Virtual Machine Manager
SDN Software Defined Network
VPN Virtual Private Network
[Page 3]
Internet Draft November 2012
2. Application of MPLS/BGP VPNs to End-Systems
MPLS/BGP VPN technology [RFC 4364] have proven to be able to very
scale to a large number of VPNs (tens of thousands) and customer
routes (millions) while providing for aggregated management
capability. In traditional WAN deployments of BGP IP VPNs a
Customer Edge (CE) is a physical device, residing a customer's
location, connected to a Provider Edge (PE), residing in a Service
Provider's location. CE devices are logically part of a customer's
VPN while PE routers are logically part of the SP's network. In a
traditional MPLS/BGP VPN deployment, a CE device is a router and it
is a routing peer of a PE to which it is attached via an attachment
circuit.
In addition, the forwarding function and control function of a
Provider Edge (PE) device co-exist within a single physical router.
MPLS/BGP VPN technology can be evolved and adapted to new
virtualized environments by implementing the VPN edge functionality
of the PE line-cards on the end-system hosts and thereby extending
VPN service directly to end-systems.
2.1. End-System CE and PE Functions
When end-system attaches to MPLS/BGP VPN, CE corresponds to a non-
routing host that can reside in a Virtual Machine or be an
application residing on the end-system itself.
As in traditional MPLS/BGP VPN deployments, it is undesirable for
the end-system VPN forwarding knowledge to extend to the transport
network infrastructure. Hence, optimally, with regard to forwarding,
the end-system should become both the CE and the PE simultaneously.
The network virtualization solution should also support deployments
where it is not possible or not desirable to co-locate the PE and
CE functionality. In such deployments PE may be implemented on an
external device with remote CE attachments. This external PE device
should be as close as possible to the end-system where the CE
resides. The external PE devices that attach to a particular VPN,
need to know, for each attachment circuit leading to that VPN, the
host address that is reachable over that attachment circuit. The
end-system MPLS/BGP VPN solution must specify a method to convey
this information from the end-system to the PE.
[Page 4]
Internet Draft November 2012
The same network virtualization solution should support deployments
with mixed, internal (co-located with CE) and external PE (i.e.,
remote CE) implementations.
2.2. PE Control Plane Function
It is a current practice to implement MPLS/BGP VPN PE forwarding
and control functions in different processors of the same device
and to use internal (proprietary) communication between those
processors. Typically, the PE control functionality is implemented
in one (or very few) components of a device and the PE forwarding
functionality is implemented in multiple components of the same
device (a.k.a., "line cards").
In end-system environment, a single end-system, effectively,
corresponds to a line card in a traditional PE router. For scalable
and cost effective deployment of end-system MPLS/BGP VPNs the PE
forwarding function should be decoupled from PE control function
such that the former can be implemented on multiple standalone
devices. This separation of functionality will allow for
implementing the end-system PE forwarding on multiple end-system
devices, for example, in operating systems of application servers
or network appliances.
Moreover, the separation of PE forwarding and control plane
functions allows for the PE control plane function to be itself
virtualized and run as an application in end-system.
3. VPN Communication Requirements
3.1. Unicast IPv4 and IPv6
A network virtualization solution should be able to provide IPv4 and
IPv6 unicast connectivity between hosts in the same and different
subnets without any assumptions regarding the underlying media
layer.
3.2. Multicast/VPN Broadcast IPv4 and IPv6
Furthermore, the multicast transmission, i.e., allowing IP
applications to send packets to a group of IPv4 or IPv6 addresses
should be supported. The multicast service should also support a
delivery of traffic to all endpoints of a given VPN even if those
endpoints have not sent any control messages indicating the need to
receive that traffic. In other words, the multicast service should
[Page 5]
Internet Draft November 2012
be capable of delivering the IP broadcast traffic in a virtual
topology. A solution for supporting VPN multicast and VPN broadcast
must not require that the underlying transport network supports IP
multicast transmission service.
3.3. IP Subnet Support
In some deployments, Virtual Machines or applications are
configured to belong to an IP subnet. A network virtualization
solution should support grouping of virtual resources into IP
subnets regardless of whether the underlying implementation uses a
multi-access network or not. While some applications may expect to
find other peers in a particular user defined IP subnet, this does
not imply the need to provide a layer 2 service that preserves MAC
addresses. End-system network virtualization solution should be
able to provide IP (unicast, multicast, VPN broadcast) connectivity
between hosts in the same and different subnets without any
assumptions regarding the underlying media layer.
4. Multi-Tenancy Requirements
One of the main goals of network virtualization is to provide
traffic and routing isolation between different virtual components
that share a common physical infrastructure. Networks use various
VPN technologies to isolate disjoint groups of virtual resources.
Some use VLANs [IEEE.802-1Q] as a VPN technology, others use layer
3 based solutions, often with proprietary control planes. Service
Providers are interested in interoperability and in openly
documented protocols rather than in proprietary solutions.
A collection of virtual resources might provide external or
internal services. Such collection may serve an external "customer"
or internal "tenant" to whom a Service Provider provides
service(s). In MPLS/BGP VPN terminology a collection of virtual
resources dedicated to a process or application corresponds to a
VPN.
A network virtualization multi-tenancy solution should support the
following:
- Tenant or application isolation, in data plane and control plane,
while sharing the same underlying physical network. Tenants
should be able to independently select and deploy their choice of
IP address space: public or private IPv4 and/or IPv6.
[Page 6]
Internet Draft November 2012
- Multiple distinct VPNs per tenant. Tenant's inter-VPN traffic
should be allowed to cross VPN boundaries, subject to access
controls and/or routing policies.
- Inter-VPN communication, subject to access policies. Typically
VPNs that belong to different external tenants do not communicate
with each other directly but they should be allowed to access
shared services or shared network resources. It is often the case
that SP infrastructure services are provided to multiple tenants,
for example voice-over-IP gateway services or video-conferencing
services for branch offices.
- VM or application end-point should be able to directly access
multiple VPNs without a need to traverse a gateway.
End-system network virtualization solution should support both,
isolated VPNs as well as overlapping VPNs (often referred to as
"extranets"). It should also support any-to-any and hub-and-spoke
topologies.
5. Decoupling of Virtualized Networking from Physical
Infrastructure
One of the main goals in designing a large scale transport network
is to minimize the cost and complexity of its "fabric" by
delegating the virtual resource communication processing to the
network edge. It has been proven (in Internet and in large MPLS/BGP
VPN deployments) that moving complexity to network edge while
keeping network core simple has very good scaling properties.
The transport network infrastructure should not maintain any
information that pertains to the virtual resources in end-systems.
Decoupling of virtualized networking from the physical
infrastructure has the following advantages: 1) provides better
scalability; 2) simplifies the design and operation; 3) reduces
network cost.
Decoupling of virtualized networking from underlying physical
network consists in the following:
- Separation between the virtualized segments (i.e., interface
associated with virtual resources) and the physical network
(i.e., physical interfaces associated with network
infrastructure).
- Separation of the virtual network IP address space from the
physical infrastructure network IP address space. In the case of
[Page 7]
Internet Draft November 2012
a transport other than IP, for example MPLS or Ethernet, the
infrastructure address refers to the Subnetwork Point of
Attachment (SNPA) address in a given multi-access network.
- The physical infrastructure addresses should be routable (or
switchable) in the underlying transport network, while the
virtual network addresses should be routable only in the virtual
network.
- The virtual network control plane should be decoupled from the
underlying transport network.
6. Decoupling of Layer 3 Virtualization from Layer 2 Topology
The layer 3 approach to network virtualization dictates that the
virtualized communication should be routed, not bridged. The layer
3 virtualization solution should be decoupled from the layer 2
topology. Thus, there should be no dependency on VLANs and layer 2
broadcast.
In solutions that depend on layer 2 broadcast domains, host-to-host
communication is established based on flooding and data plane MAC
learning. Layer 2 MAC information has to be maintained on every
switch where a given VLAN is present. Even if some solutions are
able to minimize data plane MAC learning and/or unicast flooding,
they still rely on MAC learning at the network edge and on
maintaining the MAC addresses on every switch where the layer 2 VPN
is present.
The MAC addresses known to guest OS in end-system are not relevant
to IP services and introduce unnecessary overhead. Hence, the MAC
addresses associated with virtual resources should not be used in
the virtual layer 3 networks. Rather, only what is significant to
IP communication, namely the IP addresses of the virtual machines
and application endpoints should be maintained by the virtual
networks.
7. Requirements for Encapsulation of Virtual Payloads
In order to scale the transport networks, the virtual network
payloads must be encapsulated with headers that are routable (or
switchable) in the physical network infrastructure. The IP
addresses of the virtual resources are not to be advertized within
the physical infrastructure address space.
The encapsulation (and de-capsulation) function should be
implemented on a device as close to virtualized resources as
[Page 8]
Internet Draft November 2012
possible. Since the hypervisors in the end-systems are the devices
at the network edge they are the most optimal location for the
encap/decap functionality.
The network virtualization solution should also support deployments
where it is not possible or not desirable to implement the virtual
payload encapsulation in the hypervisor/Host OS. In such
deployments encap/decap functionality may be implemented in an
external device. The external device implementing encap/decap
functionality should be a close as possible to the end-system
itself. The same network virtualization solution should support
deployments with both, internal (in a hypervisor) and external
(outside of a hypervisor) encap/decap devices.
Whenever the virtual forwarding functionality is implemented in an
external device, the virtual service itself must be delivered to an
end-system such that switching elements connecting the end-system
to the encap/decap device are not aware of the virtual topology.
7.1. Encapsulation Methods
MPLS/VPN technology based on [RFC 4364] specifies that different
encapsulation methods could be for connecting PE routers, namely
Label Switched Paths (LSPs), IP tunneling, and GRE tunneling.
If LSPs are used in the transport network they could be signaled
with LDP, in which case host (/32) routes to all PE routers must be
propagated throughout the network, or with RSVP-TE, in which case a
full mesh of RSVP-TE tunnels is required.
If the transport network is only IP-capable then MPLS in IP or MPLS
in GRE [RFC4023] encapsulation could be used. Due to route
aggregation property of IP protocols, with IP/GRE encapsulation the
PE host routes do not have to be present in the transport network.
Multi-access technologies, especially Ethernet, may also need to be
supported as transport networks, for example, 802.1ah.
7.2. Routing of Virtual Payloads
A device implementing the encap/decap functionality acts as the
first-hop router in the virtual topology.
In a layer 3 end-system virtual network, IP packets should reach
the first-hop router in one IP-hop, regardless of whether the
first-hop router is an end-system itself (i.e., a hypervisor/Host
OS) or it is an external (to end-system) device. The first-hop
[Page 9]
Internet Draft November 2012
router should always perform an IP lookup on every packet it
receives from a virtual machine or an application. The first-hop
router should encapsulate the packets and route them towards the
destination end-system.
8. Optimal Forwarding of Traffic
The network virtualization solutions that optimize for the maximum
utilization of compute and storage resources require that those
resources may be located anywhere in the network. The physical and
logical spreading of appliances and workloads implies a very
significant increase in the infrastructure bandwidth consumption.
In order to be efficient in terms of traffic forwarding, the
virtualized networking solutions must assure that packets traverse
the transport network only once.
It must be also possible to send the traffic directly from one end-
system to another end-system without traversing through a midpoint
router.
9. IP Mobility
Another reason for a network virtualization is the need to support
IP mobility. IP mobility consists in IP addresses used for
communication within or between applications being located anywhere
across the virtual network. Using a virtual topology, i.e.,
abstracting the externally visible network address from the
underlying infrastructure address is an effective way to solve IP
mobility problem.
IP mobility consists in a device physically moving (e.g., a roaming
wireless device) or a workload being transferred from one physical
server/appliance to another. IP mobility requires preserving
device's active network connections (e.g., TCP and higher-level
sessions). Such mobility is also referred to as "live" migration
with respect to a Virtual Machine. IP mobility is highly desirable
for many reasons such as efficient and flexible resource sharing,
data center migration, disaster recovery, server redundancy, or
service bursting.
9.1. IP Addressing of Virtual Hosts
To accommodate live mobility of a virtual machine (or a device), it
is desirable to assign to it a semi-permanent IP address that
remains with the VM/device as it moves. The semi-permanent IP
[Page 10]
Internet Draft November 2012
address can be configured through VM configuration process or by
means of DHCP.
9.2. Network Layer-Based Mobility
When dealing with IP-only applications it is not only sufficient
but optimal to forward the traffic based on layer 3 (network layer)
rather than on layer 2 (data-link layer) information. The MAC
addresses of devices or applications are irrelevant to IP services
and introduce unnecessary overhead and complications when devices
or VMs move. For example, when a VM moves between physical servers,
the MAC learning tables in the switches must be updated. Moreover,
it is possible that VM's MAC address might need to change in its
new location. In IP-based network virtualization solution a device
or a workload move is handled by an IP route advertisement.
9.3. Routing Convergence Requirements
IP mobility has to be transparent to applications and any external
entity interacting with the applications. This implies that the
network connectivity restoration time is critical. The transport
sessions can typically survive over several seconds of disruption,
however, applications may have sub-second latency requirement for
their correct operation.
To minimize the disruption to established communication during
workload or device mobility, the control plane of a network
virtualization solution should be able to differentiate between the
activation of a workload in a new location from advertising its
route to the network. This will enable the remote end-points to
update their routing tables prior to workload's migration as well
as allowing the traffic to be tunneled via the workload's old
location.
10. Inter-operability with Existing MPLS/BGP VPNs
Service Providers want to tie their server-based offerings to their
MPLS/BGP VPN services. MPLS/BGP VPNs provide secure and latency-
optimized remote connectivity to the virtualized resources in SP's
data center. The Service Provider-based VPN access can provide
additional capabilities compared with public internet access, such
as QoS, OAM, multicast service, VoIP service, video conferencing,
wireless connectivity.
[Page 11]
Internet Draft November 2012
MPLS/BGP VPN customers may require simultaneous access to resources
in both SP and their own data centers.
Service Providers want to "spin up" the L3VPN access to data center
VPNs as dynamically as the spin up of compute and other virtualized
resources.
The network virtualization solution should be fully inter-operable
with MPLS/BGP VPNs, including:
- Inter-AS MPLS/BGP VPN Options A, B, and C [RFC 4364].
- BGP/MPLS VPN-capable network devices (such as routers and network
appliances) should be able to participate directly in a virtual
network that spans end-systems.
- The network devices should be able to participate in isolated
collections of end-systems, i.e., in isolated VPNs, as well as in
overlapping VPNs (called "extranets" in BGP/MPLS VPN
terminology).
- The network devices should be able to participate in any-to-any
and hub-and-spoke end-systems topologies.
When connecting an end-system VPN with other services/networks, it
should not be necessary to advertize the specific host routes but
rather the aggregated routing information. A BGP/MPLS VPN-capable
router or appliance can be used to aggregate VPN's IP routing
information and advertize the aggregated prefixes. The aggregated
prefixes should be advertized with the router/appliance IP address
as BGP next-hop and with locally assigned aggregate 20-bit label.
The aggregate label should trigger a destination IP lookup in its
corresponding VRF on all the packets entering the virtual network.
The inter-connection of end-system VPNs with traditional VPNs
requires an integrated control plane and unified orchestration of
network and end-system resources.
11. BGP Requirements in a Virtualized Environment
11.1. BGP Convergence and Routing Consistency
BGP was designed to carry very large amount of routing information
but it is not a very fast converging protocol. In addition, the
routing protocols, including BGP, have traditionally favored
convergence (i.e., responsiveness to route change due to failure or
policy change) over routing consistency. Routing consistency means
[Page 12]
Internet Draft November 2012
that a router forwards a packet strictly along the path adopted by
the upstream routers. When responsiveness is favored, a router
applies a received update immediately to its forwarding table
before propagating the update to other routers, including those
that potentially depend upon the outcome of the update. The route
change responsiveness comes at the cost of routing blackholes and
loops.
Routing consistency in virtualized environments is important
because multiple workloads can be simultaneously moved between
different physical servers due to maintenance activities, for
example. If packets sent by the applications that are being moved
are dropped (because they do not follow a live path), the active
network connections will be dropped. To minimize the disruption to
the established communications during VM migration or device
mobility, the live path continuity is required.
11.1.1. BGP IP Mobility Requirements
In IP mobility, the network connectivity restoration time is
critical. In fact, Service Provider networks already use routing
and forwarding plane techniques that support fast failure
restoration by pre-installing a backup path to a given destination.
These techniques allow to forward traffic almost continuously using
an indirect forwarding path or a tunnel to a given destination, and
hence, are referred to as "local repair". The traffic path is
restored locally at the destination's old location while the
network converges to a backup path. Eventually, the network
converges to an optimal path and bypasses the local repair.
BGP assists in the local repair techniques by advertizing multiple
and not only the best path to a given destination.
11.2. Optimization of Route Distribution
When virtual networks are triggered based on the IP communication,
the Route Target Constraint extension [RFC 4684] of BGP should be
used to optimize the route distribution for sparse virtual network
events. This technique ensures that only those VPN forwarders that
have local participants in a particular data plane event receive
its routing information. This also decreases the total load on the
upstream BGP speakers.
12. Security Considerations
[Page 13]
Internet Draft November 2012
The document presents the requirements for end-systems MPLS/BGP
VPNs. The security considerations for traditional MPLS/BGP VPN
deployments are described in [RFC 4364] in Section 13. The
additional security issues associated with deployments using MPLS-
in-GRE or MPLS-in-IP encapsulations are described in [RFC4023] in
Section 8.
The additional security requirements specific to end-system
MPLS/BGP VPNs are as follows:
- End-systems MPLS/BGP VPNs solution should guarantee that packets
originating from a specific end-system virtual interface are
accepted only if the corresponding VPN IP host is present on that
end-system.
- Virtual network must ensure that traffic arriving at the egress
end-system is being sent from the correct ingress end-system.
- One virtual host or VM should not be able to impersonate another,
during steady-state operation and during live migration.
The security considerations for specific solutions will be
documented in the relevant documents.
13. IANA Considerations
This document contains no new IANA considerations.
14. Normative References
[RFC 4363] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC 4023] Worster, T., Rekhter, Y. and E. Rosen, "Encapsulating
in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March
2005.
[RFC 4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K. and J. Guichard, "Constrained Route Distribution for
Border Gateway Protocol/Multiprotocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
November 2006.
15. Informative References
[Page 14]
Internet Draft November 2012
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IEEE.802-1Q] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", IEEE Std 802.1Q-2005, May 2006.
16. Authors' Addresses
Maria Napierala
AT&T
200 Laurel Avenue
Middletown, NJ 07748
Email: mnapierala@att.com
Luyuan Fang
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830, USA
Email: lufang@cisco.com
17. Acknowledgements
The authors would like to thank Pedro Marques and Han Nguyen for
the comments and suggestions.
[Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 01:12:47 |