Internet Draft Expiration Date: June 1998 Ken-ichi Nagami Yasuhiro Katsube Shigeo Matsuzawa Akiyoshi Mogi Koutarou Ise Toshiba Flow Attribute Notification Protocol Version 2 (FANPv2) Distributed 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-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) distributed control mode (DC-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. In the DC-mode, the control message exchange for a packet flow between each pair of neighboring CSRs is initiated independently from the message exchange for the same flow between any other pair of CSRs. The DC-mode is applicable to the control of both unicast and multicast cut-through paths. 1. Introduction The FANPv2 is a protocol used by Cell Switch Routers (CSRs)[1] to Nagami, et al. [Page 1] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 communicate mapping information between a specific packet flow and a virtual connection that conveys the packet flow. This draft describes the specification of FANPv2 distributed control mode (DC-mode), which is one of the two modes provided by the FANPv2 as described in [2]. In the DC-mode, the control message exchange for a packet flow between each pair of neighboring CSRs is initiated independently from the message exchanges for the same flow between any other pair of CSRs. The DC-mode is applicable to the control of both unicast and multicast cut-through paths. The following descriptions assume ATM as a cut-through switching technology although the protocol mechanism can be applied to the other switching technologies such as frame-relay. 2. Terminology and Definitions o VCID (Virtual Connection IDentifier) [8] An identifier of a virtual connection (ATM VC or VP) that is uniquely recognized by neighboring nodes. In the case that the VPI/VCI values at both endpoints of the VC are not the same, the VCID value is composed of the ESI (End System Identifier) of either of the neighboring nodes and the unique identifier within the node. In the case that the VPI/VCI value at one endpoint of a VC is maintained at another endpoint, the VPI/VCI value can be used as a VCID. o Cut-through forwarding Packet forwarding based on VPI/VCI values without layer 3 processing at the CSR. Layer 3 information (e.g., destination IP address) is associated with the corresponding VPI/VCI by using FANP. o Hop-by-Hop forwarding Packet forwarding based on layer 3 information like that of conventional routers. In ATM, cells are re-assembled into packets at the router, whose layer 3 headers are analyzed for making a forwarding decision. o Default-VC A VC that is used for hop-by-hop forwarding. Cells received from the Default-VC are reassembled into packets. Conventional layer 3 processing is performed for these packets. Control packets such as routing messages and FANP messages are also transmitted over this VC. o Dedicated-VC Nagami, et al. [Page 2] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 A VC that is used for a specific packet flow. When the FlowID for an incoming VC and that for an outgoing VC are the same at a CSR, it can forward the packets belonging to the flow with the cut-through forwarding. o Cut-through path A sequence of dedicated-VCs which transmit packets belonging to the same FlowID with the cut-through forwarding. o FlowID (Flow IDentifier) A set of parameters that identify a specific packet flow. For example, an end-to-end layer 3 flow is identified by the FlowID that contains a source IP address and a destination IP address. 3. Cut-through Path Control Procedure 3.1 Overview of the Distributed Control Mode (DC-mode) In the DC-mode, the cut-through path establishment procedure for a packet flow is initiated at individual nodes on its path in a distributed manner. Each of them transmits FANP control messages to its downstream neighbor in order to notify the mapping relationship between the packet flow and the outgoing dedicated-VC that will convey the flow. The downstream node that has received the control message from its upstream neighbor memorizes the received mapping information at its incoming interface, and transmits an acknowledgment to its upstream neighbor. This message exchange with an upstream neighbor at the node does not initiate the exchange of any control messages with its downstream neighbor. A control message exchange for a flow between a pair of CSRs is initiated and carried out independently from the message exchange for the same flow between any other pair of nodes. As a result of control message exchanges performed at individual pairs of nodes, a node can perform cut-through packet forwarding when it realizes that both the incoming dedicated-VC and the outgoing dedicated-VC are associated with the same FlowID. The cut-through path release procedure is also initiated at individual nodes on the path. A node that has detected the trigger to release the cut-through path transmits FANP control messages to its downstream neighbor in order to cancel the mapping relationship between the packet flow and the outgoing dedicated-VC that conveys the flow. The reception of the control messages from the upstream neighbor and the cancellation of the mapping relationship at an incoming interface of a node do not become the trigger for the Nagami, et al. [Page 3] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 control message transmission toward its downstream neighbor. Although concrete parameters for the cut-through establishment or release trigger are not specified in this document, generic control procedures in the case of two typical types of trigger (traffic-driven and request-driven control) are described below. This subsection describes cut-through path control procedure for the case that neighboring nodes are interconnected by the point-to-point link for simplicity. Procedures in the case that the neighboring nodes are interconnected over other types of ATM datalink are described in 3.2. 3.1.1 Traffic-driven Operation 3.1.1.1 Path Establishment / Release Figure 1 shows a traffic-driven path establishment procedure for unicast packet transmission from a sender H1 to a receiver H2. Ingress edge router R1, CSR core router R2, and egress edge router R3 are assumed to speak FANPv2 protocol. Ingress edge router R1 transmits packets toward its downstream neighbor R2 over a default-VC as a default behavior. When R1 decides that a packet flow satisfies specific conditions for cut-through path establishment, it initiates the path establishment procedure. It selects a dedicated-VC for the packet flow, then transmits a NOTIFY message, that notifies its downstream neighbor R2 of the mapping relationship between the packet flow and the selected dedicated-VC, to R2. The identifier of the packet flow (FlowID) is assumed to be source IP address H1 and destination IP address H2 (H1, H2). When R2 accepts the NOTIFY message sent by R1, it transmits a NOTIFY ACK message to R1, which concludes a flow notification step between R1 and R2. Similarly, when R2 decides that the same packet flow as above satisfies specific conditions for cut-through path establishment, it selects a dedicated-VC that conveys the flow, then transmits a NOTIFY message, that notifies its downstream neighbor R3 of the mapping relationship between the flow and selected dedicated-VC, to R3. When R3 accepts the NOTIFY message sent by R2, it transmits NOTIFY ACK message to R2, which concludes a flow notification step between R2 and R3. When R2 realizes that both the incoming dedicated-VC from R1 and the outgoing dedicated-VC to R3 are associated with the same flow, it can begin cut-through packet transmission by concatenating the incoming and the outgoing dedicated-VC at ATM level. Nagami, et al. [Page 4] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 Release of the cut-through paths is also performed by individual nodes that have detected triggers to release the path. Each of them transmits a REMOVE message, that notifies its downstream neighbor of removal of the mapping relationship between the packet flow and the dedicated-VC. The downstream node transmits a REMOVE ACK message to the upstream node, which concludes a flow removal step between neighboring nodes. Note that the removal of the mapping relationship for a packet flow at an incoming interface of a node does not initiate the flow removal step for the same flow at its outgoing interface. Examples of the trigger for cut-through path establishment and release are shown below. One or several of them could be selected as well as other triggers that are not itemized below. It is desirable that the common triggers are adopted in a domain. Establishment Trigger: - Transmission of a packet with specific upper layer protocols defined by the port-ID of TCP/UDP. (ex. http, ftp, and nntp) - Transmission of a TCP SYN packet. - Transmission of a packet with specific source/destination IP addresses. - Transmission of more than a certain amount of packets in a predetermined period. Release Trigger: - Decrease of the packet activity (no packet or less than a certain amount of packets in a predetermined period). - Change of a next-hop entry in a routing table related to an active cut-through path. - Recognition that a neighbor node isn't running through the neighbor discovery protocol [4]. A similar procedure is applicable to a traffic-driven multicast case. When establishing a multicast cut-through path, each node on the multicast tree selects a dedicated-VC toward each of its downstream neighbors, and then transmits a NOTIFY message, that conveys a mapping relationship between the multicast packet flow and the selected dedicated-VC, to each neighbors. The identifier of the multicast packet flow (FlowID) would be source IP address and multicast group address in the case that the source tree-based multicast routing (e.g., DVMRP) is applied, while it would be IP address of the core node and multicast group address in the case that the core-based multicast routing (e.g., PIM-SM) is applied. Trigger for cut-through establishment, e.g., transmission of multicast packet, is detected by each node in a manner similar to the unicast case. When a node has found a new multicast group member Nagami, et al. [Page 5] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 at one of its outgoing interfaces that was not the leaf of the tree, it performs the same procedure as the initial establishment toward the downstream neighbor at the interface. When a node, on the contrary, has recognized that a multicast group member has left the group at one of its outgoing interface, it performs the same procedure as the release of the cut-through toward the downstream neighbor at the interface. 3.1.1.2 Operation for Route Changes When a node has recognized a change of the next-hop (downstream neighbor) node for an active cut-through path, it stops cut-through forwarding and transmits a REMOVE message to cancel the mapping relationship for the related packet flow. The downstream node that has received the REMOVE message sends back a REMOVE ACK message, but does not perform the flow removal action toward its downstream neighbor unless its own next-hop entry for the packet flow has been changed. It will perform the flow removal action toward the downstream neighbor if there is no packet activity from the upstream neighbor. The node that has completed the flow removal action toward the old downstream neighbor performs the path establishment procedure toward the new downstream neighbor by one of the establishment triggers (e.g., transmission of a packet with specific upper layer protocols). +--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+ |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2| +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ trigger pkt |----------> trigger packet |-------------> trigger packet NOTIFY |--------------> trigger pkt ==============> NOTIFY |-----------> NOTIFY ACK ===============> <============== NOTIFY ACK <=============== |=============| Dedicated-VC |==============| Dedicated-VC Figure 1. 3.1.2 Request-driven Operation Nagami, et al. [Page 6] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 3.1.2.1 Path Establishment/Release Figure 2 shows a request-driven path establishment procedure for packet transmission from a sender H1 to a receiver H2. The procedure between neighboring nodes is the same as in the traffic-driven case. The difference is that the trigger for the path establishment or release is not related to the data packets but to the control packets such as the RSVP messages[7]. In the case that the path establishment or release is triggered by the RSVP messages, a cut-through path is established from downstream to upstream along with the RSVP reservation (Resv) messages. R2 that has received a Resv message from R3 performs the flow notification procedure by selecting a dedicated-VC for the requested flow and transmitting a NOTIFY message to R3. R2 realizes that the flow notification procedure has succeeded when it receives a NOTIFY ACK message from R3, and then transmits a Resv message to its upstream neighbor R1. R1 that has received Resv message from R2 performs the flow notification procedure between R2 similarly. R2, as a result, realizes that both the incoming dedicated-VC from R1 and the outgoing dedicated-VC toward R3 are associated with the same packet flow, and then is able to begin cut-through forwarding. Release of the cut-through paths is also performed by individual nodes that have recognized expiration of RSVP's reservation state. Each of them transmits a REMOVE message, that notifies its downstream neighbor of removal of the mapping relationship. The expiration of the RSVP reservation state is detected by either the reception of RSVP reservation tear message or the timeout of the state refresh period. Examples of the trigger for cut-through path establishment and release in the request-driven case are shown below. Establishment Trigger: - Establishment of the RSVP reservation state. Release Trigger: - Expiration of the RSVP reservation state. - Recognition that a neighbor node isn't running through the neighbor discovery protocol. Nagami, et al. [Page 7] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 +--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+ |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2| +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ Resv <----------| Resv Resv <--------------| Resv <-------------| NOTIFY <----------| NOTIFY ===============> ==============> NOTIFY ACK NOTIFY ACK <=============== <=============| |==============| |=============| Dedicated-VC Dedicated-VC Figure 2. 3.1.2.2 Operation for Route Changes In the operation driven by RSVP, unlike the case of the traffic-driven operation, a change of the next-hop node for the packet flow with cut-through forwarding does not initiate the procedure for changing the route of the cut-through path. Since the RSVP process itself has a functionality to determine the reservation path, e.g., route pinning, it is desirable that the route of the RSVP flow is controlled by the RSVP process rather than the native routing process. 3.2 Procedure Dependent on Datalink Type A previous subsection described the cut-through path control procedure for the case that neighboring FANP-capable nodes are interconnected by the point-to-point link for simplicity. In addition to the point-to-point link, it should be possible for the nodes to be interconnected over various types of datalink such as ATM networks that provide SVC services. This subsection describes FANP procedures between neighboring nodes which are interconnected over various types of ATM network as well as by the point-to-point link. 3.2.1 Operational Overview The FANP procedure between neighboring nodes is composed of : (1)Dedicated-VC setup, (2)VCID notification, and (3)Flow Nagami, et al. [Page 8] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 notification for cut-through establishment, and (4)Flow removal, (5)VCID removal, and (6)Dedicated-VC release for cut-through teardown. (1) Dedicated-VC setup : It is performed only when the neighboring nodes are interconnected over an ATM SVC network. An upstream node establishes a dedicated-VC, by using ATM signaling procedure, so as to be used as a cut-through path. (2) VCID notification : It is performed in the case that the VPI/VCI value of the cell transmitted by the upstream node and that of the cell received by the downstream node are not the same. Association between a dedicated-VC and "VCID", which is being commonly recognized by the neighboring nodes terminating the VC, is established at this step. One of the following two types of procedure is performed depending on the types of ATM network: i)use of an inband message (PROPOSE message) that is transmitted over the dedicated-VC being used, ii)use of a message (NOTIFY message) that associates an Information Element (IE) conveyed by an ATM signaling with a VCID value. (3) Flow notification : It is the core procedure that lets the neighboring nodes share the common knowledge about mapping relationship between a packet flow (FlowID) and a VCID. An upstream node notifies a downstream node of the mapping relationship (NOTIFY message), which is acknowledged by the downstream node (NOTIFY ACK message). VCID notification and flow notification can be merged into a single message when the two actions are performed consecutively (see 3.2.5.1). (4) Flow removal : It is performed to cancel the registered mapping relationship between a packet flow and a VCID. An upstream node transmits a REMOVE_FLOW or REMOVE_ALL message to a downstream node, which is acknowledged by the downstream node. The latter message is used to perform the flow removal and the VCID removal (described below) at once. (5) VCID removal : It is performed to cancel the association between the dedicated-VC and the VCID allocated at the VCID notification step. (6) Dedicated-VC release : It is performed only when the neighboring nodes are interconnected over an ATM SVC network. An upstream node Nagami, et al. [Page 9] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 releases a dedicated-VC, by using ATM signaling procedure. The following four types of datalink which interconnect neighboring FANP-capable nodes are possible: (a) Point-to-point link that interconnects neighboring nodes directly (b) PVC-based ATM network (c) VP-based ATM network that provides logical point-to-point link (d) SVC-based ATM network Some of the above-mentioned procedural steps (e.g., dedicated-VC setup and VCID notification) could be omitted in the case of certain datalink types, while all of the steps should be executed in the case of other datalink types. Detailed procedures for individual datalinks are described from 3.2.2 to 3.2.5. Note that the FANP procedure will not work until each node recognizes its neighbor nodes as FANP-capable through the neighbor discovery protocol specified in [4]. Any messages received from an unrecognized neighbor node must be discarded. All the messages described in this section have a Sender ID and a Receiver ID field except for a PROPOSE message. Each node should fill in each of these fields with a Local ID and a Peer ID in its neighbor table[4], respectively. If a Sender ID or a Receiver ID in the received message is different from the Peer ID or the Local ID in the neighbor table, the message must be discarded. All the FANP messages except for a PROPOSE message are conveyed over a default-VC. 3.2.2 Operation over Point-to-point Link In the operation over the point-to-point link, neither the dedicated-VC setup nor the dedicated-VC release is necessary since there is no conventional ATM switch between neighboring nodes. Neither the VCID notification nor the VCID removal is necessary since the VPI/VCI value of an outgoing cell at an upstream node and that of an incoming cell at a downstream node are the same in this case. When an upstream node has detected cut-through establishment trigger for a packet flow, it determines VPI/VCI value of an available dedicated-VC, and then transmits a NOTIFY[VCID, FlowID] message, that conveys the VPI/VCI value as a VCID and the FlowID of the packet flow, to its downstream neighbor node. The downstream node sends back either an NOTIFY ACK or an ERROR message to the upstream node. Nagami, et al. [Page 10] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 The upstream node periodically retransmits the NOTIFY[VCID, FlowID] message when it has received neither a NOTIFY ACK nor an ERROR message in a certain period of time. When it has not received any response after a number of retransmissions, it proceeds to a flow removal procedure described below. Default value of the retransmission interval and the number of retransmissions are described in Appendix C. When an upstream node has detected cut-through release trigger for a cut-through packet flow, it transmits a REMOVE_FLOW message, that includes a VCID value, to the downstream node. The downstream node sends back a REMOVE_FLOW ACK message to the upstream node. The upstream node periodically retransmits the REMOVE_FLOW message when it has not received REMOVE_FLOW ACK message in a certain period of time. Default value of the retransmission interval is described in Appendix C. 3.2.3 Operation over ATM PVC In the operation over ATM PVC network, a certain amount of PVCs is provided between neighboring nodes as an initialization procedure. One of the unused PVCs is picked up as a dedicated-VC when a node detects cut-through establishment trigger. As the VPI/VCI value of an outgoing cell at an upstream node and that of an incoming cell at a downstream node are not the same in general, it is necessary that the dedicated-VC is given a VCID which can be uniquely identified by both endpoints of the VC (VCID notification). An upstream side of the PVC transmits a PROPOSE message to a downstream side over the selected PVC itself, which conveys the VCID value being allocated to the PVC. The downstream node sends back a PROPOSE ACK message to the upstream node over a default-VC, which concludes the VCID notification step. The upstream node periodically retransmits the PROPOSE message when it has received neither a PROPOSE ACK nor a PROPOSE NACK message in a certain period of time. When it has not received any response after a number of retransmissions, it proceeds to a VCID removal procedure described below. Default value of the retransmission interval and the number of retransmissions are described in Appendix C. After the VCID notification procedure has been successfully completed, the flow notification and removal can be performed with the same procedure as the point-to-point link case described in 3.2.2. The VCID notification procedure can be performed immediately after the setup of the PVCs at the initialization phase, or when the cut-through establishment trigger is detected. Nagami, et al. [Page 11] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 The VCID value allocated to the PVC at the VCID notification step can be released by the VCID removal procedure. The upstream node transmits a REMOVE_ALL message to the downstream node, which is acknowledged by the downstream node with a REMOVE_ALL ACK message. The upstream node periodically retransmits the REMOVE_ALL message when it has not received REMOVE_ALL ACK message in a certain period of time. Default value of the retransmission interval is described in Appendix C. 3.2.4 Operation over ATM VP In the operation over ATM VP network, one or several ATM VPs are provided between neighboring nodes as an initialization procedure. One of the unused VCIs is picked up as a dedicated-VC when a node detects cut-through establishment trigger. When a single VP is provided between neighboring nodes, all the procedures are the same as in the case of the point-to-point link operation described in 3.2.2 since the VCI value of an outgoing cell at an upstream node and that of an incoming cell at a downstream node are the same. When multiple VPs are provided between neighboring nodes, on the other hand, the VCID notification step is necessary in order that both nodes recognize which VPI as well as VCI is going to be used as a dedicated-VC. 3.2.5 Operation over ATM SVC In the operation over ATM SVC network, dedicated-VCs as well as default-VCs are provided through the ATM signaling. Procedures for cut-through establishment and release differ depending on, (i)whether the BLLI(Broadband Low Layer Information) IE is available in the underlying ATM signaling, and (ii)whether the SVC for a dedicated-VC is set up each time the cut-through establishment trigger is detected or a number of surplus SVCs are prepared (VC pool[9]), one of which is picked up when the cut-through establishment trigger is detected. 3.2.5.1 On-demand SVC Setup with BLLI IE When an upstream node detects the cut-through establishment trigger, it selects an available temporal ID value called LLID (Low Layer ID) and an available VCID value, both of which are identifiers of a dedicated-VC to be set up, and then sets up a dedicated-VC by ATM signaling. The upstream node conveys the selected 7-bit LLID value in the "user specified layer 3 protocol information field" of the Nagami, et al. [Page 12] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 BLLI IE of a SETUP message. When the SVC setup has been completed, both the upstream and the downstream node memorize the LLID value as an identifier of the SVC. Then the upstream node transmits a NOTIFY[LLID, VCID, FlowID] message to the downstream node, which functions as a VCID notification and flow notification at the same time. At the time that the NOTIFY[LLID, VCID, FlowID] message is acknowledged by the downstream node, both nodes share the common knowledge about the identifier "VCID" of the dedicated-VC and about the association between the VCID and the "FlowID" that is the identifier of the packet flow transmitted over the dedicated-VC. The LLID value can be released at both nodes at this stage, and can be recycled for other SVCs that are being set up. When the upstream node detects the cut-through release trigger, it transmits a REMOVE_ALL message to the downstream node, which functions as a flow removal and VCID removal at the same time. Then the SVC is released by the ATM signaling. 3.2.5.2 On-demand SVC Setup without BLLI IE When the upstream node detects the cut-through establishment trigger, it selects an available VCID value as an identifier of a dedicated-VC to be set up, and then sets up a dedicated-VC by ATM signaling. The temporal ID of the SVC, that is commonly recognized by both nodes, is not able to be conveyed by the ATM signaling message in this case. When the SVC setup has been completed, the upstream node proceeds to a VCID notification step and a flow notification step that are the same as in the case of PVC described in 3.2.3. The flow removal, VCID removal, and dedicated-VC release procedure are the same as 3.2.5.1. 3.2.5.3 Operation with VC Pool In the case that a number of surplus unused SVCs are prepared as a pool, neighboring nodes do not have to perform the dedicated-VC setup/release procedure nor the VCID notification/removal procedure each time a specific cut-through establishment/release trigger is detected. When the upstream node detects the trigger to prepare an additional dedicated-VC as a pool, it initiates a dedicated-VC setup procedure and a VCID notification procedure. When the BLLI IE is supported by the ATM signaling, a temporal Nagami, et al. [Page 13] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 identifier of the SVC is selected by the upstream node and is conveyed by the SVC SETUP message as described in 3.2.5.1. Then the upstream node transmits a NOTIFY[LLID, VCID] message to the downstream node, which functions as a VCID notification. At the time that the NOTIFY[LLID, VCID] message is acknowledged by the downstream node, both nodes recognize that the new SVC, which is identified by the VCID, is registered into a "VC pool" for future use as a dedicated-VC. When the BLLI IE is not supported by the ATM signaling, the upstream node sets up an SVC without conveying its temporal identifier, and then proceeds to a VCID notification step that uses an inband PROPOSE message as described in 3.2.3. At the time that the PROPOSE message is acknowledged by the downstream node, both nodes recognize that the new SVC, which is identified by the VCID, is registered into a "VC pool" for future use as a dedicated-VC. One of the available SVCs in a VC pool is picked up as a dedicated-VC when a cut-through path is being set up. The flow notification and the flow removal procedures are the same as the procedure for the point-to-point link described in 3.2.2. When the association with a specific flow is canceled by the flow removal procedure, the SVC is returned to a VC pool for future use. 4. Message Format 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. VCID notification messages(PROPOSE, PROPOSE ACK, PROPOSE NACK) are carried in the extended ATM-ARP messages defined in RFC1577[6]. A PROPOSE message is transferred from the upstream node to the downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE NACK messages are transferred from the downstream node to the upstream node through the default-VC. The reserved field in the following packet format MUST be zero. 4.1 VCID Notification Message PROPOSE, PROPOSE ACK and PROPOSE NACK messages are used for VCID notification procedure. They use the extended ATM-ARP message format [6] to which the VCID type and the VCID field are added. Type & Length fields are set to zero, because the messages don't need sender/target ATM address. Nagami, et al. [Page 14] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 PROPOSE message is transferred from the upstream node to the downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE NACK messages are transferred from the downstream node to the upstream node through the default-VC. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Type = 0x13 | Protocol Type = 0x0800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type&Length 1 | Type&Length 2 | Operation Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length 1 | Type&Length 3 | Type&Length 4 | Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID Type |VCID Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type&Length 1 ; Type & Length of sender ATM number = 0 Type&Length 2 ; Type & Length of sender ATM subnumber = 0 Type&Length 3 ; Type & Length of sender ATM number = 0 Type&Length 4 ; Type & Length of sender ATM subnumber = 0 Length 1 ; Source IP address length Length 2 ; Target IP address length Operation code 0x10 = PROPOSE 0x11 = PROPOSE ACK 0x12 = PROPOSE NACK VCID Type: VCID Type field as described later VCID Length: Length of VCID field (Byte) VCID : VCID field as described later 4.2 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 . Nagami, et al. [Page 15] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 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. This flag is one if this message is for the IC-Mode[3]. 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 operation code = 5 : ERROR message operation code = 6 : NOTIFY message operation code = 7 : NOTIFY ACK message operation code = 8 : REMOVE_FLOW message operation code = 9 : REMOVE_FLOW ACK message operation code = 10 : REMOVE_ALL message operation code = 11 : REMOVE_ALL ACK message operation code = 12 : UPDATE message (used by IC-mode) operation code = 13 : UPDATE ACK message (used by IC-mode) 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. Sender ID The Local ID of the sender of the message. This field is zero for HELLO messages. Nagami, et al. [Page 16] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 Receiver ID The Local ID of the receiver of the message. This field is zero for HELLO and INIT messages. 4.3 FANP Objects 4.3.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. 4.3.2 Map Object A format of MAP OBJECT, which maps VCID, FlowID and LLID, is as follows. This object type is 1. 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 = 1| Reserved | Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID Type | FlowID Type | Error Code | LLID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowID | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Type : Set to 1 for Map Object Object Length : The length of the object (in bytes) includes the object header. Nagami, et al. [Page 17] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 VCID Type : The type of VCID. It is zero if no VCID field. FlowID Type : The type of FlowID. It is zero if no FlowID field. Error Code : If this message is ERROR message, the following error code is put into this field. Error Code = 1: unknown VCID Type Error Code = 2: unknown VCID Error Code = 3: unknown FlowID Type Error Code = 4: unknown FlowID Error Code = 5: resource unavailable Error Code = 6: refuse as a matter of policy Error Code = 7: hop count threshold exceeded (used by IC-mode) Error Code = 8: same FlowID received on different interface (used by IC-mode) Error Code = 9: unknown LLID LLID : The Low Layer ID (LLID) field. If LLID isn't needed, this field is zero. VCID : The VCID field as described latter. FlowID : The FlowID field as described latter. 4.3.2.1 VCID Field Format VCID type value decides VCID field format. Currently, only type "1" and "2" are defined. The VCID field format 1 is shown below. VCID Type = 1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESI of upstream node | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESI : IEEE 802 MAC address (ESI:End System Identifier [10]) of the upstream node. ID : A unique identifier allocated by the upstream node. Nagami, et al. [Page 18] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 VCID Type = 2: Explicit ATM Label (4 bytes) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Reservd| VPI | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.2.2 FlowID field FlowID type value decides FlowID field format. Currently, FlowID type "1", "2" and "3" are defined. The format is shown below. FlowID Type = 1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IP address : source IP address of a flow Destination IP address : destination IP address of a flow FlowID Type = 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol ID : protocol ID of a flow Source IP address : source IP address of a flow Destination IP address : destination IP address of a flow Source port : source port of a flow. If a flow doesn't have it, this field is zero. Destination port : destination port of a flow. If a flow doesn't have it, this field is zero. Nagami, et al. [Page 19] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 FlowID Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination network mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination IP address : destination IP address of a flow Destination network mask : netmask of a flow 4.3.3 Capability Object This object is only used by FANPv2-ND. The value of this object type is 2. Details are described in [4]. 4.3.4 VCID Range Object This object is only used by FANPv2-ND. The value of this object type is 3. Details are described in [4]. 4.3.5 Hop Count Object This object is only used by IC-Mode. The value of this object type is 4. Details are described in [3]. 4.3.6 Ingress Object This object is only used by IC-Mode. The value of this object type is 4. Details are described in [3]. 4.4 Examples of Message ERROR,NOTIFY,NOTIFY_ACK,REMOVE_FLOW,REMOVE_FLOW ACK,REMOVE_ALL and REMOVE_ALL ACK messages have a common header and one or more than one map objects. [ ....] 5. Security Considerations Nagami, et al. [Page 20] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 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. 7. References [1] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for ATM : Overview", RFC2098, Feb. 1997 [2] Y. Katsube, et al., "Cell Switch Router - Architecture and Protocol Overview -", Internet Draft draft-katusbe-csr-arch-00.txt(work in progress), Dec. 1997 [3] Y. Ohba, et al., "FANP Version 2 - Ingress Control Mode", Internet Draft draft-ohba-csr-fanpv2-icmode-00.txt(work in progress), Dec. 1997 [4] K. Nagami, et al., "FANP Version 2 - Neighbor Discovery", Internet Draft draft-nagami-csr-fanpv2-nd-00.txt(work in progress), Dec. 1997 [5] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, July 1993. [6] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Oct. 1993 [7] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)", RFC2205, Sep. 1997 [8] N. Demizu, et al., "VCID: Virtual Connection Identifier", Internet Draft draft-demizu-mpls-vcid-01.txt, Oct. 1997 [9] N. Demizu, et al., "VC Pool", Internet Draft draft-demizu-mpls-vcpool-00.txt, Oct. 1997 [10] "UNI Specification Version 3.1", ATM Forum, Sep. 1994 8. Authors' Addresses Nagami, et al. [Page 21] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 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 Yasuhiro Katsube Research and Development Center, Toshiba 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : katsube@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 Koutarou Ise Research and Development Center, Toshiba 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : ise@isl.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[6] 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 Nagami, et al. [Page 22] Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997 In the case of ATM, the encapsulation over default-VCs and dedicated-VCs is LLC encapsulation for routed non-ISO protocols defined by RFC1483 [5]. Appendix C: Default Timer value / Default resend times Timer: HELLO Timer : 60 sec Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec Resend Timer(others): 2,4,8,16,32,64,64,64,.... sec Resend Times: Resend PROPOSE : 3 times Resend NOTIFY : 3 times Nagami, et al. [Page 23]