Multilink Frame Relay Setup and Operation
Now that the main issues and solutions that are raised through implementation of the Multilink Frame Relay feature have been described, you can put the full benefits of this feature into perspective.
This section discusses the components of the Multilink Frame Relay feature and explains its setup and basic operation.
Multilink Link Integrity Protocol
Multilink Frame Relay uses the Link Integrity Protocol Control messages for link management of the bundle links. The link control messages defined by the Multilink Frame Relay Link Integrity Protocol are exchanged between peers in a three-step process: establishing the link, maintaining the link, and tearing down the link. The basic format of the Multilink Frame Relay Link Integrity Protocol message, as defined in FRF.16, is shown in Figure 14-2.
Figure 14-2. Format of the Multilink Frame Relay Link Integrity Protocol Message
Multilink Frame Relay Link Integrity Protocol Control messages are transmitted in Multilink Frame Relay frames with the Control Bit set to 1. This serves to differentiate a Multilink Frame Relay data packet from a Multilink Frame Relay link control packet. The Begin (B) and End (E) bits in the headers indicate whether fragmentation has occurred. The control messages are sent without fragmentation (Bit B=1 and Bit E=1). The message consists of a Message Type element and multiple variable-length Information Element fields. The Multilink Frame Relay Link Integrity Protocol defines seven control messages for link management. The Message Type field in the Multilink Frame Relay Link Integrity Protocol message identifies the type of control message. The purposes of each Message Type value are described in Table 14-1.
A Multilink Frame Relay Link Integrity Protocol message can consist of one or more Information Element fields, depending on the type of information it carries. Furthermore, Link Integrity Protocol Control messages are exchanged between peers independently on each link of a bundle.
Figure 14-3 shows the basic format of an Information Element field in the Multilink Frame Relay Link Integrity Protocol message. Table 14-2 explains the purpose of the various Information Element fields.
Figure 14-3. Format of the Multilink Frame Relay Link Integrity Protocol Information Element
Initialization and Bundle Setup
This section explains the basic operation involving bundle initialization and setup, management, and tearing down of the bundle link.
Bundle Link Establishment
The ADD_LINK, ADD_LINK_ACK, and ADD_LINK_REJ messages in the Multilink Frame Relay Link Integrity Control Protocol are used to negotiate the setup of a bundle link between two associated peers or endpoints. When a physical interface is configured as a bundle link, the bundle link setup process is invoked, and an ADD_LINK message is sent out to the peer device on the new bundle link. At the same time, the N_MAX_RETRY counter is cleared and the T_ACK timer is started.
The bundle link establishment process is considered complete when an ADD_LINK_ACK message is received. When this happens, the T_ACK timer is reset and the T_HELLO timer is started. The T_HELLO timer is used to pace the exchange of periodic HELLO and HELLO_ACK messages between the peers for bundle management. However, if the T_ACK timer expires before the endpoint receives an ADD_LINK_ACK message, the bundle link endpoint retransmits the ADD_LINK message.
In the event of errors, the ADD_LINK_REJ message is used to indicate that an invalid ADD_LINK message has been received. For example, this can happen when the received bundle identification is not consistent with the bundle identification received from the other bundle link. The ADD_LINK_REJ message contains the cause for the rejection for diagnostic purposes.
Figure 14-4 shows the basic steps involved in establishing a bundle link between two endpoints.
Figure 14-4. Bundle Establishment Between Two Endpoints
Bundle Management
When the bundle link is up, the peers exchange HELLO and HELLO_ACK messages in order to maintain the link. The periodic exchange of the HELLO and HELLO_ACK messages acts as a keepalive mechanism for the link. The HELLO message is used by a local endpoint to notify its peer that the bundle link is in the UP state. Both ends of a bundle link generate this message periodically based on the T_HELLO timer. The T_HELLO timer can be adjusted to control the rate at which HELLO messages are sent out. For example, reducing the value of the T_HELLO timer increases the frequency at which the Multilink peers poll each other. On Cisco routers, the default T_HELLO timer is set to 10 seconds, and the supported range is from 1 to 180 seconds.
On receiving a HELLO message, the remote peer responds with a HELLO_ACK message to indicate that it has received a valid HELLO message. If a peer does not receive a HELLO_ACK message from its peer after the T_HELLO timer expires, it retransmits the HELLO message, up to the maximum number of attempts specified by the N_MAX_RETRY counter. On Cisco routers, the N_MAX_RETRY counter is set to two tries, and the configurable range is from one to five tries.
Tearing Down the Bundle Link
The Multilink Frame Relay Link Integrity Protocol also specifies a set of rules for tearing down the bundle link. The REMOVE_LINK and REMOVE_LINK_ACK control messages are used to notify the remote peer that the local peer is removing the bundle link from bundle operation. A bundle link can be brought down by configurations. In this case, the bundle link sends a REMOVE_LINK message to its peer that it is releasing this bundle link member interface. On receiving the REMOVE_LINK message, the peer responds with the REMOVE_LINK_ACK message to indicate that it has received the REMOVE_LINK message request. At this time, the endpoint resets the N_MAX_RETRY counter, starts the T_ACK timer, and enters the idle state.
However, if the peer sending out the REMOVE_LINK message does not receive a REMOVE_LINK_ACK message from its peer before its T_ACK timer expires, it retransmits the REMOVE_LINK message up to the maximum number of attempts specified in the N_MAX_RETRY counter. If the local peer tearing down the bundle link does not receive the REMOVE_LINK_ACK message from its peer after the N_MAX_RETRY counter is exceeded, it continues to deactivate the bundle link at its local end.
Multilink Frame Relay System Parameters
The FRF.16 specification defines three system parameters for the basic Multilink Frame Relay operation. As mentioned, these parameters are the T_HELLO timer, the T_ACK timer, and the N_MAX_RETRY counter. The T_HELLO timer is used to control the rate at which HELLO messages are sent out for link management. The T_ACK timer indicates the period for which the peer should wait for ADD_LINK_ACK, HELLO_ACK, or REMOVE_LINK_ACK messages. Finally, the N_MAX_RETRY counter specifies the maximum number of retransmission attempts for HELLO or REMOVE_LINK messages after the T_ACK timer has expired.
Table 14-3 shows the default values of the Multilink Frame Relay system parameters. It is recommended to use the default values for the Multilink system parameters.
This section discusses the components of the Multilink Frame Relay feature and explains its setup and basic operation.
Multilink Link Integrity Protocol
Multilink Frame Relay uses the Link Integrity Protocol Control messages for link management of the bundle links. The link control messages defined by the Multilink Frame Relay Link Integrity Protocol are exchanged between peers in a three-step process: establishing the link, maintaining the link, and tearing down the link. The basic format of the Multilink Frame Relay Link Integrity Protocol message, as defined in FRF.16, is shown in Figure 14-2.
Figure 14-2. Format of the Multilink Frame Relay Link Integrity Protocol Message
Multilink Frame Relay Link Integrity Protocol Control messages are transmitted in Multilink Frame Relay frames with the Control Bit set to 1. This serves to differentiate a Multilink Frame Relay data packet from a Multilink Frame Relay link control packet. The Begin (B) and End (E) bits in the headers indicate whether fragmentation has occurred. The control messages are sent without fragmentation (Bit B=1 and Bit E=1). The message consists of a Message Type element and multiple variable-length Information Element fields. The Multilink Frame Relay Link Integrity Protocol defines seven control messages for link management. The Message Type field in the Multilink Frame Relay Link Integrity Protocol message identifies the type of control message. The purposes of each Message Type value are described in Table 14-1.
Table 14-1. Values of Message Type Fields in Multilink Frame Relay Link Integrity Protocol Message |
|
|
Message Type |
Description |
|
ADD_LINK |
Notifies the peer endpoint that the local endpoint supports frame processing and is ready to become operational |
|
ADD_LINK_ACK |
Notifies the peer endpoint that the local endpoint has received a valid ADD_LINK message |
|
ADD_LINK_REJ |
Notifies the peer endpoint that the local endpoint has received an invalid ADD_LINK message |
|
HELLO |
Notifies the peer endpoint periodically that the local endpoint remains in the UP state |
|
HELLO_ACK |
Notifies the peer endpoint that the local endpoint has received a valid HELLO message |
|
REMOVE_LINK |
Notifies the peer endpoint that the local endpoint and layer management function is removing the bundle link from bundle operation |
|
REMOVE_LINK_ACK |
Notifies the peer endpoint that the local endpoint has received a REMOVE_LINK message |
A Multilink Frame Relay Link Integrity Protocol message can consist of one or more Information Element fields, depending on the type of information it carries. Furthermore, Link Integrity Protocol Control messages are exchanged between peers independently on each link of a bundle.
Figure 14-3 shows the basic format of an Information Element field in the Multilink Frame Relay Link Integrity Protocol message. Table 14-2 explains the purpose of the various Information Element fields.
Figure 14-3. Format of the Multilink Frame Relay Link Integrity Protocol Information Element
Initialization and Bundle Setup
This section explains the basic operation involving bundle initialization and setup, management, and tearing down of the bundle link.
Bundle Link Establishment
The ADD_LINK, ADD_LINK_ACK, and ADD_LINK_REJ messages in the Multilink Frame Relay Link Integrity Control Protocol are used to negotiate the setup of a bundle link between two associated peers or endpoints. When a physical interface is configured as a bundle link, the bundle link setup process is invoked, and an ADD_LINK message is sent out to the peer device on the new bundle link. At the same time, the N_MAX_RETRY counter is cleared and the T_ACK timer is started.
The bundle link establishment process is considered complete when an ADD_LINK_ACK message is received. When this happens, the T_ACK timer is reset and the T_HELLO timer is started. The T_HELLO timer is used to pace the exchange of periodic HELLO and HELLO_ACK messages between the peers for bundle management. However, if the T_ACK timer expires before the endpoint receives an ADD_LINK_ACK message, the bundle link endpoint retransmits the ADD_LINK message.
In the event of errors, the ADD_LINK_REJ message is used to indicate that an invalid ADD_LINK message has been received. For example, this can happen when the received bundle identification is not consistent with the bundle identification received from the other bundle link. The ADD_LINK_REJ message contains the cause for the rejection for diagnostic purposes.
Figure 14-4 shows the basic steps involved in establishing a bundle link between two endpoints.
Figure 14-4. Bundle Establishment Between Two Endpoints
Bundle Management
When the bundle link is up, the peers exchange HELLO and HELLO_ACK messages in order to maintain the link. The periodic exchange of the HELLO and HELLO_ACK messages acts as a keepalive mechanism for the link. The HELLO message is used by a local endpoint to notify its peer that the bundle link is in the UP state. Both ends of a bundle link generate this message periodically based on the T_HELLO timer. The T_HELLO timer can be adjusted to control the rate at which HELLO messages are sent out. For example, reducing the value of the T_HELLO timer increases the frequency at which the Multilink peers poll each other. On Cisco routers, the default T_HELLO timer is set to 10 seconds, and the supported range is from 1 to 180 seconds.
On receiving a HELLO message, the remote peer responds with a HELLO_ACK message to indicate that it has received a valid HELLO message. If a peer does not receive a HELLO_ACK message from its peer after the T_HELLO timer expires, it retransmits the HELLO message, up to the maximum number of attempts specified by the N_MAX_RETRY counter. On Cisco routers, the N_MAX_RETRY counter is set to two tries, and the configurable range is from one to five tries.
Tearing Down the Bundle Link
The Multilink Frame Relay Link Integrity Protocol also specifies a set of rules for tearing down the bundle link. The REMOVE_LINK and REMOVE_LINK_ACK control messages are used to notify the remote peer that the local peer is removing the bundle link from bundle operation. A bundle link can be brought down by configurations. In this case, the bundle link sends a REMOVE_LINK message to its peer that it is releasing this bundle link member interface. On receiving the REMOVE_LINK message, the peer responds with the REMOVE_LINK_ACK message to indicate that it has received the REMOVE_LINK message request. At this time, the endpoint resets the N_MAX_RETRY counter, starts the T_ACK timer, and enters the idle state.
However, if the peer sending out the REMOVE_LINK message does not receive a REMOVE_LINK_ACK message from its peer before its T_ACK timer expires, it retransmits the REMOVE_LINK message up to the maximum number of attempts specified in the N_MAX_RETRY counter. If the local peer tearing down the bundle link does not receive the REMOVE_LINK_ACK message from its peer after the N_MAX_RETRY counter is exceeded, it continues to deactivate the bundle link at its local end.
Multilink Frame Relay System Parameters
The FRF.16 specification defines three system parameters for the basic Multilink Frame Relay operation. As mentioned, these parameters are the T_HELLO timer, the T_ACK timer, and the N_MAX_RETRY counter. The T_HELLO timer is used to control the rate at which HELLO messages are sent out for link management. The T_ACK timer indicates the period for which the peer should wait for ADD_LINK_ACK, HELLO_ACK, or REMOVE_LINK_ACK messages. Finally, the N_MAX_RETRY counter specifies the maximum number of retransmission attempts for HELLO or REMOVE_LINK messages after the T_ACK timer has expired.
Table 14-3 shows the default values of the Multilink Frame Relay system parameters. It is recommended to use the default values for the Multilink system parameters.
Table 14-3. Default Values of the Multilink Frame Relay System Parameters |
|||
|
System Parameter |
Default Value |
Minimum Value |
Maximum Value |
|
T_HELLO |
10 seconds |
1 second |
180 seconds |
|
T_ACK |
4 seconds |
1 second |
10 seconds |
|
N_MAX_RETRY |
2 tries |
1 try |
5 tries |
