网络试点部署方案.docx

1、网络试点部署方案IPOE试点项目部署方案一、概述随着中国电信宽带业务的发展，ADSL/ADSL2+/FTTH/GPON等高带宽接入方式，极大提高了用户网络使用体验，PPPoE目前成为为宽带业务最主要的接入协议。同时，IP网络的巨大成功以及互联网内容向流媒体发展的趋势，引发了人们将所有智能设备联网的需求，并使得VoIP, IPTV成为电信运营商网络规划和发展的主要议题。但是，对于新型网络中的设备，例如：STB、智能手机、数字电视以及掌上游戏机（PSP等）等很难支持PC所采用的内置PPPoE拨号程序，很大程度上限制了新互联网应用的快速推出。综合各个电信运营商在接入方式上的尝试，为使新型Voice/

2、Video等实时性、永久在线业务得到有效的控制与管理， DSL工作组于2006年开始规划以DHCP技术为核心，紧密结合当今PPPoE通用的RADUIS协议，建立了IPoE解决方案的体系架构。为提升多业务承载能力，中国电信制定了如下IPOE接入认证规范，同时集团公司统一组织两种方案的试点工作。（1）中国电信IPoE 接入认证规范Session 级IPoE 分册：对用户接入实现“BRAS集中控制用户会话，先认证后分配IP地址”的可精细化控制和运营级接入认证方式。具有可管可控，高安全性。（2） 中国电信IPoE 接入认证规范非Session 级IPoE 分册：对DHCP协议进行增强，实施用户认证，增

3、强安全性。在2011年，XX电信将在YY城域网精品网层面试点部署非Session级IPOE项目以承载IPTV等精品业务，为后期的全面推广打下坚实的技术基础。二、IPoE定义2.1 定义IPoE技术是由DSL论坛WT-146推荐的一种新形式的接入认证方式，它是基于DHCP协议转换为RADIUS认证报文来实现用户接入认证与控制。为获取用户MAC地址和接入设备端口等信息，在接入设备中插入DHCP Option 82 选项，取代了嵌入在用户终端内的PPPoE 拨号软件，将获取所需的接入信息机制前移到网络接入设备中，从而使用户终端继续保持其原有的通用性和灵活性，为IP网络向多业务承载的演进，提供必要保障

4、。 IPoE实际上是直接通过以太网传送宽带业务流量，而不采用PPP封装。这种新的会话管理方式主要依靠DHCP为用户终端分配IP地址，原本并不支持链路建立、用户认证和链路监控等功能。利用DHCP扩展以及其它协议（例如EAP），这种方法可以提供类似于PPPoE的功能。2.2 IPoE定位 在宽带网络中提供的主要业务可以归纳为两类，一类是为用户提供高速上网服务的公众业务，另一类是为用户提供IPTV、NGN电话等增值服务的精品业务。 目前，前一类业务一般都通过PPPoE接入方式为用户提供服务，而且当前宽带网络上部署的绝大多数接入设备也都是提供PPPoE接入方式；对于后一类业务，业务开展的初期，为了尽量

5、减少对现有网络的改造，通常也采用PPPoE的接入方式。 但是，与公众业务一般只注重QoS的带宽属性不同，精品业务通常对链路的抖动、延迟等参数具有特殊要求，因此在QoS控制上需要更为精细，同时，一些精品业务（例如IPTV）还要求接入网络具备高效的组播功能。 虽然当前普遍使用的PPPoE接入方式能够在QoS控制方面达到精品业务的要求，但是在提供高效的组播能力方面却是先天不足。而IPoE则在这两个方面都可以提供满足业务要求的特性。 IPoE具有同时支持公众业务和精品业务的能力，从技术上讲可以采用IPoE来支持现有的各种宽带业务。但是，从宽带网络的部署和业务现状来看，为了保证网络和业务的平滑过渡，同时

6、避免公众业务影响精品业务的提供，公众业务仍然通过PPPoE接入方式以及现有的宽带接入设备（BRAS）网络基础设施提供，而精品业务则通过IPoE接入方式以及正在部署的业务路由器（SR）网络基础设施提供。 在未来IP承载网络部署和宽带业务发展成熟的情况下，可以考虑将目前公众业务和精品业务分别采用PPPoE和IPoE两种接入方式在独立网络平台承载的模式逐步过渡为采用统一网络平台承载的模式；而接入方式也可以由过渡为在业务路由器单一网络平台上同时支持PPPoE和IPoE，分别支持公众业务和精品业务，继而发展为完全通过IPoE支持所有的业务。三、IPoE总体流程3.1 业务流程3.1.1 用户接入流程IP

