英文文献科技类原文及翻译1

英文文献科技类原文及翻译1

On the deployment of V oIP in Ethernet networks:

methodology and case study

Abstract

Deploying IP telephony or voice over IP (V oIP) is a major and challenging task for data network researchers and designers. This paper outlines guidelines and a step-by-step methodology on how V oIP can be deployed successfully. The methodology can be used to assess the support and readiness of an existing network. Prior to the purchase and deployment of V oIP equipment, the methodology predicts the number of V oIP calls that can be sustained by an existing network while satisfying QoS requirements of all network services and leaving adequate capacity for future growth. As a case study, we apply the methodology steps on a typical network of a small enterprise. We utilize both analysis and simulation to investigate throughput and delay bounds. Our analysis is based on queuing theory, and OPNET is used for simulation. Results obtained from analysis and simulation are in line and give a close match. In addition, the paper discusses many design and engineering issues. These issues include characteristics of V oIP traffic and QoS requirements, V oIP flow and call distribution, defining future growth capacity, and measurement and impact of background traffic. Keywords: Network Design，Network Management，V oIP，Performance Evaluation，

Analysis，Simulation，OPNET

1 Introduction

These days a massive deployment of V oIP is taking place over data networks. Most of these networks are Ethernet based and running IP protocol. Many network managers are finding it very attractive and cost effective to merge and unify voice and data networks into one. It is easier to run, manage, and maintain. However, one has to keep in mind that IP networks are best-effort networks that were designed for non-real time applications. On the other hand, V oIP requires timely packet delivery with low latency, jitter, packet loss, and

sufficient bandwidth. To achieve this goal, an efficient deployment of V oIP must ensure these real-time traffic requirements can be guaranteed over new or existing IP networks. When deploying a new network service such as V oIP over existing network, many network architects, managers, planners, designers, and engineers are faced with common strategic, and sometimes challenging, questions. What are the QoS requirements for V oIP? How will the new V oIP load impact the QoS for currently running network services and applications? Will my existing network support V oIP and satisfy the standardized QoS requirements? If so, how many V oIP calls can the network support before upgrading prematurely any part of the existing network hardware? These challenging questions have led to the development of some commercial tools for testing the performance of multimedia applications in data networks. A list of the available commercial tools that support V oIP is listed in [1,2]. For the most part, these tools use two common approaches in assessing the deployment of V oIP into the existing network. One approach is based on first performing network measurements and then predicting the network readiness for supporting V oIP. The prediction of the network readiness is based on assessing the health of network elements. The second approach is based on injecting real V oIP traffic into existing network and measuring the resulting delay, jitter, and loss. Other than the cost associated with the commercial tools, none of the commercial tools offer a comprehensive approach for successful V oIP deployment. I n particular, none gives any prediction for the total number of calls that can be supported by the network taking into account important design and engineering factors. These factors include V oIP flow and call distribution, future growth capacity, performance thresholds, impact of V oIP on existing network services and applications, and impact background traffic on V oIP. This paper attempts to address those important factors and layout a comprehensive methodology for a successful deployment of any multimedia application such as V oIP and video conferencing. However, the paper focuses on V oIP as the new service of interest to be deployed. The paper also contains many useful engineering and design guidelines, and discusses many practical issues pertaining to the deployment of V oIP. These issues include characteristics of V oIP traffic and QoS requirements, V oIP flow and call distribution, defining future growth capacity, and measurement and impact of background traffic. As a case study, we illustrate how our

approach and guidelines can be applied to a typical network of a small enterprise. The rest of the paper is organized as follows. Section 2 presents a typical network topology of a small enterprise to be used as a case study for deploying V oIP. Section 3 outlines practical eight-step methodology to deploy successfully V oIP in data networks. Each step is described in considerable detail. Section 4 describes important design and engineering decisions to be made based on the analytic and simulation studies. Section 5 concludes the study and identifies future work.

2 Existing network

3 Step-by-step methodology

Fig. 2 shows a flowchart of a methodology of eight steps for a successful V oIP deployment. The first four steps are independent and can be performed in parallel. Before embarking on the analysis and simulation study, in Steps 6 and 7, Step 5 must be carried out which requires any early and necessary redimensioning or modifications to the existing network. As shown, both Steps 6 and 7 can be done in parallel. The final step is pilot deployment.

