rfc2129.txt

RFC 的详细文档！

       else Send an ERROR(resource unavailable).

   The upstream node retransmits the PROPOSE message when it neither
   receive PROPOSE ACK message nor ERROR message.  When the upstream
   node has received neither of the messages even with five
   retransmissions of the PROPOSE message, the Dedicated-VC picked up
   through the Dedicated-VC selection procedure should be released.
   Here, the number of retransmissions (five in this specification)is
   recommended value and can be modified in the future.

   The purpose of the VCID negotiation procedure is not only to share
   the VCID information regarding the Dedicated-VC, but also to confirm
   whether the Dedicated-VC is available and whether the neighbor node
   operates correctly.

   If the VCID negotiation procedure with a neighbor node always fails,
   it is considered that the node may not be FANP-capable node.
   Therefore the upstream node should not try the VCID negotiation
   procedure to that node for a certain time period.

5.3 Flow-ID Notification Procedure

   After the VCID negotiation procedure, the upstream node transmits an
   OFFER message to the downstream node through the Default-VC.  The
   OFFER message contains the VCID of the Dedicated-VC, the flow-ID of
   the packet flow transferred through the Dedicated-VC and the refresh
   interval of a READY message.

   When the downstream node receives the OFFER message from the upstream
   node, it transmits the READY message to the upstream node through the
   Default-VC in order to indicate that the OFFER message issued by the
   upstream node is accepted.  By the reception of the READY message,
   the upstream node realizes that the downstream node can receive IP
   packets transferred through the Dedicated-VC.



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


   The upstream node retransmits the OFFER message when it does not
   receive a READY message from the downstream node.  When the upstream
   node has not receive a READY message even with five retransmissions,
   the Dedicated-VC should be released.  Here, the number of
   retransmissions (i.e., five in this specification) is a recommended
   value and may be modified in the future.

   The node transmits an ERROR message to its neighbor in the following
   cases.  When the node receives the ERROR message, the Dedicated-VC
   should be released.

    (a) unknown VCID: The VCID in the message is unknown.
    (b) unknown VCID Type: The VCID Type is unknown.
    (c) unknown flow-ID Type: the flow-ID Type is unknown.

   When the downstream node accepts the OFFER message from the upstream
   node, it must send a READY message to the upstream node within the
   refresh interval offered by the upstream node.  If it can not, the
   downstream node sends the ERROR message (this refresh interval is not
   supported) to the upstream node.  The downstream node should accept
   the refresh interval larger than 120 seconds.  Therefore the
   downstream node shouldn't send the ERROR message (this refresh
   interval is not supported) when the refresh interval in the OFFER
   message is larger than 120 seconds.

   The following describes the procedure of the node which has received
   an OFFER message.

    1. if(unknown version in the OFFER message)
       then Discard the message.  Goto end.

    2. if(unknown VCID Type in the OFFER message)
       then Send an ERROR (unknown VCID Type) message.  Goto end.

    3. if(VCID in the OFFER message has not been registered)
       then Send an ERROR (unknown VCID) message.  Goto end.

    4. if(unknown Flow ID Type in the OFFER message)
       then Send an ERROR (unknown Flow ID Type) message.  Goto end.

    5. if(refuse Flow ID in the OFFER message)
       then Send an ERROR (refused by policy) message.  Goto end.

    6. if(refuse refresh interval in the OFFER message)
       then Send an ERROR(This refresh interval is not supported)
       message.  Goto end.





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


    7. if(the mapping between Flow ID and VCID already exists and
          Flow ID in the OFFER message is different from the registered
          Flow ID for the corresponding VCID)
       then Do Flow-ID removal procedure.  Goto end.

    8. Do the procedure of receiving the OFFER message.

    7. if(successful)
       then Send a READY message.
       else Send an ERROR (resource unavailable) message.

    8. end.

   The procedure of the node which has received a READY message is
   described.

    1. if(unknown version in the READY message)
       then Discard the message.  Goto end.

    2. if(unknown VCID Type in the READY message)
       then Send an ERROR (unknown VCID Type) message.  Goto end.

    3. if(VCID in the READY message has not been registered)
       then Send an ERROR (unknown VCID) message.  Goto end.

    4. if(unknown Flow ID Type in the READY message)
       then Send an ERROR (unknown Flow ID Type) message.  Goto end.

    5. if((the mapping between Flow ID and VCID doesn't exist)||
          (the mapping between Flow ID and VCID already exists and
           Flow ID in the READY message is different from registered Flow
           ID for the corresponding VCID))
       then Send an ERROR (unknown VCID) message.  Goto end.

    6. Do the procedure of receiving the READY message.

    7. end.

5.4 Flow ID Refresh Procedure

   While the downstream node receives IP packets through the Dedicated-
   VC, it should periodically (with a refresh interval) send the READY
   message to the upstream node.  When the downstream node does not
   receive any IP packet during the refresh interval, it does not send
   the READY message to the upstream node.






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


   While the upstream node continues to receive READY messages, it
   realizes that it can transmit the IP packets through the Dedicated-
   VC.  When it does not receive a READY message at all for a
   predetermined period (dead interval), it removes the mapping between
   the Flow IP and VCID.  The dead interval is defined below.

   When the upstream node falls into failure without the Flow ID removal
   procedure for a Dedicated-VC, its mapping must be removed by the
   downstream node.  The downstream node removes the mapping between the
   Flow ID and VCID for the Dedicated-VC when it does not receive any IP
   packet for a "removal period" (=refresh interval times m).

   The refresh interval, the dead interval and the removal period should
   satisfy the following equation.

    refresh interval < dead interval < removal period (=refresh
    interval times m)

    The recommended values are:
        refresh interval =  2 minutes
        dead interval    =  6 minutes (=refresh interval x 3)
        removal period  = 20 minutes (=refresh interval x 10)

5.5 Flow ID Removal Procedure

   When the upstream node realizes that the Dedicated-VC is not used, it
   performs a Flow ID removal procedure.

   The Flow ID removal procedure differs between the case of PVC/VP
   configuration and the case of SVC configuration.

   With the PVC/VP configuration, the upstream node issues a REMOVE
   message to the downstream node, and the downstream node sends back a
   REMOVE ACK message to the upstream node.  The upstream node
   retransmits REMOVE messages when it does not receive a REMOVE ACK
   message.  The upstream node assumes that the downstream node is in
   failure state when it dose not receive any REMOVE ACK message from
   the downstream node even with five REMOVE message retransmissions.













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


   With SVC configuration, two procedures are possible.  One is that the
   mapping between the Flow ID and the VCID is removed without the
   release of the ATM connection, which is the same procedure as the
   PVC/VP configuration.  The other procedure is that the mapping
   between the Flow ID and the VCID is removed by releasing the VC
   through ATM signaling.  The former procedure can promptly create and
   delete the mapping between Flow ID and VCID, since the ATM signaling
   does not have to be performed each time.  However, an un-used ATM
   connections have to be maintained by the node.  Which procedure is
   applied to is a matter of each CSR's local decision, taking the VC
   resource cost and responsiveness into account.

   The downstream node may want to remove the mapping between the Flow
   ID and the VCID.  When the upstream node receives the REMOVE message,
   it sends a REMOVE ACK message to the downstream node.

             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |           PROPOSE              |
               |===============================>|
      VCID     |       [VCID, target IP]        |
  negotiation  |          PROPOSE ACK           |
               |<===============================|
               |            [VCID]              |
               |                                |
               |            OFFER               |
               |===============================>|
     Flow-ID   |       [VCID, flow-ID]          |
  notification |            READY               |
               |<===============================|
               |       [VCID, flow-ID]          |
               |                                |
                    :         :           :
                    :         :           :
               |           READY                |
               |<===============================|
  Dedicated-VC |       [VCID, flow-ID]          |
  refresh      |           READY                |
               |<===============================|
               |       [VCID, flow-ID]          |

          Figure 2. Flow ID notification and refresh procedure








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


             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |                                 |
               |             REMOVE              |
               |================================>|
               |             [VCID]              |
               |                                 |
               |           REMOVE ACK            |
               |<================================|
               |             [VCID]              |

          (a) Flow ID removal (independent of ATM signaling)

             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |          ATM signaling          |
               |           (release)             |
               |<===============================>|
               |                                 |

            (b) Flow ID removal through ATM signaling

             Figure 3.  Flow ID removal procedure

6. Message Format

   FANP control procedure includes seven messages described from 6.2 to
   6.8.  Among them, a PROPOSE message used for VCID negotiation
   procedure uses an extended ATM ARP message format defined in RFC1577
   [2].  The other messages are encapsulated into IP packets.

   The destination IP address in the IP packet header signifies the
   neighbor node's IP address and the source IP address signifies
   sender's IP address.  Currently, the protocol ID for these messages
   is 110(decimal).  This protocol ID must be registered by IANA.

   The reserved field in the following packet format must be zero.












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


6.1 Field Format

6.1.1 VCID field

   VCID type value decides VCID field format.  Currently, only type "1"
   is defined.  The VCID field format of VCID type 1 is shown below.

     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 field: ESI of upstream node
       ID       : upstream node decides unique identifier.

6.1.2 Flow ID field

   Flow ID type value decides flow-ID field format.  Currently, flow-ID
   type "0" and "1" are defined.  The flow ID type value "0" signifies
   that the flow ID field is null.  When flow ID type value is "1", the
   format shown below is used.

     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                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+