网络试点部署方案.docx

网络试点部署方案.docx

《网络试点部署方案.docx》由会员分享，可在线阅读，更多相关《网络试点部署方案.docx（23页珍藏版）》请在冰点文库上搜索。

网络试点部署方案

IPOE试点项目部署方案

一、概述

随着中国电信宽带业务的发展，ADSL/ADSL2+/FTTH/GPON等高带宽接入方式，极大提高了用户网络使用体验，PPPoE目前成为为宽带业务最主要的接入协议。

同时，IP网络的巨大成功以及互联网内容向流媒体发展的趋势，引发了人们将所有智能设备联网的需求，并使得VoIP,IPTV成为电信运营商网络规划和发展的主要议题。

但是，对于新型网络中的设备，例如：

STB、智能手机、数字电视以及掌上游戏机（PSP等）等很难支持PC所采用的内置PPPoE拨号程序，很大程度上限制了新互联网应用的快速推出。

综合各个电信运营商在接入方式上的尝试，为使新型Voice/Video等实时性、永久在线业务得到有效的控制与管理，DSL工作组于2006年开始规划以DHCP技术为核心，紧密结合当今PPPoE通用的RADUIS协议，建立了IPoE解决方案的体系架构。

为提升多业务承载能力，中国电信制定了如下IPOE接入认证规范，同时集团公司统一组织两种方案的试点工作。

（1）《中国电信IPoE接入认证规范－Session级IPoE分册》：

对用户接入实现“BRAS集中控制用户会话，先认证后分配IP地址”的可精细化控制和运营级接入认证方式。

具有可管可控，高安全性。

（2）《中国电信IPoE接入认证规范－非Session级IPoE分册》：

对DHCP协议进行增强，实施用户认证，增强安全性。

在2011年，XX电信将在YY城域网精品网层面试点部署非Session级IPOE项目以承载IPTV等精品业务，为后期的全面推广打下坚实的技术基础。

二、IPoE定义

2.1定义

IPoE技术是由DSL论坛WT-146推荐的一种新形式的接入认证方式，它是基于DHCP协议转换为RADIUS认证报文来实现用户接入认证与控制。

为获取用户MAC地址和接入设备端口等信息，在接入设备中插入DHCPOption82选项，取代了嵌入在用户终端内的PPPoE拨号软件，将获取所需的接入信息机制前移到网络接入设备中，从而使用户终端继续保持其原有的通用性和灵活性，为IP网络向多业务承载的演进，提供必要保障。

IPoE实际上是直接通过以太网传送宽带业务流量，而不采用PPP封装。

这种新的会话管理方式主要依靠DHCP为用户终端分配IP地址，原本并不支持链路建立、用户认证和链路监控等功能。

利用DHCP扩展以及其它协议（例如EAP），这种方法可以提供类似于PPPoE的功能。

2.2IPoE定位

在宽带网络中提供的主要业务可以归纳为两类，一类是为用户提供高速上网服务的公众业务，另一类是为用户提供IPTV、NGN电话等增值服务的精品业务。

目前，前一类业务一般都通过PPPoE接入方式为用户提供服务，而且当前宽带网络上部署的绝大多数接入设备也都是提供PPPoE接入方式；对于后一类业务，业务开展的初期，为了尽量减少对现有网络的改造，通常也采用PPPoE的接入方式。

但是，与公众业务一般只注重QoS的带宽属性不同，精品业务通常对链路的抖动、延迟等参数具有特殊要求，因此在QoS控制上需要更为精细，同时，一些精品业务（例如IPTV）还要求接入网络具备高效的组播功能。

虽然当前普遍使用的PPPoE接入方式能够在QoS控制方面达到精品业务的要求，但是在提供高效的组播能力方面却是先天不足。

而IPoE则在这两个方面都可以提供满足业务要求的特性。

IPoE具有同时支持公众业务和精品业务的能力，从技术上讲可以采用IPoE来支持现有的各种宽带业务。

但是，从宽带网络的部署和业务现状来看，为了保证网络和业务的平滑过渡，同时避免公众业务影响精品业务的提供，公众业务仍然通过PPPoE接入方式以及现有的宽带接入设备（BRAS）网络基础设施提供，而精品业务则通过IPoE接入方式以及正在部署的业务路由器（SR）网络基础设施提供。