3.1. VoIP traffic characteristics, requirements, and assumptions

For introducing a new network service such as V oIP, one has to characterize first the nature of its traffic, QoS requirements, and any additional components or devices. For simplicity, we assume a point-to-point conversation for all V oIP calls with no call conferencing. For deploying V oIP, a gatekeeper or Call Manager node has to be added to the network [3,4,5]. The gatekeeper node handles signaling for establishing, terminating, and authorizing connections of all V oIP calls. Also a V oIP gateway is required to handle external calls. A V oIP gateway is responsible for converting V oIP calls to/from the Public Switched Telephone Network (PSTN). As an engineering and design issue, the placement of these nodes in the network becomes crucial. We will tackle this issue in design step 5. Other

hardware requirements include a V oIP client terminal, which can be a separate V oIP device, i.e. IP phones, or a typical PC or workstation that is V oIP-enabled. A V oIP-enabled workstation runs V oIP software such as IP Soft Phones .

Fig. 3 identifies the end-to-end V oIP components from sender to receiver [9]. The first component is the encoder which periodically samples the original voice signal and assigns a fixed number of bits to each sample, creating a constant bit rate stream. The traditional sample-based encoder G.711 uses Pulse Code Modulation (PCM) to generate 8-bit samples every 0.125 ms, leading to a data rate of 64 kbps . The packetizer follows the encoder and encapsulates a certain number of speech samples into packets and adds the RTP, UDP, IP, and Ethernet headers. The voice packets travel through the data network. An important component at the receiving end, is the playback buffer whose purpose is to absorb variations or jitter in delay and provide a smooth playout. Then packets are delivered to the depacketizer and eventually to the decoder which reconstructs the original voice signal. We will follow the widely adopted recommendations of H.323, G.711, and G.714 standards for V oIP QoS requirements.

Table 1 compares some commonly used ITU-T standard codecs and the amount of

one-way delay that they impose. To account for upper limits and to meet desirable quality requirement according to ITU recommendation P.800, we will adopt G.711u codec standards for the required delay and bandwidth. G.711u yields around 4.4 MOS rating. MOS, Mean Opinion Score, is a commonly used V oIP performance metric given in a scale of 1–5, with 5 is the best. However, with little compromise to quality, it is possible to implement different ITU-T codecs that yield much less required bandwidth per call and relatively a bit higher, but acceptable, end-to-end delay. This can be accomplished by applying compression, silence suppression, packet loss concealment, queue management techniques, and encapsulating more than one voice packet into a single Ethernet frame.

3.1.1. End-to-end delay for a single voice packet

Fig. 3 illustrates the sources of delay for a typical voice packet. The end-to-end delay is sometimes referred to by M2E or Mouth-to-Ear delay. G.714 imposes a maximum total one-way packet delay of 150 ms end-to-end for V oIP applications . In [22], a delay of up to 200 ms was considered to be acceptable. We can break this delay down into at least three different contributing components, which are as follows (i) encoding, compression, and packetization delay at the sender (ii) propagation, transmission and queuing delay in the network and (iii) buffering, decompression, depacketization, decoding, and playback delay at the receiver.

3.1.2. Bandwidth for a single call

The required bandwidth for a single call, one direction, is 64 kbps. G.711 codec samples 20 ms of voice per packet. Therefore, 50 such packets need to be transmitted per second. Each packet contains 160 voice samples in order to give 8000 samples per second. Each packet is sent in one Ethernet frame. With every packet of size 160 bytes, headers of additional protocol layers are added. These headers include RTP+UDP+IP+Ethernet with preamble of sizes 12+8+20+26, respectively. Therefore, a total of 226 bytes, or 1808 bits, needs to be transmitted 50 times per second, or 90.4 kbps, in one direction. For both directions, the required bandwidth for a single call is 100 pps or 180.8 kbps assuming a symmetric flow.

3.1.3. Other assumptions

Throughout our analysis and work, we assume voice calls are symmetric and no voice conferencing is implemented. We also ignore the signaling traffic generated by the gatekeeper. We base our analysis and design on the worst-case scenario for V oIP call traffic. The signaling traffic involving the gatekeeper is mostly generated prior to the establishment of the voice call and when the call is finished. This traffic is relatively small compared to the actual voice call traffic. In general, the gatekeeper generates no or very limited signaling traffic throughout the duration of the V oIP call for an already established on-going call. In this paper, we will implement no QoS mechanisms that can enhance the quality of packet delivery in IP networks.

