Subject: [ippm] re: draft-bennett-ippm-ipmp-00.txt

From: jon b <[email-masked]>
Date: Thu, 7 Nov 2002 20:55:11 -0800 (PST)

>Would you say a bit about what's new with your draft and how
>it differs from the previous IPMP draft?
>
>--Matt

The differences between draft-bennett-ipmp-00.txt and
draft-mcgregor-ipmp-00.txt can be grouped into a number of different
areas. This isn't a complete list, but it covers most of the
differences I think.

1) Modifications to make it easier to implement in hardware in a
   router fast path, as well as make it easier for routers to perform
   filtering on IPMP packets.

   a) rearranged the header to make it easier to process in hardware

   b) added extra fields to allow it to be filtered as if it was a
   TCP/UDP packet so that the path taken by individual flows can be
   measured. 

   c) reduced the timestamp from 64 to 40 bits (16 bits of seconds, 24
   bits of fractional seconds) to save space in the timestamp, and
   reduce the expectation that routers are going to have 64 bit real
   time clocks.

2) Modifications to make the protocol more "industrial strength", in
   terms of its handling of various of conditions.

   a) added error return codes and mechanism

   b) added flags and ranges (on the TTL) to allow measuring of paths
   that are too long to be measured with one packet, either because
   the path is long, or because a small packet is being used.

   c) added ability to give a 'proxy' address so that the router does
   not have to respond to "Information Request" packets, but can
   indicate someone who will respond in the routers place. this allows
   ISPs to support IPMP without having to let people talk to their
   routers in order to do so.

3) Modifications to make the results returned by the "Echo" portion of
   the protocol capable of being used without requiring the use of the
   "Information Request" portion of the protocol.

   a) added flags to the timestamp to give details about its accuracy,
   clock source, stamping location, etc, so that for some applications
   it will not be required to have to make an "Information Request" to
   be able to use the timestamp.

   b) added the TTL to the timestamp so it can be seen which hops on
   the path are IPMP aware

4) Addition of a "redirection" function to allow measurement of a
   path beginning at a host other than the one which originally sent
the
   packet. 

   a) includes security options to limit/authenticate its use.

5) Added ability to have the Information Request packet ask to have
   specific timestamp values converted to real time values, instead of
   just having the router give conversion point of its own choosing.

   a) includes error return for case where router restarts and can't
   convert and old timestamp.

6) Misc other changes

   a) added option to request measurement only in the "fast path"
   (i.e. if you can't give an accurate measurement leave the packet
   alone) 

   b) added option to request only address stamps, instead of
   timestamps, i.e. gives a replacement for 'traceroute' that is less
   abusive on the routers.

   c) added option to request "extra information" with the
   timestamp, such as MTU, link speed, etc (i.e. lets the router tell
   you about properties of the path so you don't have to, figure them
   out, or infer them from observed behavior.

   d) added general TLV "extensions" to the timestamp to support c)
   above and any other additional that might be useful.

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm