rfc2041.txt

RFC 的详细文档！

   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
   are in Table 3.  In addition to the property list, general headers
   have only the IP address of the host generating the record and the
   time at which observations began.  General entries have only a
   timestamp, and the optional fields.





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


4.6. Annotations

   An experimenter may occasionally want to embed arbitrary descriptive
   text into a trace.  We include annotation records to provide for
   this.  Such records are not part of a track; they stand alone.  The
   structure of an annotation record is shown in Figure 7.  Annotations
   include the time at which the annotation was inserted in the trace,
   the host which inserted the annotation, and the variable-sized text
   of the annotation itself.

      struct tr_gen_hdr_t {
          u_int32_t            gh_magic;
          u_int32_t            gh_size;
          u_int32_t            gh_defines;
          struct tr_time_t     gh_ts;
          u_int32_t            gh_ip;
          struct tr_prop_lst_t gh_plist[0]; /* Variable size */
      };

      struct tr_gen_ent_t {
          u_int32_t        ge_magic;
          u_int32_t        ge_size;
          struct tr_time_t ge_ts;
          u_int32_t        ge_vlist[0]; /* Variable size */
      };

               Figure 6: General header and entry records


      +------------+--------------------------------------------+
      | MH_LOC_X   | Mobile host's X coordinate (map-relative)  |
      | MH_LOC_Y   | Mobile host's Y coordinate (map-relative)  |
      | MH_LOC_LAT | Mobile host's GPS latitude                 |
      | MH_LOC_LON | Mobile host's GPS longitude                |
      +------------+--------------------------------------------+
          Table 3: Current optional fields for general entries


      struct tr_annote_t {
          u_int32_t        a_magic;
          u_int32_t        a_size;
          struct tr_time_t a_ts;
          u_int32_t        a_ip;
          char             a_text[0]; /* variable size */
      };


                      Figure 7: Annotation records



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


4.7. Lost Trace Data

   It is possible that, during collection, some trace records may be
   lost due to trace buffer overflow or other reasons.  Rather than
   throw such traces away, or worse, ignoring the lost data, we've
   included a loss record to count the types of other records which are
   lost in the course of trace collection.  Loss records are shown in
   Figure 8.

      struct tr_loss_t {
          u_int32_t        l_magic;
          u_int32_t        l_size;
          struct tr_time_t l_ts;
          u_int32_t        l_ip;
          u_int32_t        l_pkthdr;
          u_int32_t        l_pktent;
          u_int32_t        l_devhdr;
          u_int32_t        l_devent;
          u_int32_t        l_annote;
      };

                         Figure 8: Loss records

5. Software Components

   In this section, we describe the set of tools that have been built to
   date for mobile network tracing.  We believe many of these tools are
   widely applicable to network tracing tasks, but some have particular
   application to mobile network tracing.  We begin with an overview of
   the tools, their applicability, and the platforms on which they are
   currently supported, as well as those they are being ported to.  This
   information is summarized in Table 4.

   We have made every effort to minimize dependencies of our software on
   anything other than protocol and device specifications.  As a result,
   we expect ports to other BSD-derived systems to be straightforward;
   ports to other UNIX systems may be more complicated, but feasible.

   There are three categories into which our tracing tools can be
   placed:  trace collection, trace modulation, and trace analysis.
   Trace collection tools are used for generating new traces.  They
   record information about the general networking facilities, as well
   as data specific to mobile situations:  mobile host location, base
   station location, and wireless device characteristics.  These tools
   are currently supported on BSDI, and are being ported to NetBSD. We
   describe these tools in Section 5.1.





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


   Trace modulation tools emulate the performance of a traced wireless
   network on a private wired network.  The trace modulation tools,
   discussed in Section 5.2, are currently supported on NetBSD
   platforms.  They are geared toward replaying low speed/quality
   networks on faster and more reliable ones, and are thus most
   applicable to reproducing mobile environments.

   In Section 5.3, we conclude with a set of trace processing and
   analysis tools, which are currently supported on both NetBSD and BSDI
   platforms.  Our analyses to date have focused on properties of
   wireless networks, and are most directly applicable to mobile traces.
   The processing tools, however, are of general utility.

                  +--------------+--------------+--------------+
                  | Collection   | Modulation   | Analysis     |
      +-----------+--------------+--------------+--------------+
      | NetBSD    | In Progress  | Supported    | Supported    |
      | BSDI      | Supported    | Planned      | Supported    |
      +-----------+--------------+--------------+--------------+
This table summarizes the currently supported platforms for the tracing
tool suites, and the platforms to which ports are underway.

                       Table 4: Tool Availability

5.1. Trace Collection Tools

   The network trace collection facility comprises two key components:
   the trace agent and the trace collector.  They are shown in Figure 9.

   The trace agent resides in the kernel where it can obtain data that
   is either expensive to obtain or inaccessible from the user level.
   The agent collects and buffers data in kernel memory; the user-level
   trace collector periodically extracts data from this kernel buffer
   and writes it to disk.  The buffer amortizes the fixed costs of data
   transfer across a large number of records, minimizing the impact of
   data transfer on system performance.  The trace collector retrieves
   data through a pseudo-device, ensuring that only a single -- and
   therefore complete -- trace file is being generated from a single
   experiment.  To provide simplicity and efficiency, the collector does
   not interpret extracted data; it is instead processed off-line by the
   post-processing and analysis tools described in Sections 5.2 and 5.3.

   There are three sorts of data collected by the tracing tools: network
   traffic, network device characteristics, and mobile host location.
   The first two are collected in much the same way; we describe the
   methodology in Section 5.1.1.  The last is collected in two novel
   ways.  These collection methods are addressed in Section 5.1.2.




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


                                     +-----------+  write to disk
                                     | Trace     | ==============>
                                     | Collector |
                                     +-----------+
                                             A
     ========================================|===== kernel boundary
     +-----------------+                     |
     | Transport Layer |                     |
     |-----------------|             +------------------+
     |  Network Layer  |------------>| Trace   +------+ |
     |-----------------|             | Agent   |buffer| |
     |  NI |  NI |  NI |------------>|         +------+ |
     +-----------------+             +------------------+
 This figure illustrates the components of trace collection.  The NI's
                        are network interfaces.

                Figure 9: Components of trace collection

5.1.1. Traffic and Device Collection

   The trace agent exports a set of function calls for traffic and
   device data collection.  Traffic data is collected on a per-packet
   basis.  This is done via a function called from device drivers with
   the packet and a device identifier as arguments.  For each packet,
   the trace record contains the source and destination address options.
   Since our trace format assembles related packets into tracks, common
   information, such as the destination address, is recorded in the
   track header to reduce the record size for each packet entry.  We
   also record the size of each packet.

   Information beyond packet size and address information is typically
   protocol-dependent.  For transport protocols such as UDP and TCP, for
   example, we record the source and destination port numbers; TCP
   packet records also contain the sequence number.  For ICMP packets,
   we record their type, code and additional type-dependent data.  As
   explained in Section 5.2.3, we record the identifier, sequence number
   and time stamp for ICMP ECHOREPLY packets.

   Before appending the record to the trace buffer, we check to see if
   it is the first record in a track.  If so, we create a new packet
   track header, and write it to the buffer prior the packet entry.

   Our trace collection facility provides similar mechanisms to record
   device-specific data such as signal quality, signal level, and noise
   level.  Hooks to these facilities can be easily added to the device
   drivers to invoke these tracing mechanisms.  The extensible and
   self-describing features of our trace format allow us to capture a
   wide variety of data specific to particular network interfaces.



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


   For wireless network devices, we record several signal quality
   measurements that the interfaces provide.  Although some interfaces,
   such as NCR's WaveLAN, can supply this of information for every
   packet received, most devices average their measurements over a
   longer period of time.  As a result, we only trace these measurements
   periodically.  It is up to the device drivers to determine the
   frequency at which data is reported to the trace agent.

   When devices support it, we also trace status and error events.  The
   types of errors, such as CRC or buffer overflow, allow us to
   determine causes for some observed packet losses.  For example, we
   can attribute loss to either the wireless channel or the network
   interface.

5.1.2. Location Tracing

   At first thought, recording the position of a mobile host seems
   straightforward.  It can be approximated by recording the base
   station (BS) with which the mobile host is communicating.  However,
   due to the large coverage area provided by most radio interfaces,
   this information provides a loose approximation at best.  In
   commercial deployments, we may not be able to reliably record the
   base station with which a mobile host communicates.  This section
   outlines our collection strategy for location information in both
   outdoor and indoor environments.

   The solution that we have considered for wide-area, outdoor
   environments makes use of the Global Positioning System (GPS). The
   longitude and latitude information provided by the GPS device is
   recorded in a general track.

   Indoor environments require a different approach because the
   satellite signals cannot reach a GPS device inside a building.  We
   considered deploying an infrared network similar to the Active Badge
   [14] or the ParcTab [12]; however, this significant addition to the
   wireless infrastructure is not an option for most research groups.