Internet Draft 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:INIT, RECOGNIZE Messages: ATM Point-to-point link: Nagami, et al. [Page 11] Internet Draft draft-nagami-csr-fanpv2-nd-00.txt December 1997 Otherwise: 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]