Internet Draft Yoshihiro Ohba Expiration Date: June 1998 Jun-ichi Takahashi Shigeo Matsuzawa Yasuhiro Katsube (Toshiba Corp.) December 1997 Flow Attribute Notification Protocol Version 2 (FANPv2) Ingress Control Mode 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-abstracts.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) Ingress Control Mode (IC Mode). The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to communicate mapping information between a specific packet flow and a virtual connection that conveys the packet flow. The IC Mode is used for establishing and releasing a loop-free cut-through path from an ingress node to an egress node by forwarding FANP control messages along the path. The IC mode provides a simple potential-loop prevention mechanism by using hop count and ingress node information, and a ''retry'' mechanism that tries to extend the cut-through path after setup failures. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 2 3. Cut-through Path Control Procedure ......................... 3 Y. Ohba, et al. [Page 1] Internet Draft FANPv2 Ingress Control Mode December 1997 3.1. Overview of Ingress Control Mode .......................... 3 3.1.1 Path Establishment ....................................... 4 3.1.2 Retry .................................................... 5 3.1.3 Loop Prevention .......................................... 5 3.1.4 Path Release ............................................. 6 3.1.5 Route Change ............................................. 6 3.1.6 Hop Count Change ......................................... 7 3.2 Actions Dependent on VC Type ............................... 7 3.2.1 Actions in Path Establishment Phase ...................... 8 3.2.2 Actions in Path Release Phase ............................ 9 4. Message Format .............................................. 10 4.1 Hop Count Object ........................................... 11 4.2 Ingress Object ............................................. 11 5. Security Considerations ..................................... 11 6. Intellectual Property Considerations ........................ 11 References ..................................................... 12 Authors Addresses ............................................... 12 Appendix A. Protocol Parameters ................................ 13 Appendix B. Examples of Optional Trigger Events ................ 13 Appendix C. Error Code ......................................... 14 1. Introduction This memo describes the specification of FANPv2 (Flow Attribute Notification Protocol version 2) Ingress Control Mode (IC Mode). The IC Mode is used for establishing and releasing a loop-free cut-through path from an ingress node to an egress node by forwarding FANP protocol messages along the path, whereas another mode of FANPv2, Distributed Control Mode (DC Mode) [1], operates independently of the states of other nodes. The IC mode supports a simple potential-loop prevention mechanism by using hop count and ingress node information, and a "retry" mechanism that tries to extend the cut-through path after path setup failures occur for some reason (e.g., ATM connection setup failure). In addition, the IC Mode as well as the DC mode support a mechanism to obtain a common identifier (e.g., VCID [2]) for a cut-through path between neighboring CSRs (Cell Switch Routers), including the case where intermediate L2 switches may rewrite the label value between the neighboring CSRs. 2. Terminology The following terms are defined only for the IC Mode. See the DC Mode protocol specification for other terms [1]. Ingress node: A node which initiates a cut-through path setup procedure, and is a starting point of the path. Egress node: A node which becomes a termination point of a cut-through path. There are three types of egress nodes: actual egress node, proxy egress node, and temporal egress node. An Y. Ohba, et al. [Page 2] Internet Draft FANPv2 Ingress Control Mode December 1997 actual egress node is a node which is the final destination of the flow, or which is a routing boundary (e.g., flow deaggregation is needed) for the flow. A proxy egress node is a node that is not an actual egress node and does not invoke the "retry" operation to extend the current cut-through path. A temporal egress node is a node that is not an actual egress node and does invoke the "retry" operation to extend the current cut-through path. See Section 3.1.2 for details. The egress node for a cut-through path may change with time. One example is when the next hop node of a non-egress node for some flow becomes unrecognized as a FANP neighbor. In this case, the non-egress node becomes a proxy egress node. Trigger event: An event which triggers a setup or a release of a cut-through path. Mandatory trigger event: A trigger event which is defined in this specification. Optional trigger event: A trigger event which is not specified in this specification. Optional trigger events occur only at ingress nodes. Examples of optional trigger events are shown in Appendix B. 3. Cut-through Path Control Procedure 3.1. Overview of Ingress Control Mode In this section, basic operations for setup, retry, loop detection, release, and route change of a cut-through path are explained. In the IC Mode, a setup message for creating a cut-through path is sent when a setup trigger event occurs, and a release message for deleting the path is sent when a release trigger event occurs. There are two modes of passing protocol messages: pessimistic mode and optimistic mode. In the pessimistic mode, a node returns an ACK for a message after the node makes sure that the message has reached its final receiver (an egress node or an ingress node). In the optimistic mode, in contrast, a node returns the ACK immediately after the node accepts the message. The optimistic mode is used for quick response from the neighbor when it is guaranteed that the message will be forwarded along a loop-free path, and otherwise the pessimistic mode is used for loop prevention. For simplicity, VCs on point-to-point links are assumed for the dedicated VCs used in Section 3.1. Detailed procedures depending on the dedicated VC types are described in Section 3.2. Note that the both the IC and DC modes use the same neighbor discovery protocol. See the neighbor discovery protocol specification [3] for the detailed procedure. Y. Ohba, et al. [Page 3] Internet Draft FANPv2 Ingress Control Mode December 1997 3.1.1. Path Establishment The pessimistic mode is adopted for the path establishment procedure to prevent loops for a newly created cut-through path. There are four mandatory trigger events that invoke a path establishment procedure: (1) reception of a NOTIFY message from a previous node (described below), (2) retry event at a temporal egress node (described in Section 3.1.2), (3) discovery of a new downstream FANP neighbor at a proxy egress node, and (4) route change for the flow at a node whose next hop on the new route is a FANP neighbor (described in Section 3.1.5). When a mandatory or an optional trigger event for a flow occurs at an ingress node, the node prepares an outgoing dedicated VC and informs the downstream neighbor of the mapping between the flow and the dedicated VC by sending a NOTIFY message. When a mandatory trigger event occurs at a node other than an ingress node, the node registers the mapping between the flow and the incoming dedicated VC (if it is not an ingress node), prepares an outgoing dedicated VC for the flow, and informs the downstream neighbor of the mapping between the flow and the dedicated VC by sending a NOTIFY message. These procedures are repeated until a NOTIFY message reaches the egress node for the flow. Finally, when the egress node receives a NOTIFY message, it registers the mapping between the flow and the incoming dedicated VC, and returns a NOTIFY ACK message to the upstream neighbor. The NOTIFY ACK message is returned on the reverse path for the flow. Each intermediate node which receives the NOTIFY ACK message is able to carry out cut-through forwarding by concatenating the incoming and outgoing dedicated VCs. Finally, when the ingress node receives the NOTIFY ACK message, the node is able to start putting the datagrams belonging to the flow into the outgoing dedicated VC. If a node receives a NOTIFY message which is not acceptable for some reason (e.g., an invalid flow is specified, or a loop is detected), it immediately returns an ERROR message to the upstream neighbor, instead of forwarding the NOTIFY message to the downstream neighbor. When a node which transmitted a NOTIFY message receives the ERROR message instead of a NOTIFY ACK message, it becomes a temporal or proxy egress node depending on the error code (see Appendix C), and returns a NOTIFY ACK message to the upstream neighbor. If the node becomes a temporal egress node, the path will be extended by the retry mechanism described in Section 3.1.2. NOTIFY messages are retransmitted until a NOTIFY ACK or an ERROR Y. Ohba, et al. [Page 4] Internet Draft FANPv2 Ingress Control Mode December 1997 message is received. The retransmission timer (NOTIFY Timer) is set to min(2**(m+1), 64) seconds, where m means the current number of transmissions. On the 5th expiration of the NOTIFY timer, the node starts the path release procedure by sending a REMOVE message to the downstream neighbor (described in 3.1.4), and returns a NOTIFY ACK message to its upstream neighbor. A node which fails retransmission becomes a temporal egress node for the flow. NOTIFY messages contain a hop count from an ingress node (referred to as Hb) and ingress information, while NOTIFY ACK messages contain a hop count from an egress node (referred to as He) and ingress information. Ingress information is composed of an IP address at an ingress node's output interface and a local ID which is allocated locally at the output interface. This information is used for detecting potential loops (see Section 3.1.3). Ingress nodes set hop-count=1 in their NOTIFY messages. Egress nodes set hop-count=1 in their NOTIFY ACK messages. Intermediate nodes increment the hop counts in the NOTIFY or NOTIFY ACK messages by one. Usage of the hop counts and ingress node information fields are described in detail in Section 3.1.3. 3.1.2. Retry If a node fails to set up a cut-through path or receives an ERROR message with specific error codes, it becomes a temporal egress node, and sets a RETRY timer to extend the cut-through path toward the flow's destination. When the RETRY timer expires, the node resends a NOTIFY message to the downstream neighbor and waits for a NOTIFY ACK. The NOTIFY message is forwarded following the same procedure described in Section 3.1.1. When the node that initiated the retry operation receives a NOTIFY ACK with an updated hop count, it must notify the upstream node of the updated hop count by sending an UPDATE message. The hop count update operation is described in Section 3.1.6. 3.1.3. Loop Prevention A node detects a potential-loop when (1) the hop count in the NOTIFY message exceeds a threshold or (2) the specified VCID in the NOTIFY message is different from that already registered for the specified FlowID and ingress node information. The node which meets one of the conditions above returns an ERROR message with error code = "hop count threshold exceeded" for the former condition, and with error code = "same FlowID and Ingress Object already registered on different interface" for the latter condition. If both conditions (1) and (2) are met at the same time, condition (1) always precedes condition (2) (See Appendix C). With condition (2), message loops can be detected without waiting for the hop count to exceed the threshold. There are some cases where a loop is mis-detected during a transient Y. Ohba, et al. [Page 5] Internet Draft FANPv2 Ingress Control Mode December 1997 state of the routing protocol where the path release procedure and the path establishment procedure may occur in parallel for the same flow. In such cases, the potential-loop detection mechanism works as a mechanism for preventing the node from increasing the number of transient cut-through paths rather than loop prevention, especially when the route is flapping. 3.1.4. Path Release The optimistic mode is adopted for the path release procedure since the released path is guaranteed to be a loop-free path. The mandatory trigger events to release a cut-through path are: (1) the node receives a flow removal request (by receiving a REMOVE message) for an existing path from its upstream node, (2) the upstream or downstream neighbor for the flow becomes unrecognized as a FANP neighbor, or (3) the next hop neighbor changes. When a mandatory or an optional release trigger event occurs at a node, the node disables cut-through forwarding between the incoming and outgoing dedicated VCs (if the node is not an ingress), and then sends a REMOVE message in order to inform the downstream neighbor of the removal of the mapping between the flow and the dedicated VC. When a node receives a REMOVE message, it immediately returns a REMOVE ACK message to the upstream neighbor. When a node receives a REMOVE ACK message after sending a REMOVE message, the node removes mapping between the flow and outgoing dedicated VC. REMOVE messages are retransmitted until a REMOVE ACK message is received. The retransmission timer values for these messages are set to min(2**m, 64) sec., where m means the current number of transmissions of this message. Note that if a node becomes unrecognized, the upstream node for the node removes the mapping between the flow and the outgoing dedicated VC without sending a REMOVE message. See Section 3.2 for detailed path release procedure. 3.1.5. Route Change When a route for a cut-through path is changed, the following operation is carried out at each node that detected the route change. First, the path release procedure described in Section 3.1.4 is invoked on the old route to release the dedicated VC on the old route (triggered by the mandatory release trigger (3)). After finishing the path release procedure, the node that detected the route change starts the path establishment procedure described in Section 3.1.1 on the new route (triggered by the mandatory setup Y. Ohba, et al. [Page 6] Internet Draft FANPv2 Ingress Control Mode December 1997 trigger (4)). When the node that initiated the route change operation receives a NOTIFY ACK message with an updated hop count, it must notify the the upstream node of the updated hop count by using an UPDATE message. The hop count update operation is described in Section 3.1.6. Note that the route change operation may be carried out concurrently at multiple nodes. 3.1.6. Hop Count Change When a node realizes that the number of hops from the egress node of a path is changed due to an event such as a route change, success of retry, recognition of a new neighbor, or loss of an existing neighbor, it memorizes the updated hop count, and sends an UPDATE message to its upstream neighbor with the updated hop count. The upstream node returns an UPDATE ACK to its downstream node based on the optimistic mode since the updated path is guaranteed to be a loop-free path. Finally, when the UPDATE message arrives at the ingress node, the node replies with an UPDATE ACK message and may decrement the TTL with the new hop count value. UPDATE messages are retransmitted until an UPDATE ACK message is received. The retransmission timer value for the UPDATE message is set to min(2**m, 64) sec., where m means the current number of transmissions of this message. 3.2. Actions Dependent on VC Type Actions taken during the path establishment or release procedures differ depending on the VC types. There are 4 VC types: VC on point-to-point link (P-to-P Link VC), VC within an ATM VP, ATM PVC, and ATM SVC. A P-to-P Link VC is a VC which is set up between directly connected neighboring nodes, i.e., there are no intermediate ATM switches in between and hence the VPI and VCI are not rewritten between them. A VC within an ATM VP is contained in a VP that is pre-allocated between a pair of neighboring nodes. If there is only one VP used for cut-through transfer between the neighboring nodes, the VC is called a VP Type1 VC, otherwise VP Type2 VC. For VP Type1 and Type2 VCs, VCIs are not rewritten between neighboring nodes. Different procedures are taken for VP Type1 VCs and VP Type2 VCs. An ATM PVC is a VC which is set up manually at system startup time. Both the VCI and VPI are rewritten between neighboring nodes for an ATM PVC. An ATM SVC is a VC which is set up between neighboring nodes by using ATM signaling. There are two types of ATM SVCs. A BLLI-capable SVC is an ATM SVC which is set up by using an ATM signaling message Y. Ohba, et al. [Page 7] Internet Draft FANPv2 Ingress Control Mode December 1997 that contains unique identifier of the SVC (termed "LLID") in BLLI (Broadband Low Layer Information) IE [4]. A BLLI-incapable SVC is an ATM SVC which is set up by using an ATM signaling message that does not contain LLID. Actions taken for BLLI-capable SVCs and BLLI-incapable SVCs are also different depending on whether a VC pool is available or not. Both the VCI and VPI are rewritten between neighboring nodes for an ATM SVC. 3.2.1. Actions in Path Establishment Phase There are three procedures taken during the path establishment phase, in the following order: dedicated VC setup procedure, VCID notification procedure, and flow notification procedure. The dedicated VC setup procedure is the procedure to prepare a dedicated VC for current or future use. For PVCs, VP Type1 and Type2 VCs, or P-to-P VCs, the dedicated VC setup procedure is invoked prior to cut-through path setup trigger events (e.g., system startup time). For SVCs with VC pool operation [2], the procedure is also carried out prior to cut-through path setup trigger events by invoking ATM signaling. For SVCs without VC pool operation, the procedure is carried out on demand by calling ATM signaling. The VCID notification procedure is used to obtain a common identifier for a cut-through path between neighboring CSRs in the case where the allocated VCIs for the same VC are different between the neighboring CSRs. There are three different VCID notification procedures depending on the VC type. 1. For a BLLI-capable SVC with VC pool, a NOTIFY[LLID,VCID] message in which the FlowID field is set to zero is transmitted on the default VC in order to indicate the mapping between the LLID (Low Layer ID) [1] and the VCID for the dedicated VC. After this notification, the VCID is used as an identifier for the VC. 2. For a PVC, a VP Type2 VC, and a BLLI-incapable SVC, a PROPOSE message is transmitted on the dedicated VC itself to indicate the VCID for the dedicated VC. 3. For a BLLI-capable SVC without VC pool and a VP Type1 VC, the VCID notification procedure is integrated into the flow notification message (see below). The VCID notification procedure completes when the node receives a NOTIFY ACK for the NOTIFY[LLID,VCID] message or a PROPOSE ACK for the PROPOSE message from the downstream neighbor. NOTIFY[LLID,VCID] and PROPOSE messages are retransmitted until a NOTIFY ACK or a PROPOSE ACK message is received, respectively. The retransmission timer (NOTIFY Timer or PROPOSE Timer) is set to min(2**(m+1), 64) seconds, where m means the current number of transmissions of the message. On the 5th expiration of the retransmission timer, the node invokes the path release procedure. The flow notification procedure is used to inform the neighbor of Y. Ohba, et al. [Page 8] Internet Draft FANPv2 Ingress Control Mode December 1997 the mapping between the FlowID and VCID of the dedicated VC. For a BLLI-capable SVC without VC pool, a NOTIFY[LLID,VCID,FlowID] message in which each of the LLID, VCID, and FlowID fields contains a non-zero value is transmitted on the default VC, integrating the VCID notification and flow notification procedures. For other VCs, a NOTIFY[VCID,FlowID] message in which the LLID field is set to zero is transmitted on the default VC. The flow notification procedure completes when the node receives a NOTIFY ACK or an ERROR message from the downstream neighbor. NOTIFY[(LLID,)VCID,FlowID] messages are retransmitted until a NOTIFY ACK message or an ERROR message is received. The retransmission timer (NOTIFY Timer) is set to min(2**(m+1), 64) seconds, where m means the current number of transmissions of the message. On the 5th expiration of the retransmission timer, the node invokes the path release procedure. The IC and DC modes take the same actions in the dedicated VC setup and VCID notification procedures for each VC type [1]. The flow notification procedure is different between the IC and DC modes in that (i) a NOTIFY[(LLID,)VCID,FlowID] message used in the IC mode contains additional information (hop count and ingress information) and (ii) in the IC mode, a NOTIFY ACK message is not immediately sent back after receiving a NOTIFY [(LLID,)VCID,FlowID] message, as described in Section 3.1.1. 3.2.2. Actions in Path Release Phase There are three procedures in path release phase: flow removal procedure, VCID removal procedure, and dedicated VC release procedure. The flow removal procedure is the procedure to indicate the neighbor to remove the mapping between the FlowID and VCID of the dedicated VC. The VCID removal procedure is the procedure to indicate the neighbor to remove the mapping between the VCID and the dedicated VC which is created by the VCID notification procedure. The dedicated VC release procedure is the procedure to release a dedicated VC which is prepared in the path setup procedure. In these procedures, REMOVE messages are sent to downstream neighbors. There are two types of REMOVE messages: REMOVE_ALL message and REMOVE_FLOW message. For SVCs without VC pool operation, all three procedures are performed by sending a REMOVE_ALL message when the path release trigger event occurs. For other VC types, only the flow removal procedure is carried out by sending a REMOVE_FLOW message, and other procedures are carried out only under abnormal situations (e.g., reset operations). There are also two types of REMOVE ACK messages. A REMOVE_ALL ACK message and a REMOVE_FLOW ACK message are returned for a REMOVE_ALL message and a REMOVE_FLOW message, respectively, without waiting for an ACK from the Y. Ohba, et al. [Page 9] Internet Draft FANPv2 Ingress Control Mode December 1997 downstream neighbor (optimistic mode). The IC and DC modes take the same actions in these three procedures between neighboring nodes. 4. Message Format The IC Mode specific message format is defined below. Other message formats are the same as in the DC Mode [1]. NOTIFY[VCID,FlowID] : = NOTIFY ACK[VCID,FlowID] : = NOTIFY[LLID,VCID,FlowID] : = 0)> NOTIFY ACK[LLID,VCID,FlowID] : = 0)> ERROR : = UPDATE : = UPDATE ACK : = The definition of objects which is used only in the IC Mode is Y. Ohba, et al. [Page 10] Internet Draft FANPv2 Ingress Control Mode December 1997 described below. 4.1 Hop Count Object 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 = 4| Hop Count | Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Type = 4 Object Length = 4 Hop Count: Contains a hop count value. 4.2 Ingress Object 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 = 5| Reserved | Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Local ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Type = 5 Object Length = 12 Ingress IP Address: Contains an output interface IP address of the ingress node. Ingress Local ID: Contains an id which is unique in the output interface specified in the Ingress IP Address field. This field is used when multiple cut-through paths are set up for the same FlowID from the same output interface. The default value is 0. 5. Security Considerations Security issues are not discussed in this document. 6. Intellectual Property Considerations Toshiba Corporation may seek patent or other intellectual property protection for some or all of 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. Y. Ohba, et al. [Page 11] Internet Draft FANPv2 Ingress Control Mode December 1997 References [1] K. Nagami et al., FANPv2 Distributed Control Mode," Internet Draft, draft-nagami-csr-fanpv2-dcmode-00.txt, Nov. 1997. [2] Y. Katsube et al., "Cell Switch Router -- Architecture and Protocol Overview," Internet-Draft, draft-katsube-csr-arch-00.txt, Nov. 1997. [3] K. Nagami et al., "FANPv2 Neighbor Discovery Protocol Specification," Internet Draft, draft-nagami-csr-fanpv2-nd-00.txt, Nov. 1997. [4] The ATM Forum Technical Committee, "User-Network Interface (UNI) Specification Version 3.1," Sep. 1994. Authors Address Yoshihiro Ohba R&D Center, Toshiba Corp., 1, Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Tel: +81-44-549-2238 Fax: +81-44-520-1806 Email: ohba@csl.rdc.toshiba.co.jp Jun-ichi Takahashi Network Development Dept., Hino Works, Toshiba Corp., 3-1-1, Asahigaoka Hino, Tokyo, 191, Japan Tel: +81-42-585-3447 Fax: +81-42-589-7441 Email: takahasi@atm.hino.toshiba.co.jp Shigeo Matsuzawa R&D Center, Toshiba Corp., 1, Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Tel: +81-44-549-2238 Fax: +81-44-520-1806 Email: shigeom@isl.rdc.toshiba.co.jp Yasuhiro Katsube R&D Center, Toshiba Corp., 1, Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Tel: +81-44-549-2238 Fax: +81-44-520-1806 Email: katsube@isl.rdc.toshiba.co.jp Y. Ohba, et al. [Page 12] Internet Draft FANPv2 Ingress Control Mode December 1997 Appendix A. Protocol Parameters o Timers (m: the number of transmissions, m>=1) + min(2**m,64) sec. for PROPOSE and NOTIFY[LLID,VCID] timers. + min(2**(m+1),64) sec. for NOTIFY[VCID,FlowID] and NOTIFY[LLID,VCID,FlowID] timers. + min(2**m,64) sec. for REMOVE timer. + min(2**m,64) sec. for UPDATE timer. + RETRY timer is variable depending on the reason of retry. The default RETRY timer is 64 sec. o The maximum number of message retransmissions/retries + 3 times for PROPOSE and NOTIFY[LLID,VCID] messages. + 5 times for NOTIFY[VCID,FlowID] and NOTIFY[LLID,VCID,FlowID] messages. + unlimited number of times for REMOVE and UPDATE messages. + unlimited number of times for retry operation. o The default hop count threshold = 16. Appendix B. Examples of Optional Trigger Events If the FlowID is given by destination network prefix (e.g., a pair of destination IP (network) address and netmask), two types of optional trigger events can be considered: 1. For protocol traffic driven case, a setup trigger event is given by a routing table creation event, and a release trigger event is given by a routing table deletion event. If the next hop node for a routing table entry is updated, a setup trigger event and a release trigger event are created in turn. 2. For data traffic driven case, a setup trigger event is created when the data rate for the network prefix exceeds a threshold, and a release trigger is created when the data rate for the network prefix falls below a threshold. Note that for both cases, the setup trigger event for the default route (network prefix with all 0's) must not be created. Y. Ohba, et al. [Page 13] Internet Draft FANPv2 Ingress Control Mode December 1997 Appendix C. Error Code When an ERROR message is sent, the following error codes are set. The retry operation does not have to be taken (the received node becomes a proxy egress node) unless explicitly stated : o If the received LLID is invalid, set error code = 9 (unknown LLID). o If the received VCID Type is invalid, set error code = 1 (unknown VCID Type). o If the received VCID is invalid, set error code = 2 (unknown VCID). o If the received FlowID Type is invalid set error code = 3 (unknown FlowID Type). o If the received FlowID is invalid (e.g., IPv4 Class D address prefix is specified), set error code = 4 (unknown FlowID). o If the received Hop Count exceeds the threshold, set error code = 7 (hop count threshold exceeded). o If an incoming VCID which is different from the received VCID is already allocated for the received FlowID Type, FlowID, and Ingress Object, or if an outgoing VCID is already registered for the received FlowID Type, FlowID, and Ingress Object, set error code = 8 (same FlowID and Ingress Object already registered on different interface). The retry operation is invoked. o If there is no enough resource to accept the message, set error code = 5 (resource unavailable). The retry operation is invoked. o If the specified flow must be refused by policy, set error code = 6 (refuse by policy). Note that if more than one conditions above are met at the same time, upper items precedes the lower ones. For example, if both LLID and FlowID are invalid, error code = 9 (unknown LLID) is set. Y. Ohba, et al. [Page 14]