CoS & DSCP 映射机制

对于CoS和DSCP,只是分类的标准,可以自己设置信任哪个。而且CoS和DSCP之间有映射,只是标识了包的优先级的不同,根据包的优先级选择不同的出队列,不同出队列所占的带宽资源,拥塞时丢弃比例不同。从而实现服务质量的目标。

QoS 的实现以IETF 的DiffServ 体系为基础。DiffServ体系规定每一个传输报文将在网络中被分类到不同的类别,分类信息被包含在了IP 报文头中,DiffServ 体系使用了IP 报文头中的TOS(Type Of Service)中的前6 个比特来携带报文的分类信息。当然分类信息也可以被携带在链路层报文头上。一般地,附带在报文中的分类信息有:

1 帧头的Tag Control Information 中的前3 个比特,它包含了8 个类别的优先级信息,通常称这三个比特为为User Priority bits。

2 报文头中的TOS 字段前3 个比特,称作IP precedence ">value;或者携带在IP 报文头中的TOS 字段前6 个比特,称作Differentiated Services Code Point (DSCP) value。

在遵循DiffServ 体系的网络中,各交换机和路由器对包含同样分类信息的报文采取同样的传输服务策略,对包含不同分类信息的报文采取不同的传输服务策略。报文的分类信息可以被网络上的主机、交换机、路由器或者其它网络设备赋予。可以基于不同的应用策略或者基于报文内容的不同为报文赋予类别信息。识别报文的内容以便为报文赋予类别信息的做法往往需要消耗网络设备的大量处理资源,为了减少骨干网络的处理开销,一般这种赋予类别信息的方式都使用在网络边界。

交换机或路由器根据报文所携带的类别信息,可以为各种交通流提供不同的传输优先级,或者为某种交通流预留带宽,或者适当的丢弃一些重要性较低的报文、或者采取其他一些操作等等。这些独立设备的这种行为在DiffServ 体系中被称作每跳行为(per-hop behavior)。如果网络上的所有设备提供了一致的每跳行为,那么对于DiffServ 体系来说,这个网络就可以构成end-to-end QoS solution。

下面几个段落将详细介绍本交换机所提供的以DiffServ 体系为基础的QoS 模型。

QoS入口端动作包括Classifying、Policing 和Marking。

Classifying:确保将网络交通流划分成以DSCP值来标识的各个数据流。随后交换机将根据DSCP值来对各个数据流实施不同的QoS策略。有关分类的更详细介绍,请参阅Classifying章节。

Policing:用于约束某个流的所占用的传输带宽,根据配置的Policer来决定流中的哪些部分超出了所限制的传输带宽,并将结果传递给下一阶段的Marking动作。有关Policing的更详细介绍,请参阅Policing章节。

Marking:决定怎样处理数据流中在Policing动作中超限的部分。可能的处理动作有丢弃超限部分和用另外的DSCP值标记超限部分。有关Marking的更详细介绍,请参阅Marking章节。

QoS 出口端动作包括Queueing和Scheduling: Queueing:根据数据流的每一个报文所附带的DSCP值来确定将报文送往端口的哪个输出队列,有关Queueing的更详细介绍,请参阅Queueing章节。 Scheduling:确定以什么样的方式处理被送到端口各个输出队列中的报文有关Scheduling的更详细介绍,请参阅Scheduling 章节。下面的段落将详细介绍QoS模型的各个阶段的动作。

Classifying

Classifying 即为分类,其过程是根据信任策略或者根据分析每个报文的内容来确定将这些报文归类到以DSCP 值来表示的各个数据流中,因此分类动作的核心任务是确定输入报文的DSCP 值。分类发生在端口接收输入报文阶段,当某个端口关联了一个表示QoS 策略的policy-map 后,分类就在该端口上生效,它起作用于所有从该端口输入的报文。

对于一般非IP 报文,交换机将根据以下准则来归类报文:

1 1. 如果报文本身不包含QoS 信息,即报文的第二层报文头中不包含User Priority bits,那么可以根据报文输入端口的缺省CoS值来获得报文的QoS信息。端口的缺省CoS值和报文的UserPriority bits 一样,取值范围为0~7。取得报文的CoS 值之后,再根据交换机上配置的CoS-to-DSCP map 来将CoS 转化为DSCP 值。

2. 如果报文本身包含QoS 信息,报文的第二层报文头中包含User Priority bits,那么可以直接从报文中获得CoS 值,然后再根据交换机上配置的CoS-to-DSCP map 来将CoS 转化为DSCP值。

注意以上两种归类准则只有当端口的QoS 信任模式打开的时候才起作用。打开端口的QoS 的信任模式意味着不通过分析报文的内容,而直接从报文中或报文的输入端口上获得报文QoS信息,从而得到DSCP 值。

2 3. 如果端口关联的policy-map 中使用了基于mac access-list extended 的ACLs 归类,那么在该端口上,将通过提取报文的源MAC 地址、目的MAC 地址以及Ethertype 域来匹配关联的ACLs,以确定报文的DSCP 值。要注意的是,如果端口关联了某个policy-map,但又没有为其设置相应的DSCP 值,则交换机将按照缺省行为为符合这种归类的报文分配优先级:即根据报文第二层报文头中包含的优先级信息或端口的缺省优先级。

注意上面三种归类准则可能会同时作用于一个端口上。在这种情况下,上面三种归类准则按3、2、1 的优先级起作用。即,先根据ACLs 归类,在归类失败的情况下,才有可能选择归类准则2、1,在这个时候,如果端口的QoS 信任模式打开,则根据准则2 和1 直接从报文中或者从端口上获得QoS 信息;如果端口的QoS 信任模式关闭,那么那些归类失败的报文将被赋予DSCP 的缺省值0。

对于IP 报文,可以将根据以下准则来归类报文:

1 1. 直接从IP 报文的TOS 字段中提取出DSCP 值。IETF规定IP 报文的TOS 字段的前6 个比特作为DSCP 值,它的取值范围为0~63,和交换机内部使用的DSCP 值一一对应。

2. 按照非IP 报文处理,按照上面介绍的非IP 报文归类准则1、2来确定报文的DSCP 值。

注意以上几种归类准则只有当端口的QoS 信任模式打开的时候才起作用。打开端口的QoS 的信任模式意味着不通过分析IP 报文的内容,而直接从IP 报文的TOS 字段中或报文的输入端口上获得QoS 信息,从而得到DSCP 值。

2 3. 如果端口关联的policy-map 中使用了基于ip access-list (extended)的ACLs 归类,那么该在该端口上,将通过提取报文的源IP 地址、目的IP 地址、Protocol字段、以及第四层TCP/UDP 端口字段来匹配相关联的ACLs,以确定报文的DSCP 值。要注意的是,如果端口关联了某个policy-map,但又没有为其设置相应的DSCP 值,则交换机将按照缺省行为为符合这种归类的报文分配优先级:即根据报文第二层报文头中包含的优先级信息或端口的缺省优先级。

和非IP 报文归类准则一样,以上几种归类准则可以同时作用于一个端口上。在这种情况下,上面的归类准则按照3、2、1的优先级起作用。即先根据ACLs 归类,在归类失败的情况下,才有可能选择归类准则2、1;在这个时候,如果端口选择QoS 信任模式Trust IP-precedence,那么准则1 起作用;如果端口选择QoS 信任模式Trust CoS,那么准则2 起作用。

有关上面提到的CoS-to-DSCP map、IP-precedence-to-DSCP map映射表的详细描述情常见随后描述。

Policing

Policing 动作发生在数据流分类完成后,它用于约束被分类的数据流所占用的传输带宽。Policing动作检查被归类的数据流中的每一个报文,如果该报文超出了作用于该数据流的Policer 所允许的限制带宽,那么该报文将会被做会被作特殊处理,它或者要被丢弃,或者要被赋予另外的DSCP 值。

在QoS 处理流程中,Policing 动作是可选的。如果没有Policing 动作,那么被分类的数据流中的报文的DSCP 值将会不作任何修改,报文也不会在送往Marking 动作之前被丢弃。

Marking

经过Classifying 和Policing 动作处理之后,为了确保被分类报文报文对应DSCP 值的能够传递给网络上的下一跳设备,需要通过Marking 动作将为报文写入QoS 信息,可以使用Trust 方式直接保留报文中QoS 信息,例如,选择Trust Cos 从而保留802.1Q 报文头的Tag Control Information 中的CoS 信息;默认情况下,Marking 总是用报文对应的DSCP 值转化成QoS 信息,然后写入到报文CoS字段(对于非IP 报文)、DSCP字段或者IP-precedence 字段(对于IP 报文)中。

Queueing

Queueing 动作负责将数据流中报文送往端口的哪个输出队列中,送往端口的不同输出队列的报文将获得不同等级和性质的传输服务策略。

每一个端口上都拥有8 个输出队列,通过交换机上配置的DSCP-to-CoS Map 和Cos-to-Queue Map 两张映射表来将报文的DSCP 值转化成输出队列号,以便确定报文应该被送往的输出队列。

Scheduling

Scheduling 动作时QoS 流程的最后一个环节。当报文被送到端口的不同输出队列上之后,交换机将采用WRR 或者SP 轮转算法发送8 个队列中的报文。

时间: 2024-09-17 04:44:34

CoS & DSCP 映射机制的相关文章

c++-C++ 6.0关于函数的消息映射机制的发问

问题描述 C++ 6.0关于函数的消息映射机制的发问 看了一些文章介绍,C++ 6.0的消息映射以后,函数接收到消息处理以后就返回系统控制权了,但是能得到当前消息的上一个消息么?我想知道这个消息是否执行过了 解决方案 http://blog.csdn.net/hxh129/article/details/9313897

