Challenges with All-Ethernet Metro Networks
All-Ethernet metro networks pose many scalability and reliability challenges. The following are some of the issues that arise with an all-Ethernet control plane:
Restrictions on the number of customers
Service monitoring
Scaling the L2 backbone
Service provisioning
Interworking with legacy deployments
The following sections describe each of these challenges.
Restrictions on the Number of Customers
The Ethernet control plane restricts the carrier to 4096 customers, because the 802.1Q defines 12 bits that can be used as a VLAN ID, which restricts the number of VLANs to 212 = 4096. Remember that although Q-in-Q allows the customer VLANs (CE-VLANs) to be hidden from the carrier network, the carrier is still restricted to 4096 VLAN IDs that are global within its network. For many operators that are experimenting with the metro Ethernet service, the 4096 number seems good enough for an experimental network but presents a long-term roadblock if the service is to grow substantially.
Service Monitoring
Ethernet does not have an embedded mechanism that lends to service monitoring. With Frame Relay LMI, for example, service monitoring and service integrity are facilitated via messages that report the status of the PVC. Ethernet service monitoring requires additional control-plane intelligence. New Link Management Interface (LMI) protocols need to be defined and instituted between the service provider network and the CPE to allow the customer to discover the different EVCs that exist on the UNI connection. The LMI could learn the CE-VLAN to EVC map and could learn the different service parameters such as bandwidth profiles. Other protocols need to be defined to discover the integrity of the EVC in case of possible failures. You have seen in the previous section how performance parameters could indicate the availability of an EVC. Protocols to extract information from the UNI and EVC are needed to make such information usable.
Scaling the L2 Backbone
A metro carrier that is building an all-Ethernet network is at the mercy of STP. STP blocks Ethernet ports to prevent network loops. Traffic engineering (discussed in Chapter 5, "MPLS Traffic Engineering") is normally a major requirement for carriers to have control over network bandwidth and traffic trajectory. It would seem very odd for any carrier to have the traffic flow in its network be dependant on loop prevention rather than true bandwidth-optimization metrics.
Service Provisioning
Carrying a VLAN through the network is not a simple task. Any time a new carrier VLAN is created (a new VPN), care must be taken to configure that VLAN across all switches that need to participate in that VPN. The lack of any signaling protocols that allow VPN information to be exchanged makes the task manual and tedious. Early adopters of metro Ethernet have endured the pains of carrying VLANs across many switches. Even with the adoption of new protocols such as 802.1s ("Amendment to 802.1Q (TM) Virtual Bridged Local Area Networks: Multiple Spanning Trees"), the task of scaling the network is almost impossible.
Interworking with Legacy Deployments
Another challenge facing Ethernet deployments is interworking with legacy deployments such as existing Frame Relay and ATM networks. Frame Relay has been widely deployed by many enterprises as a WAN service. Remote offices are connected to headquarters via P2P Frame Relay circuits forming a hub-and-spoke topology. Enterprises that want to adopt Ethernet as an access technology expect the carrier to provide a means to connect the new sites enabled with Ethernet access with existing headquarters sites already enabled with Frame Relay. This means that a function must exist in the network that enables Frame Relay and Ethernet services to work together.
The IETF has standardized in RFC 2427, Multiprotocol Interconnect over Frame Relay, how to carry different protocols over Frame Relay, including Ethernet. In some other cases, the Ethernet and Frame Relay access networks are connected by an ATM core network. In this case, two service-interworking functions need to happen, one between Ethernet and ATM and another between ATM and Frame Relay. Ethernet-to-ATM interworking is achieved using RFC 2684, and ATM-to-Frame Relay interworking is achieved via the Frame Relay Forum specification FRF 8.1. Figure 3-10 illustrates the service-interworking functions.
)
Figure
3-10 Service Interworking
Figure 3-10 shows a scenario in which an enterprise headquarters is connected to its remote sites via Frame Relay connections carried over an ATM network. The different service-interworking functions are displayed to allow such networks to operate. For service interworking, two encapsulation methods are defined: one is bridged, and the other is routed. Both sides of the connection are either bridged or routed. Some challenges might exist if one end of the connection is connected to a LAN switch, and hence bridged, while the other end is connected to a router. Other issues will arise because of the different Address Resolution Protocol (ARP) formats between the different technologies, such as Ethernet, Frame Relay, and ATM. Some vendors are attempting to solve these problems with special software enhancements; however, such practices are still experimental and evolving.
It is all these challenges that motivated the emergence of hybrid architectures consisting of multiple L2 domains that are connected via L3 IP/MPLS cores. The network can scale because L2 Ethernet would be constrained to more-controlled access deployments that limit the VLAN and STP inefficiencies. The network can then be scaled by building a reliable IP/MPLS core. This is discussed in Chapter 4, "Hybrid L2 and L3 IP/MPLS Networks."