Internet Draft

Internet Draft
Expiration Date: June 1998                               Ken-ichi Nagami
                                                        Yasuhiro Katsube
                                                        Shigeo Matsuzawa
                                                           Akiyoshi Mogi
                                                            Koutarou Ise

                                                                 Toshiba


        Flow Attribute Notification Protocol Version 2 (FANPv2)
                        Distributed Control Mode

                <draft-nagami-csr-fanpv2-dcmode-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) distributed control mode (DC-mode).
    The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to
    communicate mapping information between a specific packet flow and a
    virtual connection that conveys the packet flow.  In the DC-mode,
    the control message exchange for a packet flow between each pair of
    neighboring CSRs is initiated independently from the message
    exchange for the same flow between any other pair of CSRs. The
    DC-mode is applicable to the control of both unicast and multicast
    cut-through paths.


1. Introduction

    The FANPv2 is a protocol used by Cell Switch Routers (CSRs)[1] to



Nagami, et al.                                                 [Page  1]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    communicate mapping information between a specific packet flow and a
    virtual connection that conveys the packet flow.  This draft
    describes the specification of FANPv2 distributed control mode
    (DC-mode), which is one of the two modes provided by the FANPv2 as
    described in [2].

    In the DC-mode, the control message exchange for a packet flow
    between each pair of neighboring CSRs is initiated independently
    from the message exchanges for the same flow between any other pair
    of CSRs. The DC-mode is applicable to the control of both unicast
    and multicast cut-through paths.

    The following descriptions assume ATM as a cut-through switching
    technology although the protocol mechanism can be applied to the
    other switching technologies such as frame-relay.


2. Terminology and Definitions

    o VCID (Virtual Connection IDentifier) [8]
        An identifier of a virtual connection (ATM VC or VP) that
        is uniquely recognized by neighboring nodes.
        In the case that the VPI/VCI values at both endpoints of the
        VC are not the same, the VCID value is composed of the ESI
        (End System Identifier) of either of the neighboring nodes
        and the unique identifier within the node. In the case that
        the VPI/VCI value at one endpoint of a VC is maintained at
        another endpoint, the VPI/VCI value can be used as a VCID.

    o Cut-through forwarding
        Packet forwarding based on VPI/VCI values without layer 3
        processing at the CSR.
        Layer 3 information (e.g., destination IP address) is
        associated with the corresponding VPI/VCI by using FANP.

    o Hop-by-Hop forwarding
        Packet forwarding based on layer 3 information like that of
        conventional routers.  In ATM, cells are re-assembled into
        packets at the router, whose layer 3 headers are analyzed for
        making a forwarding decision.

    o Default-VC
        A VC that is used for hop-by-hop forwarding.  Cells received
        from the Default-VC are reassembled into packets.
        Conventional layer 3 processing is performed for these packets.
        Control packets such as routing messages and FANP messages
        are also transmitted over this VC.

    o Dedicated-VC



Nagami, et al.                                                 [Page  2]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


        A VC that is used for a specific packet flow.  When the
        FlowID for an incoming VC and that for an outgoing VC are the
        same at a CSR, it can forward the packets belonging to the
        flow with the cut-through forwarding.

    o Cut-through path
        A sequence of dedicated-VCs which transmit packets belonging
        to the same FlowID with the cut-through forwarding.

    o FlowID (Flow IDentifier)
        A set of parameters that identify a specific packet flow.
        For example, an end-to-end layer 3 flow is identified by the
        FlowID that contains a source IP address and a destination
        IP address.


3. Cut-through Path Control Procedure

3.1  Overview of the Distributed Control Mode (DC-mode)

    In the DC-mode, the cut-through path establishment procedure for a
    packet flow is initiated at individual nodes on its path in a
    distributed manner.  Each of them transmits FANP control messages to
    its downstream neighbor in order to notify the mapping relationship
    between the packet flow and the outgoing dedicated-VC that will
    convey the flow. The downstream node that has received the control
    message from its upstream neighbor memorizes the received mapping
    information at its incoming interface, and transmits an
    acknowledgment to its upstream neighbor.

    This message exchange with an upstream neighbor at the node does not
    initiate the exchange of any control messages with its downstream
    neighbor. A control message exchange for a flow between a pair of
    CSRs is initiated and carried out independently from the message
    exchange for the same flow between any other pair of nodes.

    As a result of control message exchanges performed at individual
    pairs of nodes, a node can perform cut-through packet forwarding
    when it realizes that both the incoming dedicated-VC and the
    outgoing dedicated-VC are associated with the same FlowID.

    The cut-through path release procedure is also initiated at
    individual nodes on the path.  A node that has detected the trigger
    to release the cut-through path transmits FANP control messages to
    its downstream neighbor in order to cancel the mapping relationship
    between the packet flow and the outgoing dedicated-VC that conveys
    the flow.  The reception of the control messages from the upstream
    neighbor and the cancellation of the mapping relationship at an
    incoming interface of a node do not become the trigger for the



