One document matched: draft-ietf-ipngwg-hbh-ext-csi-02.txt
Differences from draft-ietf-ipngwg-hbh-ext-csi-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:20:26 |