INTERNET-DRAFT H. Kitamura 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 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]