Fast Path Characterization Protocol (FPCP)
Version of Tuesday, September 19, 2000 22:49 -0700

Todo

This section is here to record things that need to be addressed.  It is not really part of this document.

Abstract

FPCP (Fast Path Characterization Protocol) is a fast and inexpensive way to obtain information about a path through the Internet.  FPCP is intended to be used by content management systems in order to evaluate content placement options.  FPCP also serves as an alternative to troubleshooting tools such as "traceroute".

FPCP operates by sending a probe packet along the path to be evaluated.  The FPCP probe contains a description of a hypothetical flow.  The routers along the path examine the hypothetical flow and append appropriate router and link information to the probe packet before forwarding that packet to the next hop router.  When the probe has reached the end of the path, the accumulated information is sent back to the querying application for analysis.

FPCP may be used in both IPv4 and IPv6 networks.

FPCP contains mechanisms to handle various conditions such as forwarding loops, forwarding paths that fork, non-FPCP aware routers, excessive growth of probe packets, etc.

The FPCP packet structure is based on type-length-value structures.  This will ease the burden of extending the capabilities of FPCP in the future.

FPCP does not require real-time processing within the high-speed forwarding paths of routers.  Rather FPCP is designed to be handled at low priority.

Table of Contents

Overview

FPCP is the Fast Path Characterization Protocol.

There is a need on the Internet for people and applications to ascertain whether the network path between a pair of potential communications partners will be adequate.  There is a similar need to evaluate the relative merits of different network paths when selecting among multiple potential communications peers.

In many instances people or applications make rough guesses based on inadequate and possibly misleading data.  Among the most frequently used data are the ICMP Echo (Ping) or DNS query round trip time and the number of hops on what may or may not be the one-way path from one point on the net to another.

TCP's flows, particularly when they are carrying more than a few segment size's worth of of data, are often more sensitive to path bandwidth and packet loss than they are to hop counts and round trip times.  Consequently, when evaluating a path for a data flow of more than trivial size that will be carried using TCP, one is probably more interested in bandwidth and loss than hop count and round trip time.  (Note: For small size transfers, ones in which the transfer time will be dominated by TCP connection and tear-down handshakes rather than by the data transfer itself, round trip time is probably more relevant than bandwidth.  Similarly, transfers that involve a lot of end-to-end interactions tend to be more affected by round-trip-time than by bandwidth.)

The increasing presence of mechanisms such as policy routing, flow-based traffic pacing and traffic shaping, QoS, fair queuing, and asymmetrical routes further tends to diminish the value of simple ping-based or DNS based round trip time estimates - it is unlikely that the ping or DNS query will be given the same QoS or routing treatment as the proposed flow.

Tools such as Pathchar, pchar, and clink can provide better data on which to evaluate a network path.  But those tools are packet intensive and require a long period of time to accumulate the data.  And they are blind to any QoS, policy, or priority handling that may be accorded to certain data streams.

FPCP is designed to fill this information gap.  FPCP is designed to quickly measure the actual path that the user's data will follow.  (Each direction is evaluated using a distinct FPCP operation.)

In the best case, FPCP can obtain information on a path in slightly more than one round trip time.

Router processing of FPCP packets is intended to be lightweight and may occur at relatively low processing priorities.  (In other words FPCP could be handled by low priority software in the routers.)  Most of the burden of FPCP falls on the device that is making the query, and even then the burden is fairly small - probably about the same as would fall on an multicast traceroute (MTRACE) client.

The FPCP probe packet is unicast from each hop to next with the destination address being changed at each step to be the next hop router; the Router Alert IP option is neither necessary for- nor used by- FPCP.

Each FPCP probe packet contains an embedded IP header the describes the hypothetical flow that is being evaluated.  Each router uses that hypothetical header to examine how it would handle an IP packet with that header and appends an FPCP information package to the probe packet.

An optional hypothetical TSPEC [RFC2215] may be sent along with the hypothetical IP header in order to describe the dynamics of the hypothetical traffic flow.

An FPCP query begins when a querying application sends a probe packet to the first router in a path.  That router uses the hypothetical IP header (and optional TSPEC) in the probe packet to examine the routers forwarding tables.  The router determines the next router to which the hypothetical IP packet would be sent and appends an information package to the probe packet.  The revised probe packet is then addressed to, and sent directly to, that next router.

This bucket-brigade procedure continues until the probe packet either reaches the last hop router, the path forks (perhaps due to load balancing), or the probe packet has accumulated so many packages that it has grown too large.  When any of these events occurs, the accumulated probe packet is sent back to the querying application and the FPCP processing by the routers ceases.  If the full path was not evaluated, it is up to the querying application to pick up where the query left off.  For example, if the probe packet became too large and was returned to the querying application, it would be up to the application to start a new FPCP with a new, empty probe starting at the router where the oversize condition occurred.

There are special-case mechanisms to deal with the initial link from a host to its first hop router and when the probe packet vanishes into a router that does not support FPCP.  (These are described later.)

FPCP processing contains tests to detect queries that loop due to single or multiple hop forwarding loops.

For convenience in implementation (and to obtain the protection of a checksum) all FPCP packets are encapsulated in UDP.

The current design of FPCP has the probe packet being forwarded explicitly from each router to the next.  This makes FPCP sensitive to non-participating routers - such routers require an FPCP client to engage in a rather slower "traceroute" technique to walk pas the non-participating router(s).  Consequently, it is possible that a variation of FPCP will be defined in which the probe packet is addressed to the ultimate destination IP address and has the Router Alert Option.

FPCP is not expected to be a burden on routers.  The software processing load to handle an FPCP packet is anticipated to be reasonably low if the software has a reasonably efficient means to inquire how a hypothetical IP packet would be routed were it to arrive on a particular interface.  (In addition, if the hypothetical packet could be forwarded down multiple paths, FPCP needs to be able to ascertain that fact and to enumerate the set of possible immediate next hops.)

For each hop along the path FPCP may obtain several kinds of information.  

When in a network in which FPCP is active on all routers, FPCP serves as an alternative to Path MTU Discovery and traceroute.

When used as a means of comparing the paths between a network client and a set of potential servers, FPCP becomes a useful means for content management systems to ascertain which server have the best effective communications with the client.

Packages and Objects

FPCP two kinds of composite structures - objects and packages.

Of the two, objects are the more basic structure.

Objects are built from basic data elements, usually numbers.

Packages contain zero or more objects.  Packages may contain only certain kinds of objects, however, an implementation that encounters an object that it does not comprehend MUST skip over and ignore that object for purposes of its own processing.  An implementation MUST forward all packages and objects along the FPCP query path even if the implementation does not understand those packages and objects.

Packages do not contain other packages.

Objects may never be used alone - they are always wrapped within a package.

The order of packages within a packet may be significant; implementations MUST preserve package order.

Packages and objects are all composed of an integral number of bytes.   Packages and objects are packed; no padding bytes are used between packages and objects.  Hence some packages and objects may not fall on the "natural" memory boundaries of any particular machine.  Programmers should take care that their software allows for generalized byte alignment of packages, objects, and object contents.

The specific kinds of packages and objects will be described in detail later in this document.

Objects

An object is essentially a named datum.  Depending on the object that datum is a single fundamental type or it may be a composite structure of other basic types.

Objects are identified by a type code.  Object type codes are unique across all types of packages.

An implementation that encounters an object that it does not comprehend MUST skip over and ignore that object for purposes of its own processing.  Objects that are not understood MUST be forwarded, unchanged, as the FPCP packet is processed.

Objects are found only wrapped within a package.

The order of objects within a package may be significant; implementations MUST preserve object order.

Although order of objects must be preserved when packages are are relayed, unless an order is mandated by the specification, an implementation is free to generate the objects in a package in any order.  Note: since it would not be surprising to see FPCP object parsers with order sensitivity, it is suggested that to avoid inducing failures in those admittedly out-of-specification conservative implementations a gracious FPCP implementation may wish to take some care to generate objects in the sequence in which they appear in the object definitions.

All objects begin with a standard header.

Object Header

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  | Object contents...            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type 0x01 .. 0x7F

Values 0x00 and the range 0x80 .. 0xFF, inclusive, are reserved for future use.

The following Object Types are defined by this document.  See the Numbers section of this document for the particular code value assigned to each Object Type.

  • Reporting IP Address IPv4
  • Reporting IP Address IPv6
  • Reply-To IPv4 UDP address
  • Reply-To IPv6 UDP address
  • Start-IP Address IPv4
  • Start-IP Address IPv6
  • Force Next Hop IPv4
  • Force Next Hop IPv6
  • Hypothetical IPv4 header
  • Hypothetical IPv6 header
  • Hypothetical sender TSPEC
  • Link Speed
  • Link Type
  • Link HighSpeed
  • Link Transit Time Estimate
  • Link Loss Estimate
  • Router Latency Estimate
  • Router Drop Probability Estimate
  • WRED Estimate 
  • Next Hop IPv4
  • Next Hop IPv6
  • Possible Path IPv4
  • Possible Path IPv6
Obj Length 1..255

The number of bytes comprising this object, including the object header.

An object, including header, may not be longer than 255 bytes.

Object contents  (Varies by object type.)

Packages

Packages are much like what are called "objects" in RSVP [RFC2205] and COPS [RFC2748] - they are distinct chunks of information that are appended to the FPCP probe packet as it moves through a sequence of routers.  The order of packages is important and routers MUST append any packages after other packages, if any, in the packet.  A router MUST NOT disturb the order or content of any other packages in the packet.

Each package is self-describing - every package contains a tag that identifies the package type (and hence the format of its contents) as well as a length indicator.

An implementation that encounters a package that it does not comprehend MUST skip over and ignore that package, including all the objects that that package might contain.   Packages that are not understood MUST be forwarded, unchanged, as the FPCP packet is processed.

All packages begin with a standard header.

The information in a package may have a limited lifetime.  The package header contains a time-to-live value that establishes the period that the information may be considered valid.

Package Header

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Pkg Type   |    Pkg TTL    |            Pkg Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Package Contents ...                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pkg Type 0x01 .. 0x7F

Values 0x00 and 0x80 .. 0xFF are reserved for future use.

The following Pkg Types are defined by this document.  See the Numbers section of this document for the particular code value assigned to each Pkg Type.
  • Query IPv4
  • Query IPv6
  • Initial Hop Data IPv4
  • Initial Hop Data IPv6
  • Next Hop Data IPv4
  • Next Hop Data IPv6
  • Path Fork Data IPv4
  • Path Fork Data IPv6
Pkg TTL An indication of how long the information in this package should be considered valid.
  • 0 - The information validity period is unknown, it may change at any time.
  • 255 - The information is so unlikely to change that the information in the package should be considered permanent.
  • 1 .. 254 - The information should be considered valid for a period not to exceed (2**0.125)**N seconds (where N is the value of Pkg TTL.
    This permits an effective time range from 0.125 second to 3,611,622,602 seconds (a bit more than 114 years).
Pkg Length 1..65535

The number of bytes comprising this package, including the package header.

A package, including its header and all included objects, may not exceed 65535 bytes in length.

Pkg contents  (Varies by package type.)

Packet Format

There is really only one kind of FPCP packet.

The FPCP packet begins with a FPCP header, described below, that is followed by zero or more packages.  All of this is carried within the data portion of a UDP packet.

All FPCP packets take the following form.  Note that every packet contains a Query package.

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  VER  | Status|     Flags     | Hops Left     | Reserved (MBZ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Query Identifier        |      Maximum packet size      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Package...                                            ...
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more result packages...                             ...
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of the header have the following meanings:

VER Version 1 (0x01)
Status One of the following.  See the Numbers section of this document for the particular code value assigned to each Status.
  • Probe
  • EndOfPath - Reached the last hop of the path.
  • ForwardingPathForks - The forwarding path forks.
  • NoForwardingPath - No forwarding path.
  • ForwardingLinkDown - Forwarding link is down either administratively or operationally.
  • ForwardingLinkFilterViolation - The hypothetical packet could not be sent on the forwarding link because of an access-control restriction.
  • InitialSourceNotDirectlyAttached - Initial source is not on directly attached subnet.
  • InitialHopInterfaceIsDown - Interface to the initial source is down.
  • WouldExceedSizeLimit - Addition of another package would cause resulting packet to exceed Maximum packet size.
  • HopCountExceeded - The Hops Left field of the probe header has reached zero.
Flags Zero or more of the following, logically OR-ed together:
  • RequestInitialHopData
Hops Left 1..255 - The upper bound on the number of hops through which the FPCP probe should be processed.  This field is examined as the last stage of processing before forwarding an FPCP probe from one router to the next (i.e. after all error handling has been performed and after all packages generated by that router have been appended to the probe packet).  This examination consists of decrementing the field by one and testing the result.  If the result is zero, then the HopCountExceeded status is set and the probe, rather than being forwarded to the next hop router, is sent back to the querying application as identified by the Reply-To object in the Query Package.

0 - Reserved

Query Identifier Set by the querying application to distinguish FPCP queries from one another.
Maximum packet size Maximum number of bytes to which this FPCP packet may be allowed to grow.  If the addition of a package would cause the result to exceed this number then the package MUST NOT be added and, instead, the "WouldExceedSizeLimit" status SHALL be set and the probe packet, along with all existing packages SHALL be sent to to the given Reply-to-IP address and Reply-to UDP port.

Packages

The following subsections define the various kinds of packages and the objects that they may contain.

Most FPCP packages come in two forms - an IPv4 flavor and an IPv6 flavor.  Each flavor is treated as a distinct kind of package.  See the section on IPv4 

Query Package

A Query package contains information about a hypothetical flow about which the routers are to formulate FPCP results.

A thing to note about the Query Package is that the Reply-To objects may be either IPv4 or IPv6 - this permits the reply to be wrapped in whatever version of IP the querying application would like.

Query IPv4 Package bill-of-materials

Object

Inclusion Constraints
Reply-To IPv4 UDP address object
OR
Reply-To IPv6 UDP address object
Exactly one instance
Start-IP address IPv4 object Exactly one instance
Hypothetical IPv4 header object Exactly one instance
Hypothetical sender TSPEC object At most one instance
Force Next Hop IPv4 object At most one instance
All other objects Zero instances

Query IPv6 Package bill-of-materials

Object

Inclusion Constraints
Reply-To IPv4 UDP address object
OR
Reply-To IPv6 UDP address object
Exactly one instance
Start-IP address IPv6 object Exactly one instance
Hypothetical IPv6 header object Exactly one instance
Hypothetical sender TSPEC object At most one instance
Force Next Hop IPv6 object At most one instance
All other objects Zero instances

Initial Hop Data Package:

The Initial Hop Data package contains information about the hop from the source of the hypothetical IP packet to a first hop router.  In other words this is a link coming into the router that is generating the package.

Initial Hop IPv4 Package bill-of-materials

Object

Inclusion Constraints
Link Type object Exactly one instance
Link Speed object
OR
Link HighSpeed object
Exactly one instance
Link Transit Time Estimate object Exactly one instance
Link Loss Estimate object At most one instance
All other objects Zero instances

Initial Hop IPv6 Package bill-of-materials

Object

Inclusion Constraints
Link Type object Exactly one instance
Link Speed object
OR
Link HighSpeed object
Exactly one instance
Link Transit Time Estimate object Exactly one instance
Link Loss Estimate object At most one instance
All other objects Zero instances

Next Hop Data Package:

The Next Hop Data package contains information about the hop from one router to the next.  A Next Hop Data package contains information about a link that is outgoing from the router that is creating the package.

Next Hop IPv4 Package bill-of-materials

Object

Inclusion Constraints
Reporting IP Address IPv4 Exactly one instance
Next Hop IPv4 Exactly one instance
Link Type Exactly one instance
Link Speed object
OR
LinkHighSpeedObject
Exactly one instance
Link Transit Time Estimate Object Exactly one instance
Link Loss Estimate object At most one instance.
Router Latency Estimate object Exactly one instance
Router Drop Probability Estimate object At most one instance
WRED Estimate object At most one instance
All other objects Zero instances

 

Next Hop IPv6 Package bill-of-materials

Object

Inclusion Constraints
Reporting IP Address IPv6 Exactly one instance
Next Hop IPv6 Exactly one instance
Link Type Exactly one instance
Link Speed object
OR
LinkHighSpeedObject
Exactly one instance
Link Transit Time Estimate Object Exactly one instance
Link Loss Estimate object At most one instance.
Router Latency Estimate object Exactly one instance
Router Drop Probability Estimate object At most one instance
WRED Estimate object At most one instance
All other objects Zero instances

 

Path Fork Data Package:

The Path Fork Data package enumerates the possible forwarding paths that exist when there is more than a single forwarding path.

Path Fork IPv4 Package bill-of-materials

Object

Inclusion Constraints
Possible Path IPv4 object One or more instances
All other objects Zero instances

Path Fork IPv6 Package bill-of-materials

Object

Inclusion Constraints
Possible Path IPv6 object One or more instances
All other objects Zero instances

 

Objects

Reporting IP Address IPv4

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |   Reporting IPv4 Address ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... Reporting IPv4 Address     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Reporting IPv4 UDP Address
Obj Length The number of bytes comprising this object, including the object header.
Reporting IPv4 Address When included in an Initial Hop package this is the IPv4 address of the ingress interface of the router that created the Initial Hop package.

When included in  a Next Hop package this is the IPv4 address of the egress interface of the router that created the Next Hop package.

 

Reporting IP Address IPv6

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |   Reporting IPv6 Address ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|  ... Reporting IPv6 Address                                   |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Reporting IPv6 UDP Address
Obj Length The number of bytes comprising this object, including the object header.
Reporting IPv6 Address When included in an Initial Hop package this is the IPv6 address of the ingress interface of the router that created the Initial Hop package.

When included in  a Next Hop package this is the IPv6 address of the egress interface of the router that created the Next Hop package.

 

Reply-To IPv4 UDP Address Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |         UDP Port number       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Reply-To IPv4 Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Reply-To IPv4 UDP Address
Obj Length The number of bytes comprising this object, including the object header.
UDP Port number UDP port number to which result or error packets are to be sent.
Reply-To IPv4 Address IPv4 address to which result or error packets are to be sent.

Reply-To IPv6 UDP Address Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |         UDP Port number       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Reply-To IPv6 Address                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Link Type (0x09)
Obj Length The number of bytes comprising this object, including the object header.
UDP Port number UDP port number to which result or error packets are to be sent.
Reply-To IPv6 Address IPv6 address to which result or error packets are to be sent.

 

Start-IP address IPv4 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |      Start IPv4 Address ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Start IPv4 Address        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Start IPv4 UDP Address
Obj Length The number of bytes comprising this object, including the object header.
Start IPv4 Address IPv4 address to which the FPCP query process is to begin.

Start-IP address IPv6 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |      Start IPv6 Address ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|  ... Start IPv6 Address                                       |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Start IPv6 UDP Address
Obj Length The number of bytes comprising this object, including the object header.
Start IPv6 Address IPv6 address to which the FPCP query process is to begin.

 

Force Next Hop IPv4 Object

The IP address of the egress interface that is to be used.  This IP address must identify an interface that is operationally and administratively active, however it need not be an interface that would be normally be indicated by routing mechanisms as in interface to be used to forward the hypothetical packet.

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |  Force Next IPv6 Address ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ...Force Next IPv4 Address   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Reply-To IPv4 UDP Address

Obj Length

The number of bytes comprising this object, including the object header.

Force Next IPv4 Address

<<**TODO**>>

 

Force Next Hop IPv6 Object

The IP address of the egress interface that is to be used.  This IP address must identify an interface that is operationally and administratively active, however it need not be an interface that would be normally be indicated by routing mechanisms as in interface to be used to forward the hypothetical packet.

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |  Force Next IPv6 Address ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|  ...Force Next IPv6 Address                                   |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Reply-To IPv6 UDP Address

Obj Length

The number of bytes comprising this object, including the object header.

Force Next IPv6 Address

<<**TODO**>>

 

Hypothetical IPv4 Header Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |          IPv4 Header ...      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|  ... IPv4 Header ...                                          |
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Hypothetical IPv4 Header

Obj Length

The number of bytes comprising this object, including the object header.

IPv4 Header

IPv4 Header (may include IP options)

Hypothetical IPv6 Header Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |          IPv6 Header ...      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|  ... IPv6 Header ...                                          |
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Hypothetical IPv4 Header

Obj Length

The number of bytes comprising this object, including the object header.

IPv6 Header

IPv6 Header (may include IP options)

Hypothetical Sender TSPEC Object

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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |   Token Bucket Rate ...       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...Token Bucket Rate      |   Token Bucket Size ...       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...Token Bucket Size      |   Peak Data Rate ...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ... Peak Data Rate        |   Minimum Policed Unit ...    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ... Minimum Policed Unit  |   Maximum Packet Size ...     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ... Maximum Packet Size   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Hypothetical Sender TSPEC

Obj Length

The number of bytes comprising this object, including the object header.

Token Bucket Rate

(32-bit IEEE floating point number)

See RFC2215

Token Bucket Size

(32-bit IEEE floating point number)

See RFC2215

Peak Data Rate 

(32-bit IEEE floating point number)

See RFC2215

Minimum Policed Unit

See RFC2215

Maximum Packet Size

See RFC2215

 

Link Type Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |            Link MTU           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Link Type                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link Type

Obj Length

The number of bytes comprising this object, including the object header.

Link MTU

The Maximum Transmission Unit as perceived by the IP protocol.  Thus number is in bytes and includes the space required for the IP header but not any media headers or wrappers.

Link Type

IANAifType (RFC2233)

 

Link Speed Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |            Link Speed...        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Link Speed               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link Speed

Obj Length

The number of bytes comprising this object, including the object header.

Object contents

 (Varies by object type.

Link Speed

ifSpeed (RFC2233)

 

Link HighSpeed Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |            Link High Speed... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Link High Speed          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link HighSpeed

Obj Length

The number of bytes comprising this object, including the object header.

Link High Speed

ifHighSpeed (RFC2233)

 

Link Transit Time Estimate Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  | Link Transit Time Estimate... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... Link Transit Time Estimate |Link Transit Time Est StdDev...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Link Transit Time Est StdDev|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link Transit Time Estimate

Obj Length

The number of bytes comprising this object, including the object header.

Link Transit Time Estimate

 Estimated number of nanoseconds required for the hypothetical packet to flow from the output interface of the source into the input interface of the router creating this package.  (This number is independent of packet size and is a measure of the propagation delay of the link.)

Link Transit Time Est StdDev

An indication of how much the Link Transit Time Estimate may vary.

Link Loss Estimate  Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  | Link Loss Est |Loss Est StdDev|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link Loss Estimate

Obj Length

The number of bytes comprising this object, including the object header.

Link Loss Est

An estimate of the likelihood that the hypothetical packet will be lost on the link.

The estimate is expressed as 1/(2**N) where N is the value of this Link Loss Est..  A value of zero represents essentially 100% loss and a value of 254 represents a loss of one packet in every 2**254 packets.

The value 255 is a distinguished value that indicates that the loss rate is effectively zero.

Loss Est StdDev

An indication of how much the Link Loss Est may vary.

 

Router Latency Estimate Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |          Delay Estimate...    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Delay Estimate           |       Delay Estimate StdDev...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Delay Estimate StdDev    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Router Latency Estimate

Obj Length

The number of bytes comprising this object, including the object header.

Delay Estimate

Estimated number of nanoseconds required for the hypothetical packet to flow from the input interface of the router generating this package to the output interface.  (This number is independent of packet size and is a measure of the processing and queueing delays within the router.)

Delay Estimate StdDev

An indication of how much the Delay Estimate may vary.

 

Router Drop Probability Estimate Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |  Drop Probability Estimate... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Drop Probability Estimate | Drop Probability Est StdDev...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Drop Probability Est StdDev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Router Drop Probability Estimate

Obj Length

The number of bytes comprising this object, including the object header.

Drop Probability Estimate

An estimate of the likelihood that the hypothetical packet would be dropped due to congestion or to a packet drop algorithm (such as WRED.)

If zero, the packet drop rate estimate is less than 1 per 65536 packets.

If non zero, the packet drop rate estimate is 1 per the indicated value.

<<<***Consider an alternative representation - something like 1/(2**N)

Drop Probability Est. StdDev

An indication of how much the Drop Probability Estimate may vary.

 

WRED Estimate Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |         Est. TTL              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                  StdDev                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Object Type

Link Transit Time Estimate

Obj Length

The number of bytes comprising this object, including the object header.

WRED Est. TTL

1..65535: An indication of how long this WRED estimate should be considered valid, in seconds.

Zero is a distinguished value indicating that the link transit time is not expected to change.

 

Estimate StdDev

An indication of how much this estimate may vary.

 

Next Hop IPv4 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |    Hop Chance   |Outgoing IPv4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Outgoing IPv4 Interface Address            |Next Hop IPv4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Next Hop IPv4 Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outgoing IPv4 Interface Address

The IP address of the interface out of which the hypothetical packet would be forwarded.

Next Hop IPv4 Address

The IP address to which the hypothetical packet would be forwarded.

Next Hop IPv6 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |    Hop Chance   |Outgoing IPv6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|  ... Outgoing IPv6 Interface Address                          |
|                                                 +-+-+-+-+-+-+-+
|                                                 |Next Hop IPv6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|  ... Next Hop IPv6 Address                                    |
|                                                 +-+-+-+-+-+-+-+
|                                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outgoing IPv6 Interface Address

The IP address of the interface out of which the hypothetical packet would be forwarded.

Next Hop IPv6 Address

The IP address to which the hypothetical packet would be forwarded.

Possible Path IPv4 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |    Hop Chance   |Next Hop IPv4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ... Next Hop IPv4 Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Hop IPv4 Address

IPv4 address to which the hypothetical IP packet could be forwarded.

This address represents an interface on a next hop router.

Hop Chance

0..255

This is a metric indicating the preference that this path will be used.

The metrics are used solely to indicate which next hops are more preferred and which are less preferred.

The metrics are not probabilities.

The values themselves (as well as the differences in values for different possible next hops) have no quantitative meaning except that:

  • Zero means that the associated next hop will never be used.

  • Equal values mean that there is an equal chance that the related next hops will be used.

  • Larger values indicate that a hop is more likely to be selected than a hop with a lower value and that the ratio of values is roughly equivalent to the ratio of the likelihood that each hop will be selected.

Possible Path IPv6 Object

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Object Type  |   Obj Length  |    Hop Chance   |Next Hop IPv6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|  ... Next Hop IPv6 Address                                    |
|                                                 +-+-+-+-+-+-+-+
|                                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Hop IPv6 Address

IPv6 address to which the hypothetical IP packet could be forwarded.

This address represents an interface on a next hop router.

Hop Chance

0..255

This is a metric indicating the preference that this path will be used.

The metrics are used solely to indicate which next hops are more preferred and which are less preferred.

The metrics are not probabilities.

The values themselves (as well as the differences in values for different possible next hops) have no quantitative meaning except that:

  • Zero means that the associated next hop will never be used.

  • Equal values mean that there is an equal chance that the related next hops will be used.

  • Larger values indicate that a hop is more likely to be selected than a hop with a lower value and that the ratio of values is roughly equivalent to the ratio of the likelihood that each hop will be selected.

IPv4 and IPv6

The choice of IPv4 or IPv6 encapsulation is completely independent of whether FPCP is being used to evaluate an IPv4 or IPv6 path.  An IPv6 FPCP probe may be carried in an IPv4 frame and vice versa.

Indeed, the IP version used for the wrapper may change at each hop at the discretion of the device that is sending the FPCP packet..  The only place that the IP version is nailed down is for the encapsulation used to send the result back to the querying application.

As an overall rule, FPCP packets that contain an IPv4 Query package MUST contain only the IPv4 versions of those packages that have IP version variants.  Similarly those FPCP packets that contain an IPv6 Query package MUST contain only the IPv6 versions of those packages that have IP version variants.

Because the any version of IP may be used to carry an FPCP packet that itself queries any version of IP, it is necessary that the FPCP portion of the packet not depend on information obtained from the enclosing IP and UDP headers.  In particular, the destination IP address from the IP/UDP header is insufficient to indicate to a router that is receiving an FPCP query directly from a querying application (as opposed to receiving it from another router that is bucket-brigading the probe packet) which interface to use to begin the FPCP sequence.  For this reason, the Query Package contains a Start IP address object to indicate the router ingress address at which the probe is to begin.

Numeric Precision

FPCP is not intended to obtain highly precise numbers - one should assume that the results contain relatively few significant digits.

The intent is, rather, to obtain something that is a fair, but not perfect, set of numbers that can be used for comparative purposes with FPCP values obtained between other source/destination pairs.

It is expected that when one wants more precise values that one will resort to SNMP and MIBs. 

When the Probe Packet Grows Too Large

A probe packet gets larger and larger as it moves through a sequence of routers along a path.

At some point the addition of a new package of information to the probe would make the resulting packet exceed a size limit set in the probe packet or some local implementation limitation.

In that case, rather than adding an information package, the router that detects this condition sets the WouldExceedSizeLimit flag in the probe packet and then sends the probe packet back to an address indicated in the probe.  (That address is presumably that of the application that is performing the FPCP query.)  Once the probe is sent back to the querying application the router performs no further processing of the probe.

When the router is generating multiple packages, this size test is performed for each package rather than for all the packages together.  Thus it is possible that the first package(s) generated may fit while the subsequent package(s) may not.  The error packat that is returned to the querying application will thus contain all the packages that could fit.

Upon receipt of the returned probe packet that application has the option of stopping or of starting a new FPCP query starting at the router that returned the probe with the WouldExceedSizeLimit indication.  The querying application is responsible for logically splicing the information obtained from the initial FPCP with that obtained from successor FPCP sessions.  Note: because the probe that triggered the oversize situation contains all the packages that could fit, the querying application should be prepared for the successor FPCP session to generate some packages that duplicate those generated by the last hop of the query that triggered the oversize situation.

Obtaining Information About the Initial link

The Next Hop and Path Fork packages are forward looking - they contain information about how the hypothetical packet will be moved forward towards the destination from the current router.

The Initial Hop package is retrospective - it contains data about how the source host indicated by the hypothetical packet will move the hypothetical packet to the router that has been asked to generate the Initial Hop package.

There is a flag in the Flag field of the FPCP header - Request Initial HopData.

If set, this flag indicates that if if the following conditions are met, the router should attempt to generate an Initial Hop Data package (of the correct IP version) before attempting to generate any other package:

Upon successfully generating and appending the Initial Hop Data package, the router SHALL reset the Request Initial HopData flag so that the subsequent routers do not attempt to generate an Initial Hop Data package.

Dealing With Forking Paths

An FPCP probe stops when it hits a router where the path to the destination splits so that there is more than one possible next hop.  However, before stopping, a Path Fork package is generated and added to the probe, which is then sent back to the querying application.

This Path Fork package contains a list of the possible next hops, along with an assessment as to the probability that the hypothetical packet would be sent to each of those potential next hops.  It is up to the querying application to use this information to start a new FPCP query starting with each of those potential next hops (or at least those that have a non-trivial chance of being used) and splicing the results together with the already-accumulated FPCP information to build an overall assessment of the forked path.  How that splicing is done is a matter for the application and is not defined by this specification.

<<**TODO**>> Say how one uses Force Next Hop object to resume the trace at the router where the fork occurred.

Dealing With Non-FPCP Routers.

FPCP is loosely modeled on the multicast traceroute (draft-ietf-idmr-traceroute-ipm-06.txt).  In particular FPCP makes use of a probe packet that is sent from an FPCP application to the first router in a path.  From then on the probe packet is forwarded hop by hop to each successive router.  Each router appends an information segment about itself and, optionally, about the incoming and outgoing interfaces and links used by the probe.  If an error is encountered or if the path forks or the probe grows too large, the FPCP is terminated and a response sent back to FPCP application.  When the probe grew too large, the FPCP application may simply start a continuing FPCP with a fresh (and hence still-small) probe at the point of the problem.  When the path splits, the FPCP application may initiate a new FPCP for each of the forks.

Detecting and Suppressing Probe Packet Loops

When processing a probe packet, a router must scan the list of items in the packet placed there by previous routers.  If one is encountered that has an address of one of the router's interfaces, then there is a routing loop.  The probe packet MUST be marked with the routing-loop detected error code and sent to the querying application's address in the probe packet.  Further processing of the FPCP probe packet by the router then ceases.

However, checking for probe packet loops by the routers is not sufficient.  It is possible for a routing situation to be made invisible because of an intervening break in the FPCP procedure due to a probe packet becoming too large or a route forking.  Thus the querying application MUST take steps to detect loops.

In particular, the querying application MUST NOT send a probe packet to any router that has already been examined by any of the FPCP pieces that are being spliced together.  As a practical matter this means that whenever a querying application is engaged in the task of piecing together multiple FPCP results that it must scan all the results that it has already accumulated to see whether the router to which it is intending on sending the probe packet is to be found in any of the accumulated data.  If so, the querying application MUST declare a routing loop and MUST abort the FPCP procedure.

Measuring A Partial Path

<<**TODO**>>

What Happens When An FPCP Packet Is Lost.

FPCP packets are carried in UDP.  And UDP makes no guarantees of delivery.

If one desires a guaranteed FPCP service, the querying application must maintain lists of unanswered queries and associated timers.  The querying application must decide for itself when a query has gone awry and must start a new query.

The querying application MUST not re-use a query identifier unless the querying application is certain that old probe packets with the query id have gone to the great network bit bucket in the sky.  As a practical matter this means not re-using a query id for at least 256 seconds.

How A Router Processes A Received FPCP Packet ("Elements of Procedure")

<<**TODO**>>

The Querying Application

<<**TODO**>>

Issues

**TODO** Measuring delays in routers, especially in output queues - how is it done?

**TODO** How does router determine queue delay and link delay (and queue loss probability) for IP headers with unusual QoS or options?

Number Assignments

Status Values in FPCP Packet Header

Value Name

Description

Code

Probe

 

0x01

EndOfPath

Reached the last hop of the path.  This is the normal termination of an FPCP query.

0x81

ForwardingPathForks

The forwarding path forks.

0x82

NoForwardingPath

No forwarding path.

0x83

ForwardingLinkDown

Forwarding link is down.

0x84

InitialSourceNotDirectlyAttached 

Initial source is not on directly attached subnet.

0x85

InitialHopInterfaceIsDown

An Initial Hop package has been requested but the interface is operationally or administrative non-operational.

0x86

WouldExceedSizeLimit

Addition of another package would cause resulting packet to exceed Maximum packet size.

0x87

HopCountExceeded

The Hops Left field in the FPCP packet header has been decremented to zero.

0x88

ForwardingLinkFilterViolation

The hypothetical packet could not be sent on the forwarding link because of an access-control restriction.

0x89

 

Flag Values in FPCP Packet Header

Flag Name

Description

Code

Request Initial HopData

Indicates that if if the following conditions are met, the router should attempt to generate an Initial Hop Data package (of the correct IP version) before attempting to generate any other package:

  • No packages except the a Query package are in the probe packet.

  • The interface indicated by the Start-IP address object in the Query package is both operationally and administratively operational.

  • The source IP address of the hypothetical IP header in the Query package is on the directly attached subnet on the interface indicated by the Start-IP address object in the Query package.

0x01

 

 

 

 

Package Types

Package Name

Code

Query IPv4

0x01

Query IPv6

0x81

Initial Hop Data IPv4

0x02

Initial Hop Data IPv6

0x82

Next Hop Data IPv4

0x03

Next Hop Data IPv6

0x83

Path Fork Data IPv4

0x04

Path Fork Data IPv6

0x84

 

 

 

 

 

Object Types

Object Name

Code

Reporting IP Address IPv4

0x01

Reporting IP Address IPv6

0x81

Reply-To IPv4 UDP address

0x02

Reply-To IPv6 UDP address

0x82

Start-IP address IPv4

0x03

Start-IP address IPv6

0x83

Force Next Hop IPv4

0x04

Force Next Hop IPv6

0x84

Hypothetical IPv4 header

0x05

Hypothetical IPv6 header

0x85

Next Hop IPv4

0x06

Next Hop IPv6

0x86

Possible Path IPv4

0x07

Possible Path IPv6

0x87

Hypothetical sender TSPEC

0x08

Link Type 0x09
Link Speed 0x0A
Link HighSpeed 0x0B

Link Transit Time Estimate

0x0C

Link Loss Estimate

0x0D

Router Latency Estimate

0x0E

Router Drop Probability Estimate

0x0F

WRED Estimate

0x10

 

Security

Design Documents

Draft document  <<<***Out of Date***>>>

Acknowledgements

This work was originally conceived while reading a paper by Allen Downey.

Substantial and invaluable comments were received from Bruce Mah.

References

RFC2215 General Characterization Parameters for Integrated Service Network Elements
S. Shenker, J. Wroclawski
September 1997
RFC2233 The Interfaces Group MIB using SMIv2
K. McCloghrie, F. Kastenholz
November 1997
RFC2748 The COPS (Common Open Policy Service) Protocol
J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry
January 2000
RFC2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin
September 199
pathchar Van Jacobson'
ftp://ftp.ee.lbl.gov/pathchar/
pchar A reimplementation of Van Jacobson's pathchar utility for characterizing the individual hops of a path between two network hosts.
Bruce Mah
http://www.employees.org/~bmah/Software/pchar/
clink

Another reimplementation of Van Jacobson's pathchar utility called clinkClink offers some slightly different statistical analysis, as well as the option for Linux in-kernel timestamping of packets.
Allen B. Downey of Colby College, Maine

mtrace draft-ietf-idmr-traceroute-ipm-07.txt
W. Fenner, S. Casner
Expires January 2001

 

Authors


Updated: September 19, 2000