[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

INTERNET-DRAFT                                               H. Kitamura
<draft-ietf-ipngwg-hbh-ext-csi-02.txt>                   NEC Corporation
Expires in six months                                    22 October 1999

               Connection/Link Status Investigation (CSI)
          IPv6 Hop-by-Hop option and ICMPv6 messages Extension
                 <draft-ietf-ipngwg-hbh-ext-csi-02.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document proposes a new mechanism called "Connection/Link Status
   Investigation (CSI)". It is designed to collect status information of
   nodes along the communication path. One new IPv6 Hop-by-Hop option
   (CSI option) and three new ICMPv6 messages (Status Request/Reply, and
   Status Report) are proposed as extensions for the CSI mechanism.

   The CSI mechanism is based on hop-by-hop data acquisition operations
   and realtime "boomerang" action messages. It is simple and can
   investigate both outgoing and incoming paths between the source and
   the destination with minimum investigation packets.

   It can provide various new functions (e.g. realtime consumed
   bandwidth measurement, etc.). Since it has good characteristics, it
   is possible to innovate current investigation functions (e.g.,
   "traceroute", "pathchar", etc.)

   This document describes specifications of the CSI mechanism and
   defines a set of basic data types. The CSI mechanism is designed as a
   generic framework mechanism. By defining new data types to collect,
   it can be easily applied to various advanced usages.

H. Kitamura                                                    [Page 1]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

1. Introduction

   When network users encounter a bad communication environment in which
   the throughput is much lower than expected or the connection
   reachability is often lost, they want to investigate or diagnose the
   realtime status of their connections and to locate the bottlenecks
   and the problems in the communication path.

   The current IPv6 [IPv6] and ICMPv6 [ICMPv6] specifications, however,
   do not have features for status investigation except the end-to-end
   ICMPv6 Echo Request/Reply messages mechanism, and they do not provide
   sufficient hop-by-hop based status investigation mechanisms.

   This document proposes a new type of simple mechanism, called "CSI
   (Connection/Link Status Investigation)". It is composed of one new
   IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6 messages
   (Status Request/Reply, and Status Report). It provides a node-by-node
   based realtime investigation mechanism and status information of
   nodes along the communication path is collected.

   The current investigation mechanisms ("traceroute", "pathchar", etc.)
   have two types of problems. One is that they issue too many
   probe/reply packets to investigate. This may cause traffic congestion
   and it takes a long time to reach the result. The other, more serious
   problem, is that they can investigate only the OUTGOING path from the
   source to the destination, in spite of the fact that most users have
   a greater need to investigate the INCOMING (download) path from the
   destination to the source.

   The CSI mechanism solves these problems effectively, as is able to
   investigate both outgoing and incoming paths between the source and
   the destination with minimum investigation packets through the use of
   the realtime "boomerang" action messages.

   Furthermore, the result obtained in using the CSI mechanism are more
   reliable than those provided by the current investigation mechanisms,
   because the CSI mechanism enables the varying path problem to be
   avoided. Since the mechanism is simple, it can easily to be
   implemented to any IPv6 nodes.

   The CSI mechanism is designed not only to replace the mechanism such
   as "traceroute" or "pathchar" but also to provide various new status
   investigation functions. It is designed as a generic status
   investigation framework mechanism. By defining new data types to
   collect, it can be easily applied to various advanced usages.
   This document describes specifications of the CSI mechanism and
   defines a set of basic data type definitions, called the "Basic
   Investigation Definition Set".

H. Kitamura                                                    [Page 2]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. Requirements

   It is necessary to satisfy the following requirements to establish an
   efficient hop-by-hop based investigation mechanism.

   1. Investigate both outgoing and incoming paths

      The outgoing and incoming paths between the source and the
      destination are not always the same. The combinations of nodes and
      links that packets pass through the outgoing and incoming paths
      are generally different in large scale networks.

      The current "traceroute" and "pathchar" type investigation
      approaches can collect status information only on the outgoing
      path, in spite of the fact that the overwhelming majority of users
      need to know status information on the incoming path.

      Thus it is necessary to investigate both outgoing and incoming
      paths.

   2. Minimize packet traffic

      The number of probe and reply packets for the investigation must
      be minimized to avoid traffic congestion.

      Thus the "traceroute" or "pathchar" type approaches (which invoke
      multiple probes and multiple replies) are not recommended.

   3. Avoid the varying path problem

      Probe packets going to the same node do not always pass through
      the same paths (node-link combinations) because of dynamic routing
      mechanisms. This varying of paths makes it difficult to provide
      reliable status information.

      Thus it is necessary to avoid the varying path problem to obtain
      reliable information.

   4. Be sufficiently simple

      It must be as simple as the "ping" or "traceroute" mechanism, with
      no need for cumbersome management and authentication mechanisms
      like SNMP.

H. Kitamura                                                    [Page 3]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   5. Enable CSI messages to pass through CSI feature disabled nodes

      Inevitably, there will be nodes that do not implement the CSI
      feature, and some nodes that disable the CSI feature on purpose
      (e.g., by filtering etc.).
      Thus the CSI mechanism must be designed so that no problems occur
      when CSI messages pass through such nodes.

   6. Support lost CSI messages

      CSI messages may be lost, because they are based on ICMPv6.
      The CSI mechanism must be designed so that no serious problems
      occur when CSI messages are lost.

   7. Be scalable and easily expandable

      In order to make the CSI mechanism a generic framework mechanism
      to collect status information of nodes along the communication
      path, it must be scalable and easily expandable.

      Therefore, it must be designed to be applicable to any scale
      networks, and its design must have mechanisms for future
      extension.

   8. Support reachability-less network environment

      The CSI mechanism must be designed to run on any network
      environment.  In addition to running on normal network
      environments that the source can receive reply packets from the
      destination, it must be able to run and locate problems on
      problematic network environments whose connection reachability has
      been lost.

3. Basic design of the CSI mechanism

3.1 CSI Option (IPv6 Hop-by-Hop Option)

   The mechanism incorporates a new IPv6 Hop-by-Hop option, called the
   CSI option, to investigate and acquire status information of nodes
   along the communication path. Option Type of the CSI option must be
   started as 00 to avoid the discarding of packets at CSI feature
   disabled nodes, and the third bit must be set to 1 to record the
   collected data. [see Section 4.2 of RFC2460].

   A packet in which the CSI option is set investigates and acquires
   status information when it passes through the nodes along the path.
   This mechanism helps to minimize the traffic and to avoid the varying
   path problem.

H. Kitamura                                                    [Page 4]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

3.2 Status Request and Status Reply (ICMPv6 messages)

   Second, a pair of messages that makes a round trip probing loop is
   prepared by introducing new ICMPv6 messages (Status Request and
   Status Reply). The behaviors of these messages are similar to those
   of Echo Request and Echo Reply messages [ICMPv6].

                        Outgoing path   ------->
                          Status Request message
                    +------------+     +------------+
             /----->|   node 1   |---->|   node 2   |----->\
            /       +------------+     +------------+       \
           /                                                 \
    +------------+                                      +------------+
    |   source   |                                      |destination |
    | (node 0,6) |                                      |  (node 3)  |
    +------------+                                      +------------+
           \                                                 /
            \       +------------+     +------------+       /
             \<-----|   node 5   |<----|   node 4   |<-----/
                    +------------+     +------------+
                          Status Reply message
                        Incoming path   <-------

                        Fig. 1 Basic CSI mechanism

   Figure 1 shows the basic CSI mechanism. A pair of messages makes a
   round trip loop, the action of which is similar to an action of a
   boomerang. The Status Request message is transferred from the source
   (initiator) node to the destination node along the outgoing path, and
   the Status Reply message is transferred back from the destination
   node to the source node along the incoming path.

   The IPv6 Hop-by-Hop CSI option must be set in both the Status Request
   and the Status Reply messages.

   These Status Request/Reply messages have two roles. One is to trigger
   the status information acquisition by the CSI option operation
   routines on each node along the paths. The other is to carry the
   acquired data that attaches to the messages.

   In general, all of the status information of nodes along the paths is
   collected by one pair of Status Request/Reply messages.

   To ensure that the length of each message packet does not increase as
   it passes through the nodes, the attaching procedure is done by
   inserting the acquired data into a pre-allocated data space area of
   the CSI option header of the messages.

H. Kitamura                                                    [Page 5]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   Each acquired data is called a "Record". One record is basically
   composed of one interface's data. When both the incoming and outgoing
   interfaces are investigated, two record spaces are consumed in the
   data space area per node.

3.3 Status Report (ICMPv6 message)

   The data carrying capacity (the size of the pre-allocated data space
   area) of one pair of Status Request/Reply messages is limited. In
   cases where the number of nodes along the path is large and the total
   record length exceeds the data carrying capacity, it is impossible to
   collect status information data with one pair of messages alone.

   In order to solve this problem, the mechanism incorporates another
   new ICMPv6 message (Status Report). When the data space of the pair
   of the Status Request/Reply probing messages is full, all of the
   collected data records are transferred to the source (initiator) node
   by using this Status Report message.

   When the condition given in section 5 is satisfied, all of the
   collected data records are copied to the prepared Status Report
   message, and the message is transmitted to the source node that has
   initiated the Status Request message.

   After the Status Report message is issued, the data space area of the
   Status Request/Reply probing messages is reset (emptied) and they can
   continue the data collection further.

                        Outgoing path   ------->
                          Status Request message
                    +------------+     +------------+
             /----->|   node 1   |---->|   node 2   |----->\
            /       +------------+     +------------+       \
           /                                 /               \
    +------------+   Status Report message  /           +------------+
    |   source   |<-------------------------            |destination |
    | (node 0,6) |<-------------------------            |  (node 3)  |
    +------------+   Status Report message  \           +------------+
           \                                 \               /
            \       +------------+     +------------+       /
             \<-----|   node 5   |<----|   node 4   |<-----/
                    +------------+     +------------+
                          Status Reply message
                        Incoming path   <-------

                   Fig. 2 Status Report message example

H. Kitamura                                                    [Page 6]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   Figure 2 shows an example that explains how Status Report messages
   are issued. Nodes 2 and 4 satisfy the condition given in section 5.

   Introducing the Status Report removes any restriction on the number
   of nodes along the paths. Thus CSI mechanism can be applied to any
   network environments of any size and scale.

   The Status Report is introduced not only to make the CSI mechanism
   scalable but also to enable it to locate the problem on the
   problematic network environment [see the following section].

3.4 Operation Mode

   The CSI mechanism must be able to run on any network environment.
   Basically, it is designed to run effectively on the normal network
   environments in which the source can receive reply packets from the
   destination.

   In addition, it is required to run and locate problems on the
   problematic network environments whose connection reachability has
   been lost.

   In order to support the latter environments, the idea "Operation
   Mode" is introduced. It has two modes (SPSR and SPMR).

3.4.1 SPSR (Single-Probe/Single-Reply) mode

   The SPSR (Single-Probe/Single-Reply) mode is used to support normal
   network environments in which the source can receive reply packets
   from the destination. Up to here, this document has been discussing
   the SPSR mode. Figure 1 showed a typical procedural example of the
   SPSR mode. The CSI mechanism usually runs in the SPSR mode.

   The policy of the SPSR mode is to minimize the number of packets for
   the investigation. In order to minimize the number of times the
   Status Report is issued, a maximum size is pre-allocated to the data
   space area of the Status Request/Reply messages.

   In most cases, the initiator node sends one probe packet (Status
   Request) and receives one reply packet (Status Reply) for the
   investigation, because the CSI mechanism usually runs on network
   environments in which the number of nodes along the path is not large
   and the size of the total collected record data is smaller than that
   of the pre-allocated data space.

   The initiator receives several Status Report messages only in the
   rather rare case when the number of nodes along the path is large.

H. Kitamura                                                    [Page 7]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

3.4.2 SPMR (Single-Probe/Multiple-Reply) mode

   The SPMR (Single-Probe/Multiple-Reply) mode is used to support
   problematic network environments whose connection reachability has
   been lost.

   In problematic network environments, the source node can not receive
   the Status Reply message. The reply message is lost somewhere on the
   path, and the source can not obtain the collected status information
   that is carried by the Status Report.

   The SPMR mode solves this problem and the location where the problem
   occurred on the path is found.

   In the SPMR mode, all of the nodes along the path must issue Status
   Report messages, when the Status Request/Reply messages pass through
   them. Figure 3 shows the procedure of the SPMR mode.

                        Outgoing path   ------->
                          Status Request message
                    +------------+     +------------+
             /----->|   node 1   |---->|   node 2   |----->\
            / __    +------------+     +------------+       \
           / / /          /                  /               \
    +------------+<-------                  /           +------------+
    |   source   |<-------------------------            |destination |
    |            |<--Status Report messages-------------|            |
    | (node 0,6) |<-------------------------            |  (node 3)  |
    +------------+<-------                  \           +------------+
           \ \_\          \                  \               /
            \       +------------+     +------------+       /
             \<-----|   node 5   |<----|   node 4   |<-----/
                    +------------+     +------------+
                          Status Reply message
                        Incoming path   <-------

                             Fig. 3 SPMR mode

   By using this mode, the location where the problem occurred on the
   path is found. The problem is usually located at the link or node
   that follows the node that issued the last Status Report messages.

   In the SPMR mode, the size of a pre-allocated data space must be
   larger that of data Record(s) for a node. When both the incoming and
   outgoing interfaces are investigated, the size of a pre-allocated
   data space must be larger than that of two data Records.

H. Kitamura                                                    [Page 8]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

3.4.3 Comparison with "traceroute"

   The CSI mechanism in the SPMR mode has a number of advantages over
   the "traceroute" mechanism. The latter can find problems only on the
   outgoing path, while the SPMR mode operation can find problems on
   both the outgoing and incoming paths. In addition, the "traceroute"
   method can be called an MPMR (Multiple-Probe/Multiple-Reply)
   operation as it sends many probe packets, the SPMR mode operation
   sends only one probe packet.

3.5 Destination address type

   It is theoretically possible to adopt all legal IPv6 address types to
   the destination, but this document does not consider the multicast
   address case here in order to simplify the discussion.

   This document considers only the case in which a unicast or anycast
   address is adopted to the destination.

4. Procedure of the basic CSI mechanism

   The procedure of the basic CSI mechanism comprises the following
   steps:

   1. The source node prepares the Status Request message in which
      the IPv6 hop-by-hop CSI option is set, and transmits it
      to the destination.

      Since the Status Request message is accompanied by the CSI option,
      the status information of nodes along the "outgoing" path (from
      the source to the destination) is acquired and collected by the
      message.

      If it is necessary to transmit the Status Report message on the
      "outgoing" path, the return (destination) address of it is taken
      from the "source" address of the IPv6 header of the Status Request
      message.  (as the Return address flag field shows)

   2. The destination node receives the Status Request message from the
      source and transmits the Status Reply message back to the
      destination node.

      At this time, all of the CSI option fields are copied from the
      Status Request message to the Status Reply message, and the Return
      address flag field is turned over. Also, the Hop Limit field of
      the IPv6 header is copied and set as a continuous sequence.

H. Kitamura                                                    [Page 9]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

      Since the Status Reply message is accompanied by the CSI option,
      the status information of nodes along the "incoming" path (from
      the destination to the source) is acquired and collected by the
      message.

      If it is necessary to transmit the Status Report message on the
      "incoming" path, the return (destination) address of it is taken
      from the "destination" address of the IPv6 header of the Status
      Reply message. (as the Return address flag field shows)

   3. The source node receives the Status Reply message from the
      destination node.

   If the investigated nodes on the path satisfy the condition given in
   the following section, all of the collected data records are copied
   to the prepared Status Report message and the message is transmitted
   to the source node that initiates the Status Request message.

5. Status Report message transmission condition and check algorithm

5.1 Transmission condition

   When any of the following conditions is satisfied, the Status Report
   message is transmitted.

   1. Data Space is full

      The pre-allocated Data Space of the Status Request/Reply messages
      is fully filled with collected data Records.

      [Record Count] exceeds [Maximum Record Count]

   2. Hop Limit expires (becomes zero)  (Time Exceeded)

      If the [Hop Limit] expires, the message is discarded and the
      collected data is lost at that point. In order to avoid losing the
      collected data, the Status Report message must be issued.

   3. Run in the SPMR mode

      When the operation mode flag of the Status Request/Reply messages
      is set to the SPMR mode, all of the nodes along the path must
      issue the Status Report messages after the status information is
      acquired.

H. Kitamura                                                   [Page 10]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

5.2 Check Algorithm

   The following algorithm shows the check operation procedures.

     hbh_CSI_management_routine()
     {
        if ([Data Space] is full || [Hop Limit] expires) {
           issue_Status_Report_update();
        }
        Data Record acquisition operations;
        insert the Record into the Data Space;

        if ([Operation Mode] == SPMR) {
           issue_Status_Report_update();
        }
     }

     issue_Status_Report_update()
     {
        prepare Status Report message;
        copy    CSI Option header;
        issue   Status Report message;
        clear  [Data Space];
        [Record Count]=0;
        [Report Count]++;
     }

   This algorithm is based on the policy to minimize the number of
   packets for investigation when the CSI mechanism runs in the SPSR
   mode. By following the algorithm, the number of times the Status
   Report messages are issued is minimized. They are issued only when
   they are absolutely necessary.

   By following the algorithm, Status Report messages are not issued
   immediately after the Data Space becomes full, because the check
   operation ([Data Space] is full) is not done at the same node, but at
   the following node. If the next node is a CSI feature-disabled node,
   the check operation is forwarded to the next node after that. The
   algorithm causes at least a one hop delay to issue the Status Report
   message.

   This delay helps to minimize the number of times Status Report
   messages are issued, because the Status Reply may return to the
   initiator node within the delay period.

H. Kitamura                                                   [Page 11]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

6. Pass through feature-disabled nodes or lost Status Report messages

   No problems occur when the Status Request/Reply messages pass through
   nodes in which the CSI feature has not been implemented or has been
   disabled, because Option Type of the CSI option is started from 00
   and messages are merely skipped [see Section 4.2 of RFC2460].

   No serious problems occur if Status Report messages are lost, because
   losing Status Report messages causes almost the same result as that
   when messages pass through feature-disabled nodes.

   The source node can notice the difference between them, because the
   source can detect the message lost by verifying [Report Count] field
   values of the received messages.

7. IPv6 Hop-by-Hop CSI Option Format

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Opt Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|Invest. Class| Invest. Type  | Reserved    |R| Hop Limit Base|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          | Record Count  | Report Count  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Data Space                          +
      |                                                               |

   Option Type:    8-bit.
                   Identifier of the type of option
                   Value is 001xxxxx (0x20+TBA).
                   (Tentatively 0x22)

   Opt Data Len:   8-bit unsigned integer.
                   Length of the option data fields of this option
                   from [M] to [Data Space].
                   Max: 255
                   Its value depends on the length of [Data Space].

   M:              1-bit (Operation Mode flag)
                   Flag to specify the operation mode [see Section 3.4]

                   =0 run in a SPSR (Single Probe Single Reply) mode
                   =1 run in a SPMR (Single Probe Multiple Replies) mode

H. Kitamura                                                   [Page 12]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   Invest. Class:  7-bit.
                   Investigation Class to define the meanings of the
                   following Invest. Type field. [see Section 11]

                   =0 (reserved)

                   In the Basic Investigation Definition Set,
                   the following values are assigned:
                   =1 investigate the Incoming interface
                   =2 investigate the Outgoing interface
                   =3 investigate both
                                  the Incoming and Outgoing interfaces

   Invest. Type:   8-bit unsigned integer.
                   Investigation Type: Its meaning is defined by the
                   value of [Invest. Class]. [see Section 11]

                   In the Basic Investigation Definition Set,
                   [Invest. Type] is used to specify the Combined
                   Components Group number.

                   Currently the following are assigned:
                   =0 Address
                   =1 Static data
                   =2 Dynamic data with Address compression
                   =3 Dynamic data
                   =4 All data

   Reserved:       7-bit
                   Reserved.

   R:              1-bit. (Return address flag)
                   Flag to indicate return destination address for
                   Status Report ICMP messages.

                   =0 Source Address of IPv6 header of the message.
                           (Status Request ICMP message case)
                   =1 Destination Address of IPv6 header of the message.
                           (Status Reply ICMP message case)

   Hop Limit Base: 8-bit unsigned integer.
                   Copy of initial value of Hop Limit of the IPv6
                   header. The value is never changed (decreased).
                   Node location number [Hop Number] can be calculated
                   with the following formula.
                   [Hop Number] = [Hop Limit Base] - [Hop Limit]
                   For the source node, [Hop Number] is 0.

H. Kitamura                                                   [Page 13]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   Identifier:     16-bit.
                   Identifier to distinguish one message from another.

   Record Count:   8-bit unsigned integer.
                   Counter that shows how many data Records have been
                   recorded in the Data Space area.
                   After one Record is acquired, it is increased by 1.
                   After a Status Report message is issued,
                   [Record Count] is reset.
                   Next data recording position in the Data Space area
                   is calculated by [Record Length] * [Record Count].
                   Min: 0
                   Max: {[Opt Data Len]-8}/[Record Length]

   Report Count:   8-bit unsigned integer.
                   Counter that shows how many Status Report messages
                   have been issued.
                   After one Status Report ICMP message is issued,
                   it is increased by 1.
                   This value is used to check the packet loss of the
                   Status Report messages.
                   Min: 0
                   Max: 255

   Data Space:     [Opt Data Len]-8 octets
                   Pre-allocated buffer space in which to insert
                   the acquired data Records.

                   After a Status Report message is issued,
                   [Data Space] is cleared (emptied).

   After an investigation scenario is chosen, values of [M], [Invest.
   Class] and [Invest. Type] fields are decided and the length of [Data
   Space] is also decided.

   There is no field for the [Record Length]. Its value is decided by
   the values of [Invest. Class] and [Invest. Type].
   [Maximum Record Count] is calculated by the following formula.
   [Maximum Record Count]={[Opt Data Len]-8}/[Record Length]

   In this format, [Version] field is not prepared.
   [Invest. Class] field partially fulfills this role. If a major
   modification is necessary, it will be realized by introducing a new
   value for [Option Type] field.

H. Kitamura                                                   [Page 14]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

8. ICMPv6 Status Request Message Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-

   IPv6 Fields:

   Hop Limit
                   Hop Limit must be larger than the number of nodes
                   on the round trip path.

   Destination Address
                   Any legal IPv6 address except multicast address.
                   [see Section 3.5]

   ICMPv6 Fields:

   Type            TBA (tentatively 142)

   Code            0

   Identifier
                   An identifier to aid in matching Status Reply
                   to this Status Request.
                   May be zero.

   Sequence Number
                   A sequence number to aid in matching Status Reply
                   to this Status Request.
                   May be zero.

   Data
                   Zero or more octets of arbitrary data.

H. Kitamura                                                   [Page 15]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

9. ICMPv6 Status Reply Message Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-

   IPv6 Fields:

   Hop Limit
                   Copied from the Hop Limit field of the invoking
                   Status Request packet and set as a continuous
                   sequence.

   Destination Address
                   Copied from the Source Address field of the invoking
                   Status Request packet.

   ICMPv6 Fields:

   Type            TBA (tentatively 143)

   Code            Shows [Hop Number] that is calculated by the
                   following formula. [Hop Limit Base] - [Hop Limit]

                   This type of Code field usage is unusual. In order
                   to design Status Request/Reply message formats as
                   extended Echo Request/Reply message formats, Code
                   field is applied to show [Hop Number] value.

                   Since Status Request/Reply messages are very similar
                   to Echo Request/Reply messages, there are future
                   possibilities for realizing Status Request/Reply
                   messages by extending Echo Request/Reply messages.

                   There is not any conflict between Code field values
                   of Echo Reply messages and those of the Status Reply
                   messages. For Echo Reply messages, Code field is
                   always filled with 0.
                   For Status Reply messages, the Code field never
                   becomes 0, because Code (Hop Number) = 0 means a
                   source node and the source node never issues a
                   Status Reply message.

H. Kitamura                                                   [Page 16]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   Identifier      The identifier from the invoking Status Request
                   message.

   Sequence        The sequence number from the invoking Status Request
   Number          message.

   Data            The data from the invoking Status Request message.

10. ICMPv6 Status Report Message Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|Invest. Class| Invest. Type  | Reserved    |R| Hop Limit Base|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          | Record Count  | Report Count  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Data Space                          +
      |                                                               |

   IPv6 Fields:

   Destination Address
                   If the invoking message's R flag is 0
                   (i.e. a Status Request message is invoked),
                   the "Source" address of the IPv6 header of the
                   invoking message is copied.

                   If the invoking message's R flag is 1
                   (i.e. a Status Reply message is invoked),
                   the "Destination" address of the IPv6 header of
                   the invoking message is copied.

   ICMPv6 Fields:

   Type            TBA (tentatively 144)

   Code            Shows [Hop Number] that is calculated by the
                   following formula. [Hop Limit Base] - [Hop Limit]
                   This type of Code field usage is unusual.

   Others
                   Copied from the CSI option of the invoking message
                   except Option Type and Opt Data Len.

H. Kitamura                                                   [Page 17]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

11. Investigation Class and Investigation Type

   In this section, the fundamental concept of how to use Investigation
   Class and Investigation Type fields is described.

   Status information that is acquired by the CSI Option operation is
   specified by two fields (Investigation Class and Investigation Type).
   Using those two hierarchical fields provides the CSI mechanism with
   flexible extendabiliy, and makes it easy to apply the CSI mechanism
   to various advanced usages.

   The Investigation Class field defines the meanings of the
   Investigation Type field. If the Investigation Class value is
   changed, the definition of the Investigation Type field is also
   changed.

   This document describes one definition called a "Basic Investigation
   Definition Set". Three Investigation Class values (1, 2, and 3) are
   assigned in this definition.

   By introducing new values for the Investigation Class field and
   preparing new definitions of the Investigation Type field, the CSI
   mechanism is extended.

11.1 Investigation Scenarios and "Basic Investigation Definition Set"

   Investigation scenarios become the bases of definitions of the
   Investigation Type field. By the specific investigation scenarios,
   values of the Investigation Type field are defined.

   It is not necessary to provide universal methods to specify the
   acquired data types, because the number of investigation scenarios is
   finite.

   The "Basic Investigation Definition Set" provides only five
   investigation scenarios (Investigation Types).

   In order to make the "Basic Investigation Definition Set" extendable,
   two concepts are introduced. One is "Elementary Investigation Data
   Components," that define primitive acquired data types. The other is
   "Combined Components Groups", which comprise combinations of
   components chosen from the Elementary Investigation Data Components.

   Investigation scenarios are reflected to the definition of Combined
   Components Groups, and Investigation type is used to specify the
   Combined Components Group number.

H. Kitamura                                                   [Page 18]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

11.2 Definition of Elementary Investigation Data Components

   The following 13 components are defined as "Elementary Investigation
   Data Components".

   1. Mandatory Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |I/F|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        This is a mandatory component;
        each data record must start with it.
        Its definition is different from those of the other components.

        Hop Number:
         Node location number. It can be calculated with the following
         formula.   [Hop Number] = [Hop Limit Base] - [Hop Limit]

        I/F:
         Shows the attribute of the following acquired components.

         =00  Neutral (independent on interface)
         =01  Incoming interface is investigated.
         =10  Outgoing interface is investigated.
         =11  (reserved) (currently invalid)

        Timestamp (22bit):
         Shows timestamp when the following components are acquired.
         The unit is millisecond, and the dynamic range is one hour
         (3,600,000 msec).        (22bit:  2^22= 4194304 > 3600000)

         ICMP [Clock] defines the ICMP timestamp format. It is the
         number of milliseconds that have elapsed since midnight UTC.
         This format is (ICMP timestamp % 3600000). In other words,
         the time in milliseconds with hour parts ignored.

         It is not essential for the timestamp to be accurately
         synchronized with UTC, because its information is generally
         utilized by comparing it with data of the same node that is
         recorded by other probes at other timings.

   2. Upper Address Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address                    +
      |                                                               |
      +---------------------------------------------------------------+

H. Kitamura                                                   [Page 19]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   3. Lower Address Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Lower part of IPv6 Address                    +
      |                                                               |
      +---------------------------------------------------------------+
        One IPv6 address information of the interface is separated into
        two components to compress it. The details of the compression
        are described in Section 13.5

        Since one physical interface usually has more than two IPv6
        addresses (multi-homing problem), some rule or algorithm is
        necessary to choose one IPv6 address from them.
        It is described in Section 13.4

   4. ifType Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifType                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        type of the interface ([MIB-II] defined)

   5. ifSpeed Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifSpeed                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        physical maximum bandwidth of the interface ([MIB-II] defined)

   6. ifInOctets Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifInOctets                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Inbound: Number of received octets ([MIB-II] defined)

   7. ifInPackets Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifInPackets                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Inbound: Number of received packets (not defined in [MIB-II])

        This is essential data that is counted at the interface.
        All types (unicast, multicast, etc.) of packets are included.

        [MIB-II] defines ifInUcastPkts and ifInNUcastPkts.
        The following formula is concluded.
            ifInPackets = ifInUcastPkts + ifInNUcastPkts

        ifInPackets can be directly acquired from counter information
        of the interface, or can be acquired by using this formula.

H. Kitamura                                                   [Page 20]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   8. ifInDiscards Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifInDiscards                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Inbound: Number of packets contained errors ([MIB-II] defined)

   9. ifInErrors Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifInErrors                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Inbound: Number of discarded packets ([MIB-II] defined)

   10. ifOutOctets Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifOutOctets                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Outbound: Number of transmitted octets ([MIB-II] defined)

   11. ifOutPackets Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifOutPackets                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Outbound: Number of transmitted packets
                                             (not defined in [MIB-II])
        This is essential data that is counted at the interface.
        All types (unicast, multicast, etc.) of packets are included.

        [MIB-II] defines ifOutUcastPkts and ifIOutNUcastPkts.
        The following formula is concluded.
            ifOutPackets = ifOutUcastPkts + ifIOutNUcastPkts

        ifOutPackets can be directly acquired from counter information
        of the interface, or can be acquired by using this formula.

   12. ifOutDiscards Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifOutDiscards                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Outbound: Number of packets contained errors ([MIB-II] defined)

   13. ifOutErrors Component
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ifOutErrors                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Outbound: Number of discarded packets ([MIB-II] defined)

H. Kitamura                                                   [Page 21]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

11.3 Categorization of the Elementary Investigation Data Components

   Elementary Investigation Data Components are categorized into two
   types (Static and Dynamic).

   ([Mandatory] component is an exception; It is not categorized.)

    1. Static Data

       Data whose acquired values basically do not depend on probing
       timings and probe messages.
       Acquired values usually show the same values.

       Once such data is collected by the initial probe, it is not
       necessary to collect it with the followed repeated probes.

      ([Upper Address] and [Lower Address] components are exceptions.
       Their values are static, but they are acquired by repeated probes
       to use them as identifiers of investigated nodes (interfaces))

       [Upper Address], [Lower Address], [ifType], and [ifSpeed]
       components belong to this type.

    2. Dynamic Data

       Data whose acquired values depend on probing timings.
       Acquired values are usually different.

       Such data must be collected by the repeated probes.

       Dynamic Data is further categorized into two types.

    2.1 Dynamic Data for normal investigation

        Counter data for regular data (packets).
        These data are acquired by most investigation scenarios.

        [ifInOctets], [ifInPackets], [ifOutOctets] and [ifOutPackets]
        components belong to this type.

    2.2 Dynamic Data for diagnostic investigation

        Counter data for error packets.
        These data are acquired only by diagnostic investigation
        scenarios.

        [ifInDiscards], [ifInErrors], [ifOutDiscards] and [ifOutErrors]
        components belong to this type.

H. Kitamura                                                   [Page 22]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

11.4 Definition of the Investigation Class

   In the "Basic Investigation Definition Set", all of the Elementary
   Investigation Data Components are the property information of the
   interface.

   Accordingly, the following three Investigation Classes are assigned
   to specify which interface(es) is(are) investigated.

    [Invest. Class]=1: Investigate only the Incoming interface
       One data Record is consumed in the Data Space area per node.

    [Invest. Class]=2: Investigate only the Outgoing interface
       One data Record is consumed in the Data Space area per node.

    [Invest. Class]=3: Investigate both
                                   the Incoming and Outgoing interfaces
       Two data Records are consumed in the Data Space area per node,
       because two interfaces are investigated.

11.5 Definition of the investigation scenarios (Investigation Type)

   The number of the investigation scenarios is finite because they are
   specified by the user applications, and they have a close
   relationship with the categorization of components.

   In the "Basic Investigation Definition Set", the following five
   investigation scenarios are defined. Each investigation scenario
   creates a "Combined Components Group" and one [Invest. Type] field
   value is assigned for it.

    [Invest. Type]=0: Address Group

      This is the simplest group.
      Record Route operation is done by this scenario.
      The group is composed of [Mandatory], [Upper Address], and
      [Lower Address] components.

    [Invest. Type]=1: Static data Group

      This group is used in initial probing messages.
      The group is composed of [Mandatory], [Upper Address],
      [Lower Address], [ifType], and [ifSpeed] components.

    [Invest. Type]=2: Dynamic data with Address compression Group

      This group is used in repeated probing messages for
                                         the normal investigation.

H. Kitamura                                                   [Page 23]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

      The definition of the group depends on the Investigation Class.

        If the Incoming interface is investigated ([I. Class]=1,3]),
        counter components for inbound octets and packets are chosen.
          The group is composed of [Mandatory],
          [Lower Address], [ifInOctets], and [ifInPackets] components.

        If the Outgoing interface is investigated, counter components
        for outbound octets and packets are chosen.
          The group is composed of [Mandatory],
          [Lower Address], [ifOutOctets], and [ifOutPackets] components.

      Since this group contains only [Lower Address], simple address
      compression is done.

    [Invest. Type]=3: Dynamic data Group

      This group is used in repeated probing messages for
                                         the normal investigation.

      The definition of the group depends on the Investigation Class.

        If the Incoming interface is investigated ([I. Class]=2,3]),
        counter components for inbound octets and packets are chosen.
          The group is composed of [Mandatory], [Upper Address],
          [Lower Address], [ifInOctets], and [ifInPackets] components.

        If the Outgoing interface is investigated, counter components
        for outbound octets and packets are chosen.
          The group is composed of [Mandatory], [Upper Address],
          [Lower Address], [ifOutOctets], and [ifOutPackets] components.

      This group differs from the [Invest. Type]=2 in that it
      contains both [Upper Address] and [Lower Address].
      There is no address compression.

    [Invest. Type]=4: All data Group

      This group is used in probing messages for
                                         the diagnostic investigation.

      This is the largest group. It contains all components.

      The group is composed of [Mandatory],
      [Upper Address], [Lower Address], [ifType], [ifSpeed],
      [ifInOctets], [ifInPackets], [ifInDiscards], [ifInErrors],
      [ifOutOctets], [ifOutPackets], [ifOutDiscards] and [ifOutErrors]
      components.

