Tutorial on VLANs: Part 2

In Part 1 of this article, we looked at the different flavors of VLANs available today and at the key building blocks, such as tags and identifiers, that make a VLAN work. Now, in Part 2, we'll further the discussion by examining the generic attribute registration protocol (GARP) as well as GARP VLAN registration protocol (GVRP). We'll also look at two emerging VLAN technologies: VLAN stacking and virtual private LAN services (VPLS).

Understanding GARP
A LAN supports heterogeneous devices that each use different types of applications. It is difficult for the network manager to configure all the devices and the applications carefully. It is easier if the configuration is restricted to a few devices and applications and the remaining devices or applications learn the required information dynamically. The IEEE 802.1D MAC bridges defines GARP as a solution to this requirement.

GARP has been defined to enable any group of applications that share a common attribute to declare and register their state information related to the attribute. Two applications that make use of the GARP are a) Multicast group information exchanges with the help of GARP multicast registration protocol (GMRP) and b) GARP VLAN registration protocol (GVRP).

A GARP applicant may or may not choose to actively involve in declaring and registering the attribute value. By declaring an attribute A, a GARP applicant indicates to the other applicants that it is associated with attribute A or it is interested to know about other applicants association with the attribute A.

A GARP applicant registers an attribute A, when it is knows that there are applicants (including itself) associated with the attribute A. GARP messages JoinEmpty and JoinIn are used by an applicant to declare an attribute. Reception of a JoinIn messages from other applicants or transmission of Join messages by the applicant enables an applicant to register the attribute.

A GARP applicant uses LeaveEmpty or LeaveIn messages to withdraw its declaration when it is no more associated with an attribute. Periodic declarations and registration maintenance is done with the help of LeaveAll GARP message. An applicant periodically sends LeaveAll messages which enable other applicants to indicate their attributes registered states.

A GARP applicant that actively declares attributes is known as a member while an applicant that does not declare but act upon received attribute information and registers the attributes is known as an observer. In the case of GVRP, a VLAN Bridge (VBridge) that shares statically configured VLAN information is a member while a VBridge that receives the GVRP protocol data units (PDUs) and becomes aware of its VLAN membership is an observer.

A GARP applicant is known as an active member when the member initiates GARP PDUs for an attribute say "A". A new applicant that joins the network, interested in attribute A will not initiate GARP PDUs for the attribute when it is aware that there exist other applicants for attribute A and they have registered this attribute. This new member is known as a passive member. A passive member becomes an active member when it initiates GARP PDUs for registering the member's associated attribute information.

A GARP active member, when it decides to get disassociated with an attribute, withdraws its declaration for that attribute. The ability to dynamically declare and withdraw enables the GARP applicant devices to modify their behavior associated with the attribute.

The GARP messages are sent as either untagged or tagged MAC data frames (Figure 1). The GVRP messages are always sent as untagged data frames. The GMRP messages sent in multiple spanning trees context are sent as tagged data frames with tag value matching the associated VID. Otherwise they are sent as untagged data frames. GARP messages are sent to specific multicast MAC addresses. The destination MAC address for GMRP and GVRP messages are 01:80:c2:00:00:20 and 01:80:c2:00:00:21 respectively.

GARP implementation consists of three state machines (tables) along with three timers. The three state machines are applicant state, registrar state, and LeaveAll state machines. The timers are denoted as Join, Leave and LeaveAll.

The registrar state machine maintains the registration state of an attribute. If an attribute is registered or un-registered, the state will be "IN" or "MT" respectively. If the attribute had been registered and is being withdrawn, the state will be "LV".

A JoinIn or JoinEmpty message reception causes the Registrar state to move to "IN" state. A LeaveAll or Leave message reception in "IN" state causes state transition to "LV" state. Other GARP messages have no effect on other states.

When the registrar state transitions from the "IN" to "LV" state, the leave timer is started. At the end of the leave timer period (1 second), the registrar transitions to "MT" state.