Nagami, et al.                                                 [Page  3]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    control message transmission toward its downstream neighbor.

    Although concrete parameters for the cut-through establishment or
    release trigger are not specified in this document, generic control
    procedures in the case of two typical types of trigger
    (traffic-driven and request-driven control) are described below.

    This subsection describes cut-through path control procedure for the
    case that neighboring nodes are interconnected by the point-to-point
    link for simplicity. Procedures in the case that the neighboring
    nodes are interconnected over other types of ATM datalink are
    described in 3.2.


3.1.1  Traffic-driven Operation

3.1.1.1  Path Establishment / Release

    Figure 1 shows a traffic-driven path establishment procedure for
    unicast packet transmission from a sender H1 to a receiver H2.
    Ingress edge router R1, CSR core router R2, and egress edge router
    R3 are assumed to speak FANPv2 protocol.

    Ingress edge router R1 transmits packets toward its downstream
    neighbor R2 over a default-VC as a default behavior. When R1 decides
    that a packet flow satisfies specific conditions for cut-through
    path establishment, it initiates the path establishment
    procedure. It selects a dedicated-VC for the packet flow, then
    transmits a NOTIFY message, that notifies its downstream neighbor R2
    of the mapping relationship between the packet flow and the selected
    dedicated-VC, to R2. The identifier of the packet flow (FlowID) is
    assumed to be source IP address H1 and destination IP address H2
    (H1, H2).  When R2 accepts the NOTIFY message sent by R1, it
    transmits a NOTIFY ACK message to R1, which concludes a flow
    notification step between R1 and R2.

    Similarly, when R2 decides that the same packet flow as above
    satisfies specific conditions for cut-through path establishment, it
    selects a dedicated-VC that conveys the flow, then transmits a
    NOTIFY message, that notifies its downstream neighbor R3 of the
    mapping relationship between the flow and selected dedicated-VC, to
    R3.  When R3 accepts the NOTIFY message sent by R2, it transmits
    NOTIFY ACK message to R2, which concludes a flow notification step
    between R2 and R3.  When R2 realizes that both the incoming
    dedicated-VC from R1 and the outgoing dedicated-VC to R3 are
    associated with the same flow, it can begin cut-through packet
    transmission by concatenating the incoming and the outgoing
    dedicated-VC at ATM level.




Nagami, et al.                                                 [Page  4]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    Release of the cut-through paths is also performed by individual
    nodes that have detected triggers to release the path.  Each of them
    transmits a REMOVE message, that notifies its downstream neighbor of
    removal of the mapping relationship between the packet flow and the
    dedicated-VC. The downstream node transmits a REMOVE ACK message to
    the upstream node, which concludes a flow removal step between
    neighboring nodes.  Note that the removal of the mapping
    relationship for a packet flow at an incoming interface of a node
    does not initiate the flow removal step for the same flow at its
    outgoing interface.

    Examples of the trigger for cut-through path establishment and
    release are shown below. One or several of them could be selected as
    well as other triggers that are not itemized below.  It is desirable
    that the common triggers are adopted in a domain.

    Establishment Trigger:
      - Transmission of a packet with specific upper layer protocols
        defined by the port-ID of TCP/UDP.
        (ex. http, ftp, and nntp)
      - Transmission of a TCP SYN packet.
      - Transmission of a packet with specific source/destination
        IP addresses.
      - Transmission of more than a certain amount of packets in a
        predetermined period.

    Release Trigger:
      - Decrease of the packet activity (no packet or less than a
        certain amount of packets in a predetermined period).
      - Change of a next-hop entry in a routing table related to
        an active cut-through path.
      - Recognition that a neighbor node isn't running through the
        neighbor discovery protocol [4].

    A similar procedure is applicable to a traffic-driven multicast
    case.  When establishing a multicast cut-through path, each node on
    the multicast tree selects a dedicated-VC toward each of its
    downstream neighbors, and then transmits a NOTIFY message, that
    conveys a mapping relationship between the multicast packet flow and
    the selected dedicated-VC, to each neighbors. The identifier of the
    multicast packet flow (FlowID) would be source IP address and
    multicast group address in the case that the source tree-based
    multicast routing (e.g., DVMRP) is applied, while it would be IP
    address of the core node and multicast group address in the case
    that the core-based multicast routing (e.g., PIM-SM) is applied.

    Trigger for cut-through establishment, e.g., transmission of
    multicast packet, is detected by each node in a manner similar to
    the unicast case. When a node has found a new multicast group member