H. Kitamura                                                   [Page 24]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

12 Data Record Format in Data Space and Examples

   In this section, the rule of Data Record format in Data Space and
   component stacking orders in each Record are explained.

   The Data Space is filled by the acquired data Records in natural
   manners from the first to the last. If any records are not inserted
   into the Data Space on some nodes intentionally (e.g., by disabling
   the CSI feature), no gaps or padding are inserted instead of them.

   One data Record is composed of the status information of one
   interface. If both the incoming and outgoing interfaces are
   investigated (i.e., [Invest. Class] = 3]), two Records are inserted
   into the Data Space. The first record is for the incoming interface,
   and the second record is for the outgoing interface. If an
   acquisition for either interface is disabled, only one acquired
   Record is inserted without padding.

   All Records must start with the [Mandatory] component.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |I/F|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The other chosen components of each record follow it and are stacked
   in the following order:

      [Upper Address], [Lower Address], [ifType], [ifSpeed],
      [ifInOctets], [ifInPackets], [ifInDiscards], [ifInErrors],
      [ifOutOctets], [ifOutPackets], [ifOutDiscards] and [ifOutErrors]

   This order is based on the order of data types (Static Data, Dynamic
   Data for normal investigation, and Dynamic Data for diagnostic
   investigation)

   If information of some components of a Record is not acquired by some
   reasons (e.g., operations are disabled on purpose), fields for such
   components are filled with zero. The length of each record is fixed,
   and never changed.

   Some specific examples are shown in the following sections.

H. Kitamura                                                   [Page 25]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

12.1 Record Route Operation

    Investigation Class = 1 (Incoming I/F)
    Investigation Type  = 0 (Address)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
    Record Unit:           20-octet       Number of Records: 1
    Maximum Record Count:  12

    Investigation Class = 2 (Outgoing I/F)
    Investigation Type  = 0 (Address)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
    Record Unit:           20-octet       Number of Records: 1
    Maximum Record Count:  12

H. Kitamura                                                   [Page 26]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

    Investigation Class = 3 (Incoming and Outgoing I/F)
    Investigation Type  = 0 (Address)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
    Record Unit:           20-octet       Number of Records: 2
    Maximum Record Count:  12

12.2 Initial Probing Operation

    Investigation Class = 1 (Incoming I/F)
    Investigation Type  = 1 (Static)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifType                 [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifSpeed                [Incoming I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           28-octet       Number of Records: 1
    Maximum Record Count:  8

H. Kitamura                                                   [Page 27]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

    Investigation Class = 2 (Outgoing I/F)
    Investigation Type  = 1 (Static)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifType                 [Outgoing I/F]   |
      +---------------------------------------------------------------+
      |                       ifSpeed                [Outgoing I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           28-octet       Number of Records: 1
    Maximum Record Count:  8

12.3 Normal Repeated Probing with Address Compression Operation

    Investigation Class = 1 (Incoming I/F)
    Investigation Type  = 2 (Dynamic with Address Compression)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifInOctets             [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInPackets            [Incoming I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           20-octet       Number of Records: 1
    Maximum Record Count:  12

H. Kitamura                                                   [Page 28]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

    Investigation Class = 2 (Outgoing I/F)
    Investigation Type  = 2 (Dynamic with Address Compression)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifOutOctets            [Outgoing I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutPackets           [Outgoing I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           20-octet       Number of Records: 1
    Maximum Record Count:  12

    Investigation Class = 3 (Incoming and Outgoing I/F)
    Investigation Type  = 2 (Dynamic with Address Compression)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifInOctets             [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInPackets            [Incoming I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifOutOctets            [Outgoing I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutPackets           [Outgoing I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           20-octet       Number of Records: 2
    Maximum Record Count:  12

H. Kitamura                                                   [Page 29]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

12.4 Normal Repeated Probing Operation

    Investigation Class = 1 (Incoming I/F)
    Investigation Type  = 3 (Dynamic)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifInOctets             [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInPackets            [Incoming I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           28-octet       Number of Records: 1
    Maximum Record Count:  8

    Investigation Class = 2 (Outgoing I/F)
    Investigation Type  = 3 (Dynamic)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |1 0|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Outgoing I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifOutOctets            [Outgoing I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutPackets           [Outgoing I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           28-octet       Number of Records: 1
    Maximum Record Count:  8

H. Kitamura                                                   [Page 30]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

12.5 Diagnostic Probing (Collect All data) Operation

    Investigation Class = 1 (Incoming I/F)
    Investigation Type  = 4 (All)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hop Number  |0 1|  Timestamp (22bit, unit: msec, range: 1hour)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Upper part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                                                               |
      +                 Lower part of IPv6 Address   [Incoming I/F]   +
      |                                                               |
      +---------------------------------------------------------------+
      |                       ifType                 [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifSpeed                [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInOctets             [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInPackets            [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInDiscards           [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifInErrors             [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutOctets            [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutPackets           [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutDiscards          [Incoming I/F]   |
      +---------------------------------------------------------------+
      |                       ifOutErrors            [Incoming I/F]   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Record Unit:           60-octet       Number of Records: 1
    Maximum Record Count:  4

H. Kitamura                                                   [Page 31]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

13. Miscellaneous Considerations

13.1 Comparison with an investigation by the Router Alert option

   The Router Alert option [RFC2711] is one of the hop-by-hop options.
   It has potential to achieve an investigation mechanism.  An
   investigation based on the Router Alert option will be accomplished
   by defining a new message which will be managed by each Router Alert
   option operation routines on nodes, and preparing packets in which
   the Router Alert option and the message is set.

   Compared with the CSI mechanism, the mechanism based on the Router
   Alert option has the following weak points.

    1. Without introducing boomerang type special messages like
       Status Request/Reply, it can investigate only the status of
       the outgoing path like a "traceroute".
       The status of the incoming path is not investigated.

    2. It can run only in the SPMR (Single-Probe/Multiple-Reply) mode.
       It will work effectively on problematic network environments,
       but it will not efficient on the normal network environments,
       because it issued multiple reply packets.
       Compared with the SPSR (Single-Probe/Multiple-Reply) operation,
       the SPMR operation is less efficient.

13.2 Characteristics and Implementation on Nodes (Routers)

   As described before, the specification of the CSI mechanism is simple
   enough to implement on any IPv6 nodes.

   The CSI mechanism design is based on the following policies.

    1. It does not ask for complex and intelligent operation
       implementations to intermediate nodes (routers), because main
       roles of them on such nodes are simple data acquisition
       operations.

    2. It requests intelligent operations only to a utility application
       on the initiator node, because the collected data is analyzed
       only by the application.

   In order to acquire data records composed of the elementary data
   components by the CSI option operation, there is a condition that the
   ICMP (timestamp) and MIB II features are properly implemented.  Since
   most nodes satisfy the condition, it is easy to implement the CSI
   mechanism on such nodes.

H. Kitamura                                                   [Page 32]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   The reliability of the collected data is not dependent on the time
   how long data acquisition operations take. This means that high speed
   processing of them is not necessary and performance issues are not
   relevant to the mechanism. Therefore, the CSI mechanism can be
   implemented on most intermediate nodes (routers) with ease.

13.3 Hop-by-Hop CSI Option Operation Routines (Input/Output)

   Basically, Hop-by-Hop CSI option operation routines are executed
   twice in the kernel of the nodes, once as an input side operation to
   acquire the status information of the incoming interface, and also as
   an output (forwarding) side operation to acquire the status
   information of the outgoing interface.

   Input and output side operations are basically independent on each
   other. The CSI option fields ([Record Count] and [Report Count]) are
   updated independently in both the operations.

   When both the incoming and outgoing interfaces are investigated
   (i.e., [Invest. Class]=3]) in the SPMR mode, there are two methods to
   issue the Status Report message(s). One is to issue two Status Report
   messages from one node. The Status Report message for one Record is
   issued twice in the input and output side operations respectively.
   The other is to issue one Status Report message from one node. The
   Status Report message for two Records is issued only in output side
   operation. Both methods are acceptable, but the latter is advisable
   from the viewpoint to minimize the traffic.

13.4 Timestamp and Realtime Consumed Bandwidth Measurement

   Since timestamp and counter information are collected by using the
   CSI mechanism, Realtime consumed bandwidth can be calculated.

   By sending repeated probes periodically with a certain interval,
   timestamp value T(n) and counter value C(n) of an interface on a
   certain node are obtained.

   The following shows a formula how to calculate the realtime consumed
   bandwidth of the interface on the node.

   Consumed Bandwidth:
     B(n) = (delta C)/(delta T) = (C(n+1)-C(n))/(T(n+1)-T(n))

   Since (delta C) and (delta T) are closed information on the node,
   they are accurate. Therefore, B(n) becomes accurate information.

H. Kitamura                                                   [Page 33]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   In the usage of this formula, it is not necessary to synchronize
   timestamp information with any time coordinates. Only the dynamic
   range of it must be sufficient larger than the round trip times and
   intervals of the probes.

13.5 Recording IP address Choosing Operation

   One physical interface usually has more than two IPv6 addresses. Some
   rule or algorithm is necessary to choose one IPv6 address from them.
   (This is a part of multi-homing problems.)

   In order to choose one appropriate IP address that is to be acquired
   and recorded to the Data Space area from IP addresses of the
   interface, the following rule/algorithm is applied.

   1. For an input operation, the destination address of the
      IP header is compared with the IP addresses of the interface.
      If a matching address is found, it is chosen.

      (With this algorithm, probing messages in which both CSI and
       Route options are set bring appropriate results. The recorded
       incoming addresses are the same as those specified in the
       source route path)

   2. The scope (global, site-local, link-local, or node-local) of
      the destination address is determined, and compared with the
      scope of the IP addresses of the interface.

      If an IP address that has the same scope of the destination
         address is found, it is chosen.
         If multiple same-scope addresses are found,
            the first found address can be chosen.
           (It is better to choose the longest prefix matched address.)
      Else,
         IP addresses of the interface are prioritize in the following
         order: global, site-local, link-local, or node-local, and
         the address with the highest priority is chosen.

   This procedure is basically the same as that for choosing addresses
   to be filled into the source address field of general IP packets.

H. Kitamura                                                   [Page 34]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

   13.6 Simple IP address Compression

   With the current specification, one octet is assigned for the [Opt
   Data Len] field. The total length of the CSI option fields is limited
   to 256 octets, which is not long enough to record much data. In order
   to maximize the amount of data that can be recorded, an efficient
   (compressed) data format is necessary.

   IP address information occupies 16 octets, which is four times as
   large as the size of other property information. It is static
   information, and can be compressed.

   The IP address compression is achieved by the following simple
   technique. An IP address information is separated into two parts
   (upper and lower), which are recorded as independent components. When
   the upper part information is not necessary, only lower part
   information is recorded, and vice versa. By using this simple method,
   IP address information is compressed.

   Basically, the upper part contains network proper information
   (prefix), and the lower part contains node (interface) proper
   information. This characteristic helps make it possible to achieve
   the effective IP address compression.

   When the CSI mechanism is applied in a private network environment,
   there will be some cases in which the upper part information for all
   IP addresses is the same and only the lower part information is
   necessary.

   In case of repeated probing to the same path, after the initial probe
   records the full IP addresses of the nodes on the path, it is no
   longer necessary to record upper parts to identify the nodes
   (interfaces) for later probes.

H. Kitamura                                                   [Page 35]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

13.7 Coexistence with Route Option (source route)

   In this section, the relationship between the CSI mechanism (CSI
   option) and the source routing mechanism (Route option) is described.
   Basically, the CSI mechanism can coexist with the source routing
   mechanism, but the following issues must be considered.

   It is easy to specify the source route path for the "outgoing" path,
   because such a packet is issued from the source node. On the other
   hand, it is almost impossible to specify the source route path for
   the "incoming" path, because such a packet is issued from the
   destination node. There is no convenient way to transfer the source
   path specification information for the "incoming" path from the
   source node (user applications) to the destination node.

   Even if such information transfer were possible by some method,
   another problem would occur. The CSI option operation routines, which
   manage the "incoming" CSI message (Status Reply) in which the Route
   option is set, can not issue proper Status Report messages. This is
   because the return (destination) address for the Status Report
   message can not easily be obtained from the invoked Status Reply
   message.

   The return (destination) address for the Status Report message must
   be the address of the initiator node. For an "incoming" path, the
   return address is taken from the "destination" address of the invoked
   Status Reply message [see Section 4]. Since the Route option modifies
   the "destination" address of the message, it does not indicate the
   address of the initiator node and a problem occurs.

   By introducing a special usage of the source routing, these problems
   are solved comprehensively. It is possible to make a source route
   path as a loop path (the source node and the final destination node
   are the same) by specifying all the nodes on the CSI probing loop
   path. With this method, nodes on the loop path can be investigated by
   means of the Status Request message alone. Since the loop path is
   composed of an "outgoing" path only and the "incoming" path has been
   eliminated, all problems vanish.

   Since the CSI option can coexist with the Route option, the CSI
   mechanism can easily avoid the varying path problem of the dynamic
   routing mechanism and can provide reliable information by using
   repeated probing procedures [see Appendix B: -fixroute option].

   In addition, this means that the CSI mechanism can be applied to
   mechanisms that are based on a source routing mechanism (e.g., mobile
   IP for IPv6).

H. Kitamura                                                   [Page 36]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

14. IANA Considerations

   The CSI mechanism incorporates one new IPv6 Hop-by-Hop option and
   three new ICMPv6 messages. In order to implement the CSI mechanism,
   the option and message types are tentatively assigned from unassigned
   spaces as follows:

    IPv6 Hop-by-Hop CSI Option Type:    0x22 (Tentatively)
    Status Request ICMPv6 Message Type:  142 (Tentatively)
    Status Reply   ICMPv6 Message Type:  143 (Tentatively)
    Status Report  ICMPv6 Message Type:  144 (Tentatively)

   These numbers must be assigned by IANA officially.

   The numbers to be assigned to the Investigation Class and
   Investigation Type fields will be maintained by IANA.

15. Security Considerations

   Since the CSI mechanism is based on ICMPv6 messages, the security
   feature of the CSI mechanism follows that of ICMPv6. It is described
   in the Security Considerations section of the Internet Control
   Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
   Specification [ICMPv6].

   In addition, the status information of the investigated node is
   transferred to the investigator node by the investigation procedure
   of the CSI mechanism. Basically, the CSI mechanism does not provide
   any authentication in the investigation procedure. The absence of
   authentication helps to make the CSI mechanism simple and light, but
   it may make it vulnerable from the standpoint of security.

   Thus, it is advisable to implement IP address based access filtering
   or authentication mechanisms for the probing packets of the CSI
   mechanism on the investigated nodes.  Without such mechanisms, it is
   not advisable to transfer important data by the CSI mechanism.

H. Kitamura                                                   [Page 37]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

Appendix A. CSI Header Structure and Macros

   The following structure and macros are useful for implementing the
   CSI mechanism. Operations for bit aligned fields are done via the
   macros.

    #define IP6_CSI_OPT_TYPE        0x22   /* tentative */
    #define IP6_CSI_OPT_MINLEN      10
    #define IP6_CSI_OPT_LEN(unit,n) (IP6_CSI_OPT_MINLEN + (unit) * (n))
    #define IP6_CSI_OPT_MULTX       4    /* alignment is 4n+2 */
    #define IP6_CSI_OPT_OFFSETY     2

    struct ip6_csi_opt {
      uint8_t   ip6_csi_opt_pad[IP6_CSI_OPT_OFFSETY];
      uint8_t   ip6_csi_opt_type;   /* option type */
      uint8_t   ip6_csi_opt_len;    /* option length */
      uint8_t   ip6_csi_opt_mocl;   /* operation mode bit (MSB) and
                                       investigation class */
      uint8_t   ip6_csi_opt_itype;  /* investigation type */
      uint8_t   ip6_csi_opt_flags;  /* optional flags.  currently
                                       only one flag is defined */
      uint8_t   ip6_csi_opt_hlb;    /* hop limit base */
      uint16_t  ip6_csi_opt_id;     /* identifier */
     /* following fields are modified by nodes en route to the dest. */
      uint8_t   ip6_csi_opt_nrecs;  /* record counter */
      uint8_t   ip6_csi_opt_nreps;  /* Status Report counter */
     /* uint32_t  ip6_csi_opt_recbuf[N];  record buffer follows.. */
    };

    /* Operation Mode */
    #define IP6_CSI_OPT_MODE_BIT  0x80
    #define IP6_CSI_OPT_MODE_SR   0    /* single reply mode */
    #define IP6_CSI_OPT_MODE_MR   0x80 /* multiple reply mode */

    /* Flags */
    #define IP6_CSI_OPT_FLAG_RA   1  /* report address direction flag */

    #define IP6_CSI_OPT_MODE(p)   ((p)->csi_mocl & CSI_MODE_BIT)
    #define IP6_CSI_OPT_CLASS(p)  ((p)->csi_mocl & ~CSI_MODE_BIT)
    #define IP6_CSI_OPT_RAFLAG(p) ((p)->csi_flags & CSI_FLAG_RA)

    /* Investigation Classes */
    #define IP6_CSI_OPT_CLASS_IF_IN     1 /* probe for incoming I/F */
    #define IP6_CSI_OPT_CLASS_IF_OUT    2 /* probe for outgoing I/F */
    #define IP6_CSI_OPT_CLASS_IF_INOUT  3 /* probe for both I/Fs */

H. Kitamura                                                   [Page 38]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

    /* Investigation types for IF classes (IF_IN/IF_OUT/IF_INOUT) */
    #define IP6_CSI_OPT_IF_TYPE_ADDRESS 0 /* address only */
    #define IP6_CSI_OPT_IF_TYPE_STATIC  1 /* static information */
    #define IP6_CSI_OPT_IF_TYPE_DYNCOMP 2 /* dynamic information
                                             with address compression */
    #define IP6_CSI_OPT_IF_TYPE_DYNAMIC 3 /* dynamic information */
    #define IP6_CSI_OPT_IF_TYPE_ALL     4 /* static, dynamic and more */

Appendix B. Utility Application for the CSI mechanism.

   "Tracestatus" is a utility application that is designed to utilize
   the basic CSI mechanism. The relationship between "tracestatus" and
   Status Request/Reply is similar to that between "ping" and Echo
   Request/Reply.

SYNOPSIS

     tracestatus [options..] target

DESCRIPTION

     Tracestatus utilizes the CSI mechanism, which is composed of one
     IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6 messages
     (Status Request/Reply, and Status Report),  to collect status
     information of nodes along the communication path.

     When invoked, tracestatus sends a Status Request message in which
     the CSI option is set to the target, receives a Status Reply mes-
     sage, may receive several Status Report messages, and displays the
     information collected.

     The target argument specifies the destination node.
     Source routing path can be specified using the following form:

          @intermediate-node-1@intermediate-node-2@..@target

OPTIONS

     The following option specifies the CSI operation mode.

        -stepwise Specifies an SPMR (single-probe/multiple-reply) mode.
                  The default is an SPSR (single-probe/single-reply)
                  mode.

H. Kitamura                                                   [Page 39]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

     The following three options specify the CSI investigation class.

        -I        Specifies class 1, which orders to collect status
                  information of incoming interfaces.

        -O        Specifies class 2, which orders to collect status
                  information of incoming interfaces.

        -IO       Specifies class 3, which orders to collect status
                  information of both incoming and outgoing interfaces.

     The following five options specify the CSI investigation type.

        -address  Specifies type 0, which orders to acquire only address
                  information.

        -static   Specifies type 1, which orders to acquire static
                  information.

        -compress Specifies type 2, which orders to acquire dynamic
                  information with address compression

        -dynamic  Specifies type 3, which orders to acquire dynamic
                  information (with full IP address).

        -all      Specifies type 4, which orders to acquire all of the
                  elementary data components.

     There are other options to specify CSI option parameters or to
     change the behavior of the tracestatus command.

        -hop N    Specifies the hop limit for a round trip path.

        -maxrec N Specifies the size of the data space of CSI option.
                  Tracestatus pre-allocates a data space so that it can
                  hold up to N records.

        -repeat   Specifies repeat probing mode, in which tracestatus
                  repeatedly probes and shows the result at certain
                  intervals.  The default is one shot probing mode.

        -fixroute Specifies fixing the route. The initial probe records
                  addresses on a route, and the repeated probes follow
                  the route by using the source routing.

        -interval N
                  Specifies the interval of each repetition in seconds.

H. Kitamura                                                   [Page 40]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

References

     [IPv6]    S. Deering, R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification," RFC2460, December 1998.

     [ICMPv6]  A. Conta, S. Deering, "Internet Control Message Protocol
               (ICMPv6) for the Internet Protocol Version 6 (IPv6)
               Specification," RFC2463, December 1998.

     [ND]      T. Narten, et al., "Neighbor Discovery for IP Version 6
               (IPv6)," RFC2461, December 1998.

     [Clock]   J. Postel, "Internet Control Message Protocol,"
               RFC792, September 1981.

     [MIB-II]  K. McCloghrie, et al., "Management Information Base for
               Network Management of TCP/IP-based internets: MIB-II,"
               RFC1213, March 1991.

     [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels," RFC2119

     [RFC2711] C. Partridge, A. Jackson, "IPv6 Router Alert Option,"
               RFC2711, October 1999

H. Kitamura                                                   [Page 41]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

Changes from the last I-D

      * The CSI header format is changed and simplified.
        - Investigation Type field is divided into three fields
            (M, Invest. Class and Invest. Type).

        - Invest. Class and Invest. Type fields are introduced
            to specify the investigation data type hierarchically
            and to make it easy to introduce new data types.

        - M(Operation Mode) flag is introduced to support two operation
            modes (SPSR and SPMR).
            M flag controls the operation mode of the CSI mechanism.

            Usually, the CSI mechanism runs in an SPSR (Single-Probe/
            Single-Reply) mode.
            When it is necessary to find a problem in the network, it
            runs in an SPMR (Single-Probe/Multiple-Reply) mode.
        - Record Unit field is deleted and changed into Reserved field.
            Since Record Unit can be calculated by the Invest. Class
            and Invest. Type, no Record Unit field is necessary.

        - Node Count field is changed into Report Count field
            The role of the field is clarified and the field is refined.

        - Page and Bitmap fields are deleted.
            By changing the Data Record format in Data Space,
            similar function is provided by a simpler method.

        - Alignment requirement is changed from 8n+2 to 4n+2

      * Data Record format in Data Space is changed
        - Mandatory component of each Record is introduced.

        - Timestamp format is changed and becomes mandatory component.
            Its dynamic range is changed to one hour,
            and its field is shortened to 22 bits.

         - The saved 10 bits are filled with Hop Count (8 bits) and
           I/F (interface) field (2 bits).

      * Dealing unit of Data Record is changed.
            One Data Record is composed of one interface's data.
            When both the Incoming and Outgoing interfaces are
            investigated, two Data Records are consumed in the
            Data Space area on one node.

      * Concept for Investigation Type is refined.

H. Kitamura                                                   [Page 42]


INTERNET-DRAFT Connection/Link Status Investigation (CSI)   October 1999

        - Ideas of "Elementary Investigation Data Components" and
            "Combined Components Group" are introduced.

        - Components are categorized and investigation scenarios
          are clarified.

        - Investigation scenario become bases of the definition of
          Investigation Class and Type.

        - Investigation Type is used to specify the combined components
          group number.

       * More information relative to IANA Considerations and Security
         Considerations is added.

Author's Address

     Hiroshi Kitamura
     NEC Corporation
     C&C Media Research Laboratories
     1-1, Miyazaki, 4-Chome, Miyamae-ku,
     Kawasaki, Kanagawa, 216-8555, JAPAN

     Phone: +81 (44) 856-2123
     Fax:   +81 (44) 856-2230
     EMail: kitamura@ccm.cl.nec.co.jp

H. Kitamura                                                   [Page 43]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/