A myriad of QoS standards are available and can be enabled for network elements. QoS standards may i nclude IEEE 802.1p/Q, the IETF’s RSVP, and DiffServ.Analysis of implementation cost, complexity, management, and benefit must be weighed carefully before adopting such QoS standards. These standards can be recommended when the cost for upgrading some network elements is high and the network resources are scarce and heavily loaded.

3.2. VoIP traffic flow and call distribution

Knowing the current telephone call usage or volume of the enterprise is an important step for a successful V oIP deployment. Before embarking on further analysis or planning phases for a V oIP deployment, collecting statistics about of the present call volume and profiles is essential. Sources of such information are organization’s PBX, telephone records and bills. Key characteristics of existing calls can include the number of calls, number of concurrent calls, time, duration, etc. It is important to determine the locations of the call endpoints, i.e. the sources and destinations, as well as their corresponding path or flow. This will aid in identifying the call distribution and the calls made internally or externally. Call distribution must include percentage of calls within and outside of a floor, building, department, or organization. As a good capacity planning measure, it is recommended to base the V oIP call distribution on the busy hour traffic of phone calls for the busiest day of a week or a month. This will ensure support of the calls at all times with high QoS for all V oIP calls.

When such current statistics are combined with the projected extra calls, we can predict the worst-case V oIP traffic load to be introduced to the existing network.

Fig. 4 describes the call distribution for the enterprise under study based on the worst busy hour and the projected future growth of V oIP calls. In the figure, the call distribution is described as a probability tree. It is also possible to describe it as a probability matrix. Some important observations can be made about the voice traffic flow for inter-floor and external calls. For all these type of calls, the voice traffic has to be always routed through the router. This is so because Switchs 1 and 2 are layer 2 switches with VLANs configuration. One can observe that the traffic flow for inter-floor calls between Floors 1 and 2 imposes twice the load on Switch 1, as the traffic has to pass through the switch to the router and back to the switch again. Similarly, Switch 2 experiences twice the load for external calls from/to Floor 3.

3.3. Define performance thresholds and growth capacity

In this step, we define the network performance thresholds or operational points for a number of important key network elements. These thresholds are to be considered when deploying the new service. The benefit is twofold. First, the requirements of the new service to be deployed are satisfied. Second, adding the new service leaves the network healthy and susceptible to future growth. Two important performance criteria are to be taken into account.

First is the maximum tolerable end-to-end delay; and second is the utilization bounds or thresholds of network resources. The maximum tolerable end-to-end delay is determined by the most sensitive application to run on the network. In our case, it is 150 ms end-to-end for V oIP. It is imperative to note that if the network has certain delay sensitive applications, the delay for these applications should be monitored, when introducing V oIP traffic, such that they do not exceed their required maximum values. As for the utilization bounds for network resources, such bounds or thresholds are determined by factors such as current utilization, future plans, and foreseen growth of the network. Proper resource and capacity planning is crucial. Savvy network engineers must deploy new services with scalability in mind, and ascertain that the network will yield acceptable performance under heavy and peak loads, with no packet loss. V oIP requires almost no packet loss. In literature, 0.1–5% packet loss was generally asserted. However, in [24] the required V oIP packet loss was conservatively suggested to be less than 105 . A more practical packet loss, based on experimentation, of below 1% was required in [22]. Hence, it is extremely important not to utilize fully the network resources. As rule-of-thumb guideline for switched fast full-duplex Ethernet, the average utilization limit of links should be 190%, and for switched shared fast Ethernet, the average limit of links should be 85% [25]. The projected growth in users, network services, business, etc. must be all taken into consideration to extrapolate the required growth capacity or the future growth factor. In our study, we will ascertain that 25% of the available network capacity is reserved for future growth and expansion. For simplicity, we will apply this evenly to all network resources of the router, switches, and switched-Ethernet links. However, keep in mind this percentage in practice can be variable for each network resource and may depend on the current utilization and the required growth capacity. In our methodology, the reservation of this utilization of network resources is done upfront, before deploying the new service, and only the left-over capacity is used for investigating the network support of the new service to be deployed.

