Toshiba's Flow Attribute Notification Protocol (FANP) Specification
RFC 2129

Document Type RFC - Informational (April 1997; No errata)
Was draft-rfced-info-nagami (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2129 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          K. Nagami
Request for Comments: 2129                                    Y. Katsube
Category: Informational                                     Y. Shobatake
                                                                 A. Mogi
                                                            S. Matsuzawa
                                                               T. Jinmei
                                                                H. Esaki
                                                      Toshiba R&D Center
                                                              April 1997

  Toshiba's Flow Attribute Notification Protocol (FANP) Specification

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


   This memo discusses Flow Attribute Notification Protocol (FANP),
   which is a protocol between neighbor nodes for the management of
   cut-through packet forwarding functionalities. In cut-through packet
   forwarding, a router doesn't have to perform conventional IP packet
   processing for received packets.  FANP indicates mapping information
   between a datalink connection and a packet flow to the neighbor node
   and helps a pair of nodes manage the mapping information.  By using
   FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming
   packets based on their datalink-level connection identifiers,
   bypassing usual IP packet processing.  The design policy of the FANP

       (1)  soft-state cut-through path (Dedicated-VC) management
       (2)  protocol between neighbor nodes instead of end-to-end
       (3)  applicable to any connection oriented datalink platform

1.  Background

   Due to the scalability requirement, connection oriented (CO) datalink
   platforms, e.g., ATM and Frame Relay, are going to be used as well as
   connection less (CL) datalink platforms, e.g., Ethernet and FDDI.
   One of the important features of the CO datalink is the presence of a
   datalink-level connection identifier.  In the CO datalink, we can
   establish multiple virtual connections (VCs) with their VC
   identifiers among the nodes. When we aggregate packets that have the
   same direction (e.g., having the same destination IP address) into a
   single VC, we can forward the packets in the VC without IP

Nagami, et. al.              Informational                      [Page 1]
RFC 2129                   FANP Specification                 April 1997

   processing.  With this configuration, routers can decide which node
   is the next-hop for the packets based on the VC identifier.  CSRs [1]
   can forward the incoming packets using an ATM switch engine bypassing
   the conventional IP processing.  According to the ingress VPI/VCI
   value with ingress interface information, CSR determines the egress
   interface and egress VPI/VCI value.

   In order to configure the cut-through packet forwarding state, a pair
   of neighbor nodes have to share the mapping information between the
   packet flow and the datalink VC.  FANP (Flow Attribute Notification
   Protocol) described in this memo is the protocol to configure and
   manage the cut-through packet forwarding state.

2.  Protocol Requirements and Future Enhancement

2.1 Protocol Requirements

   The followings are the protocol requirements for FANP.

   (1) Applicable to various types of CO datalink platforms

   (2) Available with various connection types (i.e., SVC, PVC, VP)

   (3) Robust operation
       The system should operate correctly even under the following

        (a) VC failure
            Some systems can detect VC failure as the function of
            datalink (e.g., OAM function in the ATM).  However, we can
            not assume all nodes in the system can detect VC failure.
            The system has to operate correctly, assuming that every
            node can not detect VC failure.

        (b) Message loss
            Control messages in the FANP may be lost.  The system has to
            operate correctly, even when some control messages are lost.

        (c Node failure
            A node may be down without any explicit notification to its
            neighbors.  The system has to operate correctly, even with
            node failure.

   Though FANP is not the protocol only for ATM, the following
   discussion assumes that the datalink is an ATM network.

Nagami, et. al.              Informational                      [Page 2]
RFC 2129                   FANP Specification                 April 1997

2.2  Future Enhancement

   The followings are the future enhancements to be done.

        (1) Aggregated flow

          In this memo, we define the flow which contain source and
          destination IP address.  As this may require many VC
          resources, we also need a new definition of aggregated flow
Show full document text