The Control Direct VCC is a bi-directional point-to-point control connection between LEC and LES. It is established during the LEC initialization phase. In contrast to the Configuration Direct VCC, the LEC and LES are required to preserve this
VCC connection throughout the participation of the LEC in the ELAN.
The Control Distribute VCC is a unidirectional point-to-point or point-to-multipoint control connection from LES to LEC s. This is an optional control connection which the LES may establish during the initialization of an LEC. Once it is
established, the LEC and LES are required to maintain this control connection throughout the participation of the LEC in the ELAN.
Previous Table of Contents Next
Copyr ight © CRC Pr ess LLC
by Abhijit S. Pandya; Ercan Sen CRC Press, CRC Press LLC
ISBN: 0849331390 Pub Date: 110198
Previous Table of Contents Next
The Data Direct VCC is a bi-directional point-to-point data connection between LECs to exchange unicast data. When an LE Client wants to send a packet to another LEC for the first time and it does not
have the ATM address of this destination LEC, the source LEC issues an LE_ARP request to BUS in order to obtain the required destination ATM address. Upon receiving an LE_ARP response with the
ATM address of the destination LEC, the source LEC sets up a Data Direct VCC to the destination LEC to be used for the remainder of the data exchange. If the source LEC is unable to set up this new
connection due to lack of resources, it is expected to clear down one of its existing Data Direct VCC connections in order to free up the nessary resources to set up this new connection instead of keep
repeating the LE_ARP request to BUS.
The Multicast Send VCC is a bi-directional point-to-point data connection between LEC and BUS. An LEC establishes this connection using the same procedure which was described previously for Data
Direct VCCs. When the LEC wants to send multicast data to multiple elements of the ELAN, it uses this VCC to pass the multicast data to the BUS for distribution. The LEC also uses this VCC for sending
initial unicast data to an unknown destination through the BUS. The LEC is required to maintain this VCC for the duration of its participation in the ELAN and to accept data from this VCC which the BUS
might use to send data or a response back to the LEC.
The Multicast Forward VCC is a unidirectional point-to-point or point-to-multipoint data connection set by the BUS to the LEC during the initialization of the LEC for the ELAN sign up. The primary function
of this VCC is to distribute data from the BUS to the member LECs of the ELAN. The LEC is required to accept the connection request and to maintain this VCC for the duration of its participation in the
ELAN. The BUS may choose to forward data over either the Multicast Send or Multicast Forward VCC with the assurance that the LEC will not receive duplicate data from both VCCs.
E. Basic Operations Flow for LEC
We next describe the basic operational flow for LE Clients. The key elements of this operational flow include Initialization, Active Operation and Recovery phase. The operational flow as shown in Figure 9-
7 starts with the initial state. The initial state involves the definition of key ELAN parameters such as ELAN name, maximum frame size allowed and essential addresses such as LE Configuration Server,
etc. The LEC uses these parameters for the ELAN sign-up process. It is possible that these parameters may be defined for more than one ELAN for the LEC so that the LAN can participate in more than one
When an LEC decides to join a particular ELAN, it first goes through the LECS Connect phase. In this phase, the LEC sets up a Configuration Direct VCC to the LECS to obtain the necessary configuration
information such as the LES address, etc. Upon establishment of this VCC, the LEC goes into the next phase which is the Configuration phase.
In the Configuration phase, the LEC receives information about the LE Service through its Connection Direct VCC to the LECS and proceeds to the Join phase.
In the Join phase, the LEC establishes its Control Direct and Control Distribute VCCs to the LE Server. Upon successful connection to the LES, the LEC receives information which is critical to its
participation in the ELAN. This information includes a unique LEC identifier LECID, maximum frame size allowed and its LAN type, i.e., Ethernet or Token-Ring. Following the successful completion of
Join phase, the LEC precedes with the Initial Registration phase.
In the Initial Registration phase, it is possible for a LEC to register additional MAC addresses and or Router Descriptors in addition to the single MAC address used in the Joining phase. Through this Initial
Registration process, the LEC can validate the uniqueness of its local addresses before becoming operational in order to eliminate the possibility of any address conflict within the ELAN. After this
address validation process through the Initial Registration phase, the LEC precedes with the BUS Connection phase.
In the Bus Connect phase, the LEC sends an LE_ARP to the “all ones” broadcast MAC address in order to set up a Multicast Send VCC to the BUS. Upon receiving the LE_ARP response containing the BUS
address, it establishes this connection. In turn, the BUS establishes a Multicast Forward VCC to the LEC. Upon successful completion of the BUS Connect phase, the LEC is considered operational within
the ELAN.
The LEC Recovery phase involves returning to the Initial State in all failure cases except the loss of BUS connection in which case the LEC goes back to the BUS Connect phase to re-establish the BUS
connections.
Previous Table of Contents Next
Copyr ight © CRC Pr ess LLC
by Abhijit S. Pandya; Ercan Sen CRC Press, CRC Press LLC
ISBN: 0849331390 Pub Date: 110198
Previous Table of Contents Next
F. LANE Connection Management
A LANE environment can be set up to operate with Permanent Virtual Connections PVCs or Switched Virtual Connections SVC for the connections among the LANE elements LEC, LES and BUS. When
operating with PVC connections, the PVCs are set up manually using the ATM Layer Management entity. On the other hand, if the LANE is operating with SVC connections, the ATM UNI signaling protocol is
used to set up the required connections. At least the best effort quality of service is required for these connections.
When using SVC for Data Direct VCC, a slightly modified version of ATM call setup procedure is used to guarantee readiness of both sides calling and called parties before the data transfer takes place. This
modified call setup protocol is shown in Figure 9-8.
The first part of the call setup involving SETUP, CONNECT and CONNECT_ACK messages is the same as a typical SVC setup. The second part of the procedure involving READY_IND and READY_QUERY
is specific to the LANE environment. The main reason for the additional message sequence is to ensure end-to-end validation that both parties are ready to exchange data. For example, it is possible that the
called party may receive the CONNECT_ACK message before the calling party gets the CONNECT message. Such an undesirable timing has to do with the fact that the CONNECT_ACK message may be
sent from the local switch where the called party is connected. If the CONNECT_ACK message was to be interpreted as a GO signal by the called party, then the called party would possibly start sending data to the
calling party before the CONNECT message is received by the calling party. The CONNECT message carries critical information such as the indication of successful allocation of the VPIVCI numbers for the
Data Direct VCC. Hence the calling party cannot make itself ready to receive data from the called party until it receives such confirmation.
Figure 9-7 Basic LEC operational flow.
The READY_IND and READY_QUERY messages provide end-to-end, confirmation to both sides. When the called part receives the CONNECT_ACK message, it starts a timer for the supervision of
READY_IND. If the READY_IND is received before the timer expires, the called party stops the timer and goes into ready state to exchange data with the calling party. However, if the timer expires before
receiving the READY_IND, then the called party sends a READY_QUERY message to request