Applicant State Machine
The applicant state machine enables the GARP applicant to ensure that all other applicants have registered this applicant's declaration of an attribute while ensuring that other applicants declare whenever required to maintain the registration of an attribute. An active member declares attribute(s) with the help of JoinIn or JoinEmpty messages.

GARP has been designed to handle single message loss namely, if two Join messages are sent by an applicant — at least one Join message is expected to be received by all other participants and the attribute get registered. An applicant can be sure that an attribute value is registered if the applicant sends two Join messages, sends one Join message and receives one JoinIn message, or receives two JoinIn messages.

When two Join messages are sent, the second message is sent after a Join time interval (200 ms). If no messages have been sent or JoinIns received, an applicant is said to be a very anxious applicant. If either one Join message is sent or one JoinIn is received, an applicant is said to be an anxious applicant. If either two Join messages are sent or one Join message is sent and one JoinIn message is received or two JoinIn messages are received, an applicant is said to be a quiet applicant.

An active member applicant present in either very anxious or anxious state will send out join messages. Combining the active member, passive member, observer, and receiving leave messages, there are multiple combinations of Applicant states, as shown in Table 1. The applicant state transitions are based on the transmission and reception of the GARP PDUs.

The LeaveAll state machine is used to constantly refresh the registrations by prompting declarations from the participants. This state machine uses LeaveAll timer. At every LeaveAll timer period (10 seconds) a LeaveAll message is generated which triggers the appropriate participants to declare their attributes with Join messages.

Understanding GVRP
GVRP enables VLAN Bridges to dynamically learn their VLAN membership. It is sufficient that an administrator configures the minimum VLAN configuration at a bridge. This configuration must ensure that:

• Required VLANs are enabled at the bridge level
• Member ports are added as either tagged or untagged members based on the confirmed reachability of VLAN aware/un-aware devices
• GVRP is enabled/disabled
• Dynamic VLAN registration is enabled/disabled by processing the received GVRP messages

Figure 2 illustrates the GVRP exchanges and Table 2 provides the dynamic VLAN registrations at the VLAN network bridges shown in Figure 2 from Part 1. Note, the timescale used to indicate the GVRP messages has been drawn to explain the PDU exchanges. Additionally note that some GVRP implementations might be different from the given illustration.

Table 2 provides VLAN status information at the three VLAN Bridges. Snapshots of the VLAN registration information based on the GVRP PDUs are captured at t0, t8, t12 and t15. The notation VLAN_x (Px,Py) indicates the VLAN enabled at the bridge level and the associated member ports in the VBridge.

Emerging VLAN Solutions
Two emerging solutions enable LANs to spread across geographies transparently. The first solution is Q-in-Q, otherwise known as VLAN stacking, while the second is known as virtual private LAN services (VPLS). Let's look at both in more detail.

1. VLAN Stacking
IEEE 802.1ad (provider bridges) enables the service provider to use Layer 2 (bridging and VLAN) protocols and solutions in their networks to connect the customer sites. Figure 3 shows two customers connected via a service provider network (SPN) supporting VLAN stacking.

In Figure 3, customer A has configured VLANs 1 to 100 at their sites and similarly Customer B has configured VLANs 1 to 100 at their sites. The tagged data frames belonging to the customers must be kept separate while they traverse the SPN. The customer's data frame can be identified and kept separate by associating another VLAN for that customer's traffic. This results in the tagged customer data frame to be tagged again with a VLAN tag, when it traverses the SPN. The additional tag is removed at the edge of the SPN when the data enters the customer's network again.

Packed VLAN tagging is known as VLAN stacking or as Q-in-Q. Figure 3 shows the frame format of VLAN stacked frames. Customer A's tagged data associated with VLAN 64 when it leaves provide edge (PE) device PE1 towards PE2 (or vice-versa), is tagged with VLAN tag for VLAN 32. Similarly, Customer B's tagged data associated with VLAN 64 is tagged with VLAN tag of VLAN 48 when they traverse between the PE devices.

VLAN stacking is a simple and effective solution to expand LANs, however it has certain drawbacks. Some of these are:

• Scaling issues, since there can exist only 4094 (0, 4095 are reserved) unique and usable VLAN identifiers, a service provider can support atmost 4094 customers. Otherwise, if multiple SPs share a network, they need to share the 4094 VIDs between them.
• Support for tracing the Q-in-Q paths does not exist. This is required to determine whether appropriate paths supporting the needful quality of service for the data are chosen for the data flow. If appropriate paths are not chosen, a path might require a re-routing.
• The size of the bridged network diameter is limited to seven due to bridge protocol constraints.

2. VPLS
VPLS defined as one of the L2 virtual private network (L2VPN) technologies by the Internet Engineering Task Force (IETF) helps customer LANs and VLANs to be interconnected across the SPNs with the help of tunnels known as pseudowires (PWs). The PE devices and provider devices in a SPN along with the PWs provide an emulated LAN across the SPN.

In VPLS-enabled networks, the customer edge (CE) devices are connected to the PE device via Ethernet. These connections are called attachment circuits (ACs).

Two PE devices have PWs which are virtual tunnels (MPLS tunnels or L2TP tunnels) established between them, if they are part of the same emulated LAN, or part of the same emulated VLAN. The PWs are either point-to-point or point-to-multipoint tunnels. In VPLS, the auto discovery process with the help of protocols such as border gateway protocol (BGP) enables a PE to discover the other PEs associated with the same VPLS instance. The signaling protocols such as label distribution protocol (LDP), Layer 2 tunneling protocol (L2TP) are then used to establish and maintain the PWs between the PEs.

Each VPLS supporting PE device has two functional components:

1. A PE Bridge module that connects a CE device via an emulated LAN interface (emulated LAN AC) and connects to the second component a VPLS forwarder
2. A VPLS forwarder that connects PE devices via PWs and the PE bridge module

The PE bridge module and the VPLS forwarder learn the MAC addresses, such as those received from MAC bridges. The VPLS forwarder learns only the source address (SA) of the frames received on the PWs. It does not learn the SA of the data frames received on the ACs associated with the PE.

When a data frame (tagged or untagged) is received from a CE at a PE, the PE bridge module learns the MAC address and forwards the frame to the VPLS forwarder in the PE. The VPLS forwarder forwards the data over a single PW if the destination address (DA) of the data frame was learned earlier. Otherwise, the VPLS forwarder forwards the frame in broadcast mode via point-to-multipoint PWs to other PEs. The VPLS forwarder at the reception PE of the PW receives the data frame learns the SA and forwards the frame to the PE Bridge module.

The PE bridge module forwards the data frame towards the attached CE. When the data traverses a PW, suitable encapsulation is done based on the tunnel type of the PW. For example, if the PW is a MPLS tunnel established using LDP, the Ethernet data frames are MPLS labeled and label switched along the PW.

Wrap Up
Ethernet, initially a LAN technology, has matured to be deployed in larger physical spaces such as MANs. The associated protocols such as Layer 2 bridging and VLANs can be extended end-to-end between customer sites across the SPN creating transparent LANs. Network device vendors and service providers along with the standard bodies such as IEEE and IETF are working towards promising technologies such as VPLS. VPLS enables customer LAN applications to work seamlessly across the MANs and WANs utilizing the provider's value added services.

Editor's Note: To view Part 1 of this article, click here.

About the Author
Manikantan Srinivasan is the engineering manager at Net-O2 Technologies. He has an ME (Computer Science & Engineering) from the Indian Institute of Science, Bangalore, India and a B.Sc in Physics and Electronics from the University of Bangalore, India. Manikantan can be reached at manis@net-o2.com.