在未来IP承载网络部署和宽带业务发展成熟的情况下，可以考虑将目前公众业务和精品业务分别采用PPPoE和IPoE两种接入方式在独立网络平台承载的模式逐步过渡为采用统一网络平台承载的模式；而接入方式也可以由过渡为在业务路由器单一网络平台上同时支持PPPoE和IPoE，分别支持公众业务和精品业务，继而发展为完全通过IPoE支持所有的业务。

三、IPoE总体流程

3.1业务流程

3.1.1用户接入流程

IPoE用户接入处理流程如下：

（1）用户终端发起DHCP请求，携带相应的Option60信息；

（2）中间途经的网络设备根据相关规范标记Option82信息；

（3）BRAS/SR收到用户请求报文，标记相应的Option82信息（如果有需要）；同时直接转请求报文中继转发给相应的DHCPServer；

（4）DHCPServer收到用户请求报文，提取请求报文中的相关信息，构造认证所需Username和Nas-Port-ID。

现阶段建议Username由MAC地址和Option60信息形成，格式为：

MAC@Option60；密码为任意字符串；并将Option82信息转换为NAS-Port-ID信息，送到Radius认证。

此外，DHCPSERVER与AAA之间也可采用私有协议实现用户接入认证；

（5）Radius对用户进行认证，如认证不通过，则返回拒绝报文，DHCPServer回复DHCPNack报文；如认证通过，则向DHCPServer发回认证通过信息，并携带用户一些相关属性；

（6）DHCPServer根据用户不同的业务信息分配相应的地址；用户可以正常使用业务。

3.1.2用户下线流程

用户主动发起下线请求，流程如下：

（1）用户终端主动发起DHCPRelease；

（2）BRAS/SR收到用户的DHCPRelease，向DHCPServer转发DHCPRelease消息；

（3）DHCPSever收到用户的DHCPRelease，向用户发出DHCPAck报文，确认用户下线，清空相应IP-MAC表。

3.1.3用户续租流程

用户终端根据DHCP标准协议规范，在规定的时间内向DHCPServer发起地址续租请求，流程处理如下：

（1）终端根据DHCP协议规范，在续租时间点发起续租请求；

（1）BRAS/SR收到续租请求，转发给DHCPServer；

（2）DHCPServer处理用户的续租请求，更新地址续租信息，处理完成后，返回DHCPACK信息；

（3）BRAS/SR收到续租确认的ACK信息，转发给用户终端；

（4）用户终端收到续租确认的ACK信息，更新地址续租状态；续租过程完成。

3.1.4用户异常掉线处理

用户使用业务过程中，经常直接拔掉网线，不按照常规发送下线请求，网络设备只能简单地对这类用户行为进行处理，处理流程如下：

（1）用户异常掉线；

（2）用户流量在ARP表老化时间内，没有收到该用户的流量，则清空该用户的IP-MAC项；

（3）DHCPServer在租约时间内没有收到发过来的续租信息，则在租约时间到期后，清空用户信息，回收相应的IP地址。

3.2认证属性规范

在IPoE业务流程中，使用了大量的认证属性，其中Username和NAS-Port-ID在认证过程中尤其重要，下面将对这两个属性中使用到的MAC、Option60、Option82进行规范。

3.2.1MAC地址

用户合法性认证若采用Username＝MAC@Option60，同时在认证过程中需要校验MAC时，由于在Radius进行认证时MAC地址中间无须携带特殊字符，且特殊字符会导致Radius系统复杂性大幅提高，因而规定DHCPServer发出的Radius报文中，username字段中的MAC地址字段不包含特殊字符。

若认证过程中，不检验MAC，或者采用私有协议进行接入认证，对MAC无要求。

3.2.2Option60

Option60在IPoE认证流程中作为用户业务区分，DHCP处理时，根据Option60分配相应的地址。

Optioin60内容字段的具体格式定义为：

业务名称，如：

iTV，VoIP等。

3.2.3Option82

Option82在IPoE认证流程中，用于标识用户的线路信息，DHCPServer处理时，提取Option82信息形成相应的NAS-Port-ID属性；

对于Option82的规范定义参照《中国电信宽带用户接入线路标识编码格式要求》以及《中国电信PON系统用户接入端口标识编码格式要求》定义，接入线路（端口）标识信息采用Sub-option1（即AgentCircuitIDSub-option）承载。

DHCPServer处理Option82时，同样按照以上规范定义，从AgentCircuitIDSub-option中获取。

3.3IPoE安全防护

