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
<draft-ohba-csr-fanpv2-icmode-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-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] : =
<FANP_Fixed_Header(I Flag=1, OpCode=6)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID=0)>
NOTIFY ACK[VCID,FlowID] : =
<FANP_Fixed_Header(I Flag=1,OpCode=7)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID=0)>
NOTIFY[LLID,VCID,FlowID] : =
<FANP_Fixed_Header (I Flag=1,OpCode=6)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID>0)>
NOTIFY ACK[LLID,VCID,FlowID] : =
<FANP_Fixed_Header (I Flag=1,OpCode=7)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID>0)>
ERROR : =
<FANP_Fixed_Header (I Flag=1,OpCode=5)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID=0)>
UPDATE : =
<FANP_Fixed_Header (I Flag=1,OpCode=12)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID=FlowID=0)>
UPDATE ACK : =
<FANP_Fixed_Header (I Flag=1,OpCode=13)>
<Hop_Count_Object>
<Ingress_Object>
<Map_Object(LLID=FlowID=0)>
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]