One document matched: draft-ietf-ipngwg-hbh-ext-csi-01.txt
Differences from draft-ietf-ipngwg-hbh-ext-csi-00.txt
INTERNET-DRAFT H. Kitamura
<draft-ietf-ipngwg-hbh-ext-csi-01.txt> NEC Corporation
Expires in six months 19 April 1999
Connection/Link Status Investigation (CSI) for IPv6
IPv6 Hop-by-Hop option and ICMPv6 messages Extension
<draft-ietf-ipngwg-hbh-ext-csi-01.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 whereby status information is
collected for nodes along both the outgoing and incoming paths. This
mechanism is called "Connection/Link Status Investigation (CSI)."
In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option
and three new ICMPv6 messages are proposed as extensions.
The CSI mechanism is as simple as the "ping" mechanism and is also
efficient, because ideally the status information of the nodes is
collected with a pair of "request/reply" ICMPv6 messages. By using
the CSI mechanism, more efficient and reliable "traceroute" type
functions can be realized.
Since the mechanism provides a generic framework for node data
collection. It has good potential for application to other advanced
usages easily. This document also clarifies requirements for the
mechanism.
H. Kitamura [Page 1]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
1. Introduction
The need exists for a node-by-node based status investigation
mechanism as a means of diagnosing networks and efficiently locating
bottlenecks in communication paths.
The current IPv6 [IPv6] and ICMPv6 [ICMPv6] specifications, however,
do not sufficiently support node-by-node status investigation
mechanisms, and do not have features that are designed to do so
except the End-to-End ICMPv6 Echo Request/Reply messages mechanism.
This document proposes a new type of simple mechanism, called "CSI
(Connection/Link Status Investigation)" to provide a node-by-node
based efficient investigation mechanism.
One new IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6
messages (Status Request, Status Reply, and Status Report) are
proposed to realize the CSI mechanism.
There are two types of paths between a source (initiator) node and a
destination node. One is the outgoing path from the source to the
destination. The other is the incoming path from the destination to
the source. The nodes in the paths and the order is which data
packets pass through them are not always the same. Most current
investigation mechanisms (e.g., "traceroute," etc.) can only obtain
the status information of the outgoing path.
In order to solve the problem, the CSI mechanism is designed to
collect status information of all nodes along both incoming and
outgoing paths by a simple procedure.
The current investigation mechanism (e.g., "traceroute") issues many
probe and reply packets. This may cause traffic congestion, and the
information obtained may not be reliable because the transferred
paths of the packets are not always the same.
The CSI mechanism is designed to improve these points, it can provide
more reliable information with less traffic.
2. Requirements
An efficient node-by-node based investigation mechanism has the
following requirements:
1. Cause minimum traffic
The number of probe and reply packets must be minimized to avoid
traffic congestion. Thus the "traceroute" type approach (multiple
H. Kitamura [Page 2]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
probes and multiple replies) is not recommended.
2. Avoid the varying path problem
The paths of the probe packets to the same node are not always the
same because of the dynamic routing mechanism. The varying of path
makes it difficult to provide reliable information on all paths.
Thus it is necessary to avoid the varying path problem to obtain
reliable information.
3. Investigate both outgoing and incoming paths
The outgoing and incoming paths are not always the same. The
"traceroute" type approach can collect information only on
outgoing path. However, the overwhelming majority of users need
information on the incoming path.
Thus it is necessary to investigate both outgoing and incoming
paths.
4. Be simple enough
It must be as simple as the "ping" or "traceroute" mechanism, with
no need for cumbersome management and authentication mechanisms
like SNMP.
5. Support passing 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.
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 problems occur when
the CSI messages are lost.
7. Be scalable and easily expandable
In order to make the CSI mechanism a generic framework for node
data collection, the mechanism must be scalable and easily
expandable. The header field of CSI messages must be assigned
without making special constraints.
H. Kitamura [Page 3]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
3. Design of the basic CSI mechanism
First, one new IPv6 Hop-by-Hop option, called CSI option, is
introduced to investigate and collect status information of nodes.
Option Type of the CSI option must be started from 00 to avoid
discarding the packet at the CSI feature disabled node, 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 collects
status information when it passes through the nodes along the path.
This mechanism contributes to minimize the traffic and to avoid the
varying path problem.
Second, a round trip probing message 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].
This pair of messages makes a round trip loop 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 CSI Hop-by-Hop option must be set in both the Status Request
and the Status Reply messages.
These ICMPv6 messages have two roles. One is to trigger the start of
status information collection of each node along the path. The other
is to carry the collected data by the CSI option.
Since the data carrying capacity (as measured by the number of
records) of the pair of messages is limited, it is impossible for
them to carry all the collected data if the number of nodes along the
path is larger than their data carrying capacity.
In order to solve this problem, another new ICMPv6 message (Status
Report) is introduced. The roles of the Status Report message is to
carry the overflowed data to the source node that transmitted the
initial Status Request message from the investigated nodes that
satisfy the conditions given in section 5.
If the number of nodes along the path is smaller than the data
carrying capacity of the probing messages, the source node can
investigate the connection/link status with the pair of Status
Request and Reply messages alone.
H. Kitamura [Page 4]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
It is theoretically possible to adopt all of regal IPv6 address types
to the destination, but this document does not consider multicast
address case here in order to simplify the discussion.
This document considers only the case that 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 is
set the IPv6 Hop-by-Hop CSI option, and transmits it
to the destination.
Since the Status Request message is accompanied by the CSI option,
it investigates and collects the status data of nodes along the
"outgoing" path.
The "source" address of the IPv6 header of the message is adopted
to the return address for the invoked Status Report message.
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.
Since the Status Reply message is accompanied by the CSI option,
it investigates and collects the status data of nodes along the
"incoming" path.
The "destination" address of the IPv6 header of the message is
adopted to the return address of the invoked Status Report
message.
4. The source node receives the Status Reply message from the
destination node.
If the number of nodes that record the status data is larger than the
data carrying capacity (Maximum Record Count) of these messages, the
Status Report messages are transmitted to the source node from the
investigated nodes that satisfy the conditions given in section 5.
H. Kitamura [Page 5]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
5. Status Report message transmission conditions and check algorithm
When the following conditions are satisfied, the collected data is
flushed and the Status Report message is transmitted.
1. Data is full
(Record Count) exceeds (Maximum Record Count)
2. Position record Bitmap is full and Page must be updated
In order to avoid losing the collected Bitmap information, the
Status Report message must be issued.
There is an exception. If all bits of the Bitmap field are filled
with zeroes, it is not necessary to issue the message because the
Bitmap field does not provide any effective information. This will
be explained in more detail in section 7.
3. Hop Limit expires (become to 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
data, the Status Report message must be issued.
The following algorithm shows the check operation procedures.
hbh_CSI_management_routine()
{
if (Data is full || Bitmap is full || Hop Limit expires) {
flush and issue the Status Report message;
reset Data Space and Data Count fields;
}
Data collection and record operations;
}
This algorithm shows that the check operation is done only at the
first part of the routine. It is apparent that there is a delay of at
lease one hop in issuing the Status Report message with this
algorithm The algorithm is specifically designed this way, however,
because the role of the Status Report message is to carry the
OVERFLOW data.
H. Kitamura [Page 6]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
6. Feature-disabled nodes or lost messages
No problems occur when the Status Request/Reply messages pass through
node 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].
Neither do any problems occur if CSI messages are lost. For the
source node, losing a Status Report message is almost the same as
passing through the feature-disabled nodes. The difference is that
the source node can detect the message lost by using Node Count field
information.
7. IPv6 Hop-by-Hop CSI Option Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Investigation Type | Record Unit |R| Hop Limit Base|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Record Count | Node Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Page | Bitmap (for Node Position Record) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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 field of this option
Max: 255
Depends on Record Unit (Investigation Type)
Maximum Data Record Count is calculated by the
following formula.
(Max Record Count)={(Opt Data Len)-12}/(Record Unit)
Version: 4-bit.
=1
Connection/Link Status Investigation version number.
H. Kitamura [Page 7]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
Investigation Type: 12-bit.
Investigation type to acquire status information
data. Currently several types are defined.
[see section 11]
Record Unit: 7-bit unsigned integer.
Unit length of each information data in 2-octet.
One investigated node records and occupies one data
Record Unit length in Data Space field
Min: 8 (16 octets = length of IPv6 address)
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 (decremented).
Node location number (Hop Number) can be calculated
with the following formula.
(Hop Number) = (Hop Limit Base) - (Hop Limit)
In case of the source node, (Hop Number) is 0.
Identifier: 16-bit.
Identifier to distinguish one messages from another.
Record Count: 8-bit unsigned integer.
Counter that shows how many data records were
recorded in the Data Space field.
Incremented by 1 by each node that records data.
After the Status Report ICMP message is issued,
The Record Count and Data Space fields are reset
Next data recording position in the Data Space field
is calculated by (Record Unit) * (Record Count).
Min: 0
Max: {(Opt Data Len)-12}/(Record Unit)
Node Count: 8-bit unsigned integer.
Counter that shows how many nodes recorded
the status data with this message.
Incremented by 1 by each node that records data.
The value is never reset.
This value is used to check packet loss of the
Status Report ICMP messages.
H. Kitamura [Page 8]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
Min: 0
Max: 255
Page: 4-bit.
Page number of the Bitmap field.
Min: 0
Max: 15 (10 practically)
Bitmap (for Node Position Record): 28-bit
Bitmap is a set of flags and shows the positions
along the path of nodes where data was recorded.
Flag:
=0 only packet forward node (Feature-disabled node)
=1 status data record node (Feature-enabled node)
Flag is set by the following logic.
(Bitmap) |= 2^{(Hop Number) of the data record node}
As a result, the Bitmap shows which nodes on the
path recorded the status data.
The combination of 4-bit Page and 28-bit Bitmap can
show enough bitmap space 448 (=(2^4) * 28).
Data Space: (Opt Data Len)-12 octets
Buffer space to record the status information data.
8. 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]
H. Kitamura [Page 9]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
ICMPv6 Fields:
Type TBA (tentatively 142)
Code 0
Identifier
An identifier to aid in matching Status Replies
and Status Reports to this Status Request.
May be zero.
Sequence Number
A sequence number to aid in matching Status Replies
and Status Reports to this Status Request.
May be zero.
Data
Zero or more octets of arbitrary data.
9. 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 Count) that is calculated by the
following formula. (Hop Limit Base) - (Hop Limit)
H. Kitamura [Page 10]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
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 Count 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.
Value of Code field never conflicts between Echo and
Status Reply messages. In case of Echo Reply message,
Code field is always filled with 0.
In case of Status Reply message, Code field never
becomes to 0, because Code (Hop Count) = 0 means the
source node and the source node never issues the
Status Reply message.
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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Investigation Type | Record Unit |R| Hop Limit Base|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Record Count | Node Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Page | Bitmap (for Node Position Record) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Space +
| |
H. Kitamura [Page 11]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
IPv6 Fields:
Destination Address
In case that the invoking message's R flag is 0
(Case of the Status Request message invoked),
the "Source" address of the IPv6 header of the
invoking message is copied.
In case that the invoking message's R flag is 1
(Case of the Status Reply message invoked),
the "Destination" address of the IPv6 header of
the invoking message is copied.
ICMPv6 Fields:
Type TBA (tentatively 144)
Code Shows (Hop Count) 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.
11. Predefined Investigation Types
In this section, several examples of Investigation Type are
described.
Bit field flags of the Investigation Type are assigned as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+
| | |m|s|o|i|t|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+
11.1 Major (Interface) Bits
"I" and "O" bits are used to specify interface(s) that is/are
investigated, and their meanings are different from the other bits
(lower letter bits).
H. Kitamura [Page 12]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
I: Incoming Interface
O: Outgoing Interface
When "I" and/or "O" bit is/are set , IP address information of
interface(s) is recorded. At least, either "I" or "O" bit must be
set.
|O|I| = |0|0| case: This never happens.
|O|I| = |0|1| case: Only Incoming interface is investigated
|O|I| = |1|0| case: Only Outgoing interface is investigated
|O|I| = |1|1| case: Both Incoming and Outgoing interfaces
are investigated
11.2 Subordinate Bits
"t", "i", "o", "s", and "m" bits are subordinates of "I" and "O"
bits. These bits are used to specify additional information that is
recorded with IP address information.
These bits are commonly used by "I" and "O" bits to specify which
additional information must be recorded with IP address information
of Incoming or/and Outgoing interface(s).
When some of the subordinate bits are set, correspondent additional
information is recorded. It is possible to set none of the
subordinate bits. At that time, only IP address information is
recorded.
Every additional information field occupies 4 octets in the record.
If the number of set bits is odd, it is necessary to add 4-octet
padding at the end of each interface record in order to maintain
8-octet alignment.
t: timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
timestamp format that is generally used in [Clock] and [NTP]
The data collected time at each node is recorded.
It is not strongly requested that the timestamp is accurately
synchronized with UTC, because its information is generally
utilized by comparing with data of the same node that is
recorded by other probes at other timings.
H. Kitamura [Page 13]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
i: ifInOctets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
incoming direction octet counts ([MIB-II] defined)
o: ifOutOctets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
outgoing direction octet counts ([MIB-II] defined)
s: ifSpeed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifSpeed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
physical maximum bandwidth of the interface ([MIB-II] defined)
m: ifMtu
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifMtu |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTU of the interface ([MIB-II] defined)
11.3 Order in the Data Record Format
1. If "I" bit is set, the Incoming IP address is recorded.
2. If "I" bit and some subordinate bits are set,
additional information of the Incoming interface is recorded.
The order of additional information fields is the same as that
of the bit fields("t", "i", "o", "s", and "m").
3. If the number of set subordinate bits is odd, 4-octet padding is
added.
4. If "O" bit is set, the Outgoing IP address is recorded.
5. If "O" bit and some subordinate bits are set, correspondent
additional information of the Outgoing interface is recorded.
The order of additional information fields is the same as that
of the bit fields("t", "i", "o", "s", and "m").
6. If the number of set subordinate bits is odd, 4-octet padding is
added.
H. Kitamura [Page 14]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
In the following subsections, some examples are showed:
11.4 Record Incoming Interface Address
Investigation Type = 1 (0b 0000 0000 0001)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 16-octet
Maximum Record Count: 15
This operation can work as a "Record Route" operation.
11.5 Record Incoming/Outgoing Interface Addresses
Investigation Type = 3 (0b 0000 0000 0011)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outgoing Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 32-octet
Maximum Record Count: 7
H. Kitamura [Page 15]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.6 Record Incoming Interface Address and Timestamp
Investigation Type = 5 (0b 0000 0000 0101)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 24-octet
Maximum Record Count: 10
11.7 Record Incoming Interface Address, Timestamp and Incoming direction
Octet Counts
Investigation Type = 13 (0b 0000 0000 1101)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 24-octet
Maximum Record Count: 10
H. Kitamura [Page 16]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.8 Record Incoming Interface Address, Timestamp and Incoming/Outgoing
direction Octet Counts
Investigation Type = 29 (0b 0000 0001 1101)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 32-octet
Maximum Record Count: 7
11.9 Record Incoming Interface Address, Timestamp, Incoming/Outgoing
direction Octet Counts, and Maximum Bandwidth
Investigation Type = 61 (0b 0000 0011 1101)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifSpeed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 32-octet
Maximum Record Count: 7
H. Kitamura [Page 17]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.10 Record Incoming/Outgoing Interface Addresses and Timestamps
Investigation Type = 7 (0b 0000 0000 0111)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outgoing Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 48-octet
Maximum Record Count: 5
H. Kitamura [Page 18]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.11 Record Incoming/Outgoing Interface Addresses, Timestamps and
Incoming direction Octet Counts
Investigation Type = 15 (0b 0000 0000 1111)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outgoing Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 48-octet
Maximum Record Count: 5
H. Kitamura [Page 19]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.12 Record Incoming/Outgoing Interface Addresses, Timestamps and
Incoming/Outgoing direction Octet Counts
Investigation Type = 31 (0b 0000 0001 1111)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outgoing Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 64-octet
Maximum Record Count: 3
H. Kitamura [Page 20]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
11.13 Record Incoming/Outgoing Interface Addresses, Timestamps
Incoming/Outgoing direction Octet Counts and Maximum Bandwidth
Investigation Type = 63 (0b 0000 0011 1111)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Incoming Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifSpeed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outgoing Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifSpeed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Record Unit: 64-octet
Maximum Record Count: 3
H. Kitamura [Page 21]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
Appendix A. CSI Header Structure and Macros
The following structure and macros is useful to implement the CSI
mechanism. Operations for bit aligned fields are done via the macros.
#define IP6_CSI_OPT_TYPE 0x22
#define IP6_CSI_OPT_MINLEN 12
#define IP6_CSI_OPT_LEN(unit,n) (IP6_CSI_OPT_MINLEN + (unit) * (n))
#define IP6_CSI_OPT_MULTX 8 /* alignment is 8n+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 */
uint16_t ip6_csi_opt_vt; /* version and investigation type */
uint8_t ip6_csi_opt_ur; /* record unit size and
return address direction flag */
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_nr; /* number of records */
uint8_t ip6_csi_opt_nc; /* node counter */
uint32_t ip6_csi_opt_bm; /* node bitmap and page number */
/* uint64_t ip6_csi_opt_recbuf[N]; record buffer follows.. */
};
#define IP6_CSI_OPT_BMWIDTH 28
#define IP6_CSI_OPT_BMMASK 0xfffffff
#define IP6_CSI_OPT_VERSION(p) (ntohs((p)->vt) >> 12)
#define IP6_CSI_OPT_INVTYPE(p) (ntohs((p)->vt) & 0xfff)
#define IP6_CSI_OPT_DATAUNIT(p) ((p)->ur & ~1)
#define IP6_CSI_OPT_RFLAG(p) ((p)->ur & 1)
#define IP6_CSI_OPT_BMPAGE(p) (ntohl((p)->bm)>>IP6_CSI_OPT_BMWIDTH)
#define IP6_CSI_OPT_BITMAP(p) (ntohl((p)->bm) & IP6_CSI_OPT_BMMASK)
H. Kitamura [Page 22]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 1999
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.
Users can specify the following items at least as command line
arguments of "tracestatus".
1. Destination Node
2. Investigation Type
3. Initial value of Hop Limit for Status Request message
Hop Limit for the round trip path (not one way) must be
specified.
4. Maximum Record Count
Since there is limitation of the Hop-by-Hop option length,
the real Maximum Record Count is equal to or smaller than
this value.
5. Number of repeat probings
6. Interval time of repeat probings
H. Kitamura [Page 23]
INTERNET-DRAFT Connection/Link Status Investigation (CSI) April 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.
[NTP] David L. Mills, "Network Time Protocol (Version 3)
Specification," RFC1305, March 1992
[MIB-II] K. McCloghrie, et al., "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II,"
RFC1213, March 1991.
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 24]
| PAFTECH AB 2003-2026 | 2026-04-23 06:20:26 |