rfc1953.txt

RFC 的详细文档！

             Specifies the Flow Type of the Flow Identifier contained in
             the Flow ID field.

   Flow ID Length
             Specifies the length of the Flow Identifier field in
             integer multiples of 32 bit words.

   Reserved
             Field is unused and should be set to zero by the sender and
             ignored by the receiver.

   Label
             Field contains the label to be released.

   Flow Identifier
             Field contains the flow identifier to be unbound.

   A node can send a Reclaim message element to instruct an adjacent
   upstream node to unbind a flow from the label to which it is
   currently bound, return the flow to the default forwarding state, and
   release the label.  Each Reclaim message element applies to a single
   flow and a single label.  When the receiver has completed the
   operation, it must issue a Reclaim Ack message element.  Reclaim Ack
   message elements can be grouped together, in any order, into one or
   more IFMP Reclaim Ack messages and returned to the sender as an
   acknowledgment that the operation is complete.

   If a Reclaim message element is received indicating an unknown flow,
   a Reclaim Ack message element must be returned containing the same
   Label and Flow Identifier fields from the Reclaim message.





Newman, et. al.              Informational                     [Page 14]

RFC 1953                   IFMP Specification                   May 1996


   If a Reclaim message element is received indicating a known flow, but
   with a Label that is not currently bound to that flow, the flow must
   be unbound and returned to the default forwarding state, and a
   Reclaim Ack message sent containing the actual label to which the
   flow was previously bound.

   If the receiver detects an error in any of the fields of a Reclaim
   message element, the receiver must discard that message element,
   without affecting any other Reclaim message elements in the same
   message.  The receiver must return an error message to the sender
   only in the case that the receiver does not understand the version of
   the IFMP protocol in the received message or does not understand a
   Flow Type in one of the Reclaim message elements.

4.3 Reclaim Ack Message

   The Reclaim Ack message element is used by a receiving node to
   acknowledge the successful release of one or more reclaimed labels.

   Each Reclaim Ack message element has the following structure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Flow Type   | Flow ID Length|           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Label                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Flow Identifier                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flow Type
             Specifies the Flow Type of the Flow Identifier contained in
             the Flow Identifier field.

   Flow ID Length
             Specifies the length of the Flow Identifier field in
             integer multiples of 32 bit words.

   Reserved
             Field is unused and should be set to zero by the sender and
             ignored by the receiver.

   Label
             Field contains the label released from the flow specified
             by the Flow Identifier.



Newman, et. al.              Informational                     [Page 15]

RFC 1953                   IFMP Specification                   May 1996


   Flow Identifier
             Field contains the Flow Identifier from the Reclaim message
             element that requested the release of the label specified
             in the Label field.

   A Reclaim Ack message element must be sent in response to each
   Reclaim message element received.  It is sent to indicate that the
   requested flow is now unbound and that the label is now free.  If
   possible, each Reclaim Ack message element should not be sent until
   all data queued for transmission on the link, using the label
   specified for release, has been sent.

   If a Reclaim Ack message element is received specifying a flow for
   which no Reclaim message element was issued, that Reclaim Ack message
   element must be ignored, but no other Reclaim Ack message elements in
   the same message must be affected.

   If a Reclaim Ack message element is received specifying a different
   label from the one sent in the original Reclaim message element for
   that flow, the Reclaim Ack message element should be handled as if
   the reclaim operation were successful.

   If an error is detected in any of the fields of a Reclaim Ack message
   element, that message element must be discarded, but no other Reclaim
   Ack message elements in the same message must be affected.

   The receiver should return an Error message to the sender only in the
   case that the receiver does not understand the version of the IFMP
   protocol in the received message or does not understand a Flow Type
   in one of the Reclaim Ack message elements.

4.4 Label Range Message

   The Label Range message element is sent in response to a Redirect
   message if the label requested in one or more of the Redirect message
   elements is outside the range that the receiver of the Redirect
   message can handle.  The Label Range message informs the sender of
   the Redirect message of the label range that can be handled on the
   relevant link.

   Only a single Label Range message element is permitted in a Label
   Range message.  The Label Range message element has the following
   structure:








Newman, et. al.              Informational                     [Page 16]

RFC 1953                   IFMP Specification                   May 1996


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Minimum Label                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Maximum Label                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Minimum Label
             The minimum value of label that can be specified in an IFMP
             Redirection Protocol message across this link.

   Maximum Label
             The maximum value of label that can be specified in an IFMP
             Redirection Protocol message across this link.

   All values of label within the range Minimum Label to Maximum Label
   inclusive may be specified in an IFMP Redirection Protocol message
   across the link.

4.5 Error Message

   An Error message can be sent by a node in response to any IFMP
   Redirection Protocol message.

   Only a single Error message element is permitted in an Error message.
   The Error message element has the following structure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Error Code   |                  Parameter                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Error Code
             Specifies which an error has occurred.

   Each Error message can specify a single Parameter.











Newman, et. al.              Informational                     [Page 17]

RFC 1953                   IFMP Specification                   May 1996


   Two Error message elements are specified:


   Bad Version:

   Error Code = 1. The sender of the Error message cannot process the
             version of the IFMP protocol of the message that caused the
             error.  This message must only be sent if the version of
             the message that caused the error is greater than the most
             recent version that the sender of the Error message can
             process.  The parameter field of this Error message gives
             the most recent version of the IFMP protocol that the
             sender can process, right justified, with the unused most
             significant bits of the Parameter field set to zero.

   Bad Flow Type:

   Error Code = 2. The sender of the Error message does not understand a
             Flow Type that was received in the message that caused the
             error.  The Flow Type that caused the error is given in the
             parameter field, right justified, with the unused most
             significant bits of the Parameter field set to zero.





























Newman, et. al.              Informational                     [Page 18]

RFC 1953                   IFMP Specification                   May 1996


REFERENCES

      [ENCAP] Newman, P., et. al., "Transmission of Flow Labelled IPv4
               on ATM Data Links Ipsilon Version 1.0," Ipsilon Networks,
               RFC 1954, May 1996.

      [RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC
               793, September 1981.

SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

AUTHORS' ADDRESSES

   Peter Newman                        Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]

   W. L. Edwards, Chief Scientist      Phone:  [phone]
   Sprint                              EMail:  [e-mail]

   Robert M. Hinden                    Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]

   Eric Hoffman                        Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]

   Fong Ching Liaw                     Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]

   Tom Lyon                            Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]

   Greg Minshall                       Phone: [phone]
   Ipsilon Networks, Inc.              EMail: [e-mail]
















Newman, et. al.              Informational                     [Page 19]

RFC 1953                   IFMP Specification                   May 1996


Ipsilon Networks, Inc. is located at:

   2191 East Bayshore Road
   Suite 100
   Palo Alto, CA 94303
   USA

Sprint is located at:

   Sprint
   Sprint Technology Services - Long Distance Division
   9300 Metcalf Avenue
   Mailstop KSOPKB0802
   Overland Park, KS 66212-6333
   USA




































Newman, et. al.              Informational                     [Page 20]