1.2 记账的目的
网络管理：计费与性能管理策略
正如前面定义的，记账的目的是对网络资源的使用情况及流量特征进行分析。下面将分小节逐一说明各种不同的记账环境：
网络监控；
用户监控和参数定义；
应用监控和参数定义；
性能规划；
流量参数定义和流量工程；
对等关系和传输协定；
计费；
安全分析。
以上并没有完全包括所有不同的记账环境以及分类，但是企业和服务提供商用户主要的情况都涉及到了。每一个小节都会对问题所在、详尽结果的举例以及一些实施范例进行描述。
1.2.1 网络监控
让我们从记账和性能管理边缘的一些常见范例开始讨论，“网络监控”这个较为含糊的部分就属于这个范围。“网络监控”这一术语广泛地被理解为这样的意思：某些人将它与设备使用情况相关联，而其他人可能会认为是端到端的监控。事实上，网络监控本身就是一种含混的表达，它包含了多种功能。网络监控应用使得系统管理员可以基于安全、计费，或者分析（生产线上和线下的）的目的对网络实施监控。我们打算使用“网络监控”这一术语来表示那些不属于其他类别的应用。
表1-2列举了设备的使用情况。假设我们有一个部署了三个服务级别的网络：级别0用于传输实时流量，如基于IP的语音；级别1承载企业关键性流量，如e-mail和财务事务；级别2用于其他所有流量。这就是一个“尽最大努力”的流量级别。表1-2列举了每个级别所收集的流量总数，包括报文和字节的数量。该记录为网络设计人员提供了相应的信息。该范例中应用的技术是通过SNMP收集CISCO-CLASS-QOS-MIB数据（请参阅第4章），这些数据描述了所有的CoS计数器。
另外一个使用网络监控的场景是为性能监控统计有用的资源报告。在设备层面的记账收集进程收集关于网络资源有用的记录，这些记录包含了诸如接口使用情况、每种应用和每个用户的流量细节（如web流量的百分率）、实时流量以及网络管理流量的信息。在这些信息中可能会包括类似通信的起源地和目的地这样的细节内容，详细的程度根据需求的不同而不同。服务提供商可能为每一个用户收集详尽的个人信息，而企业也许只关心以每个部门为单位的信息。本节主要关注有用资源的记录，而不是所有的像CPU利用率和可用内存这一类的设备细节。
网络监控解决方案可以为性能监控提供以下细节信息。
设备性能监控：
接口及子接口的利用情况；
每一种服务级别的使用情况；
每一种应用的流量。
网络性能监控：
网络中的通信模式；
网络中设备间的链路使用情况。
服务性能监控：
每一台服务器的流量；
每一种服务的流量；
每一种应用的流量。
可应用于性能监控的技术包括SNMP MIBs、RMON、Cisco IP SLA以及Cisco NetFlow服务。
1.2.2 用户监控和参数定义
现在在网络中运行重要业务的趋势已经非常明显了。基于IP的语音、虚拟私有网络（VPN）和视频会议系统在网络中的应用越来越多。同时，人们使用（滥用）网络下载电影、在线收听音乐、过分的网络冲浪等。
这些信息可以用来：
监控用户和定义用户参数；
对每个用户的网络使用情况进行跟踪；
用户、组、部门的文档使用趋向；
确定向目标客户出售附加增值服务的时机；
为每个机构、组织，甚至个人创建流量矩阵。流量矩阵阐明了网络中源和目的之间流量的模式。
记账记录可以用来帮助回答下面的问题：
哪种应用生成的流量最大？是哪种类型的流量？
哪些用户使用这些应用？
流量所占的百分比是多少？
在任意给定时间中，网络中有多少活动的用户？
用户在网络中停留了多长时间？
这些用户是从哪儿来的？
这些用户访问了什么目的地？
用户是否接受了网络中使用的策略？
什么时候进行升级才能使得受影响的用户最少？
针对用户监控和记账记录收集同样存在合法的需求。举例来说，你可以对个体的执行力进行总结。但是在一些国家，对雇员的执行力细节信息进行收集是不合法的。所以需要一种解决方案来收集个体的信息，而不是细节。尽管从法律的层面来讲，这是一种非常理想的解决方案，但是在安全攻击面前是十分危险的。想象这样的一个场景：一台个人电脑PC感染了某种病毒，并且已经开始对网络进行攻击，但是用户还未意识到。那么要将这台PC标识出来，不对它进行基于每个用户的记账记录收集是无法做到的，也就是说，还必须要对这台PC在这个层面上的信息进行收集。同样的工作还会在遭受攻击的其他设备上进行。用户会对劣等的网络服务进行抱怨，但是操作员在没有这些收集来的有用数据的情况下根本就不能帮助用户解决问题。从数据分析的角度来看，我们需要将性能基本信息存储起来，然后通过诸如“背离正常”一类的统计行为来发现异常情况。
一种折中的办法是首先收集所有细节信息，然后用不同的存储机制进行隔离。可以以天为单位（最少）或者以周为单位（最多）来保留所有细节信息用于安全分析，并且将这些记录以部门为单位进行集中，用于性能管理或计费。如果能够保证对这些安全的信息不会有公共访问的话，这种方法从合法的角度上将是可行的。
注释：
在实施基于每个用户的记账技术之前，请核查所在国家的法律要求。
对用户监控和参数定义所采用的技术包括：RMON，认证、授权、记账（AAA），以及Cisco NetFlow服务。
1.2.3 应用监控和参数定义
类似VoIP/IP电话、视频、数据存储、自动强制销售、用户关系管理、呼叫中心、代理、人力资源管理、网络管理系统等技术渐渐浮出水面，而这些技术都要求能够基于每种应用来标识流量。几年以前，这是一份相对简单的工作，因为存在多种不同的传输协议：UNIX通信使用TCP、Novell文件服务器共享使用IPX、大型帧会话使用SNA等。后来，向IP的合并过程淘汰了一部分这些协议，但是却给网络操作员带来了新的挑战：如果都使用IP的话，如何区别各种不同的应用呢？对不同接口计数器信息的收集并不是十分完美，从监控的角度上讲，效果更差。那个时候，大部分的服务器应用都使用图形化用户接口（GUI），并且大部分的网络流量都是基于HTTP的。在这种情况下，要对流量进行分类来部署不同的服务等级就需要进行深度报文检查，这样一来就需要提供一些记账技术。因为这些变化，我们就需要有一种新的方法来收集基于应用的细节信息，并且用选定的技术进行记账。其中一个例子就是Cisco基于网络的应用识别（NBAR），这将在第10章“NBAR”中进行介绍。
所收集的记账信息可以帮助你实现：
应用监控和参数定义：
在整个网络中；
在某条特定的链路上。
基于每一组或者个体用户进行应用监控；
针对不同的服务级别部署QoS以及指派应用；
根据应用的使用情况来实施流量矩阵。
对于网络基准来说，对特定应用细节信息的收集同样非常重要。在第一时间运用审计有时会让人不解，因为大部分的应用在网络中的活跃程度是超乎管理员想象的。应用监控同时还是在网络中实施QoS的先决条件。为了将应用分门别类，对这些应用特定的需求需要进行预先的学习，包括每种应用的通信模式以及流量矩阵。实时应用更是要求更为严密的SLA参数，如语音和视频，而e-mail和备份流量却可以接受尽最大努力的传输，影响不会很大。
下面的问题说明了如何在网络上确定某种特定应用。
在大多数的环境中，应用主要有以下几种不同类型。
应用可以通过TCP或UDP端口号进行标识。可以是“众所周知”（0~1023）的端口号，也可以是其他合法的端口号（1024~49151）。这些端口号由因特网地址分配机构（IANA）分配。
应用可以使用动态或私有的应用端口号（49152~65535），这将会在建立连接之间进行协商，有时在整个会话过程中还会动态地改变。
应用通过服务类别（ToS）比特位进行标识。例如语音和视频会议（IPVC），这些应用可以通过ToS值进行标识。
以下是子端口分类。
HTTP：URL、MIME（多用途网络邮件扩充）类型或者主机名；
标准应用：基于公共应用名称的流量。
同时根据报文检查和特性应用的多种属性进行的分类。RTP负载分类就是基于这样的算法，这些报文根据RTP头部的多种属性被确定为RTP报文。
这些情况，都需要深度报文检查，可以通过实施诸如Cisco NBAR之类的技术来实现。
图1-7显示了每种应用的流量细节，以时间为单位进行集合。
在Cisco的内部网络中，Cisco IT通过网络审计来跟踪应用，并提供一些有价值的结果。下面的应用和协议列表囊括了穿越WAN总流量的80%。
HTTP
E-mail
IP电话
IP视频
服务器和PC的备份
按需视频（VoD）
组播
SNMP
反病毒更新
点到点流量
用来对每种应用进行分类的技术是RMON2、Cisco NetFlow和Cisco NBAR。这3种分类方式都根据每种类型应用的流量进行分类。第5章将对RMON进行说明，第7章将详细介绍NetFlow，第10章将关注NBAR。
一种更为高级的记录是将特定应用的细节信息和CoS信息合并起来。网络设计人员可以使用这样的报告将启用了QoS的环境中的问题隔离出来（如检测到某一级别已经满负荷，但是带宽并没有增加）。在这样的情况下，一个或多个应用可能被转移到其他级别上去，例如，e-mail流量可能被从级别1重新分类到级别2。
表1-3中显示的报表是基于表1-2的，但是扩展了各级别的细节，增加了一些应用特定的部分。对级别0来说，我们关心VoIP以及非VoIP流量的百分比；在级别1中，我们将e-mail和SAP流量进行了区分（假设级别1只分配了这两种应用）；对于尽最大努力传输的级别2，我们区分开了web流量（HTTP）、点到点流量及其他剩余流量。这个报表不能通过SNMP从CISOC-CLASSBASED-QOS-MIB数据进行编排，这是因为它只是根据每个流量级别的计数器进行数据收集的，而不是根据级别中每一个应用。因此，我们使用NetFlow或RMON（用于区分服务的远程监控MIB扩展，RFC 3287）来收集同级别中每种应用额外的细节信息。
从经验上建议，在部署新的应用之前，最好先对网络进行监控。通过某种前瞻性的方法进一步对网络进行分析，确定如何处理新的应用，以及网络是否有能力处理增加的流量。最好的一个例子就是对IP电话（IPT）的部署。你可以运行Cisco IP SLA中的延迟抖动嗅探来标识网络中需要变更或升级的地方，然后在完成所有的测试、保证网络运行正常的前提下开始IPT的部署。部署完成后，记账记录会传递新部署服务的详细信息。这些信息可以用作对服务的监控、故障排查和SLA检查。
1.2.4 性能规划
因特网的流量每天都在增加。不同的应用对于需要多长时间流量加倍的估计是不相同的。这可以引导我们预知今天设计的网络无法承载5年后的流量。宽带的采用已经是主流，因特网几乎已经遍及全球。目前，Cisco内部IT部门推断，每18个月带宽的消耗就会增加一倍。
这就要求能够预见并准确地对网络进行设计和将来的扩展。企业和服务提供商应该很仔细地计划如何以一种经济的方式进行网络扩展。
服务提供商也许应该考虑以下因素。
哪些是能够创造最大利润的端点（PoP）？
哪些接入点的价值不高，需要进行调整？
是否存在备用的扩充给额外的用户？
哪些网段的流量降低了？是否在竞争中丧失了客户？是什么原因导致的？
企业IT部门可能需要考虑以下因素。
哪些部门发展最快？哪些链路近期需要升级？
哪些部门的网络连接是商业上比较重要的，因此需要有一种高可用性的设计？
以上问题在没有进行精确的流量分析的情况下是无法回答的，这需要网络基准以及持续性地对趋向性记录进行收集。服务提供商和专业的IT部门应该更进一步地对他们的客户提供服务监控。该方法可以预先确定潜在瓶颈的存在，还可以让服务提供商提前通知客户，提供更多的带宽、不同的QoS、更高的可用性等。
性能规划可以从链路节点进行考虑，可以用全网节点进行考虑。每一种方式都需要收集一组完全不同的数据参数和使用不同的机制。
- 链路性能规划
对于链路性能规划，储存于MIB的接口计数器通过SNMP进行轮询，这样可以降低链路的使用率。这种简单的、仅凭经验的方法有时会被应用到性能规划中去。如果在工作时间，链路的使用率超过50%的话，就需要对链路进行升级了。链路的使用率是由接口组MIB中的MIB参数计算得出的（RFC2863）。
计算使用率的公式如下：
输入使用率=[(∆(ifInOctets)) 8 100] / [(number of seconds in ∆) * ifSpeed]
输出使用率=[∆(ifOutOctets)) 8 100] / [(number of seconds in ∆) * ifSpeed]
注释：
在Cisco的路由器中，ifSpeed的值通过接口命令bandwidth来进行设置。带宽是一个用户可配置的值，它可以被修改为任意值来满足对路由协议度量值的修改。应该正确地设置带宽，在进行任何接口使用率计算之前，检查show interface命令中BW（带宽）的值，是以Kbit/s为单位的。
一些警告，如陷阱消息或系统日志消息，可能会被发送给故障管理应用来检测门限值超出。当我们在为故障管理使用记账信息的时候，就进入了性能管理的世界，其中的应用在本章稍后将会进行介绍。
- 全网性能规划
如果网络管理员知道网络中瓶颈的所在，链路性能规划大多数时候可能就已经足够了。但是在链路带宽升级之后，网络管理员就会面临下一个瓶颈——因为这是一个持续的过程。另外，大部分网络都是以经济的角度被设计的，也就是说，几乎不会有额外的剩余。“网络订购过量”这一术语描述了网络中的带宽非常丰富，在正常的环境下，性能的限制不会是因为链路性能的缺乏所致。换句话说，应用在和其他应用通信的时候能够看到的惟一限制是网络物理结构上所固有的限制。相反，“网络供应不足”说明了所设计的网络带宽不足以提供给流量。也就是说，即使在正常的环境中，都没有足够的带宽同时提供给所有用户按照他们所分配的最大带宽通过网络完成他们的工作。很明显，网络订购过量的概念比起网络供应不足，成本上更加节省，因为它假设并不是所有用户会在同一时刻使用他们所有的专有带宽。然而，性能规划在这里却更加复杂。要计算足够的供应量，而不会引起供应不足，需要根据精确的核心性能规划，该规划现实地假设了在关键时间区域内，哪些组织或部门的用户将会使用什么样的应用和服务。另一种方法是通过对“核心流量矩阵”进行收集来实现全网的性能规划。核心流量矩阵是一张可以提供网络中在源和目的地之间的流量规模的一张表。为了在整个网络输入节点收集这张表，我们需要核心网络中每一个输出点位的有用信息（要么以每单位时间的字节数为单位，要么以每单位时间的报文数量为单位）。图1-9显示了从Rome到其他所有PoP所需的带宽，表1-4说明了其结果。
*不可用。从一个特定输入节点进来的流量不可能会从这一个节点输出。每一个PoP包含了不止一个接口，不止一台路由器，所以从本地到PoP的流量是实际存在的。然而，这些流量在为网络设计链路性能规划的时候是不予考虑的。
性能规划可以通过将核心流量矩阵映射为拓扑信息的方式来完成。因为我们知道，从Rome到Paris的流量使用Rome跟Paris之间直连的链路，在简单的设计环境中，这条链路的容量是很容易演算出来的。但是，我们将核心流量矩阵映射到路由信息，通常是路由协议的链路状态数据库，更是将这个过程简化了。在路由表/链路状态数据库中进行查找会获得一条路径，让流量可以从Rome去到Paris。此外，性能规划可以对将来提供保护，比如“如果所有的流量在第二年以后的每个月都增长5%，将会发生什么？”或者“如果在以后的6个月内我希望将Rome的客户数量增加一倍，将会发生什么？”
哪一种记账的机制可以帮助我们创建核心流量矩阵？首先，我们可以尝试着通过SNMP接口计数器来推算核心流量矩阵，但是马上就可以看到我们不得不要用N级别解决方案去解决一个N2级别的问题，这里N是网络中节点的数量。因此，这种方法仅仅是一种特殊的众所周知的架构，是一种简单的网络设计。当然，它还不是非常准确。
另一种方法是将SNMP接口计数器与另外一种机制相结合，如引力模型，该模型假设节点之间的流量是按照比例分布在每一个节点的。
有一些研究目的是通过对路由协议度量值的修改来推断核心流量矩阵，具体做法是将路由协议度量值修改前后的接口计数器进行比较。断层模型（核心流量矩阵的推断）在今天越来越多地被研究机构所重视，比如因特网度量参考（http://www.acm.org/sigcomm/imc）、被动和主动度量（http://www.pam2006.org/）以及INTIMATE工场（因特网流量矩阵估计，http://adonis.lip6.fr/intimate2006/）。另外，越来越多的断层白皮书在因特网中发表。很多研究人员都尝试在提供对所有数据记录进行精确收集（这些数据暗示了一些缺陷，比如网络要素CPU和内存使用率的提高、收集的信息总数等等）和简单化用于定义大致的流量矩阵的记账方法之间寻找到一个平衡点。本书将对Cisco路由器和交换机上的记账特性进行归纳，包括Cisco NetFlow服务和BGP策略记账（请参阅第8章）。注意：核心流量矩阵的意义不仅仅为了进行性能规划，还能够提供流量工程，下一小节将对其进行讨论。
1.2.5 流量参数定义和流量工程
要充分理解流量工程，可以拿交通流量模式进行类比。在我居住的地方有很多公路，所以去机场或办公室都有好几条路可以选择。根据每周不同的日子以及每天不同的时间，我会选择不同的道路去我的目的地。通常，在下雨的星期一早上，我会避开高速公路，因为这个时候的高速公路肯定非常拥挤，所以我会选择市区内的道路。但是在星期二的晚上，高速公路就特别适合高速行驶。但是，我也许不想为某座桥或某条隧道支付通行费，所以我会选择不同的道路。另外，我总是听交通广播以避开交通事故地点、拥堵的路段等。在出门之前，我甚至会更进一步地通过查看因特网来了解道路交通状况。大多数人在开车的时候都会考虑多条可选的路径。将这个类比应用到网络结构中，为网络中的数据流量建模来实现流量工程。继续我们的类比，记账数据就是流量信息，一条超过使用门限值的链路就相当于广播中所报道的流量拥堵路段。
IETF因特网流量工程工作小组（TEWG）对流量工程提出了非常技术性的定义：
“因特网流量工程定义为因特网网络工程的一部分，它关心在网络中进行流量处理时的性能最优化。对最优化而言，主要关注的是当其他性能在网络中可用的时候，让性能的过量使用情况最小化。流量工程承担了网络工程这方面的责任，它负责考虑设计、采购，以及与因特网络协调的工作。它通过商业目标、技术及科学原则来度量、建模、描述和控制因特网流量，并运用相关的知识和技术去实现特定的服务和既定的性能目标，包括流量在穿越网络过程中的可靠性和敏捷性、网络资源利用的高效性，以及网络性能规划的科学性。”
一旦我们得到了核心流量矩阵，就可以开始进行一些网络模拟了，比如性能规划之类的。我们应该更进一步地将模拟的观念（流量参数定义、服务、网络故障）结合到核心流量矩阵中去。如果我们假设网络已经设计完成，SLA已经在普通的流量环境中使用，那么对于服务提供商来说，什么是最重要的？服务提供商想要知道一旦网络中有额外负载、链路故障或路由重启的时候（换句话说，就是不正常的情况），SLA会有什么样的结果（这个结果直接影响到客户）。这就是所谓的模拟假设分析法。
网络有定义得非常清晰的边界，这当然是网络管理员的工作。从流量矩阵的角度上看，这就等价于在核心网络边界内驻留了多少流量，以及有多少流量在穿越边界（“进来”和“出去”的流量）。很多细节可能是非常有价值的，比如通过不同的节点、到特定主机的目的地、每个部门的入站和出站流量来确定流量。流量参数定义对网络规划、设备和链路定量、趋势分析、创建特定的商业模型等来说都是一个先决条件。流量工程的目标是最优化网络资源的使用率及流量性能。
每CoS的核心流量矩阵可以通过流量工程工具来进行分析。在这个范例中，定义了三个服务级别，每一个级别代表了一个特定的服务。
CoS 1：VoIP流量。
CoS 2：商业上重要的流量。
CoS 3：尽最大努力传输的流量。
如前所述，通过模拟故障环境，服务提供商可以回答如下一些问题：如果某条链路失效，所有的流量将会通过网络中的另一台路由器进行重新选路，但是用户发起的VoIP流量是否能够通过SLA协议？在SLA级别较低的地方，对商业上重要的流量来说有没有影响？另外，尽最大努力传输的流量是不是仍然能够穿越网络，尽管这些流量没有指定SLA？
在回答了上述问题之后，就可以对每一个服务级别进行性能规划了。
“如果所有的流量在第二年以后的每个月都增长5%，将会发生什么？”
“如果语音的流量以每年10%的速度增长，瓶颈会出现在什么地方？”
“是否该部署新的服务？部署在哪儿？”
如果流量被正确地建了模的话，模拟应用可以通过在不同的环境中分析网络性能的方式对网络规划人员提供帮助。
最后一个步骤，在流量度量、分类、模拟之后，就是将流量分配给接口和网络链路。根据前面步骤中模拟环境的应用，可以分配具体的流量到网络链路上去。大部分的网络设计都包括了节点之间的冗余连接以及不同场所之间的网状互联，用来避免单点故障。可以用附加的连通性来区分不同类型的应用。
为商业上重要的流量分配额外的连接；
不太重要的应用数据可以通过备份或便宜的链路传输；
尽最大努力传输的流量可以用链路剩余带宽来承载。
在性能损耗的情况下，可以考虑将不太重要的流量阻止掉，为其他应用保留带宽。图1-10说明了这样的设计。从Rome到Paris的流量在商业上重要的流量上进行了区分，这部分流量通过直接链路传输，同时运用了SLA。而尽最大努力传输的流量部分则是通过Munich和London进行传输的，因为这条链路上的可用带宽较大。
存在以下一些进行流量工程的方法。
增加链路的带宽；
修改内部网关协议（IGP）的度量值；
修改边界网关协议（BGP）的度量值；
在MPLS核心插入流量工程隧道；
引入高可用性的软件特性或硬件组建。
流量工程本质上讲用于服务提供商的骨干网络。这样的骨干提供高的传输能力，同时要求有很强的修复能力，以便可以抵挡链路或是节点的故障。WAN连接在因特网服务提供商（ISP）的预算中是一项非常昂贵的项目。流量工程使得ISP可以对网络流量进行路由，以便对其用户在吞吐量和延迟方面提供最好的服务质量。流量工程通过关注链路的带宽和流量大小来确定穿越骨干网络的显式路由。
要了解更多关于MPLS流量工程的详细内容，请参阅RFC 2702，MPLS中流量工程的需求。
本书的研究范围将被限制在核心流量矩阵的收集上，不会深入钻研流量工程解决方案的细节。
1.2.6 对等关系和传输协定
就算是最大规模的ISP也只有因特网中一部分的路由条目，所以需要跟其他的ISP进行合作。为确保所有因特网中的目的地都是可达的，ISP和其他ISP（这些ISP是在其他的自治系统[AS]中，但是可以通过边界网关协议[BGP]形成连通性）都加入了对等协定。BGP是因特网中的一种核心路由协议，它是通过维护一张IP网络或前缀列表而进行工作，这些条目指定了在不同自治系统之间的网络可达性。一个AS就是在一个单一实体控制下的IP网络信息的集合——通常这个实体就是一个ISP或一个很大规模的组织，他们与因特网的连接存在冗余。
对等的角色可以有以下几种。
私有对等关系：这种关系存在于两个能够平等地访问到对方网络的ISP，而且访问不需要事先说明。通常，互联网络与他们的客户之间或相关企业之间交换流量的行为都是不情愿的，不会有第三方网络的流量能够被允许进入这个互联网络。
通过因特网交换点（IXP）的对等关系：IXP是一个物理上的网络基础架构，它独立于任何单独的服务提供商，它允许不同的ISP通过手工建立对等协定的方法在AS之间交换因特网流量。IXP通常是ISP用来减少对其上游服务提供商的依赖的。此外，还提高了效率和容错能力。
中转传输（或客户和服务提供商之间的关系）：这种关系涉及到在一个ISP和另一个运营商之间的流量交换。和私有对等流量不同的是，ISP为他们的中转流量付费，只要这些中转流量能够成功地路由到正确的目的地。
第一个层面的ISP操作全球骨干网络的中转流量，集中维护全世界的因特网路由。他们之间趋向于建立私有对等关系，可以无需事先说明地让他们都能够访问到所有的因特网路由。第二层的ISP执行整个国家规模的中转流量，从一个或多个第一层的ISP购买到全球因特网路由的地连通性（上游中转）。因此，他们的IP网络就成了第一层面IP网络的一个子集。这种关系被理解成客户与服务提商之间的关系。第二层的ISP相互之间同样形成对等关系，以实现最小化从第一层ISP交换的流量总数，因为这些上游中转流量需要花钱购买。第三层面的ISP，就像本地接入ISP，需要第二层ISP对其提供上游中转。这种层次化的模型在第三层变得越来越不清楚，因为第三层的ISP既可以从第一层ISP购买上游中转，也可以从第二层ISP购买，甚至还可以与第二层和其他第三层ISP形成对等关系，和第一层ISP形成对等关系的情况也是偶尔存在的。
底层以客户和服务提供商的关系形成对等在因特网商业领域中是最为常见的，客户宁愿从他们的上游ISP那里购买中转。流量比较少的服务提供商倾向于在IXP进行汇聚，这样可以让他们能够在一个中立的场点建立对等关系，相对比较经济。
图1-11显示了中转和对等协定。为了向所有的客户提供因特网接入，第二层的ISP-1与第一层的ISP-B签署了一个中转协定。因为ISP-B只覆盖了整个因特网的一部分路由，所以它与其他第一层的ISP签署了私有对等关系——在本例中就是ISP-A和ISP-C。和ISP-1相同，ISP-2也签署了一个中转协定，不过是和第一层的ISP-A。根据ISP-A和ISP-B之间的私有对等协定，ISP-B将会不作任何事先声明地将来自于ISP-2的所有流量传递给ISP-1，ISP-A同样也会将ISP-1的所有流量传递给ISP-2。注意，缺省情况下，ISP-A和ISP-B之间的私有对等协定没有包含通过ISP-C发送给ISP-2或ISP-1的流量，但是协定可以通过扩充而将其包含进去。
从技术的角度上讲，中转和对等协定是通过交换路由表条目的方式进行控制的。中转协定包括所有路由条目的交换，而私有对等协定只包含了相关客户的路由表条目。
从记账的角度上讲，ISP通常不会对在其管理域之外的终端系统进行记账。记账主要关心的还是从其他相邻（直接连接）的管理域收到或指向这些相邻管理域的流量。在图1-11中，ISP-B发送了一个通知给ISP-1，请求使用它的网络。如果ISP-1想要在它的终端用户或子系统中分配一些有偿资源给ISP-B的话，ISP-1就有责任更详细地收集记账记录，这些记录将来可以用来向单独的用户进行计费。因为每个服务提供商都关注他们直连的邻居，所有只有服务提供商需要基于每一个用户进行详细的记录收集，以便可以对终端客户进行收费。这个记账方案被称为递归记账。如果一个管理域存在一些子域的话，它可以应用在这个大的管理域中。
私有对等协定应该是公平公正的。私有对等在两个服务提供商之间穿越的流量大致均等的情况下工作效果最好，这样两者都能够做到成本最优化。所以，即使不涉及到费用问题，绑定私有对等协定的两个ISP也会对相互收到的流量和发送的流量进行比较。在和其他自治系统进行对等交换点最优化的时候，需要确定流量是从什么地方过来的，以便进行适当的路由策略变更和规划，在某些情况下，会为额外路由的流量向某个服务提供商收取费用。
中转流量和费用相关，所以下游服务提供商最主要的工作之一就是对发送给上游服务提供商的账单进行核查。另一方面，ISP通常会对与利润相关的流量部署较高的优先级。因此，上游ISP都想对流量的类型进行监控，以确保中转流量事实上能够获得预先部署好的服务质量，而不会对这些对等的流量产生影响。
从ISP记账的角度上讲，总是需要根据每一个BGP的AS进行流量分类，如图1-12所示。该示图显示了ISP的一个BGP邻居以及流量交换的百分比。确定额外的对等合作者是一项非常重要的工作，已经存在的服务提供商对等关系也许无法提供因特网完全覆盖的能力。理解了流量目的地和源的需求以及相应的容量规模，就可以确定和其他服务提供商之间形成对等关系的可能性了。
通过分析流量矩阵，ISP可能会发现并不应该和目前邻居形成对等关系。
在“性能规划”和“流量参数定义和流量工程”小节中讲到了核心流量矩阵的好处。接下来让我们深入地区别一下内部核心流量矩阵和外部核心流量矩阵。内部矩阵在之前已经进行了定义，它是一张用来提供在网络中的源和目的地之间流量规模的列表，这里的源和目的地也就是网络中的输入和输出节点（通常都是PoP中的路由器）。外部核心流量矩阵同样也是提供网络中源和目的地之间的流量规模，但是这里要分析的源和目的地不单是网络输入和输出节点，还是BGP的源AS和目的AS。在内部流量矩阵的顶部，外部流量矩阵在流量进入ISP的网络之前将会返回关于流量来源的信息以及从输出节点输出后的最终目的地信息。
对外部核心流量矩阵进行分析有什么好处？
首先，ISP可能会确定它是否与正确的邻居AS形成了对等关系。在图1-13中，ISP-1的外部核心流量矩阵可以确定大部分发送给ISP-B的流量事实上是在ISP-A中进行决策的，所以ISP-1本质上可以直接和ISP-A协商中转对等协议。深度分析应该可以证明发送给ISP-A的流量中，大多数都是指向ISP-2的，所以ISP-1可以考虑和ISP-2签署一个私有对等协定。更为明确的是，类似“ISP-1也接收到来自ISP-1等量的流量”的说法通过对外部核心流量矩阵的分析很快得出结论：被证实或被驳回。
其次，“我的网络是否被用于中转或对等流量？”这个问题可以通过外部核心流量矩阵解决，因为我们可以轻松得出流量是在网络内部还是在网络之间的结论。正常情况下，为了节约开支，会为网络内部的流量（on-net）设置一个优先级，而发送到其他服务提供商的流量（off-net）却是为了获取费用。
第三，当ISP为了特定的因特网路由，想要修改对等协定或变更输出节点的时候，他们首先考虑到的是这样的变动对他的网络会带来什么样的影响。这时，问题就出来了，比如“性能规划如何？变更之后会不会造成某些链路过载？”、“用户的SLA如何？是否仍然需要考虑用户情况？”、“流量工程设置得怎么样？是否需要进行更改？”。输入的外部核心流量矩阵信息、拓扑环境信息以及路由协议信息，再加上合适的性能规划和流量工程应用，就可以为上述问题提供很有价值的详细信息。
参考图1-13，Rome的外部核心流量矩阵在表1-5中进行了说明。考虑一个实践范例：Rome和Paris之间的链路负载非常重，所以ISP想要判断是否可以将流量通过London进行传递，因为Rome和London之间的链路带宽尚有剩余。一种方法是将所有从Rome到ISP-2的流量都绕到London，这是因为London的PoP同样有一条直连的链路到ISP-2。根据外部核心流量矩阵，这些流量的参数已经被标识出来了。接下来，我们需要了解核心流量矩阵。再次强调，外部核心流量矩阵能够为流量工程工具提供正确的输入信息，因为矩阵同时包含了ISP输出节点和目的ISP的信息。流量工程工具能够确定Rome-Paris链路上流量负载的减少量以及Rome-London链路上流量负载的增加量。
最后，通过IXP的对等关系需要特定的记账需求。连接到IXP的ISP可以和连接到同一个IXP的其他任何ISP交换流量。IXP的基础架构通常都是基于交换型以太网组建（介质共享）的，也就是说每一个ISP专用一个交换端口。因为只需要有单点连接到IXP就可以了，所以这种设计解决了在所有ISP之间互联导致的可管理性，以及可测量性的问题。不过，还需要一种额外的记账信息，那就是基于每一个MAC地址的记账信息，因为MAC地址标识了邻居BGP AS的输入节点。图1-14显示了两种环境，都是5个ISP进行互连。在左边，是一个全互联的结构，每一个ISP都有4条连接（n-1）。在右边的图中，只需要一条链路连接到IXP就可以了。
哪一种Cisco的记账特性能够用于BGP对等协定应用？基于NetFlow的方式可以根据BGP源AS以及目的AS对流量进行分类和记账。在这之前，BGP策略记账特性能够支持常规的度量值变革处理，包括AS路径、BGP团体及其他一些用作分类标准的属性。对于基于每个MAC地址的第二层记账，可以考虑使用“基于IP的MAC地址记账”特性。
1.2.7 计费
前面已经提到过记账和计费之间密切的关系，所以现在我们要对这两者进行区别。记账描述了从网络设备或应用服务器测量和收集来有价值的网络参数的一个进程，而计费是利用这些格式恰当并有价值的记录来实现的一种应用。原始的数据收集不能作为通告发送给用户。因为这些数据包含了技术细节，如用IP地址代替了用户名或服务器名，有用的数据记录可能会出现很多次、但是它们之间毫无联系等。所以原始数据需要进行集中、终止以及分离出复制版本后，首先转换成对客户来说有用的信息。我们将通过一个例子来说明这个问题。如果一个用户在工作日开始的时候连接到一台应用服务器（如一个数据库），并且一直使用到这个工作日的结束。如果我们在设备层面上进行数据收集的话，就会收集到如下有用的数据记录。
因为没有路由器或交换机在几个小时内持续性地进行统计，那么可能存在内存资源的限制或性能损耗过程中记录的丢失，进而导致有多条记录表示从客户端到服务器的流量。用户都希望能得到可靠的记录，通常每个小时收集一次。
从服务器返回到客户端的响应流量会另外生成记录，这些记录很可能会在其他网络设备或设备接口上收集到。用户可能希望能够收到每个方向上合并的单条记录，而不是多条。
设备记录包含了客户端和服务器的IP地址。注意：客户端地址根据时间的不同会有变化。用户希望能够通过主机名来标识设备，而不是IP地址，特别是在用DHCP服务器分配IP地址的可变环境中。因此，这些原始记录需要迎合用户需求而进行包装。
记录还包括了通信协议和端口细节，但是没有用户会对写着端口号是80的资源记录感兴趣。因为用户都希望看到通用应用的名称，如web的流量、VoIP的流量及e-mail的流量。
设备层面的时间戳可以被用作设备的sysUpTime（一种SNMP MIB变量，它定义了设备启动后时间的开始），或者从1970年开始的时间（协调世界时[UTC]，包括时间区域），或者由网络时间协议（NTP）表示的当前日期和时间。用户在开始以及终止计时器的时候不希望看到“1079955900”这样的显示方式，而希望是一种人类可接收的时间日期格式。
根据流量在网络中穿越的路径，可能会有多个记录被收集，包括相同用户的流量信息。分离副本可以让用户不用为相同的传输流量付费两次。
在设备层面，另一种对有用记录进行收集的方法是在服务器级别上对有用数据记录进行收集。如果用户在某台服务器上需要进行认证或使用某种服务的话，在使用应用服务之前，该认证进程还可以对如下计费信息进行收集。
登陆时间
注销时间
执行过的进程数量（如从某种预订系统得来的）
数据库的请求和响应次数
CPU使用情况
在前面的例子中，我们仅需要在SAP服务器上收集有用的记录。这样做的好处在于不会涉及到IP地址和用户之间的相互关系。但是额外的计费功能需要在每一台应用服务器上操作，这样一来就会增加投放在应用层面的费用。一个网络如果包含了多种应用和服务器，那么就需要在网络中的每一台服务器上部署服务器记账功能。所以最好的部署方式是采用单点执行、全网通用的解决方案，因为如果需要在每一种应用上都进行认证的话，用户通常会很不高兴。图1-15显示了一个基于服务器的记账场景。
另一种方法是使用一台AAA服务器，这样用户认证只需进行一次，而且每个用户的总时间及使用细节信息都会被收集出来。但是，用这种方法做到的细节信息收集不会像前面描述的那样能够细致地收集到每一种服务的记账信息，也就是每台服务器上特定服务的记账信息（如CPU、数据库需求等）的收集。使用AAA服务器最明显的优势在于所有的记账记录都是集中式创建的，不需要从不同的服务器或网络设备中进行收集。图1-16显示了一个远程认证拨入用户服务（RADIUS）的记账场景。
对于计费解决方案来说，下面的步骤是必需的。
数据收集：在设备层面度量使用中的数据。
数据集中：将多个记录集中成单个记录。
数据终止：将恰当的记录转换成通用或标准的格式。
分离副本：将记录副本排出。
为IP地址分配主机名/用户名：执行DNS和DHCP查找，并且从AAA服务器获取额外的记账记录。
计算呼叫时长：将来自于带有RADIUS会话信息设备的数据记录合并，并且将sysUpTime条目根据用户所在时区转换成每天的时间和每月的日期。
费用：根据呼叫时长、传输的数据量、每个服务级别的流量等因素为记账数据分配非金钱成本度量。费用政策的定义要考虑关税及其他因素。
价格制定：将费用信息转化成金钱数量，然后打印一份最终发票给客户。发票的形式可以选择——是否需要列出详细项目、使用电子版本或通过邮件传递、将多个用户的账单合并成一张完整的账单（比如，对于团体客户来说）。此外，计费策略也需要应用，比如创建产品清单、开通信用卡付款等。
图1-17显示了在设备层面的记账环境下，记账和计费之间的区别。Cisco的NetFlow服务就是这样的一种环境。
在当今的服务提供商市场上，按用量计费在IP网络中相对于单调的按速率计费的模式来说具有更大的竞争优势。随着时间的推移，服务提供商通过为不同的增值服务和应用提供灵活的价格模型来创建利润增长服务，具有竞争力的价格模型同样可以和按用量计费一同创建。无论增加的服务及其相应的价格模型如何，计费记录必须准确，这是强制的。通过使用正确的技术，服务提供商可以很快地发展、定价以及提供他们的新服务。因为单调的速率计费模型并不总是服务提供商的首选，所以新的服务可以考虑以下基于用量的计费方式。
流量/带宽的使用：发送的流量越多，账单数额就越大。
按照距离：如果用户流量的目的在同一个城市或区域，那么其流量可以比发送流量到其他国家或大陆的流量便宜。根据服务提供商的网络和设计，用户为流量的花费可能会比较昂贵，这取决于该流量是在服务提供商网络内部传输（on-net），还是需要离开该服务提供商（off-net）。
应用和/或每种类别的服务：如果SLA与VoIP的流量类型相关联，大多数的客户会为VoIP的流量付更高的费用，而为VPN付中等的费用，为尽最大努力传输的流量付很便宜的费用。
一天中的时间：在夜间发送的流量比在工作时间内发送的流量便宜。
因为没有记账架构的需求，所以在单纯的速率计费中，根据每种服务类别的用量计费就会存在很复杂的多样性。下一小节将会详细介绍不同的计费方案。
单纯的速率计费是一种效率较高的计费机制，因为它不涉及到任何记账和计费的底层架构。无论用户是否很少使用服务或者生成的流量很小，服务提供商都可以从中得到很丰厚的利润。然而，如果用户生成的流量很大，就是另外一回事了。因此服务提供商可能想要通过降低接入速率来吸引那些不太需要大量使用服务的用户，同时为用户准备一些基于用途的计费标准。
作为一种可选方案，一些服务提供商收集SNMP接口计数器的信息用于计费。如果用户是通过路由器或者交换机上的一个专用接口或子接口来进行连接的话，这种方式是可以被接受的。但即便是这样，其结果的局限性也很大，因为只会收集到流量的总数，不可能做到对每一种应用、每一类服务或不同目的的区分。出于竞争的需要，服务提供商不得不研究不同的基于用途的计费机制。
服务提供商需要确定实施哪一种商业化模型。在很长一段时间，由于缺乏经济的记账技术，限制了服务提供商，特别是大型企业部署基于用途的计费。定义的商业案例由于其架构巨大的投资花费而搁浅。另外，需要有一种全面的端到端的解决方案。如果想要对用户使用的服务有一个全面的掌控，仅有一部分的网络组件能够执行跟踪以及输出记账信息是不够的。
今天，Cisco特性，如NetFlow服务、BGP策略记账以及目的地敏感的计费都适合使用到基于用途的计费系统中。
然而，计费并不仅仅局限于服务提供商。在过去，企业IT支出通常是共享的，并且是在部门之间平均分配的，各部门花费的开支通常是基于人头或桌面设备的。随着这种情况的改变，一些财政上的策略就变得越来越不可接受了。首先，在过去十年中，企业和服务提供商用于IT架构的花费都在稳定地增长，而这些增长的费用是需要弥补回来的。第二，对企业来说，对网络的依赖性越来越大，但是在不同部门的情况也不平均。考虑这样一个简单的实例：某企业想要根据各部门的使用情况来收取Internet链路的费用。
一种恰当的计费结构使得服务提供商和企业用户可以实现下面任意的功能。
在不同的组织、部门、组及用户之间平均分类使用成本；
查看部门或企业用户是如何使用网络的；
战略上分配网络资源；
判断增加服务和带宽；
为特定组提供新的服务。
注意：上述后3项并不是计费体系的主要目的，但是它们可以为服务提供商的商业支持系统（BSS）提供重要的信息。新的服务和带宽的添加并不会应用到用户用于尽最大努力服务的链路，即便该链路的使用率非常高。举例来说，在单纯的速率环境中，更多的流量并不会带来额外的利润。相反，如果超出额定的SLA，客户还需要为额外的带宽付出费用，这就给服务提供商提供了预先计划升级的机会。尽管并不会马上产生利润，但是可以向客户建议升级，因为服务提供商除了对违反SLA进行处罚之外，就不会作其他额外的事情了。尽管BSS会考虑这些财政上的信息，但是记账和性能管理应用是不会注意到的。
既然开始介绍基于用途的计费，那么就可能有一些商业化的模型，接下来将对此给予说明。
- 基于量的计费
在该环境中，你会收集每个用户、组或者部门所传输的原始字节或报文量。该模型实施起来相对简单，特别是对特定应用的数据没有要求，而只是需要每组相关的流量总数的时候。此外，每个接口或子接口连接一个用户的网络设计可以通过轮询接口MIB计数器来收集基于量的记账信息。第一眼看上去，这种模型像是很公平的，因为对带宽要求高的用户或组要比那些生成流量少的用户付的费用高。另一方面，你也许会认为带宽的使用情况应该和每天的使用时间相关，因为夜里使用网络进行大容量数据传输的时候，大多数的用户都处于非活动状态。如果实施QoS，你可能还是这样认为，例如，在“黄金”流量类别中少量的IP电话呼叫字节可能比在“尽最大努力传输”类别中大量的文件传输更为昂贵。
对企业用户而言，基于量的计费对于已有的IP成本分配来说是一种很好的选择，因为复杂性相对较低。以基于目的地来说，我们只需要区别流量是局限在内网范围之内（on-net）还是在Internet（off-net）。另外，还可以使用基于部门的成本反馈。图1-18显示了一个典型的企业场景，在中心场点有多个组，通过广域网链路进行分发。
总而言之，基于量的计费的优势在于它很简单。对服务提供商而言，其缺陷在于在竞争中缺乏差异性。
- 目的地敏感的计费
该模型主要根据一个简单的原理，即到流量目的地的距离根据一系列列举值中的一种（如便宜、中等价格或昂贵）进行分类。图1-19对该范例进行了描述。在德国的某客户想要发起一个到德国国内的、便宜的VoIP呼叫，访问在欧洲其他国家的web服务器将花费更多，而发送一个很大的视频文件给远在悉尼的朋友可能会非常昂贵。
这种计费机制的缺陷主要有以下两方面。
用户只为发送到服务提供商的这部分流量付费。那么如果用户想要从悉尼的一台服务器上请求一个很大的文件的话，怎么办？用户只需为一个很小的请求文件付费，而该请求的回应却是一个很大的文件，该文件需要由在悉尼的服务器管理员付费。该模型引出了对于应用服务提供商（ASP）的追溯付款需求（本例子中，就是在悉尼的服务器管理员）来或者向个人用户收费，或者向用户所连接的服务提供商收费，然后将这笔费用添加到每月的发票中。这样就大大增加了这种计费机制的复杂性。
目的地敏感的计费意味着收集的有用记录全部来自于服务提供商网络的入站接口。和其他任何入站收集机制一样，目的地敏感的计费特性需要在网络中的所有的入站接口上启用，否则有些流量就不会被记录到。这对于ISP来说一个很大的挑战，特别是如果PoP使用了多个厂商的设备，并且并不是所有的接入设备都支持该特性的话。
- 目的地和源敏感的计费
为了弥补目的地敏感计费方案中的不足，目的地和源敏感的计费模型同时考虑了流量的目的地和源。让我们回到一个德国用户到悉尼的一台服务器的FTP请求和FTP回复的例子。这个用户需要为发送到悉尼服务器以及从该服务器接收的流量负担很高的费用，不会再有任何附加的复杂性的引入，如ASP的追溯付款。目的地和源敏感计费的一个主要的优势在于它可以基于设备及接口进行应用，因为有用的记录是双向采集的。回忆一下前面小节介绍的目的地敏感的计费，它应用到网络中所有的接口，以避免丢失记账记录。
典型的公共交换电话网络（PSTN）记账模型是将时间与目的地和源敏感的计费相结合的应用，已经应用了超过100年。该模型的政治背景是通过允许资金从发达国家向发展中国家流通来帮助发展中国家建设网络架构。对于在因特网上的计费，该模型主要应用于VPN用户，这样的用户通过单一的服务提供商连接着全球的多个场点。所以并没有真正应用到终端用户，其原因很简单：网络连接是透明的，而终端用户并没有说明服务器在因特网中的位置。然而，目的地敏感计费的一种变体已经出现：网内（on-net）和网外（off-net）流量。网内是指所有的流量都可以被服务提供商控制在它自己的网络内部，或者对等合作者的网络内部。网外流量需要在ISP之间的对等协议。一些ISP已经可以提供免费的网络内接入，例如，接入服务提供商的因特网服务器。另外一个例子是在连接到同一个服务提供商的内部用户之间免费的VoIP呼叫。图1-20和表1-6列举了各种不同的计费种类。
Cisco对于目的和/或者源敏感的计费特性包括NetFlow服务、BGP策略记账和目的地敏感的计费。
- 服务质量计费
另外一个例子是在区分服务（DiffServ）网络中基于类别的计费，在这里不同的应用可能会有不同的费用。目前还没有任何计费模型考虑到网络中特定应用设计的需求。虽然IP电话应用传输的数据量很小，但是相对于其他诸如e-mail和web浏览的流量而言，它对带宽和延迟的需求是很严格的。可以针对VoIP 网络进行额外的投资，而这笔费用专门由应用VoIP的用户偿还，而不是所有用户。QoS计费模型可以解决这个问题，因为基于每类服务的记账记录可以和目的地和/或者源和目的地敏感的计费相结合。我们认为这是最为公平的计费方式，因为商业关键的应用应该比相对不太重要的应用费用要高。特别是如果“尽最大努力”的类免费的话，就不会有用户抱怨不公平对待了。不幸的是，这种模型不是简简单单就能实施的。每一个网络组件不仅需要收集记账信息（对于某些设备来说，这已经是个问题了），而且需要基于每个服务类别收集信息。基于此，该模型仅应用在被证实有必要投资的具体商业个案中。在网络组件收集记账信息的时候还要对流量的类别进行修改（如通过对ToS或DSCP值的修改），所以要格外小心。举例来说，一个简单的设计中，记账信息在ISP的边缘网络设备中进行收集——尤其是在指向用户的接口上。但是，如果该网络设备正好是将客户流量分类到青铜、白银和黄金类别进行服务的设备的话，怎么办？在这种情况下，应该在分类之后（在ToS或DSCP值重写之后）再对记账信息进行收集，千万不要在报文到达接口的时候就通告记账信息。否则，QoS计费就会不准确，因为它是将流量按照用户着以不同的颜色，而不是在服务提供商网络中被传输。
该模型同时还和诸如流量所经过的特定路径之类的概念相关，这曾在“1.2.5节进行描述。
图1-21显示了DiffServ架构中不同的组件。为了降低复杂性，只对“黄金”流量进行了完整的列举。进入网络的报文根据流量分类的定义被分类到三个不同的类别中。黄金代表实时协议和应用，如语音的流量。商业相关的流量并没有被分配到黄金类别中，而是被指派到了白银类别中。所有剩余的流量就被分类到青铜类别，并且以“尽最大努力”的方式进行处理。
类别的参数决定了每一个类别中流量的总数、最大传输率以及发送的匹配标记器定义的类别的流量数量。超过定义的流量定型的流量被认为是不一致的流量，其处理方式不同：要么整形，要么丢弃。标记好的和整形后的流量会被发送到不同的出站队列中等待传输。从记账的角度上看，我们会关心“参数”的集合。如你所见，我们需要为黄金类别考虑以下三种参数集合：
一致的流量；
部分一致的流量；
不一致的流量，（在本例中）将被丢弃。
在我们的范例中，需要总共实施9个类别到每一台设备上（3种一致性等级乘以3种服务类别）。
Cisco CLASS-BASED-QOS-MIB是Cisco用于实施QoS计费的特性。
- 基于应用和内容的计费
基于内容的计费在因特网上已经非常普遍了。虽然不是每个人都喜欢这样做，但是色情网页在因特网上是产生利润的第一大应用。今天的因特网可以向我们提供学识服务、传输服务、培训、幼儿游戏、产品测试等等，我们需要标识基于每种应用的流量，以便可以适当地根据使用的应用为用户计费。应用服务提供商（ASP）和经营web的公司都根据所访问的应用来为用户计费（这被称为基于内容的计费）。在很多情况下，ASP和ISP一起提供给客户解决方案。每种方案各自拥有自己的一部分网络，但是需要保证QoS、网络带宽以及响应时间不会受到影响。同样地，经营web的公司可以按照SLA对接入到服务器和网络的流量按照服务级别分类。要创建这些商业模型，就需要在技术上实施SLA监控和按照使用情况的计费。
总的来说，基于内容的计费可以很容易就链接到特定应用的SLA上去，这是一种进行服务区分的方法。但是，因为要进行报文检查，所以该模型对资源进行了扩展。Cisco NBAR设备特性和服务控制引擎（SCE）能够为应用和基于内容的计费的实施提供所需的功能。
- 基于时间/连接的计费
除了PSTN和GSM网络外，基于时间的计费只应用在拨号环境以及pWLAN接入中。用户根据呼叫的时间及每天中的时间段不同计费的。该模型实施起来比较方便，因为只需要有网络接入服务器（NAS）和RADIUS服务器（或其他提供用户AAA的方式）。记账记录通过RADIUS服务器生成，然后传递给计费应用。我们来区别一下预付费和后付费模式。预付费的模式要求在计费服务器和NAS之间实时地连接来标识用户还有多少的信用额度。预付费计费方式的好处在于用户可以购买特定的接入，而不用向服务提供商要求一个账号，也不需要进行身份核查。 - IP语音（VoIP）和IP电话（IPT）的计费
在10年前，语音的应用指的是邮政、电报和电话（PTT）“摇钱树”，所以很明显，在VoIP发明之初，对其进行计费并没有排上日程。不过，VoIP相关的计费方案具有很大的挑战性，这是因为整个方案中所有不同的部分都需要考虑到。
终端用户计费（扁平的方式、基于每个呼叫、基于每个呼叫的特征、基于每种服务类别、基于距离，或者基于网内/网外）；
根据向PSTN发起的呼叫或接收到的呼叫（基于每个呼叫、总的呼叫量）；
根据发起到其他VoIP服务提供商的呼叫（基于带宽、QoS、时间）；
与语音相关的流量状况（呼叫类型、使用的特性等）。
一个典型的VoIP呼叫数据记录（CDR）包括以下的数据字段：
呼叫ID；
呼叫初始化时间（用户开始拨号的时间）；
呼叫连接的时间（目的端电话挂机的时间）；
呼叫断开的时间；
IP源地址（呼叫发起方）；
远程IP地址（呼叫接收方）；
远程UDP端口；
主叫号码；
被叫号码；
代码（G.711、G.722、G.723、G.726、G.728、G.729及其他）；
协议（H.323、SIP、MGCP及其他）；
传输的字节；
接收到的字节；
传输的报文；
接收到的报文；
回程延迟；
延迟的变化（抖动）；
错误的报文（丢失、早、晚）。
在什么地方收集计费数据，以及收集什么样的数据都依赖于服务提供商的商业模型（固定的价格相对于基于呼叫的、预付费相对于后付费的），同时还要考虑一些细节因素（时间、带宽、QoS、使用的特性）用于计费。下面的场景会生成并收集CDR。
终端用户计费：CDR可以为基于使用情况、带宽或QoS的费用提供所需的详细信息。RADIUS提供了用来应用预付费计费模型的基础架构。第9章将会对RADIUS进行详细介绍。
服务提供商或PSTN“对等”计费：该信息可以在呼叫代理或SS7网关时通过CDR获得。对于服务提供商到服务提供商的对等来说，它主要是看整个的带宽（以及一些流量分类），而不是单独看一个呼叫。
流量状况：CDR可以用来对电话状况进行深入分析（呼叫类型、使用的特性等）。
因为复杂性级别以及小量的数据传输，我们假设超过时间的语音呼叫免费，至少在网内使用尽最大努力传输的语音质量。除此之外，服务提供商可以通过增值服务来提供额外的创利机会，如保证语音质量的商业用语音。今天，我们还不清楚用户是否愿意为增值服务负担额外的费用，或者激烈的竞争是否导致对尽最大努力传输的服务质量的提高。基于因特网的电话Skype获得的巨大成功就是一个很好的说明。
1.2.8 安全分析
企业网络及服务提供商的操作员都因为各种各样的网络威胁和恶意的滥用服务而面临着网络被破坏的巨大威胁。攻击的发起方可能寄存于网络内部或者来自于外部，抑或（最坏的可能）攻击可能同时来自于网络的内部和外部。安全攻击已经成了企业以及个人的祸患。
幸运的是，用来收集在网络中报文传输信息的记账技术同样可以用来进行安全监控。当攻击发生时，记账技术可以检测到不正常的情况或恶意的流量，进而在安全攻击的流量类型被检测到的同时向网络实施中心（NOC）发出警报，如smurf、fraggle或SYN泛洪。接下来，数据记录可以用来进行根源分析，以减少日后被攻击的风险。注意：根源分析需要有个基准，这个基准将在1.3节中进行详细介绍。
第16章将会对用于安全目的的记账进行研究。
考虑到对商业的影响、实施的成本以及损失的利润，对于安全检测和防护来说，需要强调的重点也越来越多。用于安全分析的设计需要考虑以下的需求。
端到端的监控，用于监控本地网络及WAN的辅助连接。
24/7的可用性，因为未更新的安全应用可能会成为被攻击的对象。
接近实时的数据收集，因为较长的传输延迟或聚合间隔可以鉴定并拦截攻击。大多数攻击的持续时间少于15分钟。
在服务器和客户端之间进行加密的通信可以避免泄露可能的攻击信息，并且可以阻止某些格式的攻击。
加固来自于多个源的输入和加强技术以避免错误警告。设定的源越多，就越需要这样做。太多的错误警告将会导致用户拒绝应用工具，以致错过商业上致命的某种攻击。
一种很有效地用于流量描述和用户定义的技术是内置于Cisco IOS软件中的Cisco NetFlow记账特性。在NMS的应用层面，先前讨论的“背离常规”功能对于检测与安全攻击相关的异常是非常有用的。
下面是一些可能需要检测安全攻击的情况：
网络中的流量突然增加；
个人主机生成出乎意料多的流量；
生成的记账记录数量增加；
多个记账记录的内容不正常，例如每一个流记录一个报文（如TCP SYN泛洪）；
伴随着流量应用的改变，比如突然增加的“未知”应用；
某种特定流量类型以及消息数量的增加，比如TCP重置或ICMP消息；
单播、组播、广播流量组合比例明显地改变；
违背ACL的数量增加；
同时存在很大和很小的报文可能意味着遭受了组合攻击。大型报文阻塞网络链路，而小型报文的目标是网络组件及服务器。
所有上述这些征兆如果是单独出现的话，还可以认为是正常情况，但是如果多个相关的事件一起出现，那就有可能是安全问题了。图1-22说明了标识一台设备上数量巨大的流的流程。
入侵检测系统（IDS）会关注这些以及额外的一些考量。还可以使用状态化的报文流分析来标识可疑的行为或异常的网络行为。为了更好地了解这一主题，我们将说明用于标识和阻止可能的DoS攻击的步骤。IDS会将流量与预先定义好的格式进行比较，然后要么将不匹配过滤标准的所有报文都阻止，要么将使用记录储存起来用于记账的目的。
在安全威胁的检测中，有一种网络基准是必须的，这将在1.3.5节中进行说明。在网络正常的工作环境中，如果没有相关知识的话，如何推断出是否有问题呢？举例来说，如果不将其每小时、每天或每星期的值和过去进行比较的话，你又怎么会知道路由器的CPU和内存使用率目前是过低还是过高呢？如果没有定义在星期一上午记账记录的平均数值的话，你又怎么知道在星期一上午记录数量的增加意味着存在安全威胁呢？记账可以帮你找到这些问题的答案。
下面是用于定向标识和阻止安全攻击的步骤。
（1）准备——制定基础架构的基准，比较相关的安全参数。
监控网络设备；
标识关键参数；
在数据库中储存统计数据；
将目前的数据与储存的数据进行比较；
如果门限值超出，或者检测到有可能的异常，生成事件。
（2）标识——检测相关设备。
谁是肉鸡？通过检查“流量接收最高者”的流量来找到处于威胁中的主机，这在分布式DoS攻击中是至关重要的。
哪些网络设备被卷入了？监控不规则的流。
（3）分类——标识攻击的危险程度。
如果某种蠕虫“仅仅”会导致网络链路拥塞的话，那么就可以认为不太危险，而相应的某种会清除所有PC的数据或窃取信用卡信息的恶意病毒就应该是非常危险的了；
单独一个客户端发起的DoS攻击，同时在大量受害主机上发起的分布式DoS（DDoS）攻击会增加标识攻击源的复杂性，也会提高攻击的严重性等级。
（4）向后跟踪——标识攻击源。
记账记录可以帮助标识攻击发起的子网或IP地址；
跟踪被欺骗的IP源地址会让分析变得更复杂，可以按照下面的顺序使用这样的步骤来跟踪源。
A．从肉鸡边上的路由器开始；
B．跟踪每一台上游路由器，每次一台，标识出接收攻击的特定接口；
C．在共享介质的环境中，查找MAC地址是标识上游设备的惟一方法。
（5）反作用：通过一种类似于编乐的安全、性能、故障、记账及配置应用的方法来阻止攻击。
记账应用提供了用于监控和分析的流记录；
性能和故障应用可以标识出由于攻击而导致的网络损耗或过载；
安全应用可以将攻击标识出来，并提供更详细的信息；
配置应用通过修改设备的配置来阻止入侵者，阻止恶意流量（如通过使用访问控制列表）；
记账和性能监控应用还可以标识出什么时候攻击结束。
（6）被攻击之后——回答以下问题。
从中学到了什么？
下次我们会有任何提高吗？
是否按照网络架构的需求进行了修正？
是否需要额外的安全功能、进程、应用或人员？
第（5）步和第（6）步在整个安全管理策略中是非常重要的。但是，本书的目标是为安全威胁的确定和分类收集正确的记账信息，而并不是修正这些错误。因此，我们只会列举第1～4步的技术措施。
特定的MIB参数可以对CPU的使用情况、内存的使用情况、接口的使用情况等等进行轮询。用于流量定性和用户定型的一种较为有效的工具是内置于Cisco IOS软件中的Cisco NetFlow服务记账特性，该特性可以基于IP地址、应用层或其他标准对网络流量进行分类。
RMON协议同样也非常有用，因为RMON探针可以分析链路上所有它接触过的流量，并对这些流量进行分类，然后通过MIB参数对结果进行通告。注意：同时还有一些特定的安全设备，比如入侵检测系统（IDS）或Cisco的PIX防火墙，可以简化安全威胁的检测过程。因为这个主题超出了本书的范围，所以我们为想要更深入研究安全理论的读者推荐一些读物，比如Sean Convery的《网络安全体系结构》（已由人民邮电出版社翻译出版）。
安全监控的另外一个领域是检测未经允许的无线接入。无线LAN（WLAN）目前越来越流行，而且WLAN卡及WLAN接入点（AP）的价格也下降不少。用户购买他们自己的AP，然后连接到公司网络再正常不过了，这样做可以提高接入的灵活性，也许还能够避免公司IT部门部署上的不方便。但是未经允许的AP是没有经过公司IT部门批准的。使用未经授权的AP可能会导致很严重的安全问题，比如会打开一个能连接到公司网络的不受控制的接口。对于网络操作员来说，最可怕的是不仅有未经允许的AP的存在，而且黑客也发现了它。有很多方法都可以标识出未经允许的AP，最简单的办法是扫描网络中所有的IP地址，然后检查是否有web服务器在80端口上响应的请求，因为大多数的AP都集成了web服务器。不幸的是，这种方法只能标识出那些新手安装的未经授权的AP，因为有经验的黑客可能会马上将AP的web服务器功能禁用掉。
在这个案例里面，记账可以起到什么作用呢？考虑这样一个场景，一个用户从数据口断开和笔记本电脑的连接，然后插到一个AP上，用无线代替有线来连接笔记本电脑。使用情况没有任何改变，基于IP地址的记账无法认识到这是新的、第二层的无线连接，它会向笔记本电脑最初连接的交换机上请求MAC地址记账。AP的MAC地址和PC是不一样的，所以在这个交换机端口上的流量的源会突然变成了一个新的MAC地址。即使在这个案例中可以使用记账，也是非常复杂的。但是也有更为简单的方法，比如在每个交换机端口上只允许预先设置的MAC地址（可以参考“端口安全”特性）。
然而，如果其他用户也开始使用AP的话（故意的，或者因为他们PC机上的802.11客户端信号非常强，所以就用他们的AP，而不使用公司的AP了），要是有一个执行基准的话，你就可以在交换机的特定端口上标识出被修改的流量特征。该范例说明了如何将网络基准的制定和记账结合起来，根据改变的流量特征来帮助标识网络安全问题。