INTERNET-DRAFT H. Kitamura Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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 that collects status information of nodes along the both outgoing and incoming paths, which 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 "ping" mechanism and efficient, because the status information of the nodes is ideally collected with one pair of request and 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 to collect data of the nodes, there is potential to apply it to other advanced usages easily. The document also clarifies requirements for the mechanism. H. Kitamura [Page 1] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 1. Introduction In order to diagnose networks or find out bottlenecks of communication paths efficiently, a node-by-node based status investigation mechanism is needed. The current IPv6 [IPv6] and ICMPv6 [ICMPv6] specifications do not have enough capability to 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, which is 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 outgoing path from the source to the destination. The other is incoming path from the destination to the source. These paths 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. It may cause traffic congestion, and the brought information 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 In order to provide a node-by-node based efficient investigation mechanism, the following requirements are imposed. 1. Cause minimum traffic The number of probe and reply packets must be minimized to avoid the traffic congestion. The "traceroute" type approach (multiple probes and multiple replies) is not recommendable. H. Kitamura [Page 2] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 2. Avoid unstable path problem The paths of the probe packets to the same node are not always the same because of the dynamic routing mechanism. If the paths of them are different, it is difficult to provide reliable information. Thus it is necessary to avoid the unstable 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 the information of only outgoing path. However, dominant general users need the information of the incoming path. Thus it is necessary to investigate both outgoing and incoming paths. 4. Be simple enough It must be as simple as "ping" or "traceroute" mechanism. Heavy management and authentication mechanisms like SNMP are not necessary. 5. Support CSI feature disabled nodes case There will be nodes that do not implement the CSI feature. Also, there must be some nodes that disable the CSI feature on purpose. The CSI mechanism must be designed not to cause problems when the CSI messages pass through them. 6. Support CSI messages lost case The CSI messages may be lost, because they are based on ICMPv6 message. The CSI mechanism must be designed not to cause problems when the CSI messages are lost. 7. Be scalable and easily expandable In order to make the CSI mechanism a generic framework to collect data of the nodes, 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) February 1999 3. Design of the basic CSI mechanism At 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 that is set the CSI option investigates and collects status information when it pass through the nodes along the path. This mechanism contributes to minimize the traffic and to avoid the unstable 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. 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. Both the Status Request and the Status Reply messages must be set the IPv6 CSI Hop-by-Hop option. These ICMPv6 messages have two roles. One is to trigger to start collecting status information of each node along the path. The other is to carry the collected data by the CSI option. Since the number of carried data by these messages is limited, it is impossible to carry all collected data only with one pair of messages if the number of nodes along the path is larger than the data carrying capacity of them. 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 conditions [see section 5]. In case that 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 only with one pair of the Status Request and Reply messages. H. Kitamura [Page 4] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 It is theoretically possible to adopt multicast or anycast address to the destination, but this document dose not consider such cases here in order to simplify the discussion. This document considers only the case that unicast address is adopted to the destination. 4. Procedure of the basic CSI mechanism The followings show the procedure of the basic CSI mechanism. 1. The source node prepare the Status Request message that 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 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 back the Status Reply message to the destination node. At this time, all of the CSI option fields is copied from the Status Request message to the Status Reply message, and Return address flag field is turned over. Also, Hop Limit field of 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 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 carry capacity (Max Record Count) of these messages, the Status Report messages are transmitted to the source node from the investigated nodes that satisfy conditions [see section 5]. H. Kitamura [Page 5] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 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 (Max 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 zero, it is not necessary to issue the message because Bitmap field dose not provide any effective information. 3. Hop Limit is expired (Time Exceeded) If Hop Limit is expired, the message is discarded and the collected data is lost there. 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 is expired) { flush and issue the Status Report message; reset Data Body and Data Count fields; } Data collection and record operations; } This algorithm shows that the check operation is done only at first part of the routine. It seems that the algorithm causes more than one hop delay of issuing the Status Report message. However, this algorithm is correct, because the role of the Status Report message is to carry the OVERFLOWED data. H. Kitamura [Page 6] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 6. Feature disabled nodes or message lost case When the Status Request/Reply messages pass through the CSI feature not-implemented or disabled nodes, problems are never caused, because Option Type of the CSI option is started from 00 and messages are merely skipped [see section 4.2 of RFC2460]. In case of the CSI messages is lost, problems are also never caused. For the source node, losing the Status Report message is almost same to 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 Body + | | 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 Depend on Record Unit (Investigation Type) Maximum Data Record Count is calculated by the following formula. (Max Record Count)={(Opt Data Len)-12}/(Record Unit) H. Kitamura [Page 7] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 Version: 4-bit. =1 Connection/Link Status Investigation version number. 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-octets. One investigated node records and occupies one data Record Unit length in Data Body 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 from other messages. Record Count: 8-bit unsigned integer. Counter that shows number how many data records were recorded in Data Body field. Incremented by 1 by a node that records data. After the Status Report ICMP message is issued, Record Count and Data Body is reset Next data recording position in Data Body 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 number how many nodes recorded the status data with this message. H. Kitamura [Page 8] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 Incremented by 1 by a node that records data. The value is never reset. This value is used to check packet loss of the Status Report ICMP messages. 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 positions of data recorded nodes along the path. 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 the 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 Body: (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 a number of nodes on the turn around path. H. Kitamura [Page 9] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 Destination Address Any legal IPv6 address. 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) H. Kitamura [Page 10] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 Code Shows (Hop Count) that is calculated by the following formula. (Hop Limit Base) - (Hop Limit) This type of the Code field usage is extraordinary. Since the Status Request/Reply are very similar to the Echo Request/Reply, there are possibility to enhance the Echo Request/Reply in future. So, it is designed to keep the same format of Echo Reply (Hop Count) = 0 means the source node. Since the source node does not issues the Status Reply message, the Code field never become 0 (value of Echo Reply). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Time Stamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Investigation Type | Record Unit |R| Hop Limit Base| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Record Count | Node Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Page | Bitmap (for Node Position Record) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Data Body + | | IPv6 Fields: Destination Address In case that the invoking message's R flag is 0 (Case of the Status Request message invoked), H. Kitamura [Page 11] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 the "Source" address of 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 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 the Code field usage is extraordinary. Time Stamp Filled with the "struct timeval" of the node. This information is low precision data, because time information of network nodes is not always synchronized and network transfer fluctuation exist. The 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 tentatively assigned as follows. +-+-+-+-+-+-+-+-+-+-+-+-+ | | | |C|O|I| +-+-+-+-+-+-+-+-+-+-+-+-+ I: =1 Record Incoming Interface Address O: =1 Record Outgoing Interface Address C: =1 Record both In and Out octet Counts of the interface (Record both ifInOctets and ifOutOctets [MIB-II]) H. Kitamura [Page 12] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 11.1 Record Incoming Interface Address Investigation Type = 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Incoming Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Unit: 16-octet Maximum Record Count: 15 This operation can work as a "Record Route" operation. 11.2 Record Incoming/Outgoing Interface Addresses Investigation Type = 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Incoming Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outgoing Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Unit: 32-octet Maximum Record Count: 7 H. Kitamura [Page 13] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 11.3 Incoming Interface Address and Octet Counts Investigation Type = 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Incoming Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifOutOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Unit: 24-octet Maximum Record Count: 10 11.4 Outgoing Interface Address and Octet Counts Investigation Type = 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outgoing Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifOutOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Unit: 24-octet Maximum Record Count: 10 H. Kitamura [Page 14] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 11.5 Incoming/Outgoing Interface Addresses and Octet Counts Investigation Type = 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Incoming Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifOutOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outgoing Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifOutOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Unit: 24-octet Maximum Record Count: 5 H. Kitamura [Page 15] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 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 16] INTERNET-DRAFT Connection/Link Status Investigation (CSI) February 1999 Appendix B. Utility Application for the CSI mechanism. "tracestatus" is an utility application that is designed to utilize the basic CSI mechanism. The relationship between "tracestatus" and Status Request/Reply is similar to the relationship 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 turn around 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 or smaller than this value. 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. [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 17]