Cisco IOS MPLS Virtual Private LAN Service(VPLS): Q&A
Cisco IOS MPLS
Virtual Private LAN Service
Q. What is VPLS?
A. VPLS stands for Virtual Private LAN Service, and is a VPN technology that enables Ethernet multipoint services (EMSs) over a packet-switched network infrastructure. VPN users get an emulated LAN segment that offers a Layer 2 broadcast domain. The end user perceives the service as a virtual private Ethernet switch that forwards frames to their respective destinations within the VPN. Ethernet is the technology of choice for LANs due to its relative low cost and simplicity. Ethernet has also gained recent popularity as a metropolitan-area network (MAN or metro) technology.
VPLS helps extend the reach of Ethernet further to be used as a WAN technology. Other technologies also enable Ethernet across the WAN, Ethernet over Multiprotocol Label Switching (MPLS), Ethernet over SONET/SDH, Ethernet bridging over ATM, and ATM LAN emulation (LANE). However, they only provide point-to-point connectivity and their mass deployment is limited by high levels of complexity, or they require dedicated network architectures that do not facilitate network convergence. Figure 1 shows the logical view of a VPLS connecting three sites. Each customer edge device requires a single connection to the network to get full connectivity to the remaining sites.
Figure 1
Logical View of a VPLS
Q. What does it mean that VPLS enables an EMS?
A. A multipoint technology allows a user to reach multiple destinations through a single physical or logical connection. This requires the network to make a forwarding decision based on the destination of the packet. Within the context of VPLS, this means that the network makes a forwarding decision based on the destination MAC address of the Ethernet frame. A multipoint service is attractive because less connections are required to achieve full connectivity between multiple points. An equivalent level of connectivity based on a point-to-point technology requires a much larger number of connections or the use of suboptimal packet forwarding.
Q. What are the main components of VPLS?
A. In its simplest form, a VPLS consists of several sites connected to provider edge devices implementing the emulated LAN service. These provider edge devices make the forwarding decisions between sites and encapsulate the Ethernet frames across a packet-switched network using a virtual circuit or pseudo wire. A virtual switching instance (VSI) is used at each provider edge to implement the forwarding decisions of each VPLS. The provider edges use a full mesh of Ethernet emulated circuits (or pseudowires) to forward the Ethernet frames between provider edges. Figure 2 illustrates the components of a VPLS that connects three sites.
Figure 2
VPLS Components
Q. How are packets forwarded in VPLS?
A. Ethernet frames are switched between provider edge devices using the VSI forwarding information. Provider edge devices acquire this information using the standard MAC address learning and aging functions used in Ethernet switching. The VSI forwarding information is updated with the MAC addresses learned from physical ports and other provider edge devices via virtual circuits. These functions imply that all broadcast, multicast, and destination-unknown MAC addresses are flooded over all ports and virtual circuits associated with a VSI. Provider edge devices use split-horizon forwarding on the virtual circuits to form a loop-free topology. In this way, the full mesh of virtual circuits provides direct connectivity between the provider edge devices in a VPLS, and no protocols have to be used to generate a loop-free topology (Spanning Tree Protocol, for example).
Q. What are the signaling requirements of VPLS?
A. Two functional components in VPLS involve signaling—provider edge discovery and virtual circuit setup. Cisco® VPLS currently relies on static configuration of provider edge associations within a VPLS. However, the architecture can be easily enhanced to support several discovery protocols, including Border Gateway Protocol (BGP), RADIUS, Label Distribution Protocol (LDP), or Domain Name System (DNS). The virtual circuit setup uses the same LDP signaling mechanism defined for point-to-point services. Using a directed LDP session, each provider edge advertises a virtual circuit label mapping that is used as part of the label stack imposed on the Ethernet frames by the ingress provider edge during packet forwarding.
Q. How is reachability information distributed in a VPLS?
A. Cisco VPLS does not require the exchange of reachability (MAC addresses) information via a signaling protocol. This information is learned from the data plane using standard address learning, aging, and filtering mechanisms defined for Ethernet bridging. However, the LDP signaling used for setting up and tearing down the virtual circuits can be used to indicate to a remote provider edge that some or all MAC addresses learned over a virtual circuit need to be withdrawn from the VSI. This mechanism provides a convergence optimization over the normal address aging that would eventually flush the invalid addresses.
Q. Can VPLS be implemented over any packet network?
A. VPLS has been initially specified and implemented over an MPLS transport. From a purely technical point of view, the provider edge devices implementing VPLS could also transport the Ethernet frames over an IP backbone using different encapsulations, including generic routing encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec).
Q. Are there any differences in the encapsulation of Ethernet frames across the packet network between VPLS and Any Transport over MPLS (AToM)?
A. No. VPLS relies on the same encapsulation defined for point-to-point Ethernet over MPLS. The frame preamble and frame check sequence (FCS) are removed, and the remaining payload is encapsulated with a control word, a virtual circuit label, and an Interior Gateway Protocol (IGP) or transport label.
Q. Is VPLS limited to Ethernet?
A. Even though most VPLS sites are expected to connect via Ethernet, they may connect using other Layer 2 technologies (ATM, Frame Relay, or Point-to-Point Protocol [PPP], for example). Sites connecting with non-Ethernet links exchange packets with the provider edge using a bridged encapsulation. The configuration requirements on the customer edge device are similar to the requirements for Ethernet Interworking in point-to-point Layer 2 services.
Q. Are there any scalability concerns with VPLS?
A. Packet replication and the amount of address information are the two main scaling concerns for the provider edge device. When packets need to be flooded (because of broadcast, multicast, or destination-unknown unicast address), the ingress provider edge needs to perform packet replication. As the number of provider edge devices in a VPLS increases, the number of packet copies that need to be generated increases. Depending on the hardware architecture, packet replication can have an important impact on processing and memory resources. In addition, the number of MAC addresses that may be learned from the data plane may grow rapidly if many hosts connect to the VPLS. This situation can be alleviated by avoiding large, flat, network domains in the VPLS.
Q. What is hierarchical VPLS?
A. A hierarchical model can be used to improve the scalability characteristics of VPLS. Hierarchical VPLS (H-VPLS) reduces signaling overhead and packet replication requirements for the provider edge. Two types of provider edge devices are defined in this model—user-facing provider edge (u-PE) and network provider edge (n-PE). Customer edge devices connect to u-PEs directly and aggregate VPLS traffic before it reaches the n-PE, where the VPLS forwarding takes place based on the VSI. In this hierarchical model, u-PEs are expected to support Layer 2 switching and to perform normal bridging functions. Cisco VPLS uses 802.1Q Tunneling, a double 802.1Q or Q-in-Q encapsulation, to aggregate traffic between the u-PE and n-PE. The Q-in-Q trunk becomes an access port to a VPLS instance on an n-PE (Figure 3).
Figure 3
Hierarchical VPLS
Q. How does VPLS fit with metro Ethernet?
A. VPLS can play an important role to scale metro Ethernet services by increasing geographical coverage and service capacity. The H-VPLS model allows service providers to interconnect dispersed metro Ethernet domains to extend the geographical coverage of the Ethernet service. H-VPLS helps scale metro Ethernet services beyond the 4000-subscriber limit imposed by the VLAN address space. Conversely, having an Ethernet access network contributes to the scalability of VPLS by distributing packet replication and reducing signaling requirements. Metro Ethernet and VPLS are complementary technologies that enable more sophisticated Ethernet service offerings.
Q. Is Cisco VPLS standards-based?
A. Cisco VPLS is based on the IETF draft draft-ietf-pppvpn-vpls-ldp, which has wide industry support. VPLS specifications are still under development at the IETF. There are two proposed VPLS drafts (draft-ietf-pppvpn-vpls-ldp and draft-ietf-l2vpn-vpls-bgp). There are no current plans to support both drafts.
Q. How does VPLS compare with Cisco AToM?
A. Cisco AToM provides a standards-based implementation that enables point-to-point Layer 2 services. VPLS complements the portfolio of Layer 2 services with a multipoint offering based on Ethernet. These two kinds of services impose different requirements for the provider edge devices. A point-to-point service relies on a virtual circuit (or pseudowire) that provider edges set up to transport Layer 2 frames between two attachment circuits. The mapping between attachment circuits and virtual circuits is static and one-to-one. A multipoint service requires the provider edge to perform a lookup on the frame contents (typically, MAC addresses) to determine the virtual circuit to be used to forward the frame to the destination. This lookup creates the multipoint nature of a VPLS. The virtual circuit signaling and encapsulation characteristics performed by the provider devices are the same. The operation of provider edge devices is transparent from the type of service implemented by the devices.
Q. How does VPLS compare with MPLS VPNs?
A. VPLS and MPLS (Layer 3) VPN enable two very different services. VPLS offers a multipoint Ethernet service that can support multiple higher-level protocols. MPLS VPN also offers a multipoint service, but it is limited to the transport of IP traffic and all traffic that can be carried over IP. Both VPLS and MPLS VPN support multiple link technologies for the customer edge to provider edge connection (Ethernet, Frame Relay, ATM, PPP, and so on). VPLS, however, imposes additional requirements (bridged encapsulation) on the customer edge devices in order to support non-Ethernet links. MPLS VPN reduces the amount of IP routing design and operation required from the VPN user. VPLS leaves full control of IP routing to the VPN user. VPLS and MPLS VPN are two alternatives to implement a VPN. The selection of the appropriate VPN technology requires analysis of the specific service requirements of the VPN customer.
Q. Does VPLS preclude the use of the same network infrastructure for services such as Layer 3 VPNs (L3VPNs), point-to-point Layer 2 VPNs (L2VPNs), and Internet services?
A. No. MPLS allows service providers to deploy a converged network infrastructure that supports multiple services. Provider edge devices are required to implement the signaling and encapsulation requirements for any specific service. However, those devices do not have to be dedicated to a single service. Furthermore, the provider devices in the core of the network do not need to be aware of the service a packet is associated with. Provider devices are service- and customer-agonistic, giving the MPLS backbone unique scalability characteristics.
Q. Where can I find additional information on VPLS?
A. The following links provide additional information.
Cisco IOS® MPLS Page
http://www.cisco.com/en/US/tech/tk436/tk891/tech_protocol_family_home.html
http://www.cisco.com/en/US/products/hw/routers/ps368/products_white_paper09186a00801df1df.shtml
http://www.cisco.com/en/US/products/hw/routers/ps368/index.html
Virtual Private LAN Service
Q. What is VPLS?
A. VPLS stands for Virtual Private LAN Service, and is a VPN technology that enables Ethernet multipoint services (EMSs) over a packet-switched network infrastructure. VPN users get an emulated LAN segment that offers a Layer 2 broadcast domain. The end user perceives the service as a virtual private Ethernet switch that forwards frames to their respective destinations within the VPN. Ethernet is the technology of choice for LANs due to its relative low cost and simplicity. Ethernet has also gained recent popularity as a metropolitan-area network (MAN or metro) technology.
VPLS helps extend the reach of Ethernet further to be used as a WAN technology. Other technologies also enable Ethernet across the WAN, Ethernet over Multiprotocol Label Switching (MPLS), Ethernet over SONET/SDH, Ethernet bridging over ATM, and ATM LAN emulation (LANE). However, they only provide point-to-point connectivity and their mass deployment is limited by high levels of complexity, or they require dedicated network architectures that do not facilitate network convergence. Figure 1 shows the logical view of a VPLS connecting three sites. Each customer edge device requires a single connection to the network to get full connectivity to the remaining sites.
Figure 1
Logical View of a VPLS
Q. What does it mean that VPLS enables an EMS?
A. A multipoint technology allows a user to reach multiple destinations through a single physical or logical connection. This requires the network to make a forwarding decision based on the destination of the packet. Within the context of VPLS, this means that the network makes a forwarding decision based on the destination MAC address of the Ethernet frame. A multipoint service is attractive because less connections are required to achieve full connectivity between multiple points. An equivalent level of connectivity based on a point-to-point technology requires a much larger number of connections or the use of suboptimal packet forwarding.
Q. What are the main components of VPLS?
A. In its simplest form, a VPLS consists of several sites connected to provider edge devices implementing the emulated LAN service. These provider edge devices make the forwarding decisions between sites and encapsulate the Ethernet frames across a packet-switched network using a virtual circuit or pseudo wire. A virtual switching instance (VSI) is used at each provider edge to implement the forwarding decisions of each VPLS. The provider edges use a full mesh of Ethernet emulated circuits (or pseudowires) to forward the Ethernet frames between provider edges. Figure 2 illustrates the components of a VPLS that connects three sites.
Figure 2
VPLS Components
Q. How are packets forwarded in VPLS?
A. Ethernet frames are switched between provider edge devices using the VSI forwarding information. Provider edge devices acquire this information using the standard MAC address learning and aging functions used in Ethernet switching. The VSI forwarding information is updated with the MAC addresses learned from physical ports and other provider edge devices via virtual circuits. These functions imply that all broadcast, multicast, and destination-unknown MAC addresses are flooded over all ports and virtual circuits associated with a VSI. Provider edge devices use split-horizon forwarding on the virtual circuits to form a loop-free topology. In this way, the full mesh of virtual circuits provides direct connectivity between the provider edge devices in a VPLS, and no protocols have to be used to generate a loop-free topology (Spanning Tree Protocol, for example).
Q. What are the signaling requirements of VPLS?
A. Two functional components in VPLS involve signaling—provider edge discovery and virtual circuit setup. Cisco® VPLS currently relies on static configuration of provider edge associations within a VPLS. However, the architecture can be easily enhanced to support several discovery protocols, including Border Gateway Protocol (BGP), RADIUS, Label Distribution Protocol (LDP), or Domain Name System (DNS). The virtual circuit setup uses the same LDP signaling mechanism defined for point-to-point services. Using a directed LDP session, each provider edge advertises a virtual circuit label mapping that is used as part of the label stack imposed on the Ethernet frames by the ingress provider edge during packet forwarding.
Q. How is reachability information distributed in a VPLS?
A. Cisco VPLS does not require the exchange of reachability (MAC addresses) information via a signaling protocol. This information is learned from the data plane using standard address learning, aging, and filtering mechanisms defined for Ethernet bridging. However, the LDP signaling used for setting up and tearing down the virtual circuits can be used to indicate to a remote provider edge that some or all MAC addresses learned over a virtual circuit need to be withdrawn from the VSI. This mechanism provides a convergence optimization over the normal address aging that would eventually flush the invalid addresses.
Q. Can VPLS be implemented over any packet network?
A. VPLS has been initially specified and implemented over an MPLS transport. From a purely technical point of view, the provider edge devices implementing VPLS could also transport the Ethernet frames over an IP backbone using different encapsulations, including generic routing encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec).
Q. Are there any differences in the encapsulation of Ethernet frames across the packet network between VPLS and Any Transport over MPLS (AToM)?
A. No. VPLS relies on the same encapsulation defined for point-to-point Ethernet over MPLS. The frame preamble and frame check sequence (FCS) are removed, and the remaining payload is encapsulated with a control word, a virtual circuit label, and an Interior Gateway Protocol (IGP) or transport label.
Q. Is VPLS limited to Ethernet?
A. Even though most VPLS sites are expected to connect via Ethernet, they may connect using other Layer 2 technologies (ATM, Frame Relay, or Point-to-Point Protocol [PPP], for example). Sites connecting with non-Ethernet links exchange packets with the provider edge using a bridged encapsulation. The configuration requirements on the customer edge device are similar to the requirements for Ethernet Interworking in point-to-point Layer 2 services.
Q. Are there any scalability concerns with VPLS?
A. Packet replication and the amount of address information are the two main scaling concerns for the provider edge device. When packets need to be flooded (because of broadcast, multicast, or destination-unknown unicast address), the ingress provider edge needs to perform packet replication. As the number of provider edge devices in a VPLS increases, the number of packet copies that need to be generated increases. Depending on the hardware architecture, packet replication can have an important impact on processing and memory resources. In addition, the number of MAC addresses that may be learned from the data plane may grow rapidly if many hosts connect to the VPLS. This situation can be alleviated by avoiding large, flat, network domains in the VPLS.
Q. What is hierarchical VPLS?
A. A hierarchical model can be used to improve the scalability characteristics of VPLS. Hierarchical VPLS (H-VPLS) reduces signaling overhead and packet replication requirements for the provider edge. Two types of provider edge devices are defined in this model—user-facing provider edge (u-PE) and network provider edge (n-PE). Customer edge devices connect to u-PEs directly and aggregate VPLS traffic before it reaches the n-PE, where the VPLS forwarding takes place based on the VSI. In this hierarchical model, u-PEs are expected to support Layer 2 switching and to perform normal bridging functions. Cisco VPLS uses 802.1Q Tunneling, a double 802.1Q or Q-in-Q encapsulation, to aggregate traffic between the u-PE and n-PE. The Q-in-Q trunk becomes an access port to a VPLS instance on an n-PE (Figure 3).
Figure 3
Hierarchical VPLS
Q. How does VPLS fit with metro Ethernet?
A. VPLS can play an important role to scale metro Ethernet services by increasing geographical coverage and service capacity. The H-VPLS model allows service providers to interconnect dispersed metro Ethernet domains to extend the geographical coverage of the Ethernet service. H-VPLS helps scale metro Ethernet services beyond the 4000-subscriber limit imposed by the VLAN address space. Conversely, having an Ethernet access network contributes to the scalability of VPLS by distributing packet replication and reducing signaling requirements. Metro Ethernet and VPLS are complementary technologies that enable more sophisticated Ethernet service offerings.
Q. Is Cisco VPLS standards-based?
A. Cisco VPLS is based on the IETF draft draft-ietf-pppvpn-vpls-ldp, which has wide industry support. VPLS specifications are still under development at the IETF. There are two proposed VPLS drafts (draft-ietf-pppvpn-vpls-ldp and draft-ietf-l2vpn-vpls-bgp). There are no current plans to support both drafts.
Q. How does VPLS compare with Cisco AToM?
A. Cisco AToM provides a standards-based implementation that enables point-to-point Layer 2 services. VPLS complements the portfolio of Layer 2 services with a multipoint offering based on Ethernet. These two kinds of services impose different requirements for the provider edge devices. A point-to-point service relies on a virtual circuit (or pseudowire) that provider edges set up to transport Layer 2 frames between two attachment circuits. The mapping between attachment circuits and virtual circuits is static and one-to-one. A multipoint service requires the provider edge to perform a lookup on the frame contents (typically, MAC addresses) to determine the virtual circuit to be used to forward the frame to the destination. This lookup creates the multipoint nature of a VPLS. The virtual circuit signaling and encapsulation characteristics performed by the provider devices are the same. The operation of provider edge devices is transparent from the type of service implemented by the devices.
Q. How does VPLS compare with MPLS VPNs?
A. VPLS and MPLS (Layer 3) VPN enable two very different services. VPLS offers a multipoint Ethernet service that can support multiple higher-level protocols. MPLS VPN also offers a multipoint service, but it is limited to the transport of IP traffic and all traffic that can be carried over IP. Both VPLS and MPLS VPN support multiple link technologies for the customer edge to provider edge connection (Ethernet, Frame Relay, ATM, PPP, and so on). VPLS, however, imposes additional requirements (bridged encapsulation) on the customer edge devices in order to support non-Ethernet links. MPLS VPN reduces the amount of IP routing design and operation required from the VPN user. VPLS leaves full control of IP routing to the VPN user. VPLS and MPLS VPN are two alternatives to implement a VPN. The selection of the appropriate VPN technology requires analysis of the specific service requirements of the VPN customer.
Q. Does VPLS preclude the use of the same network infrastructure for services such as Layer 3 VPNs (L3VPNs), point-to-point Layer 2 VPNs (L2VPNs), and Internet services?
A. No. MPLS allows service providers to deploy a converged network infrastructure that supports multiple services. Provider edge devices are required to implement the signaling and encapsulation requirements for any specific service. However, those devices do not have to be dedicated to a single service. Furthermore, the provider devices in the core of the network do not need to be aware of the service a packet is associated with. Provider devices are service- and customer-agonistic, giving the MPLS backbone unique scalability characteristics.
Q. Where can I find additional information on VPLS?
A. The following links provide additional information.
Cisco IOS® MPLS Page
http://www.cisco.com/en/US/tech/tk436/tk891/tech_protocol_family_home.html
http://www.cisco.com/en/US/products/hw/routers/ps368/products_white_paper09186a00801df1df.shtml
http://www.cisco.com/en/US/products/hw/routers/ps368/index.html
Comments