rfc2544.txt

<VC++网络游戏建摸与实现>源代码

   assigned for use on the "input" ports.  A second series from
   198.19.1.0 to 198.19.64.0 have been assigned for use on the "output"
   ports. In all cases the router port is node 1 on the appropriate
   network.  For example, a two port DUT would have an IP address of
   198.18.1.1 on one port and 198.19.1.1 on the other port.

   Some of the tests described in the methodology memo make use of an
   SNMP management connection to the DUT.  The management access address
   for the DUT is assumed to be the first of the "input" ports
   (198.18.1.1).

C.2.2.2 Frame addresses

   Some of the described tests assume adjacent network routing (the
   reboot time test for example).  The IP address used in the test frame
   is that of node 2 on the appropriate Class C network. (198.19.1.2 for
   example)

   If the test involves non-adjacent network routing the phantom routers
   are located at node 10 of each of the appropriate Class C networks.
   A series of Class C network addresses from 198.18.65.0 to
   198.18.254.0 has been assigned for use as the networks accessible
   through the phantom routers on the "input" side of DUT.  The series
   of Class C networks from 198.19.65.0 to 198.19.254.0 have been
   assigned to be used as the networks visible through the phantom
   routers on the "output" side of the DUT.

C.2.3 Routing Update Frequency

   The update interval for each routing protocol is may have to be
   determined by the specifications of the individual protocol.  For IP
   RIP, Cisco IGRP and for OSPF a routing update frame or frames should
   precede each stream of test frames by 5 seconds.  This frequency is
   sufficient for trial durations of up to 60 seconds.  Routing updates
   must be mixed with the stream of test frames if longer trial periods
   are selected.  The frequency of updates should be taken from the
   following table.

          IP-RIP  30 sec
          IGRP  90 sec
          OSPF  90 sec




Bradner & McQuaid            Informational                     [Page 25]

RFC 2544                Benchmarking Methodology              March 1999


C.2.4 Frame Formats - detailed discussion

C.2.4.1 Learning Frame

   In most protocols a procedure is used to determine the mapping
   between the protocol node address and the MAC address.  The Address
   Resolution Protocol (ARP) is used to perform this function in TCP/IP.
   No such procedure is required in XNS or IPX because the MAC address
   is used as the protocol node address.

   In the ideal case the tester would be able to respond to ARP requests
   from the DUT.  In cases where this is not possible an ARP request
   should be sent to the router's "output" port.  This request should be
   seen as coming from the immediate destination of the test frame
   stream. (i.e. the phantom router (Figure 2) or the end node if
   adjacent network routing is being used.) It is assumed that the
   router will cache the MAC address of the requesting device.  The ARP
   request should be sent 5 seconds before the test frame stream starts
   in each trial.  Trial lengths of longer than 50 seconds may require
   that the router be configured for an extended ARP timeout.

                      +--------+            +------------+
                      |        |            |  phantom   |------ P LAN
         A
            IN A------|   DUT  |------------|            |------ P LAN
         B
                      |        |   OUT A    |  router    |------ P LAN
         C
                      +--------+            +------------+

                                 Figure 2

           In the case where full routing is being used

C.2.4.2 Routing Update Frame

   If the test does not involve adjacent net routing the tester must
   supply proper routing information using a routing update.  A single
   routing update is used before each trial on each "destination" port
   (see section C.24).  This update includes the network addresses that
   are reachable through a phantom router on the network attached to the
   port.  For a full mesh test, one destination network address is
   present in the routing update for each of the "input" ports.  The
   test stream on each "input" port consists of a repeating sequence of
   frames, one to each of the "output" ports.






Bradner & McQuaid            Informational                     [Page 26]

RFC 2544                Benchmarking Methodology              March 1999


C.2.4.3 Management Query Frame

   The management overhead test uses SNMP to query a set of variables
   that should be present in all DUTs that support SNMP.  The variables
   for a single interface only are read by an NMS at the appropriate
   intervals.  The list of variables to retrieve follow:

             sysUpTime
             ifInOctets
             ifOutOctets
             ifInUcastPkts
             ifOutUcastPkts

C.2.4.4 Test Frames

   The test frame is an UDP Echo Request with enough data to fill out
   the required frame size.  The data should not be all bits off or all
   bits on since these patters can cause a "bit stuffing" process to be
   used to maintain clock synchronization on WAN links.  This process
   will result in a longer frame than was intended.

C.2.4.5 Frame Formats - TCP/IP on Ethernet

   Each of the frames below are described for the 1st pair of DUT ports,
   i.e. "input" port #1 and "output" port #1.  Addresses must be changed
   if the frame is to be used for other ports.

