Path Record Design

The path record is the structure in the IPMP echo protocol that enables per-hop mea-surement of Internet packet dynamics to take place. An IPMP path record contains information useful for directly measuring packet dynamics. Like the echo protocol, the path record is designed to be compact and efficient to process. The format of the IPv4 IPMP path record is shown in figure 4.6.

The reason that the path record structure is designed to be compact is to allow as many path records to be included in an echo packet as possible; an IPv4 path record requires 12 bytes, while an IPv6 path record requires 24 bytes. In order to keep the

space requirements of a path record to a minimum, a path record does not include information about the path that does not change between probes. A mechanism to retrieve static information is provided with the IPMP information protocol.

The space between the echo packet’s header and trailer is reserved for path records. As with the IPMP echo packet design, the path record structure is de-signed with processing efficiency as a primary design criterion. Most of the space reserved for path records is initialised to zero so that incrementally updating the IPMP checksum [67] is as simple as possible. The exception to this is the first byte of each path record – the TTL field – which is used by the source to restrict which hops may insert a path record. An intermediate node determines if it should insert a path record by comparing the TTL field in the IP header – after the TTL has been decremented as part of the forwarding process – with the TTL field of the next un-used path record. If the TTL field in the next unun-used path record is greater than or equal to the TTL field in the IP header, then the intermediate node may use that path record space, provided the ‘S’ bit, discussed next, is not set.

When a path record is inserted, the IPMP TTL field in the path record inserted is a copy of the TTL field from the IP header, after the IP TTL has been decremented as part of the forwarding process. Including a TTL field in a path record allows a host to determine the distance, in hops, into an Internet path where the path record was inserted. The set (S) field is a bit which is set when space reserved for a path record is used. This field is useful for systems which process an echo packet as a bit-stream because it allows an intermediate system to determine the next suitable location for a path record to be inserted without waiting for the path record pointer field which comes at the end of the packet. Processing an echo packet as a bit-stream is discussed further in section 4.4.6.2.

The flow counter (FlowC) field records the arrival order of a series of IPMP echo packets which belong to the same flow. An IPMP flow is defined as a series of echo packets with the same source and destination IP addresses, IP protocol type, and IPMP echo ID. Including a flow counter in an IPMP path record was first pro-posed by Mahajan, Spring, Wetherall, and Anderson in “User-Level Internet Path Diagnosis” [1]. A flow counter provides the ability to determine the arrival order of

3 HLIM

0 1 2 3 4 5 6 7 0

8 9 0 1

1 2 3 4 5 6 7 8 9 0 2

1 2 3 4 5 6 7 8 9 0 1 S Res. FlowC

Timestamp

IPv6 Address of the Receiving Interface

Figure 4.7: Format of the IPMP path record when encapsulated in IPv6 a series of packets and to infer where a previous packet was lost in appropriate con-ditions. The algorithms for doing so are discussed in section 6.4. The flow counter field is 4 bits wide, which enables 16 sequence numbers to be recorded before the counter wraps. A flow record relates an IPMP flow to a flow counter. Flow records are interface scoped; that is, each flow record records the arrival order of an echo flow at a particular interface. IPMP echo probes that belong to the same flow but arrive at different interfaces therefore have different flow records. Flow counters are an optional part of IPMP, as generating and recording a flow counter requires significant processing and state to be kept compared with other parts of the echo protocol.

The three bits between the S field and the FlowC field are currently reserved;

they are set to zero by the sender. A possible use for one of these bits is to include an Explicit Congestion Notification (ECN) Congestion Experienced (CE) bit in the path record, which could be used for determining the congestion status of routers in an end-to-end path.

The timestamp field is a 48 bit field that represents the time the packet was received at the interface. In order to ensure that IPMP is as simple as possible to process in the forwarding path, the timestamp field has no defined format, other than the size and location. Translating the timestamp to real time is handled in a separate packet exchange with the information protocol, discussed in section 4.5.

Finally, the IP address field is an IP address of the interface which received the echo probe; the method to choose an appropriate address if the interface has more than one address to choose from is discussed in section 4.4.3.

IPv4 IPv6 IP header size 20 bytes 40 bytes IPMP echo header 12 bytes 12 bytes IPMP echo trailer 4 bytes 4 bytes Path record size 12 bytes 24 bytes Minimum IP MTU 576 bytes 1280 bytes

Path record count 45 51

Ethernet IP MTU 1500 bytes 1500 bytes

Path record count 122 60

Table 4.1: Number of path records able to be included for various IP packet sizes The format of the IPv6 IPMP path record is shown in figure 4.7. The format of the IPv6 path record is very similar to the IPv4 path record. An IPv6 path record varies from the IPv4 path record in two ways. First, it has a 128-bit IPv6 address instead of a 32-bit IPv4 address. Second, it has a Hop Limit (HLIM) field instead of a TTL field, as the IPv6 header has a HLIM field instead of a TTL field. Table 4.1 shows how many path records may be included in an echo probe, depending on the size of the echo probe and whether IPv4 or IPv6 is used.