Echo Packet Design

As discussed in section 4.2, an echo packet must follow the same processing path as any other packet for it to be a representative measurement of packet dynamics. In addition, it must not present a denial of service vector. For these reasons, processing

3

Type Faux IP Proto Reserved

Checksum

Figure 4.4: Format of an IPMP echo packet

(0x01)

Figure 4.5: Format of the IPMP type field

efficiency is a primary design criterion for the IPMP echo protocol. The design of the IPMP echo packet has a number of purposes. First, it provides an efficient mechanism for an IPMP-capable destination host or router to determine if it should insert a path record in an echo packet. Second, it provides an efficient mechanism for an IPMP-capable host or router to modify the echo packet. Third, it provides an efficient mechanism for an intermediate system to determine how the packet should be queued, should the system queue packets other than on a FIFO basis. Finally, it provides an efficient mechanism for a measurement process executing on a source host to identify individual echo responses as they arrive and match them to echo request probes it sent.

The format of the IPMP echo packet is shown in figure 4.4. An IPMP echo packet has three components; an echo header, pre-allocated space for path records, and an echo trailer. The components are arranged in the order they are required for decision making when an echo packet is processed in the forwarding path of a router. For example, the trailer contains fields which are modified last, after pro-cessing decisions have been made. The fields in each component are arranged so that an IPMP echo packet is as simple to process as possible.

The echo header signals to IPMP capable nodes how to process the packet. The version field identifies the version of the IPMP protocol being used, to allow for non-backwards compatible extensions to be added in the future if required. The type field, shown in figure 4.5, identifies if the IPMP packet is an echo probe, if the packet is a request or response, and if the echo probe is a one-way singleton probe.

The identifier and sequence number fields allow a source host to match re-sponses with a corresponding request record. If an IPMP packet causes an ICMP message to be sent, the source host can use these fields to match the message with a corresponding request record. The identifier and sequence number fields are placed in the first 8 bytes of the echo packet so that if an ICMP stack is not configured to send more of an original packet than the historical recommendation of the IP header plus the first eight bytes of payload, it will still be able to identify the packet that caused the ICMP message to be returned. The identifier is also used by interme-diate systems – such as firewalls and routers – to determine which flow the packet belongs to.

The faux protocol type, faux source port, and faux destination port fields allow an IPMP echo probe to be queued or filtered as another packet type would if a router or intermediate system queues or rate limits packets based on their type.

For example, if measurement of TCP traffic is of interest, then the faux protocol field would be set to 6, which is the protocol type of TCP. Similarly, if Hypertext Transfer Protocol (HTTP) traffic is of specific interest, then the sender would set the faux destination port field to 80, which is the most common HTTP port used.

The echo trailer is found in the last four bytes of an echo packet. An echo trailer contains a path record pointer and an IPMP checksum, which are updated when the packet is modified to include an additional path record, or when the echo header is modified at the destination host. These fields are located at the end of the packet so that nodes which process IPMP packets as a bit-stream do not have to buffer the whole packet when inserting a path record; this is discussed in further detail in section 4.4.6.2. The value of the path record pointer field identifies the offset relative to the first byte of the echo header (the version field) at which the next IPMP path record should be inserted, and is used by nodes which process IPMP

TTL

IPv4 Address of the Receiving Interface S Res.

Figure 4.6: Format of the IPMP path record when encapsulated in IPv4 packets in a store-and-forward manner. The checksum is a standard RFC 1009 [66]

Internet checksum, and is computed over the echo packet from the IPMP version field to the IPMP checksum field.

Between the echo header and echo trailer is pre-allocated space reserved by the source host for path records. The motivation for using pre-allocated path record space instead of allowing an IPMP echo packet to grow dynamically is two-fold.

First, extending the packet requires extra processing; the IP header requires mod-ification to the length and checksum fields, and the packet buffer which holds the probe requires extra memory resources to be dynamically assigned. Second, ex-tending the packet dynamically limits the ability to measure the behaviour of an Internet path with a specific packet size. The space reserved for path records is also initialised in such a way as to reduce the processing burden of intermediate nodes which process IPMP in the forwarding path, and to allow a source to restrict which routers on a path may insert a path record. These details are discussed further in the next section.