7、oE 用户接入处理流程如下：（1） 用户终端发起DHCP 请求，携带相应的Option60 信息；（2） 中间途经的网络设备根据相关规范标记Option82 信息；（3） BRAS/SR 收到用户请求报文，标记相应的Option82 信息(如果有需要)；同时直接转请求报文中继转发给相应的DHCP Server ；（4） DHCP Server 收到用户请求报文，提取请求报文中的相关信息，构造认证所需Username 和Nas-Port-ID。现阶段建议Username 由MAC 地址和Option60 信息形成，格式为： MACOption60；密码为任意字符串；并将Option82 信息转换

8、为NAS-Port-ID 信息，送到Radius 认证。此外， DHCP SERVER 与AAA 之间也可采用私有协议实现用户接入认证；（5） Radius 对用户进行认证，如认证不通过，则返回拒绝报文，DHCP Server 回复DHCP Nack 报文；如认证通过，则向DHCP Server 发回认证通过信息，并携带用户一些相关属性；（6） DHCP Server 根据用户不同的业务信息分配相应的地址；用户可以正常使用业务。3.1.2 用户下线流程用户主动发起下线请求，流程如下：（1） 用户终端主动发起DHCP Release；（2） BRAS/SR 收到用户的DHCP Release ，

9、向DHCP Server 转发DHCP Release 消息；（3） DHCP Sever 收到用户的DHCP Release，向用户发出DHCP Ack 报文，确认用户下线，清空相应IP-MAC 表。3.1.3 用户续租流程用户终端根据DHCP 标准协议规范，在规定的时间内向DHCP Server 发起地址续租请求，流程处理如下：（1） 终端根据DHCP 协议规范，在续租时间点发起续租请求；（1） BRAS/SR 收到续租请求，转发给DHCP Server ；（2） DHCP Server 处理用户的续租请求，更新地址续租信息，处理完成后，返回DHCP ACK 信息；（3） BRAS/SR

10、收到续租确认的ACK 信息，转发给用户终端；（4） 用户终端收到续租确认的ACK 信息，更新地址续租状态；续租过程完成。3.1.4 用户异常掉线处理用户使用业务过程中，经常直接拔掉网线，不按照常规发送下线请求，网络设备只能简单地对这类用户行为进行处理，处理流程如下：（1） 用户异常掉线；（2） 用户流量在ARP 表老化时间内，没有收到该用户的流量，则清空该用户的IP-MAC 项；（3） DHCP Server 在租约时间内没有收到发过来的续租信息，则在租约时间到期后，清空用户信息，回收相应的IP 地址。3.2 认证属性规范在IPoE 业务流程中，使用了大量的认证属性，其中Username 和N

11、AS-Port-ID 在认证过程中尤其重要，下面将对这两个属性中使用到的MAC、Option60、Option82 进行规范。3.2.1 MAC 地址用户合法性认证若采用UsernameMACOption60，同时在认证过程中需要校验MAC 时，由于在Radius 进行认证时MAC 地址中间无须携带特殊字符，且特殊字符会导致Radius 系统复杂性大幅提高，因而规定DHCP Server 发出的Radius 报文中，username 字段中的MAC 地址字段不包含特殊字符。若认证过程中，不检验MAC，或者采用私有协议进行接入认证，对MAC 无要求。3.2.2 Option60 Option60

12、 在IPoE 认证流程中作为用户业务区分，DHCP 处理时，根据Option60 分配相应的地址。Optioin60 内容字段的具体格式定义为：业务名称，如： iTV，VoIP 等。3.2.3 Option82 Option82 在IPoE 认证流程中，用于标识用户的线路信息，DHCP Server 处理时，提取Option82 信息形成相应的NAS-Port-ID 属性；对于Option82 的规范定义参照中国电信宽带用户接入线路标识编码格式要求以及中国电信PON 系统用户接入端口标识编码格式要求定义，接入线路(端口)标识信息采用Sub-option 1（即Agent Circuit ID

13、Sub-option）承载。DHCP Server 处理Option82 时，同样按照以上规范定义，从Agent Circuit ID Sub-option 中获取。3.3 IPoE 安全防护单纯的DHCP 协议，仅仅考虑了针对用户请求分配IP 地址，维持地址分配的状态信息；在安全可靠性方面欠缺考虑，用户可以随意获取地址，随意与DHCP Server 进行交互，获取地址前无需进行认证，系统自身也没有相应的攻击防护机制。IPoE 的部署需在安全性和可靠性等方面进行相应的增强。3.3.1 仿冒DHCP Server 攻击仿冒DHCP Server 的攻击是，攻击者另外架设DHCP Server ，