单纯的DHCP协议，仅仅考虑了针对用户请求分配IP地址，维持地址分配的状态信息；在安全可靠性方面欠缺考虑，用户可以随意获取地址，随意与DHCPServer进行交互，获取地址前无需进行认证，系统自身也没有相应的攻击防护机制。

IPoE的部署需在安全性和可靠性等方面进行相应的增强。

3.3.1仿冒DHCPServer攻击

仿冒DHCPServer的攻击是，攻击者另外架设DHCPServer，假冒为电信的DHCPServer为用户提供地址分配，扰乱用户正常和电信DHCPServer间的通信，造成用户无法正常和电信DHCPServer交互。

针对此类攻击主要有以下一些方式进行防范：

（1）采用VLAN隔离的方式，实现用户之间的隔离，避免恶意用户私自架设DHCPServer对其他用户的影响；

（2）二层网络开启DHCPSnooping，将下行端口配置非信任端口，在非信任端口上不接受DHCPOffer报文；

（3）采用DHCP认证的相应机制，实现DHCPClient和DHCPServer间的认证；但此种方式需要Client端支持相应的Option及其相关的处理功能。

考虑到业务部署的时候，已经采用的VLAN来标识、区分和隔离用户，如：

PUPV已经实现了用户间的隔离。

是可以有效防止仿冒DHCPServer攻击的。

建议采用此种方式。

全网二层网络开启DHCPSnooping的工作量较大；DHCP认证的方式，需要DHCPServer和DHCPClient端进行相应的支持，需要进行额外的开发，并且用户终端的改造量较大。

3.3.2家庭网关开启DHCPServer

在某些应用场景下，家庭网关下面的某些业务，如：

高速上网采用路由模式，并且要求多终端上网，这时，要求家庭网关开启DHCPServer功能，对内分配地址。

此时，如果iTV采用桥接方式，则家庭网关的DHCPServer可能对其造成影响。

针对这种情况，主要有两种方式进行处理：

（1）采用VLAN隔离的方式，在家庭网关上，iTV和高速上网的端口区分开，分别在不同的VLAN，实现VLAN隔离（此处仅在家庭网关为不同VLAN，家庭网关以上，用户可以采用PUPV）

（2）采用DHCP认证的相应机制，实现DHCPClient和DHCPServer间的认证；但此种方式需要Client端支持相应的Option及其相关的处理功能现阶段部署，建议采用VLAN隔离的方式，目前家庭网关内部的各个业务默认属于不同的VLAN，可以实现VLAN隔离。

3.3.3用户DHCP泛洪攻击

用户DHCP泛洪攻击主要表现为：

用户不断变更MAC地址发起DHCP请求，或者使用相同的MAC地址不断发起DHCP请求。

用户的DHCP请求在DHCPServer上转换为Radius请求报文送到RadiusServer进行认证，对DHCPServer和RadiusServer的压力较大，需考虑相应的保护措施。

需要限制处理DHCP请求的速率；建议支持基于用户级限制处理DHCP请求的数量，实现用户级的控制，有效限制用户的DHCP泛洪攻击。

另外，可以在二层接入网，基于用户的接入端口，限制每用户端口允许的MAC地址数量，配合进行安全控制。

3.3.4用户数据转发层面泛洪攻击

用户数据转发层面的泛洪攻击是最常见的。

恶意用户接入网络后发送大量的攻击报文，进行DoS攻击。

针对这种攻击，暂时在网络层面上，还没有很好的解决方案，存在一定的安全隐患。

3.4地址分配策略

单纯的DHCP协议，在收到DHCP请求后，便分配地址。

但在多业务混合运营的网络中，需要更多的地址分配策略。

在我的e家业务承载网络中，采用DHCP方式获取地址的业务有iTV，VOIP，TR069，WLAN，或许以后的C+W等其他业务。

在网络中，一般不同的业务需要规划使用不同的地址段。

因而，DHCPServer需要针对不同的业务分配不同的地址段，需要支持相应的地址分配策略。

目前，不同的业务采用不同Option60进行区分，DHCPServer需要支持基于giaddr以及Option60实施不同的地址分配策略，分配不同的地址段。

为适应更多地址分配策略的需要，如：

某终端需每次分配相同的地址，某线路上的某设备需分配固定地址，要求DHCPServer能够实现IP地址和MAC地址，Option82信息的绑定等地址分配策略。

因而地址分配策略应能根据业务开展的需要进行相应地制定。

3.5用户业务识别与控制

在非Session级IPoE的方式下，BRAS/SR只是作为用户的普通IP终结，没有相应的IPSession，无法识别用户，只能根据用户VLAN或者规范业务分配的IP地址段进行业务分流。

同时所承载的用户数量和业务流量只能通过规划的手段进行。

3.6业务可靠性

在IPoE业务承载环境中，业务的可靠性主要取决于BRAS/SR，DHCPServer和RadiusServer的可靠性。

这三种网元设备单设备承载的用户量都非常大，需要考虑相应的备份机制。

DHCPServer采用集中部署时，需要考虑到DHCP用户数据库，DHCPServer的热备份，提高可靠性；BRAS/SR采取VRRP方式进行网关保护。

3.7IPoE流程分析

IPoE的流程分析主要包括以下几个方面：

（1）总体流程：

DHCPServer负责将相关Option信息转成Radius属性，与Radius交互，完成用户的接入认证。

对用户异常掉线情况处理不够及时；

（2）标准性与可扩展性：

DHCPServer需要具备RadiusClient的功能；同时DHCPServer串接在BRAS/SR与Radius认证服务器之间，存在在瓶颈问题；

（3）业务区分与承载能力：

没有相应的IPSession，无法识别用户，只能根据用户VLAN或者规范业务分配的IP地址段进行业务分流；

（4）用户识别与业务控制能力：

无法感知用户；无法对用户进行识别，不具备对用户业务进行控制能力；

（5）采用MAC地址作为用户名，具有普遍性，所有采用以太网承载的业务发起DHCP请求均会带有MAC地址；但是，需要将MAC地址输入到Radius认证数据库，以及终端的规范化，IBSS的相关流程改造的工作量相对较大。

四、设备技术要求

4.1对终端设备的要求

IPoE对终端设备的要求主要有以下几个方面：

（1）终端设备需要支持DHCPClient功能；

（2）终端设备必须支持Option60，且Option60字段应可以修改，修改方式可以通过ITMS或者提供相应修改界面；

（3）终端设备发起DHCP请求的业务模块需采用固定MAC地址，即每次发起DHCP请求的MAC地址必须是同一个（MAC地址必须是合法申请的，以保证其唯一性）；

（4）如果一个终端有多个模块需要DHCP获取地址，则这些模块使用的MAC地址必须有相应的规律性；如：

家庭网关有TR069和IAD两个模块需要获取IP地址，则规定家庭网关采用连续的MAC地址，TR069采用第一个，IAD采用第二个；

（5）为方便设备MAC地址录入系统，规定将终端使用到的MAC地址和设备ID相关联，并在终端设备外壳进行标识。

4.2IPoE对DHCPServer的要求

4.2.1Option支持要求

（1）DHCP服务器必须支持根据option60值分配不同IP地址段/池的地址；

（2）DHCP服务器必须支持根据Option82，限制每条线路用户数，增强IP地址安全性；

（3）DHCP服务器应支持一些应用业务的option值；如支持Option120，返回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这些终端，分配各自指定的IP地址段/池；

（3）DHCP服务器应支持支持同一RelayID返回不同地址段/池的地址；

（4）DHCP服务器必须支持根据Option82，限制分配IP地址的数量，增强IP地址安全性。

4.2.3管理功能要求

（1）DHCP服务器必须支持定义模版，作用于特定的子网；如租约时间，网关，DNS，掩码等相关参数的定义以及要求返回Option值定义；

（2）DHCP服务器必须具备良好人机操作界面，应支持分权分域的管理；

（3）DHCP服务器必须支持实时在线检测及查询定位功能；用户上线，能检测相应子网的使用情况；支持输入相关条件，如子网，MAC等信息，能查询出用户，子网的相关基本信息；支持log文件查询；

（4）灵活、方便的地址池管理，回收，实现地址的统一管理、分配、回收，方便业务的部署与调整，提高资源利用率；

4.2.4可靠性与备份要求

（1）DHCP服务器必须具备DDOS攻击的防护功能，基于系统级、基于Option82，基于用户实现防护；

（2）DHCP服务器必须具备良好的备份机制；支持配置文件的备份和还原；支持服务器之间的1：

1和1：

N热备份；

（3）必须支持DHCP系统数据库的备份和还原

4.2.5性能容量要求

（1）DHCPServer必须具备1000session/sec的处理能力；

（2）DHCPServer必须具备百万级的用户接入能力；

4.2.6认证功能要求

（1）必须支持RadiusClient功能；

（2）必须支持将DHCPOption信息转换成Radius属性功能；

4.3IPoE对BRAS/SR的要求

（1）支持DHCPRelay；支持DHCPSnooping；

（2）支持根据Vlan或业务IP地址信息等信息进行业务流量分流。

4.4IPoE对后台系统的要求

4.4.1AAA认证系统

1）认证

Ø后台系统必须支持用户名为MAC@Option60格式，密码为任意

Ø后台系统必须支持DHCP+Web认证方式

Ø后台系统必须支持根据NAS-Port-ID跟用户进行绑定（用户第一次认证通过时绑定）

Ø后台系统应支持根据域名区分业务并执行相关处理

1）其他

Ø后台系统应具备良好的可扩展性，方便实现厂家属性的应用

Ø需支持同一个用户不同的业务会采用不同的MAC地址作为用户名进行认证，配合定义相关的业务策略，在用户业务认证成功后，下发相应的业务策略

Ø后台系统应能具备和支撑系统的接口，实现用户多个业务认证、业务策略数据的同步

4.4.2BOSS系统

Ø应该提供外线放装时输入各业务MAC地址的接口（尽量简化输入操作）；

Ø将输入的MAC地址和宽带用户进行关联（MAC地址作为IPoE的用户名，用于作为网络的接入认证和计费用户名）；

Ø将用户的用户名及业务信息送给Radius认证数据库；

Ø将用户名及相关信息送计费平台；

Ø相关管理信息送给相关的管理系统。

4.5IPoE对宽带接入网的要求

宽带接入网设备主要包括DSLAM、ONU、OLT、楼道、园区、汇聚交换机等；主要为IPoE业务及控制信息提供承载。

在IPoE的控制层面，存在非法用户攻击的网络及非法使用等问题，要求宽带接入网设备实现以下安全控制功能：

（1）根据用户接入端口限制最大MAC地址数量，防止用户伪造大量MAC攻击；

（2）支持DHCPSnooping，实现MAC地址和IP地址的绑定，防止用户盗用地址；另外还可设置不信任端口，防止用户私设DHCPServer；

（3）需根据相关规范实现Option82的标记和添加，为上层业务的认证提供基础。

在IPoE的数据业务层面，IPoE的一个重要应用是为iTV提供承载，可以使得iTV的用户组播业务复制点下移；要求汇聚交换机、OLT、园区交换机支持组播VLAN；ONU，DSLAM，楼道交换机、园区交换机支持跨VLAN组播复制能力。

五、总体方案

5.1部署原则

随着在IP网络上开展多种业务的需求日益增长，IP网络也在增强自身可控、可管理以及QoS等能力的同时不断向IP多业务承载网的方向发展。

对于日新月异的新业务，尤其是需要网络组播能力支持的新业务，例如IPTV，当前大规模使用的PPPoE接入方式已经显现出其不足之处，需要尽快采用新的接入技术来支撑这些新的业务。

IPoE就是一种能够满足多业务支撑需求的接入技术。

与PPPoE不同，IPoE可不再采用用户名/密码方式对用户进行认证和授权，而是利用DHCP协议交互过程中所携带的用户物理或逻辑信息，例如MAC地址、VLAN、Option82（线路信息）等，做为用户标识对用户及其业务进行认证和授权。

在完成DHCP交互流程的过程中，接入设备（SR）会以用户及其业务接入控制点的形式，提取相应的用户信息，与RADIUS服务器进行交互，对用户进行认证并执行业务授权，只有通过认证的用户才能继续完成后续的DHCP流程，获得IP地址。

IPoE接入方式的关键点之一是如何定位和识别用户，即选择什么信息做为用户的标识，从而使得业务管控平台（RADIUS）能够正确识别用户及其业务，并且正确地向接入设备（SR）下发该用户的业务授权。

目前可选择的用户标识信息包括MAC地址、VLAN和Option82等，根据现阶段规划、设备以及测试等方面的情况评估（见下表），建议当前使用MAC地址做为用户的标识。

MAC

VLAN

Option82

资源规划

将MAC地址与用户及其业务对应

将VLAN信息与用户及其业务对应

将Option82携带的线路信息与用户及其业务对应

业务规划

用户终端与业务对应，适合于局方发放终端的业务，例如IPTV、NGN电话

每用户每业务每VLAN

用户的物理或逻辑线路信息与业