CN102143037B - 一种处理报文的方法和装置 - Google Patents

Abstract

本发明实施例涉及通信技术领域，公开了一种处理报文的方法和装置，其中该方法包括：第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；上游邻居管理将接收到的报文发送给核心处理实例；所述核心处理实例根据接收到的所述报文，执行业务处理，生成处理后的第一报文；所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将处理后的第一报文通过第二套接字发送给下游节点。采用将RSVP实例划分为NM和CORE两部分，从而大大提高了RSVP实例所支持的LSP数量。

Description

一种处理报文的方法和装置

技术领域

本发明涉及通信技术，具体涉及一种处理报文的方法和装置。

背景技术

随着人们对通信需求在不断增长，导致网络规模越来越大，提供商边缘(Provider edge，PE)节点越来越多。而且，网络扁平化的趋势也使得每一层的网络规模在变大。在大规模网络下，如何规划流量，使得网络整体利用效率提高，是关系到运营商投资收益的重要问题。另外，差异化服务是运营商营销的重要策略，如何在同一张网络中提供差异化服务，直接关系到运营商市场的成功与否。同时，随着市场竞争激烈化，用户要求也越来越高，其中高可靠性的通信质量是至关重要的，这种要求反映到到网络技术上，就是PE之间通信如何保证服务质量(QoS，Qualityof Service)和可靠性。

流量工程(TE，Traffic Engineering)技术能很好的满足上述要求。TE能指定显式路径，满足用户网络规划的需求；TE通过区分服务流量工程(DS-TE，Diffserv Traffic Engineering)，可以提供差异化服务；TE支持快速重路由(FRR，Fast Reroute)、端到端保护，能满足不同层次的可靠性需求。但是随着网络的规模变大，TE扩展性不足的情况开始呈现：由于TE是软状态刷新协议，每条标签交换路径(LSP，Label-Switch Path)的状态块需要定期刷新，限制了单个资源预留协议(RSVP，Resource Reservation Protocol)实例能够支持的LSP数量，并且，每条LSP都需要占用状态块，耗用内存资源，也限制了单个RSVP实例能够支持的LSP数量。

现有技术采用标签分发协议(LDP，Label Distribution Protocol)叠加在TE上(LDP over TE，Laber Distribution Protocol over TE)，来减少单个RSVP实例中的LSP的数量，如图1所示，LDP over TE技术的特点是：在网络的核心节点部署TE，在边缘节点部署LDP。这种方式既具有部分TE的特点，又能够避免网络过大带来的TE扩展性问题。但是，在LDP区域不能实现带宽预留功能，因此，不能在PE节点间提供完整的流量规划，也不能提供差分服务，降低数据传输的可靠性。

也可以采用TE层次化的方法来减少核心节点或者RSVP实例中的状态块的数量和开销。如图2所示，提供商(P，Provider)节点之间可以先建立互联的TE隧道，PE之间互联的隧道可以叠加在P节点之间的隧道上，这样PE之间的TE隧道仅在相近的两个P节点上存在控制块和刷新开销。当两个PE需要通信时，两个PE之间的P节点已经建立互联TE隧道作为底层隧道，两个PE节点的互联隧道的状态块和刷新仅被与PE相连的P节点感知，其他P节点不感知。该方案采用TE层次化技术需要以网络拓扑层次化作为基础，本质上需要引入更多的设备，去分担PE互联带来的大量LSP，不能从根源上解决单个RSVP实例不能支持大量LSP的问题。

发明人在实现本发明的过程中，发现现有技术至少存在的缺陷是：单个RSVP实例支持的LSP数量非常有限，严重影响网络侧对数据的传输速度，需要增加网络设备，造成网络布局复杂，成为扩大网络规模的瓶颈。

发明内容

本发明实施例提供的一种处理报文的方法和装置，克服了现有技术中单个RSVP实例支持的LSP数量非常有限，严重影响网络侧对数据的传输速度的缺点。

本发明实施例提供了一种处理报文的方法，包括：

第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；

上游邻居管理将接收到的报文发送给核心处理实例；

所述核心处理实例根据接收到的所述报文，执行业务处理，生成处理后的第一报文；

所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将处理后的第一报文通过第二套接字发送给下游节点。

本发明实施例还提供了一种处理报文的装置，包括：第一套接字，上游邻居管理，核心处理实例，下游邻居管理，和第二套接字；

所述第一套接字，用于接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；

上游邻居管理，用于接收第一套接字发送的报文，将接收到的报文发送给所述核心处理实例；

核心处理实例，用于接收上游邻居管理发送的报文，执行业务处理，生成处理后的第一报文；将所述处理后的第一报文发送给下游邻居管理；

下游邻居管理，用于接收所述核心处理实例发送的处理后的第一报文，将所述处理后的第一报文发送给第二套接字；

第二套接字，用于接收下游邻居管理发送的处理后的第一报文，将所述处理后的第一报文发送给下游节点。

本发明实施例提供的一种处理报文的方法和装置，通过采用将RSVP实例划分为NM和CORE两部分，实现对上游节点发送的报文的处理，可以灵活的扩展NM和CORE的数量，且可以将业务更合理的分配到多个CORE中，从而大大提高了RSVP实例所支持的LSP数量，且大大提高了RSVP的工作效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为LDP over TE技术的组网示意图；

图2为采用TE层次化方案组网示意图；

图3为建立TE的LSP的网络示意图；

图4为本发明实施例提供的处理报文方法的总体流程图；

图5为本发明实施例提供的处理报文方法的流程示意图；

图6为本发明实施例提供的建立Peer地址与NM关联关系示意简图；

图7为本发明实施例中业务分配器为业务分配CORE操作的示意简图；

图8为本发明实施例提供当装置中NM与CORE数量比为1∶1时，节点的处理流程示意简图；

图9为本发明实施例提供的部署的包括一个NM和多于一个的CORE的装置示意图；

图10为本发明实施例提供的部署的包括多于一个NM和一个CORE的装置示意图；

图11为本发明实施例提供的部署NM与CORE的数量比值为1∶1的装置；

图12为本发明实施例提供的一种装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

图3所示为建立TE的LSP的网络示意图。LSP的建立是由正向的path消息和反向的resv消息来实现的。并且path消息和resv消息会定期刷新。在本实施例中，节点将消息刷新业务按照报文分发规则分配到该节点的一个或者多于一个的邻居管理(NM，Neighbor Manager)实例中，将核心业务处理按照业务分布规则分配到该节点一个或者多于一个核心处理实例中，这种核心处理实例可以称为CORE。其中，核心业务处理是指：在LSP建立过程中，需要本节点进行的资源和表项处理。具体可包括：为LSP分配入标签；为LSP申请预留带宽；将入标签和出标签表项下发到接口板，用于MPLS报文转发等。因此，在一个节点内存在至少一个NM和至少一个CORE，且NM和CORE之间具有对应关系。NM和CORE是根据功能上的不同而划分的，NM和CORE可以分别由相应的独立的硬件资源实现，通常在多核、多主控板、或者多中央处理单元(CPU，Central Process Unit)时，可以充分显现出分布式节点比现有集中式节点的优势。NM的功能是维持软状态刷新，多个NM可以分担刷新的CPU压力，CORE的功能是为LSP分配标签、带宽、下发表项，它需要保存LSP控制块，分布在多个硬件资源上的CORE之间可以分担内存压力，CORE的空闲、繁忙区别可以体现在对其所在的硬件资源的内存使用上。

在对本发明实施例做说明之前，对套接字(SOCKET)进行说明，SOCKET中相当于接口，主要包括三个参数，即通信的目的IP地址、使用的传输层协议(如：传输控制协议(TCP，Transmission Control Protocol))和使用的端口号，应用层和传输层可以通过套接字，区分来自不同网络连接的通信。

为了更好的理解本发明实施例提供的处理报文方法，参考图4至图11及其说明。

图4所示为本发明实施例提供的处理报文方法的总体流程图，该方法包括：

步骤S401：第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理(NM)；

步骤S402：上游NM将接收到的报文发送给核心处理实例(CORE)；

步骤S403：所述CORE根据接收到的所述报文，执行核心业务处理，生成处理后的第一报文；

步骤S404：所述CORE将所述处理后的第一报文发送给下游NM，由下游NM将处理后的第一报文通过第二套接字发送给下游节点。

通过对图4中提供的一种处理报文方法的说明，该方法采用将节点划分为NM和CORE两部分，实现对上游节点发送的报文的处理，由于在一个节点内存在至少一个NM和至少一个CORE，且NM和CORE之间具有对应关系，NM和CORE是根据功能上的不同而划分的，NM和CORE可以分别由相应的独立的硬件资源实现，当有大量的报文需要处理时，可以扩展NM和CORE的数量，使得节点可以支持更多的LSP，同时不会降低该节点的性能。

进一步，该节点还可以实现对下游节点发送的报文的处理，则在步骤404之后，该方法还包括：

步骤S405：第二套接字接收所述下游节点发送的报文，将所述报文发送给下游NM；

需要理解的是，下游节点发送的报文和步骤401中上游节点发送的报文是归属于相同的业务的。

步骤S406：下游NM将所述报文发送给所述CORE；

其中，下游NM将接收到的报文(如resv消息)，发送到该报文所归属的业务所在的CORE中，该CORE与步骤S403中的CORE是同一个CORE。

步骤S407：所述CORE根据接收到的所述下游NM发送的报文，执行业务处理，生成处理后的第二报文；

步骤S408：所述CORE将所述处理后的第二报文发送给上游NM，由上游NM将处理后的第二报文通过第一套接字发送至所述上游节点。

通过对步骤S405至S408的说明，实现对下游节点发送的报文的处理，由于该方法采用将RSVP实例划分为NM和CORE两部分，由于在一个节点内存在至少一个NM和至少一个CORE，且NM和CORE之间具有对应关系，NM和CORE是根据功能上的不同而划分的，NM和CORE可以分别由相应的独立的硬件资源实现，当有大量的报文需要处理时，可以扩展NM和CORE的数量，使得节点可以支持更多的LSP，同时不会降低该节点的性能。

图5为本发明实施例提供的处理报文方法的具体流程图。该方法包括：

步骤501：第一套接字接收上游节点发送的path消息，将该path消息发送给上游NM；

需要理解的是，该节点中可以包括多个NM，则接收到path消息后，节点可以按照报文分发规则将该path消息发送到对应的NM中。具体可以是：按SOCKET中接收报文的端口号将该报文分布到不同NM中；或者按接收报文的目的地址分布到不同NM中；或者按接收报文的源地址分布到不同NM中；或者上述规则的任意组合，将报文发送给对应的NM中。

步骤502：上游NM根据接收到的path消息，建立接收path消息状态块，其中，建立的接收path消息状态块中记录path消息中携带的信息，将path消息上报给CORE；其中，上游NM在接收到的path消息后，可以检查该path消息的合法性，当判断path消息合法后，执行上述建立消息状态块的操作。

其中，步骤502中建立的path消息状态块为接收path消息状态块，后续刷新操作中，该NM根据建立的接收path消息状态块，开启NM中的超时器，接收上游节点定期发送的path消息，当该NM接收到的path消息中携带的信息与当前接收path消息状态块中的信息没有变化时，NM不会将path消息上报给CORE。当该NM接收到path消息有变化时，NM更新接收path消息状态块中的记录，并将path消息上报给CORE。从而减轻了刷新操作对CORE的压力。