Nagami, et al.                                                 [Page  5]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    at one of its outgoing interfaces that was not the leaf of the tree,
    it performs the same procedure as the initial establishment toward
    the downstream neighbor at the interface. When a node, on the
    contrary, has recognized that a multicast group member has left the
    group at one of its outgoing interface, it performs the same
    procedure as the release of the cut-through toward the downstream
    neighbor at the interface.


3.1.1.2  Operation for Route Changes

    When a node has recognized a change of the next-hop (downstream
    neighbor) node for an active cut-through path, it stops cut-through
    forwarding and transmits a REMOVE message to cancel the mapping
    relationship for the related packet flow.  The downstream node that
    has received the REMOVE message sends back a REMOVE ACK message, but
    does not perform the flow removal action toward its downstream
    neighbor unless its own next-hop entry for the packet flow has been
    changed.  It will perform the flow removal action toward the
    downstream neighbor if there is no packet activity from the upstream
    neighbor.

    The node that has completed the flow removal action toward the old
    downstream neighbor performs the path establishment procedure toward
    the new downstream neighbor by one of the establishment triggers
    (e.g., transmission of a packet with specific upper layer
    protocols).


    +--+ Ethernet +--+   +-----+   +--+   +-----+   +--+ Ethernet +--+
    |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
    +--+          +--+   +-----+   +--+   +-----+   +--+          +--+
       trigger pkt
       |----------> trigger packet
                    |------------->   trigger packet
                       NOTIFY        |-------------->  trigger pkt
                    ==============>     NOTIFY         |----------->
                       NOTIFY ACK    ===============>
                    <==============     NOTIFY ACK
                                     <===============
                    |=============|
                     Dedicated-VC    |==============|
                                       Dedicated-VC

                                 Figure 1.


3.1.2  Request-driven Operation




Nagami, et al.                                                 [Page  6]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


3.1.2.1  Path Establishment/Release

    Figure 2 shows a request-driven path establishment procedure for
    packet transmission from a sender H1 to a receiver H2. The procedure
    between neighboring nodes is the same as in the traffic-driven case.
    The difference is that the trigger for the path establishment or
    release is not related to the data packets but to the control
    packets such as the RSVP messages[7].

    In the case that the path establishment or release is triggered by
    the RSVP messages, a cut-through path is established from downstream
    to upstream along with the RSVP reservation (Resv) messages.  R2
    that has received a Resv message from R3 performs the flow
    notification procedure by selecting a dedicated-VC for the requested
    flow and transmitting a NOTIFY message to R3.  R2 realizes that the
    flow notification procedure has succeeded when it receives a
    NOTIFY ACK message from R3, and then transmits a Resv message to its
    upstream neighbor R1.  R1 that has received Resv message from R2
    performs the flow notification procedure between R2 similarly.  R2,
    as a result, realizes that both the incoming dedicated-VC from R1
    and the outgoing dedicated-VC toward R3 are associated with the same
    packet flow, and then is able to begin cut-through forwarding.

    Release of the cut-through paths is also performed by individual
    nodes that have recognized expiration of RSVP's reservation state.
    Each of them transmits a REMOVE message, that notifies its
    downstream neighbor of removal of the mapping relationship. The
    expiration of the RSVP reservation state is detected by either
    the reception of RSVP reservation tear message or the timeout of the
    state refresh period.

    Examples of the trigger for cut-through path establishment and
    release in the request-driven case are shown below.

    Establishment Trigger:
      - Establishment of the RSVP reservation state.

    Release Trigger:
      - Expiration of the RSVP reservation state.
      - Recognition that a neighbor node isn't running through the
        neighbor discovery protocol.











