端用户ENUM与框架ENUM
端用户ENUM与框架ENUM
标题 端用户ENUM与框架ENUM
作者 张 捷
来源 《通信技术与标准》
发布时间 2005-11-01
摘要 一、ENUM的基本概念
  ENUM(Telephone Number Mapping)的全称为电话号码映射,它定义了一套将电话号码映射为域名的规则,以及在DNS中存储与该域名相关联的信息的方式。这些信息就是用户的各种通信联络信息,他们以NAPTR(Naming Authority Pointer)记录的形式存储。在NAPTR记录中通过“order”和“preference”字段确定各种通信联络手段的优先级。


 
  为了实施ENUM需要在DNS系统中建立相应的解析体系对由E.164号码转换的域名进行解析,该解析体系在逻辑上分为三层,即Tier 0、Tier 1和Tier 2,如图1所示。Tier 0包含的NS(Name Server,定义某个域是由哪个名字服务器负责)记录指向Tier 1注册管理机构,这些NS记录将国家码对应的域授权到Tier 1注册管理机构中。Tier 1包含的NS记录又对一个给定国家码下的具体E.164号码对应的域进行了授权。Tier 1中包含的NS记录指向Tier 2,Tier2中包含实际的与具体E.164号码对应的NAPTR记录。其中Tier 0是由国外组织管理的,对应于Tier 0的服务器分布于多个国家,其中有一台服务器设置在中国。第0层的域名服务器中包含的记录指向ENUM第1层的域名服务器。对应于Tier 1和Tier 2层的服务器是由各国建设和管理的。

二、ENUM的发展概况
  ENUM的想法最初是在1993年提出的,1998年开始在IETF的一个工作组中研究,到2000年9月引起互联网界的广泛关注。目前,ENUM技术已经成为ITU、IETF、ETSI等国际标准化组织的研究热点,很多国家已经开展了ENUM试验。根据截至到2005年6月29日在ITU网站公布的信息,已经有包括荷兰、法国、爱尔兰、芬兰、匈牙利、罗马尼亚、瑞士、奥地利、英国、瑞典、德国、新加坡、泰国和韩国等28个国家在内的国家码被授权注册到ENUM解析系统中,其中也包括我国的国家码“86”,我国的国家码是作为临时授权的,将在2006年6月30日结束。奥地利于2004年12月在全世界首先引入ENUM商用业务,韩国计划今年将预商用业务投放市场,并于2006年实现完全商用。从韩国开展的ENUM试验情况来看,主要的业务都是基于PC或IP电话发起的通讯业务,通过在PC上装载相应的客户端软件或者在IP电话中嵌入相应的程序,如ENUM的搜索程序,用户可以搜索到与某人的ENUM号码相关的业务清单,并进而通过这些业务清单信息与该号码对应的用户取得联系,业务清单中包含的业务有:主页、因特网电话、电子邮件、PSTN电话、移动电话等。此外,还开发了基于ENUM号码的类似MSN的即时消息业务。随着网络从TDM电路交换环境演进到基于IP的分组交换环境,业务提供者希望将岛状发展的各种VOIP业务提供者桥接起来,实现全程IP连接,而不再通过PSTN来连接不同运营者的IP网络,在这个方面ENUM机制可能会发挥重要的作用。