3.4. Perform network measurements

In order to characterize the existing network traffic load, utilization, and flow, network

measurements have to be performed. This is a crucial step as it can potentially affect results to be used in analytical study and simulation. There are a number of tools available commercially and noncommercially to perform network measurements. Popular open-source measurement tools include MRTG, STG, SNMPUtil, and GetIF [26]. A few examples of popular commercially measurement tools include HP OpenView, Cisco Netflow, Lucent VitalSuite, Patrol DashBoard, Omegon NetAlly, Avaya ExamiNet, NetIQ Vivinet Assessor, etc. Network measurements must be performed for network elements such as routers, switches, and links. Numerous types of measurements and statistics can be obtained using measurement tools. As a minimum, traffic rates in bits per second (bps) and packets per second (pps) must be measured for links directly connected to routers and switches. To get adequate assessment, network measurements have to be taken over a long period of time, at least 24-h period. Sometimes it is desirable to take measurements over several days or a week. One has to consider the worst-case scenario for network load or utilization in order to ensure good QoS at all times including peak hours. The peak hour is different from one network to another and it depends totally on the nature of business and the services provided by the network.

Table 2 shows a summary of peak-hour utilization for traffic of links in both directions connected to the router and the two switches of the network topology of Fig. 1. These measured results will be used in our analysis and simulation study.

外文文献译文

以太网网络电话传送调度：方法论与案例分析

摘要

对网络数据研究者与设计师来说，IP电话或者语音IP电话调度是一项重大而艰巨的任务。本文概述的准则与循序渐进的方法，解释了如何在IP上成功调度传送语音。该方法可用于评估的支持，并准备用在现有的网络。此前购买并部署的网络电话设备，这种方法预算出了在保证现有网络服务质量要求与日后足够扩充能力基础上的网络电话调用次数。作为一个研究的课题，我们把这种方法在一个典型的小型企业网上得到逐步应用。我们运用分析与模拟吞吐量与延迟区域。我们的分析基于排队理论，同时OPNET 用于模拟。理论分析与模拟结构比较一致。此外，本文谈论了许多设计与工程问题。这些问题包含网络电话通信的特征与服务质量要求，网络电话流程与呼叫分配，定义未来增长容量，测定后台通信的影响。

关键词：网络设计，网络管理，V oIP，性能评估，分析，模拟，OPNET

绪论

最近大量的网络电话调度在数据网中占有相当的比例。其中大部分基于以太网与运行IP协议。很多网络管理员发现把语音与数据网合二为一非常有吸引力与具成本效应。这将更易于运行、管理与保护。然而，人们应该认识到IP网络目的是为了非实时应用服务；另一方面，网络电话要求带有低延迟、低抖动、低丢包率与充足的带宽。为了达到这一目标，务必保证在现有或者新的IP网络中完成实时通信要求的高效网络电话调度。当在现有的网络部署譬如VoIP这样的新网络服务，许多网络架构师、经理、计划师、设计师与工程师面临着共同的目标与挑战。什么是网络电话的服务质量要求？新的网络电话负荷如何冲击了当今运行中的网络服务与应用的质量？我们现有的网络将支持网络电话与将满足标准的服务质量要求吗？假如那样，在过早升级任何现有的网络硬件的零件前，能支持多少个的VoIP电话网络？这些富挑战性的问题导致了用于测试网络多媒体数据应用性能的商业工具的进展。支持网络电话的商用工具名单如表[1,2]。很大程度上，这些工具使用两种共同的方法把VoIP 部署入现有的网络。一种方法根据第一次执行的网络测量与然后预测支持VoIP的网络应该就绪情况。预测的网络情况是根据网络要素来估计的。第二种是根据加入到现有网络中VoIP的实时通信信息，然后测出延时时间、时基误差与丢包率。除有关的商业工具费用外，没有其它工具能够提供全面兼容的成功网络电话调度方法。特别是，无任何一个预测能给出网络能够支持的呼叫次数已提到设计与工程的议事日程上来。这些因素包含网络电话流程与呼叫分配、今后增长容量、性能极限、VoIP对现有网络服务与应用与后台通信能力的冲击。本文尝试研究这些重要因素，规划出一个支持像网络电话与视频会议系统的全面可行方法。