RSVP同一条业务需要集中处理，完成资源检查、申请、下发表项等过程。但是同一条LSP的path、resv消息分别来自不同邻居，且这两个消息通常会定向到不同的NM中，所以NM必须能够将相同LSP的消息发送到相同的CORE里进行集中业务处理。从协议定义的角度来看，RSVP处理业务的最小粒度为会话(session)。同一个session下可能存在多条LSP，在清晰共享(SE，ShareExplicit)风格下，这些LSP在同一个节点内和共享出接口时通常需要共享带宽资源(由协议选项决定)。所以在SE风格下NM必须能够保证相同session的消息能定向到相同的CORE中处理。NM也可以以LSP为粒度将消息分发到CORE中，并设立一个集中的资源管理模块，来实现多个CORE中相同session的LSP的带宽共享。将同一session，或者同一LSP的报文发送给对应的同一CORE中进行处理，称为业务分布。步骤502中将path消息上报给CORE的操作可以具体包括：根据业务分布规则，NM将path消息上报给CORE。其中，业务分布规则可以包括：散列(Hash)方式，集中分配方式，或者部署方式其中任一种或者任意组合。

Hash方式是指：按照业务关键字进行hash运算，由hash结果决定执行业务处理的CORE；集中分配方式是指：设立业务分发器构件，将业务均衡的分发到多个CORE；部署方式是指：采用特殊的部署方式，根据部署特点决定将业务定向到CORE。在后续的实施例中会详细说明。

步骤503：CORE根据接收到的path消息，执行生成LSP控制块的处理，生成LSP控制块；其中，执行生成LSP控制块的处理，生成LSP控制块的具体操作可以包括：CORE计算LSP的下一跳，以及出接口，检查该节点是否有足够资源建立LSP，当判断出资源充足后，生成LSP控制块。否则显示建立LSP失败。

其中，LSP控制块用于记录LSP的属性(这些属性来自path消息和resv消息)、记录下游节点给本节点分配的标签(即出标签)，记录本节点为上游节点分配的标签(即入标签)，记录分配的带宽。

步骤504：CORE生成发送给下游节点的path消息，将该path消息发送给下游NM，其中，此处的下游NM可以是与步骤501中的上游NM为同一个NM，也可以是不同于步骤501中的上游NM。

其中，CORE生成发送给下游节点的path消息与接收到的path消息相似，但也有不同，不同在于：路径对象，路径地址等。同理，后续的resv消息有相同的说明。

步骤504中操作，具体可以是：CORE根据报文分发规则将发送给下游节点的path消息发送给下游NM。其中，该报文分发规则具体可以是：按照发送报文的SOCKET的端口号(可以理解为报文的出接口，后续为了便于说明，简称“出接口”)分布到不同NM中；或者按照发送报文的源地址分布到不同NM中；或者按照发送报文的目的地址分布到不同NM中；或者上述规则的任意组合。

步骤505：下游NM接收CORE发送的path消息，建立path消息状态块，将该path消息通过套接字(SOCKET)发送给下游节点，其中，下游NM具体可以通过第二套接字将path消息发送给下游节点。

为了便于和步骤502中上游NM建立的path消息状态块进行区分，将步骤502中建立的path消息状态块称为“接收path消息状态块”，步骤505中下游NM建立的path消息状态块称为“发送path消息状态块”。其中，后续为了维持LSP，定期进行path消息的刷新的操作，由下游NM，根据发送path消息状态块来完成，CORE可以不再干预。

上述步骤501至505是节点对接收到上游节点发送的path消息处理的过程，后续步骤506至510是节点对接收到下游节点发送的resv消息的处理过程，需要理解的是，节点中NM和CROE对resv消息的处理方法与对path消息的处理方法是相似的。下面具体说明节点中NM和CROE对resv消息的处理过程。

步骤506：该节点的第二套接字接收到下游节点发送的resv消息，将该resv消息发送给下游NM；

其中，节点的套接字可以根据报文分发规则，将接收到的报文发送到对应的NM中。

步骤507：下游NM根据接收到的resv消息，建立resv消息状态块，其中，建立的resv消息状态块中记录resv消息中携带的信息，将resv消息上报给CORE；其中，下游NM在接收到的resv消息后，可以检查该resv消息的合法性，当判断resv消息合法后，执行上述建立消息状态块的操作。还需要说明的是，步骤507中的CORE应当和对该resv消息相应的path消息进行处理的CORE相同。

其中，步骤507中建立的resv消息状态块为接收resv消息状态块，后续刷新操作中，下游NM根据建立的接收resv消息状态块，定期的接收下游节点发送的resv消息进行刷新，当下游NM接收到刷新resv消息没有变化时，NM不会将刷新resv消息上报给CORE，当该NM接收到刷新resv消息有变化时，NM将刷新resv消息上报给CORE。从而减轻了刷新操作对CORE的压力。

步骤507中将resv消息上报给CORE的操作，具体可以是：下游NM向节点中的每个CORE发送查询信息，用于查询resv消息归属业务所在的CORE，当其中一个CORE中判断出resv消息归属业务在自身处理时，回复查询响应给该下游NM，从而将resv消息发送给对应CORE；或者，对于节点中设立有业务集中点的，下游NM可以向业务集中点查询resv消息归属业务所在的CORE，从而将resv消息发送给与上游NM绑定的CORE；或者，下游NM根据记录的发送path消息的CORE，将resv消息发送给与上游NM绑定的CORE。在后续的实施例中将会详细说明。

步骤508：CORE根据接收到resv消息，预留资源，生成发送给上游节点的resv消息，其中，发送给上游节点的resv消息中包含自身为上游节点分配的LSP的标签(即入标签)；

LSP是依靠标签进行转发的，下游节点负责给上游节点分配标签，这个标签通过resv消息从下游携带给上游。对于一个节点来说，它收到下游的resv消息，获得出标签；同时它给上游分配一个相应的标签(称为入标签)，通过resv消息发给上游。如果收到一个报文，它的标签是本节点分配的入标签，那么就会把这个标签换成对应的出标签，继续转发给分配该出标签的下游节点。这个过程一直重复直到到达LSP末端。

步骤509：CORE将生成的发送给上游节点的resv消息发送给上游NM；