三、框架ENUM产生的背景
  ENUM技术从提出至今已有一段较长的时间,很多国家已开展了相关的研究和试验,但它在全球的商用却并不乐观,最关键的问题是没有杀手级的应用,另外还涉及用户的隐私问题,人们不想将他们的所有联络信息都集合到一个开放的空间中去。ENUM只有在大量的用户注册了ENUM号码之后才是有价值的,但是在业务开始提供的时候,用户数量总是由少到多的,出于隐私方面的考虑,端用户(end user)不太可能将他们的电话号码注册到ENUM中并存储他们自己的与应用相关的信息。没有业务需求的驱动,只有一些用户的申请没有办法衡量是否值得构建基础的DNS框架。为了吸引更多的用户注册ENUM,基于业务驱动的模式,有两种可能的方案来使ENUM的注册和使用最大化:
  第一种方案是在用户注册一个新的基于IP的业务时,在征得端用户的同意后将其注册到ENUM系统中。即借用户使用新的IP业务的机会,将其号码注册到ENUM系统中。但这种方案看起来对于NGN/Telco/VoIP提供者还没有什么用途,因为它依赖于用户的活动,包括注册、插入数据和管理这些数据。这种方案遵从的是一直以来对ENUM的传统认识,即E.164号码是否注册到ENUM系统中由分配了号码的用户本着自愿的原则作出,并赋予用户选择储存最终的NAPTR记录的Tier 2的权利,而且使用公共顶级域(目前暂定为e164.arpa)之下的全球解析体系,即所谓的Golden Tree。
  第二种方案是NGN/Telco/VoIP提供者利用ENUM机制实现选路和寻址。由拥有E.164号码的运营者决定将哪些号码配置到ENUM解析体系中去,以及在该解析体系中与这些号码对应的NAPTR记录的内容,这些内容往往与网络的寻址和选路相关。这就是目前在欧美比较流行的“infrastructure ENUM”或者是“carrier ENUM”的概念,在本文中称其为“框架ENUM”。象第一种方案那样每个用户自愿注册的ENUM在本文中称为“端用户ENUM”(end-user ENUM)。
  这两种方案实际上对应了ENUM所解决的两方面的问题。端用户ENUM方案侧重于利用ENUM解决用户的单一号码接入问题,即可以通过一个号码打电话、发传真或发送电子邮件等。用户的很多信息都存储在互联网DNS中,获得这些信息之后,可以利用这些信息为用户提供各种各样的业务,例如:主叫用户可以根据自己的需要,通过拨单一的接入码,选择与被叫通过电话、传真或电子邮件的方式进行通信联络。被叫用户可以根据自己的需要,确定使用不同的通信手段接受来话等。而框架ENUM方案则侧重于利用ENUM解决寻址问题。此时,ENUM机制作为一种中间机制,实现E.164号码到URI的映射,而URI到选路信息或地址的映射可以根据URI的不同采用不同的方式,例如对于H.323 URI需要由网守完成到IP地址的解析。

四、端用户ENUM
  RFC 3761和 RFC 3403定义了ENUM协议和NAPTR记录。在RFC 3761中有如下规定:
  ● e164.arpa用于提供存储E.164号码的DNS框架。
  ● 本文件描述的这些操作适用于E.164号码。同样的机制也可用于专用拨号计划,如果是这样,专用拨号计划的后缀一定不可以是e164.arpa,以避免与本规范冲突。这种私有用途一定不能称为ENUM。
  从上述规定中可以看出,除E.164外的其他编号计划必须在非e164.arpa域之下实现,而且不能称为ENUM。端用户ENUM就是指传统意义的ENUM,即在公共顶级域之下,国家码的授权须经各国管制部门的确认,号码的注册基于每个用户的意愿。还有一种说法就是“e164.arpa”之下的ENUM。由于目前对于ENUM在全球实施中是否采用“e164.arpa”作为顶级域还存在争论,在本文中为了便于讨论,暂时表述为“e164.arpa”。

五、框架ENUM
(1)概述
  目前关于框架ENUM,IETF还没有一个统一的十分准确的定义。总的来说,大家在谈论的框架ENUM是指运营者基于RFC3761将E.164号码翻译为相应的URI,而这些URI规定了该运营者与其他运营者或业务提供者网络的互连点,通过该互连点发起方与终接方之间建立通讯。它与端用户注册的与其E.164号码相关联的URI完全是两回事。框架ENUM也可由运营者用于提供自己网络内部的选路信息。
  目前运营者使用E.164号码作为他们主要的命名和选路工具,建立框架ENUM可将基于互联网的资源(如URI)与E.164号码链接起来。运营者可以将其管理的所有E.164号码或者是号码段注册,而不必考虑终端用户设备是在互联网上、在基于IP的闭合NGN上,还是在PSTN上。框架ENUM将一个运营者都管理着哪些E.164号码的信息公布给一些对等的组织或者是其他的运营者,它实际上是试图将ENUM用于提供选路的信息(内部选路和网间选路),包括号码携带信息、被叫付费电话以及其他的号码或地址翻译能力、SMS和MMS的选路等等。这些信息是专门由运营者提供的,并且是专门提供给运营者的。端用户既不能接入这些信息,也不能使用这些信息。它不符合自愿加入的原则,可能会根据运营者的需要一次将所有的号码都注册。
  框架ENUM将主要提供两类功能,一类是实现运营者之间的选路,完成到他网实体的选路,该实体可能是一个交换机、一个出口网关或者是到另一个网络的互连点等,它可能在外网上,也可能在公众互联网上。在本文中为了描述方便,将这些实体称为网络的边界元素。另一类功能就是简单的翻译功能,例如为号码携带和被叫付费电话号码提供选路号码,提供SMS和MMS的选路信息。
  在ETISI TR 105 055 “Infrastructure ENUM”中建议了各种框架ENUM的方案,包括:
  ● 内部框架ENUM,仅由某个运营者自己使用;
  ● 共享框架ENUM,由加入的一组运营者公用;
  ● 全球(公共)框架ENUM,由全球公用。每个运营者分别负责自己的框架部分,这样最新信息可以全球接入,包括在全球范围内哪个提供者持有哪个E.164号码,以及最新的携带/停止服务号码信息。
  上述框架ENUM方案都是由运营者控制ENUM的注册以及NAPTR记录的内容,他们不同的地方在于:NAPTR记录信息的接入是仅限于有权控制这些记录的运营者的一些闭合用户群还是能够接入DNS的任何方;掌管这些号码的运营者和其他方是否能够接入同样的信息,即归属运营者查询得到的NAPTR记录与非归属运营者查询得到的NAPTR记录的内容是否一致,因为运营者可以选择建立一个公众的或者是半公众的(闭合用户群)可接入的NAPTR集合由互连方使用,该集合不同于号码归属的运营者内部选路使用的NAPTR集合。
  框架ENUM一般仅涉及号码归属运营者的边缘功能,而不涉及除此之外的其他的信息,URI所对应的点并不是用户的设施或者是终端,而是运营者为很多用户提供服务的网络元素,例如类似PSTN中的端局交换机。这样也就是说在这种方案中不会暴露个人的标识信息的问题。
  端用户ENUM和框架ENUM可能会在网络中同时存在,有可能端用户和运营者都为同样的能力(例如SIP)分别在他们的Tier 2配置了不同的NAPTR记录。在这种情况下,可能会由发起ENUM查询的客户端决定使用哪一个记录建立通讯。
(2)框架ENUM的顶级域问题
  采用全球共享的名字空间方式实现框架ENUM提出了采用什么域作为顶点的问题。ETSI认为e164.arpa名字空间对框架ENUM是不合适的。主要理由为:
  ● e164.arpa域受到ITU、IAB和RIPE NCC之间达成的程序以及管制部门的限制,如果框架ENUM仍然采用e164.arpa,则同样的限制会应用于框架ENUM;
  ● e164.arpa通常是遵从自愿的原则管理的。只有用户明确表示同意之后,他/她的号码才会被注册,如果框架ENUM采用同样的原则,这对运营者来讲是非常不切实际的;
  ● 运营者在框架ENUM中公布的信息对公众开放的可能性不大。它可能包含边界网关的具体信息,而这些边界网关是无法从公众因特网达到的。向公众分发这些信息可能会暴露运营者网络的拓扑结构和运营情况。
  而另一种观点则认为应该选择e164.arpa之下的其他域。持这种观点的一方认为运营者可能会对框架ENUM非常感兴趣,因而会马上就开始建设基础框架。如果强制运营者单独实现框架ENUM,他们肯定会这样做,但是他们将不会将自己的资源用于建设端用户ENUM。其次,如果将框架ENUM作为由政府管理的在e164.arpa之下实施ENUM的一部分,框架ENUM很可能演进为一种帮助解决号码资源优化问题以及培育市场竞争的工具。