14、假冒为电信的DHCP Server 为用户提供地址分配，扰乱用户正常和电信DHCP Server 间的通信，造成用户无法正常和电信DHCP Server 交互。针对此类攻击主要有以下一些方式进行防范：（1） 采用VLAN 隔离的方式，实现用户之间的隔离，避免恶意用户私自架设DHCP Server 对其他用户的影响；（2） 二层网络开启DHCP Snooping ，将下行端口配置非信任端口，在非信任端口上不接受DHCP Offer 报文；（3） 采用DHCP 认证的相应机制，实现DHCP Client 和DHCP Server 间的认证；但此种方式需要Client 端支持相应的Option 及其

15、相关的处理功能。考虑到业务部署的时候，已经采用的VLAN 来标识、区分和隔离用户，如：PUPV 已经实现了用户间的隔离。是可以有效防止仿冒DHCP Server 攻击的。建议采用此种方式。全网二层网络开启DHCP Snooping 的工作量较大； DHCP 认证的方式，需要DHCP Server 和DHCP Client 端进行相应的支持，需要进行额外的开发，并且用户终端的改造量较大。3.3.2 家庭网关开启DHCP Server 在某些应用场景下，家庭网关下面的某些业务，如：高速上网采用路由模式，并且要求多终端上网，这时，要求家庭网关开启DHCP Server 功能，对内分配地址。此时，如果

16、iTV 采用桥接方式，则家庭网关的DHCP Server 可能对其造成影响。针对这种情况，主要有两种方式进行处理：（1） 采用VLAN 隔离的方式，在家庭网关上，iTV 和高速上网的端口区分开，分别在不同的VLAN，实现VLAN 隔离(此处仅在家庭网关为不同VLAN，家庭网关以上，用户可以采用PUPV) （2） 采用DHCP 认证的相应机制，实现DHCP Client 和DHCP Server 间的认证；但此种方式需要Client 端支持相应的Option 及其相关的处理功能现阶段部署，建议采用VLAN 隔离的方式，目前家庭网关内部的各个业务默认属于不同的VLAN，可以实现VLAN 隔离。3.

17、3.3 用户DHCP 泛洪攻击用户DHCP 泛洪攻击主要表现为：用户不断变更MAC 地址发起DHCP 请求，或者使用相同的MAC 地址不断发起DHCP 请求。用户的DHCP 请求在DHCP Server 上转换为Radius 请求报文送到Radius Server 进行认证，对DHCP Server 和Radius Server 的压力较大，需考虑相应的保护措施。需要限制处理DHCP 请求的速率；建议支持基于用户级限制处理DHCP 请求的数量，实现用户级的控制，有效限制用户的DHCP 泛洪攻击。另外，可以在二层接入网，基于用户的接入端口，限制每用户端口允许的MAC 地址数量，配合进行安全控制。

18、3.3.4 用户数据转发层面泛洪攻击用户数据转发层面的泛洪攻击是最常见的。恶意用户接入网络后发送大量的攻击报文，进行DoS 攻击。针对这种攻击，暂时在网络层面上，还没有很好的解决方案，存在一定的安全隐患。3.4 地址分配策略单纯的DHCP 协议，在收到DHCP 请求后，便分配地址。但在多业务混合运营的网络中，需要更多的地址分配策略。在我的e 家业务承载网络中，采用DHCP 方式获取地址的业务有iTV，VOIP， TR069，WLAN，或许以后的C+W 等其他业务。在网络中，一般不同的业务需要规划使用不同的地址段。因而，DHCP Server 需要针对不同的业务分配不同的地址段，需要支持相应的地

19、址分配策略。目前，不同的业务采用不同Option60 进行区分，DHCP Server 需要支持基于giaddr 以及Option60 实施不同的地址分配策略，分配不同的地址段。为适应更多地址分配策略的需要，如：某终端需每次分配相同的地址，某线路上的某设备需分配固定地址，要求DHCP Server 能够实现IP 地址和MAC 地址，Option82 信息的绑定等地址分配策略。因而地址分配策略应能根据业务开展的需要进行相应地制定。3.5 用户业务识别与控制在非Session 级IPoE 的方式下，BRAS/SR 只是作为用户的普通IP 终结，没有相应的IP Session ，无法识别用户，只能根

20、据用户VLAN 或者规范业务分配的IP 地址段进行业务分流。同时所承载的用户数量和业务流量只能通过规划的手段进行。3.6 业务可靠性在IPoE 业务承载环境中，业务的可靠性主要取决于BRAS/SR，DHCP Server 和Radius Server 的可靠性。这三种网元设备单设备承载的用户量都非常大，需要考虑相应的备份机制。DHCP Server 采用集中部署时，需要考虑到DHCP 用户数据库，DHCP Server 的热备份，提高可靠性； BRAS/SR 采取VRRP 方式进行网关保护。3.7 IPoE 流程分析IPoE 的流程分析主要包括以下几个方面：（1） 总体流程：DHCP Serv

21、er 负责将相关Option 信息转成Radius 属性，与Radius 交互，完成用户的接入认证。对用户异常掉线情况处理不够及时；（2） 标准性与可扩展性： DHCP Server 需要具备Radius Client 的功能；同时DHCP Server 串接在BRAS/SR 与Radius 认证服务器之间，存在在瓶颈问题；（3） 业务区分与承载能力：没有相应的IP Session ，无法识别用户，只能根据用户VLAN 或者规范业务分配的IP 地址段进行业务分流；（4） 用户识别与业务控制能力：无法感知用户；无法对用户进行识别，不具备对用户业务进行控制能力；（5） 采用MAC 地址作为用户名，

22、具有普遍性，所有采用以太网承载的业务发起DHCP 请求均会带有MAC 地址；但是，需要将MAC 地址输入到Radius 认证数据库，以及终端的规范化，IBSS 的相关流程改造的工作量相对较大。四、设备技术要求4.1 对终端设备的要求IPoE 对终端设备的要求主要有以下几个方面：（1） 终端设备需要支持DHCP Client 功能；（2） 终端设备必须支持Option60，且Option60 字段应可以修改，修改方式可以通过ITMS 或者提供相应修改界面；（3） 终端设备发起DHCP 请求的业务模块需采用固定MAC 地址，即每次发起DHCP 请求的MAC 地址必须是同一个(MAC 地址必须是合法

23、申请的，以保证其唯一性) ；（4） 如果一个终端有多个模块需要DHCP 获取地址，则这些模块使用的MAC 地址必须有相应的规律性；如：家庭网关有TR069 和IAD 两个模块需要获取IP 地址，则规定家庭网关采用连续的MAC 地址，TR069 采用第一个，IAD 采用第二个；（5） 为方便设备MAC 地址录入系统，规定将终端使用到的MAC 地址和设备ID 相关联，并在终端设备外壳进行标识。4.2 IPoE 对DHCP Server 的要求4.2.1 Option 支持要求（1） DHCP 服务器必须支持根据option60 值分配不同IP 地址段/池的地址；（2） DHCP 服务器必须支持根据

24、Option 82，限制每条线路用户数，增强IP 地址安全性；（3） DHCP 服务器应支持一些应用业务的option 值；如支持Option 120， 返回SIP 代理服务器IP 地址或域名；（4） DHCP 服务器应支持特定的option 值；如支持option120/43/61/124/125。4.2.2 地址分配要求（1） DHCP 服务器必须支持给固定的设备分配固定的IP 地址；根据设备的唯一标识，例如MAC+Option60+Option82，每次上线后都获到同一个IP 地址；（2） DHCP 服务器必须支持根据设备类型分配指定的IP 地址段/池；如SIP， STB 这些终端，分配

25、各自指定的IP 地址段/池；（3） DHCP 服务器应支持支持同一Relay ID 返回不同地址段/池的地址；（4） DHCP 服务器必须支持根据Option 82，限制分配IP 地址的数量，增强IP 地址安全性。4.2.3 管理功能要求（1） DHCP 服务器必须支持定义模版，作用于特定的子网；如租约时间，网关，DNS，掩码等相关参数的定义以及要求返回Option 值定义；（2） DHCP 服务器必须具备良好人机操作界面，应支持分权分域的管理；（3） DHCP 服务器必须支持实时在线检测及查询定位功能；用户上线，能检测相应子网的使用情况；支持输入相关条件，如子网，MAC 等信息，能查询出用户

26、，子网的相关基本信息；支持log 文件查询；（4） 灵活、方便的地址池管理，回收，实现地址的统一管理、分配、回收，方便业务的部署与调整，提高资源利用率；4.2.4 可靠性与备份要求（1） DHCP 服务器必须具备DDOS 攻击的防护功能，基于系统级、基于Option82，基于用户实现防护；（2） DHCP 服务器必须具备良好的备份机制；支持配置文件的备份和还原；支持服务器之间的1：1 和1：N 热备份；（3） 必须支持DHCP 系统数据库的备份和还原4.2.5 性能容量要求（1） DHCP Server 必须具备1000 session/sec 的处理能力；（2） DHCP Server 必须

27、具备百万级的用户接入能力；4.2.6 认证功能要求（1） 必须支持Radius Client 功能；（2） 必须支持将DHCP Option 信息转换成Radius 属性功能；4.3 IPoE 对BRAS/SR 的要求（1） 支持DHCP Relay ；支持DHCP Snooping； （2） 支持根据Vlan 或业务IP 地址信息等信息进行业务流量分流。4.4IPoE 对后台系统的要求4.4.1 AAA 认证系统1）认证 后台系统必须支持用户名为MACOption60 格式，密码为任意 后台系统必须支持DHCP+Web 认证方式 后台系统必须支持根据NAS-Port-ID 跟用户进行绑定(用

28、户第一次认证通过时绑定) 后台系统应支持根据域名区分业务并执行相关处理1） 其他 后台系统应具备良好的可扩展性，方便实现厂家属性的应用 需支持同一个用户不同的业务会采用不同的MAC 地址作为用户名进行认证，配合定义相关的业务策略，在用户业务认证成功后，下发相应的业务策略 后台系统应能具备和支撑系统的接口，实现用户多个业务认证、业务策略数据的同步4.4.2 BOSS 系统 应该提供外线放装时输入各业务MAC 地址的接口(尽量简化输入操作)； 将输入的MAC 地址和宽带用户进行关联(MAC 地址作为IPoE 的用户名，用于作为网络的接入认证和计费用户名)； 将用户的用户名及业务信息送给Radius

29、 认证数据库； 将用户名及相关信息送计费平台； 相关管理信息送给相关的管理系统。4.5 IPoE 对宽带接入网的要求宽带接入网设备主要包括DSLAM、ONU、OLT 、楼道、园区、汇聚交换机等；主要为IPoE 业务及控制信息提供承载。在IPoE 的控制层面，存在非法用户攻击的网络及非法使用等问题，要求宽带接入网设备实现以下安全控制功能：（1） 根据用户接入端口限制最大MAC 地址数量，防止用户伪造大量MAC 攻击；（2） 支持DHCP Snooping ，实现MAC 地址和IP 地址的绑定，防止用户盗用地址；另外还可设置不信任端口，防止用户私设DHCP Server ；（3） 需根据相关规范实

30、现Option82 的标记和添加，为上层业务的认证提供基础。在IPoE 的数据业务层面，IPoE 的一个重要应用是为iTV 提供承载，可以使得iTV 的用户组播业务复制点下移；要求汇聚交换机、OLT 、园区交换机支持组播VLAN；ONU，DSLAM，楼道交换机、园区交换机支持跨VLAN 组播复制能力。五、 总体方案5.1 部署原则随着在IP网络上开展多种业务的需求日益增长，IP网络也在增强自身可控、可管理以及QoS等能力的同时不断向IP多业务承载网的方向发展。对于日新月异的新业务，尤其是需要网络组播能力支持的新业务，例如IPTV，当前大规模使用的PPPoE接入方式已经显现出其不足之处，需要尽快

31、采用新的接入技术来支撑这些新的业务。IPoE就是一种能够满足多业务支撑需求的接入技术。 与PPPoE不同，IPoE可不再采用用户名/密码方式对用户进行认证和授权，而是利用DHCP协议交互过程中所携带的用户物理或逻辑信息，例如MAC 地址、VLAN、Option 82（线路信息）等，做为用户标识对用户及其业务进行认证和授权。在完成DHCP交互流程的过程中，接入设备（SR）会以用户及其业务接入控制点的形式，提取相应的用户信息，与RADIUS服务器进行交互，对用户进行认证并执行业务授权，只有通过认证的用户才能继续完成后续的DHCP流程，获得IP地址。 IPoE接入方式的关键点之一是如何定位和识别用户

32、，即选择什么信息做为用户的标识，从而使得业务管控平台（RADIUS）能够正确识别用户及其业务，并且正确地向接入设备（SR）下发该用户的业务授权。目前可选择的用户标识信息包括MAC地址、VLAN和Option 82等，根据现阶段规划、设备以及测试等方面的情况评估（见下表），建议当前使用MAC地址做为用户的标识。 MAC VLAN Option 82 资源规划 将MAC 地址与用户及其业务对应 将VLAN 信息与用户及其业务对应 将Option 82 携带的线路信息与用户及其业务对应 业务规划 用户终端与业务对应，适合于局方发放终端的业务，例如IP TV、NGN 电话 每用户每业务每VLAN 用户的物理或逻辑线路信息与业