Internet Draft
Expiration Date: June 1998 Ken-ichi Nagami
Koutarou Ise
Shigeo Matsuzawa
Akiyoshi Mogi
Yoshihiro Ohba
Toshiba
Flow Attribute Notification Protocol Version 2 (FANPv2)
Neighbor Discovery
<draft-nagami-csr-fanpv2-nd-00.txt>
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstract.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes the specification of FANPv2 (Flow Attribute
Notification Protocol version 2) Neighbor Discovery protocol (ND).
The ND is used for (1) automatically detecting FANPv2 neighbors, (2)
obtaining FANPv2 protocol attributes of the neighbors, and (3)
checking whether consistent states are maintained by the neighboring
nodes. Both DC-mode (Distributed Control mode)[4] and IC-mode (Ingress
Control mode)[5] of the FANPv2 use the ND for these purposes.
The ND operates over multi-access interfaces as well as over
point-point interfaces.
1. Terminology and Definitions
o Point-to-point Interface:
Nagami, et al. [Page 1]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
A logical interface of a node that can be interconnected to a
single neighbor node only.
o Multi-access Interface
A logical interface of a node that can be interconnected to
multiple neighbor nodes. An example of this is an interface that
is attached to an ATM logical IP subnet (LIS).
2. Neighbor Discovery Protocol
2.1 Overview
The ND is used for (1) automatically detecting FANPv2 neighbors, (2)
obtaining FANPv2 protocol attributes of the neighbors, and (3)
checking whether consistent states are maintained by the neighboring
nodes.
For this purpose, ND messages are exchanged among nodes in the same
IP subnet. A node recognizes that FANP is running on a neighbor
node as long as it periodically receives ND messages from the
neighbor.
A state transition machine is prepared for each neighbor node. A
FANP capable node has a "Neighbor Table" for each neighbor. It
contains the following fields.
o Local ID:
A non-zero value which represents the current ID of a node that
maintains the Neighbor Table. When a node sends a FANP message
to its neighbors, it puts its own Local ID into the "Sender ID"
field of the message.
The value of a Local ID is allocated when a FANP starts at the
node and is unchanged as long as the FANP is running at the
node. The value must be different from that allocated at the
past FANP startup times so that the neighbors are able to detect
FANP restart events at the node.
o Peer ID:
A Local ID of a neighbor node. It is obtained from the "Sender
ID" field of a receiving message. If the received Peer ID is
different from the registered one, the node detects that the
neighbor node restarted.
o State:
The state of the ND for the neighbor node.
Each state transition machine for the ND states is shown in Figure
Nagami, et al. [Page 2]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
2. The node takes different actions depending on the type of a
network interface (point-to-point/multi-access).
The ND is explained in detail in the following sections.
2.2 Procedure for Point-to-Point Interface
Figure 1(a) shows the message sequence in the case of point-to-point
interface when node A starts or restarts. For simplicity, Figure
1(a) shows only the case where node A is the sender of the INIT
message. But there is another case where node A is the receiver of
the INIT message.
A FANP capable node allocates a new Local ID and stores it in the
Local ID field in the Neighbor Table when it starts or restarts.
Then, the node sends an INIT message to the neighbor. The INIT
message contains the allocated Local ID in the Sender ID field,
supported protocol information in the Capability Object, and a range
of VCIDs in the VCID Range Object. Then the initial state is set to
"Sent INIT(S1)". While the state is in "Sent INIT(S1)", a node
periodically sends INIT messages. The default timer value for
sending INIT messages is 30 seconds. This timer is called a Resend
Timer.
When node B receives an INIT message from node A, it searches for
the corresponding Neighbor Table entry by using the IP source
address (node A's IP address) field of the received message as the
search key. Node B stores the value of the Sender ID field of the
INIT message into the Peer ID field of the entry. Then, node B
sends a RECOGNIZE message to the sender of the INIT message. The
RECOGNIZE message contains the Local ID and Peer ID fields (which
are stored in the Neighbor Table entry) in the Sender ID and
Receiver ID fields, respectively. It also contains the supported
protocol information in the Capability Object, and a range of VCIDs
in the VCID Range Object.
When node A receives a RECOGNIZE message, it checks whether the
Receiver ID in the message is the same as the Local ID in the
corresponding Neighbor Table entry. When both IDs are the same, node
A recognizes that node B is a neighbor node, and puts Sender ID
in the message into Peer ID in the neighbor table and sends
KEEP_ALIVE message to node B. The Local ID and the Peer ID in the
neighbor table are put into the Sender ID and Receiver ID fields of
the message, respectively. Then the state for node B changes to
"Operational(S3)". The message for setting/releasing a Dedicated-VC
(described in [4][5]) is accepted only in this state.
When node B receives a KEEP_ALIVE message, it checks whether the
Nagami, et al. [Page 3]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
Sender ID and Receiver ID in the message are the same as the Peer ID
and Local ID in the Neighbor Table, respectively. Node B recognizes
that node A is a neighbor node when both pairs of IDs are the same.
Then, the state for node A changes to "Operational (S3)".
While the state in the node is "Operational (S3)", it periodically
sends KEEP_ALIVE messages to the neighbor node. The Local ID and
Peer ID in the Neighbor Table are put into the Sender ID and
Receiver ID fields in the KEEP_ALIVE message, respectively. The
default interval for sending KEEP_ALIVE messages is 30 seconds.
When a node receives a KEEP_ALIVE message, the node checks if the
Sender ID and Receiver ID fields in the message are the same as the
Peer ID and Local ID in the Neighbor Table, respectively. It
recognizes that FANP keeps on running in the neighbor node when both
pairs of IDs are the same.
A node detects that the neighbor node is down when one of the
following conditions are met.
1. A KEEP_ALIVE message isn't received from the neighbor in a
specific interval. A default value of this
interval(Dead-Interval) is three times as long as the KEEP_ALIVE
resend interval.
2. The Sender ID and Receiver ID in the received KEEP_ALIVE message
are different from the Local ID and Peer ID in the neighbor
node, respectively.
In both cases, a node invokes the "Reset the peer" procedure,
changes a state to "Sent INIT (S1)" and restarts the ND. Details of
the "Reset the peer" procedure are shown in Figure 2.
2.3 Procedure for Multi-Access Interface
Figure 1(b) shows a message sequence in the case of the the
multi-access interface. In an initial phase, a node changes a state
to "Idle (S0)". A node periodically sends HELLO messages to
ALLNodes(224.0.0.1) if it is a CSR core router, otherwise to
ALLRouters(224.0.0.2). The default interval for sending HELLO
messages is 60 seconds.
When a node receives a HELLO message, the node allocates a Local ID
and puts it into the Local ID field in the Neighbor Table entry
corresponding to the sender of the HELLO message. The node sends an
INIT message which contains the Local ID in the Sender ID field to
the sender of the HELLO message, and changes the neighbor state to
"Sent INIT (S1)". After this, the same procedure as in the
Nagami, et al. [Page 4]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
point-to-point interface case follows.
if the node doesn't receive a KEEP_ALIVE message during the Dead
Interval from its neighbor, it invokes the "Reset the peer"
procedure and changes the state to "Sent INIT(S1)". When the node
doesn't receive an INIT message or a RECOGNIZE message in this state
during Dead Interval, the state changes to "Idle (S0)".
Node A Node B Node A Node B
| | | |
| | | HELLO |
| | |<----------|
| | | |
| INIT | | INIT |
|---------->| |---------->|
| | | |
| RECOGNIZE | | RECOGNIZE |
|<----------| |<----------|
| | | |
|KEEP_ALIVE | |KEEP_ALIVE |
|---------->| |---------->|
| : | | : |
|KEEP_ALIVE | |KEEP_ALIVE |
|<----------| |<----------|
| : | | : |
|KEEP_ALIVE | |KEEP_ALIVE |
|---------->| |---------->|
(a) Point-to-Point Interface (b) Multi-Access Interface
Figure 1: Sequence of Neighbor Discovery Protocol
2.4 Detailed Procedure
The following is the detailed procedure of the ND.
Initialize(point-to-point interface):
1. Allocated a new Local ID and store it in the Neighbor Table.
2. Send an INIT message.
3. Start a Resend Timer.
4. Change the state to "Sent INIT(S1)".
Initialize(multi-access interface):
1. If a node is a core router, send a HELLO message to
AllNodes(224.0.0.1). Otherwise, send a HELLO message to
AllRouters(224.0.0.2).
2. If a node is a core router, start a HELLO timer.
Nagami, et al. [Page 5]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
3. Change the state to "Idle(S0)".
Receive message:
Take the state specific actions defined in the state transition
table in Figure 2.
Expire DEAD Timer or Resend Timer:
Take the state specific actions defined in the state transition
table in Figure 2.
Expire HELLO Timer:
Send a HELLO message to AllNodes(224.0.0.1)
Reset the peer Procedure:
When a node recognizes that a neighbor node is down, it takes
the following actions.
1. Clear the Peer ID in the table.
2. Remove all the dedicated-VCs for the neighbor node.
3. Generate a new Local ID.
4. Send an INIT message.
State: Idle(S0) [MA]
+----------------+--------------------------+--------------------+
| Event | Action | Next State |
+================+==========================+====================+
| | Generate a new Local ID | Sent RECOGNIZE(S2) |
| | Store Peer ID | |
| Recv INIT | Send RECOGNIZE | |
| | Start Resend Timer | |
| | Start DEAD Timer | |
+----------------+--------------------------+--------------------+
| | Generate a new Local ID | Sent INIT(S1) |
| Recv | Send INIT | |
| RECOGNIZE | Start Resend Timer | |
| | Start DEAD Timer | |
+----------------+--------------------------+--------------------+
| | Generate a new Local ID | Sent INIT(S1) |
| Recv | Send INIT | |
| KEEP_ALIVE | Start Resend Timer | |
| | Start DEAD Timer | |
+----------------+--------------------------+--------------------+
| Recv | Generate a new Local ID | Sent INIT(S1) |
| HELLO | Send INIT | |
| [MA] | Start Resend Timer | |
| | Start DEAD Timer | |
+----------------+--------------------------+--------------------+
Nagami, et al. [Page 6]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
State: Sent INIT(S1)
+----------------+--------------------------+--------------------+
| Event | Action | Next State |
+================+==========================+====================+
| Recv | Store Peer ID | Sent RECOGNIZE(S2) |
| INIT | Send RECOGNIZE | |
+----------------+--------------------------+--------------------+
| Recv | Store Peer ID | Operational(S3) |
|RECOGNIZE && A | Send KEEP_ALIVE | |
| | Start DEAD Timer[P-P] | |
+----------------+--------------------------+--------------------+
| Recv | Send INIT | Sent INIT(S1) |
|RECOGNIZE && !A | | |
+----------------+--------------------------+--------------------+
| Recv | Send INIT | Sent INIT(S1) |
| KEEP_ALIVE | | |
+----------------+--------------------------+--------------------+
| Expire | Stop DEAD Timer | Idle(S0) |
| DEAD-Timer[MA]| Stop Resend Timer | |
+----------------+--------------------------+--------------------+
| Expire | Send INIT | Sent INIT(S1) |
| Resend Timer | | |
+----------------+--------------------------+--------------------+
State: Sent RECOGNIZE(S2)
+----------------+--------------------------+--------------------+
| Event | Action | Next State |
+================+==========================+====================+
| Recv | Store Peer ID | Sent RECOGNIZE(S2) |
| INIT | Send RECOGNIZE | |
+----------------+--------------------------+--------------------+
| Recv | Send KEEP_ALIVE | Operational(S3) |
|RECOGNIZE && B | Start DEAD Timer[P-P] | |
+----------------+--------------------------+--------------------+
| Recv | Reset the peer | Sent INIT(S1) |
|RECOGNIZE && !B | | |
+----------------+--------------------------+--------------------+
| Recv | Start DEAD Timer[P-P] | Operational(S3) |
|KEEP_ALIVE && B | | |
+----------------+--------------------------+--------------------+
| Recv | Reset the peer | Sent INIT(S1) |
|KEEP_ALIVE && !B| | |
+----------------+--------------------------+--------------------+
| Expire | Stop DEAD Timer | Idle(S0) |
| DEAD-Timer | Stop Resend Timer | |
| [MA] | Clear Peer ID | |
+----------------+--------------------------+--------------------+
| Expire | Send RECOGNIZE | Sent RECOGNIZE(S2) |
| Resend Timer | | |
Nagami, et al. [Page 7]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
+----------------+--------------------------+--------------------+
State: Operational(S3)
+----------------+--------------------------+--------------------+
| Event | Action | Next State |
+================+==========================+====================+
| Recv | Stop DEAD Timer[P-P] | Sent INIT(S1) |
| INIT | Reset the peer | |
+----------------+--------------------------+--------------------+
| Recv | Send KEEP_ALIVE | Operational(S3) |
|RECOGNIZE && B | Reset DEAD Timer | |
+----------------+--------------------------+--------------------+
| Recv | Stop DEAD Timer[P-P] | Sent INIT(S1) |
|RECOGNIZE && !B | Reset the peer | |
+----------------+--------------------------+--------------------+
| Recv | Reset DEAD Timer | Operational(S3) |
|KEEP_ALIVE && B | | |
+----------------+--------------------------+--------------------+
| Recv | Stop DEAD Timer[P-P] | Sent INIT(S1) |
|KEEP_ALIVE && !B| Reset the peer | |
+----------------+--------------------------+--------------------+
| Expire | Stop DEAD Timer[P-P] | Sent INIT(S1) |
| DEAD-Timer | Reset the peer | |
+----------------+--------------------------+--------------------+
| Expire | Send KEEP_ALIVE | Operational(S3) |
| Resend Timer | | |
+----------------+--------------------------+--------------------+
Condition A: Receiver ID in the received message is the same as the
stored ID.
Condition B: Sender ID and Receiver ID in the received message are
the same as the stored ID, respectively.
&& : logical AND
! : logical NOT
[P-P] : Point-to-Point Interface
[MA] : Multi-Access Interface
Reset the peer Procedure:
- Clear Peer ID in the table
- Remove all the dedicated-VCs for the neighbor node
- Generate a new Local ID
- Send INIT
Figure2 : State Transition Table
3. Message Format
Nagami, et al. [Page 8]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
FANP control messages are encapsulated in IP packets except for VCID
notification messages. The protocol ID for these messages is
110(decimal). They are transfered through default-VC. They consist
of a common header and object fields.
The reserved field in the following packet format MUST be zero.
3.1 FANP Common Header
FANP control messages except for VCID notification messages(PROPOSE,
PROPOSE ACK,PROPOSE NACK) consist of a FANP common header and FANP
objects described in section 4.3 .
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |I| Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Object /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version : The protocol version of FANP. This protocol version is 2.
I Flag :
This flag is zero if this message is for the DC-Mode[4].
This flag is one if this message is for the IC-Mode[5].
This flag is zero in HELLO,INIT,RECOGNIZE and KEEP_ALIVE messages.
Operation Code:
This field indicates the operation code of the message.
The value of operation code is as follows.
operation code = 1 : HELLO message
operation code = 2 : INIT message
operation code = 3 : RECOGNIZE message
operation code = 4 : KEEP_ALIVE message
Checksum
This field is the 16 bits checksum for the whole body of the
FANP message. The checksum algorithm is the same as that used
for the IP header.
Nagami, et al. [Page 9]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
Sender ID
The Local ID of the sender of the message. This field is zero
for HELLO messages.
Receiver ID
The Local ID of the receiver of the message. This field is zero
for HELLO and INIT messages.
3.2 FANP Objects
3.2.1 Object Header
The FANP object header format is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Object Flags | Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type : The type of this object.
Object Flags : The flag of this object. The semantics of this field
depends on the object types.
Object Length : The length of the object (in bytes) includes the
object header.
3.2.2 Capability Object
This object indicates the attribute of the neighbor node. For
example, it indicates that the neighbor node supports the DC-Mode
and/or the IC-Mode. This object is required for INIT and RECOGNIZE
messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Object Type = 2| Resv |B|I|D| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type : This value is 2.
Object Length : This value is 4 (bytes).
D Flag : Set to 1 if the node supports DC-Mode.
I Flag : Set to 1 if the node supports IC-Mode.
B Flag : Set to 1 if a dedicated-VC can be used bidirectionally.
Nagami, et al. [Page 10]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
3.2.3 VCID Range Object
This object indicates the available VCID range. It is required for
INIT and RECOGNIZE messages if the datalink is an ATM point-to-point
link.
If a dedicated-VC is used bidirectionally, the neighboring nodes for
the VC must have the same available VCID range.
Otherwise, the available VCID range is divided into two parts. The
node which has lower IP address uses the lower half of the range
[Minimum VCID, (Maximum VCID - Minimum VCID -1) / 2]. The node
which has higher IP address used the higher half of the
range[(Maximum VCID - Minimum VCID - 1) / 2 + 1, Maximum VCID].
The format of this object is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Object Type = 3| VCID Type | Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type : This value is 3.
Object Flags : The VCID type
Object Length : The length of the object (in bytes) including
the object header.
Minimum VCID : The minimum VCID value
Maximum VCID : The maximum VCID value
3.3 Examples of Message
The formats of the messages are described in this section.
HELLO, KEEP_ALIVE Messages:
<Common Header>
INIT, RECOGNIZE Messages:
ATM Point-to-point link:
<Common Header> <Capability Object> <Range Object>
Nagami, et al. [Page 11]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
Otherwise:
<Common Header> <Capability Object>
4. Security Considerations
Security issues are not discussed in this document.
5. Intellectual Property Considerations
Toshiba Corporation may seek patent or other intellectual property
protection for some of or all the aspects of the technology
discussed in this document. If any standards arising from this
document are or become protected by one or more patents assigned to
Toshiba Corporation, Toshiba intends to license them on reasonable
and non- discriminatory terms.
6. References
[1] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for
ATM : Overview", RFC2098, Feb. 1997
[2] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[3] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Oct. 1993
[4] K. Nagami, et al., "FANP Version 2 - Distribute Control Mode",
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt(work in
progress), Dec. 1997
[5] Y. Ohba, et al., "FANP Version 2 - Ingress Control Mode",
Internet Draft draft-ohba-csr-fanpv2-icmode-00.txt(work in
progress),Dec. 1997
7. Authors' Addresses
Ken-ichi Nagami
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.jp
Koutarou Ise
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Nagami, et al. [Page 12]
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997
Japan
Phone : +81-44-549-2238
EMail : ise@isl.rdc.toshiba.co.jp
Shigeo Matsuzawa
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : shigeom@isl.rdc.toshiba.co.jp
Akiyoshi Mogi
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : mogi@isl.rdc.toshiba.co.jp
Yoshihiro Ohba
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : ohba@csl.rdc.toshiba.co.jp
Appendix A: How to construct a default-VC
A default-VC in the case of ATM is as follows.
SVC : created using RFC1577[3]
PVC : set up by manual configuration
VP : VCI = 32 is reserved for the default-VC
Point-to-Point : VPI = 0, VCI = 32 is reserved for the default-VC
Appendix B: Packet Encapsulation
In the case of ATM, the encapsulation over default-VCs and
dedicated-VCs is LLC encapsulation for routed non-ISO protocols
defined by RFC1483 [2].
Appendix C: Default Timer value / Default resend times
Timer:
HELLO Timer : 60 sec
Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec
Nagami, et al. [Page 13]