其中，CORE具体可以根据报文分发规则，将发送给上游节点的resv消息发送给对应的NM。

步骤510：上游NM接收到发送给上游节点的resv消息后，建立resv消息状态块，将该resv消息通过SOCKET发送给上游节点。为了便于和步骤507中下游NM建立的resv消息状态块进行区分，将步骤507中建立的resv消息状态块称为“接收resv消息状态块”，步骤510中上游NM建立的resv消息状态块称为“发送resv消息状态块”，其中，后续为了维持LSP，定期进行resv消息的刷新将由上游的NM，根据发送resv消息状态块来完成，CORE可以不再干预。

通过上述步骤501至步骤510的说明，可以建立一条LSP，后续如果收到相同的LSP的path消息或者resv消息执行刷新，path消息将会被发送到与上述建立LSP时处理path消息的NM中，同理，resv消息也将会被发送到与上述建立LSP时处理resv消息的NM中。上游NM检查resv消息与本地记录状态块是否一致，且下游NM检查path消息与本地记录状态块是否一致，当两个NM判断都一致时，完成一次刷新操作。否则将检查到的与本地记录不一致的消息上报给CORE处理。

通过上述步骤501至步骤510对本实施例提供的一种处理报文的说明，该方法采用将RSVP实例划分为NM和CORE两部分，通过灵活部署NM和CORE的数量，以及NM与CORE的对应关系，使得一个节点上可以支持的LSP数量远远大于现有技术。

为了更清楚的理解上述步骤501、504、506和步骤509中提出报文分发规则，下面详细说明报文分发规则，包括：

第一、报文分发规则可以是接口分布规则。该规则可以通过手工干预或者其它方法，建立RSVP实例中接口与NM的关联关系，并且将该关联关系表发送给CORE和SOCKET。其中，当SOCKE接收到报文时，可以根据接收到报文的SOCKET的端口号(可以理解为该报文的入接口，后续为了便于说明，简称“入接口”)查询关联关系表，SOCKE将报文发送给与入接口对应的NM；当CORE生成处理后的报文时，根据该报文的出接口查询关联关系表，CORE将处理后的报文发送给与出接口对应的NM。

其中，SOCKET和入接口可以是一对多的关系，SOCKET可以根据报文分发规则与多个NM具有对应关系。从SOCKET收到报文后，首先会上送给特定SOCKET，SOCKET需要查询关联表才能确定送给哪个NM进行处理。

CORE获得LSP的出接口的具体操作可以是：LSP的首节点事先算好一条路径(或者用户显式指定一条路径)，路径信息是一串IP地址，通过path消息的显式路径对象(ERO，Explicit path object)携带给沿途各个节点，各个节点可以通过ERO得知出接口；在没有ERO的情况下，CORE实例可以根据LSP的目的地址(在path消息里面会指明)查询本地存储的路由信息中的出接口。

采用接口分布规则时，NM(可以是上游NM，或者下游NM)还执行邻居处理，具体可以包括：产生和接收处理基于接口的哈罗(Hello)消息。具体包括：NM可以为Hello消息建立状态块，处理Hello消息和发送Hello消息，维护Hello消息状态块。当NM超时未收到Hello消息时，判断Hello消息丢失，NM可以停止该邻居的LSP状态块超时器，进入自刷新状态；当邻居之间通过Hello消息在预置的时间内重新连接上，NM可以通知CORE，CORE产生path消息和resv消息协助邻居恢复状态块；如果通过Hello消息在预置的时间内邻居之间无法连接，NM通知CORE，CORE按照协议规定，删除LSP资源和表项，NM也删除自身保留的LSP状态块。

其中，上述LSP状态块超时器是RSVP协议是软状态刷新的协议中规定的模块，每个节点会定时发送path或resv消息给下游或上游节点来“保活”LSP，同样，上游或下游节点会为LSP启动超时器等待LSP“保活”，超时收不到刷新消息就会把LSP删除。

其中，上述自刷新状态是指因为停止了超时器，即使LSP收不到刷新消息，LSP也不会因为超时而被删除，这种状态称为“自刷新状态”。

第二、报文分发规则可以是本地地址分布规则。该规则可以通过手工干预或者其它方法，建立本地地址与NM的关联关系，并且将该关联关系表发送给CORE和SOCKE。其中，当SOCKE接收到报文时，可以根据接收到报文的目的地址查询关联关系表，SOCKE将报文发送给对应的NM；当CORE生成处理后的报文时，根据该报文的源地址查询关联关系表，CORE将处理后的报文发送给对应的NM。其中，目的地址、源地址都可以是本地地址，一个节点有多个本地地址，本地地址与NM的关系是记录在关联关系表中。

这里的本地地址分布规则与接口分布规则相似，本地地址可以唯一关联到一个接口。对于上游节点发送的报文中包括有路由警告(router-alert)选项的(如path消息，path-tear消息，resv-confirm消息)，其目的地址是LSP末节点的标签交换路由器标识(lsr-id，Laber-Switch Router Identity)，中间节点的SOCKET根据接收到的path消息的目的地址(即末节点的lsr-id)查询关联关系表，将该报文发送到lsr-id对应的NM中，而末节点中向上游节点发送resv消息时，resv消息的出接口作为该resv消息的源地址。当中间节点从接收到resv消息中获取的resv消息的源地址，与path消息中lsr-id不相同时，则末节点中处理path消息的NM，与根据resv消息处理邻居关系的NM是不同的NM，从而导致了末节点中处理业务的错误。

因此，对于报文中包括有路由警告(router-alert)选项的，可以不采用本地地址分布规则。

第三、报文分发规则可以是邻居(Peer)地址分布规则。该规则可以通过手工干预或者其它方法，建立peer地址与NM的关联关系，并且将该关联关系表发送给CORE和SOCKE。其中，当SOCKE接收到报文时，可以根据接收到报文的源地址分配关联关系表，SOCKE将报文发送给对应的NM；当CORE生成处理后的报文时，根据该报文的目的地址查询关联关系表，CORE将处理后的报文发送给对应的NM。

根据RSVP协议规定，节点的邻居信息是随着业务报文携带而获得的，在处理业务的过程中建立邻居关系，在删除业务的过程中删除邻居关系，其中邻居是指上下游节点，与邻居有关的信息称为邻居信息，邻居信息具体可以是path/resv消息里面的标识的下一跳(hop)地址。因此，节点可以通过学习邻居关系建立与NM之间的关联关系。如图6所示建立Peer地址与NM关联关系示意简图，包括：

步骤611：当SOCKET接收到报文，且该报文的源地址尚未分配NM时，请求peer分配器分配NM；

步骤612：peer分配器将分配结果发送给SOCKET，SOCKET记录分配结果，将接收到的报文发送给分配的NM处理；

步骤621：当CORE要对外发送报文时，如果该报文的目的地址尚未分配NM，则CORE请求peer分配器分配NM；

步骤622：peer分配器为该目的地址分配对应的NM，将分配结果发送给CORE，CORE记录分配结果，将报文下发给分配的NM。

其中，为SOCKET分配NM的peer分配器，与为CORE分配NM的peer分配器可以是相同的peer分配器。

其中，NM和CORE中分别都可以感知承载其中的业务，当NM发现本地的peer地址与业务无关时，通知peer分配器释放建立的关联关系；或者当CORE发现本地的peer地址与业务无关时，通知peer分配器释放建立的关联关系。例如：在步骤612中peer分配器为SOCKET分配的NM，与不同于上述图6中说明业务的其他业务中使用到该peer分配器为SOCKET分配的NM，且SOCKET接收到的报文都来自相同的源地址(即peer地址相同)；或者，在步骤622中peer分配器根据报文的目的地址(即peer地址)分配对应的NM，CORE将报文下发给分配的该NM，且该peer地址与分配对应的NM恰好被其它业务所使用到。也就是说，在peer地址与NM的对应关系被不同的业务同时利用到，那么，需要对该peer地址与NM的对应关系被利用到的次数进行计数，当有业务执行完毕，不需要利用该peer地址与NM的对应关系，相应的减少该peer地址与NM的对应关系被利用到的次数，当没有业务再利用该peer地址与NM的对应关系时，相应的计数可以是零，才可以释放peer地址与NM的对应关系。

其中，在SOCKET中是不能感知业务，因此，通常由NM或者CORE通知peer分配器改变peer地址与NM的对应关系被利用到的次数，peer分配器可以在计数为零时，释放peer地址与NM的对应关系。

当业务删除时，SOCKET和CORE可以释放peer地址与NM的关联关系。由于SOCKET不感知RSVP业务，无法释放Peer地址与NM的关联关系，因此，当NM发现本地的peer地址与业务无关时，通知peer分配器释放建立的关联关系。CORE可以感知RSVP业务，当发现本地的peer地址与业务无关时，通知peer分配器释放建立的关联关系。当SOCKET和CORE引用相同的peer地址用于根据该peer地址分配NM时，peer分配器需要记录peer地址的引用计数，便于peer分配器判断peer地址的引用次数，用来判断是否可以释放该peer地址，如果有任何一个peer地址与NM的关联关系仍然与业务有关，则不可以释放该peer地址。

上述是对一种自动建立peer与NM关联关系的举例，采用邻居(Peer)地址分布规则部署……具有更好的灵活性，NM的数量可以随着Peer增多(减少)而自动增加(减少)。peer与NM的关联关系也可以是手工干预建立的。

还需要说明的是，第一SOCKET还可以根据报文的其它特征(如首节点地址、末节点地址)建立与NM的关联关系，将接收到的报文发送给对应的NM(也可以称为“上游NM”)。

上述说明的报文分发规则并非是对本发明实施例的穷举，不应该理解为对本发明实施例的限制。

为了更清楚的理解上述步骤502提出的业务分布规则，下面详细说明业务分布规则，包括：

第一、业务分布规则采用Hash方式。在CORE中可以预设规则，例如某种Hash算法，以取模算法为例，如下式(1)所示：

K＝x％n    (1)

其中，K为CORE实例标识，x为Session或者LSP标识，n为部署的CORE实例的数目，％表示取模。假设部署n个CORE实例，每个CORE赋予一个实例标识，从0开始到n-1。对于特定session或者LSP，它所处理的CORE实例标识K按照如式(1)可以快速定位CORE。将业务分布的到合理的CORE中。Hash算法也可以是循环冗余校验(Cyclic redundancy check，CRC)、纵向冗余校验(Longitudinal redundancy check，LRC)、信息-摘要算法5(Message-Digest Algorithm 5，MD5)、安全散列算法(Secure Hash Algorithm)等其他散列算法。

第二、业务分布规则采用集中分配方式。采用集中分配的方式时，可以增加单独的业务分配器，由业务分配器为业务分配CORE。如图7，业务分配器为业务分配CORE操作具体包括：

步骤701：NM在接收到新的业务消息时，向业务分配器发送分配CORE请求；其中，为该新业务分配CORE可以是按照Session为粒度，也可以是按照LSP为粒度。在本实施例中以Session为粒度举例，对于以LSP为粒度分配CORE的操作可以容易推出。

步骤702：业务分配器为该新业务分配CORE，将分配结果发送给NM。

其中，业务分配器可以根据该节点中可使用的CORE数量和各CORE中的使用率，为业务分配合理的CORE。如果该业务所属的Session已经分配给一个CORE，则增加用于处理该Session的CORE的计数，或者，分配一个空闲的CORE，将其分配给Session，记录该空闲的CORE与归属于Session的关系，如果当前的CORE都非常繁忙，可以增加一个新的CORE来支撑业务。如果是以LSP为粒度，假设为该LSP归属的业务分配一个CORE，则记录该CORE上业务的计数。