C.2.6.1 Learning Frame

          ARP Request on Ethernet

          -- DATAGRAM HEADER
          offset data (hex)            description
          00     FF FF FF FF FF FF     dest MAC address send to
         broadcast address
          06     xx xx xx xx xx xx     set to source MAC address
          12     08 06                 ARP type
          14     00 01                 hardware type Ethernet = 1
          16     08 00                 protocol type IP = 800
          18     06                    hardware address length 48 bits
         on Ethernet
          19     04                    protocol address length 4 octets
         for IP
          20     00 01                 opcode request = 1
          22     xx xx xx xx xx xx     source MAC address
          28     xx xx xx xx           source IP address
          32     FF FF FF FF FF FF     requesting DUT's MAC address
          38     xx xx xx xx           DUT's IP address



Bradner & McQuaid            Informational                     [Page 27]

RFC 2544                Benchmarking Methodology              March 1999


C.2.6.2 Routing Update Frame

          -- DATAGRAM HEADER
          offset data (hex)            description
          00     FF FF FF FF FF FF     dest MAC address is broadcast
          06     xx xx xx xx xx xx     source hardware address
          12     08 00                 type

          -- IP HEADER
          14     45                    IP version - 4, header length (4
         byte units) - 5
          15     00                    service field
          16     00 EE                 total length
          18     00 00                 ID
          20     40 00                 flags (3 bits) 4 (do not
         fragment),
                                       fragment offset-0
          22     0A                    TTL
          23     11                    protocol - 17 (UDP)
          24     C4 8D                 header checksum
          26     xx xx xx xx           source IP address
          30     xx xx xx              destination IP address
          33     FF                    host part = FF for broadcast

          -- UDP HEADER
          34     02 08                 source port 208 = RIP
          36     02 08                 destination port 208 = RIP
          38     00 DA                 UDP message length
          40     00 00                 UDP checksum

          -- RIP packet
          42     02                  command = response
          43     01                  version = 1
          44     00 00               0

          -- net 1
          46     00 02               family = IP
          48     00 00               0
          50     xx xx xx            net 1 IP address
          53     00                  net not node
          54     00 00 00 00         0
          58     00 00 00 00         0
          62     00 00 00 07         metric 7

          -- net 2
          66     00 02               family = IP
          68     00 00               0
          70     xx xx xx            net 2 IP address



Bradner & McQuaid            Informational                     [Page 28]

RFC 2544                Benchmarking Methodology              March 1999


          73     00                  net not node
          74     00 00 00 00         0
          78     00 00 00 00         0
          82     00 00 00 07         metric 7

          -- net 3
          86     00 02               family = IP
          88     00 00               0
          90     xx xx xx            net 3 IP address
          93     00                  net not node
          94     00 00 00 00         0
          98     00 00 00 00         0
          102    00 00 00 07         metric 7

          -- net 4
          106    00 02               family = IP
          108    00 00               0
          110    xx xx xx            net 4 IP address
          113    00                  net not node
          114    00 00 00 00         0
          118    00 00 00 00         0
          122    00 00 00 07         metric 7

          -- net 5
          126    00 02               family = IP
          128    00 00               0
          130    00                  net 5 IP address
          133    00                  net not node
          134    00 00 00 00         0
          138    00 00 00 00         0
          142    00 00 00 07         metric 7

          -- net 6
          146    00 02               family = IP
          148    00 00               0
          150    xx xx xx            net 6 IP address
          153    00                  net not node
          154    00 00 00 00         0
          158    00 00 00 00         0
          162    00 00 00 07         metric 7

C.2.4.6 Management Query Frame

   To be defined.

C.2.6.4 Test Frames

   UDP echo request on Ethernet



Bradner & McQuaid            Informational                     [Page 29]

RFC 2544                Benchmarking Methodology              March 1999


          -- DATAGRAM HEADER
          offset data (hex)            description
          00     xx xx xx xx xx xx     set to dest MAC address
          06     xx xx xx xx xx xx     set to source MAC address
          12     08 00                 type

          -- IP HEADER
          14     45                    IP version - 4 header length 5 4
         byte units
          15     00                    TOS
          16     00 2E                 total length*
          18     00 00                 ID
          20     00 00                 flags (3 bits) - 0 fragment
         offset-0
          22     0A                    TTL
          23     11                    protocol - 17 (UDP)
          24     C4 8D                 header checksum*
          26     xx xx xx xx           set to source IP address**
          30     xx xx xx xx           set to destination IP address**

          -- UDP HEADER
          34     C0 20                 source port
          36     00 07                 destination port 07 = Echo
          38     00 1A                 UDP message length*
          40     00 00                 UDP checksum

          -- UDP DATA
          42     00 01 02 03 04 05 06 07    some data***
          50     08 09 0A 0B 0C 0D 0E 0F

         * - change for different length frames

         ** - change for different logical streams

         *** - fill remainder of frame with incrementing octets,
         repeated if required by frame length

   Values to be used in Total Length and UDP message length fields:

          frame size   total length  UDP message length
             64            00 2E          00 1A
             128           00 6E          00 5A
             256           00 EE          00 9A
             512           01 EE          01 9A
             768           02 EE          02 9A
             1024          03 EE          03 9A
             1280          04 EE          04 9A
             1518          05 DC          05 C8



Bradner & McQuaid            Informational                     [Page 30]

RFC 2544                Benchmarking Methodology              March 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright not