在今天IT技术的发展对于提高生产效率，降低企业开支，增加企业效益已经不是什么骇人听闻的新闻了。富有远见的企业家们在办公室里、写字楼内、厂房与车间里搭建起自己的局域网，将各种各样的终端设备、服务器、数据库连接到上面。在这些富有远见的企业家的带领下，这些企业飞速的发展、扩张，生产规模进一步扩大，业务也在全国乃至全世界铺开，很快就在新的开发区开设分厂，并在全国各地设立了办事处、代办点等分支机构，并且在这些分厂、办事处、代办点也建立起独立的局域网。这些独立的局域网因为相互之间被隔离开来，形成了一个个信息孤岛，既无法共享资源，又不能相互沟通。各个地方的办事处主任成天坐着飞机来往于总部和办事处之间，而无暇处理办事处的日常事务。企业都希望能够将他们分布在各个城市之间的分支机构与总部连接起来，或者是将分布在城市各个角落里的超市、网点、代办处的网络连接起来，以进一步提高信息的传递效率，加强统一管理。
这样的连接需求大致可以分为两类。一类是大型企业总部与分支机构之间的互连需求，这类企业的分厂或者是研发中心开设在若干不同的城市里，而办事处则分布于全国各大中心城市。每个研发中心都部署了一张中等规模的局域网，连接着数千台终端设备；办事处网络的规模会稍微小一些，连接几百台终端设备。这些分支机构大多都有完善的网络规划，有一套完整的路由，一批功能丰富、性能适中的网络设备，接入需求较丰富，带宽和服务质量的需求比高。
另一类是分支机构与代办点、销售点之间的互连需求，像车票机票代售点、彩票销售点、连锁小型超市。这些代办点、销售点基本上只有一个很小的局域网，十几台终端设备，甚至只有一台终端设备，不存在局域网的概念。这些代办点、销售点基本不会有复杂的网络规划，大多采用Hub或者单一功能的低端交换机实现互连，对于带宽的需求不高。
虽然上面提到的企业都有很快的发展，但是大多数企业还是无力满世界地铺设光纤电缆，搭建一张覆盖整个城市甚至覆盖世界各个角落的专网，用于连接这些分支机构。即使对于沃尔玛这样的大型跨国公司而言，自己铺设光纤将分布在世界各地的大型超市的局域网连接起来也是一件得不偿失的事情。
运营商凭借自己已经搭建好的覆盖全国的光纤/网络，正好可以向这些企业用户提供相对廉价的互连业务，但是摆在运营商面前的第一个问题就是如何将这些用户连接到自己的网络上。
在这个背景下，大部分运营商选择搭建城域网以完成这些企业的接入，然后采用各种封装方式将用户的数据放到骨干网上传输，并最终通过另一端的城域网将用户的数据发送给应该送达的用户分支上。
MEF，Metro Ethernet Forum（城域以太网论坛）是一个开放性非官方组织，其成员大多来自全世界各个运营商、设备提供商、测试设备制造商，这个组织从成立一来就一直致力于打造一个规范而统一的城域以太网，以实现不同厂商设备间的互连互通。这个组织发布的第一份规范MEF 1定稿于2003年11月，此后一直到2006年1月这两年间MEF一共推出了16份规范，通过这一系列规范，MEF定义了从城域以太网的架构、服务到接口、通道、介质再到管理、可靠性，甚至拟订了测试方法、测试套，并推出了MEF认证。其中规范MEF 1旨在阐释一个标准的城域以太网的基本模型，涵盖了城域网的框架结构、各种接口以及相关属性等，MEF 5则重点描述了城域以太网中的服务质量和业务保障；这两份规范现已被废除，其内容被汇总在MEF 10中。所以在整个MEF体系中城域以太网的整体结构在MEF 10中被确定下来，2006年11月，MEF对MEF 10中的规定进行了进一步的补充，形成了MEF 10.1，本文即参照这份规定中的内容，向读者介绍城域以太网的整体结构及相关的属性和要求。
按照MEF的想法呢，以太网的服务模型大抵应该是这样的：
对于用户而言，一个用于运营的以太网，大概应该像图1中的云图一样，是一个莫可名状的东西，这片“乌云”仅仅给用户提供了一个被称为UNI的用户接口。每个UNI只针对一个用户，而不应该被若干个用户共享。这里UNI作为一个明确的物理上的分界点，将用户侧和运营商侧分开，如果在UNI里面出了问题，用户大可以致电800电话把工作人员骂得痛哭流涕；但是如果定位下来，问题是出在UNI外面——也就是说用户侧的话，对不起，服务是收费的——当然，大客户另说。
当然给用户提供这么一个UNI的主要目的还是用于转发用户的数据包的，打个比方，用户左侧的CE将数据包发送到UNI上，这个数据包在穿越了层层“乌云”之后，从右侧的UNI被发送到用户右侧的CE设备上，再由用户的设备去处理。
既然是提供以太网服务，UNI接口和用户CE设备的接口自然应该是标准的以太网接口了，其最大链路层报文长度（含CRC）不加802.1Q tag的情况下为1518，加上802.1Q tag的情况下为1522（为了兼容各种网络应用，这个报文长度的限制被放宽了）。因为两端物理层都是以太的，所以也不需要转发物理层的信息，比如速率双工的协商帧或者是以太报文的前导位等，这些协商工作都可以交给UNI和用户端口协商完成。
两个或者多个UNI之间的连接被叫做EVC（Ethernet Virtual Connection，虚拟以太连接），MEF提供了多种EVC作为参考，当然这些都是给客户做参考的，设备供应商需要支持全部的种类——再不济也要支持最基本的那几种。对于UNI而言，也有很多服务属性，采用什么样的属性跟运营商和用户签订的协议有关，对于设备供应商而言也是需要全部支持才行。
当然“乌云”里面那片东西的构造和这篇文档就没什么关系了，穷点的运营商拿根网线或者一对光纤也能充数——只要能够完成协议上规定的条款就可以了——当然运营商们大多很有钱，不大会考虑这样的方案。
这年头都流行炒做差异化服务的概念，运营商在这方面从来没有落在后面过，既然城域以太网是做给运营商用的，自然不能不深谙其中道理了。所以MEF中规定——城域以太网能提供多种差异化的服务。
以太网服务框架也是从这种思想出发的，MEF提出对于一种类型的以太网服务，应该有若干对应的服务属性；而对于每一种属性，又应该有若干对应的参数。
根据这样的分类原则，运营商可以很轻易地通过不同的属性和参数来区分不同的服务。
比如在今后的MEF里会被广泛提及的E-Line服务和E-LAN服务就可以看作是两种不同的服务。这两种服务又包含了两种属性：UNI的属性和EVC的属性。
MEF对这两种服务的属性和参数做了如下规定：
Attribute | Type of Parameter Value |
UNI Identifier | Any string |
Physical Medium | 参照IEEE 802.3以太网定义 |
Speed | 10 Mbps, 100 Mbps, 1 Gbps, or 10 Gbps |
Mode | Full Duplex or Auto negotiation |
MAC Layer | 参照IEEE 802.3以太网定义 |
Service Multiplexing | Yes or No |
UNI EVC ID | An arbitrary string for the EVC supporting the service instance |
CE-VLAN ID/EVC Map | 按照章节4.6 在UNI上区分EVC 实施 |
Maximum Number of EVCs | Integer ≥ 1 |
Bundling | Yes or No |
All to One Bundling | Yes or No |
Ingress Bandwidth Profile Per Ingress UNI | No or 参照后文定义 |
Ingress Bandwidth Profile Per EVC | No or 参照后文定义 |
Ingress Bandwidth Profile Per Class of Service Identifier | No or 参照后文定义 |
Layer 2 Control Protocols Processing | All entries from Table 1 with each being labeled Discard, Peer, or Pass to EVC |
表1 UNI的属性
Attribute | Type of Parameter Value |
EVC Type | Point-to-Point or Multipoint-to-Multipoint |
UNI List | A list of UNI Identifiers (4.1) |
CE-VLAN ID Preservation | Yes or No |
CE-VLAN CoS Preservation | Yes or No |
Unicast Service Frame Delivery | Discard, Deliver Unconditionally, or Deliver Conditionally. If Deliver Conditionally is used, then the conditions MUST be specified. |
Multicast Service Frame Delivery | 同上 |
Broadcast Service Frame Delivery | 同上 |
Layer 2 Control Protocols Processing | Entries from Table 1 labeled Tunnel or Discard. |
EVC Performance | 参见后文定义 |
表2 EVC的属性
表1和表2中的参数将在后文中逐渐提到。
EVC的全称叫Ethernet Virtual Connection，我管它叫做虚拟以太连接。一个EVC可以被看作是一个二层的双向通路，每个EVC都包含若干个UNI，或者说某个UNI从属于某某EVC，当报文从一个UNI进入EVC后，它会被转发到这个EVC中的其他UNI上——当然，是按需的。
MEF中提到了三种EVC的服务种类，点到点EVC（Point-to-Point EVC）、多点到多点EVC（Mutlipoint-to-Multipoint EVC）和根到多点EVC（Rooted-Multipoint EVC）。
点到点的EVC大致应该是这样的：
图3 点到点EVC模型
一条点到点的EVC将两个UNI严格地关联起来，如图3中所示的两条EVC，从左侧节点到右侧两个节点之间分别建立了一条EVC，从右上侧节点发送出来的报文只能通过EVC1被递交到左侧节点的端口上，左侧节点发送到EVC1中的报文也只能递交到右上侧节点的端口上，而这些报文绝对不能被右下侧的节点接收到。至于左侧UNI上接收到的报文中，什么样的报文应该在EVC1中转发，什么样的报文应该在EVC2中转发，则是由运营商和客户之间协商定义了——当然，这样的转发规则是要能够在设备上配置实现的。
多点到多点的EVC则应该是这样的：
图4 多点到多点EVC模型
一个多点到多点EVC可以将两个或者两个以上的UNI关联起来，而且用户/运营商可以在不影响其他UNI的前提下根据需要向这个EVC中任意个UNI，或者将这个EVC中的某些UNI剔除出去，这个和点到点的EVC是一个很大的不同。当单播报文从某个UNI进入一个多点到多点EVC后，报文会根据一系列规则被转发到另一个UNI，比如根据目的mac地址转发；如果是广播报文或者是组播报文，则会其他的每一个UNI拷贝一份，当然对于那些不符合转发规则的报文如未知单播也享受同样的待遇。如图4中所示，多点到多点EVC的结构和一台二层交换机类似。
根到多点EVC应该是这样的：
图5 点到多点EVC模型
这种EVC类似于三层VPN中的Hub-Spoke模式，它包含一个或多个根UNI（Root）和若干叶子UNI（Leaf），其中根UNI可以和EVC中的所有UNI直接通信，而叶子UNI只能和EVC中的根UNI直接通信，两个叶子UNI之间不能直接通信。
后文中将把多点到多点EVC和根到多点EVC统称为多点可达EVC。
EVC的标识是运营商定义的一段能够标识这个EVC的字符串，这个字符串应该是全局唯一的标识——这完全是出于管理方便的目的而制定的，通过它运营商可以很容易得到租用这个EVC的用户代码或者其他相关信息。在这个EVC中转发的报文不会携带该EVC的EVC ID。
这个属性是MEF 10新定义的一个属性，大概是觉得UNI ID这个属性比较好用，所以在新的规则里面又引入了EVC ID。
UNI描述列表其实为EVC中的UNI标识建一张索引表，对于EVC中的每一个UNI都必须有一个明确的全局唯一的标识。
即上述UNI描述列表中所允许添加的UNI的最大数量；在一个点到点EVC中，这个数值必须等于2，而是一个多点到多点的EVC中，这个数值则要大于等于2。
一个EVC能转发的报文，就像前文提到的一样，包括单播报文、广播报文、组播报文等等。在城域以太网里，EVC可以根据报文的目的mac地址来判断报文的种类。但是做为一条承载二层业务的通道，有一类目的mac以01-80-C2开头的特殊报文是必须要考虑的，这些报文是二层协议控制帧，每个EVC都需要具备识别和正确处理这些控制帧的能力，而不仅仅是简简单单透传或丢弃了事。
MAC Addresses | Description |
0x0180c2000000 through 0x0180c200000f | Bridge Block of protocols |
0x0180c2000020 through 0x0180c200002f | GARP Block of protocols |
0x0180c2000010 | All Bridges Protocol |
表3 官方定义的二层协议控制帧mac对应表
对于不同协议的报文，EVC的处理方式必须有所不同，后面我们会一一提到。
通常EVC对于从用户侧发送过来的报文会有以下三种处理方式：
l 丢弃；比如说FCS错误的业务报文会在UNI口上被丢弃，一些协议报文如802.3X协议的报文也会在UNI口上被丢弃。
l 无条件转发；比如说从点到点EVC的一个UNI端口上收到的完整无误的数据报文都会被无条件地从另一个UNI端口转发出去。
l 有条件转发；比如说从某个EVC的一个端口上收到的报文，在有限的带宽范围以内的报文被转发到其他端口上，超出带宽限制的报文则会被丢弃。
上述行为是指在网络正常的情况下EVC对报文的处理，如果出现EVC发生中断或者EVC上有大量拥塞的情况，就不能保证报文还能够被正确处理了。当然，既然是用于运营的网络，如果连这些问题都搞不定，那就该换一家了。
用户CE发送给UNI的报文的各个字段在它们被发送到另一端的用户CE上时必须和原来一模一样，除非在一些特殊情况下，比如：
l 有的时候，出于应用的需要，EVC需要为进入的报文加上802.1Q tag，将原报文所携带的802.1Q tag剥掉、替换。
l 进入EVC的报文携带的802.1Q tag在被转发出去时被剥掉了，这个时候需要填入新的FCS字段，以保证报文的正确。
l 进入EVC的报文不携带802.1Q tag在被转发出去时被加了一层tag，这个时候需要填入新的FCS字段，以保证报文的正确。
l 进入EVC的报文携带的802.1Q tag在被转发出去时被换成新的tag，这个时候需要填入新的FCS字段，以保证报文的正确。
这个属性主要是针对用户报文的802.1Q tag中的两个关键字段——VLAN ID字段和COS字段。为了让运营商能够很方便的在原有网络上进行改造，这个属性为运营商提供了多样性选择。
如果运营商选择保留VLAN ID的话，报文在穿越EVC前后，不携带802.1Q tag的报文仍然没有802.1Q tag，携带802.1Q tag的报文，其VLAN ID字段也不会改变。如果运营商选择保留COS字段的话，报文在穿越EVC前后，COS字段应该一致。
对于不同的EVC而言，这两个关键字段的属性是独立的，即使把多个EVC绑定在一个UNI上，也可以对每个EVC单独配置。
与之对应的，运营商也可以选择不保留VLAN ID或者VLAN COS，这样的话，运营商可以根据现有网络的情况选择给用户的报文添加、剥除VLAN tag，或者修改用户报文tag中的VLAN ID或VLAN COS。
在一些特定的场合下，EVC对于用户CE间运行的二层控制协议是透明的，所以EVC需要为一些二层控制协议报文建立隧道（tunnel），从而保证这些协议报文在转发的过程中不会被处理或修改，并且能被转发到正确的UNI上。比如用户希望在各个CE设备之间起STP协议，相应的EVC就必须要具备支持BPDU tunnel的功能。一旦这个EVC被确定为需要支持某种二层协议的tunnel功能，那么这类协议的协议报文在穿越EVC前后，各个字段是不应该被修改的。比如前文表3中所列出的二层控制协议报文，在它们进入EVC之前通常是不携带802.1Q tag的，那么在它们离开EVC的时候，也不能携带802.1Q tag。
运营商可以根据需要在指定的EVC的某个指定UNI上配置某种二层控制协议报文是应该从tunnel中被转发还是应该丢弃，如果是在tunnel中被转发，还需要明确这个报文在EVC中的VLAN ID——这个属性会决定报文将会被转发到哪些UNI上。
此外还需要注意的一点是，在一个EVC中，如果需要为某种协议报文建立tunnel的话，这个EVC中的所有UNI都应该运行这类协议报文通过。
服务等级属性标识为EVC中传输的业务报文提供了统一的标识方法，它通过将不同的业务报文分为若干类，每一类对应一个唯一的服务等级实例，对于某一个指定的服务等级实例而言，都有一套与之对应的服务性能。而每一个服务等级实例也会对应一个服务等级标识，这个标识一般通过业务报文中的一个或几个字段反映出来。比如说，在某个UNI接口上，定义了银牌、金牌、白金三种服务等级。其中银牌服务包含了三个实例，金牌服务包含两个实例，白金服务包含一个实例，那么这个UNI上就包含了六个服务等级实例。
用户可以指定对EVC中的某一类服务等级实例的报文进行丢弃处理，丢弃一些服务等级实例中的业务报文。这种部署特性往往是出于一些安全方面的考虑，或实现一些特殊的应用。
被映射到不同EVC中的业务报文必须采用不同的服务等级实例，城域以太网中提供三种相互独立的方法来划分报文服务等级实例。
采用这种方法，所有被映射到同一EVC中的业务报文都会被划入一个服务等级实例中。
比如，某UNI上有两个EVC，分别为EVC 1和EVC 2，用户可以指定所有进入EVC 1的报文被标记为服务等级实例1，享受金牌服务；所有进入EVC 2的报文被标记为服务等级实例2，享受银牌服务。对于哪些通过EVC 1转发的二层控制协议报文则可以被标记为服务等级实例1，享受金牌服务；而哪些通过EVC 2转发的二层控制协议报文则可以被标记为服务等级实例3，享受白金服务。
采用这种方法，可以根据一套CE-VLAN CoS到服务等级实例的映射法则将进入EVC的报文划入不同的服务等级实例中，这套映射法则应该包含所有EVC中可能出现的CE-VLAN CoS。如果报文是untagged的，那么这些报文将被视为CE-VLAN CoS为0的报文来处理。
举例来说，某UNI上有两个EVC，分别为EVC 1和EVC 2。其中在进入EVC 1的报文中优先级字段为7、6、5、4的报文映射到第一等级，享受金牌服务；优先级字段为0和3的报文映射到第二等级，享受银牌服务；优先级字段为1和2的报文映射到第三等级，这些报文被指定为丢弃处理；untagged的报文和优先级指定为0的报文一样，映射到第二等级，享受银牌服务。在进入EVC 2的报文中，优先级字段为7的报文映射到第四等级，享受白金服务；其他的报文被映射到第五等级，享受金牌服务。
由于目前大多数业务都是基于IP的，所以MEF中也提供一种基于DSCP确定报文服务等级的标识方法，即根据一套DSCP到服务等级实例的映射法则将进入EVC的报文划入不同的服务等级实例中，这套法则需要包含所以EVC中可能出现的DSCP值。对于那些非IP的报文，则按照用户和运营商的约定，统一映射到一个服务等级实例中。
除去前面提到的三种服务等级的标识方法以外，MEF中还规定EVC必须能够对二层控制协议报文也进行服务等级标识的区分，这是和上述三种方法并行进行的。而且EVC还需要具备根据协议类型不同，将不同的协议报文映射到不同的服务等级中。
这个约定服务性能的属性对于运营商而言是相当重要的东西，通俗点讲就是一分价钱一分货。运营商要向用户提供有差异的服务，必然需要将这些用户分门别类地区分开来，而区分服务最简单的方法就是通过EVC进行区分。比如对某个EVC中的业务提供1M带宽的高优先级业务，保证这种业务在服务期99.99%的时间内不大于0.05％的丢包率、不大于50ms的延迟和不大于10ms的延迟抖动，再提供2M额外带宽的低优先级业务，但是不对这部分业务做服务质量的承诺。
这项属性都是根据用户不同的业务需求制定的，通常这些业务可以通过一组不同的CE VLAN COS来区分，运营商可以通过和用户签订协议来定义这项属性，并在相应的EVC上配置这项属性。
在MEF 10.1中，这部分属性被极大地丰富了，这个属性被细化为三个部分：延迟、延迟抖动和丢包率。这个约定仅仅针对被标记为绿色的报文，只需要保证在一个规定的时间长度内，绿色报文的延迟、延迟抖动和丢包率在约定的范围以内，黄色报文则不在这个约定之中，至于红色报文，它们在UNI上就已经被丢弃了，EVC中不会有这类报文。（报文着色的规则会在后文中提到，有兴趣的同学可以直接跳到章节3.10）
不过既然要按照服务质量收费，这种服务质量必须是可以测量的，以保障租用EVC的用户的权益，下面分别介绍延迟、延迟抖动和丢包率的测量计算方法。
某个报文在一个点到点的EVC上的延迟是这样定义的：当这个报文的第一bit（从目的mac算起）进入UNI开始，到这个报文的最后一bit从另一个UNI上出来为止的这段时间，即被视为这个EVC上的延迟，通常的单位为ms。图6中形象地给出了延迟的计算方法。
图6 点到点EVC的延迟
这里定义的延迟是指单向延迟，在实际操作中可能无法直接测量获得，不过通过测量双向延迟再计算单向延迟的方法，我们还是能够得到一个近似值。
在运营商和用户的约定中，对于点到点EVC的延迟这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，双向通过EVC的绿色报文中，某个指定的服务等级实例中至少有P%的报文平均单向延迟小于d。比如：在任意的5分钟内采样，从UNI A到UNI B的绿色报文中，第一等级实例中至少98％的报文平均单向延迟小于30ms，第二等级实例中至少90％的报文平均单向延迟小于30ms。
某报文在多点可达EVC上的延迟则复杂一些，假设某指定EVC中有m个UNI，那么这个EVC中报文可能经过的所有路径（单向）共有2m×(m－1)条，定义一个子集S，包含上述部分或全部路径，这样可以把S看做是若干点到点EVC的集合，报文通过S中的某一条路径的延迟可以参照点到点EVC上延迟的计算方式得到，如果某个报文会同时通过S中的多条路径（比如广播、组播、未知单播报文），那么取这些路径中延迟最大的那条路径的延迟作为报文在子集S中的延迟，而那些报文不会通过的路径则延迟为0。
通常S可以用UNI对的集合来表示，如S＝{(UNI i1，UNI j1)，（UNI i2，UNI j2）……}，其中UNI in表示报文的入口，UNI jn表示报文的出口，一条路径的出、入口不能为同一UNI。
根据这样的定义在运营商和用户的约定中，对于多点可达EVC的延迟这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，通过EVC的某个子集S的绿色报文中，某个指定的服务等级实例中至少有P%的报文平均单向延迟小于d。比如：在任意的5分钟内采样，在UNI A、UNI B、UNI C之间转发的绿色报文中，第一等级实例中至少98％的报文平均单向延迟小于30ms，第二等级实例中至少90％的报文平均单向延迟小于30ms。
仅仅定义平均延迟，还是不能保证所有业务都能够完全正常，在一个普遍报文的延迟都比较低的情况下，即使有部分报文的延迟非常大，平均延迟也不会明显增加。为了限制这种情况的出现，运营商和用户还会对延迟抖动作出约定，作为对延迟参数的补充。
图7 点到点EVC的延迟抖动
图7给出了一个延迟抖动采样的计算方法，在一个长度为T的任意时间段内，任意一对进入UNI时间间隔为Δt的两个报文，到达EVC另一端的延迟之差。在这里Δt的选择是有特殊意义的，而不是一个随机选择的值，比如针对语音业务，Δt一般会被定为一路IP电话的两个相邻报文之间帧间隙的整数倍——2倍或3倍，也不至于太大。
在运营商和用户的约定中，对于延迟抖动这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，通过EVC的绿色报文中的任意两个进入UNI时间间隔为Δt的报文对的延迟之差的采样中，某个指定的服务等级实例中至少有P%的采样小于d。比如：在任意的5分钟内采样，从UNI A到UNI B的绿色报文中的时间间隔为50ms的报文对的延迟之差的采样中，第一等级实例中至少99％的采样小于1ms。
同计算延迟一样，多点可达EVC的延迟抖动的计算方法也是在一个路径子集S中，报文通过子集中的一条路径的延迟抖动参照点到点EVC中的计算方法，然后取报文通过子集中的所有路径里，延迟抖动的最大值作为报文在子集S中的延迟抖动。
在运营商和用户的约定中，对于多点可达EVC的延迟抖动这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，通过EVC某个子集S的绿色报文中的任意两个进入同一UNI时间间隔为Δt的报文对的延迟之差的采样中，某个指定的服务等级实例中至少有P%的采样小于d。比如：在任意的5分钟内采样，从UNI A、UNI B、UNI C中的任一指定端口进入，到其他两个端口的绿色报文中的时间间隔为50ms的报文对的延迟之差的采样中，第一等级实例中至少99％的采样小于1ms。
丢包率这种东西实在是乏善可陈，无非就是那些进入一个UNI本应该被EVC转发的报文，却没有从另一个UNI上被发送出去，占所有进入UNI并且应该被EVC转发的报文的百分比。
在运营商和用户的约定中，对于丢包率这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，EVC中某个指定的服务等级实例的丢包率小于L。比如：在任意的5分钟内采样，EVC中第一服务等级的丢包率小于0.001％。
在多点可达EVC中，丢包率的计算相对特殊一些，由于一些报文会被转发到多个UNI接口，有可能出现一部分UNI接口收到而另一部分UNI接口却没有接收到的情况，所以不能简单的统计每个报文的收发情况。有鉴于此，MEF中规定如果报文会经过N条路径（比如广播、组播、未知单播报文），那么在统计时这个报文会被计为N个，如果其中M条路径上发生了丢包，则统计为M份丢包。所以丢包率最终可以表示为M的总和/N的总和（单播报文按照N＝1、M＝1处理）。
在运营商和用户的约定中，对于多点可达丢包率这个参数的约定建议采用如下格式：在一个长度为T的任意时间段内，通过EVC中某子集S的某个指定服务等级实例的丢包率小于L。比如：在任意的5分钟内采样，通过UNI A、UNI B、UNI C的第一等级的丢包率小于0.001％。
可靠性是指在一个较小的丢包率的范围以内，网络不中断地提供持续业务的能力。如果运营商向用户承诺在一个月内提供99.9％的可靠性，那么按照30天一个月计算，这个月内网络的中断时间累积不能超过43分钟。
在非正式场合中，连通性通常是这样测量的。每隔一小段时间发送一组测试帧，如果这些测试帧的丢包率在指定范围以内，即可认为这一小段时间以内网络是连通的；如果这些测试帧的丢包率超过了指定范围，即可认为这一小段时间以内网络中断。
MEF中定义了6个参数来判定网络的可靠性，这6个参数分别为指定时间段T，检测时间分片Δt，网络不可达丢包率判定门限Cu，网络可达丢包率判断门限Ca，持续倍速n，可靠性A。（其中Cu>=Ca）测试时以Δt为最小时间间隔发送一组测试帧，在网络处于连通的情况下，如果连续n组测试帧的丢包率都大于Cu，则可判定网络进入中断状态，反之网络仍然处于连通状态；在网络处于中断的情况下，如果连续n组测试帧的丢包率都小于Ca，则网络进入连通状态，反正网络仍然处于中断状态。
图8中形象地给出了网络连通性的判定方法。
网络的可靠性可以按照网络连通的时间段数量/总的时间段数量来计算。
同前文中多点可达EVC的各项参数一样，多点可达EVC的可靠性也是由EVC中所有路径的子集S中各条路径上的可靠性的最低值作为子集S的可靠性。
所有上述约定只针对EVC中的绿色报文。
即EVC承诺转发的最大长度的报文的报文长度，以字节计算。通常这个值需要大于1522字节，而且EVC中所有UNI必须都能支持。
如果进入EVC的报文长度大于这个值，那么这些报文的服务质量将无法得到保证，其承诺带宽也不能保证达到约定值。
UNI有一大堆特征/属性，这些特征/属性可以直接决定运营商向用户CE提供什么类型的服务。不管城域以太网内部是如何实现或者如何构成的，UNI是唯一面向用户可见的元素（EVC对于用户而言都是不可见的）。
这里不得不提到UNI中很重要的一方面，在一个EVC中的多个UNI是可以有不同的属性的，比如某个EVC中所有UNI都是100M全双工的RJ45接口，也有可能某个EVC中的两个UNI一个是100M全双工的RJ45接口，而另一个是1G全双工的光纤接口。
后面我们会逐项了解几种MEF中提到的UNI的服务属性。
UNI的标识完全是运营商定义的一段能够标识这个UNI的字符串，这个字符串应该是全局唯一的标识——这完全是处于管理方便的目的而制定的，通过它运营商可以很容易得到这个UNI所在的物理位置或者其他相关信息，就像汽车的车牌号一样。
每个UNI的物理层属性是为了方便和用户CE设备互通而设定的，我们当然不能指望用户能把他们的光纤接头插到运营商提供的RJ45接口上，所以这个属性也是运营商和用户通过协议定下来的。这个属性主要包括三项：
Speed | Mode | Physical Medium |
10 Mbps | Full duplex | 兼容IEEE 802.3以太网定义中规定的各种介质 |
100 Mbps | Full duplex | |
10/100 Mbps | Auto negotiation | |
1 Gbps | Full duplex | |
10 Gbps | Full duplex |
物理介质这项属性基本上是由城域以太网的接入设备决定的，速度双工这些属性有时也是可以配置的。用户CE设备连接UNI的接口也需要和UNI的物理层属性一致。
毫无疑问，从互连互通的角度出发，UNI接口需要支持所有IEEE 802.3上定义的所有的帧格式。
即UNI承诺转发的最大长度的报文的报文长度，以字节计算。通常这个值需要大于1522字节，并且不受UNI上各个EVC的MTU长度属性的影响，而且UNI上的各个EVC的MTU长度不能超过UNI的MTU长度。
所谓多EVC服务是指在一个UNI上同时支持多个EVC的服务方式。这种方式有一个典型的应用，如图9中所示：
图9 多EVC服务的一个实例
CE A和B、C、D之间需要分别建立一条点到点EVC，从而实现CE A和B、C、D之间的互通。在一个支持多EVC服务的UNI上，只需要将三条EVC都配置上就可以了，而不需要为CE A再提供两个额外的UNI。
当然在这种情况下，需要在连接CE A的UNI上定义什么样的报文可以进入什么样的EVC，下面我们就讲讲映射规则。
运营商可以根据和用户签订的协议在UNI上配置CE VLAN ID到EVC的映射关系，也就是说到达UNI的报文是按照它们的CE VLAN ID来决定进入哪个EVC的，untagged报文在抵达UNI的时候会被分配一个CE VLAN ID（通常是接口上的PVID），tagged报文的CE VLAN ID必须和用户所标记的VLAN ID一致，VLAN号从1到4095。有一种特例，当CE发送的报文携带的802.1Q tag中VLAN ID为0，这种报文被定义为携带COS优先级的untagged报文，处理方式可以参考untagged报文。如果某个EVC没有定义其CE-VLAN tag保留属性的话，这类报文将和untagged报文一样，在从UNI被发送出去时不携带802.1Q tag。
值得一提的是，在一部分用户的设备上，有一些VLAN是用于一些特殊功能的（比如IRF），这样就导致了这些设备上的VLAN数小于4095。不过这种情况对于城域以太网来说没有什么太大影响，能够到达UNI接口的报文的VLAN ID数不会多余4095个，即使加上untagged的报文，4095个CE VLAN ID也已经足够了。也正由于此，一个UNI上所能绑定的最大EVC数量也不会超过4095个。
勿庸置疑，多个CE VLAN ID可以被映射到一个EVC上。
UNI EVC ID是一串被运营商指定的字符串，用来标识UNI上的不同EVC，以便管理和控制。
每个UNI口上都必须有一张CE VLAN ID和EVC之间的映射表，每个CE VLAN ID至多映射到一个EVC上。
图10 CE VLAN ID到EVC的映射实例
图10示意了一个UNI上的CE VLAN ID到EVC的映射实例，将VLAN 47映射到EVC1，将VLAN 1343映射到EVC2，为untagged报文分配一个CE VLAN ID 17，并映射到EVC3中。当报文从这个UNI进入时将根据其携带802.1Q tag的情况进入不同的EVC，当不同EVC上的报文从这个UNI中被发送出去时，也会带上相应的802.1Q tag。如果报文所携带的802.1Q tag中的VLAN ID没有在映射表中列出，那么这个报文会被丢弃，当然从这个UNI也不会发出的报文也不会携带上述三种CE VLAN ID以外的tag。
在一些情况下，也可以不用专门为每一个CE VLAN ID分配一个EVC，比如说在UNI上做了多到一的绑定，将所有CE VLAN ID绑定到一个EVC中。
由于这个属性还涉及到用户CE设备的能力，所以有时候是需要运营商和用户在协议中规定的。
这个映射的属性仅仅是针对单一UNI有效的，之所以要定义这个属性，一个主要的目的是为了将不同UNI下的VLAN关联起来。因为在部署城域以太网的时候，不同的UNI下的几个相关VLAN的CE VLAN ID可能不同，此时就需要配置这个属性，将两边不同的CE VLAN ID映射到同一个EVC上，以实现两边VLAN的互通。
图11 两个UNI上的CE VLAN ID到EVC映射关系示意图
如图11中，UNI A上收到的VLAN 187中的报文被映射到EVC3上，然后在UNI B上标记上VLAN 1343的tag被发送出去。而EVC1则使能了CE-VLAN tag保留属性，从UNI A上收到的报文被原封不动地从UNI B上被发送出去。
这是用来记录CE VLAN ID到EVC映射关系的一段摘要，类似图13中description一栏所示，方便查阅管理。
顾名思义，这个属性给出了该UNI上最多能够支持多少个EVC，取值在1到4095之间。当然UNI上实际的EVC数量可能小于这个值。
实在不知道怎么译Bundling这个词，只有想当然的翻译成捆绑了。
使能这个属性的端口上必须可以通过配置将若干个CE VLAN ID捆绑到一个EVC中，而这个被捆绑了多个CE VLAN ID的EVC也必须使能CE-VLAN tag保留属性，而且在这个EVC中的所有UNI上被映射到该EVC的CE VLAN ID也必须一样，以保证在转发过程中不会造成用户报文的CE VLAN ID混乱。很多时候，这个属性还会和多EVC（Multiplexing）服务属性同时出现在一个UNI上。
图12中，UNI A和UNI B就使能了捆绑映射，将VLAN 47、48、49三个VLAN映射到EVC1中。同时，这两个端口还支持多EVC服务。
为了描述方便，在运营商和用户的协议里还可以这样规定：
按照图13中的描述，除去2000和2001这两个CE VLAN ID以外，其他CE VLAN ID均被捆绑映射到EVC4中。
这个属性其实就是把UNI上的所有CE VLAN ID——从1到4095全部都映射到唯一的一个EVC中，和前面一样，这个被映射了多个CE VLAN ID的EVC也需要使能CE-VLAN tag保留属性。但是这个属性和多EVC服务属性不能同时出现在一个UNI上，因为已经没有多余的CE VLAN ID可以被绑定在另外的EVC上了。
首先MEF对带宽限制做了一个定义，即在某个参考点上指定的对于进入的报文的长度和频度的一个约定。在这篇文档里，这个参考点就是UNI。
如果在部署了带宽限制属性的UNI上，对某一类型的业务进行限制，那么在这类业务的报文进入UNI后就会被分为带宽限制以内的报文和超出带宽限制的报文。同时带宽限制属性还会对超出带宽限制的报文定义一系列处理方式，比如丢弃或者着色等。
在支持多EVC或者支持捆绑映射的UNI上，运营商可以根据业务需要对这个UNI上的不同EVC或者不同CE VLAN ID的业务配置不同的带宽限制。通常而言，如果在一个UNI对多个业务或多个EVC配置了不同的带宽限制的话，所有这些业务所占用的带宽总和不应该超过UNI的物理带宽上限。城域以太网作为一个商用运营网络，是必须对用户的承诺带宽进行保证，如果UNI的物理带宽上限不能满足用户的带宽要求，最好的方法还是更换高速率的物理介质，而不是计算收敛比。
带宽限制这个属性之所以被关联在UNI下而不是EVC下的一个主要原因在于，一个EVC下有时候会包含很多UNI（如多点到多点EVC），而每个UNI上对于这个EVC的带宽限制都会不同，如果把这个属性和EVC关联起来，在运营商和客户之间签署协议的时候描述起来会比较复杂，而将这个属性关联在UNI下则会方便很多，而且也便于操作。
以下部分是MEF 10中关于带宽限制的定义，这部分和MEF 1中的定义有很大不同，既然MEF 1已经被废除了，那还是参照MEF 10中的标准吧。
带宽限制属性是由6部分描述组成的，这6部分分别是：
l Committed Information Rate(CIR) ，承诺信息速率，单位bits/秒，正常情况下业务的平均速率，大于0。
l Committed Burst Size(CBS) ，承诺突发长度，单位bytes，正常情况下业务的突发报文大小，大于或等于业务中最大报文长度。
l Excess Information Rate(EIR) ，扩展信息速率，单位bits/秒，业务可以占用的扩展带宽，大于0。
l Excess Burst Size(EBS) ，扩展突发长度，单位bytes，占用扩展带宽的业务的突发报文大小，当EIR大于0时必须定义这个参数，大于或等于业务中最大报文长度。
l Coupling Flag(CF) ，耦合标志，一个bool型参数，取值为0或1。
l Color Mode(CM) ，颜色识别模式，只有两个取值，color-blind或者color-aware。
对于那些color-blind的UNI而言，CF没有什么实际作用，所以在color-blind的UNI上，CF可以不用设置。
每个从UNI进入的业务报文都会依照带宽限制的执行准则根据一定的带宽限制算法被判断、标记不同的服务级别：绿色、黄色或者红色。在color-blind和color-aware的UNI上的带宽限制算法是不同的，在color-blind的UNI上，报文所携带的颜色会被忽略，所有报文遵从同样的处理流程；在color-aware的UNI上，报文则会根据其所携带的颜色不同而进入不同的处理流程。UNI必须支持color-blind模式，而color-aware模式则为可选项。
在时间点 tj 上UNI收到第j个报文的长度为 lj 的报文，那么这个报文的服务级别应该按照图12中所示的算法判定：
图14中Bc(t0)=CBS，Be(t0)=EBS。Bc(t)和Be(t)则分别代表在 t 时间点上，承诺和扩展令牌筒中剩余的令牌字节数。
但事实上上述算法只是一套理论上的执行过程，实际的网络设备或许无法完全按照上述过程执行，所以只要设备能够使执行结果和上述算法的结果近似即可。这样我们可以用两个简单的公式来实现类似的效果，即在任何时间段 ti 到 tj 内：
进入UNI的绿色报文数量不超过WG，其中WG≥Bc(ti)+CIR×（tj－ti）；
进入UNI的黄色报文数量不超过WY，其中WY≥Be(ti)+EIR×（tj－ti）；
上述算法主要是针对绿色和红色报文的带宽限制，针对黄色报文的带宽限制方式有两种，CF标志位的作用就是确定该UNI使用哪一种。具体来说，当CF位被置0的情况下，黄色报文的进入速率只要不超过EIR即可；当CF被置1的情况下，黄色报文的进入速率被限制在CIR+EIR减去绿色报文的进入速率。不管采用那种方式，黄色报文的突发速率总不超过EBS。
UNI上对不同颜色的报文的处理方式也是不同的，红色报文会在UNI上被直接丢弃；绿色报文则是必须被保证转发的，在SLS（Service Level Specifications）中需要承诺保证这部分报文的服务质量；黄色报文也会被尽力转发，不过在SLS中不承诺这部分报文的服务质量，报文的延迟、抖动可能很大，甚至会被大量丢弃。
这个属性仅仅申明了整个UNI上的带宽限制，并不对这个UNI上的EVC或业务进行区分，在一个UNI上有入方向和出方向两个方向的带宽限制属性，如图15和图16中，3个EVC以竞争方式共享UNI的带宽上限。
图15 基于UNI的入方向带宽限制属性
图16 基于UNI的出方向带宽限制属性
这个属性为UNI上的每个EVC单独设置带宽限制，任何一个EVC也不能抢占分配给其他EVC的带宽，如图17和图18中，根据需要为每个EVC分配了不同的带宽上限。
基于EVC的带宽限制属性也分为入方向和出方向两种。
图17 基于EVC的入方向带宽限制属性
图18 基于EVC的出方向带宽限制属性
这个属性为指定EVC中各种不同COS的业务单独设置带宽限制，通常这些COS分别代表用户的不同业务，如图19中，在EVC1上为不同的COS定义了3种不同的带宽限制。
和前面一样，基于COS的带宽限制属性也分为入方向和出方向两种。
图19 基于COS的带宽限制属性
在一个UNI口上有可能出现基于EVC的带宽限制和基于COS的带宽限制属性共存的情况，如前文图17中，用户在对EVC1中不同COS的报文制定了基于COS的带宽限制的同时，也可以对EVC2制定基于EVC的带宽限制，这种做法不会造成冲突；但是用户不能再对EVC1制定基于EVC的带宽限制，也不能制定基于UNI的带宽限制，因为这种做法会在不同的模式下造成包含的关系，从而引发混乱。
由于EVC的设计中就包含了用户网络和运营商网络的区分以及不同用户之间的隔离，因此城域以太网可以被认为是相对安全的，如果今后发展中有涉及城域以太网安全方面的问题，MEF们会根据事情的发展考虑对策的。
我们在前文表3中罗列了几种二层控制协议报文，用户可以根据需要在UNI上通过配置来指定对这些报文的处理方式。
l 丢弃：这是一种简单的处理方法，所有二层控制协议报文在到达UNI上后不会从EVC中被转发出去，而是被全部丢弃；当然，这样的话，您也不能指望UNI口上收到任何二层控制协议报文。
l 邻接：如果采用这种方式，CE发出的二层控制协议报文在到达UNI上后就会被终结，整个城域以太网会扮演这个CE的邻居处理这些报文，并且按照这些二层控制协议中的规定和CE进行交互。在CE看来，整个城域网的行为和一台网桥类似。
l 交给EVC处理：采用这种方式，二层控制协议报文会被交给EVC来决定是转发还是丢弃，至于EVC的处理方式，前文章节中已经提到过了。
新浪微博
腾讯微博
豆瓣空间
搜狐微博
QQ空间
腾讯朋友
网易微博
百度搜藏
开心网
告诉聊友