步骤703：NM接收到分配结果，将报文发送给对应的CORE处理。

还需要说明的是，当NM在删除业务状态块时，向业务分配器请求释放CORE。业务分配器减少归属于CORE的Session的计数，当计数为0时，则释放该CORE。如果CORE中没有任何业务承载，可以根据策略将该CORE占用的物理资源所在的实体脱离该节点。

上述说明的两种业务分布规则，都可以将同一个业务的报文分配到相同的CORE中处理。

第三、业务分布规则采用部署方式。通过部署该节点中的CORE和NM的之间的关系，从而完成NM到CORE的业务关联。其中，部署节点中的CORE何NM的关系的具体情况可以包括：

当有n个NM和1个CORE来部署时，如果一个CORE就已经能够提供足够大容量支持LSP，那么CORE可以固定部署一个，NM可以直接命中CORE来处理业务。

或者，NM与CORE以1∶1的数量比来部署。其中，一个NM(例如：上游NM)绑定一个CORE。当NM收到新业务消息时，固定上送到与自己绑定的CORE去处理。为了使得归属于该新业务的所有报文都由同一个CORE处理，对应1∶1方式还需要其它控制来完成整个过程，如图8所示具体包括：

步骤801：接收到新业务的path消息的NM(称为上游NM)，将消息上送给与该NM绑定的CORE处理；

步骤802：与NM绑定的CORE接收到path消息后，根据上述说明的报文分发规则，将path消息转发到下游NM；

步骤803：下游NM接收到新业务的resv消息，该消息被发送到处理path消息的CORE中。其中，将resv消息发送到处理path消息的CORE中的具体操作可以包括：

下游NM通过广播查询业务所在的CORE，从而实现将resv消息发送到处理path消息的CORE中；

或者，对于设立业务集中点的情况下，下游NM在业务集中点中查询业务所属的CORE，从而实现将resv消息发送到处理path消息的CORE中；

或者，下游NM在步骤802中记录业务(具体是path消息)与CORE的关系，收到Resv消息时查表得知CORE所在实例。

步骤804：CORE将向上游节点回复的resv消息发给上游NM。

上述对业务分布规则的说明，还需要说明的是，报文分发规则和业务分布规则可以不限于上述说明的实例，还可以采取其它方式。

综上对本实施例的说明，可以获知将RSVP实例划分为NM和CORE两部分，且NM和CORE的数量可以灵活部署。具体可以根据实际需要，将多个构件(其中，一个构件指单个的NM或者CORE)合并部署为一个实例；或者将一个构件的功能分拆为多个，分别部署到不同实例上；或者将一个构件的功能分拆为多个，然后再与其他构件合并部署为一个实例。这种部署方式的改变仍然是基于本方案实现原理，属于本实施例的覆盖范围内。下面结合图9、图10、图11举例说明构件的部署方式。

如图9所示部署一个NM和多于一个的CORE，采用这种部署方式下RSVP实例的接口与NM之间不需要报文分分发规则，NM将要发送的报文通过业务分布规则发送给对应的CORE中处理。其中，如果业务分布规则采用集中方式，则上述说明的业务分配器可以集中在NM中。采用图9所示的部署方式极大的简化了RSVP的实现方法。

图10所示部署多于一个NM和一个CORE。采用这种部署方式下RSVP实例的SOCKET(SOCKET)与NM之间根据报文分发规则具有关联。NM与CORE之间不需要业务分布规则，直接命中。NM承担了大量报文刷新工作，单个CORE可以通过减少LSP状态块内存开销来承载更多LSP。采用图10所示的部署方式可以节省业务分配所需要的控制和开销。

图11所示部署NM与CORE的数量比值为：1∶1。采用这种部署方式下SOCKET给RSVP实例之间的报文传输可以根据上述说明的报文分发规则，NM与CORE之间的关系实际上变成了RSVP实例之间的关系。详细说明可以参考图8中及其说明，此处不重述。

图12所示为本发明实施还提供的一种处理报文的装置，该节点包括：第一SOCKET101，上游邻居管理(NM)102，核心处理实例(CORE)103，下游NM104，和第二SOCKET105；

第一SOCKET，用于接收上游节点发送的报文，将接收到的报文发送给上游邻居管理(NM)；

上游NM，用于接收第一SOCKET发送的报文，将接收到的报文发送给CORE；

CORE，用于接收上游NM发送的报文，执行业务处理，生成处理后的第一报文；将处理后的第一报文发送给下游NM；

下游NM，用于接收CORE发送的处理后的第一报文，将处理后的第一报文发送给第二SOCKET；

第二SOCKET，用于接收下游NM发送的处理后的第一报文，将处理后的第一报文发送给下游节点。

通过上述对该节点的说明，该节点中将RSVP实例划分为NM和CORE两部分，实现对上游节点发送的报文的处理，可以灵活的扩展NM和CORE的数量，且可以将业务更合理的分配到多个CORE中，从而大大提高了RSVP实例所支持的LSP数量，且大大提高了RSVP的工作效率。

进一步，该装置还可以实现对下游节点发送的报文的处理，则

第二SOCKET，还用于接收下游节点发送的报文，将报文发送给下游NM；

下游NM，还用于接收第二SOCKET发送的报文，将报文发送给CORE；

CORE，还用于接收下游NM发送的报文，根据报文，执行业务处理，生成处理后的第二报文；将处理后的第二报文发送给上游NM；

上游NM，还用于接收处理后的第二报文，将处理后的第二报文发送给第一SOCKET；

第一SOCKET，还用于接收处理后的第二报文，将处理后的第二报文发送给上游节点。

进一步，

若第一SOCKET接收上游节点发送的报文为path消息，且上游NM中没有接收path消息状态块，

则上游NM，还用于根据接收到的path消息，建立接收path消息状态块；

若第一SOCKET接收上游节点发送的报文为path消息，上游NM中有接收path消息状态块，

则上游NM，还用于判断接收到path消息中状态与接收path消息状态块中的状态是否一致，如果不一致，将接收到的path消息发送给CORE；

若处理后的第一报文为处理后的path消息，且下游NM中没有发送path消息状态块，

则下游NM，还用于根据接收到的处理后的path消息，建立发送path消息状态块；根据发送path消息状态块中信息，通过第二SOCKET发送处理后的path消息给下一跳进行刷新；

若第二SOCKET接收下游节点发送的报文为resv消息，且下游NM中没有接收resv消息状态块，

则下游NM，还用于根据接收到的resv消息，建立接收resv消息状态块；

若第二SOCKET接收下游节点发送的报文为resv消息，且下游NM中有接收resv消息状态块，

则下游NM，还用于判断接收到resv消息中状态与接收resv消息状态块中的状态是否一致，如果不一致，将接收到的报文发送给与CORE；

若处理后的第二报文为处理后的resv消息，且上游NM中没有发送resv消息状态块，

则上游NM，还用于根据接收到的处理后的resv消息，建立发送resv消息状态块；根据发送resv消息状态块中信息，发送处理后的resv消息给下一跳进行刷新。

进一步，第一SOCKET，具体用于接收上游节点发送的报文，根据报文分发规则，将接收到的报文发送给上游NM，所述报文分发规则包括套接字中接收所述报文的端口号与NM的关联关系，所述报文的目的地址与NM的关联关系，或者所述报文的源地址与NM的关联关系中的一种或多种；

则CORE，具体用于根据所述业务分布规则，将所述处理后的报文发送给下游NM，所述下游NM根据所述报文分发规则，将所述处理后的报文通过第二套接字发送给下游节点。

进一步，装置中包括多于一个的CORE时，上游NM，具体用于以报文所归属会话为粒度，或者以报文所使用的标签选择路径(LSP)为粒度，根据业务分布规则，将接收到的报文发送给CORE。

进一步，业务分布规则为哈希(Hash)方式。

进一步，装置还包括：业务分配器106，用于接收上游NM发送的分配CORE请求，为报文归属的业务分配CORE，将分配结果发送给上游NM；

则上游NM，具体用于根据分配结果，将接收到的报文发送给CORE；

进一步，若装置中NM与CORE以1∶1的数量比来部署，且第一SOCKET所归属的装置包括多于一个的NM时，上游NM，具体用于将接收到的path消息发送给与上游NM绑定的CORE；

且下游NM，具体用于将接收到的resv消息，发送给与上游NM绑定的CORE。

进一步，下游NM中将接收到的resv消息，发送给与上游NM绑定的CORE，具体包括：

下游NM通过广播查询resv消息归属业务所在的CORE，从而将resv消息发送给与上游NM绑定的CORE；

或者，下游NM向业务集中点查询resv消息归属业务所在的CORE，从而将resv消息发送给与上游NM绑定的CORE；

或者，下游NM根据记录的发送path消息的CORE，将resv消息发送给与上游NM绑定的CORE。

上述是对本发明实施例提供的装置的说明，需要理解的是，对装置的更详细的说明也可以参考图3至图11中关于报文处理方法中有关的说明，此处不重述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式对本发明进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及设备；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1.一种处理报文的方法，其特征在于，包括：

第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；

上游邻居管理将接收到的报文发送给核心处理实例；

所述核心处理实例根据接收到的所述报文，执行业务处理，生成处理后的第一报文；

所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将处理后的第一报文通过第二套接字发送给下游节点。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第二套接字接收所述下游节点发送的报文，将所述报文发送给下游邻居管理；

下游邻居管理将所述报文发送给所述核心处理实例；

所述核心处理实例根据接收到的所述下游邻居管理发送的报文，执行业务处理，生成处理后的第二报文；

所述核心处理实例将所述处理后的第二报文发送给上游邻居管理，由上游邻居管理将处理后的第二报文通过第一套接字发送至所述上游节点。

3.根据权利要求2所述的方法，其特征在于，

若第一套接字接收上游节点发送的报文为path消息，且上游邻居管理中没有接收path消息状态块，则所述方法还包括：所述上游邻居管理根据接收到的path消息，建立所述接收path消息状态块；

若第一套接字接收上游节点发送的报文为path消息，所述上游邻居管理中有接收path消息状态块，则所述方法还包括：上游邻居管理判断接收到path消息中状态与所述接收path消息状态块中的状态是否一致，如果不一致，上游邻居管理将接收到的报文发送给所述核心处理实例；

若所述处理后的第一报文为处理后的path消息，且下游邻居管理中没有发送path消息状态块，则所述方法还包括：下游邻居管理根据接收到的处理后的path消息，建立所述发送path消息状态块；其中，所述下游邻居管理根据所述发送path消息状态块中信息，通过第二套接字发送处理后的path消息给下一跳进行刷新。

4.根据权利要求3所述的方法，其特征在于，

若第二套接字接收所述下游节点发送的报文为resv消息，且所述下游邻居管理中没有接收resv消息状态块，则所述方法还包括：所述下游邻居管理根据接收到的resv消息，建立所述接收resv消息状态块；

若第二套接字接收所述下游节点发送的报文为resv消息，且所述下游邻居管理中有接收resv消息状态块，则所述方法还包括：所述下游邻居管理判断接收到resv消息中状态与所述接收resv消息状态块中的状态是否一致，如果不一致，执行所述下游邻居管理将接收到的报文发送给与所述核心处理实例；

若所述处理后的第二报文为处理后的resv消息，且所述所述上游邻居管理中没有发送resv消息状态块，则所述方法还包括：所述上游邻居管理根据接收到的处理后的resv消息，建立所述发送resv消息状态块；其中，所述上游邻居管理根据所述发送resv消息状态块中信息，发送处理后的resv消息给下一跳进行刷新。

5.根据权利要求1所述的方法，其特征在于，

