rfc2041.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   describing trace, we need some compact way of determining which
   optional fields are present in a given record.  To do this, we group
   related sets of packets into tracks.  For example, a set of records
   that captured packet activity for a single protocol between two
   machines might be put together into a track.  A track is a header
   followed by some number of related records; the header completely
   describes the format of the individual records.  Records from
   separate tracks can be interleaved with one another, so long as the
   header for each individual track appears before any of the track's
   records.  Figure 2 shows an example of how records from different
   tracks might be interleaved.

   Track headers describe their records' content through property lists.
   An entry in a property list is a two-element tuple consisting of a
   name and a value.  The name is a word which identifies the property
   defined by this entry.  Some of these properties are measured only
   once for a track, for example, the address of a one-hop router in a
   track recording packets from that router.  Others are measured once
   per record in that track, such as the signal strength of a device
   which changes over time.  The former, which we call header-only
   properties, have their most significant name bit set.  The value
   field of a header-only property holds the measured value of the
   property.  Otherwise, the value field holds the number of words used
   in each of the track's records.









Noble, et. al.               Informational                      [Page 6]

RFC 2041                 Mobile Network Tracing             October 1996


       +----------++----------++----------++----------++----------+
       | Track #1 || Track #1 || Track #2 || Track #1 || Track #2 |
       | Header   || Entry    || Header   || Entry    || Entry    |
       +----------++----------++----------++----------++----------+

                  Figure 2: Interleaved track records

   Those properties measured in each record in the track are grouped
   together in a value list at the end of each such record.  They appear
   in the same order that was specified in the track header's property
   list so that tools can properly attribute data.  Thus, even if a tool
   doesn't know what property a particular name represents, it can
   identify which parts of a trace record are measuring that property,
   and ignore them.





































Noble, et. al.               Informational                      [Page 7]

RFC 2041                 Mobile Network Tracing             October 1996


4.2. Trace Headers and Footers

   Trace files begin with a trace header, and end with a trace footer.
   The formats of these appear in Figure 3.  The header specifies
   whether this trace was collected on a single machine, or was merged
   from several other traces.  In the former case, the IP address and
   host name of the machine are recorded.  In the latter, the IP address
   is taken from the family of Class E address, which are invalid.  We
   use a family of invalid addresses so that even if we cannot identify
   a number of hosts participating in the trace we can still distinguish
   records from distinct hosts.

      #define TR_DATESZ   32
      #define TR_NAMESZ   64

      struct tr_header_t {
          u_int32_t        h_magic;
          u_int32_t        h_size;
          u_int32_t        h_time_fmt;         /* usec or nsec */
          struct tr_time_t h_ts;               /* starting time */
          char             h_date[TR_DATESZ];  /* Date collected */
          char             h_agent[TR_NAMESZ]; /* DNS name */
          u_int32_t        h_agent_ip;
          char             h_desc[0];          /* variable size */
      };

      struct tr_end_t {
          u_int32_t         e_magic;
          u_int32_t         e_size;
          struct tr_time_t  e_ts;        /* end time */
          char              e_date[32];  /* Date end written */
      };


               Figure 3: Trace header and footer records

   The trace header also specifies which time stamp format is used in
   the trace, and the time at which the trace begins.  There is a
   variable-length description that is a string meant to provide details
   of how the trace was collected.  The trace footer contains only the
   time at which the trace ended; it serves primarily as a marker to
   show the trace is complete.

   Unlike other kinds of records in the trace format, the header and
   footer records have several ASCII fields.  This is to allow standard
   utilities some access to the contents of the trace, without resorting
   to specialized tools.




Noble, et. al.               Informational                      [Page 8]

RFC 2041                 Mobile Network Tracing             October 1996


