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

Versions: 00                                                            
Internet Draft                                                Yoshihiro Ohba
Expiration Date: June 1998                                Jun-ichi Takahashi
                                                            Shigeo Matsuzawa
                                                            Yasuhiro Katsube
                                                             (Toshiba Corp.)

                                                               December 1997

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

                 <draft-ohba-csr-fanpv2-icmode-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-abstracts.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) Ingress Control Mode (IC 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. The IC Mode is used
    for establishing and releasing a loop-free  cut-through path from an
    ingress node to an  egress node by  forwarding FANP control messages
    along the path.  The IC mode provides  a simple  potential-loop
    prevention  mechanism by using hop count and ingress node
    information,  and  a ''retry'' mechanism that tries to extend
    the cut-through path after setup failures.





Table of Contents

    1.  Introduction ................................................  2
    2.  Terminology .................................................  2
    3.  Cut-through Path Control  Procedure .........................  3

Y. Ohba, et al.                                                 [Page 1]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    3.1.  Overview of Ingress Control Mode ..........................  3
    3.1.1  Path Establishment .......................................  4
    3.1.2  Retry ....................................................  5
    3.1.3  Loop Prevention ..........................................  5
    3.1.4  Path Release .............................................  6
    3.1.5  Route Change .............................................  6
    3.1.6  Hop Count Change .........................................  7
    3.2  Actions Dependent on VC Type ...............................  7
    3.2.1  Actions in Path Establishment Phase ......................  8
    3.2.2  Actions in Path Release Phase ............................  9
    4.  Message Format .............................................. 10
    4.1  Hop Count Object ........................................... 11
    4.2  Ingress Object ............................................. 11
    5.  Security Considerations ..................................... 11
    6.  Intellectual Property Considerations ........................ 11
    References  ..................................................... 12
    Authors Addresses ............................................... 12
    Appendix A.  Protocol Parameters ................................ 13
    Appendix B.  Examples of Optional Trigger Events ................ 13
    Appendix C.  Error Code ......................................... 14


1. Introduction

    This   memo describes the  specification of   FANPv2 (Flow Attribute
    Notification Protocol version 2) Ingress Control Mode (IC Mode). The
    IC  Mode  is used   for   establishing  and  releasing  a  loop-free
    cut-through  path  from an   ingress  node  to  an  egress  node  by
    forwarding FANP  protocol  messages along the  path, whereas another
    mode of FANPv2, Distributed   Control Mode (DC Mode) [1],   operates
    independently of the states of other nodes.

    The IC mode supports a simple potential-loop prevention mechanism by
    using  hop  count  and ingress  node    information, and a   "retry"
    mechanism that tries to extend the cut-through path after path setup
    failures occur for some reason (e.g., ATM connection setup failure).
    In addition, the IC Mode as well as the  DC mode support a mechanism
    to obtain a common  identifier (e.g.,  VCID  [2]) for a  cut-through
    path between  neighboring CSRs (Cell  Switch Routers), including the
    case  where  intermediate L2 switches  may  rewrite the  label value
    between the neighboring CSRs.


2. Terminology

    The  following terms are defined only  for the  IC  Mode. See the DC
    Mode protocol specification for other terms [1].

    Ingress node:  A   node  which initiates   a cut-through  path setup
        procedure, and is a starting point of the path.

    Egress node:   A node  which  becomes  a   termination  point  of  a
        cut-through path. There are three  types of egress nodes: actual
        egress node, proxy egress node,   and temporal egress node.   An

Y. Ohba, et al.                                                 [Page 2]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

        actual  egress node is a node  which is the final destination of
        the   flow, or   which  is  a    routing  boundary (e.g.,   flow
        deaggregation is needed) for the flow.  A proxy egress node is a
        node that is not an  actual egress node and  does not invoke the
        "retry" operation to  extend  the current cut-through  path.   A
        temporal egress node is a node that is not an actual egress node
        and  does invoke the "retry"  operation  to  extend the  current
        cut-through path. See Section 3.1.2 for details.

        The egress node for  a cut-through path may change   with time.
        One example is when the next hop node of  a non-egress node for
        some flow becomes unrecognized as a FANP neighbor.  In this
        case,  the non-egress node becomes a proxy egress node.

    Trigger event: An  event which triggers a  setup  or a release of  a
        cut-through path.

    Mandatory trigger event: A  trigger event which  is defined  in this
        specification.

    Optional trigger  event: A trigger event which   is not specified in
        this  specification. Optional   trigger   events occur only   at
        ingress nodes. Examples of optional trigger  events are shown in
        Appendix B.


3. Cut-through Path Control Procedure

3.1. Overview of Ingress Control Mode

    In this section, basic operations  for setup, retry, loop detection,
    release, and route change of a cut-through path are explained.

    In the IC Mode,  a setup message for creating  a cut-through path is
    sent when  a setup trigger event occurs,  and a  release message for
    deleting the path is sent when a release trigger event occurs.

    There  are two modes of passing  protocol messages: pessimistic mode
    and optimistic mode. In the pessimistic mode, a  node returns an ACK
    for a message after the node makes sure that the message has reached
    its  final receiver  (an  egress node  or an  ingress  node). In the
    optimistic  mode, in contrast,  a node  returns  the ACK immediately
    after the node accepts the message. The optimistic  mode is used for
    quick response   from the neighbor   when it is  guaranteed that the
    message will be forwarded along a  loop-free path, and otherwise the
    pessimistic mode is used for loop prevention.

    For simplicity,  VCs on  point-to-point  links are assumed   for the
    dedicated VCs used in Section 3.1.  Detailed procedures depending on
    the dedicated VC types are described in Section 3.2.

    Note  that  the both  the IC  and  DC modes  use the  same  neighbor
    discovery    protocol.     See  the    neighbor   discovery protocol
    specification [3] for the detailed procedure.

Y. Ohba, et al.                                                 [Page 3]


Internet Draft         FANPv2 Ingress Control Mode         December 1997


3.1.1. Path Establishment

    The pessimistic mode is adopted for the path establishment procedure
    to prevent loops for a newly created cut-through path.

    There  are     four mandatory trigger   events   that  invoke a path
    establishment procedure: (1) reception   of a NOTIFY message from  a
    previous node (described below),   (2)  retry event at   a  temporal
    egress node   (described in Section 3.1.2),  (3)  discovery of a new
    downstream FANP neighbor   at a proxy egress   node, and  (4)  route
    change for the flow at a node whose next  hop on the  new route is a
    FANP neighbor (described in Section 3.1.5).

    When a mandatory  or an optional trigger  event for a flow occurs at
    an ingress node,  the node  prepares  an outgoing dedicated  VC  and
    informs the downstream neighbor of the mapping  between the flow and
    the dedicated VC by sending a NOTIFY message.

    When   a  mandatory trigger  event occurs  at  a node  other than an
    ingress node, the node  registers the mapping  between the  flow and
    the incoming dedicated VC  (if it is  not an ingress node), prepares
    an outgoing  dedicated VC for  the flow, and informs  the downstream
    neighbor of  the mapping between  the flow and  the  dedicated VC by
    sending a NOTIFY message.

    These procedures are  repeated  until a  NOTIFY message reaches  the
    egress node for  the flow. Finally, when the  egress node receives a
    NOTIFY message, it registers the   mapping between the flow and  the
    incoming   dedicated VC, and returns   a NOTIFY ACK   message to the
    upstream neighbor.

    The NOTIFY ACK message is returned on the reverse path for the flow.
    Each intermediate node which receives the NOTIFY ACK message is able
    to carry out  cut-through  forwarding by concatenating the  incoming
    and outgoing dedicated VCs.

    Finally, when the ingress node  receives the NOTIFY ACK message, the
    node  is able to start putting  the datagrams belonging  to the flow
    into the outgoing dedicated VC.

    If a node receives a NOTIFY message which is not acceptable for some
    reason (e.g., an invalid flow is specified, or  a loop is detected),
    it  immediately returns an ERROR  message  to the upstream neighbor,
    instead of forwarding the NOTIFY message to the downstream neighbor.

    When a  node which transmitted a  NOTIFY message receives  the ERROR
    message  instead of a NOTIFY ACK  message, it  becomes a temporal or
    proxy egress node depending on the error  code (see Appendix C), and
    returns  a NOTIFY ACK message to  the upstream neighbor. If the node
    becomes a  temporal egress node,  the path will  be  extended by the
    retry mechanism described in Section 3.1.2.

    NOTIFY messages  are retransmitted until  a NOTIFY ACK  or an ERROR

Y. Ohba, et al.                                                 [Page 4]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    message is received. The retransmission  timer (NOTIFY Timer) is set
    to min(2**(m+1),  64) seconds, where m  means  the current number of
    transmissions.  On the 5th expiration of  the NOTIFY timer, the node
    starts the path release procedure by sending a REMOVE message to the
    downstream neighbor (described in  3.1.4), and returns a  NOTIFY ACK
    message to its upstream  neighbor. A node which fails retransmission
    becomes a temporal egress node for the flow.

    NOTIFY messages  contain a hop  count from an ingress node (referred
    to as Hb) and ingress information, while NOTIFY ACK messages contain
    a hop count from  an  egress node  (referred to  as He) and  ingress
    information. Ingress information is composed  of an IP address at an
    ingress node's output interface  and a local  ID which is  allocated
    locally at the  output  interface.   This  information is used   for
    detecting potential loops (see Section 3.1.3).

    Ingress nodes  set hop-count=1   in their NOTIFY  messages.   Egress
    nodes set hop-count=1 in  their  NOTIFY ACK messages.   Intermediate
    nodes increment the hop counts in the  NOTIFY or NOTIFY ACK messages
    by one. Usage of the hop counts  and ingress node information fields
    are described in detail in Section 3.1.3.

3.1.2. Retry

    If a node  fails to set  up a cut-through path  or receives an ERROR
    message with  specific  error codes,  it becomes  a  temporal egress
    node, and  sets a RETRY timer to  extend the cut-through path toward
    the   flow's destination.  When the RETRY   timer  expires, the node
    resends a NOTIFY message to the  downstream neighbor and waits for a
    NOTIFY ACK.  The  NOTIFY  message  is  forwarded following the  same
    procedure  described in Section 3.1.1. When  the node that initiated
    the retry operation receives a NOTIFY ACK with an updated hop count,
    it must notify the upstream node of the updated hop count by sending
    an UPDATE message.  The  hop count update  operation is described in
    Section 3.1.6.

3.1.3. Loop Prevention

    A node detects a potential-loop when (1) the hop count in the NOTIFY
    message exceeds a threshold or (2) the  specified VCID in the NOTIFY
    message is different from that  already registered for the specified
    FlowID and ingress node information.

    The node which  meets one of the conditions  above  returns an ERROR
    message with error  code  = "hop count  threshold  exceeded" for the
    former condition,  and with error code   = "same FlowID  and Ingress
    Object already registered  on  different interface" for   the latter
    condition. If both conditions (1) and (2)  are met at the same time,
    condition (1) always precedes condition (2) (See Appendix C).

    With condition  (2), message loops  can be detected  without waiting
    for the hop count to exceed the threshold.

    There are some cases where a loop is mis-detected during a transient

Y. Ohba, et al.                                                 [Page 5]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    state  of the routing protocol  where the path release procedure and
    the path establishment procedure may occur in  parallel for the same
    flow. In such cases, the potential-loop detection mechanism works as
    a mechanism  for preventing the  node from increasing  the number of
    transient cut-through paths rather  than loop prevention, especially
    when the route is flapping.

3.1.4. Path Release

    The optimistic mode is adopted for  the path release procedure since
    the released path is guaranteed to be a loop-free path.

    The mandatory trigger events to release a  cut-through path are: (1)
    the node receives   a flow removal request   (by receiving a  REMOVE
    message)  for an  existing path   from its  upstream  node, (2)  the
    upstream or downstream neighbor for the flow becomes unrecognized as
    a FANP neighbor, or (3) the next hop neighbor changes.

    When  a mandatory or an  optional release trigger  event occurs at a
    node, the node  disables cut-through forwarding between the incoming
    and outgoing dedicated VCs (if the node is not an ingress), and then
    sends a REMOVE message in order to inform the downstream neighbor of
    the removal of the mapping between the flow and the dedicated VC.

    When  a  node receives a  REMOVE  message,  it immediately returns a
    REMOVE ACK message to the upstream neighbor.

    When a node receives a  REMOVE ACK  message  after sending a  REMOVE
    message,  the  node removes mapping   between  the flow and outgoing
    dedicated VC.

    REMOVE   messages are retransmitted until a   REMOVE ACK  message is
    received. The retransmission timer values for these messages are set
    to min(2**m,  64) sec.,   where  m  means   the current   number  of
    transmissions of this message.

    Note that if a node becomes  unrecognized, the upstream node for the
    node removes the mapping between the flow and the outgoing dedicated
    VC without sending a REMOVE message.

    See Section 3.2 for detailed path release procedure.

3.1.5. Route Change

    When a  route  for a  cut-through   path is changed,   the following
    operation is    carried out at  each node   that  detected the route
    change.

    First, the path  release procedure  described  in Section 3.1.4   is
    invoked on the old  route to  release the  dedicated  VC on the  old
    route  (triggered by  the   mandatory release  trigger  (3)).  After
    finishing  the path  release procedure, the   node that detected the
    route change starts the   path establishment procedure described  in
    Section 3.1.1  on the new  route  (triggered by  the mandatory setup

Y. Ohba, et al.                                                 [Page 6]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    trigger (4)). When  the    node that  initiated the   route   change
    operation receives a  NOTIFY ACK message with  an updated hop count,
    it must  notify the the upstream  node  of the updated hop  count by
    using an UPDATE message. The hop count update operation is described
    in Section 3.1.6.

    Note that the route change operation may be carried out concurrently
    at multiple nodes.

3.1.6. Hop Count Change

    When a node realizes that the number of hops from the egress node of
    a path is changed due to an event such as a route change, success of
    retry,  recognition of   a new neighbor,   or  loss of  an  existing
    neighbor, it memorizes the updated  hop  count, and sends an  UPDATE
    message to  its upstream  neighbor  with the updated hop  count. The
    upstream node returns an UPDATE ACK to  its downstream node based on
    the optimistic  mode since  the updated  path is  guaranteed to be a
    loop-free path.

    Finally,  when the UPDATE message  arrives at the  ingress node, the
    node replies  with an UPDATE ACK message  and  may decrement the TTL
    with the new hop count value.

    UPDATE  messages are  retransmitted until an  UPDATE ACK  message is
    received. The retransmission  timer value for  the UPDATE message is
    set  to min(2**m, 64) sec.,  where  m means  the  current number  of
    transmissions of this message.

3.2. Actions Dependent on VC Type

    Actions taken during the   path establishment or  release procedures
    differ  depending on the   VC types.  There  are  4 VC types:  VC on
    point-to-point link (P-to-P Link VC), VC  within an ATM VP, ATM PVC,
    and ATM SVC.

    A P-to-P Link VC is a VC which  is set up between directly connected
    neighboring nodes, i.e., there  are no intermediate ATM  switches in
    between and hence the VPI and VCI are not rewritten between them.

    A VC  within an ATM  VP is contained  in a  VP that is pre-allocated
    between a pair of  neighboring nodes.  If  there is only one VP used
    for  cut-through transfer between the  neighboring nodes,  the VC is
    called a VP Type1 VC, otherwise VP Type2 VC.  For VP Type1 and Type2
    VCs, VCIs are not   rewritten between neighboring nodes.   Different
    procedures are taken for VP Type1 VCs and VP Type2 VCs.

    An ATM PVC  is a  VC  which is set up   manually at system   startup
    time. Both the VCI  and VPI are  rewritten between neighboring nodes
    for an ATM PVC.

    An ATM  SVC is a VC  which is  set up  between  neighboring nodes by
    using ATM signaling. There are two types of ATM SVCs. A BLLI-capable
    SVC is an ATM SVC which is set up by  using an ATM signaling message

Y. Ohba, et al.                                                 [Page 7]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    that contains unique  identifier of the  SVC (termed "LLID") in BLLI
    (Broadband Low Layer Information) IE [4]. A BLLI-incapable SVC is an
    ATM SVC which is set up by using  an ATM signaling message that does
    not contain   LLID.  Actions  taken     for BLLI-capable SVCs    and
    BLLI-incapable  SVCs are  also  different depending on  whether a VC
    pool is available or not. Both the VCI and VPI are rewritten between
    neighboring nodes for an ATM SVC.

3.2.1. Actions in Path Establishment Phase

    There  are  three  procedures taken   during  the path establishment
    phase, in the following order:   dedicated VC setup procedure,  VCID
    notification procedure, and flow notification procedure.

    The dedicated  VC setup  procedure  is  the  procedure to prepare  a
    dedicated VC for current or future use. For PVCs, VP Type1 and Type2
    VCs, or  P-to-P  VCs, the dedicated VC  setup  procedure  is invoked
    prior to cut-through path setup trigger events (e.g., system startup
    time).  For  SVCs with VC pool operation  [2], the procedure is also
    carried  out prior  to  cut-through  path setup  trigger  events  by
    invoking ATM signaling.   For SVCs without  VC pool  operation,  the
    procedure is carried out on demand by calling ATM signaling.

    The  VCID notification   procedure   is  used to   obtain  a  common
    identifier for a cut-through path   between neighboring CSRs in  the
    case where the allocated VCIs for the  same VC are different between
    the  neighboring CSRs. There  are  three different VCID notification
    procedures depending on the VC type.

    1.  For a BLLI-capable SVC with VC pool, a NOTIFY[LLID,VCID] message
        in which the FlowID  field is set  to zero is transmitted on the
        default VC  in  order to indicate  the  mapping between the LLID
        (Low  Layer ID) [1] and  the VCID for the   dedicated VC.  After
        this notification, the VCID is used as an identifier for the VC.

    2.  For a  PVC, a VP Type2 VC,  and a BLLI-incapable SVC,  a PROPOSE
        message is transmitted on the dedicated  VC itself to indicate
        the VCID for the dedicated VC.

    3.  For  a BLLI-capable SVC  without VC pool  and a VP Type1 VC, the
        VCID  notification   procedure  is  integrated   into   the flow
        notification message (see below).

    The  VCID notification procedure completes  when the node receives a
    NOTIFY ACK  for the NOTIFY[LLID,VCID]  message  or a PROPOSE ACK for
    the PROPOSE message  from the downstream neighbor. NOTIFY[LLID,VCID]
    and PROPOSE messages  are  retransmitted until a   NOTIFY ACK  or  a
    PROPOSE ACK  message  is received,  respectively. The retransmission
    timer (NOTIFY Timer  or PROPOSE Timer)  is set to  min(2**(m+1), 64)
    seconds, where  m means the current number   of transmissions of the
    message. On the 5th expiration of the retransmission timer, the node
    invokes the path release procedure.

    The  flow notification procedure  is used to  inform the neighbor of

Y. Ohba, et al.                                                 [Page 8]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    the mapping between the  FlowID and VCID of the  dedicated VC. For a
    BLLI-capable SVC without VC pool, a NOTIFY[LLID,VCID,FlowID] message
    in  which each  of  the LLID,  VCID,  and FlowID  fields  contains a
    non-zero value  is transmitted on   the default VC,  integrating the
    VCID notification and flow notification  procedures.  For other VCs,
    a NOTIFY[VCID,FlowID] message in which the LLID field is set to zero
    is transmitted on the default VC.

    The flow notification procedure completes  when the node receives  a
    NOTIFY ACK  or an  ERROR   message  from  the  downstream  neighbor.
    NOTIFY[(LLID,)VCID,FlowID] messages are retransmitted until a NOTIFY
    ACK  message or an  ERROR  message is received.  The  retransmission
    timer  (NOTIFY Timer) is set to   min(2**(m+1), 64) seconds, where m
    means the current number of transmissions of the message. On the 5th
    expiration  of the retransmission timer,  the node  invokes the path
    release procedure.

    The IC and DC modes take the same actions in  the dedicated VC setup
    and VCID  notification procedures  for each  VC type  [1].  The flow
    notification procedure is  different between the IC  and DC modes in
    that (i)  a NOTIFY[(LLID,)VCID,FlowID] message  used in the  IC mode
    contains additional  information (hop count and ingress information)
    and (ii) in  the IC mode, a NOTIFY ACK  message  is not  immediately
    sent back after  receiving a NOTIFY [(LLID,)VCID,FlowID] message, as
    described in Section 3.1.1.

3.2.2. Actions in Path Release Phase

    There are   three procedures  in  path release  phase:  flow removal
    procedure,  VCID   removal  procedure, and    dedicated VC   release
    procedure.

    The flow removal procedure is the procedure to indicate the neighbor
    to remove the  mapping between the  FlowID and VCID of the dedicated
    VC.

    The VCID removal procedure is the procedure to indicate the neighbor
    to remove the mapping between the VCID and the dedicated VC which is
    created by the VCID notification procedure.

    The dedicated VC release procedure is the procedure to release a
    dedicated VC which is prepared in the path setup procedure.

    In these  procedures,    REMOVE  messages are sent   to   downstream
    neighbors.    There  are two types    of REMOVE messages: REMOVE_ALL
    message and REMOVE_FLOW message. For SVCs without VC pool operation,
    all three procedures are  performed by sending a REMOVE_ALL  message
    when the path release trigger event occurs. For other VC types, only
    the flow  removal procedure is  carried out by sending a REMOVE_FLOW
    message,  and other procedures  are carried  out only under abnormal
    situations   (e.g., reset operations).  There are  also two types of
    REMOVE ACK messages. A REMOVE_ALL ACK message  and a REMOVE_FLOW ACK
    message are returned  for   a REMOVE_ALL  message and  a REMOVE_FLOW
    message,  respectively, without   waiting    for an  ACK  from   the

Y. Ohba, et al.                                                 [Page 9]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    downstream neighbor (optimistic mode).

    The IC and DC modes take the  same actions in these three procedures
    between neighboring nodes.


4. Message Format

    The IC Mode specific message format  is defined below. Other message
    formats are the same as in the DC Mode [1].

    NOTIFY[VCID,FlowID] : =
        <FANP_Fixed_Header(I Flag=1, OpCode=6)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID=0)>

    NOTIFY ACK[VCID,FlowID] : =
        <FANP_Fixed_Header(I Flag=1,OpCode=7)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID=0)>

    NOTIFY[LLID,VCID,FlowID] : =
        <FANP_Fixed_Header (I Flag=1,OpCode=6)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID>0)>

    NOTIFY ACK[LLID,VCID,FlowID] : =
        <FANP_Fixed_Header (I Flag=1,OpCode=7)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID>0)>

    ERROR : =
        <FANP_Fixed_Header (I Flag=1,OpCode=5)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID=0)>

    UPDATE : =
        <FANP_Fixed_Header (I Flag=1,OpCode=12)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID=FlowID=0)>

    UPDATE ACK : =
        <FANP_Fixed_Header (I Flag=1,OpCode=13)>
        <Hop_Count_Object>
        <Ingress_Object>
        <Map_Object(LLID=FlowID=0)>

    The definition  of objects  which is  used only in  the IC   Mode is