不管如何，本文集中论述了网络电话服务调度新方法。文章同样包含了许多工程与设计指南，同时也讨论了许多与网络电话有关的实际问题。这些问题包含网络电话的通信与服务质量要求，网络电话数据流向与呼叫分配，定义今后的增长容量与我们的方法与纲领如何应用在像小型的企业网这样的典型网络中。其余部分作如下安排：第二部分论述了小型企业网的典型网络拓扑如何在网络电话中实现调度。第三部分大致描述了网络电话数据网调度有用的八个步骤。每一步骤都有全面的说明。第四部分介绍了基于分析与仿真研究得出的重要设计结论与工程结论。第五部分谈到了今后研究还需做的具体工作。

2 现有的网络

图1 一个小型企业网的逻辑图

图1是在大厦中一个的小型企业网的典型网络拓扑图。图中所示真实网络情况仅用于研究目的；然而，我们文中提出的原理、框架与概念等工作成果将会更容易被大型网络采纳。这些网络都是通过一个路由连接的两个第二层以太网交换机。路由是卡西欧2621，交换机是3Com Superstack 3300。交换机1连接第一、二层与两个服务器；交换机2连接第三层与四个服务器。每一层的本地局域网就是一个连接有个人电脑的工作组与打印机服务器的共享以太网。网络利用虚拟局域网来隔离广播与组播拥塞。总计有五个局域网存在。所有虚拟局域网基于端口划分。交换机一配置三个虚拟局域网。虚拟局域网一包含数据库与文件服务器。虚拟局域网二包含层一。虚拟局域网三包含层二。另一方面，交换机二配置为含有两个虚拟局域网。虚拟局域网四包含邮件服务器、超文本协议、网页与缓存代理与防火墙。虚拟局域网五包含层三。除了层1-3是100Mbps 的半双工以太网其余链接都是100Mbps 速率全双工的以太网。

3 步进的方法论

路由器

文件服

务器

数据库 层2

一个小型企业网的逻辑图

交换机1 交换机2

打印机服务器

工作组服务器 互联网

前面网络评估与更换

分析模拟

前端调度

说明方法步骤的流程图

图1说明方法步骤的流程图

图2表示了一个成功的网络电话调度八步骤流程图。前面四步是独立的，能够并行运行。在封装分析与模拟研究前，作为前面网络评估与更换的第5步务必先执行。如图，步骤6与7能够并行执行。最后一步是前端调度。

3.1 网络电话通信特征、要求与假想

要介绍像网络电话这样的服务，首先要概括出它通信的本质、服务质量要求与其它原因或者设备问题。出于简单考虑，我们假定在一个没有呼叫协商的点对点对话网络电话呼叫。对网络电话调度来说，网络节点或者呼叫管理器节点务必添加到网络[3,4,5]。网络节点处理用于建立、终止与受权所有网络电话呼叫的连接，同时也要处理外部的呼叫。网络电话负责转换网络电话呼叫到公共交换电话网(或者反向)。作为一个工程与设计课题，如何放置这些网络中的节点变得至关紧要。在步骤5中我们会谈到如何处理这个问题。其它硬件要求包含网络电话客户终端(比如网络电话机或者典型的个人电脑又或者是含有激活网络电话的工作站)能够是独立的设备。激活网络电话的工作站运行着像IP 电话这样的软件。

图 2 网络电话端到端器件

图3表示了一个端对端网络电话的发送与接收器件。第一个器件是编码器，它用于周期性采集原始声音信号与分配固定的比特位给每一个样本，产生一个常速率的比特流。传统的样本采集编码器G.711利用脉冲编码调制来产生每0.125 ms 的8位比特的样本，从而产生64 kbps 的数据速率。压缩包随着编码器压入一定数量的语音标本到信息包，然后加入实时位置、用户数据报、网际协议与以太网报头等信息。语音信号包随之流向数据网络。在接收端有一个重要的元件，它是为了汲取变调的声音与抖动失确实录音回放缓冲器，同时也是为了提供平滑过度的释放。然后数据包被传送至解压器，最终还原成原始声音信号。我们会使用大量被推荐网络电话的H.323、 G.711、与G.714服务质量保证标准。

表 1标准ITU-T 编码器与其默认值

表1对使用国际电信联盟标准的多媒体数字信号编解码器与大量强制要求的单声道的延迟标准作了一个比较。为了达到上层限制要求与满足国际电信联盟推荐的质量要求标准P.800,我们使用G.711u 编解码器标准来满足延时与带宽要求。G.711u 产生4.4等级MOS 。MOS ，意思为一种经常用在网络电话性能指标中的评价标准，有1-5个等级，第封装 解包 编码 解码

标准ITU-T 编码器与其默认值

A/D 转换延迟

5级为最好。然而，为了折衷小小的质量问题，最有可能执行每次呼叫需求带宽更少、有关程度稍高、更能同意的端到端的延迟时间的ITU-T编解码器的不一致标准。这将通过用密集的、静默压缩的、隐蔽的小包丢失数、队列管理技术与把超过一个声音信号包封装在单个以太网帧中。

3.1.1 单声道的端到端延迟

图3阐述了典型语音包延迟的缘由。这端到端的延迟有的时候归结于M2E或者口到耳的延迟。G.714提出了单声道最大总数不超过150ms的网络电话端到端应用。在[22]提到不超过200ms的延迟是能够同意的。我们能够通过下列最少三种起作用的元件降低延迟：(i)发送端的编码、压缩与解压延迟；(ii)传播、运输与网络中的排队延迟；(iii)接收端的缓冲、解压、解码、录音重放延迟。

3.1.2 单个呼叫的带宽

单个呼叫的带宽要求，一个参数就是64 kbps。G.711多媒体编解码器每个语音包20ms的采样。因此，每秒必需有50个这样的数据包。每个包中包含160语音样本目的是为了达到8000每秒的采样率。每个包通过单个以太网帧传送。每个包有160字节大小，再加上协议各层的报头信息。这些报头包含12+8+20+26对应大小的RTP+UDP+IP+Ethernet信息。因此，总共有226字节(或者1808位)的信息需要每秒传送50次，或者一次传送90.4 kbps。关于每个参数来说，一次呼叫需求的带宽是100 脉冲/秒或者均衡的180.8 kbps数据流。

3.1.3 其余假设

纵览我们的分析与研究工作，能够假设语音呼叫次数是均衡的而且语音协商被得到有效执行。我们也忽视了网关的信号拥塞。基于对网络电话呼叫拥塞最坏情况的分析与研究，网关最有可能在建立呼叫与拆除呼叫时产生发送拥塞。比起实际语音呼叫拥塞来说这还是相对较小的。总体上，在一个已经建立好同时在运行的网络电话呼叫持续时间内，网关中产生非常少或者没有信号拥塞。本文我们将使用非服务质量 (能增强在IP 网络层传输包的质量的一种服务) 的设备。许多的服务质量标准能够被网络设备运用。服务质量标准包含IEEE 802.1p/Q、the IETF’s RSVP、与DiffServ。分析运行开支、复杂性、管理与利益务必在使用服务质量标准前好好衡量一下。当网络资源稀少且负荷严重需升级一些花费较贵的网络设备时就应该推荐这种标准。

3.2 网络电话信息流与呼叫分布情况

要明白现在的电话呼叫方法与企业的容量需求是成功的网络电话调度的重要步骤。在着手分析更深层意义的网络电话调度计划阶段，收集静止的现有呼叫量与网络电话的整体框架情况是很有必要的。像这样的信息是组织机构的专用分组交换机、电话清单。现有呼叫的关键问题包含呼叫次数、并发呼叫的次数、时间、持续时间等等。测定呼叫终端的位置显得很重要，比如源与目的地、传输路径与流向。这将有助于辨别呼叫分布情况与内外部的呼叫。呼叫分布情况务必包含在楼层里面与外面的呼叫百分比、建筑物、部门与组织机构。作为一个良好容量测量，建议基于一个星期或者一个月中的最繁忙时期网络电话呼叫分布情况。这将能保证任何时期都有高服务质量的网络电话呼叫支持。当现今的数据表计划外的呼叫结合起来的时候，我们能够推测现有网络中最糟糕的网络电话负载。

网络电话呼叫分配概率树型图

图3网络电话呼叫分配概率树型图

