rfc2129.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.

Abstract

   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
   is;

       (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
       conditions.

        (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
          which includes several end-to-end flows.  The concrete
          definition of the aggregated flow is for future study.

        (2) Providing multicast service
        (3) Supporting IP level QOS signaling like RSVP
        (4) Supporting IPv6

3. Terminology and Definition

   o VCID (Virtual Connection IDentifier)
      Since VPI/VCI values at the origination and the termination points
      of a VC (and VP) may not be the same, we need an identifier to
      uniquely identify the datalink connection between neighbor nodes.
      We define this identifier as a VCID.  Currently, only one type of
      VCID is defined.  This VCID contains the ESI (End System
      Identifier) of a source node and the unique identifier within a
      source node.

   o Flow ID (Flow IDentifier)
      IP level packet flow is identified by some parameters in a packet.
      Currently, only one type of flow ID is defined.  This flow ID
      contains a source IP address and a destination IP address.  Note
      that flow ID used in this specification is not the same as the
      flow-id specified in IPv6.

   o Cut-through packet forwarding
      Packets are forwarded without any IP processing at the router
      using the datalink level information (e.g.,VPI/VCI).
      Internetworking level information (e.g., destination IP address)
      is mapped to the corresponding datalink-level identifier by using
      the FANP.

   o Hop-by-Hop packet forwarding
      Packets are forwarded using IP level information like conventional
      routers.  In ATM, cells are re-assembled into packets at the
      router to analyze the IP header.






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


   o Default-VC
      Default-VC is used for hop-by-hop packet forwarding.  Cells
      received from the Default-VC are reassembled into IP packets.
      Conventional IP processing is performed for these packets.  The
      encapsulation over the Default-VC is LLC for routed non-ISO
      protocols defined by RFC1483 [3].

   o Dedicated-VC
      Dedicated-VC is used for the specific IP packet flow identified by
      the flow-ID.  When the flow-ID for an incoming VC and an outgoing
      VC are the same at a CSR, it can forward the packets belonging to
      the flow through the cut-through packet forwarding.  The
      encapsulation over the Dedicated-VC is LLC for routed non-ISO
      protocols defined by RFC1483 [3].

   o Cut-through trigger
      When a FANP capable node receives a trigger packet, it tries to
      establish Dedicated-VC and to notify the mapping information
      between the Dedicated-VC and the IP packet flow which the received
      trigger packet belongs to.  Trigger packets are defined by the
      port-ID of TCP/UDP with the local policy of each FANP capable
      node.  In general, they would be the port-ID's of sessions with a
      long life-time and/or with large amount of packets; e.g., http,
      ftp and nntp.  Future implementation will include other triggers
      such as an arrival of resource reservation request.

4. Protocol Overview

   Figure 1 shows an operational overview of FANP.  In the figure, a
   cut-through packet forwarding path is established from host 1 (H1) to
   host 2 (H2) using two Dedicated-VCs.  H1 and H2 are connected to
   Ethernets, and R1, R2 and R3 are routers which can speak FANP.  R1
   and R3 have both an ATM interface and an Ethernet interface.  R2 has
   two ATM interfaces.

   When R1 receives an IP packet from H1, R1 analyzes the payload of the
   received IP packet whether it is a trigger packet or not.  When the
   received packet is a trigger packet, R1 fetches a Dedicated-VC to its
   downstream neighbor(R2) and sends FANP messages.  FANP is effective
   between the neighboring nodes only.  The same procedure would be
   performed between R2 and R3 independently from the procedure between
   R1 and R2.  The flow-ID of the packet flow from H1 to H2 is
   represented as id(H1,H2).  Here, id(H1,H2) is the set of the IP
   address of H1 and that of H2.







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


   The Dedicated-VC is released when no packet is transferred on it for
   a given period.  We do not need to explicitly indicate release of the
   Dedicated-VC to the neighbor node, since the state management in FANP
   is of soft-state, rather than of hard-state.

    +--+ Ethernet +--+   +-----+   +--+   +-----+   +--+ Ethernet +--+
    |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
    +--+          +--+   +-----+   +--+   +-----+   +--+          +--+
       trigger pkt
       |----------> trigger packet
                    |------------->   trigger packet
                       FANP          |-------------->  trigger pkt
                    <=============>        FANP        |----------->
                                     <==============>

                    |=============|
                     Dedicated-VC    |==============|
                                       Dedicated-VC

             Figure 1. Trigger packet and FANP initiation

5. Protocol Sequence

   FANP has the following five procedures, that are (1) Dedicated-VC
   selection, (2) VCID negotiation, (3) flow-ID notification, (4)
   Dedicated-VC refresh and (5) Dedicated-VC release.  Procedures (2),
   (3) and (4) have nothing to do with the kind of the Dedicated-
   VC;i.e.,SVC,PVC or VP.  On the contrary, the procedures (1) and (5)
   with SVC are different from the procedures with PVC and with VP.

   The detailed procedures are described in the following subsections.

5.1 Dedicated-VC Selection Procedure

   A VC is picked up in order to use as a Dedicated-VC.  The ways of
   picking up the Dedicated-VC is either of the followings.

   (1) A number of VCs are prepared in advance, and registered into an
      un-used VC list.  When a Dedicated-VC is needed, one of them is
      picked up from the un-used VC list.

   (2) A new VC is established through ATM signaling on demand.

   With ATM PVC/VP configuration, a Dedicated-VC is activated by the
   procedure (1).






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


   With ATM SVC configuration, a Dedicated-VC is activated by the
   procedure (1) or (2).  When the procedure (1) is used, some number of
   VCs are prepared in advance through ATM signaling.  These VCs are
   registered into the un-used VC list.  When a Dedicated-VC is needed,
   a VC is picked up from the un-used VC list.  When the procedure (2)
   is used, a Dedicated-VC is established through ATM signaling each
   time it is required.

   The procedure (1) can decrease a time to activate a Dedicated-VC.
   But the necessary VC resource will increase as it need to prepare
   additional VCs.  Which procedure should be applied to is a matter of
   local decision in each node, taking the economical requirement and
   the system responsiveness into account.

   A Dedicated-VC is used as a uni-directional VC, although it is
   generally bi-directional.  This means that packets are transferred
   only from upstream node to downstream node in the Dedicated-VC. The
   packets from downstream node to upstream node are transferred through
   the Default-VC or through another Dedicated-VC.

5.2 VCID Negotiation Procedure

   After the Dedicated-VC selection procedure, the upstream node
   transmits the PROPOSE message to the downstream node through the
   Dedicated-VC.  The PROPOSE message contains a VCID for the
   Dedicated-VC and IP address (target IP address) of downstream node.
   When the downstream node accepts the PROPOSE message, it transmits
   the PROPOSE ACK message to the upstream node through the Default-VC.
   With this procedure, the upstream and the downstream nodes (both
   end-points of the Dedicated-VC) can share the same indicator "VCID"
   for the Dedicated-VC.  When the downstream node can not accept the
   proposal from the upstream node with some reason (e.g., policy), the
   downstream node sends an ERROR message to the upstream node through
   the Default-VC.

   The procedure at the downstream node which has received PROPOSE
   message is;

    1. if(Target IP address of the PROPOSE message isn't equal to my IP
          address)
       then Goto end.

    2. if(The PROPOSE message should be refused)
       then  Send an ERROR(refuse by policy) message. Go to end.

    3. if(VCID Type in the PROPOSE message isn't known)
       then Send an ERROR(unknown VCID Type) message. Go to end.




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


    4. if(The VCID in the PROPOSE message is  the same as the VCID which
       has already been registered for another Dedicated-VC in the node)
       then Delete the registered VCID.
       Release the old Dedicated-VC.

    5. if(A VCID is registered for the Dedicated-VC which has received
       the PROPOSE message)
       then Delete the registered VCID.

    6. Register the mapping between VCID and  I/F, VPI, VCI for the
       Dedicated-VC.

    7. if(The mapping is successful)
       then Send a PROPOSE ACK.