所述第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理，具体包括：第一套接字接收上游节点发送的报文，根据报文分发规则，将接收到的报文发送给上游邻居管理，所述报文分发规则包括套接字中接收所述报文的端口号与邻居管理的关联关系，所述报文的目的地址与邻居管理的关联关系，或者所述报文的源地址与邻居管理的关联关系中的一种或多种；

则所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将处理后的第一报文通过第二套接字发送给下游节点，具体包括：核心处理实例根据所述业务分布规则，将所述处理后的报文发送给下游邻居管理，所述下游邻居管理根据所述报文分发规则，将所述处理后的报文通过第二套接字发送给下游节点。

6.根据权利要求1至5任一项所述的方法，其特征在于，当第一套接字所归属的节点包括多于一个的核心处理实例时，所述上游邻居管理将接收到的报文发送给核心处理实例，具体包括：

上游邻居管理以报文所归属会话为粒度，或者以报文所使用的标签选择路径为粒度，根据业务分布规则，将接收到的报文发送给核心处理实例。

7.根据权利要求1所述的方法，其特征在于，当第一套接字所归属的节点包括多于一个的核心处理实例时，所述上游邻居管理将接收到的报文发送给核心处理实例，具体包括：

所述上游邻居管理根据接收到的报文，触发执行向业务分配器发送分配核心处理实例请求；

业务分配器接收到所述请求，为所述报文归属的业务分配核心处理实例，将分配结果发送给所述上游邻居管理；

所述上游邻居管理接收所述分配结果；

所述上游邻居管理根据分配结果，将接收到的报文发送给核心处理实例。

8.一种处理报文的装置，其特征在于，包括：第一套接字，上游邻居管理，核心处理实例，下游邻居管理，和第二套接字；

所述第一套接字，用于接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；

上游邻居管理，用于接收第一套接字发送的报文，将接收到的报文发送给所述核心处理实例；

核心处理实例，用于接收上游邻居管理发送的报文，执行业务处理，生成处理后的第一报文；将所述处理后的第一报文发送给下游邻居管理；

下游邻居管理，用于接收所述核心处理实例发送的处理后的第一报文，将所述处理后的第一报文发送给第二套接字；

第二套接字，用于接收下游邻居管理发送的处理后的第一报文，将所述处理后的第一报文发送给下游节点。

9.根据权利要求8所述的装置，其特征在于，

所述第二套接字，还用于接收所述下游节点发送的报文，将所述报文发送给下游邻居管理；

所述下游邻居管理，还用于接收第二套接字发送的报文，将所述报文发送给所述核心处理实例；

所述核心处理实例，还用于接收所述下游邻居管理发送的报文，根据所述报文，执行业务处理，生成处理后的第二报文；将所述处理后的第二报文发送给上游邻居管理；

所述上游邻居管理，还用于接收所述处理后的第二报文，将处理后的第二报文发送给所述第一套接字；

所述第一套接字，还用于接收所述处理后的第二报文，将处理后的第二报文发送给所述上游节点。

10.根据权利要求9所述的装置，其特征在于，

若第一套接字接收上游节点发送的报文为path消息，且上游邻居管理中没有接收path消息状态块，

则所述上游邻居管理，还用于根据接收到的path消息，建立所述接收path消息状态块；

若第一套接字接收上游节点发送的报文为path消息，所述上游邻居管理中有接收path消息状态块，

则所述上游邻居管理，还用于判断接收到path消息中状态与所述接收path消息状态块中的状态是否一致，如果不一致，将接收到的path消息发送给所述核心处理实例；

若所述处理后的第一报文为处理后的path消息，且下游邻居管理中没有发送path消息状态块，

则所述下游邻居管理，还用于根据接收到的处理后的path消息，建立所述发送path消息状态块；根据所述发送path消息状态块中信息，通过第二套接字发送处理后的path消息给下一跳进行刷新；

若第二套接字接收所述下游节点发送的报文为resv消息，且所述下游邻居管理中没有接收resv消息状态块，

则所述下游邻居管理，还用于根据接收到的resv消息，建立所述接收resv消息状态块；

若第二套接字接收所述下游节点发送的报文为resv消息，且所述下游邻居管理中有接收resv消息状态块，

则所述下游邻居管理，还用于判断接收到resv消息中状态与所述接收resv消息状态块中的状态是否一致，如果不一致，将接收到的报文发送给与所述核心处理实例；

若所述处理后的第二报文为处理后的resv消息，且所述所述上游邻居管理中没有发送resv消息状态块，

则所述上游邻居管理，还用于根据接收到的处理后的resv消息，建立所述发送resv消息状态块；根据所述发送resv消息状态块中信息，发送处理后的resv消息给下一跳进行刷新。

11.根据权利要求10所述的装置，其特征在于，所述第一套接字，具体用于接收上游节点发送的报文，根据报文分发规则，将接收到的报文发送给上游邻居管理，所述报文分发规则包括套接字中接收所述报文的端口号与邻居管理的关联关系，所述报文的目的地址与邻居管理的关联关系，或者所述报文的源地址与邻居管理的关联关系中的一种或多种；

则所述核心处理实例，具体用于根据所述业务分布规则，将所述处理后的报文发送给下游邻居管理，所述下游邻居管理根据所述报文分发规则，将所述处理后的报文通过第二套接字发送给下游节点。

12.根据权利要求9至11任一项所述的装置，其特征在于，所述装置中包括多于一个的核心处理实例时，所述上游邻居管理，具体用于以报文所归属会话为粒度，或者以报文所使用的标签选择路径为粒度，根据业务分布规则，将接收到的报文发送给核心处理实例。

13.根据权利要求12所述的装置，其特征在于，所述装置还包括：业务分配器，用于接收所述上游邻居管理发送的分配核心处理实例请求，为所述报文归属的业务分配核心处理实例，将分配结果发送给所述上游邻居管理；

则所述上游邻居管理，具体用于根据分配结果，将接收到的报文发送给核心处理实例。

Images