home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2129.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  40.2 KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          K. Nagami
  8. Request for Comments: 2129                                    Y. Katsube
  9. Category: Informational                                     Y. Shobatake
  10.                                                                  A. Mogi
  11.                                                             S. Matsuzawa
  12.                                                                T. Jinmei
  13.                                                                 H. Esaki
  14.                                                       Toshiba R&D Center
  15.                                                               April 1997
  16.  
  17.  
  18.   Toshiba's Flow Attribute Notification Protocol (FANP) Specification
  19.  
  20. Status of this Memo
  21.  
  22.    This memo provides information for the Internet community.  This memo
  23.    does not specify an Internet standard of any kind.  Distribution of
  24.    this memo is unlimited.
  25.  
  26. Abstract
  27.  
  28.    This memo discusses Flow Attribute Notification Protocol (FANP),
  29.    which is a protocol between neighbor nodes for the management of
  30.    cut-through packet forwarding functionalities. In cut-through packet
  31.    forwarding, a router doesn't have to perform conventional IP packet
  32.    processing for received packets.  FANP indicates mapping information
  33.    between a datalink connection and a packet flow to the neighbor node
  34.    and helps a pair of nodes manage the mapping information.  By using
  35.    FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming
  36.    packets based on their datalink-level connection identifiers,
  37.    bypassing usual IP packet processing.  The design policy of the FANP
  38.    is;
  39.  
  40.        (1)  soft-state cut-through path (Dedicated-VC) management
  41.        (2)  protocol between neighbor nodes instead of end-to-end
  42.        (3)  applicable to any connection oriented datalink platform
  43.  
  44. 1.  Background
  45.  
  46.    Due to the scalability requirement, connection oriented (CO) datalink
  47.    platforms, e.g., ATM and Frame Relay, are going to be used as well as
  48.    connection less (CL) datalink platforms, e.g., Ethernet and FDDI.
  49.    One of the important features of the CO datalink is the presence of a
  50.    datalink-level connection identifier.  In the CO datalink, we can
  51.    establish multiple virtual connections (VCs) with their VC
  52.    identifiers among the nodes. When we aggregate packets that have the
  53.    same direction (e.g., having the same destination IP address) into a
  54.    single VC, we can forward the packets in the VC without IP
  55.  
  56.  
  57.  
  58. Nagami, et. al.              Informational                      [Page 1]
  59.  
  60. RFC 2129                   FANP Specification                 April 1997
  61.  
  62.  
  63.    processing.  With this configuration, routers can decide which node
  64.    is the next-hop for the packets based on the VC identifier.  CSRs [1]
  65.    can forward the incoming packets using an ATM switch engine bypassing
  66.    the conventional IP processing.  According to the ingress VPI/VCI
  67.    value with ingress interface information, CSR determines the egress
  68.    interface and egress VPI/VCI value.
  69.  
  70.    In order to configure the cut-through packet forwarding state, a pair
  71.    of neighbor nodes have to share the mapping information between the
  72.    packet flow and the datalink VC.  FANP (Flow Attribute Notification
  73.    Protocol) described in this memo is the protocol to configure and
  74.    manage the cut-through packet forwarding state.
  75.  
  76. 2.  Protocol Requirements and Future Enhancement
  77.  
  78. 2.1 Protocol Requirements
  79.  
  80.    The followings are the protocol requirements for FANP.
  81.  
  82.    (1) Applicable to various types of CO datalink platforms
  83.  
  84.    (2) Available with various connection types (i.e., SVC, PVC, VP)
  85.  
  86.    (3) Robust operation
  87.        The system should operate correctly even under the following
  88.        conditions.
  89.  
  90.         (a) VC failure
  91.             Some systems can detect VC failure as the function of
  92.             datalink (e.g., OAM function in the ATM).  However, we can
  93.             not assume all nodes in the system can detect VC failure.
  94.             The system has to operate correctly, assuming that every
  95.             node can not detect VC failure.
  96.  
  97.         (b) Message loss
  98.             Control messages in the FANP may be lost.  The system has to
  99.             operate correctly, even when some control messages are lost.
  100.  
  101.         (c Node failure
  102.             A node may be down without any explicit notification to its
  103.             neighbors.  The system has to operate correctly, even with
  104.             node failure.
  105.  
  106.    Though FANP is not the protocol only for ATM, the following
  107.    discussion assumes that the datalink is an ATM network.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Nagami, et. al.              Informational                      [Page 2]
  115.  
  116. RFC 2129                   FANP Specification                 April 1997
  117.  
  118.  
  119. 2.2  Future Enhancement
  120.  
  121.    The followings are the future enhancements to be done.
  122.  
  123.         (1) Aggregated flow
  124.  
  125.           In this memo, we define the flow which contain source and
  126.           destination IP address.  As this may require many VC
  127.           resources, we also need a new definition of aggregated flow
  128.           which includes several end-to-end flows.  The concrete
  129.           definition of the aggregated flow is for future study.
  130.  
  131.         (2) Providing multicast service
  132.         (3) Supporting IP level QOS signaling like RSVP
  133.         (4) Supporting IPv6
  134.  
  135. 3. Terminology and Definition
  136.  
  137.    o VCID (Virtual Connection IDentifier)
  138.       Since VPI/VCI values at the origination and the termination points
  139.       of a VC (and VP) may not be the same, we need an identifier to
  140.       uniquely identify the datalink connection between neighbor nodes.
  141.       We define this identifier as a VCID.  Currently, only one type of
  142.       VCID is defined.  This VCID contains the ESI (End System
  143.       Identifier) of a source node and the unique identifier within a
  144.       source node.
  145.  
  146.    o Flow ID (Flow IDentifier)
  147.       IP level packet flow is identified by some parameters in a packet.
  148.       Currently, only one type of flow ID is defined.  This flow ID
  149.       contains a source IP address and a destination IP address.  Note
  150.       that flow ID used in this specification is not the same as the
  151.       flow-id specified in IPv6.
  152.  
  153.    o Cut-through packet forwarding
  154.       Packets are forwarded without any IP processing at the router
  155.       using the datalink level information (e.g.,VPI/VCI).
  156.       Internetworking level information (e.g., destination IP address)
  157.       is mapped to the corresponding datalink-level identifier by using
  158.       the FANP.
  159.  
  160.    o Hop-by-Hop packet forwarding
  161.       Packets are forwarded using IP level information like conventional
  162.       routers.  In ATM, cells are re-assembled into packets at the
  163.       router to analyze the IP header.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Nagami, et. al.              Informational                      [Page 3]
  171.  
  172. RFC 2129                   FANP Specification                 April 1997
  173.  
  174.  
  175.    o Default-VC
  176.       Default-VC is used for hop-by-hop packet forwarding.  Cells
  177.       received from the Default-VC are reassembled into IP packets.
  178.       Conventional IP processing is performed for these packets.  The
  179.       encapsulation over the Default-VC is LLC for routed non-ISO
  180.       protocols defined by RFC1483 [3].
  181.  
  182.    o Dedicated-VC
  183.       Dedicated-VC is used for the specific IP packet flow identified by
  184.       the flow-ID.  When the flow-ID for an incoming VC and an outgoing
  185.       VC are the same at a CSR, it can forward the packets belonging to
  186.       the flow through the cut-through packet forwarding.  The
  187.       encapsulation over the Dedicated-VC is LLC for routed non-ISO
  188.       protocols defined by RFC1483 [3].
  189.  
  190.    o Cut-through trigger
  191.       When a FANP capable node receives a trigger packet, it tries to
  192.       establish Dedicated-VC and to notify the mapping information
  193.       between the Dedicated-VC and the IP packet flow which the received
  194.       trigger packet belongs to.  Trigger packets are defined by the
  195.       port-ID of TCP/UDP with the local policy of each FANP capable
  196.       node.  In general, they would be the port-ID's of sessions with a
  197.       long life-time and/or with large amount of packets; e.g., http,
  198.       ftp and nntp.  Future implementation will include other triggers
  199.       such as an arrival of resource reservation request.
  200.  
  201. 4. Protocol Overview
  202.  
  203.    Figure 1 shows an operational overview of FANP.  In the figure, a
  204.    cut-through packet forwarding path is established from host 1 (H1) to
  205.    host 2 (H2) using two Dedicated-VCs.  H1 and H2 are connected to
  206.    Ethernets, and R1, R2 and R3 are routers which can speak FANP.  R1
  207.    and R3 have both an ATM interface and an Ethernet interface.  R2 has
  208.    two ATM interfaces.
  209.  
  210.    When R1 receives an IP packet from H1, R1 analyzes the payload of the
  211.    received IP packet whether it is a trigger packet or not.  When the
  212.    received packet is a trigger packet, R1 fetches a Dedicated-VC to its
  213.    downstream neighbor(R2) and sends FANP messages.  FANP is effective
  214.    between the neighboring nodes only.  The same procedure would be
  215.    performed between R2 and R3 independently from the procedure between
  216.    R1 and R2.  The flow-ID of the packet flow from H1 to H2 is
  217.    represented as id(H1,H2).  Here, id(H1,H2) is the set of the IP
  218.    address of H1 and that of H2.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Nagami, et. al.              Informational                      [Page 4]
  227.  
  228. RFC 2129                   FANP Specification                 April 1997
  229.  
  230.  
  231.    The Dedicated-VC is released when no packet is transferred on it for
  232.    a given period.  We do not need to explicitly indicate release of the
  233.    Dedicated-VC to the neighbor node, since the state management in FANP
  234.    is of soft-state, rather than of hard-state.
  235.  
  236.     +--+ Ethernet +--+   +-----+   +--+   +-----+   +--+ Ethernet +--+
  237.     |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
  238.     +--+          +--+   +-----+   +--+   +-----+   +--+          +--+
  239.        trigger pkt
  240.        |----------> trigger packet
  241.                     |------------->   trigger packet
  242.                        FANP          |-------------->  trigger pkt
  243.                     <=============>        FANP        |----------->
  244.                                      <==============>
  245.  
  246.                     |=============|
  247.                      Dedicated-VC    |==============|
  248.                                        Dedicated-VC
  249.  
  250.              Figure 1. Trigger packet and FANP initiation
  251.  
  252. 5. Protocol Sequence
  253.  
  254.    FANP has the following five procedures, that are (1) Dedicated-VC
  255.    selection, (2) VCID negotiation, (3) flow-ID notification, (4)
  256.    Dedicated-VC refresh and (5) Dedicated-VC release.  Procedures (2),
  257.    (3) and (4) have nothing to do with the kind of the Dedicated-
  258.    VC;i.e.,SVC,PVC or VP.  On the contrary, the procedures (1) and (5)
  259.    with SVC are different from the procedures with PVC and with VP.
  260.  
  261.    The detailed procedures are described in the following subsections.
  262.  
  263. 5.1 Dedicated-VC Selection Procedure
  264.  
  265.    A VC is picked up in order to use as a Dedicated-VC.  The ways of
  266.    picking up the Dedicated-VC is either of the followings.
  267.  
  268.    (1) A number of VCs are prepared in advance, and registered into an
  269.       un-used VC list.  When a Dedicated-VC is needed, one of them is
  270.       picked up from the un-used VC list.
  271.  
  272.    (2) A new VC is established through ATM signaling on demand.
  273.  
  274.    With ATM PVC/VP configuration, a Dedicated-VC is activated by the
  275.    procedure (1).
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Nagami, et. al.              Informational                      [Page 5]
  283.  
  284. RFC 2129                   FANP Specification                 April 1997
  285.  
  286.  
  287.    With ATM SVC configuration, a Dedicated-VC is activated by the
  288.    procedure (1) or (2).  When the procedure (1) is used, some number of
  289.    VCs are prepared in advance through ATM signaling.  These VCs are
  290.    registered into the un-used VC list.  When a Dedicated-VC is needed,
  291.    a VC is picked up from the un-used VC list.  When the procedure (2)
  292.    is used, a Dedicated-VC is established through ATM signaling each
  293.    time it is required.
  294.  
  295.    The procedure (1) can decrease a time to activate a Dedicated-VC.
  296.    But the necessary VC resource will increase as it need to prepare
  297.    additional VCs.  Which procedure should be applied to is a matter of
  298.    local decision in each node, taking the economical requirement and
  299.    the system responsiveness into account.
  300.  
  301.    A Dedicated-VC is used as a uni-directional VC, although it is
  302.    generally bi-directional.  This means that packets are transferred
  303.    only from upstream node to downstream node in the Dedicated-VC. The
  304.    packets from downstream node to upstream node are transferred through
  305.    the Default-VC or through another Dedicated-VC.
  306.  
  307. 5.2 VCID Negotiation Procedure
  308.  
  309.    After the Dedicated-VC selection procedure, the upstream node
  310.    transmits the PROPOSE message to the downstream node through the
  311.    Dedicated-VC.  The PROPOSE message contains a VCID for the
  312.    Dedicated-VC and IP address (target IP address) of downstream node.
  313.    When the downstream node accepts the PROPOSE message, it transmits
  314.    the PROPOSE ACK message to the upstream node through the Default-VC.
  315.    With this procedure, the upstream and the downstream nodes (both
  316.    end-points of the Dedicated-VC) can share the same indicator "VCID"
  317.    for the Dedicated-VC.  When the downstream node can not accept the
  318.    proposal from the upstream node with some reason (e.g., policy), the
  319.    downstream node sends an ERROR message to the upstream node through
  320.    the Default-VC.
  321.  
  322.    The procedure at the downstream node which has received PROPOSE
  323.    message is;
  324.  
  325.     1. if(Target IP address of the PROPOSE message isn't equal to my IP
  326.           address)
  327.        then Goto end.
  328.  
  329.     2. if(The PROPOSE message should be refused)
  330.        then  Send an ERROR(refuse by policy) message. Go to end.
  331.  
  332.     3. if(VCID Type in the PROPOSE message isn't known)
  333.        then Send an ERROR(unknown VCID Type) message. Go to end.
  334.  
  335.  
  336.  
  337.  
  338. Nagami, et. al.              Informational                      [Page 6]
  339.  
  340. RFC 2129                   FANP Specification                 April 1997
  341.  
  342.  
  343.     4. if(The VCID in the PROPOSE message is  the same as the VCID which
  344.        has already been registered for another Dedicated-VC in the node)
  345.        then Delete the registered VCID.
  346.        Release the old Dedicated-VC.
  347.  
  348.     5. if(A VCID is registered for the Dedicated-VC which has received
  349.        the PROPOSE message)
  350.        then Delete the registered VCID.
  351.  
  352.     6. Register the mapping between VCID and  I/F, VPI, VCI for the
  353.        Dedicated-VC.
  354.  
  355.     7. if(The mapping is successful)
  356.        then Send a PROPOSE ACK.
  357.        else Send an ERROR(resource unavailable).
  358.  
  359.    The upstream node retransmits the PROPOSE message when it neither
  360.    receive PROPOSE ACK message nor ERROR message.  When the upstream
  361.    node has received neither of the messages even with five
  362.    retransmissions of the PROPOSE message, the Dedicated-VC picked up
  363.    through the Dedicated-VC selection procedure should be released.
  364.    Here, the number of retransmissions (five in this specification)is
  365.    recommended value and can be modified in the future.
  366.  
  367.    The purpose of the VCID negotiation procedure is not only to share
  368.    the VCID information regarding the Dedicated-VC, but also to confirm
  369.    whether the Dedicated-VC is available and whether the neighbor node
  370.    operates correctly.
  371.  
  372.    If the VCID negotiation procedure with a neighbor node always fails,
  373.    it is considered that the node may not be FANP-capable node.
  374.    Therefore the upstream node should not try the VCID negotiation
  375.    procedure to that node for a certain time period.
  376.  
  377. 5.3 Flow-ID Notification Procedure
  378.  
  379.    After the VCID negotiation procedure, the upstream node transmits an
  380.    OFFER message to the downstream node through the Default-VC.  The
  381.    OFFER message contains the VCID of the Dedicated-VC, the flow-ID of
  382.    the packet flow transferred through the Dedicated-VC and the refresh
  383.    interval of a READY message.
  384.  
  385.    When the downstream node receives the OFFER message from the upstream
  386.    node, it transmits the READY message to the upstream node through the
  387.    Default-VC in order to indicate that the OFFER message issued by the
  388.    upstream node is accepted.  By the reception of the READY message,
  389.    the upstream node realizes that the downstream node can receive IP
  390.    packets transferred through the Dedicated-VC.
  391.  
  392.  
  393.  
  394. Nagami, et. al.              Informational                      [Page 7]
  395.  
  396. RFC 2129                   FANP Specification                 April 1997
  397.  
  398.  
  399.    The upstream node retransmits the OFFER message when it does not
  400.    receive a READY message from the downstream node.  When the upstream
  401.    node has not receive a READY message even with five retransmissions,
  402.    the Dedicated-VC should be released.  Here, the number of
  403.    retransmissions (i.e., five in this specification) is a recommended
  404.    value and may be modified in the future.
  405.  
  406.    The node transmits an ERROR message to its neighbor in the following
  407.    cases.  When the node receives the ERROR message, the Dedicated-VC
  408.    should be released.
  409.  
  410.     (a) unknown VCID: The VCID in the message is unknown.
  411.     (b) unknown VCID Type: The VCID Type is unknown.
  412.     (c) unknown flow-ID Type: the flow-ID Type is unknown.
  413.  
  414.    When the downstream node accepts the OFFER message from the upstream
  415.    node, it must send a READY message to the upstream node within the
  416.    refresh interval offered by the upstream node.  If it can not, the
  417.    downstream node sends the ERROR message (this refresh interval is not
  418.    supported) to the upstream node.  The downstream node should accept
  419.    the refresh interval larger than 120 seconds.  Therefore the
  420.    downstream node shouldn't send the ERROR message (this refresh
  421.    interval is not supported) when the refresh interval in the OFFER
  422.    message is larger than 120 seconds.
  423.  
  424.    The following describes the procedure of the node which has received
  425.    an OFFER message.
  426.  
  427.     1. if(unknown version in the OFFER message)
  428.        then Discard the message.  Goto end.
  429.  
  430.     2. if(unknown VCID Type in the OFFER message)
  431.        then Send an ERROR (unknown VCID Type) message.  Goto end.
  432.  
  433.     3. if(VCID in the OFFER message has not been registered)
  434.        then Send an ERROR (unknown VCID) message.  Goto end.
  435.  
  436.     4. if(unknown Flow ID Type in the OFFER message)
  437.        then Send an ERROR (unknown Flow ID Type) message.  Goto end.
  438.  
  439.     5. if(refuse Flow ID in the OFFER message)
  440.        then Send an ERROR (refused by policy) message.  Goto end.
  441.  
  442.     6. if(refuse refresh interval in the OFFER message)
  443.        then Send an ERROR(This refresh interval is not supported)
  444.        message.  Goto end.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Nagami, et. al.              Informational                      [Page 8]
  451.  
  452. RFC 2129                   FANP Specification                 April 1997
  453.  
  454.  
  455.     7. if(the mapping between Flow ID and VCID already exists and
  456.           Flow ID in the OFFER message is different from the registered
  457.           Flow ID for the corresponding VCID)
  458.        then Do Flow-ID removal procedure.  Goto end.
  459.  
  460.     8. Do the procedure of receiving the OFFER message.
  461.  
  462.     7. if(successful)
  463.        then Send a READY message.
  464.        else Send an ERROR (resource unavailable) message.
  465.  
  466.     8. end.
  467.  
  468.    The procedure of the node which has received a READY message is
  469.    described.
  470.  
  471.     1. if(unknown version in the READY message)
  472.        then Discard the message.  Goto end.
  473.  
  474.     2. if(unknown VCID Type in the READY message)
  475.        then Send an ERROR (unknown VCID Type) message.  Goto end.
  476.  
  477.     3. if(VCID in the READY message has not been registered)
  478.        then Send an ERROR (unknown VCID) message.  Goto end.
  479.  
  480.     4. if(unknown Flow ID Type in the READY message)
  481.        then Send an ERROR (unknown Flow ID Type) message.  Goto end.
  482.  
  483.     5. if((the mapping between Flow ID and VCID doesn't exist)||
  484.           (the mapping between Flow ID and VCID already exists and
  485.            Flow ID in the READY message is different from registered Flow
  486.            ID for the corresponding VCID))
  487.        then Send an ERROR (unknown VCID) message.  Goto end.
  488.  
  489.     6. Do the procedure of receiving the READY message.
  490.  
  491.     7. end.
  492.  
  493. 5.4 Flow ID Refresh Procedure
  494.  
  495.    While the downstream node receives IP packets through the Dedicated-
  496.    VC, it should periodically (with a refresh interval) send the READY
  497.    message to the upstream node.  When the downstream node does not
  498.    receive any IP packet during the refresh interval, it does not send
  499.    the READY message to the upstream node.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Nagami, et. al.              Informational                      [Page 9]
  507.  
  508. RFC 2129                   FANP Specification                 April 1997
  509.  
  510.  
  511.    While the upstream node continues to receive READY messages, it
  512.    realizes that it can transmit the IP packets through the Dedicated-
  513.    VC.  When it does not receive a READY message at all for a
  514.    predetermined period (dead interval), it removes the mapping between
  515.    the Flow IP and VCID.  The dead interval is defined below.
  516.  
  517.    When the upstream node falls into failure without the Flow ID removal
  518.    procedure for a Dedicated-VC, its mapping must be removed by the
  519.    downstream node.  The downstream node removes the mapping between the
  520.    Flow ID and VCID for the Dedicated-VC when it does not receive any IP
  521.    packet for a "removal period" (=refresh interval times m).
  522.  
  523.    The refresh interval, the dead interval and the removal period should
  524.    satisfy the following equation.
  525.  
  526.     refresh interval < dead interval < removal period (=refresh
  527.     interval times m)
  528.  
  529.     The recommended values are:
  530.         refresh interval =  2 minutes
  531.         dead interval    =  6 minutes (=refresh interval x 3)
  532.         removal period  = 20 minutes (=refresh interval x 10)
  533.  
  534. 5.5 Flow ID Removal Procedure
  535.  
  536.    When the upstream node realizes that the Dedicated-VC is not used, it
  537.    performs a Flow ID removal procedure.
  538.  
  539.    The Flow ID removal procedure differs between the case of PVC/VP
  540.    configuration and the case of SVC configuration.
  541.  
  542.    With the PVC/VP configuration, the upstream node issues a REMOVE
  543.    message to the downstream node, and the downstream node sends back a
  544.    REMOVE ACK message to the upstream node.  The upstream node
  545.    retransmits REMOVE messages when it does not receive a REMOVE ACK
  546.    message.  The upstream node assumes that the downstream node is in
  547.    failure state when it dose not receive any REMOVE ACK message from
  548.    the downstream node even with five REMOVE message retransmissions.
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Nagami, et. al.              Informational                     [Page 10]
  563.  
  564. RFC 2129                   FANP Specification                 April 1997
  565.  
  566.  
  567.    With SVC configuration, two procedures are possible.  One is that the
  568.    mapping between the Flow ID and the VCID is removed without the
  569.    release of the ATM connection, which is the same procedure as the
  570.    PVC/VP configuration.  The other procedure is that the mapping
  571.    between the Flow ID and the VCID is removed by releasing the VC
  572.    through ATM signaling.  The former procedure can promptly create and
  573.    delete the mapping between Flow ID and VCID, since the ATM signaling
  574.    does not have to be performed each time.  However, an un-used ATM
  575.    connections have to be maintained by the node.  Which procedure is
  576.    applied to is a matter of each CSR's local decision, taking the VC
  577.    resource cost and responsiveness into account.
  578.  
  579.    The downstream node may want to remove the mapping between the Flow
  580.    ID and the VCID.  When the upstream node receives the REMOVE message,
  581.    it sends a REMOVE ACK message to the downstream node.
  582.  
  583.              +--+                              +--+
  584.              |R1|------------------------------|R2|
  585.              +--+                              +--+
  586.                |           PROPOSE              |
  587.                |===============================>|
  588.       VCID     |       [VCID, target IP]        |
  589.   negotiation  |          PROPOSE ACK           |
  590.                |<===============================|
  591.                |            [VCID]              |
  592.                |                                |
  593.                |            OFFER               |
  594.                |===============================>|
  595.      Flow-ID   |       [VCID, flow-ID]          |
  596.   notification |            READY               |
  597.                |<===============================|
  598.                |       [VCID, flow-ID]          |
  599.                |                                |
  600.                     :         :           :
  601.                     :         :           :
  602.                |           READY                |
  603.                |<===============================|
  604.   Dedicated-VC |       [VCID, flow-ID]          |
  605.   refresh      |           READY                |
  606.                |<===============================|
  607.                |       [VCID, flow-ID]          |
  608.  
  609.           Figure 2. Flow ID notification and refresh procedure
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Nagami, et. al.              Informational                     [Page 11]
  619.  
  620. RFC 2129                   FANP Specification                 April 1997
  621.  
  622.  
  623.              +--+                              +--+
  624.              |R1|------------------------------|R2|
  625.              +--+                              +--+
  626.                |                                 |
  627.                |             REMOVE              |
  628.                |================================>|
  629.                |             [VCID]              |
  630.                |                                 |
  631.                |           REMOVE ACK            |
  632.                |<================================|
  633.                |             [VCID]              |
  634.  
  635.           (a) Flow ID removal (independent of ATM signaling)
  636.  
  637.              +--+                              +--+
  638.              |R1|------------------------------|R2|
  639.              +--+                              +--+
  640.                |          ATM signaling          |
  641.                |           (release)             |
  642.                |<===============================>|
  643.                |                                 |
  644.  
  645.             (b) Flow ID removal through ATM signaling
  646.  
  647.              Figure 3.  Flow ID removal procedure
  648.  
  649. 6. Message Format
  650.  
  651.    FANP control procedure includes seven messages described from 6.2 to
  652.    6.8.  Among them, a PROPOSE message used for VCID negotiation
  653.    procedure uses an extended ATM ARP message format defined in RFC1577
  654.    [2].  The other messages are encapsulated into IP packets.
  655.  
  656.    The destination IP address in the IP packet header signifies the
  657.    neighbor node's IP address and the source IP address signifies
  658.    sender's IP address.  Currently, the protocol ID for these messages
  659.    is 110(decimal).  This protocol ID must be registered by IANA.
  660.  
  661.    The reserved field in the following packet format must be zero.
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Nagami, et. al.              Informational                     [Page 12]
  675.  
  676. RFC 2129                   FANP Specification                 April 1997
  677.  
  678.  
  679. 6.1 Field Format
  680.  
  681. 6.1.1 VCID field
  682.  
  683.    VCID type value decides VCID field format.  Currently, only type "1"
  684.    is defined.  The VCID field format of VCID type 1 is shown below.
  685.  
  686.      0                   1                   2                   3
  687.      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
  688.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  689.     |                    ESI of upstream node                       |
  690.     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  691.     |                               |                               |
  692.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  693.     |                              ID                               |
  694.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  695.  
  696.        ESI field: ESI of upstream node
  697.        ID       : upstream node decides unique identifier.
  698.  
  699. 6.1.2 Flow ID field
  700.  
  701.    Flow ID type value decides flow-ID field format.  Currently, flow-ID
  702.    type "0" and "1" are defined.  The flow ID type value "0" signifies
  703.    that the flow ID field is null.  When flow ID type value is "1", the
  704.    format shown below is used.
  705.  
  706.      0                   1                   2                   3
  707.      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
  708.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  709.     |                   Source IP address                           |
  710.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  711.     |                   Destination IP address                      |
  712.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  713.  
  714.        Source IP address      : source IP address of flow
  715.        Destination IP address : destination IP address of flow
  716.  
  717. 6.2 PROPOSE message
  718.  
  719.    PROPOSE message uses the extended ATM-ARP message format [2] to which
  720.    the VCID type and the VCID field are added.  Type & Length fields are
  721.    set to zero, because the messages don't need sender/target ATM
  722.    address.  This message is transferred from the upstream node to the
  723.    downstream node through the Dedicated-VC.
  724.  
  725.    PROPOSE message is transferred from the upstream node to the
  726.    downstream node through the Dedicated-VC.
  727.  
  728.  
  729.  
  730. Nagami, et. al.              Informational                     [Page 13]
  731.  
  732. RFC 2129                   FANP Specification                 April 1997
  733.  
  734.  
  735.      0                   1                   2                   3
  736.      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
  737.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  738.     | Hardware Type = 0x13          |  Protocol Type = 0x0800       |
  739.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.     | Type&Length 1 | Type&Length 2 |      Opereation Code          |
  741.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.     |    Length 1   | Type&Length 3 | Type&Length 4 |   Length 2    |
  743.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.     |                     Sender IP Address                         |
  745.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  746.     |                     Target IP Address                         |
  747.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  748.     |   VCID Type   |VCID Length    |       Reserved                |
  749.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  750.     |                        VCID                                   |
  751.     /                                                               /
  752.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  753.  
  754.     Type&Length 1 ; Type & Length of sender ATM number = 0
  755.     Type&Length 2 ; Type & Length of sender ATM subnumber = 0
  756.     Type&Length 3 ; Type & Length of sender ATM number = 0
  757.     Type&Length 4 ; Type & Length of sender ATM subnumber =0
  758.     Length 1      ; Source IP address length
  759.     Length 2      ; Target IP address length
  760.  
  761.     Operation code
  762.              0x10 = PROPOSE
  763.  
  764.     VCID Type:   Currently , VCID Type = 1 is defined.
  765.     VCID Length: Length of VCID field
  766.     VCID :       VCID described previous
  767.  
  768. 6.3 PROPOSE ACK
  769.  
  770.    PROPOSE ACK messages is transferred through the Default-VC.
  771.  
  772.      0                   1                   2                   3
  773.      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
  774.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  775.     | Version       |Op code = 1    |        Checksum               |
  776.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  777.     | VCID type     |Flow-ID type=0 |         Reserved              |
  778.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  779.     |                           VCID                                |
  780.     /                                                               /
  781.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  782.  
  783.  
  784.  
  785.  
  786. Nagami, et. al.              Informational                     [Page 14]
  787.  
  788. RFC 2129                   FANP Specification                 April 1997
  789.  
  790.  
  791.     Version
  792.         This field indicates the version   number of FANP.    Currently,
  793.         Version = 1
  794.  
  795.     Operation Code
  796.  
  797.         This field  indicates the operation code   of the message. There
  798.         are five operation codes, below.
  799.  
  800.         operation code = 1 : PROPOSE ACK message
  801.  
  802.     Checksum
  803.         This field is the 16 bits checksum for whole body of FANP message.
  804.         The checksum algorithm is same as the IP header.
  805.  
  806.     VCID Type
  807.         This field indicates the VCID type.  Currently, only "1" is
  808.         defined.
  809.  
  810. 6.4 OFFER message
  811.  
  812.    OFFER message is transferred from an upstream node to a downstream
  813.    node.  The following is the message format.
  814.  
  815.      0                   1                   2                   3
  816.      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
  817.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  818.     | Version = 1   | Op Code = 2   |        Checksum               |
  819.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  820.     | VCID type     |Flow-ID type   |     Refresh Interval          |
  821.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  822.     |                           VCID                                |
  823.     /                                                               /
  824.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  825.     |                         Flow-ID                               |
  826.     /                                                               /
  827.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  828.  
  829.     Refresh Interval
  830.         This field indicates the interval of refresh timer.  The refresh
  831.         interval is represented by second in integer.  This field is
  832.         used only in OFFER message.  Recommended value is 120 (second).
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Nagami, et. al.              Informational                     [Page 15]
  843.  
  844. RFC 2129                   FANP Specification                 April 1997
  845.  
  846.  
  847. 6.5 READY message
  848.  
  849.    READY message is transfered from a downstream node to an upstream
  850.    node. This message is transferred when the downstream node receives
  851.    OFFER message. And this message is transferred periodically in each
  852.    refresh interval. The following is the message format.
  853.  
  854.      0                   1                   2                   3
  855.      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
  856.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  857.     | Version = 1   | Op Code = 3   |        Checksum               |
  858.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  859.     | VCID type     |Flow-ID type   |     Reserved                  |
  860.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  861.     |                           VCID                                |
  862.     /                                                               /
  863.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  864.     |                         Flow-ID                               |
  865.     /                                                               /
  866.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  867.  
  868. 6.6 ERROR message
  869.  
  870.    ERROR message is transfered from a downstream node to an upstream
  871.    node or from an upstream node to a downstream node. This message is
  872.    transferred when some of the fields in the receive message is unknown
  873.    or refused.  When the receive message is the ERROR message, ERROR
  874.    message isn't sent.  VCID type ,VCID, Flow ID Type and Flow ID field
  875.    in the ERROR message are filled with the same field in the receive
  876.    message.
  877.  
  878.    The following is the message format.
  879.  
  880.      0                   1                   2                   3
  881.      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
  882.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  883.     | Version = 1   | Op Code = 4   |        Checksum               |
  884.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  885.     | VCID type     |Flow-ID type   |     Error code                |
  886.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  887.     |                           VCID                                |
  888.     /                                                               /
  889.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  890.     |                         Flow-ID                               |
  891.     /                                                               /
  892.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Nagami, et. al.              Informational                     [Page 16]
  899.  
  900. RFC 2129                   FANP Specification                 April 1997
  901.  
  902.  
  903.     Error Code = 1 : unknown VCID type
  904.                = 2 : unknown Flow-ID type
  905.                = 3 : unknown VCID
  906.                = 4 : resource is unavailable
  907.                = 5 : unavailable refresh interval is offered
  908.                = 6 : refuse by policy
  909.  
  910. 6.7 REMOVE message
  911.  
  912.    REMOVE message is transfered from a downstream node to an upstream
  913.    node or vice versa.  This message is transferred to remove the
  914.    mapping relationship between the flow ID and and the VCID. The node
  915.    which receives REMOVE message must send REMOVE ACK message, even when
  916.    VCID in the receive message isn't known .
  917.  
  918.    The following is the message format.
  919.  
  920.      0                   1                   2                   3
  921.      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
  922.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  923.     | Version = 1   | Op Code = 5   |        Checksum               |
  924.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  925.     | VCID type     |Flow-ID type   |     Reserved                  |
  926.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  927.     |                           VCID                                |
  928.     /                                                               /
  929.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  930.  
  931. 6.8 REMOVE ACK message
  932.  
  933.    REMOVE ACK message is transferred from a downstream node to an
  934.    upstream node or from an upstream node to a downstream node.  The
  935.    following is the message format.
  936.  
  937.      0                   1                   2                   3
  938.      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
  939.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  940.     | Version = 1   | Op Code = 6   |        Checksum               |
  941.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  942.     | VCID type     |Flow-ID type   |     Reserved                  |
  943.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  944.     |                           VCID                                |
  945.     /                                                               /
  946.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Nagami, et. al.              Informational                     [Page 17]
  955.  
  956. RFC 2129                   FANP Specification                 April 1997
  957.  
  958.  
  959. 7. Security Considerations
  960.  
  961.    Security issues are not discussed in this memo.
  962.  
  963. 8. References
  964.  
  965.  
  966.    [1] Katsube, Y., Nagami, K., and H. Esaki, "Router Architecture
  967.        Extensions for ATM; overview", Work in Progress.
  968.  
  969.    [2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
  970.        October 1993.
  971.  
  972.    [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
  973.        Layer 5", RFC 1483, July 1993.
  974.  
  975.    Ethernet is a registered trademark of Xerox Corp.  All other product
  976.    names mentioned herein may be trademarks of their respective
  977.    companies.
  978.  
  979. 9. Authors' Addresses
  980.  
  981.    Ken-ichi Nagami
  982.    R&D Center, Toshiba
  983.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  984.    Phone : +81-44-549-2238
  985.    EMail : nagami@isl.rdc.toshiba.co.jp
  986.  
  987.    Yasuhiro Katsube
  988.    R&D Center, Toshiba
  989.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  990.    Phone : +81-44-549-2238
  991.    EMail : katsube@isl.rdc.toshiba.co.jp
  992.  
  993.    Yasuro Shobatake
  994.    R&D Center, Toshiba
  995.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  996.    Phone : +81-44-549-2238
  997.    Email : masahata@csl.rdc.toshiba.co.jp
  998.  
  999.    Akiyoshi Mogi
  1000.    R&D Center, Toshiba
  1001.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  1002.    Phone : +81-44-549-2238
  1003.    EMail : mogi@isl.rdc.toshiba.co.jp
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Nagami, et. al.              Informational                     [Page 18]
  1011.  
  1012. RFC 2129                   FANP Specification                 April 1997
  1013.  
  1014.  
  1015.    Shigeo Matsuzawa
  1016.    R&D Center, Toshiba
  1017.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  1018.    Phone : +81-44-549-2238
  1019.    EMail : shigeom@isl.rdc.toshiba.co.jp
  1020.  
  1021.    Tatsuya Jinmei
  1022.    R&D Center, Toshiba
  1023.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  1024.    Phone : +81-44-549-2238
  1025.    EMail : jinmei@isl.rdc.toshiba.co.jp
  1026.  
  1027.    Hiroshi Esaki
  1028.    R&D Center, Toshiba
  1029.    1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
  1030.    Phone : +81-44-549-2238
  1031.    EMail : hiroshi@isl.rdc.toshiba.co.jp
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Nagami, et. al.              Informational                     [Page 19]
  1067.  
  1068.