(3)框架ENUM可能的演进路径
  目前在软交换的组网中已经面临着如何组织路由信息的问题,可以采用位置服务器的方式,将路由信息放置在位置服务器上,位置服务器之间可以形成分层结构,软交换可以配置一个首选位置服务器及一个或多个备份位置服务器,软交换向位置服务器发送地址解析请求,地址解析在位置服务器上完成。位置服务器之间实现路由信息的共享和互通,同一域内的位置服务器实现数据同步,未知路由向上层转发。也可以采用在组网中引入转接软交换的方式,转接软交换需要提供地址解析功能,即根据被叫软交换的E.164号码和/或Tel URI和/或SIP URI解析出呼叫下一跳节点所对应的IP地址。而框架ENUM概念的引入,给运营者又提供了第三种选择。利用ENUM机制,将路由信息存储在DNS中,根据运营者的需要,该DNS可以是构建在自己的专网中的,也可以是构建在几个运营者的共享网络中的,甚至可以是在公共互联网上的。在实际的实施中,框架ENUM的构建很可能是一个逐渐演进的过程:
  第一步:专用框架ENUM且运营者的IP网不互连,不同运营者的IP网通过PSTN/ISDN/PLMN互连。
  最初,运营者建立内部的框架ENUM满足本企业内部的选路要求,即在他的企业内部网络(Intranet)建立起框架ENUM要求的完整的DNS体系,包括内部的顶点、Tier 0、Tier 1、和Tier 2(在大多数情况下,它们可能会合并为一个数据库),还有内部的注册功能。NAPTR记录中包含的信息可以是用户的目的地地址,也可以是PSTN/ISDN的选路信息,是否包含网间互通的选路信息由运营者决定。
  第二步:专用框架ENUM且运营者的IP网互连。
  运营者通过双边协议以及一些边界元素(如网关等)将他们的基于IP的网络与其他运营者的基于IP的网络互连起来。根据需要,边界元素可能会完成NAT、防火墙以及网间的协议和编码转化等功能。与那些不提供基于IP的互连点的运营者的连接仍然通过PSTN/ISDN/PLMN。此时,运营者仍然使用在内部网络建立起来的专用框架ENUM。Tier 2(NAPTRS)中包含的信息给出内部的目的地、基于IP的选路信息或者是PSTN/ISDN的选路信息。
  第三步:共享框架ENUM且一组运营者之间存在外网。
  一组运营者的各企业内部网通过边界元素被连接起来,此外,运营者还有原来就存在的到PSTN/ISDN/PLMN的连接以及双边的IP连接和到外网的连接。这些边界元素可根据需要完成企业内部网和该组运营者共享的外网之间的NAT、防火墙、协议和编码转换功能。此时,这些运营者可在他们共享的外网范围内,建立共享框架ENUM,需要在外网范围内有一个共享的顶点,一个共享的Tier 0/1,以及共享的外部注册系统。共享Tier 1的NS记录指向参加外网的运营者的Tier 2名字服务器。运营者的Tier 2名字服务器被连接在外网上,且包含该运营者掌管的E.164号段的NAPTR记录,这些NAPTR记录包含指向相关的入口网关的URI。
  运营者在它的内部网中仍然有完整的框架ENUM。唯一的不同是他现在可以仅保存由他自己持有的号码的条目。所有其他不是他自己持有的号码的条目都可以删掉,或者是替换成隐含的条目,例如从内部指向边界元素。在运营者企业内部网中的框架ENUM DNS与在外网上的共享框架ENUM DNS是重叠的。因此,如果一个运营者A在他的企业内部网中查询ENUM,他总是查询他自己的框架ENUM。如果他查询一个他自己持有的号码,他从自己的框架ENUM数据库中得到答案。如果他查询一个他不持有的号码,他自己的框架ENUM DNS将会把这个查询传递给外网,并且从持有该号码的运营者B运营的Tier 2获得答案。如果运营者B查询一个运营者A持有的号码,他会从连接在外网上的ENUM Tier 2名字服务器获得答案。该答案可能会与运营者从内网中查询专用框架ENUM DNS得到的答案不同。这种方式就称为分离DNS(split DNS)。在企业内部网中的框架ENUM DNS仍然是在运营者的完全控制之下,该框架ENUM的Tier 0和Tier 1注册管理机构由参加该组共享框架ENUM的运营者共同控制,在外网中的ENUM Tier 2名字服务器也是在运营者的控制之下。这种实现方式要求提供运营者共享的Tier 0/1且需要在之前就如何建立它们达成共识。
  第四步:在全球共享外网(或者是因特网)范围内的公共框架ENUM。
  在第三步中,外网由一组运营者创建和共享,其他组运营者也可以建立他们自己独立的外网。如果这些组运营者决定建立一个共享的外网,则存在两种可能:
  a) 这些组决定保留他们的共享外网并且在其上叠加一个新的公共共享外网。
  b) 这些组决定将他们的共享外网合并。这是一种更简单的方式。但是可能会带来一些问题,因为可能会出现重复的IP地址、重复的注册管理机构和/或域名空间。因此,比较好的做法是从一开始就规划一个公共的、全球共享的外网。
  一组运营者可能会从开始就决定使用公众因特网作为共享网络,或者是两个外网要合并,相应的两组运营者决定使用因特网作为公众“共享”框架ENUM。从理论上讲,任何域都可以作为框架ENUM Tier 0/1的顶点,因此,如果没有确定一个公共的顶级域,可能会出现多个公共框架ENUM系统。

