���̕�����RFC1242�̓��{���i�a��j�ł��B ���̕����̖|����e�̐��m���͕ۏ�ł��Ȃ����߁A ���m�Ȓm�������߂���͌������Q�Ƃ��Ă��������B �|��҂͂��̕����ɂ���ēǎ҂���蓾��@���Ȃ鑹�Q�̐ӔC���������܂���B ���̖|����e�Ɍ�肪����ꍇ�A�����ł̌��J��A ���̎w�E�͓K�؂ł��B ���̕����̔z�z�͌��̂q�e�b���l�ɖ������ł��B


Network Working Group                                 S. Bradner, Editor
Request for Comments: 1242                            Harvard University
                                                               July 1991


      Benchmarking Terminology for Network Interconnection Devices
          �l�b�g���[�N���ݐڑ����u�̂��߂̃x���`�}�[�N�p��

Status of this Memo
���̕����̏��


   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.
   ���̃����̓C���^�[�l�b�g�����̂̏����������܂��B����̓C���^�[�l�b
   �g�W�����w�肵�܂���B���̃����̔z�z�͖������ł��B

Abstract
�T�v

   This memo discusses and defines a number of terms that are used in
   describing performance benchmarking tests and the results of such
   tests.  The terms defined in this memo will be used in additional
   memos to define specific benchmarking tests and the suggested format
   to be used in reporting the results of each of the tests.  This memo
   is a product of the Benchmarking Methodology Working Group (BMWG) of
   the Internet Engineering Task Force (IETF).
   ���̃����͔\�͊�e�X�g�Ƃ��̂悤�ȃe�X�g�̌��ʂ��L�q����ۂɎg����
   ���̗p���_���āA�����Ē�`���܂��B���̃����Œ�`���ꂽ�p��͓����
   ��e�X�g�ƃe�X�g�̂��ꂼ��̌��ʂ�񍐂���ۂɎg���t�H�[�}�b�g�̒�
   �Ă��`���鑼�̃����Ŏg����ł��傤�B���̃����̓C���^�[�l�b�g�Z�p
   �W�����^�X�N�t�H�[�X�i�h�d�s�e�j�̊���@���[�L���O�O���[�v�i�a�l�v
   �f�j�̃v���_�N�g�ł��B

1.  Introduction
1.  �͂��߂�

   Vendors often engage in "specsmanship" in an attempt to give their
   products a better position in the marketplace.  This usually involves
   much "smoke & mirrors" used to confuse the user.  This memo and
   follow-up memos attempt to define a specific set of terminology and
   tests that vendors can use to measure and report the performance
   characteristics of network devices.  This will provide the user
   comparable data from different vendors with which to evaluate these
   devices.
   �x���_�[�����΂��Δނ�̃v���_�N�g�̎s��ɂ���������Ɨǂ��|�W�V����
   ��^���鎎�݂Łu�X�y�b�N�}���V�b�v�v�ɏ]�����܂��B����̓��[�U�[����
   �������邽�߂ɂ��΂��΁u�������v�𔺂��܂��B���̃����ƃt�H���[�A�b�v
   �����͓���̗p��ƃx���_�[�����肵�l�b�g���[�N���u�̐��\������񍐂�
   �邽�߂Ɏg�����Ƃ��ł���e�X�g���`���悤�Ǝ��݂܂��B����́A�����
   �̑��u��]������قȂ�x���_�[���烆�[�U�[�ɗގ��̃f�[�^��p�ӂ����
   ���傤�B
 

2.  Definition format
2.  ��`�t�H�[�}�b�g

        Term to be defined. (e.g., Latency)
        ��`����p��i�Ⴆ�΁A�������ԁj

        Definition:
        ��`�F
                The specific definition for the term.
                �p��̓���̒�`

        Discussion:
        �c�_�F
                A brief discussion about the term, it's application
                and any restrictions on measurement procedures.
                �p��ɂ‚��Ă̒Z���_�c�A���̃A�v���P�[�V�����Ƒ����
                ���̐����B

        Measurement units:
        ����P�ʁF
                The units used to report measurements of this
                term, if applicable.
                �����K�p�”\�Ȃ�A���̗p��̑���̕񍐂Ŏg���P�ʁB

        Issues:
        ���ځF
                List of issues or conditions that effect this term.
                ���̗p��������炷�������邢�͏�Ԃ̃��X�g�B

        See Also:
        �Q�ƁF
                List of other terms that are relevant to the discussion
                of this term.
                ���̗p��̘_�c�Ɋ֌W�����鑼�̗p��̃��X�g�B

3.  Term definitions
3.  �p���`

3.1  Back-to-back
3.1  �A��

        Definition:
        ��`�F
                Fixed length frames presented at a rate such that there
                is the minimum legal separation for a given medium
                between frames over a short to medium period of time,
                starting from an idle state.
                �A�C�h����Ԃ���n�܂�A�r���͏���̃��f�B�A�̐������Z��
                �ŏ��t���[���Ԋu�ɂȂ郌�[�g�Ō����Œ蒷�t���[���B

        Discussion:
        �_�c�F
                A growing number of devices on a network can produce
                bursts of back-to-back frames.  Remote disk servers
                using protocols like NFS, remote disk backup systems
                like rdump, and remote tape access systems can be
                configured such that a single request can result in
                a block of data being returned of as much as 64K octets.
                Over networks like ethernet with a relatively small MTU
                this results in many fragments to be transmitted.  Since
                fragment reassembly will only be attempted if all
                fragments have been received, the loss of even one
                fragment because of the failure of some intermediate
                network device to process enough continuous frames can
                cause an endless loop as the sender repetitively
                attempts to send its large data block.
                �l�b�g���[�N�̏�̑����̑��u���A�������o�[�X�g�t���[����
                �����N�������Ƃ��ł��܂��B�m�e�r�̗l�ȉ��u�f�B�X�N�T�[�o�[
                �ƁArdump�̂悤�ȉ��u�f�B�X�N�o�b�N�A�b�v�V�X�e���ƁA��
                �u�e�[�v�A�N�Z�X�V�X�e���́A�e�v���ɂ��U�S�j�I�N�e�b�g
                �̃f�[�^�̃u���b�N��Ԃ����\����ݒ�ł��܂��B�C�[�T�l�b
                �g�̂悤�Ȕ�r�I�l�s�t�̏������l�b�g���[�N��ŁA����͑�
                ���̕����p�P�b�g�������炵�܂��B�����p�P�b�g�̑g�ݗ��ẮA
                ���ׂĂ̕����p�P�b�g����M�����ꍇ�ɂ������݂��邾�낤
                ����A�A���t���[�����������邢���ꂩ�̒��ԃl�b�g���[�N��
                �u�̎��s�ɂ�蕪���p�P�b�g�̂P�‚̑����́A���M�҂��J���
                �����̑傫���f�[�^�u���b�N�𑗂낤�Ǝ��݂鎞�ɁA�ʂĂ���
                �����[�v���N�������Ƃ��ł��܂��B

                With the increasing size of the Internet, routing
                updates can span many frames, with modern routers able
                to transmit very quickly.  Missing frames of routing
                information can produce false indications of
                unreachability.  Tests of this parameter are intended
                to determine the extent of data buffering in the
                device.
                �C���^�[�l�b�g�T�C�Y�̑����́A���ɑ����M���𑗂邱��
                ���”\�ȋߑ�I�ȃ��[�^�[�ɂ��A���[�e�B���O�X�V�ő���
                �̃t���[���𔭐������܂��B���[�e�B���O���̌����Ă���
                �t���[���͋U��̐ؒf���\���������N�������Ƃ��ł��܂��B
                ���̃p�����[�^�̃e�X�g�͑��u���o�b�t�@�ɓ���邱�Ƃ̂�
                ����f�[�^�̒��x�����肷��悤�ɈӐ}����܂��B

        Measurement units:
        ����P�ʁF
                Number of N-octet frames in burst.
                �A�������m�I�N�e�b�g�t���[���̐��B

        Issues:
        ���ځF

        See Also:
        �Q�ƁF


3.2  Bridge
3.2  �u���b�W

        Definition:
        ��`�F
                A system which forwards data frames based on information
                in the data link layer.
                �f�[�^�����N���C�����Ɋ�Â��ăf�[�^�t���[���]��������
                ���V�X�e���B

        Discussion:
        �c�_�F

        Measurement units:
        ����P�ʁF
                n/a

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                bridge/router (3.3)
                router (3.15)

3.3  bridge/router
3.3  �u���b�W/���[�^

        Definition:
        ��`�F
                A bridge/router is a network device that can selectively
                function as a router and/or a bridge based on the
                protocol of a specific frame.
                �u���b�W�^���[�^�[�́A�t���[���̃v���g�R���Ɋ�Â��đI��
                �I�Ƀ��[�^���邢�̓u���b�W�Ƃ��ē���ł���l�b�g���[�N��
                �u�ł��B

        Discussion:
        �c�_�F

        Measurement units:
        ����P�ʁF
                n/a

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                bridge (3.2)
                router (3.15)

3.4  Constant Load
3.4  ��蕉��

        Definition:
        ��`�F
                Fixed length frames at a fixed interval time.
                �Œ�Ԋu�̌Œ蒷�t���[���B

        Discussion:
        �c�_�F
                Although it is rare, to say the least, to encounter
                a steady state load on a network device in the real
                world, measurement of steady state performance may
                be useful in evaluating competing devices.  The
                frame size is specified and constant.  All device
                parameters are constant.  When there is a checksum
                in the frame, it must be verified.
                �T���߂Ɍ����Ă��A�����E�Ńl�b�g���[�N���u��Ɉ���Ԃ�
                ���ׂ������邱�Ƃ͂܂�ł��邯��ǂ��A����Ԃ̔\�͂̑�
                ��͋������Ă��鑕�u��]������ۂɗL�p�ł��邩������܂�
                ��B�t���[���T�C�Y�͎w�肳��A�����Ĉ��ł��B���ׂĂ̑�
                �u�p�����[�^�͈��ł��B�t���[���Ƀ`�F�b�N�T�������鎞�A
                ����͌��؂���Ȃ��Ă͂Ȃ�܂���B

        Measurement units:
        ����P�ʁF
                n/a

        Issues:
        ���ځF
                unidirectional vs. bidirectional
                ��������Αo������

        See Also:
        �Q�ƁF

3.5  Data link frame size
3.5  �f�[�^�����N�t���[���T�C�Y

        Definition:
        ��`�F
                The number of octets in the frame from the first octet
                following the preamble to the end of the FCS, if
                present, or to the last octet of the data if there
                is no FCS.
                �v���A���u���̌ォ��n�܂�A�����e�b�r�����݂��Ă����
                ��e�b�r�̏I���܂ŁA�����e�b�r���Ȃ���΃f�[�^�̍Ō�
                �̃I�N�e�b�g�܂ł́A�t���[���̃I�N�e�b�g���B

        Discussion:
        �c�_�F
                There is much confusion in reporting the frame
                sizes used in testing network devices or network
                measurement.  Some authors include the checksum,
                some do not.  This is a specific definition for use
                in this and subsequent memos.
                �e�X�g�l�b�g���[�N���u���邢�̓l�b�g���[�N����Ńt���[��
                �T�C�Y�̕񍐂ɂ�������̍���������܂��B���钘�҂��`�F�b
                �N�T�����܂݂܂��A������̂͂������܂���B����͂��̃���
                �ƁA���������̎g�p�ɓ��L�Ȓ�`�ł��B

        Measurement units:
        ����P�ʁF
                octets
                �I�N�e�b�g

        Issues:
        ���ځF

        See Also:
        �Q�ƁF

3.6  Frame Loss Rate
3.6  �t���[��������

        Definition:
        ��`�F
                Percentage of frames that should have been forwarded
                by a network device under steady state (constant)
                load that were not forwarded due to lack of
                resources.
                ����ԁi�萔�j���ׂ̉��Ńl�b�g���[�N���u�ɂ���ē]��
                �����ׂ��ł������������̌��@�̂��߂ɓ]������Ȃ�����
                �t���[���̃p�[�Z���e�[�W�B

        Discussion:
        �c�_�F
                This measurement can be used in reporting the
                performance of a network device in an overloaded
                state.  This can be a useful indication of how a
                device would perform under pathological network
                conditions such as broadcast storms.
                ���̑���͉ߕ��׏�ԂŃl�b�g���[�N���u�̔\�͂�񍐂���
                �ۂɎg�����Ƃ��ł��܂��B����̓u���[�h�L���X�g�X�g�[��
                �̂悤�Ȉُ�l�b�g���[�N�������ő��u���@�\������@�̗L
                �p�Ȏw�W�ł��B

        Measurement units:
        ����P�ʁF
                Percentage of N-octet offered frames that are dropped.
                To be reported as a graph of offered load vs frame loss.
                �m�I�N�e�b�g�����t���[������p�����ꂽ�p�[�Z���e�[�W�B
                �������ב΃t���[�������̃O���t�Ƃ��ĕ񍐂���邱�ƁB

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                overhead behavior (3.11)
                policy based filtering (3.13)
                MTU mismatch behavior (3.10)

3.7  Inter Frame Gap
3.7  �t���[���Ԋu

        Definition:
        ��`�F
                The delay from the end of a data link frame as defined
                in section 3.5, to the start of the preamble of the
                next data link frame.
                �R.�T�͂Œ�`���ꂽ�f�[�^�����N�t���[���̏I��肩��A��
                �̃f�[�^�����N�t���[���̃v���A���u���̊J�n�܂ł̒x��B

        Discussion:
        �c�_�F
                There is much confusion in reporting the between
                frame time used in testing network devices.  This
                is a specific definition for use in this and subsequent
                memos.
                �e�X�g����l�b�g���[�N���u�Ŏg���t���[�����Ԃł��������
                �񍐂̍���������܂��B����͂��̃����Ƒ��������Ŏg�p����
                �̂��߂̓��L�̒�`�ł��B

        Measurement units:
        ����P�ʁF
                Time with fine enough units to distinguish between
                2 events.
                �Q�‚̃C�x���g����ʂ���̂ɏ\���ȒP�ʎ��ԁB

        Issues:
        ���ځF
                Link data rate.
                �����N�f�[�^���[�g

        See Also:
        �Q�ƁF

3.8   Latency
3.8   ��������

        Definition:
        ��`�F
                For store and forward devices:
                The time interval starting when the last bit of the
                input frame reaches the input port and ending when
                the first bit of the output frame is seen on the
                output port.
                �X�g�A���t�H���[�h���u�ɑ΂��āF���̓t���[���̍Ō�̃r�b
                �g�����̓|�[�g�ɓ��B�������ԂɎn�܂�A�o�̓t���[���̍ŏ�
                �̃r�b�g���o�̓|�[�g�Ɍ���鎞�ɏI���A���ԊԊu�B

                For bit forwarding devices:
                The time interval starting when the end of the first
                bit of the input frame reaches the input port and
                ending when the start of the first bit of the output
                frame is seen on the output port.
                �r�b�g�]�����u�ɑ΂��āF���̓t���[���̍ŏ��̃r�b�g�̂��I
                ��肪���̓|�[�g�ɓ��B���Ă���A�o�̓t���[���̍ŏ��̃r�b
                �g���o�̓|�[�g�̏�Ɍ����܂ł́A���ԊԊu�B

        Discussion:
        �c�_�F
                Variability of latency can be a problem.
                Some protocols are timing dependent (e.g., LAT and IPX).
                Future applications are likely to be sensitive to
                network latency.  Increased device delay can reduce
                the useful diameter of net.  It is desired to
                eliminate the effect of the data rate on the latency
                measurement.  This measurement should only reflect the
                actual within device latency.  Measurements should be
                taken for a spectrum of frame sizes without changing
                the device setup.
                �������Ԃ̕ϓ��͖��ł��蓾�܂��B����v���g�R���̓^�C�~
                ���O�ˑ��ł��i�Ⴆ�΁A�k�`�s�Ƃh�o�w�j�B�����̃A�v���P�[
                �V�����̓l�b�g���[�N�������Ԃɕq���ł���”\���������ł��B
                ���u�x���̑����͖Ԃ̗L�p�Ȓ��a�����炵�܂��B�������ԑ���
                �ɑ΂���f�[�^���̌��ʂ�r�����邱�Ƃ͖]�܂�܂��B���̑�
                ��͂������u�������Ԃ̎��ۂ̂��̂𔽉f���邾���ł���ׂ�
                �ł��B���肪���u�ݒ��ς����Ƀt���[���T�C�Y��ς��čs��
                ���ׂ��ł��B

                Ideally, the measurements for all devices would be from
                the first actual bit of the frame after the preamble.
                Theoretically a vendor could design a device that
                normally would be considered a store and forward
                device, a bridge for example, that begins transmitting
                a frame before it is fully received.  This type of
                device is known as a "cut through" device.  The
                assumption is that the device would somehow invalidate
                the partially transmitted frame if in receiving the
                remainder of the input frame, something came up that
                the frame or this specific forwarding of it was in
                error.  For example, a bad checksum.  In this case,
                the device would still be considered a store and
                forward device and the latency would still be
                from last bit in to first bit out, even though the
                value would be negative.  The intent is to treat
                the device as a unit without regard to the internal
                structure.
                ���z�I�ɂ́A���ׂĂ̑��u�̂��߂̑���̓v���A���u���̌��
                �t���[���̂͂��߂̎��ۂ̃r�b�g�ł���ł��傤�B���_�I�Ƀx
                ���_�[���ʏ�̓X�g�A���t�H���[�h���u�A�Ⴆ�΃u���b�W�ł�
                �邪�A���S�Ɏ�M����O�ɁA�t���[����]�����n�߂鑕�u���
                �v���邱�Ƃ��ł��܂��B���̃^�C�v�̑��u�́u�J�b�g�X���[�v
                ���u�Ƃ��Ēm���Ă��܂��B����́A�������̓t���[���̎c��
                ����M���Ƀt���[�����邢�͓���̓]��������Ă����ꍇ�A��
                �u�͂ǂ��ɂ����ĕ����I�ɓ`�B���ꂽ�t���[���𖳌��ɂ����
                ���낤�Ƃ������Ƃł��B�Ⴆ�΁A�`�F�b�N�T�����ł��B����
                �ꍇ�A���u�͂܂��X�g�A���t�H���[�h���u�Ǝv���A�����Ĕ�
                �����Ԃ́A�l�����ɂȂ邾�낤���A�Ō�̃r�b�g�������Ă���A
                �ŏ��̃r�b�g���ł�܂ł̎��Ԃł��傤�B�Ӑ}�͓����̍\����
                �Ɋ֌W�Ȃ����u�����j�b�g�Ƃ��Ĉ������ł��B

        Measurement units:
        ����P�ʁF
                Time with fine enough units to distinguish between
                2 events.
                �Q�‚̃C�x���g����ʂ���̂ɏ\���ȒP�ʎ��ԁB

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                link speed mismatch (3.9)
                constant load (3.4)
                back-to-back (3.1)
                policy based filtering (3.13)
                single frame behavior (3.16)

3.9  Link Speed Mismatch
3.9  �����N���x�s��v

        Definition:
        ��`�F
                Speed mismatch between input and output data rates.
                ���͂Əo�̓f�[�^���̊Ԃ̃X�s�[�h�s�K���ȑg���킹�B

        Discussion:
        �c�_�F
                This does not refer to frame rate per se, it refers to
                the actual data rate of the data path.  For example,
                an Ethernet on one side and a 56KB serial link on the
                other.  This is has also been referred to as the "fire
                hose effect".  Networks that make use of serial links
                between local high speed networks will usually have
                link speed mismatch at each end of the serial links.
                ����͖{���I�Ƀt���[�������Q�Ƃ��܂���A����̓f�[�^�p
                �X�̎��ۂ̃f�[�^�����Q�Ƃ��܂��B�Ⴆ�΁A�Б��C�[�T�l�b
                �g�Ƒ����T�U�j�a�V���A�������N�ł��B����́u���΃z�[�X
                ���ʁv�Əq�ׂ��܂��B���[�J�������l�b�g���[�N�ԂɃV��
                �A�������N�𗘗p����l�b�g���[�N���ʏ킻�ꂼ��̃V���A
                �������N�̏I���ɂ����ă����N�X�s�[�h�̕s�K���ȑg����
                �������‚ł��傤�B

        Measurement units:
        ����P�ʁF
                Ratio of input and output data rates.
                ���͂Əo�̓f�[�^���̔䗦�B

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                constant load (3.4)
                back-to-back (3.1)

3.10  MTU-mismatch behavior
3.10  �l�s�t�s��v����


        Definition:
        ��`�F
                The network MTU (Maximum Transmission Unit) of the
                output network is smaller than the MTU of the input
                network, this results in fragmentation.
                �o�̓l�b�g���[�N�̃l�b�g���[�N�l�s�t�i�ő呗�M�P�ʁj��
                ���̓l�b�g���[�N�̂l�s�t��菬�������A�p�P�b�g��������
                ���炵�܂��B

        Discussion:
        �c�_�F
                The performance of network devices can be significantly
                affected by having to fragment frames.
                �l�b�g���[�N���u�̔\�͂̓t���[�����������Ȃ���΂Ȃ��
                �����Ƃɂ���čۗ��‰e�����^�����邱�Ƃ�����܂��B

        Measurement units:
        ����P�ʁF
                Description of behavior.
                �s���̋L�q�B

        Issues:
        ���ځF

        See Also:
        �Q�ƁF

3.11  Overhead behavior
3.11  �I�[�o�[�w�b�h����

        Definition:
        ��`�F
                Processing done other than that for normal data frames.
                �W���I�ȃf�[�^�t���[���ȊO�ɂ��ꂽ�����B

        Discussion:
        �c�_�F
                Network devices perform many functions in addition
                to forwarding frames.  These tasks range from internal
                hardware testing to the processing of routing
                information and responding to network management
                requests.  It is useful to know what the effect of
                these sorts of tasks is on the device performance.
                An example would be if a router were to suspend
                forwarding or accepting frames during the processing
                of large routing update for a complex protocol like
                OSPF.  It would be good to know of this sort of
                behavior.
                �l�b�g���[�N���u���t���[���]���̂ق��ɑ����̋@�\���s��
                �܂��B�����̎d���͓����n�[�h�E�F�A�e�X�g����o�H���
                ������l�b�g���[�N�Ǘ��v���ւ̉����܂ŋy�т܂��B�����
                �̎�ނ̎d���̑��u���\�ւ̌��ʂ����ł��邩�m�邱�Ƃ͗L
                �p�ł��B�Ⴆ�΂n�r�o�e�̂悤�ȕ��G�ȃv���g�R���Ń��[�^�[
                ���傫�����[�e�B���O�X�V�̏����̊ԂɁA�t���[���]�����
                �M�����΂炭�����킹��ł��傤�B���̎�ނ̍s���ɂ‚���
                �m�邱�Ƃ͗ǂ��ł��傤�B

        Measurement units:
        ����P�ʁF
                Any quantitative understanding of this behavior is by
                the determination of its effect on other measurements.
                ���̍s���̗ʓI�ȗ����́A���̑���ɑ΂�����ʂ̌���ɂ�
                ��܂��B

        Issues:
        ���ځF
                bridging and routing protocols
                �u���b�W�ƃ��[�e�B���O�v���g�R��
                control processing
                ���䑕�u����
                icmp
                �h�b�l�o
                ip options processing
                �h�o�I�v�V��������
                fragmentation
                �p�P�b�g����
                error processing
                �G���[����
                event logging/statistics collection
                �C�x���g���O�^���v�l���W
                arp
                �`�q�o

        See Also:
        �Q�ƁF
                policy based filtering (3.13)

3.12  Overloaded behavior
3.12  �ߕ��ד���

        Definition:
        ��`�F
                When demand exceeds available system resources.
                ���v�����p�”\�ȃV�X�e�������𒴂��鎞�B

        Discussion:
        �c�_�F
                Devices in an overloaded state will lose frames.  The
                device might lose frames that contain routing or
                configuration information.  An overloaded state is
                assumed when there is any frame loss.
                �ߕ��׏�Ԃł̑��u���t���[���������ł��傤�B���u�̓��[
                �e�B���O��ݒ�����܂ރt���[����������������܂���B
                �ߕ��׏�Ԃ��A�t���[�����������鎞�A���肳��܂��B

        Measurement units:
        ����P�ʁF
                Description of behavior of device in any overloaded
                states for both input and output overload conditions.
                ���͉ߑ��Əo�͉ߑ��̗������ʼnߕ��׏�Ԃł̑��u�̍s����
                �L�q�B

        Issues:
        ���ځF
                How well does the device recover from overloaded state?
                �ǂ�قǏ��ɑ��u�͉ߕ��׏�Ԃ���񕜂��܂����H
                How does source quench production effect device?
                �ǂ̂悤�ɏ�񌹂����Y�e�����u����߂܂����H
                What does device do when its resources are exhausted?
                ���u�͎������g���s������Ă��鎞�������܂����H
                What is response to system management in overloaded
                state?
                �ߕ��׏�ԂŃV�X�e���Ǘ��ɑ΂��鉞���͉����H�B

        See Also:
        �Q�ƁF

3.13  Policy based filtering
3.13  �|���V�[�x�[�X�t�B���^

        Definition:
        ��`�F
                Filtering is the process of discarding received
                frames by administrative decision where normal
                operation would be to forward them.
                �t�B���^�͕W���I�y���[�V�����ł͓]������ł��낤��M�t���[
                �����Ǘ���̌���Ŕj�����鏈���ł��B

        Discussion:
        �c�_�F
                Many network devices have the ability to be
                configured to discard frames based on a number
                of criteria.  These criteria can range from simple
                source or destination addresses to examining
                specific fields in the data frame itself.
                Configuring many network devices to perform
                filtering operations impacts the throughput
                of the device.
                �����̃l�b�g���[�N���u�������̊�Ɋ�Â��ăt���[������
                �Ă�ݒ肪�ł���\�͂������܂��B�����̊�̓f�[�^�t���[
                ���̒P���ȃ\�[�X�∶��A�h���X�������̃t�B�[���h�̒���
                �ɂ܂ŋy�т܂��B�����̃l�b�g���[�N���u�Ńt�B���^�[�����s
                ����ݒ�����邱�Ƃ͑��u�̃X���[�v�b�g�ɉe����^���܂��B

        Measurement units:
        ����P�ʁF
                n/a

        Issues:
        ���ځF
                flexibility of filter options
                �t�B���^�[�I�v�V�����̏_�
                number of filter conditions
                �t�B���^�[��Ԃ̐�

        See Also:
        �Q�ƁF

3.14  Restart behavior
3.14  �ċN������

        Definition:
        ��`�F
                Reinitialization of system causing data loss.
                �f�[�^�������N�����Ă���V�X�e���̍ď������B

        Discussion:
        �c�_�F
                During a period of time after a power up or
                reset, network devices do not accept and forward
                frames.  The duration of this period of unavailability
                can be useful in evaluating devices.  In addition,
                some network devices require some form of reset
                when specific setup variables are modified.  If the
                reset period were long it might discourage network
                managers from modifying these variables on production
                networks.
                �d���I�������Z�b�g��̈��̎����A���u�͓]���t���[������
                ������܂���B���̕s�������Ԃ̎������Ԃ͑��u��]�������
                �ɗL�p�ł��蓾�܂��B�����āA����l�b�g���[�N���u�������
                �ݒ�ϐ���ύX�����ۂɂ����̃��Z�b�g��K�v�Ƃ��܂��B��
                �����Z�b�g���Ԃ�������΁A�l�b�g���[�N�Ǘ��҂��^�p�l�b�g
                ���[�N��ł����̕ϐ����C�����邱�Ƃ��v���Ƃǂ܂点�邩
                ������܂���B

        Measurement units:
        ����P�ʁF
                Description of device behavior under various restart
                conditions.
                �l�X�ȍĊJ�������ł̑��u����̋L�q�B

        Issues:
        ���ځF
                Types:
                ��ށF
                        power on
                        �d���I��
                        reload software image
                        �\�t�g�E�F�A�C���[�W����[�h
                        flush port, reset buffers
                        �|�[�g�N���A�A�o�b�t�@���Z�b�g
                        restart current code image, without reconfuration
                        �Đݒ�Ȃ��ŁA���݂̃R�[�h�C���[�W���ĊJ
                Under what conditions is a restart required?
                ���̏�ԉ��ōċN�����K�v���H
                Does the device know when restart needed (i.e., hung
                        state timeout)?
                ���u�͂��ċN�����K�v���m���Ă����i���Ȃ킿�A����s�\��
                        �ԃ^�C���A�E�g�j�H
                Does the device recognize condition of too frequent
                        auto-restart?
                ���u�͂��܂�ɂ��p�ɂɂ����鎩���ċN����Ԃ�F�����܂����H
                Does the device run diagnostics on all or some resets?
                ���ׂĂ������͂����‚��̃��Z�b�g�ŁA���u�͐f�f�����܂����H
                How may restart be initiated?
                �����ɍċN�����n�߂܂����H
                        physical intervention
                        �����I���
                        remote via terminal line or login over network
                        �[��������l�b�g���[�N��̃��O�C���ɂ�鉓�u

        See Also:
        �Q�ƁF

3.15  Router
3.15  ���[�^

        Definition:
        ��`�F
                A system which forwards data frames based on
                information in the network layer.
                �f�[�^�t���[���]�����l�b�g���[�N�w���Ɋ�Â��V�X�e���B

        Discussion:
        �c�_�F
                This implies "running" the network level protocol
                routing algorithm and performing whatever actions
                that the protocol requires.  For example, decrementing
                the TTL field in the TCP/IP header.
                ����̓l�b�g���[�N���x���v���g�R�����[�e�B���O�A���S��
                �Y�����u���s�v���A�����ăv���g�R�����K�v�Ƃ���s������
                �s����\�͂��Î����܂��B�Ⴆ�΁A�s�b�o�^�h�o�w�b�_�̂s
                �s�k�t�B�[���h�����������܂��B

        Measurement units:
        ����P�ʁF
                n/a

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                bridge (3.2)
                bridge/router (3.3)

3.16  Single frame behavior
3.16  �P��t���[������

        Definition:
        ��`�F
                One frame received on the input to a device.
                ���u�̓��͂ɂP�t���[���̎�M�B

        Discussion:
        �c�_�F
                A data "stream" consisting of a single frame can
                require a network device to do a lot of processing.
                Figuring routes, performing ARPs, checking
                permissions etc., in general, setting up cache entries.
                Devices will often take much more time to process a
                single frame presented in isolation than it would if
                the same frame were part of a steady stream.  There
                is a worry that some devices would even discard a single
                frame as part of the cache setup procedure under the
                assumption that the frame is only the first of many.
                �ЂƂ‚̃t���[�����琬�藧�ƒf�[�^�́u����v�̓l�b�g���[
                �N���u�ɑ����̏�����K�v�Ƃ��邱�Ƃ�����܂��B�o�H���v�Z
                ���A�`�q�o���s���A���‚���������ȂǁA��ʂɁA�L���b�V��
                ���ڂ�g�ݗ��Ă܂��B���u�͂��΂��ΌǗ��t���[���̏����ɁA
                �t���[�������̗���̈ꕔ�̏ꍇ�K�v�Ȃ̂��A�����Ƒ���
                �̏��������܂��B�t���[���������̃t���[���̍ŏ��̂P�‚ɉ�
                ���Ȃ��Ƃ������艺�ŁA���鑕�u���ЂƂ‚̃t���[�����L���b
                �V���ݒ�菇�̈ꕔ�Ƃ��Ď̂Ă�S�z������܂��B

        Measurement units:
        ����P�ʁF
                Description of the behavior of the device.
                ���u����̋L�q�B

        Issues:
        ���ځF

        See Also:
        �Q�ƁF
                policy based filtering (3.13)

3.17  Throughput
3.17  �X���[�v�b�g

        Definition:
        ��`�F
                The maximum rate at which none of the offered frames
                are dropped by the device.
                �����t���[���̂���������u�Ɏ̂Ă��Ȃ��ő嗦�B

        Discussion:
        �c�_�F
                The throughput figure allows vendors to report a
                single value which has proven to have use in the
                marketplace.  Since even the loss of one frame in a
                data stream can cause significant delays while
                waiting for the higher level protocols to time out,
                it is useful to know the actual maximum data
                rate that the device can support.  Measurements should
                be taken over a assortment of frame sizes.  Separate
                measurements for routed and bridged data in those
                devices that can support both.  If there is a checksum
                in the received frame, full checksum processing must
                be done.
                �X���[�v�b�g�̐����̓x���_�[�Ɏs��Ŏg�p�ł���ЂƂ‚̒l
                ��񍐂��邱�Ƃ������܂��B�f�[�^���̂P�‚̃t���[���̑���
                �́A��ʃ��x���v���g�R�����^�C���A�E�g����̂�҂‚��߂ɁA
                �傫�Ȓx����N�����̂ŁA���u���T�|�[�g�ł�����ۂ̍ő��
                �f�[�^����m�邱�Ƃ͗L�p�ł��B���肪�t���[���T�C�Y�̗l�X
                �ȑg�ݍ��킹�̏�ōs����ׂ��ł��B���[�^�[�ƃu���b�W��
                �������T�|�[�g���鑕�u�ŁA���[�^�ƃu���b�W��؂藣���܂��B
                ������M�t���[���Ƀ`�F�b�N�T��������Ȃ�A���S�ȃ`�F�b�N
                �T������������Ȃ��Ă͂Ȃ�܂���B

        Measurement units:
        ����P�ʁF
                N-octet input frames per second
                �b���̂m�I�N�e�b�g���̓t���[��
                input bits per second
                �b���̓��̓r�b�g

        Issues:
        ���ځF
                single path vs. aggregate
                �P��p�X�ΏW��p�X
                load
                ����
                unidirectional vs bidirectional
                ��������Αo������
                checksum processing required on some protocols
                ����v���g�R���ŕK�v�ȃ`�F�b�N�T������

        See Also:
        �Q�ƁF
                frame loss rate (3.6)
                constant load (3.4)
                back-to-back (3.1)


4.  Acknowledgements
4.  �ӎ�

   This memo is a product of the IETF BMWG working group:
   ���̃����͂h�d�s�e �a�l�v�f���[�L���O�O���[�v�̌��ʂł��F

        Chet Birger, Coral Networks
        Scott Bradner, Harvard University (chair)
        Steve Butterfield, independant consultant
        Frank Chui, TRW
        Phill Gross, CNRI
        Stev Knowles, FTP Software, Inc.
        Mat Lew, TRW
        Gary Malkin, FTP Software, Inc.
        K.K. Ramakrishnan, Digital Equipment Corp.
        Mick Scully, Ungerman Bass
        William M. Seifert, Wellfleet Communications Corp.
        John Shriver, Proteon, Inc.
        Dick Sterry, Microcom
        Geof Stone, Network Systems Corp.
        Geoff Thompson, SynOptics
        Mary Youssef, IBM

Security Considerations
�Z�L�����e�B�̍l�@

   Security issues are not discussed in this memo.
   ���̃����ŃZ�L�����e�B���͋c�_����܂���B

Author's Address
���҂̃A�h���X

   Scott Bradner
   Harvard University
   William James Hall 1232
   33 Kirkland Street
   Cambridge, MA 02138

   Phone: (617) 495-3864

   EMail: [email protected]
   Or, send comments to: [email protected].

Japanese translation by Ishida So