图4描述了基于最繁忙时段的企业呼叫分布情况。在图中，呼叫分布情况被描述成概率树形式。这也能够说成是概率矩阵。一些重要资料能够通过内外部的语音信息流得出。对所有类型的呼叫来说，语音信息流都要通过路由器进行路由选择。这是由于交换机1与2是第2层虚拟以太网设备。能够通过交换机1的层1与层2之间两次负载看出拥塞流向，由于信息包要通过交换机到达路由再返回到交换机。类似，交换机2从(到)第3层经历了两次外部呼叫的负载。

3.3 定义性能极限与增长容量

在这一步，我们对许多重要的网络关键设备进行了性能极限或者操作点的定义。当调度新的服务时这些极限值得考虑。好处是双重的。首先是新服务调度要求令人满意；其次，增加新的设备使网络更健康良性进展。这两个性能标准正被提到议事日程上来。第一是端到端延迟的最大容忍极限；第二是网络资源的极限限制。端到端延迟的最大极限由运行在网络中的灵敏应用服务决定。在我们的案例中，对网络电话来说端到端的延迟是150ms。假如网络的灵敏应用有一定的延迟，当研究网络电话拥塞时对这些应用的延迟监控显得很有必要，这样他们就不可能超过最大极限了。对网络资源的应用范围来说，这样的范围与极限由当前应用与将来的计划与可预见的网络增长决定。恰当的资源与容量计划是至关紧要的。聪明的网络工程师务必把新服务调度的可量测性放在脑中，保证网络在重载与轻载的时候都会产生满意的性能与没有包的丢失。网络电话要求几乎没有包的丢失。在文献中，0.1～5%丢失包是经常的事。然而在文章[24]中网络电话丢失包被建议为减少至低于105 。文章[22]提到了基于实验得出的一个更实际的包丢失数是低于1%。因此，不要全部使用网络资源显得非常重要。由于单凭经验得出对快速交换全双工以太网的方法，平均使用限制在85%以内。用户计划的增长数、网络服务、繁忙程度都务必纳入考虑范围之内以此推断增长容量要求与未来增长因素。在我们的研究中，我们假设有25%的网络空闲容量能够用做将来增长之用。同样的，我们甚至把这种应用到像路由、交换机与交换以太网链接这些网络设备中。尽管如此，在实际中，应该留有对每个网络资源的这种比例与对当前应用与将来增长容量会变化的办法。在我们的拓扑图中，这种网络资源在新服务调度之前最先被保留利用，只有剩余容量被用来研究新服务调度的网络支持。

3.4 网络性能度量

为了说明现有网络通信负载、利用情况与流向，网络度量务必执行。这是一个关键性的步骤由于它能够潜在地影响分析研究与仿真结果。有很多商业或者非商业工具能够用来进行网络度量。流行的开放资源度量工具有MRTG、STG、SNMPUtil与GetIF。一些流行的商业度量工具有HP OpenView, Cisco Netflow, Lucent VitalSuite, Patrol DashBoard, Omegon NetAlly, Avaya ExamiNet, NetIQ Vivinet Assessor等等。网络度量务必在诸如路由、交换机与链接的网络设备中运行。许多类型的度量数据与统计表能够通过度量工具获得。像一个最小的以比特每秒与包每秒的传输速度可通过直接链接到的路由器与交换机测量得出。为了得到恰当的估计，网络度量务必有一段时间，至少是24小时的周期。有的时候甚至需要测量几天或者一个星期。为了保证有好的服务质

量，我们务必考虑到网络负载的最坏使用情况，包含在最高峰时期。最高峰时期的网络各不相同，它由网络提供的服务的事务的性质决定。

表2最糟网络评估表

表2显示了图1中双向链接的路由与两个交换机的网络拓扑图的最高峰拥塞情况。这些测量结果将会用于分析与仿真研究中。

摘自：《Int J Adv 》 ，2005年创刊，第25期，Manuf Technol 出版社出版，DOI 收录期刊。 From: Int J Adv .Manuf Technol (2005) 25: 723–729 DOI 10.1007/s00170-003-1914-5

From: Khaled Salah, Department of Information and Computer Science, King Fahd University of Petroleum and Minerals, 1 July 2005.

摘自：Khaled Salah , 《信息与计算机科学》, Fahd University 皇家石油矿物大学2005 年7月1 日。 最糟网络评估表

利用率

包速率 比特率