Nagami, et al.                                                 [Page  7]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    +--+ Ethernet +--+   +-----+   +--+   +-----+   +--+ Ethernet +--+
    |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
    +--+          +--+   +-----+   +--+   +-----+   +--+          +--+
                  					  Resv
                                       	       	       <----------|
                                           Resv
                         Resv        <--------------|
           Resv     <-------------|     NOTIFY       
       <----------|    NOTIFY        ===============>
                    ==============>     NOTIFY ACK
                       NOTIFY ACK    <===============
                    <=============|
                                     |==============|
                    |=============|    Dedicated-VC
		     Dedicated-VC

                                 Figure 2.


3.1.2.2  Operation for Route Changes

    In the operation driven by RSVP, unlike the case of the
    traffic-driven operation, a change of the next-hop node for the
    packet flow with cut-through forwarding does not initiate the
    procedure for changing the route of the cut-through path.  Since the
    RSVP process itself has a functionality to determine the reservation
    path, e.g., route pinning, it is desirable that the route of the
    RSVP flow is controlled by the RSVP process rather than the native
    routing process.


3.2  Procedure Dependent on Datalink Type

    A previous subsection described the cut-through path control
    procedure for the case that neighboring FANP-capable nodes are
    interconnected by the point-to-point link for simplicity. In
    addition to the point-to-point link, it should be possible for the
    nodes to be interconnected over various types of datalink such as
    ATM networks that provide SVC services.

    This subsection describes FANP procedures between neighboring nodes
    which are interconnected over various types of ATM network as well
    as by the point-to-point link.


3.2.1  Operational Overview

    The FANP procedure between neighboring nodes is composed of :
    (1)Dedicated-VC setup, (2)VCID notification, and (3)Flow



Nagami, et al.                                                 [Page  8]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    notification for cut-through establishment, and (4)Flow removal,
    (5)VCID removal, and (6)Dedicated-VC release for cut-through
    teardown.

   (1) Dedicated-VC setup :
        It is performed only when the neighboring nodes are
        interconnected over an ATM SVC network.  An upstream node
        establishes a dedicated-VC, by using ATM signaling procedure, so
        as to be used as a cut-through path.

   (2) VCID notification :
        It is performed in the case that the VPI/VCI value of the cell
        transmitted by the upstream node and that of the cell received
        by the downstream node are not the same.  Association between a
        dedicated-VC and "VCID", which is being commonly recognized by
        the neighboring nodes terminating the VC, is established at this
        step. One of the following two types of procedure is performed
        depending on the types of ATM network: i)use of an inband
        message (PROPOSE message) that is transmitted over the
        dedicated-VC being used, ii)use of a message (NOTIFY message)
        that associates an Information Element (IE) conveyed by an ATM
        signaling with a VCID value.

   (3) Flow notification :
        It is the core procedure that lets the neighboring nodes share
        the common knowledge about mapping relationship between a packet
        flow (FlowID) and a VCID.  An upstream node notifies a
        downstream node of the mapping relationship (NOTIFY message),
        which is acknowledged by the downstream node (NOTIFY ACK
        message). VCID notification and flow notification can be merged
        into a single message when the two actions are performed
        consecutively (see 3.2.5.1).

   (4) Flow removal :
        It is performed to cancel the registered mapping relationship
        between a packet flow and a VCID.  An upstream node transmits a
        REMOVE_FLOW or REMOVE_ALL message to a downstream node, which is
        acknowledged by the downstream node.  The latter message is used
        to perform the flow removal and the VCID removal (described
        below) at once.

   (5) VCID removal :
        It is performed to cancel the association between the
        dedicated-VC and the VCID allocated at the VCID notification
        step.

   (6) Dedicated-VC release :
        It is performed only when the neighboring nodes are
        interconnected over an ATM SVC network.  An upstream node



