著录项信息
专利名称 | 一种以太网宽带接入系统的用户认证管理方法 |
申请号 | CN01132301.9 | 申请日期 | 2001-11-22 |
法律状态 | 权利终止 | 申报国家 | 中国 |
公开/公告日 | 2003-06-11 | 公开/公告号 | CN1423455 |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | 暂无 | IPC分类号 | 暂无查看分类表>
|
申请人 | 深圳市中兴通讯股份有限公司上海第二研究所 | 申请人地址 | 江苏省南通市海门市北京路600号(行政中心0212室)
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 深圳市中兴通讯股份有限公司,海门市科技发展总公司 | 当前权利人 | 深圳市中兴通讯股份有限公司,海门市科技发展总公司 |
发明人 | 蔡彤军;柏钢 |
代理机构 | 暂无 | 代理人 | 暂无 |
摘要
本发明公开了一种以太网宽带接入系统的用户认证管理方法,通过在楼道交换机的每一个下行端口上建立一个管理通道和一个数据通道分别与最终用户相连,并在楼道交换机上进行认证代理,终端用户通过认证,则由管理通道动态地控制端口的数据通道上用户数据包的允许/拒绝传送,实现用户认证管理。采用本发明的方法由于认证管理不再需要接入服务器,并且只需要对楼道交换机和用户终端进行简单升级就可以实现用户的认证管理,能够节省系统成本,并且组网简单,易于维护。
1.一种以太网宽带接入系统的用户认证管理方法,其特征在于,实现过程如下:
在楼道交换机的每一个下行端口上建立一个管理通道和一个数据通道分别 与最终用户相连;
楼道交换机的控制CPU通过管理通道获取用户的用户名/口令信息,并转换 成标准的Radius协议发送到Radius服务器上,判断最终用户是否能够通 过认证;
如果最终用户通过认证,则Radius服务器向该楼道交换机的CPU发送“分 配给用户的地址信息”,该CPU转发该地址信息给用户,并开启数据通道, 最终用户就能够访问宽带网络;
否则,用户的数据通道始终是关闭的,最终用户因未通过认证将无法访问宽 带网络。
2.根据权利要求1所述的一种以太网宽带接入系统的用户认证管理方法,其特 征在于,所述的数据通道是用来传送上/下行的Ethernet数据,数据通道在 用户未通过认证的情况下是关闭的。
3.根据权利要求1所述的一种以太网宽带接入系统的用户认证管理方法,其特 征在于,所述的管理通道是用来在楼道交换机和用户间传送协议信息,管理 通道始终是开启的,可以动态地控制该端口的数据通道上用户数据包的允许/ 拒绝传送。
4.根据权利要求1所述的一种以太网宽带接入系统的用户认证管理方法,其特 征在于,当用户上线后,系统检测用户是否下线,
当楼道交换机接收到通过客户端发来终端用户下线消息,确定为终端用户正 常下线;
当楼道交换机通过对每一个上线用户定时发送确认消息,如果在一定的时间 内未收到该用户的回应消息,则确定终端用户异常下线。
5.根据权利要求4所述的一种以太网宽带接入系统的用户认证管理方法,其特 征在于,当楼道交换机得知用户已经下线,通知Radius服务器该用户已经 下线,并完成IP地址回收和上网时间的计算,同时关闭该用户的数据通道。
所属领域\n本发明涉及一种城域网中用户接入的认证管理方法,属于宽带接入领域,特 别是涉及一种以太网接入时,在以太网交换机上实现用户认证的方法。\n背景技术\n在目前的城域网建设中,大量采用FTTx+LAN的组网方式。其对接入用户的 认证管理的实现主要采用宽带接入服务器(BAS)和PPPoE的方法。参考图1所 示网络示意图:\n1)宽带用户的计算机具有10/100M自适应网卡;\n2)楼道交换机(BAN)为10/100M自适应的以太网交换机。\n3)小区的中心交换机(ZAN)为下行100M,上行1000M的以太网交换机。\n4)汇聚层网络通过宽带接入服务器连接各个小区的中心交换机,通过 PPPoE的方式对用户进行认证,并对用户IP数据进行路由。\n5)城域网中心有Radius服务器,完成用户实际的认证、鉴权功能。\n宽带接入服务器BAS(Broadband Access Server)提供对用户计算机发来的 PPPoE协议数据包的终结功能,并与Radius服务器通信,对用户进行必要的认 证,最终,通过认证的用户数据包在宽带接入服务器上解开PPP封装,以纯IP 包的形式路由到骨干网上;对于下行数据,由于从骨干网上下行到宽带接入服务 器的数据是纯IP包,因此,宽带接入服务器需要对该IP包进行PPP和PPPoE协 议封装,并发送给最终用户计算机。\n但是,采用宽带接入服务器和PPPoE技术的用户管理方式也带来了一些问 题:\n1)由于宽带接入服务器要终结大量的PPP会话,并转发IP数据包,会造成 BAS成为网络性能的巨大瓶颈;\n2)宽带接入服务器通常放置在端局的位置,以下是巨大的广播域,从用户 的安全性考虑,需要通过VLAN技术来实现用户的隔离,但是目前的设 备标准只能支持最大4096个VLAN,无法支持端局以下巨大的用户群体 (超过4096);\n3)PPPoE+VLAN的方式实现用户隔离,由于PPPoE的点到点特性,使城域 网主要的业务方向——组播视频业务的开展受到极大的限制;\n4)由于宽带接入服务器是在通常数据网络设备之外额外增加的设备,采用 宽带接入服务器和PPPoE方式无形之中增加了城域网建设的投资。\n发明内容\n本发明要解决的技术问题是提出一种基于以太网交换机的用户认证管理方 法,具有组网结构简单,业务丰富,高性能,低成本的特点。\n本发明提出的以太网宽带接入的用户管理认证方法,实现的过程如下:\n在楼道交换机的每一个下行端口上建立一个管理通道和一个数据通道分别 与最终用户相连;\n1)数据通道:用来传送上/下行的Ethernet数据,该通道在用户未通过认 证的情况下是关闭的。\n2)管理通道:用来在楼道交换机和用户间传送协议信息,该通道始终是开 启的。由于楼道交换机的每一个下行端口上有管理通道,因此,可以动态 地控制该端口的数据通道上用户数据包的允许/拒绝传送。\n楼道交换机的控制CPU通过管理通道获取用户的用户名/口令信息,并转换 成标准的Radius协议发送到Radius服务器上,判断最终用户是否能够通过认 证;\n如果最终用户通过认证,则Radius服务器向该楼道交换机的CPU发送“分 配给用户的地址信息”,该CPU转发该地址信息给用户,并开启数据通道,最终 用户就能够访问宽带网络;\n否则,用户的数据通道始终是关闭的,最终用户因未通过认证将无法访问宽 带网络。\n本方案可以解决用户认证、用户管理、地址浪费的问题,可以实现按时间或 流量的计费方式。由于用户发送的数据包就是以太网包,不再需要局方购置价格 昂贵的宽带接入服务器设备,也去掉了PPPoE和PPP协议的封装,加快可数据包 处理的速度;同时可以更好地支持组播的业务,避免了在组播应用时,由于PPPoE 的点到点特性,即使几个主机同属一个组播组,也要为每个主机复制一份数据流 的问题。另外,本发明还具有以下的特点:\n1.采用了路由器/L3交换机+L2交换机组网结构,网络结构简单;\n2.各小区分散的路由方式,网络性能没有集中的瓶颈;\n3.支持根据用户时长、用户端口流量的计费方式;\n4.可以根据用户的ID在端口标识不同的优先级,实现对QoS的支持,并可 对以太网端口进行访问速率的限制;\n5.对组播的业务无任何影响;\n6.只需对以太网交换机进行升级,成本低廉。\n附图说明\n图1是现有技术采用的宽带接入服务器和PPPoE方法的网络示意图;\n图2是本发明以太网宽带接入用户认证管理方法的网络示意图;\n图3是本发明以太网宽带接入用户认证管理方法的流程图;\n图4是本发明以太网宽带接入用户认证管理方法的协议交互流程图。\n具体实施方式\n参考图2所示,本发明的以太网宽带接入方法在宽带接入网络的汇聚层采用 通常的路由器实现各个小区流量的汇聚和路由,无需宽带接入服务器设备,所有 的宽带接入功能在小区的楼道交换机(BAN)上分散实现,下面用具体实例展开介 绍本发明的以太网宽带接入方法的实现过程。\n假设可管理的楼道交换机(BAN)为25个端口,其中24个下行端口接用户计 算机,1个上行端口接小区的中心交换机。对于所有的24个下行端口中的每一 个端口,楼道交换机在逻辑上提供一个管理通道和一个数据通道与最终用户相 连。\n附图3所示的本发明以太网宽带接入用户认证管理方法流程在发明内容中已 经做了详细的说明,这里就不再赘述。\n参考附图4的协议流程图,由于楼道交换机的每一个下行端口上都有一个管 理通道,可以动态地控制该端口的数据通道上用户数据包的允许/拒绝传送。用 户的认证请求经过BAN中控制CPU的认证代理后成为Radius请求,经由ZAN、 中心路由器到Radius服务器中进行Radius认证。控制的先决条件就是用户发送 的认证包经过管理通道的代理后,发送到Radius服务器,是否被Radius服务 器认证通过。经过Radius服务器认证判断后的Radius响应经由中心路由器、ZAN 到BAN后,如果认证通过,开启该用户的数据通道,并通知用户认证成功,用户 与BAN之间通过在线检测,即完成了该用户的认证管理过程。下面再针对认证过 程中的报文设计等问题进行具体的说明。\n1.BAN交换机上数据、管理通道的实现\n缺省情况下,在楼道交换机(BAN)的所有24个下行端口的每一个端口上,设 定MAC帧的过滤条件,如下: 序号 MAC源地址 MAC目的地址 动作 1 Any 组播MAC地址 01:00:5e:00:00:01 (对应组播IP地址239.0.0.1) 到BAN的以太网交换机控制 CPU,做进一步协议处理 2 Any Any 阻塞\n序号1实现的是管理通道的功能,当用户向外发出目的地址为组播IP地址 239.0.0.1(组播MAC地址为01:00:5e:00:00:01)的认证请求报文时,该报文被 序号1的过滤条件截获,并送到BAN的控制CPU。认证请求报文为标准UDP报文, 端口号为3080,其净荷部分的协议格式如下:\n 4 bytes\n\n协议版本号 协议类型标志符 未定义 用户名 (40 bytes)\n 口令 (40 bytes) 用户的附加信息 (20 bytes)\n协议版本号,目前为1,协议类型标志符,对于认证请求报文,设定ID=0。\n另外,以太网交换机的控制CPU还可以同时截获到该用户计算机的MAC地址, 便于控制信息的回传。\n2.代理认证过程\n由于在BAN交换机的CPU配置了公网的IP地址,因此,BAN交换机的CPU作为 Radius Client端,将用户侧发来的用户名/口令信息封装成Radius协议报文格式, 通过ZAN和局方的路由器,最终发送给了Radius服务器。在Radius服务器上, 如果该用户名/口令通过认证,则Radius服务器将通过Radius协议报文格式向认 证代理(该楼道交换机)发送分配给用户的地址信息,该协议报文最终被该楼道交 换机的控制CPU获取。\n3.认证成功后的操作\n楼道交换机(BAN)的控制CPU截获了Radius服务器发来的认证协议包,通过检 验其内容,可以获知该用户是否通过了认证。如果:\n1)认证失败:向用户发送认证失败消息,本机不做任何动作。\n2)认证成功:开启该用户对应的数据通道,向用户PC发送分配给它的地址 信息、DNS信息和缺省网关。\n向用户发送的认证成功/失败报文同样采用UDP报文格式,端口号为3080, 其净荷部分的格式如下:\na)认证失败报文\n 4 bytes\n\n协议版本号 协议类型标志符 未定义 认证失败原因标志符\n协议版本号,目前为1;协议类型标志符,对于认证失败报文,ID=1。\nb)认证成功报文\n 4 bytes\n\n协议版本号 协议类型标志符 未定义 分配给用户的IP地址 掩码 网关地址(路由器接口地址) DNS Server的地址 附加信息\n协议版本号,目前为1,协议类型标志符,对于认证成功报文,ID=2\n如果认证成功,用户的数据通道已经被打开,同时用户得到了IP地址信息, 这样用户就能够访问宽带网络了。\n4.用户下线检测\n当用户上线后,为了检测用户是否下线,需要提供两种机制:\na)用户正常下线\n在这种情况下,用户通过客户端向楼道交换机发送disconnect消息,告之 用户下线,该协议包采用UDP报文格式,端口号为3080,其净荷部分的格式如 下:\n 4 bytes\n\n协议版本号 协议类型标志符 未定义\n协议版本号,目前为1,协议类型标志符,对于disconnect报文,ID=3\nb)用户异常下线\n此情况是由于用户在上线的情况下突然关机等原因而引起的。为了检测 用户是否异常下线,需要提供必要的keepalive机制。\n在楼道交换机上,对于该交换机上的每一个上线用户,该交换机每隔 HelloInterval,向该用户发送一个keepalive报文,如果在DeadInterval 的时间内未收到该用户的回应keepalive报文,则认为用户已经下线。\n下面是keepalive的报文格式:\n 4 bytes\n\n协议版本号 协议类型标志符 未定义\n协议版本号,目前为1,协议类型标志符,对于keepalive报文,ID=4。\n无论通过哪种方式检测出用户已经下线,楼道交换机都要通知Radius Server,该用户已经下线,完成IP地址回收和上网时间的计算;同时,还必须 关闭该用户的数据通道。\n5.用户端操作\n用户端PC为了与楼道交换机进行协议交互,要求用户端能够完成以下功能 的处理:\n1)发送认证请求报文\n2)接收认证成功/失败报文\n3)如果认证成功,安装新分配的客户端地址、掩码、缺省网关、DNS Server 地址等。\n4)回应楼道交换机发来的keepalive报文\n5)用户下线时发送disconnect报文\n需要说明的是,用户PC初始发送认证请求包时,由于该用户还没有申请到地 址,因此该认证请求包的源地址设定为用户PC上固定设置的地址(地址1)。当楼 道交换机经过代理认证过程,确认用户通过/未通过认证,需要向用户计算机发送 认证成功/失败报文时,该报文的目的IP地址设定为上面所说的地址1,而目的MAC 地址设定为该用户PC的MAC地址,这样,用户PC就可以很好地接收和解释协议包 了。\n一旦用户PC安装了新分配的地址(地址2),用户PC与楼道交换机之间的协 议交互以新分配的地址为源地址。
法律信息
- 2018-01-05
未缴年费专利权终止
IPC(主分类): H04L 12/24
专利号: ZL 01132301.9
申请日: 2001.11.22
授权公告日: 2005.11.23
- 2013-08-14
专利权的转移
登记生效日: 2013.07.22
专利权人由中兴通讯股份有限公司变更为海门市科技发展总公司
地址由518057 广东省深圳市南山区高新技术产业园科技南路中兴通讯大厦法律部变更为226144 江苏省南通市海门市北京路600号(行政中心0212室)
- 2005-11-23
- 2004-10-27
- 2003-06-11
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有引用任何外部专利数据! |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 1 | | 2006-05-27 | 2006-05-27 | | |