home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1953.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  42.7 KB  |  1,124 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 P. Newman, Ipsilon
  8. Request for Comments: 1953                         W. L. Edwards, Sprint
  9. Category: Informational                               R. Hinden, Ipsilon
  10.                                                      E. Hoffman, Ipsilon
  11.                                                   F. Ching Liaw, Ipsilon
  12.                                                         T. Lyon, Ipsilon
  13.                                                     G. Minshall, Ipsilon
  14.                                                                 May 1996
  15.  
  16.  
  17.         Ipsilon Flow Management Protocol Specification for IPv4
  18.                               Version 1.0
  19.  
  20. Status of this Memo
  21.  
  22.    This document provides information for the Internet community.  This
  23.    memo does not specify an Internet standard of any kind.  Distribution
  24.    of this memo is unlimited.
  25.  
  26. IESG Note:
  27.  
  28.    This memo documents a private protocol for IPv4-based flows.  This
  29.    protocol is NOT the product of an IETF working group nor is it a
  30.    standards track document.  It has not necessarily benefited from the
  31.    widespread and in depth community review that standards track
  32.    documents receive.
  33.  
  34. Abstract
  35.  
  36.    The Ipsilon Flow Management Protocol (IFMP), is a protocol for
  37.    allowing a node to instruct an adjacent node to attach a layer 2
  38.    label to a specified IP flow.  The label allows more efficient access
  39.    to cached routing information for that flow.  The label can also
  40.    enable a node to switch further packets belonging to the specified
  41.    flow at layer 2 rather than forwarding them at layer 3.
  42.  
  43. Table of Contents
  44.  
  45.    1. Introduction....................................................2
  46.    2. Flow Types......................................................2
  47.    3. IFMP Adjacency Protocol.........................................4
  48.        3.1  Packet Format.............................................4
  49.        3.2  Procedure.................................................7
  50.    4. IFMP Redirection Protocol......................................10
  51.        4.1  Redirect Message.........................................12
  52.        4.2  Reclaim Message..........................................13
  53.        4.3  Reclaim Ack Message......................................15
  54.        4.4  Label Range Message......................................16
  55.  
  56.  
  57.  
  58. Newman, et. al.              Informational                      [Page 1]
  59.  
  60. RFC 1953                   IFMP Specification                   May 1996
  61.  
  62.  
  63.        4.5  Error Message............................................17
  64.    References........................................................19
  65.    Security Considerations...........................................19
  66.    Authors' Addresses................................................19
  67.  
  68. 1. Introduction
  69.  
  70.    The Ipsilon Flow Management Protocol (IFMP), is a protocol for
  71.    instructing an adjacent node to attach a layer 2 label to a specified
  72.    IP flow. The label allows more efficient access to cached routing
  73.    information for that flow and it allows the flow to be switched
  74.    rather than routed in certain cases.
  75.  
  76.    If a network node's upstream and downstream links both redirect a
  77.    flow at the node, then the node can switch the flow at the data link
  78.    layer rather than forwarding it at the network layer.  The label
  79.    space is managed at the downstream end of each link and redirection
  80.    messages are sent upstream to associate a particular flow with a
  81.    given label.  Each direction of transmission on a link is treated
  82.    separately.
  83.  
  84.    If the flow is not refreshed by the time the lifetime field in the
  85.    redirect message expires, then the association between the flow and
  86.    the label is discarded.  A flow is refreshed by sending a redirect
  87.    message, identical to the original, before the lifetime expires.
  88.  
  89.    Several flow types may be specified.  Each flow type specifies the
  90.    set of fields from the packet header that are used to identify a
  91.    flow.  There must be an ordering amongst the different flow types
  92.    such that a most specific match operation may be performed.
  93.  
  94.    A particular flow is specified by a flow identifier.  The flow
  95.    identifier for that flow gives the contents of the set of fields from
  96.    the packet header as defined for the flow type to which it belongs.
  97.  
  98.    This document specifies the IFMP protocol for IPv4 on a point-to-
  99.    point link.  The definition of labels, and the encapsulation of
  100.    flows, are specified in a separate document for each specific data
  101.    link technology.  The specification for ATM data links is given in
  102.    [ENCAP].
  103.  
  104. 2. Flow Types
  105.  
  106.    A flow is a sequence of packets that are sent from a particular
  107.    source to a particular (unicast or multicast) destination and that
  108.    are related in terms of their routing and any logical handling policy
  109.    they may require.
  110.  
  111.  
  112.  
  113.  
  114. Newman, et. al.              Informational                      [Page 2]
  115.  
  116. RFC 1953                   IFMP Specification                   May 1996
  117.  
  118.  
  119.    A flow is identified by its flow identifier.
  120.  
  121.    Several different flow types can be defined.  The particular set of
  122.    fields from the packet header used to identify a flow constitutes the
  123.    flow type.  The values of these fields, for a particular flow,
  124.    constitutes the flow identifier for that flow.  The values of these
  125.    fields must be invariant in all packets belonging to the same flow at
  126.    any point in the network.
  127.  
  128.    Flow types are sub- or super-sets of each other such that there is a
  129.    clear hierarchy of flow types.  This permits a most specific match
  130.    operation to be performed.  (If additional flow types are defined in
  131.    the future that are not fully ordered then the required behavior will
  132.    be defined.) Each flow type also specifies an encapsulation that is
  133.    to be used after a flow of this type is redirected.  The
  134.    encapsulations for each flow type are specified in a separate
  135.    document for each specific data link technology.  The encapsulations
  136.    for flows over ATM data links are given in [ENCAP].
  137.  
  138.    Three flow types are defined in this version of the protocol:
  139.  
  140.    Flow Type 0
  141.  
  142.       Flow Type 0 is used to change the encapsulation of IPv4 packets
  143.       from the default encapsulation.
  144.  
  145.       For Flow Type 0: Flow Type = 0 and Flow ID Length = 0.
  146.  
  147.       The Flow Identifier for Flow Type 0 is null (zero length).
  148.  
  149.    Flow Type 1
  150.  
  151.       Flow Type 1 is designed for protocols such as UDP and TCP in which
  152.       the first four octets after the IPv4 header specify a Source Port
  153.       number and a Destination Port number.
  154.  
  155.       For Flow Type 1, Flow Type = 1 and Flow ID Length = 4 (32 bit
  156.       words).
  157.  
  158.       The format of the Flow Identifier for Flow Type 1 is:
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Newman, et. al.              Informational                      [Page 3]
  171.  
  172. RFC 1953                   IFMP Specification                   May 1996
  173.  
  174.  
  175.        0                   1                   2                   3
  176.        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
  177.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.       |Version|  IHL  |Type of Service| Time to Live  |   Protocol    |
  179.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.       |                         Source Address                        |
  181.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.       |                      Destination Address                      |
  183.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.       |          Source Port          |       Destination Port        |
  185.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.  
  187.    Flow Type 2
  188.  
  189.       For Flow Type 2, Flow Type = 2 and Flow ID Length = 3 (32 bit
  190.       words).
  191.  
  192.       The format of the Flow Identifier for Flow Type 2 is:
  193.  
  194.        0                   1                   2                   3
  195.        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
  196.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  197.       |Version|  IHL  |   Reserved    | Time to Live  |   Reserved    |
  198.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  199.       |                         Source Address                        |
  200.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  201.       |                      Destination Address                      |
  202.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  203.  
  204.       The Reserved fields are unused and should be set to zero by the
  205.       sender and ignored by the receiver.
  206.  
  207. 3. IFMP Adjacency Protocol
  208.  
  209.    The IFMP Adjacency Protocol allows a host or router to discover the
  210.    identity of a peer at the other end of a link.  It is also used to
  211.    synchronize state across the link, to detect when the peer at the
  212.    other end of the link changes, and to exchange a list of IP addresses
  213.    assigned to the link.
  214.  
  215. 3.1 Packet Format
  216.  
  217.    All IFMP messages belonging to the Adjacency Protocol must be
  218.    encapsulated within an IPv4 packet and must be sent to the IP limited
  219.    broadcast address (255.255.255.255).  The Protocol field in the IP
  220.    header must contain the value 101 (decimal) indicating that the IP
  221.    packet contains an IFMP message.  The Time to Live (TTL) field in the
  222.    IP header must be set to 1.
  223.  
  224.  
  225.  
  226. Newman, et. al.              Informational                      [Page 4]
  227.  
  228. RFC 1953                   IFMP Specification                   May 1996
  229.  
  230.  
  231.    All IFMP messages belonging to the adjacency protocol have the
  232.    following structure:
  233.  
  234.     0                   1                   2                   3
  235.     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
  236.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.    |    Version    |    Op Code    |           Checksum            |
  238.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.    |                        Sender Instance                        |
  240.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.    |                         Peer Instance                         |
  242.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243.    |                         Peer Identity                         |
  244.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.    |                    Peer Next Sequence Number                  |
  246.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.    |         Reserved              |    Reserved   | Max Ack Intvl |
  248.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.    |                                                               |
  250.    ~                          Address List                         ~
  251.    |                                                               |
  252.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  253.  
  254.    Version
  255.              The IFMP protocol version number.  The current Version = 1.
  256.  
  257.    Op Code
  258.              Specifies the function of the message.  Four Op Codes are
  259.              defined for the IFMP Adjacency Protocol:
  260.  
  261.                 SYN:    Op Code = 0
  262.                 SYNACK: Op Code = 1
  263.                 RSTACK: Op Code = 2
  264.                 ACK:    Op Code = 3
  265.  
  266.    Checksum
  267.              The 16-bit one's complement of the one's complement sum of
  268.              a pseudo header of information from the IP header and the
  269.              IFMP message itself.  The pseudo header, conceptually
  270.              prefixed to the IFMP message, contains the Source Address,
  271.              the Destination Address, and the Protocol fields from the
  272.              IPv4 header, and the total length of the IFMP message
  273.              starting with the Version field (this is equivalent to the
  274.              value of the Total Length field from the IPv4 header minus
  275.              the length of the IPv4 header itself).
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Newman, et. al.              Informational                      [Page 5]
  283.  
  284. RFC 1953                   IFMP Specification                   May 1996
  285.  
  286.  
  287.    Sender Instance
  288.              For the SYN, SYNACK, and ACK messages, is the sender's
  289.              instance number for the link.  The receiver uses this to
  290.              detect when the link comes back up after going down or when
  291.              the identity of the peer at the other end of the link
  292.              changes.  The instance number is a 32 bit number that is
  293.              guaranteed to be unique within the recent past and to
  294.              change when the link or node comes back up after going
  295.              down.  It is used in a similar manner to the initial
  296.              sequence number (ISN) in TCP [RFC 793].  Zero is not a
  297.              valid instance number.  For the RSTACK message the Sender
  298.              Instance field is set to the value of the Peer Instance
  299.              field from the incoming message that caused an RSTACK
  300.              message to be generated.
  301.  
  302.    Peer Instance
  303.              For the SYN, SYNACK, and ACK messages, is what the sender
  304.              believes is the peer's current instance number for the
  305.              link.  If the sender of the message does not know the
  306.              peer's current instance number for the link, the sender
  307.              must set this field to zero.  For the RSTACK message the
  308.              Peer Instance field is set to the value of the Sender
  309.              Instance field from the incoming message that caused an
  310.              RSTACK message to be generated.
  311.  
  312.    Peer Identity
  313.              For the SYN, SYNACK, and ACK messages, is the IP address of
  314.              the peer that the sender of the message believes is at the
  315.              other end of the link.  The Peer Identity is taken from the
  316.              Source IP Address of the IP header of a SYN or a SYNACK
  317.              message.  If the sender of the message does not know the IP
  318.              address of the peer at the other end of the link, the
  319.              sender must set set this field to zero.  For the RSTACK
  320.              message, the Peer Identity field is set to the value of the
  321.              Source Address field from the IP header of the incoming
  322.              message that caused an RSTACK message to be generated.
  323.  
  324.    Peer Next Sequence Number
  325.              Gives the value of the peer's Sequence Number that the
  326.              sender of the IFMP Adjacency Protocol message expects to
  327.              arrive in the next IFMP Redirection Protocol message.  If a
  328.              node is in the ESTAB state, and the value of the Peer Next
  329.              Sequence Number in an incoming ACK message is greater than
  330.              the value of the Sequence Number plus one, from the last
  331.              IFMP Redirection Protocol message transmitted out of the
  332.              port on which the incoming ACK message was received, the
  333.              link should be reset.  The procedure to reset the link is
  334.              defined in section 3.2.
  335.  
  336.  
  337.  
  338. Newman, et. al.              Informational                      [Page 6]
  339.  
  340. RFC 1953                   IFMP Specification                   May 1996
  341.  
  342.  
  343.    Max Ack Intvl
  344.              Maximum Acknowledgement Interval is the maximum amount of
  345.              time the sender of the message will wait until transmitting
  346.              an ACK message.
  347.  
  348.    Address List
  349.              A list of one or more IP addresses that are assigned to the
  350.              link by the sender of the message.  The list must have at
  351.              least one entry that is identical to the Source Address in
  352.              the IP header.  The contents of this list are not used by
  353.              the IFMP protocol but can be made available to the routing
  354.              protocol.
  355.  
  356. 3.2 Procedure
  357.  
  358.    The IFMP Adjacency Protocol is described by the rules and state
  359.    tables given in this section.
  360.  
  361.    The rules and state tables use the following operations:
  362.  
  363.     o The "Update Peer Verifier" operation is defined as storing the
  364.       Sender Instance and the Source IP Address from a SYN or SYNACK
  365.       message received from the peer on a particular port.
  366.  
  367.     o The procedure "Reset the link" is defined as:
  368.  
  369.           1. Generate a new instance number for the link
  370.           2. Delete the peer verifier (set the stored values of Sender
  371.              Instance and Source IP Address of the peer to zero)
  372.           3. Set Sequence Number and Peer Next Sequence Number to zero
  373.           4. Send a SYN message
  374.           5. Enter the SYNSENT state
  375.  
  376.     o The state tables use the following Boolean terms and operators:
  377.  
  378.         A    The Sender Instance in the incoming message matches the
  379.              value stored from a previous message by the "Update Peer
  380.              Verifier" operation for the port on which the incoming
  381.              message is received.
  382.  
  383.         B    The Sender Instance and the Source IP Address in the
  384.              incoming message matches the value stored from a previous
  385.              message by the "Update Peer Verifier" operation for the
  386.              port on which the incoming message is received.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Newman, et. al.              Informational                      [Page 7]
  395.  
  396. RFC 1953                   IFMP Specification                   May 1996
  397.  
  398.  
  399.         C    The Peer Instance and Peer Identity in the incoming message
  400.              matches the value of the Sender Instance and the Source IP
  401.              Address currently in use for all SYN, SYNACK, and ACK
  402.              messages transmitted out of the port on which the incoming
  403.              message was received.
  404.  
  405.         "&&" Represents the logical AND operation
  406.  
  407.         "||" Represents the logical OR operation
  408.  
  409.         "!" Represents the logical negation (NOT) operation.
  410.  
  411.     o A timer is required for the periodic generation of SYN, SYNACK,
  412.       and ACK messages.  The period of the timer is unspecified but a
  413.       value of one second is suggested.
  414.  
  415.       There are two independent events: the timer expires, and a packet
  416.       arrives.  The processing rules for these events are:
  417.  
  418.          Timer Expires:   Reset Timer
  419.                           If state = SYNSENT Send SYN
  420.                           If state = SYNRCVD Send SYNACK
  421.                           If state = ESTAB   Send ACK
  422.  
  423.          Packet Arrives:  If incoming message is an RSTACK
  424.                              If A && C && !SYNSENT
  425.                                 Reset the link
  426.                              Else Discard the message
  427.                           Else the following State Tables.
  428.  
  429.  
  430.     o State synchronization across a link is considered to be achieved
  431.       when a node reaches the ESTAB state.
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Newman, et. al.              Informational                      [Page 8]
  451.  
  452. RFC 1953                   IFMP Specification                   May 1996
  453.  
  454.  
  455. State Tables
  456.  
  457.    State: SYNSENT
  458.  
  459. +======================================================================+
  460. |     Condition      |                Action               | New State |
  461. +====================+=====================================+===========+
  462. |    SYNACK && C     |  Update Peer Verifier; Send ACK     |   ESTAB   |
  463. +--------------------+-------------------------------------+-----------+
  464. |    SYNACK && !C    |            Send RSTACK              |  SYNSENT  |
  465. +--------------------+-------------------------------------+-----------+
  466. |        SYN         |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
  467. +--------------------+-------------------------------------+-----------+
  468. |        ACK         |            Send RSTACK              |  SYNSENT  |
  469. +======================================================================+
  470.  
  471.    State: SYNRCVD
  472.  
  473. +======================================================================+
  474. |     Condition      |                Action               | New State |
  475. +====================+=====================================+===========+
  476. |    SYNACK && C     |  Update Peer Verifier; Send ACK     |   ESTAB   |
  477. +--------------------+-------------------------------------+-----------+
  478. |    SYNACK && !C    |            Send RSTACK              |  SYNRCVD  |
  479. +--------------------+-------------------------------------+-----------+
  480. |        SYN         |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
  481. +--------------------+-------------------------------------+-----------+
  482. |    ACK && B && C   |              Send ACK               |   ESTAB   |
  483. +--------------------+-------------------------------------+-----------+
  484. |  ACK && !(B && C)  |            Send RSTACK              |  SYNRCVD  |
  485. +======================================================================+
  486.  
  487.    State: ESTAB
  488.  
  489. +=======================================================================+
  490. |     Condition       |                Action               | New State |
  491. +=====================+=====================================+===========+
  492. |   SYN || SYNACK     |            Send ACK (note 1)        |   ESTAB   |
  493. +---------------------+-------------------------------------+-----------+
  494. |   ACK && B && C     |            Send ACK (note 1)        |   ESTAB   |
  495. +---------------------+-------------------------------------+-----------+
  496. |  ACK && !(B && C)   |              Send RSTACK            |   ESTAB   |
  497. +=======================================================================+
  498.  
  499.  
  500.  Note 1: No more than one ACK should be sent within any time period of
  501.         length defined by the timer.
  502.  
  503.  
  504.  
  505.  
  506. Newman, et. al.              Informational                      [Page 9]
  507.  
  508. RFC 1953                   IFMP Specification                   May 1996
  509.  
  510.  
  511. 4. IFMP Redirection Protocol
  512.  
  513.    A sender encapsulates within an IPv4 packet all IFMP messages
  514.    belonging to the Redirection Protocol.  The sender sends these
  515.    messages to the unicast IP address of the peer at the other end of
  516.    the link. The IP address of the peer is obtained from the adjacency
  517.    protocol.  The Protocol field in the IP header must contain the value
  518.    101 (decimal) indicating that the IP packet contains an IFMP message.
  519.    The Time to Live (TTL) field in the IP header must be set to 1.
  520.  
  521.    All IFMP Redirection Protocol messages have the following structure:
  522.  
  523.     0                   1                   2                   3
  524.     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
  525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.    |    Version    |    Op Code    |           Checksum            |
  527.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.    |                        Sender Instance                        |
  529.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  530.    |                         Peer Instance                         |
  531.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.    |                        Sequence Number                        |
  533.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.    |                                                               |
  535.    ~                          Message Body                         ~
  536.    |                                                               |
  537.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.  
  539.  
  540.    Version
  541.              The IFMP protocol version number, currently Version = 1.
  542.  
  543.    Op Code
  544.              This field gives the message type.  Five message types are
  545.              currently defined for the IFMP Redirection Protocol:
  546.  
  547.                  REDIRECT:     Op Code = 4
  548.                  RECLAIM:      Op Code = 5
  549.                  RECLAIM ACK:  Op Code = 6
  550.                  LABEL RANGE:  Op Code = 7
  551.                  ERROR:        Op Code = 8
  552.  
  553.    Checksum
  554.              The 16-bit one's complement of the one's complement sum of
  555.              a pseudo header of information from the IP header, and the
  556.              IFMP message itself.  The pseudo header, conceptually
  557.              prefixed to the IFMP message, contains the Source Address,
  558.              the Destination Address, and the Protocol fields from the
  559.  
  560.  
  561.  
  562. Newman, et. al.              Informational                     [Page 10]
  563.  
  564. RFC 1953                   IFMP Specification                   May 1996
  565.  
  566.  
  567.              IPv4 header, and the total length of the IFMP message
  568.              starting with the version field (this is equivalent to the
  569.              value of the Total Length field from the IPv4 header minus
  570.              the length of the IPv4 header itself).
  571.  
  572.    Sender Instance
  573.              The sender's instance number for the link from the IFMP
  574.              Adjacency Protocol.
  575.  
  576.    Peer Instance
  577.              What the sender believes is the peer's current instance
  578.              number for the link from the IFMP Adjacency protocol.
  579.  
  580.    Sequence Number
  581.              The sender must increment by one, modulo 2**32, for every
  582.              IFMP Redirection Protocol message sent across a link.  It
  583.              allows the receiver to process IFMP Redirection Protocol
  584.              messages in order.  The Sequence Number is set to zero when
  585.              a node resets the link.
  586.  
  587.    Message Body
  588.              Contains a list of one or more IFMP Redirection Protocol
  589.              message elements.  All of the message elements in the list
  590.              have the same message type because the Op Code field
  591.              applies to the entire IFMP message.  The number of message
  592.              elements included in a single packet must not cause the
  593.              total size of the IFMP message to exceed the MTU size of
  594.              the underlying data link.  Only a single message element is
  595.              permitted in a Label Range message or in an Error message.
  596.  
  597.    No IFMP Redirection Protocol messages can be sent across a link until
  598.    the IFMP Adjacency Protocol has achieved state synchronization across
  599.    that link.  All IFMP Redirection Protocol messages received on a link
  600.    that does not currently have state synchronization must be discarded.
  601.    For every received IFMP Redirection Protocol message the receiver
  602.    must check the Source IP Address from the IP header, the Sender
  603.    Instance, and the Peer Instance.  The incoming message must be
  604.    discarded if the Sender Instance and the Source IP Address fields do
  605.    not match the values stored by the "Update Peer Verifier" operation
  606.    of the IFMP Adjacency Protocol for the port on which the message is
  607.    received.  The incoming message must also be discarded if the Peer
  608.    Instance field does not match the current value for the Sender
  609.    Instance of the IFMP Adjacency Protocol.
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Newman, et. al.              Informational                     [Page 11]
  619.  
  620. RFC 1953                   IFMP Specification                   May 1996
  621.  
  622.  
  623. 4.1 Redirect Message
  624.  
  625.    The Redirect Message element is used to instruct an adjacent node to
  626.    attach one or more given labels to packets belonging to one or more
  627.    specified flows each for a specified period of time.  The Redirect
  628.    message is not acknowledged.
  629.  
  630.    Each Redirect message element has the following structure:
  631.  
  632.     0                   1                   2                   3
  633.     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
  634.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  635.    |   Flow Type   | Flow ID Length|           Lifetime            |
  636.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  637.    |                             Label                             |
  638.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  639.    |                                                               |
  640.    ~                         Flow Identifier                       ~
  641.    |                                                               |
  642.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  643.  
  644.  
  645.    Flow Type
  646.              Specifies the Flow Type of the flow identifier contained in
  647.              the Flow Identifier field.
  648.  
  649.    Flow ID Length
  650.              Specifies the length of the Flow Identifier field in
  651.              integer multiples of 32 bit words.
  652.  
  653.    Lifetime field
  654.              Specifies the length of time, in seconds, for which this
  655.              redirection is valid.  The association of flow identifier
  656.              and label should be discarded at a time no greater than
  657.              that specified by the Lifetime field.  A value of zero is
  658.              not valid.
  659.  
  660.    Label field
  661.              Contains a 32 bit label.  The format of the label is
  662.              dependent upon the type of physical link across which the
  663.              Redirect message is sent.  (The format of the label for ATM
  664.              data links is specified in [ENCAP].)
  665.  
  666.    Flow Identifier
  667.              Identifies the flow with which the specified label should
  668.              be associated.  The length of the Flow Identifier field
  669.              must be an integer multiple of 32 bit words to preserve 32
  670.              bit alignment.
  671.  
  672.  
  673.  
  674. Newman, et. al.              Informational                     [Page 12]
  675.  
  676. RFC 1953                   IFMP Specification                   May 1996
  677.  
  678.  
  679.    A node can send an IFMP message containing one or more Redirect
  680.    message elements across a link to its upstream neighbor.  Each
  681.    Redirect message element requests that the upstream neighbor
  682.    associate a given link-level label to packets belonging to a
  683.    specified flow for up to a specified period of time.  A node
  684.    receiving an IFMP message that contains one or more Redirect message
  685.    elements from an adjacent downstream neighbor can choose to ignore
  686.    any or all of the Redirect message elements.  Neither the IFMP
  687.    message nor any of the Redirect message elements are acknowledged.
  688.    If the node chooses to accept a particular Redirect message element
  689.    and to redirect the specified flow, it should attach the label
  690.    specified in the Redirect message element to all further packets sent
  691.    on that flow until it chooses to do so no longer, or until the
  692.    specified lifetime expires.  While the flow remains redirected, the
  693.    encapsulation specified by the definition of the Flow Type given in
  694.    the Redirect message element must be used for all packets belonging
  695.    to that flow.  If the label in a Redirect message element is outside
  696.    the range that can be handled across the relevant link, a Label Range
  697.    message can be returned to the sender.  The Label Range message
  698.    informs the sender of the Redirect message of the range of labels
  699.    that can be sent across the link.
  700.  
  701.    If a Redirect message element is received specifying a flow that is
  702.    already redirected, the Label field in the received Redirect message
  703.    element must be checked against the label stored for the redirected
  704.    flow.  If they agree, the lifetime of the redirected flow is reset to
  705.    that contained in the Redirect message element.  If they disagree,
  706.    the Redirect message element is ignored, and the flow returned to the
  707.    default state.  There is a minimum time between Redirect message
  708.    elements specifying the same flow.  The default value is one second.
  709.  
  710.    If a receiving node detects an error in any of the fields of a
  711.    Redirect message element, the node must discard that message element
  712.    without affecting any other Redirect message elements in the same
  713.    IFMP message.  The receiver should return an error message to the
  714.    sender only in the case that the receiver does not understand the
  715.    version of the IFMP protocol in the received IFMP message or does not
  716.    understand a Flow Type in any of the Redirect message elements.  An
  717.    Error Message should be returned for each Flow Type that is not
  718.    understood.
  719.  
  720. 4.2 Reclaim Message
  721.  
  722.    The Reclaim message element is used by a node to instruct an adjacent
  723.    upstream node to unbind one or more flows from the labels to which
  724.    they are currently bound, and to release the labels.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Newman, et. al.              Informational                     [Page 13]
  731.  
  732. RFC 1953                   IFMP Specification                   May 1996
  733.  
  734.  
  735.    Each Reclaim message element has the following structure:
  736.  
  737.     0                   1                   2                   3
  738.     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
  739.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.    |   Flow Type   | Flow ID Length|           Reserved            |
  741.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.    |                             Label                             |
  743.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.    |                                                               |
  745.    ~                         Flow Identifier                       ~
  746.    |                                                               |
  747.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  748.  
  749.  
  750.    Flow Type
  751.              Specifies the Flow Type of the Flow Identifier contained in
  752.              the Flow ID field.
  753.  
  754.    Flow ID Length
  755.              Specifies the length of the Flow Identifier field in
  756.              integer multiples of 32 bit words.
  757.  
  758.    Reserved
  759.              Field is unused and should be set to zero by the sender and
  760.              ignored by the receiver.
  761.  
  762.    Label
  763.              Field contains the label to be released.
  764.  
  765.    Flow Identifier
  766.              Field contains the flow identifier to be unbound.
  767.  
  768.    A node can send a Reclaim message element to instruct an adjacent
  769.    upstream node to unbind a flow from the label to which it is
  770.    currently bound, return the flow to the default forwarding state, and
  771.    release the label.  Each Reclaim message element applies to a single
  772.    flow and a single label.  When the receiver has completed the
  773.    operation, it must issue a Reclaim Ack message element.  Reclaim Ack
  774.    message elements can be grouped together, in any order, into one or
  775.    more IFMP Reclaim Ack messages and returned to the sender as an
  776.    acknowledgment that the operation is complete.
  777.  
  778.    If a Reclaim message element is received indicating an unknown flow,
  779.    a Reclaim Ack message element must be returned containing the same
  780.    Label and Flow Identifier fields from the Reclaim message.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Newman, et. al.              Informational                     [Page 14]
  787.  
  788. RFC 1953                   IFMP Specification                   May 1996
  789.  
  790.  
  791.    If a Reclaim message element is received indicating a known flow, but
  792.    with a Label that is not currently bound to that flow, the flow must
  793.    be unbound and returned to the default forwarding state, and a
  794.    Reclaim Ack message sent containing the actual label to which the
  795.    flow was previously bound.
  796.  
  797.    If the receiver detects an error in any of the fields of a Reclaim
  798.    message element, the receiver must discard that message element,
  799.    without affecting any other Reclaim message elements in the same
  800.    message.  The receiver must return an error message to the sender
  801.    only in the case that the receiver does not understand the version of
  802.    the IFMP protocol in the received message or does not understand a
  803.    Flow Type in one of the Reclaim message elements.
  804.  
  805. 4.3 Reclaim Ack Message
  806.  
  807.    The Reclaim Ack message element is used by a receiving node to
  808.    acknowledge the successful release of one or more reclaimed labels.
  809.  
  810.    Each Reclaim Ack message element has the following structure:
  811.  
  812.     0                   1                   2                   3
  813.     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
  814.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  815.    |   Flow Type   | Flow ID Length|           Reserved            |
  816.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  817.    |                             Label                             |
  818.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  819.    |                                                               |
  820.    ~                         Flow Identifier                       ~
  821.    |                                                               |
  822.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  823.  
  824.    Flow Type
  825.              Specifies the Flow Type of the Flow Identifier contained in
  826.              the Flow Identifier field.
  827.  
  828.    Flow ID Length
  829.              Specifies the length of the Flow Identifier field in
  830.              integer multiples of 32 bit words.
  831.  
  832.    Reserved
  833.              Field is unused and should be set to zero by the sender and
  834.              ignored by the receiver.
  835.  
  836.    Label
  837.              Field contains the label released from the flow specified
  838.              by the Flow Identifier.
  839.  
  840.  
  841.  
  842. Newman, et. al.              Informational                     [Page 15]
  843.  
  844. RFC 1953                   IFMP Specification                   May 1996
  845.  
  846.  
  847.    Flow Identifier
  848.              Field contains the Flow Identifier from the Reclaim message
  849.              element that requested the release of the label specified
  850.              in the Label field.
  851.  
  852.    A Reclaim Ack message element must be sent in response to each
  853.    Reclaim message element received.  It is sent to indicate that the
  854.    requested flow is now unbound and that the label is now free.  If
  855.    possible, each Reclaim Ack message element should not be sent until
  856.    all data queued for transmission on the link, using the label
  857.    specified for release, has been sent.
  858.  
  859.    If a Reclaim Ack message element is received specifying a flow for
  860.    which no Reclaim message element was issued, that Reclaim Ack message
  861.    element must be ignored, but no other Reclaim Ack message elements in
  862.    the same message must be affected.
  863.  
  864.    If a Reclaim Ack message element is received specifying a different
  865.    label from the one sent in the original Reclaim message element for
  866.    that flow, the Reclaim Ack message element should be handled as if
  867.    the reclaim operation were successful.
  868.  
  869.    If an error is detected in any of the fields of a Reclaim Ack message
  870.    element, that message element must be discarded, but no other Reclaim
  871.    Ack message elements in the same message must be affected.
  872.  
  873.    The receiver should return an Error message to the sender only in the
  874.    case that the receiver does not understand the version of the IFMP
  875.    protocol in the received message or does not understand a Flow Type
  876.    in one of the Reclaim Ack message elements.
  877.  
  878. 4.4 Label Range Message
  879.  
  880.    The Label Range message element is sent in response to a Redirect
  881.    message if the label requested in one or more of the Redirect message
  882.    elements is outside the range that the receiver of the Redirect
  883.    message can handle.  The Label Range message informs the sender of
  884.    the Redirect message of the label range that can be handled on the
  885.    relevant link.
  886.  
  887.    Only a single Label Range message element is permitted in a Label
  888.    Range message.  The Label Range message element has the following
  889.    structure:
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Newman, et. al.              Informational                     [Page 16]
  899.  
  900. RFC 1953                   IFMP Specification                   May 1996
  901.  
  902.  
  903.     0                   1                   2                   3
  904.     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
  905.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.    |                         Minimum Label                         |
  907.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  908.    |                         Maximum Label                         |
  909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.  
  911.  
  912.    Minimum Label
  913.              The minimum value of label that can be specified in an IFMP
  914.              Redirection Protocol message across this link.
  915.  
  916.    Maximum Label
  917.              The maximum value of label that can be specified in an IFMP
  918.              Redirection Protocol message across this link.
  919.  
  920.    All values of label within the range Minimum Label to Maximum Label
  921.    inclusive may be specified in an IFMP Redirection Protocol message
  922.    across the link.
  923.  
  924. 4.5 Error Message
  925.  
  926.    An Error message can be sent by a node in response to any IFMP
  927.    Redirection Protocol message.
  928.  
  929.    Only a single Error message element is permitted in an Error message.
  930.    The Error message element has the following structure:
  931.  
  932.     0                   1                   2                   3
  933.     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
  934.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.    |  Error Code   |                  Parameter                    |
  936.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.  
  938.  
  939.    Error Code
  940.              Specifies which an error has occurred.
  941.  
  942.    Each Error message can specify a single Parameter.
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Newman, et. al.              Informational                     [Page 17]
  955.  
  956. RFC 1953                   IFMP Specification                   May 1996
  957.  
  958.  
  959.    Two Error message elements are specified:
  960.  
  961.  
  962.    Bad Version:
  963.  
  964.    Error Code = 1. The sender of the Error message cannot process the
  965.              version of the IFMP protocol of the message that caused the
  966.              error.  This message must only be sent if the version of
  967.              the message that caused the error is greater than the most
  968.              recent version that the sender of the Error message can
  969.              process.  The parameter field of this Error message gives
  970.              the most recent version of the IFMP protocol that the
  971.              sender can process, right justified, with the unused most
  972.              significant bits of the Parameter field set to zero.
  973.  
  974.    Bad Flow Type:
  975.  
  976.    Error Code = 2. The sender of the Error message does not understand a
  977.              Flow Type that was received in the message that caused the
  978.              error.  The Flow Type that caused the error is given in the
  979.              parameter field, right justified, with the unused most
  980.              significant bits of the Parameter field set to zero.
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Newman, et. al.              Informational                     [Page 18]
  1011.  
  1012. RFC 1953                   IFMP Specification                   May 1996
  1013.  
  1014.  
  1015. REFERENCES
  1016.  
  1017.       [ENCAP] Newman, P., et. al., "Transmission of Flow Labelled IPv4
  1018.                on ATM Data Links Ipsilon Version 1.0," Ipsilon Networks,
  1019.                RFC 1954, May 1996.
  1020.  
  1021.       [RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC
  1022.                793, September 1981.
  1023.  
  1024. SECURITY CONSIDERATIONS
  1025.  
  1026.    Security issues are not discussed in this memo.
  1027.  
  1028. AUTHORS' ADDRESSES
  1029.  
  1030.    Peter Newman                        Phone: +1 (415) 846-4603
  1031.    Ipsilon Networks, Inc.              EMail: pn@ipsilon.com
  1032.  
  1033.    W. L. Edwards, Chief Scientist      Phone:  +1 (913) 534 5334
  1034.    Sprint                              EMail:  texas@sprintcorp.com
  1035.  
  1036.    Robert M. Hinden                    Phone: +1 (415) 846-4604
  1037.    Ipsilon Networks, Inc.              EMail: hinden@ipsilon.com
  1038.  
  1039.    Eric Hoffman                        Phone: +1 (415) 846-4610
  1040.    Ipsilon Networks, Inc.              EMail: hoffman@ipsilon.com
  1041.  
  1042.    Fong Ching Liaw                     Phone: +1 (415) 846-4607
  1043.    Ipsilon Networks, Inc.              EMail: fong@ipsilon.com
  1044.  
  1045.    Tom Lyon                            Phone: +1 (415) 846-4601
  1046.    Ipsilon Networks, Inc.              EMail: pugs@ipsilon.com
  1047.  
  1048.    Greg Minshall                       Phone: +1 (415) 846-4605
  1049.    Ipsilon Networks, Inc.              EMail: minshall@ipsilon.com
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Newman, et. al.              Informational                     [Page 19]
  1067.  
  1068. RFC 1953                   IFMP Specification                   May 1996
  1069.  
  1070.  
  1071. Ipsilon Networks, Inc. is located at:
  1072.  
  1073.    2191 East Bayshore Road
  1074.    Suite 100
  1075.    Palo Alto, CA 94303
  1076.    USA
  1077.  
  1078. Sprint is located at:
  1079.  
  1080.    Sprint
  1081.    Sprint Technology Services - Long Distance Division
  1082.    9300 Metcalf Avenue
  1083.    Mailstop KSOPKB0802
  1084.    Overland Park, KS 66212-6333
  1085.    USA
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Newman, et. al.              Informational                     [Page 20]
  1123.  
  1124.