Nagami, et al.                                                 [Page  9]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


        releases a dedicated-VC, by using ATM signaling procedure.

    The following four types of datalink which interconnect neighboring
    FANP-capable nodes are possible:

    (a) Point-to-point link that interconnects neighboring nodes directly
    (b) PVC-based ATM network
    (c) VP-based ATM network that provides logical point-to-point link
    (d) SVC-based ATM network

    Some of the above-mentioned procedural steps (e.g., dedicated-VC
    setup and VCID notification) could be omitted in the case of certain
    datalink types, while all of the steps should be executed in the
    case of other datalink types.  Detailed procedures for individual
    datalinks are described from 3.2.2 to 3.2.5.

    Note that the FANP procedure will not work until each node
    recognizes its neighbor nodes as FANP-capable through the neighbor
    discovery protocol specified in [4].  Any messages received from an
    unrecognized neighbor node must be discarded.

    All the messages described in this section have a Sender ID and a
    Receiver ID field except for a PROPOSE message. Each node should
    fill in each of these fields with a Local ID and a Peer ID in its
    neighbor table[4], respectively. If a Sender ID or a Receiver ID in
    the received message is different from the Peer ID or the Local ID
    in the neighbor table, the message must be discarded.  All the FANP
    messages except for a PROPOSE message are conveyed over a
    default-VC.


3.2.2  Operation over Point-to-point Link

    In the operation over the point-to-point link, neither the
    dedicated-VC setup nor the dedicated-VC release is necessary since
    there is no conventional ATM switch between neighboring
    nodes. Neither the VCID notification nor the VCID removal is
    necessary since the VPI/VCI value of an outgoing cell at an upstream
    node and that of an incoming cell at a downstream node are the same
    in this case.

    When an upstream node has detected cut-through establishment trigger
    for a packet flow, it determines VPI/VCI value of an available
    dedicated-VC, and then transmits a NOTIFY[VCID, FlowID] message,
    that conveys the VPI/VCI value as a VCID and the FlowID of the
    packet flow, to its downstream neighbor node. The downstream node
    sends back either an NOTIFY ACK or an ERROR message to the upstream
    node.




Nagami, et al.                                                 [Page 10]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    The upstream node periodically retransmits the NOTIFY[VCID, FlowID]
    message when it has received neither a NOTIFY ACK nor an ERROR
    message in a certain period of time. When it has not received any
    response after a number of retransmissions, it proceeds to a flow
    removal procedure described below.  Default value of the
    retransmission interval and the number of retransmissions are
    described in Appendix C.

    When an upstream node has detected cut-through release trigger for a
    cut-through packet flow, it transmits a REMOVE_FLOW message, that
    includes a VCID value, to the downstream node. The downstream node
    sends back a REMOVE_FLOW ACK message to the upstream node.  The
    upstream node periodically retransmits the REMOVE_FLOW message when
    it has not received REMOVE_FLOW ACK message in a certain period of
    time. Default value of the retransmission interval is described in
    Appendix C.


3.2.3  Operation over ATM PVC

    In the operation over ATM PVC network, a certain amount of PVCs is
    provided between neighboring nodes as an initialization procedure.
    One of the unused PVCs is picked up as a dedicated-VC when a node
    detects cut-through establishment trigger. As the VPI/VCI value of
    an outgoing cell at an upstream node and that of an incoming cell at
    a downstream node are not the same in general, it is necessary that
    the dedicated-VC is given a VCID which can be uniquely identified by
    both endpoints of the VC (VCID notification).

    An upstream side of the PVC transmits a PROPOSE message to a
    downstream side over the selected PVC itself, which conveys the VCID
    value being allocated to the PVC.  The downstream node sends back a
    PROPOSE ACK message to the upstream node over a default-VC, which
    concludes the VCID notification step.

    The upstream node periodically retransmits the PROPOSE message when
    it has received neither a PROPOSE ACK nor a PROPOSE NACK message in
    a certain period of time. When it has not received any response
    after a number of retransmissions, it proceeds to a VCID removal
    procedure described below.  Default value of the retransmission
    interval and the number of retransmissions are described in Appendix
    C.

    After the VCID notification procedure has been successfully
    completed, the flow notification and removal can be performed with
    the same procedure as the point-to-point link case described in
    3.2.2.  The VCID notification procedure can be performed immediately
    after the setup of the PVCs at the initialization phase, or when the
    cut-through establishment trigger is detected.



Nagami, et al.                                                 [Page 11]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



    The VCID value allocated to the PVC at the VCID notification step
    can be released by the VCID removal procedure. The upstream node
    transmits a REMOVE_ALL message to the downstream node, which is
    acknowledged by the downstream node with a REMOVE_ALL ACK message.
    The upstream node periodically retransmits the REMOVE_ALL message
    when it has not received REMOVE_ALL ACK message in a certain period
    of time. Default value of the retransmission interval is described
    in Appendix C.