深入理解Linux内存映射机制

作者:王智通   一. 绪 论 二. X86的硬件寻址方法 三. 内核对页表的设置 四. 实例分析映射机制一. 绪 论 我们经常在程序的反汇编代码中看到一些类似0×32118965这样的地址,操作系统中称为线性地址,或虚拟地址.虚拟地址有什么用?虚拟地址又是如何转换为物理内存地址的呢?本章将对此作一个简要阐述. 1.1  Linux内存寻址概述 现代意义上的操作系统都处于32位保护模式下.每个进程一般都能寻址4G的物理空间.但是我们的物理内存一般都是几百M,进程怎么能获得4G的物理空间呢?这就是

MFC的消息映射机制揭秘

MFC的设计者们在设计MFC时,紧紧把握一个目标,那就是尽可能使得MFC的代码要小,速度尽可能快.为了这个目标,他们使用了许多技巧,其中很多技巧体现在宏的运用上,实现MFC的消息映射的机制就是其中之一.  同MFC消息映射机制有关的宏有下面几个:  DECLARE_MESSAGE_MAP()宏  BEGIN_MESSAGE_MAP(theClass, baseClass)和END_MESSAGE_MAP()宏  弄懂MFC消息映射机制的最好办法是将找出一个具体的实例,将这些宏展开,并找出相关的数

C++MFC编程笔记day02 MFC消息映射机制、菜单资源使用

机制3:MFC消息映射机制: 类内声明,类外定义宏,绑定消息处理函数派生自CCmdTarget类内声明宏:DECLARE_MESSAGE_MAP()类外添加实现宏:BEGIN_MESSAGE_MAP(类名,父类名)END_MESSAGE_MAP() //数据结构 struct AFX_MSGMAP_ENTRY {UINT nMessage;   // 消息IDUINT nCode;      // 通知码UINT nID;        // 控件ID或消息UINT nLastID;    //

孙鑫VC++讲座笔记-(4)MFC消息映射机制的剖析

孙鑫VC++讲座笔记-(4)MFC消息映射机制的剖析 一,消息映射机制 1,消息响应函数:(例:在CDrawView类响应鼠标左键按下消息) 1)在头文件(DrawView.h)中声明消息响应函数原型. //{{AFX_MSG(CDrawView) //注释宏 afx_msg void OnLButtonDown(UINT nFlags, CPoint point); //}}AFX_MSG //注释宏 说明: 在注释宏之间的声明在VC中灰色显示.afx_msg宏表示声明的是一个消息响应函数.

mfc-MFC的消息映射采用机制问题

问题描述 MFC的消息映射采用机制问题 MFC的消息映射函数是通过消息映射宏实现的,这个消息映射宏的作用是什么?我觉得用了宏代码就复杂了,它的意义是什么? 解决方案 http://blog.csdn.net/liufei_learning/article/details/5903287 解决方案二: MFC消息映射机制MFC消息映射机制MFC消息映射机制

mongodb mmap内存映射是把文件中数据全部映射到内存中的吗?

问题描述 mongodb mmap内存映射是把文件中数据全部映射到内存中的吗? 资料上说:在Mongodb中,其使用了操作系统底层提供的内存映射机制,即MMAP.MMAP可以把磁盘文件的一部分或全部内容直接映射到内存,这样文件中的信息位置就会在内存中有对应的地址空间,这时对文件的读写可以直接用指针来做,而不需要read/write函数了.同时操作系统会将数据刷新保存到磁盘上. 我有个疑问:这个内存映射,是把文件中数据全部映射到内存中的吗?还是只是映射一部分内容,那么这部门内容又是什么的呢? 请专

MFC消息映射的原理:笔记

多态的实现机制有两种,一是通过查找绝对位置表,二是查找名称表:两者各有优缺点,那么为什么mfc的消息映射采用了第二种方法,而不是c++使用的第一种呢?因为在mfc的gui类库是一个庞大的继承体系,而里面的每个类有很多成员函数(只说消息反映相关的成员函数啊),而且在派生类中,需要改写的也比较少(我用来做练习的程序就是那么一两个,呵呵).那么用c++的虚函数的实现机制会导致什么问题呢?就是大量虚表的建立使得空间浪费掉很多.   嗯-怎么办呢?于是各大c++名库(比如QT,MFC,VCL-)在消息映射

深入理解计算机系统-之-内存寻址(六)--linux中的分页机制

linux的分页机制 四级分页机制 前面我们提到Linux内核仅使用了较少的分段机制,但是却对分页机制的依赖性很强,其使用一种适合32位和64位结构的通用分页模型,该模型使用四级分页机制,即 页全局目录(Page Global Directory) 页上级目录(Page Upper Directory) 页中间目录(Page Middle Directory) 页表(Page Table) 页全局目录包含若干页上级目录的地址: 页上级目录又依次包含若干页中间目录的地址: 而页中间目录又包含若干页