4.3. Packet Tracks

   Measuring packet activity is the main focus of the network tracing
   project.  Packet activity is recorded in tracks, with a packet header
   and a set of packet entries.  A single track is meant to capture the
   activity of a single protocol, traffic from a single router, or some
   other subset of the total traffic seen by a machine.  The required
   portions of packet headers and entries are presented in Figure 4.

   Packet track headers identify which host generated the trace records
   for that track, as well as the time at which the track began.  It
   records the device on which these packets are received or sent, and
   the protocol used to ship the packet; these allow interpretation of
   device-specific or protocol-specific options.  The header concludes
   with the property list for the track.

      struct tr_pkt_hdr_t {
          u_int32_t            ph_magic;
          u_int32_t            ph_size;
          u_int32_t            ph_defines;  /* magic number defined */
          struct tr_time_t     ph_ts;
          u_int32_t            ph_ip;       /* host generating stream */
          u_int32_t            ph_dev_type; /* device collected from */
          u_int32_t            ph_protocol; /* protocol */
          struct tr_prop_lst_t ph_plist[0]; /* variable size */
      };

      struct tr_pkt_ent_t {
          u_int32_t        pe_magic;
          u_int32_t        pe_size;
          struct tr_time_t pe_ts;
          u_int32_t        pe_psize;    /* packet size */
          u_int32_t        pe_vlist[0]; /* variable size */
      };


               Figure 4: Packet header and entry records

   A packet entry is generated for every traced packet.  It contains the
   size of the traced packet, the time at which the packet was sent or
   received, and the list of property measurements as specified in the
   track header.

   The options we have defined to date are in Table 1.  Several of these
   have played an important role in our early experiments.  ADDR_PEER
   identifies the senders of traffic during the experiment.  We can
   determine network performance using either PKT_SENTTIME for one-way
   traffic between two hosts with closely synchronized clocks, or round



Noble, et. al.               Informational                      [Page 9]

RFC 2041                 Mobile Network Tracing             October 1996


   trip ICMP ECHO traffic and the ICMP_PINGTIME option.  Tracking
   PKT_SEQUENCE numbers sheds light on both loss rates and patterns.
   Section 5 discusses how these measurements are used.

4.4. Device Tracks

   Our trace format records details of the devices which carry network
   traffic.  To date, we've found this most useful for correlating lost
   packets with various signal parameters provided by wireless devices.
   The required portions of device header and entry records appear in
   Figure 5, and are quite simple.  Device track headers identify the
   host generating the track's records, the time at which the
   observation starts, and the type of device that is being traced.
   Each entry contains the time of the observation, and the list of
   optional characteristics.

   +---------------+-----------------------------------------------+
   | ADDR_PEER     | Address of peer host                          |
   | ADDR_LINK     | Address of one-hop router                     |
   | BS_LOC_X      | One-hop router's X coordinate (header only)   |
   | BS_LOC_Y      | One-hop router's Y coordinate (header only)   |
   | PKT_SEQUENCE  | Sequence number of packet                     |
   | PKT_SENTTIME  | Time packet was sent                          |
   | PKT_HOPS      | Number of hops packet took                    |
   | SOCK_PORTS    | Sending and receiving ports                   |
   | IP_PROTO      | Protocol number of an IP packet               |
   | ICMP_PINGTIME | Roundtrip time of an ICMP ECHO/REPLY pair     |
   | ICMP_KIND     | Type and code of an ICMP packet               |
   | ICMP_ID       | The id field of an ICMP packet                |
   | PROTO_FLAGS   | Protocol-specific flags                       |
   | PROTO_ERRLIST | Protocol-specific status/error words          |
   +---------------+-----------------------------------------------+
          Table 1: Current optional fields for packet entries


















Noble, et. al.               Informational                     [Page 10]

RFC 2041                 Mobile Network Tracing             October 1996


      struct tr_dev_hdr_t {
          u_int32_t            dh_magic;
          u_int32_t            dh_size;
          u_int32_t            dh_defines;  /* Magic number defined */
          struct tr_time_t     dh_ts;
          u_int32_t            dh_ip;       /* host generating stream */
          u_int32_t            dh_dev_type; /* device described */
          struct tr_prop_lst_t dh_plist[0]; /* Variable size */
      };

      struct tr_dev_ent_t {
          u_int32_t        de_magic;
          u_int32_t        de_size;
          struct tr_time_t de_ts;
          u_int32_t        de_vlist[0]; /* Variable size */
      };


               Figure 5: Device header and entry records

   These optional characteristics, listed in Table 2, are mostly
   concerned with the signal parameters of the wireless interfaces we
   have available.  Interpreting these parameters is heavily device-
   dependent.  We give examples of how we've used device observations in
   Section 5.

  +-----------------+--------------------------------------------------+
  | DEV_ID          | Major and minor number of device (header only)   |
  | DEV_STATUS      | Device specific status registers                 |
  | WVLN_SIGTONOISE | Signal to noise ratio reported by WaveLAN        |
  | WVLN_SIGQUALITY | Signal quality reported by WaveLAN               |
  | WVLN_SILENCELVL | WaveLAN silence level                            |
  +-----------------+--------------------------------------------------+
          Table 2: Current optional fields for packet entries

4.5. Miscellaneous Tracks

   We use miscellaneous, or general, tracks to record things that don't
   fit clearly in either the packet or device model.  At the moment,
   physical location of a mobile host is the only attribute tracked in
   general trace records.  The required portion of the general header
   and entry records is shown in Figure 6, the two optional properties