3.2.4  Operation over ATM VP

    In the operation over ATM VP network, one or several ATM VPs are
    provided between neighboring nodes as an initialization procedure.
    One of the unused VCIs is picked up as a dedicated-VC when a node
    detects cut-through establishment trigger.

    When a single VP is provided between neighboring nodes, all the
    procedures are the same as in the case of the point-to-point link
    operation described in 3.2.2 since the VCI value of an outgoing cell
    at an upstream node and that of an incoming cell at a downstream
    node are the same.  When multiple VPs are provided between
    neighboring nodes, on the other hand, the VCID notification step is
    necessary in order that both nodes recognize which VPI as well as
    VCI is going to be used as a dedicated-VC.


3.2.5  Operation over ATM SVC

    In the operation over ATM SVC network, dedicated-VCs as well as
    default-VCs are provided through the ATM signaling. Procedures for
    cut-through establishment and release differ depending on,
    (i)whether the BLLI(Broadband Low Layer Information) IE is available
    in the underlying ATM signaling, and (ii)whether the SVC for a
    dedicated-VC is set up each time the cut-through establishment
    trigger is detected or a number of surplus SVCs are prepared (VC
    pool[9]), one of which is picked up when the cut-through
    establishment trigger is detected.


3.2.5.1  On-demand SVC Setup with BLLI IE

    When an upstream node detects the cut-through establishment trigger,
    it selects an available temporal ID value called LLID (Low Layer ID)
    and an available VCID value, both of which are identifiers of a
    dedicated-VC to be set up, and then sets up a dedicated-VC by ATM
    signaling. The upstream node conveys the selected 7-bit LLID value
    in the "user specified layer 3 protocol information field" of the



Nagami, et al.                                                 [Page 12]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    BLLI IE of a SETUP message. When the SVC setup has been completed,
    both the upstream and the downstream node memorize the LLID value as
    an identifier of the SVC.

    Then the upstream node transmits a NOTIFY[LLID, VCID, FlowID]
    message to the downstream node, which functions as a VCID
    notification and flow notification at the same time. At the time
    that the NOTIFY[LLID, VCID, FlowID] message is acknowledged by the
    downstream node, both nodes share the common knowledge about the
    identifier "VCID" of the dedicated-VC and about the association
    between the VCID and the "FlowID" that is the identifier of the
    packet flow transmitted over the dedicated-VC. The LLID value can be
    released at both nodes at this stage, and can be recycled for other
    SVCs that are being set up.

    When the upstream node detects the cut-through release trigger, it
    transmits a REMOVE_ALL message to the downstream node, which
    functions as a flow removal and VCID removal at the same time. Then
    the SVC is released by the ATM signaling.


3.2.5.2  On-demand SVC Setup without BLLI IE

    When the upstream node detects the cut-through establishment
    trigger, it selects an available VCID value as an identifier of a
    dedicated-VC to be set up, and then sets up a dedicated-VC by ATM
    signaling. The temporal ID of the SVC, that is commonly recognized
    by both nodes, is not able to be conveyed by the ATM signaling
    message in this case.

    When the SVC setup has been completed, the upstream node proceeds to
    a VCID notification step and a flow notification step that are the
    same as in the case of PVC described in 3.2.3.

    The flow removal, VCID removal, and dedicated-VC release procedure
    are the same as 3.2.5.1.


3.2.5.3  Operation with VC Pool

    In the case that a number of surplus unused SVCs are prepared as a
    pool, neighboring nodes do not have to perform the dedicated-VC
    setup/release procedure nor the VCID notification/removal procedure
    each time a specific cut-through establishment/release trigger is
    detected. When the upstream node detects the trigger to prepare an
    additional dedicated-VC as a pool, it initiates a dedicated-VC setup
    procedure and a VCID notification procedure.

    When the BLLI IE is supported by the ATM signaling, a temporal



