LANE: Theory of Operation
Now that the chapter has built a common foundation of ATM knowledge, the following sections dive into the specifics of LAN Emulation. Before beginning, let me reiterate that the goal is not to clobber you with every subtle nuance of LANE (although it will probably feel like that in ten pages). For example, the LANE specifications contain many optional features rather than trying to highlight every option, the material focuses on the real-world applications and common practices of LANE.
VLAN Versus ELAN
Many documents treat the terms Virtual LAN (VLAN) and Emulated LAN (ELAN) as synonyms; however, although related, they are arguably different concepts. As discussed in Chapter 5, "VLANs," the term VLAN is used to describe a broadcast domain, in other words, an IP subnet. In a similar fashion, ELANs also act as broadcast domains, and each ELAN has a unique IP subnet address. However, an ELAN is also a specific type of a VLAN: a LAN emulated over ATM. Whereas VLANs can exist over any medium, ELANs only exist in an ATM environment. Whereas all ELANs are VLANs, not all VLANs are ELANs.
The LANE Fake Out: Simulating LANs
As it creates emulated LANs, LANE functions as a sophisticated fake out. Specifically, it fools higher-layer protocols into believing that the network infrastructure consists of Ethernet or Token Ring links when, in fact, the network is composed of an ATM cloud. In this chapter, we focus exclusively on Ethernet-style LANE.
To fool higher-layer protocols into believing that Ethernet is in use, LANE must simulate two important aspects of Ethernet not found in normal ATM networks:
MAC addresses As discussed in Chapter 1, "Desktop Technologies," Ethernet devices use 6-byte MAC addresses. However, as discussed earlier in this chapter, ATM uses NSAP addresses to create new ATM SVC connections. Some means to convert between these two addressing schemes must exist.
Broadcasting Given the connection-oriented nature of ATM discussed earlier, broadcasting and multicasting become non-trivial exercises in an ATM environment. However, because higher-layer protocols have always made extensive use of Ethernet's broadcast capabilities, some broadcast mechanism must be devised.
Note
Recall that LANE is a technique for bridging traffic over an ATM network. As a bridging technology, LANE therefore uses the Spanning-Tree Protocol discussed in Chapters 6 and 7. Note that this also implies a lower limit on failover performance: features such as SSRP, discussed later, might fail over in 10 15 seconds, however, Spanning Tree prevents traffic from flowing for approximately 30 seconds by default.
Because of this delay, some ATM vendors disable Spanning Tree by default. Because of the risks associated with doing this (loops can easily be formed in the Ethernet portion of the network), Cisco enables Spanning Tree over LANE by default.
Let's Go to The LANE Bar
This section uses the analogy of a play or skit called "The LANE Bar." Not only does this provide an opportunity for some comic relief in the middle of a long and technically challenging chapter, it provides a strong parallel and memory aid for how LANE functions.
The director of this play is none other than the ATM Forum, world-renowned producers of such Broadway hits as "UNI 3.1," "PNNI," and "Circuit Emulation Service." The play is about deception and deceit about a group of thugs who fake out a bunch of innocent Ethernet hosts one night. The director has chosen to include four characters.
The Four Characters (Components) of LANE
LANE uses four characters (components) to create the fake out discussed in the previous section. Most vendors implement these components in software that runs on edge devices (although hardware-assisted, hardware-based, and switch-based components are possible). In total, LANE uses one client character and three server characters. The characters (described in the ensuing sections) are as follows:
LAN Emulation Clients (LECs)
LAN Emulation Configuration Server (LECS)
LAN Emulation Server (LES)
Broadcast and Unknown Server (BUS)
Starring Role: LEC
LAN Emulation Clients (LECs, note the lowercase "s") are edge devices where the fake out actually occurs. In the case of Catalyst LECs, the Catalyst LANE module runs software that fools Ethernet-attached hosts into believing that the ATM backbone is actually Ethernet. LECs are often referred to as Clients and have a starring role in the play. There are two types of LECs: Normal LECs and Proxy LECs.
Normal LECs are everyday devices that happen to contain an ATM interface. For example, take a Windows NT server and place an ATM NIC in one of its expansion slots. Configure it to run LEC software, and the PC can now communicate directly to other devices over the ATM backbone.
Proxy LECs (PLECs) are a slightly different animal. Proxy LECs also directly connect to the ATM backbone and run some sort of LEC software, however, they usually generate very little traffic by themselves. For example, take a Catalyst 5000 that contains a LANE uplink module. Left alone, the Catalyst 5000 generates minute amounts of overhead traffic such as Spanning-Tree Protocol, VLAN Trunking Protocol (VTP), and so forth. The vast majority of traffic that the Catalyst needs to send is on behalf of the Ethernet-attached devices connected to 10/100 Ethernet ports (some B-grade supporting actors sitting just off-stage). However, these Ethernet-attached PCs, workstations, and servers cannot become LECs after all, they aren't connected to the ATM cloud! It is the Catalyst LANE module that acts as a proxy or agent on behalf of these devices.
LANE Clients serve as the front lines of the fake out; however, left to their own capabilities, LECs would be hopeless. To complete the fake out, our stars (LECs) require the services of three supporting actors (server components). In fact, these three servers allow a Client to join an Emulated LAN.
Supporting Actor: LECS
To begin this joining process, Clients require two things: security and hospitality.
These two functions are provided by a character (component) referred to as the LAN Emulation Configuration Server, or LECS (note the uppercase "S"). This character has been cast as a large, burly fellow with a huge neck, bald head, and a large tattoo on his left arm. He is affectionately referred to as The Bouncer. This character stands at the front door of the nightclub to provide security ("Hey, I need to see your ID!") and hospitality ("The bartender is located over there.") to thirsty Clients.
Tip
The acronyms used by LANE can lead to considerable confusion. This is especially true when using the terms LECs (more than one LANE Client) and LECS (a single LANE Configuration Server). You might want to always pronounce LEC as "Client" and LECS as "Config Server" to avoid this confusion.
Supporting Actor: LES
No barroom would be complete without a Bartender. This important character runs the show in each bar (ELAN). The other characters typically refer to the Bartender by his nickname, LES. Because the directors see this as a high-class bar, they have asked LES to carefully keep track of every Client sitting in the bar (joined the ELAN). To not fail at this task, LES keeps of a list of every Client's name (MAC address) on a clipboard. In addition, LES makes a note of the table number (NSAP address) where every Client is sitting. Therefore, Client actors can ask questions like, "Where's Billy Bob (MAC address 0000.0C12.3456) sitting?" LES can then easily give an answer: "He's at table 219 (NSAP address 47.0091.8100.0000.0060.8372.56A1.0000.0c33.BFC1.A1)!"
Supporting Actor: BUS
The owner of the bar has noticed that the situation sometimes gets a little out of hand in the bar. Get a room full of Clients together and you never know what will happen! One of the problems, especially on Friday nights, is that Clients tend to jump on the tables and start dancing around to attract attention from all other Clients in the bar. Because this has proven to be hard on both the tables and the Clients, our director has requested a special supporting actor called the Broadcast and Unknown Server, or BUS for short. This sly character has earned the title of The Barroom Gossip you tell him one thing and he's guaranteed to tell everyone else in the bar!
The Setting
Our play is set in the exciting community of Geektown. In building the set, the director has spared no expense. On stage, the workers have carefully built an entire nightclub. This is a single, large brick building (ATM cloud) that contains two separate barrooms (ELANs). On the right, we have The Funky Bit-Pipe, a popular local discotheque. On the left, The Dusty Switch, an always-crowded country-western bar.
Plot Synopsis
Act I is where the main drama occurs and consists of five scenes:
Scene 1 Configuration Direct Client Contacts the Bouncer (LECS): The play begins with a lone Client standing outside the barroom. The Client is clad in a pair of shiny new cowboy boots, a wide-brimmed Stetson hat, and a Garth Brooks look-alike shirt. Before the Client can enter the bar and quench his thirst, he must locate the Bouncer (LECS) standing at the front door to the nightclub. The Bouncer performs a quick security check and, noticing the Client's cowboy attire, points the Client in the direction of the Bartender (LES) for the Dusty Switch barroom (ELAN).
Scene 2 Control Direct Client Contacts the Bartender (LES): As soon as the Client enters the bar, it must approach the Bartender. Then, the Bartender makes a note of the Client's name (MAC address) and table number (NSAP address). Notice that this solves the first requirement of the LANE fake out by providing MAC address to NSAP address mapping.
Scene 3 Control Distribute Bartender (LES) Contacts the Client: As every Client enters the barroom, the Bartender adds it as a leaf node to a special fan-out point-to-multipoint VC. After the new Client contacts the Bartender, the Bartender must add this Client as well. This fan-out circuit allows the Bartender to easily send a single frame that gets distributed to all Clients in the ELAN by the ATM switches. "Happy Hour!" and "Last Call!" are commonly heard messages.
Scene 4 Multicast Send Client Contacts the Gossip (BUS): The Client then acquires the location of the Gossip (BUS) from the Bartender (LES). Next, the Client uses this address to build a connection to the Gossip, allowing the Client to easily send broadcasts and multicasts to everyone in the bar. Notice that this solves the second requirement of the fake out: the capability to send broadcast and multicast frames.
Scene 5 Multicast Forward The Gossip (BUS) Contacts the Client: Just as the Bartender has special fan-out point-to-multipoint circuits that can be used to efficiently reach every Client in the barroom, The Gossip maintains a similar circuit. This allows the Gossip to quickly distribute all of the information he collects.
After the five scenes of Act I are complete, the Client has joined the ELAN, Act II. Notice that Acts I and II only consider the action in the Dusty Switch ELAN. While the cowboys are having fun in their ELAN, another group of Clients is dancing the night away in the discotheque ELAN. Although both barrooms share the services of the Bouncer, each bar requires its own Bartender and Gossip.
Five-Step LANE Initialization Sequence
As introduced in the previous section, the four LANE characters have to do some fancy footwork before they are allowed to communicate via LANE. This section discusses in detail each of the five scenes used to describe the complete process. Now that you are awake (and hopefully have a smile on your face), the text begins to transition away from The LANE Bar analogy (for example, Scenes 1 5 are now referred to as Steps 1 5). However, because it has proven to be a useful memory aid, the text continues to refer to the analogy with parenthetical comments.
Step 1: Configuration Direct Client Contacts the LECS
As the first step in the joining process, the Client must locate the LECS (Bouncer). Clients can use four techniques to locate the Configuration Server:
A manually configured NSAP address
ILMI
Well-known NSAP (47.0079…)
Well-known VPI/VCI (0/17)
In reality, locating the Bouncer consists of building an ATM virtual circuit to the LECS. The first three options in the preceding list all make use of SVCs, and the last option utilizes a PVC.
The manually configured NSAP address option for LECS discovery uses the lane configatm-address command to hard-code the NSAP address of the LECS on every Client. Although this approach does provide for technical simplicity, it can lead to administrative headaches.
The ILMI approach uses the capabilities of ILMI to automate the distribution of the LECS' NSAP. This still requires the NSAP to be manually configured on every ATM switch, but because most networks have far fewer ATM switches than Clients, this can result in significantly less configuration effort. Cisco recommends this approach because it is both simple and effective (it also works well with the Simple Server Redundancy Protocol [SSRP] discussed later in this chapter).
The well-known NSAP technique is similar to dialing the police in the United States: regardless of where you are, just dial 911 and the phone system connects you to the nearest police station. In the case of LANE, dialing the well-known NSAP connects you to the nearest LECS. Although the full address is 47.007900000000000000000000.00A03E000001.00 (00A03E is the Organizational Unique Identifier [OUI] assigned by the ATM Forum), any time you see an address that begins with 47.0079 you can be fairly confident that this is an attempt to contact the LECS via the well-known NSAP. You might also run into another version of this address that begins with a C5 in place of a 47 (this uses an ATM feature called anycasting).
Note
Anycast addresses are special ATM NSAPs that allow multiple devices to advertise a single service. As clients request connections to these addresses, ATM switches automatically connect them to the nearest available device providing that service. Not only can this optimize traffic flows, it can provide an automatic form of redundancy (if the nearby server goes away, the client simply is sent to a more distant device when it tries to reconnect).
Under the well-known VPI/VCI approach, Clients always use 0/17 to communicate with the LECS. Because this method doesn't lend itself well to failure recovery, the well-known VPI/VCI technique is rarely used (it's also not included in the second version of the LANE specification).
Assuming that the LEC has acquired the Configuration Server's NSAP via ILMI, the Client then places an ATM phone call (SVC) to the LECS. This SVC is referred to as the Configuration Direct (it is a direct connection to the Configuration Server). After the Configuration Direct has been established, the Client tells the Configuration Server its NSAP address and the desired ELAN (barroom). The LECS then lives up to its title of the Bouncer by providing the Client with the following:
Security Optionally checks the Client's NSAP address as a security measure
Hospitality Tells the Client how to reach the bartender (LES) of the desired barroom (ELAN)
Also, if the Client doesn't request a specific ELAN, the Bouncer can optionally provide a default ELAN.
Figure 9-9 illustrates the Configuration Direct VC.
Figure 9-9. Step 1: The Client Contacts the Configuration Server to Get the NSAP of the LES
Assuming that the Client meets the security requirements and the requested ELAN exists, the LECS provide the NSAP of the LES to the Client. At this point, the Configuration Direct can optionally be torn down to conserve virtual circuits on the ATM switch (Cisco devices take advantage of this option).
Step 2: Control Direct Client Contacts the LES
After the Client has acquired the LES's NSAP address, it requests an SVC to this location. This SVC is known as a Control Direct, the direct connection to the device that controls the ELAN, the LES. The Client sends his MAC address (Name) and NSAP address (barroom table he is sitting at) to the LES (bartender). The LES then makes a note of these entries in its database. Figure 9-10 shows the Control Direct VC.
Figure 9-10. Step 2: The Client Contacts the LES and Registers Its MAC and NSAP Addresses
Step 3: Control Distribute LES Contacts the Client
Using the NSAP address registered over the Control Direct, the LES needs to call back the Client. However, this is not a normal, point-to-point phone call. Prior to this Client's attempt to join, the LES already owned a point-to-multipoint VC to every Client in the ELAN. In other words, every existing Client is a leaf node and the LES is the root node of this unidirectional circuit. The LES then issues an ADD_PARTY message to add the new Client as a leaf node. Figure 9-11 illustrates the resulting Control Distribute VC.
Figure 9-11. Step 3: The LES Adds the Client to the Already Existing Control Distribute Point-to-Multipoint Circuit
Step 4: Multicast Send The Client Contacts the BUS
As might be expected, the Client ultimately uses the Control Direct VC established in Step 3 to map MAC addresses into NSAP addresses. The name of the message used to perform this mapping process is an LE_ARP message. An LE_ARP_REQUEST allows a Client to locate the NSAP address associated with another Client's MAC address. LE_ARP_REPLIES are used by the LES to answer LE_ARP_REQUESTS.
Notice that the Client is still in the process of joining and LE_ARPs cannot be used to contact other Clients until the join process is complete. However, the Client LE_ARPs to locate the BUS (the Gossip). The Client issues an LE_ARP_REQUEST for the MAC address FFFF.FFFF.FFFF to resolve the NSAP of the BUS. In other words, the Client LE_ARPs for the broadcast MAC address to locate the device that handles broadcast traffic: the BUS. After the Client LE_ARPs for FFFF.FFFF.FFFF, the LES responds with the NSAP address of the BUS. The Client uses this information to build a Multicast Send VC to the BUS as shown in Figure 9-12.
Figure 9-12. Step 4: The Client Builds the Multicast Send to the BUS
Step 5: Multicast Forward The BUS Contacts the Client
As with the LES, the BUS maintains a point-to-multipoint connection to every Client in the ELAN. After the BUS learns of the new Client via the Multicast Send, it calls back the Client by issuing an ADD_PARTY message for that device. This VC is referred to as the Multicast Forward.
This point-to-multipoint VC provides a fairly efficient method for Clients to issue broadcast and multicast traffic to each other. After Clients forward traffic to the BUS, it sends the traffic out the Multicast Forward to all devices in the ELAN. Figure 9-13 illustrates the Multicast Forward.
Figure 9-13. Step 5: The BUS Adds the Client to the Multicast Forward
The Client Has Joined!
After the five overhead connections have been built, the Client has officially joined the ELAN. At this point, the Client is free to issue LE_ARP_REQUESTs for other Clients in the ELAN. The resulting connections, Data Direct VCs, are the primary communication path between LANE Clients. Figure 9-14 illustrates a Data Direct circuit.
Figure 9-14. Data Direct VCs are created by Clients after they have joined the ELAN
Using The LANE Bar as a Memory Aid
Because LANE obviously contains many unusual and complex mechanisms, use the LANE Bar analogy to keep your bearings. Many elements of the analogy were specifically chosen to mirror how LANE works in reality. In particular:
Just as one physical building can be used to house two barrooms, one physical ATM cloud can house multiple ELANs.
Just as a Bouncer provides security and hospitality, the LECS can check Client NSAP addresses for security and point the Clients toward the LES.
Just as both barrooms were served by a single Bouncer, a single LECS serves an entire network.
Just as each barroom required its own Bartender and Gossip, each ELAN requires a LES and BUS.
Just as a Bartender runs a barroom, an LES runs an ELAN.
Just as Gossips tell everyone everything they hear, BUSs are used to spray information to all Clients in an ELAN.
Just as Clients are not allowed to come through the bar's back door when they are thrown out (they must dust themselves off and go back to see the Bouncer first), LANE Clients must rejoin an ELAN by visiting the LECS first.
Ethernet LANE Frame Format
Ethernet LANE traffic that passes over the Data Direct uses the frame format illustrated in Figure 9-15.
Figure 9-15. Ethernet Data Frame Format for LANE
If you compare the LANE Version 1.0 format to the traditional Ethernet frame you will notice two changes:
The addition of the 2-byte LEC ID field As LECs contact the LES, they are assigned a unique, 2-byte LECID identifier. In practice, the first LEC that joins is 1, the second is 2, and so on.
The removal of the 4-byte CRC Because ATM has its own CRC mechanism, the ATM Forum removed the Ethernet CRC.
Notice that this changes the Ethernet MTU for LANE. As discussed in Chapter 1, the traditional Ethernet MTU is 1,518 bytes: 14 bytes of header, 1500 bytes of payload, and 4 bytes of CRC. Because Ethernet LANE removes the 4-byte CRC but adds a 2-byte LEC ID, the resulting MTU is 1516. However, notice that the payload portion is still 1500 bytes to ensure interoperability with all Ethernet devices.
LANE version 2.0 adds an optional 12-byte header to the front of the format used in version 1.0. The 12 bytes of this header are composed of the following four fields:
802.2 Logical Link Control (LLC) header The value AAAA03 signifies that the next five bytes are a SNAP header.
SNAP Organizationally Unique Identifier (OUI) Used to specify the organization that created this protocol format. In this case, the OUI assigned to the ATM Forum, 00A03E, is used.
SNAP Frame Type Used to specify the specific frame type. This field allows each of the organizations specified in the previous field to create up to 65,535 different protocols. In the LANE of LANE V2, the value 000C is used.
LANE V2 ELAN ID A unique identifier for every ELAN.
This allows the second version of LANE to multiplex traffic from multiple ELANs over a single Data Direct VC (the ELAN-ID is used to differentiate the traffic).
Building a Data Direct VC
This section details the sequence of events that allow two Clients to establish a Data Direct VC. The example uses the network illustrated in Figure 9-16.
Figure 9-16. Two Ethernet Hosts Connected via Proxy Clients
In the example, Host-A issues an IP ping to Host-B. Both devices are Ethernet-attached PCs connected to Catalysts that contain LANE uplink cards in slot 4. Host-A is using IP address 1.1.1.1 and MAC address AAAA.AAAA.AAAA. Host-B has IP address 1.1.1.2 and MAC address BBBB.BBBB.BBBB. Notice that this example focuses only on the building of a Data Direct both Clients (Catalyst LANE cards) are assumed to have already joined the ELAN (using the five-step process discussed earlier). All caches and LANE tables are assumed to be at a state just after initialization. The following sequence outlines the steps that allow two Clients to establish a Data Direct VC.
The user of Host-A enters ping 1.1.1.2 at a command prompt.
Host-A issues an IP ARP for the IP address 1.1.1.2. Figure 9-17 illustrates this ARP packet.
Figure 9-17. IP ARP Request
The ARP payload contains the destination IP address in question, 1.1.1.2, but contains all zeros for the associated MAC address. This ARP packet is then encapsulated in an Ethernet frame. As discussed in Chapter 2, "Segmenting LANs," the Ethernet encapsulation has a destination MAC address of FFFF.FFFF.FFFF and a source address of AAAA.AAAA.AAAA, the originating node.
The LEC-A Catalyst receives the IP ARP frame on Port 5/12 and floods the frame out all ports in the same VLAN (there are no loops here, so Spanning Tree is ignored). Because LEC-A has been assigned to the same VLAN as Host-A, this Client needs to forward the frame across the LANE cloud. Because the destination address is FFFF.FFFF.FFFF, the Client forwards the frame to the BUS via the Multicast Send. Also notice that LEC-A adds an entry into its bridging table associating MAC address AAAA.AAAA.AAAA with Port 5/12.
The BUS floods the packet to all Clients, including LEC-B, via the Multicast Forward. Notice that LEC-A also receives this frame, but is able to discard the frame because it recognizes its own LECID in the first two bytes.
Because the LEC-B is operating as a transparent bridge, it also notices the broadcast destination address of the IP ARP and floods the packet to all ports in that VLAN, including Host-B's Port of 3/10. It also makes a new entry in its bridging table to reflect the fact that it just received a source MAC address of AAAA.AAAA.AAAA on Port 4/1.
Figure 9-18 illustrates the first five steps of the Data Direct Process.
Figure 9-18. The first five steps of the Data Direct VC Creation Process
Host-B receives the IP ARP request. Recognizing its IP address in the ARP packet, it builds an IP ARP reply packet. Figure 9-19 illustrates the reply.
Figure 9-19. IP ARP Reply
In this case, the ARP message contains the MAC address in question. Also notice that ARP unicasts the reply back to the source node; it is not sent to all nodes via the broadcast address.
The LEC-B Catalyst receives the IP ARP reply. Having just added a bridging table entry for AAAA.AAAA.AAAA in Step 5, the frame is forwarded to the LANE module in slot 4.
The LEC-B software running on the LANE module must then send the IP ARP reply over the ATM backbone. At this point, two separate threads of activities take over. The first thread, an LE_ARP process, is detailed in Step 8; the second thread, forwarding the IP ARP, is explained in Step 9.
LEC-B must resolve MAC address AAAA.AAAA.AAAA into an NSAP address. To do this, LEC-B sends an LE_ARP_REQUEST to the LES. Notice the important differences between this LE_ARP and the earlier IP ARP. With the IP ARP, the destination IP address was known but the MAC address was not known. In the case of the LE_ARP, the MAC address is now known (via the IP ARP) and the NSAP address is unknown. In other words, the LE_ARP is only possible after the IP ARP has already resolved the MAC address.
The LES consults its local MAC-address-to-NSAP-address mapping table. Although this table contains a mapping entry for LEC-A, it does not contain a mapping entry for Host-A.It is important to realize that LEC-A and Host-A are using different MAC addresses. Just because LEC-A is acting as a Proxy Client for Host-A doesn't mean that it has assumed Host-A's MAC address. When LEC-A joined the ELAN, it could have optionally registered all known addresses for its Ethernet-attached hosts. However, because transparent bridges rarely know all MAC addresses (after all, they are learning bridges), most vendors opt to only register the MAC address specifically assigned to the Proxy LEC.
If it still seems unclear why the LES wouldn't learn about MAC address AAAA.AAAA.AAAA at the time LEC-A joined the ELAN, consider the following: What if Host-A wasn't even running at the time LEC-A joined? In this case, the MAC address isn't even active, so it is impossible for LEC-A to register MAC address AAAA.AAAA.AAAA.
Because the LES doesn't have a mapping for the requested MAC address, it forwards the LE_ARP message on to all Proxy Clients via the Control Distribute VC.
Figure 9-20 diagrams Steps 6 through 8c.
Figure 9-20. Steps 6 8c in the Data Direct VC Creation Process
All Clients, including LEC-A, receive the LE_ARP_REQUEST. LEC-A answers with an LE_ARP_REPLY using the bridging table entry added in Step 3.
The LES receives the LE_ARP_REPLY from LEC-A and forwards it to LEC-B.
LEC-B builds a Data Direct VC to LEC-A.
Figure 9-21 illustrates Steps 8d through 8f.
Figure 9-21. Steps 8d 8f in the Data Direct VC Creation Process
As mentioned in Step 8, LEC-B performed two tasks in parallel. Steps 8a through 8f detailed the LE_ARP resolution process. However, while this sequence of events was taking place, LEC-B also forwarded the IP ARP frame via the BUS. Steps 9a through 9f detail this process of forwarding the IP ARP.
LEC-B sends the IP ARP frame over its Multicast Send to the BUS.
The BUS forwards this frame to all Clients via the Multicast Forward.
All Clients, including LEC-A, receive the IP ARP packet. LEC-B recognizes its LECID and drops the frame. LEC-A uses the bridging table entry added in Step 3 to forward the IP ARP out Port 5/12 to Host-A. LEC-A also adds a bridging table entry associating Port 4/1 with MAC address BBBB.BBBB.BBBB.
Figure 9-22 illustrates Steps 9a through 9c.
Figure 9-22. Steps 9a 9c in the Data Direct VC Creation Process
Having received the IP ARP reply, Host-A caches the IP ARP data, and sends the IP ping packet that has been waiting since Step 2. The destination MAC address is BBBB.BBBB.BBBB (a unicast frame).
The LEC-A Catalyst receives the ping packet on Port 5/12 and uses the bridging table entry added in Step 9c to forward the frame out Port 4/1.
LEC-A then performs the same two parallel tasks discussed in the text preceding Step 8: it issues an LE_ARP_REQUEST over the Control Direct to build a Data Direct, and it floods the ping packet via the BUS. Although the intervening steps are not shown, LEC-A ultimately receives an LE_ARP_REPLY.
LEC-A uses the information contained in the LE_ARP_REPLY to build a Data Direct VC to LEC-B.
Figure 9-23 illustrates the remaining portions of Step 9.
Figure 9-23. Steps 9d 9g in the Data Direct VC Creation Process
At this point, both LECs have attempted to build a Data Direct VC. Which Data Direct VC is built first can be different in every case and depends on the timing of Steps 8 and 9. Assume that LEC-B completes its Data Direct VC first and the timing is such that LEC-A also builds a Data Direct VC. In this case, both LECs begin using the Data Direct VC built by the LEC with the lower NSAP address. Assume that LEC-A has the lower NSAP. This causes all traffic to flow over the Data Direct VC created by LEC-A (LEC-B's Data Direct VC times out after five minutes by default on Cisco equipment).
Before the Clients can begin communicating, they must take an extra step to ensure the in-order delivery of information. Notice that both LEC-B (Step 9b) and LEC-A (Step 9f) have sent information via the BUS. If the Clients were to start sending information via the Data Direct VC as soon as it became available, this could lead to out-of-order information. For example, the Data Direct frame (the second frame sent) could arrive before the frame sent via the BUS (the first frame sent). To prevent this, the Clients can optionally use a Flush protocol. Steps 11a 11e follow the Flush protocol from LEC-A's perspective:
LEC-A sends an LE_FLUSH_REQUEST message over the Multicast Send.
The BUS forwards the LE_FLUSH_REQUEST to LEC-B.
LEC-B answers the Flush with a LE_FLUSH_RESPONSE over the Control Direct.
The LES forwards the LE_FLUSH_RESPONSE over the Control Direct to LEC-A.
Having now flushed all data out of its connection to the BUS, LEC-A can safely begin using the Data Direct VC. The remaining ping packets use this Data Direct VC.
Figure 9-24 diagrams the Data Direct VC completion and Flush processes.
Figure 9-24. Steps 10 and 11a 11e in the Data Direct VC Creation Process
Notice that after the process forks in Step 8, the order of the events becomes indeterminate. In some cases, LEC-A is the first to build a Data Direct VC; in other cases, LEC-B is the first.
EAN: N/A
Pages: 223