[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft
Expiration Date: June 1998                               Ken-ichi Nagami
                                                            Koutarou Ise
                                                        Shigeo Matsuzawa
                                                           Akiyoshi Mogi
                                                          Yoshihiro Ohba

                                                                 Toshiba


        Flow Attribute Notification Protocol Version 2 (FANPv2)
                           Neighbor Discovery

                  <draft-nagami-csr-fanpv2-nd-00.txt>


    Status of this memo

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress".

    To learn the current status of any Internet-Draft, please check the
    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).


Abstract

    This memo describes the specification of FANPv2 (Flow Attribute
    Notification Protocol version 2) Neighbor Discovery protocol (ND).
    The ND is used for (1) automatically detecting FANPv2 neighbors, (2)
    obtaining FANPv2 protocol attributes of the neighbors, and (3)
    checking whether consistent states are maintained by the neighboring
    nodes. Both DC-mode (Distributed Control mode)[4] and IC-mode (Ingress
    Control mode)[5] of the FANPv2 use the ND for these purposes.

    The ND operates over multi-access interfaces as well as over
    point-point interfaces.


1. Terminology and Definitions

    o Point-to-point Interface:



Nagami, et al.                                                 [Page  1]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


        A logical interface of a node that can be interconnected to a
        single neighbor node only.

    o Multi-access Interface
        A logical interface of a node that can be interconnected to
        multiple neighbor nodes. An example of this is an interface that
        is attached to an ATM logical IP subnet (LIS).


2. Neighbor Discovery Protocol

2.1 Overview

    The ND is used for (1) automatically detecting FANPv2 neighbors, (2)
    obtaining FANPv2 protocol attributes of the neighbors, and (3)
    checking whether consistent states are maintained by the neighboring
    nodes.

    For this purpose, ND messages are exchanged among nodes in the same
    IP subnet.  A node recognizes that FANP is running on a neighbor
    node as long as it periodically receives ND messages from the
    neighbor.

    A state transition machine is prepared for each neighbor node.  A
    FANP capable node has a "Neighbor Table" for each neighbor.  It
    contains the following fields.

    o Local ID:
        A non-zero value which represents the current ID of a node that
        maintains the Neighbor Table.  When a node sends a FANP message
        to its neighbors, it puts its own Local ID into the "Sender ID"
        field of the message.

        The value of a Local ID is allocated when a FANP starts at the
        node and is unchanged as long as the FANP is running at the
        node. The value must be different from that allocated at the
        past FANP startup times so that the neighbors are able to detect
        FANP restart events at the node.

    o Peer ID:
        A Local ID of a neighbor node.  It is obtained from the "Sender
        ID" field of a receiving message.  If the received Peer ID is
        different from the registered one, the node detects that the
        neighbor node restarted.

    o State:
        The state of the ND for the neighbor node.

    Each state transition machine for the ND states is shown in Figure



Nagami, et al.                                                 [Page  2]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    2.  The node takes different actions depending on the type of a
    network interface (point-to-point/multi-access).

    The ND is explained in detail in the following sections.


2.2 Procedure for Point-to-Point Interface

    Figure 1(a) shows the message sequence in the case of point-to-point
    interface when node A starts or restarts.  For simplicity, Figure
    1(a) shows only the case where node A is the sender of the INIT
    message.  But there is another case where node A is the receiver of
    the INIT message.

    A FANP capable node allocates a new Local ID and stores it in the
    Local ID field in the Neighbor Table when it starts or restarts.
    Then, the node sends an INIT message to the neighbor.  The INIT
    message contains the allocated Local ID in the Sender ID field,
    supported protocol information in the Capability Object, and a range
    of VCIDs in the VCID Range Object.  Then the initial state is set to
    "Sent INIT(S1)".  While the state is in "Sent INIT(S1)", a node
    periodically sends INIT messages.  The default timer value for
    sending INIT messages is 30 seconds. This timer is called a Resend
    Timer.

    When node B receives an INIT message from node A, it searches for
    the corresponding Neighbor Table entry by using the IP source
    address (node A's IP address) field of the received message as the
    search key.  Node B stores the value of the Sender ID field of the
    INIT message into the Peer ID field of the entry.  Then, node B
    sends a RECOGNIZE message to the sender of the INIT message.  The
    RECOGNIZE message contains the Local ID and Peer ID fields (which
    are stored in the Neighbor Table entry) in the Sender ID and
    Receiver ID fields, respectively. It also contains the supported
    protocol information in the Capability Object, and a range of VCIDs
    in the VCID Range Object.

    When node A receives a RECOGNIZE message, it checks whether the
    Receiver ID in the message is the same as the Local ID in the
    corresponding Neighbor Table entry.  When both IDs are the same, node
    A recognizes that node B is a neighbor node, and puts Sender ID
    in the message into Peer ID in the neighbor table and sends
    KEEP_ALIVE message to node B.  The Local ID and the Peer ID in the
    neighbor table are put into the Sender ID and Receiver ID fields of
    the message, respectively. Then the state for node B changes to
    "Operational(S3)".  The message for setting/releasing a Dedicated-VC
    (described in [4][5]) is accepted only in this state.

    When node B receives a KEEP_ALIVE message, it checks whether the



Nagami, et al.                                                 [Page  3]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    Sender ID and Receiver ID in the message are the same as the Peer ID
    and Local ID in the Neighbor Table, respectively. Node B recognizes
    that node A is a neighbor node when both pairs of IDs are the same.
    Then, the state for node A changes to "Operational (S3)".

    While the state in the node is "Operational (S3)", it periodically
    sends KEEP_ALIVE messages to the neighbor node. The Local ID and
    Peer ID in the Neighbor Table are put into the Sender ID and
    Receiver ID fields in the KEEP_ALIVE message, respectively. The
    default interval for sending KEEP_ALIVE messages is 30 seconds.
    When a node receives a KEEP_ALIVE message, the node checks if the
    Sender ID and Receiver ID fields in the message are the same as the
    Peer ID and Local ID in the Neighbor Table, respectively. It
    recognizes that FANP keeps on running in the neighbor node when both
    pairs of IDs are the same.


    A node detects that the neighbor node is down when one of the
    following conditions are met.

    1.  A KEEP_ALIVE message isn't received from the neighbor in a
        specific interval. A default value of this
        interval(Dead-Interval) is three times as long as the KEEP_ALIVE
        resend interval.

    2.  The Sender ID and Receiver ID in the received KEEP_ALIVE message
        are different from the Local ID and Peer ID in the neighbor
        node, respectively.

    In both cases, a node invokes the "Reset the peer" procedure,
    changes a state to "Sent INIT (S1)" and restarts the ND.  Details of
    the "Reset the peer" procedure are shown in Figure 2.


2.3 Procedure for Multi-Access Interface

    Figure 1(b) shows a message sequence in the case of the the
    multi-access interface.  In an initial phase, a node changes a state
    to "Idle (S0)".  A node periodically sends HELLO messages to
    ALLNodes(224.0.0.1) if it is a CSR core router, otherwise to
    ALLRouters(224.0.0.2).  The default interval for sending HELLO
    messages is 60 seconds.

    When a node receives a HELLO message, the node allocates a Local ID
    and puts it into the Local ID field in the Neighbor Table entry
    corresponding to the sender of the HELLO message.  The node sends an
    INIT message which contains the Local ID in the Sender ID field to
    the sender of the HELLO message, and changes the neighbor state to
    "Sent INIT (S1)".  After this, the same procedure as in the



Nagami, et al.                                                 [Page  4]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    point-to-point interface case follows.

    if the node doesn't receive a KEEP_ALIVE message during the Dead
    Interval from its neighbor, it invokes the "Reset the peer"
    procedure and changes the state to "Sent INIT(S1)".  When the node
    doesn't receive an INIT message or a RECOGNIZE message in this state
    during Dead Interval, the state changes to "Idle (S0)".


         Node A     Node B           Node A     Node B
           |           |               |           |
           |           |               |   HELLO   |
           |           |               |<----------|
           |           |               |           |
           |   INIT    |               |   INIT    |
           |---------->|               |---------->|
           |           |               |           |
           | RECOGNIZE |               | RECOGNIZE |
           |<----------|               |<----------|
           |           |               |           |
           |KEEP_ALIVE |               |KEEP_ALIVE |
           |---------->|               |---------->|
           |     :     |               |     :     |
           |KEEP_ALIVE |               |KEEP_ALIVE |
           |<----------|               |<----------|
           |     :     |               |     :     |
           |KEEP_ALIVE |               |KEEP_ALIVE |
           |---------->|               |---------->|

       (a) Point-to-Point Interface   (b) Multi-Access Interface

       Figure 1:  Sequence of Neighbor Discovery Protocol


2.4 Detailed Procedure

    The following is the detailed procedure of the ND.

    Initialize(point-to-point interface):
        1. Allocated a new Local ID and store it in the Neighbor Table.
        2. Send an INIT message.
        3. Start a Resend Timer.
        4. Change the state to "Sent INIT(S1)".

    Initialize(multi-access interface):
        1.  If a node is a core router, send a HELLO message to
            AllNodes(224.0.0.1).  Otherwise, send a HELLO message to
            AllRouters(224.0.0.2).
        2.  If a node is a core router, start a HELLO timer.



Nagami, et al.                                                 [Page  5]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


        3.  Change the state to "Idle(S0)".

    Receive message:
        Take the state specific actions defined in the state transition
        table in Figure 2.

    Expire DEAD Timer or Resend Timer:
        Take the state specific actions defined in the state transition
        table in Figure 2.

    Expire HELLO Timer:
        Send a HELLO message to AllNodes(224.0.0.1)

    Reset the peer Procedure:
        When a node recognizes that a neighbor node is down, it takes
        the following actions.

        1. Clear the Peer ID in the table.
        2. Remove all the dedicated-VCs for the neighbor node.
        3. Generate a new Local ID.
        4. Send an INIT message.


       State: Idle(S0) [MA]
    +----------------+--------------------------+--------------------+
    |  Event         | Action                   | Next State         |
    +================+==========================+====================+
    |                | Generate a new Local ID  | Sent RECOGNIZE(S2) |
    |                | Store Peer ID            |                    |
    |  Recv INIT     | Send RECOGNIZE           |                    |
    |                | Start Resend Timer       |                    |
    |                | Start DEAD Timer         |                    |
    +----------------+--------------------------+--------------------+
    |                | Generate a new Local ID  | Sent INIT(S1)      |
    |  Recv          | Send INIT                |                    |
    |  RECOGNIZE     | Start Resend Timer       |                    |
    |                | Start DEAD Timer         |                    |
    +----------------+--------------------------+--------------------+
    |                | Generate a new Local ID  | Sent INIT(S1)      |
    |  Recv          | Send INIT                |                    |
    |  KEEP_ALIVE    | Start Resend Timer       |                    |
    |                | Start DEAD Timer         |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Generate a new Local ID  | Sent INIT(S1)      |
    |  HELLO         | Send INIT                |                    |
    |   [MA]         | Start Resend Timer       |                    |
    |                | Start DEAD Timer         |                    |
    +----------------+--------------------------+--------------------+




Nagami, et al.                                                 [Page  6]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


       State: Sent INIT(S1)
    +----------------+--------------------------+--------------------+
    |  Event         | Action                   | Next State         |
    +================+==========================+====================+
    |  Recv          | Store Peer ID            | Sent RECOGNIZE(S2) |
    |  INIT          | Send RECOGNIZE           |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Store Peer ID            | Operational(S3)    |
    |RECOGNIZE && A  | Send KEEP_ALIVE          |                    |
    |                | Start DEAD Timer[P-P]    |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Send INIT                | Sent INIT(S1)      |
    |RECOGNIZE && !A |                          |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Send INIT                | Sent INIT(S1)      |
    |  KEEP_ALIVE    |                          |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Stop DEAD Timer          | Idle(S0)           |
    |  DEAD-Timer[MA]| Stop Resend Timer        |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Send INIT                | Sent INIT(S1)      |
    |  Resend Timer  |                          |                    |
    +----------------+--------------------------+--------------------+

       State: Sent RECOGNIZE(S2)
    +----------------+--------------------------+--------------------+
    |  Event         | Action                   | Next State         |
    +================+==========================+====================+
    |  Recv          | Store Peer ID            | Sent RECOGNIZE(S2) |
    |  INIT          | Send RECOGNIZE           |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Send KEEP_ALIVE          | Operational(S3)    |
    |RECOGNIZE && B  | Start DEAD Timer[P-P]    |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Reset the peer           | Sent INIT(S1)      |
    |RECOGNIZE && !B |                          |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Start DEAD Timer[P-P]    | Operational(S3)    |
    |KEEP_ALIVE && B |                          |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Reset the peer           | Sent INIT(S1)      |
    |KEEP_ALIVE && !B|                          |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Stop DEAD Timer          | Idle(S0)           |
    |  DEAD-Timer    | Stop Resend Timer        |                    |
    |   [MA]         | Clear Peer ID            |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Send RECOGNIZE           | Sent RECOGNIZE(S2) |
    |  Resend Timer  |                          |                    |



Nagami, et al.                                                 [Page  7]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    +----------------+--------------------------+--------------------+

       State: Operational(S3)
    +----------------+--------------------------+--------------------+
    |  Event         | Action                   | Next State         |
    +================+==========================+====================+
    |  Recv          | Stop DEAD Timer[P-P]     | Sent INIT(S1)      |
    |  INIT          | Reset the peer           |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Send KEEP_ALIVE          | Operational(S3)    |
    |RECOGNIZE && B  | Reset DEAD Timer         |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Stop DEAD Timer[P-P]     | Sent INIT(S1)      |
    |RECOGNIZE && !B | Reset the peer           |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Reset DEAD Timer         | Operational(S3)    |
    |KEEP_ALIVE && B |                          |                    |
    +----------------+--------------------------+--------------------+
    |  Recv          | Stop DEAD Timer[P-P]     | Sent INIT(S1)      |
    |KEEP_ALIVE && !B| Reset the peer           |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Stop DEAD Timer[P-P]     | Sent INIT(S1)      |
    |  DEAD-Timer    | Reset the peer           |                    |
    +----------------+--------------------------+--------------------+
    |  Expire        | Send KEEP_ALIVE          | Operational(S3)    |
    |  Resend Timer  |                          |                    |
    +----------------+--------------------------+--------------------+

    Condition A: Receiver ID in the received message is the same as the
                 stored ID.

    Condition B: Sender ID and Receiver ID in the received message are
                 the same as the stored ID, respectively.

     &&    : logical AND
     !     : logical NOT
     [P-P] : Point-to-Point Interface
     [MA]  : Multi-Access Interface

    Reset the peer Procedure:
      - Clear Peer ID in the table
      - Remove all the dedicated-VCs for the neighbor node
      - Generate a new Local ID
      - Send INIT

             Figure2 : State Transition Table

3. Message Format




Nagami, et al.                                                 [Page  8]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    FANP control messages are encapsulated in IP packets except for VCID
    notification messages. The protocol ID for these messages is
    110(decimal). They are transfered through default-VC. They consist
    of a common header and object fields.

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


3.1 FANP Common Header

    FANP control messages except for VCID notification messages(PROPOSE,
    PROPOSE ACK,PROPOSE NACK) consist of a FANP common header and FANP
    objects described in section 4.3 .

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Version     |I| Op Code     |         Checksum              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Sender ID                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Receiver ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    /                             Object                            /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Version : The protocol version of FANP. This protocol version is 2.

    I Flag :
        This flag is zero if this message is for the DC-Mode[4].
        This flag is one if this message is for the IC-Mode[5].
        This flag is zero in HELLO,INIT,RECOGNIZE and KEEP_ALIVE messages.

    Operation Code:
        This field indicates the operation code of the message.
        The value of operation code is as follows.

        operation code = 1  : HELLO message
        operation code = 2  : INIT  message
        operation code = 3  : RECOGNIZE message
        operation code = 4  : KEEP_ALIVE message

    Checksum
        This field is the 16 bits checksum for the whole body of the
        FANP message. The checksum algorithm is the same as that used
        for the IP header.




Nagami, et al.                                                 [Page  9]

Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    Sender ID
        The Local ID of the sender of the message. This field is zero
        for HELLO messages.

    Receiver ID
        The Local ID of the receiver of the message. This field is zero
        for HELLO and INIT messages.


3.2 FANP Objects

3.2.1 Object Header

    The FANP object header format is as follows.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Object Type  |  Object Flags |         Object Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type   : The type of this object.

    Object Flags  : The flag of this object. The semantics of this field
                    depends on the object types.

    Object Length : The length of the object (in bytes) includes the
                    object header.


3.2.2 Capability Object

    This object indicates the attribute of the neighbor node. For
    example, it indicates that the neighbor node supports the DC-Mode
    and/or the IC-Mode.  This object is required for INIT and RECOGNIZE
    messages.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Object Type = 2|  Resv   |B|I|D|         Object Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type   : This value is 2.
    Object Length : This value is 4 (bytes).
    D Flag        : Set to 1 if the node supports DC-Mode.
    I Flag        : Set to 1 if the node supports IC-Mode.
    B Flag        : Set to 1 if a dedicated-VC can be used bidirectionally.




Nagami, et al.                                                 [Page 10]


Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997



3.2.3 VCID Range Object

    This object indicates the available VCID range. It is required for
    INIT and RECOGNIZE messages if the datalink is an ATM point-to-point
    link.

    If a dedicated-VC is used bidirectionally, the neighboring nodes for
    the VC must have the same available VCID range.

    Otherwise, the available VCID range is divided into two parts.  The
    node which has lower IP address uses the lower half of the range
    [Minimum VCID, (Maximum VCID - Minimum VCID -1) / 2].  The node
    which has higher IP address used the higher half of the
    range[(Maximum VCID - Minimum VCID - 1) / 2 + 1, Maximum VCID].

    The format of this object is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Object Type = 3| VCID Type     |         Object Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Minimum  VCID                         |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Maximum  VCID                         |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type   : This value is 3.
    Object Flags  : The VCID type
    Object Length : The length of the object (in bytes) including
                    the object header.
    Minimum VCID  : The minimum VCID value
    Maximum VCID  : The maximum VCID value


3.3 Examples of Message

    The formats of the messages are described in this section.

    HELLO, KEEP_ALIVE Messages:
        <Common Header>

    INIT, RECOGNIZE Messages:
        ATM Point-to-point link:
                <Common Header> <Capability Object> <Range Object>




Nagami, et al.                                                 [Page 11]


Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


        Otherwise:
                <Common Header> <Capability Object>

4.  Security Considerations

    Security issues are not discussed in this document.


5.  Intellectual Property Considerations

    Toshiba Corporation may seek patent or other intellectual property
    protection for some of or all the aspects of the technology
    discussed in this document.  If any standards arising from this
    document are or become protected by one or more patents assigned to
    Toshiba Corporation, Toshiba intends to license them on reasonable
    and non- discriminatory terms.


6.  References

    [1] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for
        ATM : Overview", RFC2098, Feb. 1997

    [2] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
        Layer 5", RFC1483, July 1993.

    [3] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Oct. 1993

    [4] K. Nagami, et al., "FANP Version 2 - Distribute Control Mode",
        Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt(work in
        progress), Dec. 1997

    [5] Y. Ohba, et al., "FANP Version 2 - Ingress Control Mode",
        Internet Draft draft-ohba-csr-fanpv2-icmode-00.txt(work in
        progress),Dec. 1997


7.  Authors' Addresses

    Ken-ichi Nagami
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : nagami@isl.rdc.toshiba.co.jp

    Koutarou Ise
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210



Nagami, et al.                                                 [Page 12]


Internet Draft    draft-nagami-csr-fanpv2-nd-00.txt        December 1997


    Japan
    Phone : +81-44-549-2238
    EMail : ise@isl.rdc.toshiba.co.jp

    Shigeo Matsuzawa
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : shigeom@isl.rdc.toshiba.co.jp

    Akiyoshi Mogi
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : mogi@isl.rdc.toshiba.co.jp

    Yoshihiro Ohba
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : ohba@csl.rdc.toshiba.co.jp


Appendix A: How to construct a default-VC

    A default-VC in the case of ATM is as follows.

    SVC            : created using RFC1577[3]
    PVC            : set up by manual configuration
    VP             : VCI = 32 is reserved for the default-VC
    Point-to-Point : VPI = 0, VCI = 32 is reserved for the default-VC


Appendix B: Packet Encapsulation

    In the case of ATM, the encapsulation over default-VCs and
    dedicated-VCs is LLC encapsulation for routed non-ISO protocols
    defined by RFC1483 [2].


Appendix C: Default Timer value / Default resend times

    Timer:

       HELLO Timer : 60 sec
       Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec



Nagami, et al.                                                 [Page 13]