Nagami, et al.                                                 [Page 13]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    identifier of the SVC is selected by the upstream node and is
    conveyed by the SVC SETUP message as described in 3.2.5.1. Then the
    upstream node transmits a NOTIFY[LLID, VCID] message to the
    downstream node, which functions as a VCID notification. At the time
    that the NOTIFY[LLID, VCID] message is acknowledged by the
    downstream node, both nodes recognize that the new SVC, which is
    identified by the VCID, is registered into a "VC pool" for future
    use as a dedicated-VC.

    When the BLLI IE is not supported by the ATM signaling, the upstream
    node sets up an SVC without conveying its temporal identifier, and
    then proceeds to a VCID notification step that uses an inband
    PROPOSE message as described in 3.2.3. At the time that the PROPOSE
    message is acknowledged by the downstream node, both nodes
    recognize that the new SVC, which is identified by the VCID, is
    registered into a "VC pool" for future use as a dedicated-VC.

    One of the available SVCs in a VC pool is picked up as a
    dedicated-VC when a cut-through path is being set up.  The flow
    notification and the flow removal procedures are the same as the
    procedure for the point-to-point link described in 3.2.2.  When the
    association with a specific flow is canceled by the flow removal
    procedure, the SVC is returned to a VC pool for future use.


4. Message Format

    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.

    VCID notification messages(PROPOSE, PROPOSE ACK, PROPOSE NACK) are
    carried in the extended ATM-ARP messages defined in RFC1577[6].  A
    PROPOSE message is transferred from the upstream node to the
    downstream node through the dedicated-VC.  PROPOSE ACK and PROPOSE
    NACK messages are transferred from the downstream node to the
    upstream node through the default-VC.

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


4.1 VCID Notification Message

    PROPOSE, PROPOSE ACK and PROPOSE NACK messages are used for VCID
    notification procedure.  They use the extended ATM-ARP message
    format [6] to which the VCID type and the VCID field are added.
    Type & Length fields are set to zero, because the messages don't
    need sender/target ATM address.



Nagami, et al.                                                 [Page 14]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



    PROPOSE message is transferred from the upstream node to the
    downstream node through the dedicated-VC.  PROPOSE ACK and PROPOSE
    NACK messages are transferred from the downstream node to the
    upstream node through the default-VC.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Hardware Type = 0x13          |  Protocol Type = 0x0800       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type&Length 1 | Type&Length 2 |      Operation Code           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Length 1   | Type&Length 3 | Type&Length 4 |   Length 2    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Sender IP Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Target IP Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   VCID Type   |VCID Length    |       Reserved                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        VCID                                   |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type&Length 1 ; Type & Length of sender ATM number    = 0
    Type&Length 2 ; Type & Length of sender ATM subnumber = 0
    Type&Length 3 ; Type & Length of sender ATM number    = 0
    Type&Length 4 ; Type & Length of sender ATM subnumber = 0
    Length 1      ; Source IP address length
    Length 2      ; Target IP address length

    Operation code
              0x10 = PROPOSE
              0x11 = PROPOSE ACK
              0x12 = PROPOSE NACK

    VCID Type:   VCID Type field as described later
    VCID Length: Length of VCID field (Byte)
    VCID :       VCID field as described later


4.2 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 .





Nagami, et al.                                                 [Page 15]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


     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.
        This flag is one if this message is for the IC-Mode[3].
	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
        operation code = 5  : ERROR message
        operation code = 6  : NOTIFY message
        operation code = 7  : NOTIFY ACK message
        operation code = 8  : REMOVE_FLOW message
        operation code = 9  : REMOVE_FLOW ACK message
        operation code = 10 : REMOVE_ALL message
        operation code = 11 : REMOVE_ALL ACK message
        operation code = 12 : UPDATE message
                              (used by IC-mode)
        operation code = 13 : UPDATE ACK message
                              (used by IC-mode)

    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.

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



Nagami, et al.                                                 [Page 16]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



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


4.3 FANP Objects

4.3.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.


4.3.2 Map Object

    A format of MAP OBJECT, which maps VCID, FlowID and LLID, is as
    follows. This object type is 1.

     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 = 1|   Reserved    |         Object Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   VCID Type   |  FlowID Type  |  Error Code   |     LLID      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             VCID                              |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             FlowID                            |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type   : Set to 1 for Map Object
    Object Length : The length of the object (in bytes) includes the
      object header.



Nagami, et al.                                                 [Page 17]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    VCID Type     : The type of VCID. It is zero if no VCID field.
    FlowID Type   : The type of FlowID. It is zero if no FlowID field.
    Error Code    : If this message is ERROR message, the following
                    error code is put into this field.
        Error Code = 1: unknown VCID Type
        Error Code = 2: unknown VCID
        Error Code = 3: unknown FlowID Type
        Error Code = 4: unknown FlowID
        Error Code = 5: resource unavailable
        Error Code = 6: refuse as a matter of policy
        Error Code = 7: hop count threshold exceeded
                        (used by IC-mode)
        Error Code = 8: same FlowID received on different interface
                        (used by IC-mode)
        Error Code = 9: unknown LLID

    LLID          : The Low Layer ID (LLID) field. If LLID isn't needed,
                    this field is zero.
    VCID          : The VCID field as described latter.
    FlowID        : The FlowID field as described latter.


4.3.2.1 VCID Field Format

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

    VCID Type = 1:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ESI of upstream node                       |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                              ID                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       ESI : IEEE 802 MAC address (ESI:End System Identifier [10])
             of the upstream node.
       ID  : A unique identifier allocated by the upstream node. 










Nagami, et al.                                                 [Page 18]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997


    VCID Type = 2: Explicit ATM Label (4 bytes)

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Reservd|        VPI            |             VCI               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3.2.2 FlowID field

    FlowID type value decides FlowID field format.  Currently, FlowID
    type "1", "2" and "3" are defined. The format is shown below.


    FlowID Type = 1:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Source IP address                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Destination IP address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Source IP address      : source IP address of a flow
       Destination IP address : destination IP address of a flow


    FlowID Type = 2:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved                           |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Source IP address                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Destination IP address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Protocol ID            : protocol ID of a flow
       Source IP address      : source IP address of a flow
       Destination IP address : destination IP address of a flow
       Source port            : source port of a flow. If a flow doesn't
                                have it, this field is zero.
       Destination port       : destination port of a flow. If a flow
                                doesn't have it, this field is zero.




Nagami, et al.                                                 [Page 19]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



    FlowID Type = 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Destination IP address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Destination network mask                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Destination IP address   : destination IP address of a flow
       Destination network mask : netmask of a flow


4.3.3 Capability Object

    This object is only used by FANPv2-ND. The value of this object type
    is 2. Details are described in [4].


4.3.4 VCID Range Object

    This object is only used by FANPv2-ND. The value of this object type
    is 3. Details are described in [4].


4.3.5 Hop Count Object

    This object is only used by IC-Mode. The value of this object type
    is 4. Details are described in [3].


4.3.6 Ingress Object

    This object is only used by IC-Mode. The value of this object type
    is 4. Details are described in [3].


4.4 Examples of Message

    ERROR,NOTIFY,NOTIFY_ACK,REMOVE_FLOW,REMOVE_FLOW ACK,REMOVE_ALL and
    REMOVE_ALL ACK messages have a common header and one or more than
    one map objects.

      [ ....]


5.  Security Considerations



Nagami, et al.                                                 [Page 20]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



    Security issues are not discussed in this document.


6.  Intellectual Property Considerations

    Toshiba Corporation may seek patent or other intellectual property
    protection for some or all of 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.


7.  References

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

    [2] Y. Katsube, et al., "Cell Switch Router - Architecture and
        Protocol Overview -", Internet Draft
        draft-katusbe-csr-arch-00.txt(work in progress), Dec. 1997

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

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

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

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

    [7] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)",
        RFC2205, Sep. 1997

    [8] N. Demizu, et al., "VCID: Virtual Connection Identifier",
        Internet Draft draft-demizu-mpls-vcid-01.txt, Oct. 1997

    [9] N. Demizu, et al., "VC Pool", Internet Draft
        draft-demizu-mpls-vcpool-00.txt, Oct. 1997

    [10] "UNI Specification Version 3.1", ATM Forum, Sep. 1994


8.  Authors' Addresses



Nagami, et al.                                                 [Page 21]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



    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

    Yasuhiro Katsube
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : katsube@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

    Koutarou Ise
    Research and Development Center, Toshiba
    1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
    Japan
    Phone : +81-44-549-2238
    EMail : ise@isl.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[6]
    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



Nagami, et al.                                                 [Page 22]

Internet Draft    draft-nagami-csr-fanpv2-dcmode-00.txt        December 1997



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


Appendix C: Default Timer value / Default resend times

    Timer:

       HELLO Timer : 60 sec
       Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec
       Resend Timer(others): 2,4,8,16,32,64,64,64,.... sec

    Resend Times:
       Resend PROPOSE : 3 times
       Resend NOTIFY  : 3 times



































Nagami, et al.                                                 [Page 23]