Y. Ohba, et al.                                                [Page 10]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

    described below.

4.1 Hop Count Object

    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 = 4|  Hop Count    |         Object Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type = 4

    Object Length = 4

    Hop Count: Contains a hop count value.

4.2 Ingress Object

    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 = 5|     Reserved  |         Object Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Ingress IP Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Ingress Local ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Object Type = 5

    Object Length = 12

    Ingress  IP Address: Contains an output  interface IP address of the
        ingress node.

    Ingress  Local ID:  Contains an  id which  is  unique in the  output
        interface specified in the Ingress IP Address field.  This field
        is used when multiple cut-through paths are set  up for the same
        FlowID from the same output interface.  The default value is 0.


5. Security Considerations

    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.

Y. Ohba, et al.                                                [Page 11]


Internet Draft         FANPv2 Ingress Control Mode         December 1997



References

    [1] K. Nagami et  al., FANPv2  Distributed  Control Mode,"  Internet
        Draft, draft-nagami-csr-fanpv2-dcmode-00.txt, Nov. 1997.

    [2] Y. Katsube et al., "Cell Switch  Router -- Architecture and
        Protocol Overview," Internet-Draft,
        draft-katsube-csr-arch-00.txt, Nov. 1997.

    [3] K.  Nagami    et  al.,   "FANPv2  Neighbor   Discovery  Protocol
        Specification," Internet Draft,
        draft-nagami-csr-fanpv2-nd-00.txt, Nov. 1997.

    [4] The ATM Forum Technical Committee, "User-Network Interface (UNI)
        Specification Version 3.1," Sep. 1994.


Authors Address

     Yoshihiro Ohba
        R&D Center, Toshiba Corp.,
        1, Komukai-Toshiba-cho, Saiwai-ku,
        Kawasaki, 210, Japan
        Tel: +81-44-549-2238
        Fax: +81-44-520-1806
        Email: ohba@csl.rdc.toshiba.co.jp

     Jun-ichi Takahashi
        Network Development Dept., Hino Works, Toshiba Corp.,
        3-1-1, Asahigaoka Hino,
        Tokyo, 191, Japan
        Tel: +81-42-585-3447
        Fax: +81-42-589-7441
        Email: takahasi@atm.hino.toshiba.co.jp

     Shigeo Matsuzawa
        R&D Center, Toshiba Corp.,
        1, Komukai-Toshiba-cho, Saiwai-ku,
        Kawasaki, 210, Japan
        Tel: +81-44-549-2238
        Fax: +81-44-520-1806
        Email: shigeom@isl.rdc.toshiba.co.jp

     Yasuhiro Katsube
        R&D Center, Toshiba Corp.,
        1, Komukai-Toshiba-cho, Saiwai-ku,
        Kawasaki, 210, Japan
        Tel: +81-44-549-2238
        Fax: +81-44-520-1806
        Email: katsube@isl.rdc.toshiba.co.jp



Y. Ohba, et al.                                                [Page 12]


Internet Draft         FANPv2 Ingress Control Mode         December 1997


Appendix A. Protocol Parameters

    o Timers (m: the number of transmissions, m>=1)

      + min(2**m,64) sec. for PROPOSE and NOTIFY[LLID,VCID] timers.

      + min(2**(m+1),64) sec. for NOTIFY[VCID,FlowID] and
        NOTIFY[LLID,VCID,FlowID] timers.

      + min(2**m,64) sec. for REMOVE timer.

      + min(2**m,64) sec. for UPDATE timer.

      + RETRY  timer is variable depending  on  the reason of retry.
        The default RETRY timer is 64 sec.

    o The maximum number of message retransmissions/retries

      + 3 times for PROPOSE and NOTIFY[LLID,VCID] messages.

      + 5  times   for NOTIFY[VCID,FlowID]  and NOTIFY[LLID,VCID,FlowID]
        messages.

      + unlimited number of times for REMOVE and UPDATE messages.

      + unlimited number of times for retry operation.

    o The default hop count threshold = 16.


Appendix B. Examples of Optional Trigger Events

    If the FlowID is  given by destination network  prefix (e.g., a pair
    of destination  IP  (network) address  and  netmask), two  types  of
    optional trigger events can be considered:

    1.  For protocol traffic driven case, a setup trigger event is given
        by a routing  table creation event,  and a release trigger event
        is given by a routing table deletion event.

        If the next hop node for a  routing table entry  is updated, a
        setup trigger event and a release trigger event are created in
        turn.

    2.  For data traffic  driven case, a setup  trigger event is created
        when the  data rate for the network  prefix exceeds a threshold,
        and a  release  trigger is created  when the  data rate for  the
        network prefix falls below a threshold.

        Note that for both  cases, the setup trigger  event for the
        default route (network prefix with all 0's) must not be created.



Y. Ohba, et al.                                                [Page 13]


Internet Draft         FANPv2 Ingress Control Mode         December 1997

Appendix C. Error Code

    When an  ERROR message is  sent, the following  error codes are set.
    The  retry operation does  not have  to be  taken (the received node
    becomes a proxy egress node) unless explicitly stated :

    o If the  received LLID  is invalid,  set  error code  = 9
       (unknown LLID).

    o If the received VCID Type is invalid,  set error code = 1 (unknown
      VCID Type).

    o If the   received VCID is  invalid, set  error code   = 2 (unknown
      VCID).

    o If the received FlowID Type is invalid set error code = 3 (unknown
      FlowID Type).

    o If the  received FlowID is  invalid (e.g.,  IPv4 Class  D address
      prefix is specified), set error code = 4 (unknown FlowID).

    o If the received Hop Count exceeds  the threshold, set error code =
      7 (hop count threshold exceeded).

    o If an incoming  VCID which is different from  the received VCID is
      already allocated for the  received FlowID Type, FlowID, and
      Ingress Object,  or if   an outgoing VCID   is  already registered
      for the received FlowID Type, FlowID, and Ingress Object, set
      error code = 8 (same FlowID and  Ingress   Object already
      registered on   different interface). The retry operation is
      invoked.

    o If there is no  enough resource to accept  the message, set  error
      code = 5 (resource unavailable). The retry operation is invoked.

    o If the specified flow must be refused by policy,  set error code =
      6 (refuse by policy).

    Note that if  more  than one conditions   above are met  at the same
    time, upper items precedes the lower ones. For example, if both LLID
    and FlowID are invalid, error code = 9 (unknown LLID) is set.














Y. Ohba, et al.                                                [Page 14]