六、端用户ENUM与框架ENUM的比较
  端用户ENUM与框架ENUM的主要区别如表1所示:


七、研究进展
  ETSI和美国的ENUM论坛都在研究框架ENUM,IETF ENUM工作组也曾讨论过框架ENUM的草案。在最近一次IETF的会议(第63次会议)上,ENUM工作组对框架ENUM的相关问题进行了讨论,并同意将其列入工作组的工作项目。会议上还对非最终NAPTR的方式进行了讨论,下一步可能要对RFC 3761进行修改和完善,将相关内容补充到该文件中去。
  最终NAPTR的方式下,在Tier 1中的记录如下面这个例子:
  $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
  IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information @foo.se!i"
  IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information @foo.se!i"
  所谓的非最终NAPTR方式是指在Tier 1中不使用NS记录指向Tier 2名字服务器,而是使用DDDS(Dynamic Delegation Discovery System)的置换能力允许非最终的NAPTR记录为不同域的最终NAPTR产生新的DNS查询,也就是说在Tier 1中,一个号码对应的记录可能是这样的:
  $Origin 6.9.0.3.1.0.2.6.0.1.6.8.e164.arpa.
  IN NAPTR 100 50 "" "E2U+user"   ""   6.9.0.3.1.0.2.6.0.1.6.8.joesenum.com
  IN NAPTR 100 50 "" "E2U+carrier"   "" 6.9.0.3.1.0.2.6.0.1.6.8.telco.net
  即号码+86 10 62013096的用户和为该号码提供服务的运营者分别为该号码注册了NAPTR记录,第一个记录会导致向E.164号码的端用户指定的名字服务器发起查询,第二个记录则导致向负责掌管该E.164号码的运营者指定的名字服务器发起查询。此时Tier 1 NAPTR记录是非最终的,因此这两个记录在“enumservice”域中都不包含具体的通讯协议类型(例如“sip”)。具体的通讯业务的NAPTR记录仅在用户或运营者指定的名字服务器中提供,而在这些服务器中才包含最终的NAPTR记录,且其中会包含enumservice的说明,例如SIP,即“E2U+sip”。
  虽然在Tier 1中配置了两个记录,但每个记录的权限是非常清楚的。E2U+user记录由分配了E.164号码的端用户控制,而且仅在该用户的要求之下才能够配置。该用户在竞争的环境下有权选择名字服务器(Tier 2)提供者。而E2U+carrier记录由负责掌管相关E.164号码的运营者控制。端用户和运营者可以在他们各自的域中配置不同的NAPTR记录。在这种情况下,由发起ENUM查询的客户端负责获得所有的(或者是尽可能多的)ENUM记录,并且决定使用哪一个发起通讯。


Copyright©2002-2019  中国通信标准化协会版权所有  联系我们 | 意见反馈
网站备案:京ICP备05002969号-1 网站维护:通信标准化推进中心 (010)82054513, webmaster