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

专利名称：一种处理报文的方法和装置的制作方法
技术领域：
本发明涉及通信技术，具体涉及一种处理报文的方法和装置。
背景技术：
随着人们对通信需求在不断增长，导致网络规模越来越大，提供商边缘(Provider edge,ΡΕ)节点越来越多。而且，网络扁平化的趋势也使得每一层的网络规模在变大。在大 规模网络下，如何规划流量，使得网络整体利用效率提高，是关系到运营商投资收益的重要 问题。另外，差异化服务是运营商营销的重要策略，如何在同一张网络中提供差异化服务， 直接关系到运营商市场的成功与否。同时，随着市场竞争激烈化，用户要求也越来越高，其 中高可靠性的通信质量是至关重要的，这种要求反映到到网络技术上，就是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实例划分为 匪和CORE两部分，实现对上游节点发送的报文的处理，可以灵活的扩展匪和CORE的数量， 且可以将业务更合理的分配到多个CORE中，从而大大提高了 RSVP实例所支持的LSP数量， 且大大提高了 RSVP的工作效率。


为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使 用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于 本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其 他的附图。图1为LDP over TE技术的组网示意图；图2为采用TE层次化方案组网示意图；图3为建立TE的LSP的网络示意图；图4为本发明实施例提供的处理报文方法的总体流程图；图5为本发明实施例提供的处理报文方法的流程示意图；图6为本发明实施例提供的建立Peer地址与匪关联关系示意简图7为本发明实施例中业务分配器为业务分配CORE操作的示意简图；图8为本发明实施例提供当装置中匪与CORE数量比为1 1时，节点的处理流 程示意简图；图9为本发明实施例提供的部署的包括一个匪和多于一个的CORE的装置示意 图；图10为本发明实施例提供的部署的包括多于一个NM和一个CORE的装置示意图；图11为本发明实施例提供的部署匪与CORE的数量比值为1 1的装置；图12为本发明实施例提供的一种装置的示意图。
具体实施例方式为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施 方式对本发明实施例作进一步的详细说明。图3所示为建立TE的LSP的网络示意图。LSP的建立是由正向的path消息和反向 的resv消息来实现的。并且path消息和resv消息会定期刷新。在本实施例中，节点将消息 刷新业务按照报文分发规则分配到该节点的一个或者多于一个的邻居管理(匪，Neighbor Manager)实例中，将核心业务处理按照业务分布规则分配到该节点一个或者多于一个核心 处理实例中，这种核心处理实例可以称为CORE。其中，核心业务处理是指在LSP建立过程 中，需要本节点进行的资源和表项处理。具体可包括为LSP分配入标签；为LSP申请预留 带宽；将入标签和出标签表项下发到接口板，用于MPLS报文转发等。因此，在一个节点内存 在至少一个匪和至少一个CORE，且匪和CORE之间具有对应关系。匪和CORE是根据功能 上的不同而划分的，匪和CORE可以分别由相应的独立的硬件资源实现，通常在多核、多主 控板、或者多中央处理单元(CPU，Central Process Unit)时，可以充分显现出分布式节点 比现有集中式节点的优势。NM的功能是维持软状态刷新，多个匪可以分担刷新的CPU压 力，CORE的功能是为LSP分配标签、带宽、下发表项，它需要保存LSP控制块，分布在多个硬 件资源上的CORE之间可以分担内存压力，CORE的空闲、繁忙区别可以体现在对其所在的硬 件资源的内存使用上。在对本发明实施例做说明之前，对套接字(SOCKET)进行说明，SOCKET中相当于 接口，主要包括三个参数，即通信的目的IP地址、使用的传输层协议(如传输控制协议 (TCP,Transmission Control Protocol))和使用的端口号，应用层和传输层可以通过套接 字，区分来自不同网络连接的通信。为了更好的理解本发明实施例提供的处理报文方法，参考图4至图11及其说明。图4所示为本发明实施例提供的处理报文方法的总体流程图，该方法包括步骤S401 第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻 居管理(NM)；步骤S402 上游匪将接收到的报文发送给核心处理实例(CORE)；步骤S403 所述CORE根据接收到的所述报文，执行核心业务处理，生成处理后的 第一报文；步骤S404 所述CORE将所述处理后的第一报文发送给下游匪，由下游匪将处理 后的第一报文通过第二套接字发送给下游节点。
通过对图4中提供的一种处理报文方法的说明，该方法采用将节点划分为匪和 CORE两部分，实现对上游节点发送的报文的处理，由于在一个节点内存在至少一个匪和至 少一个CORE，且匪和CORE之间具有对应关系，匪和CORE是根据功能上的不同而划分的， NM和CORE可以分别由相应的独立的硬件资源实现，当有大量的报文需要处理时，可以扩展 NM和CORE的数量，使得节点可以支持更多的LSP，同时不会降低该节点的性能。进一步，该节点还可以实现对下游节点发送的报文的处理，则在步骤404之后，该 方法还包括步骤S405 第二套接字接收所述下游节点发送的报文，将所述报文发送给下游
匪；需要理解的是，下游节点发送的报文和步骤401中上游节点发送的报文是归属于 相同的业务的。步骤S406 下游匪将所述报文发送给所述CORE ；其中，下游NM将接收到的报文(如resv消息)，发送到该报文所归属的业务所在 的CORE中，该CORE与步骤S403中的CORE是同一个CORE。步骤S407 所述CORE根据接收到的所述下游匪发送的报文，执行业务处理，生成 处理后的第二报文；步骤S408 所述CORE将所述处理后的第二报文发送给上游匪，由上游匪将处理 后的第二报文通过第一套接字发送至所述上游节点。通过对步骤S405至S408的说明，实现对下游节点发送的报文的处理，由于该方法 采用将RSVP实例划分为匪和CORE两部分，由于在一个节点内存在至少一个匪和至少一 个CORE，且匪和CORE之间具有对应关系，匪和CORE是根据功能上的不同而划分的，匪和 CORE可以分别由相应的独立的硬件资源实现，当有大量的报文需要处理时，可以扩展NM和 CORE的数量，使得节点可以支持更多的LSP，同时不会降低该节点的性能。图5为本发明实施例提供的处理报文方法的具体流程图。该方法包括步骤501 第一套接字接收上游节点发送的path消息，将该path消息发送给上游
匪；需要理解的是，该节点中可以包括多个匪，则接收到path消息后，节点可以按照 报文分发规则将该path消息发送到对应的NM中。具体可以是按SOCKET中接收报文的端 口号将该报文分布到不同匪中；或者按接收报文的目的地址分布到不同匪中；或者按接 收报文的源地址分布到不同NM中；或者上述规则的任意组合，将报文发送给对应的匪中。步骤502 上游匪根据接收到的path消息，建立接收path消息状态块，其中，建立 的接收path消息状态块中记录path消息中携带的信息，将path消息上报给CORE ；其中，上 游NM在接收到的path消息后，可以检查该path消息的合法性，当判断path消息合法后， 执行上述建立消息状态块的操作。其中，步骤502中建立的path消息状态块为接收path消息状态块，后续刷新操作 中，该NM根据建立的接收path消息状态块，开启NM中的超时器，接收上游节点定期发送的 path消息，当该NM接收到的path消息中携带的信息与当前接收path消息状态块中的信 息没有变化时，匪不会将path消息上报给CORE。当该匪接收到path消息有变化时，匪 更新接收path消息状态块中的记录，并将path消息上报给CORE。从而减轻了刷新操作对
9CORE的压力。RSVP同一条业务需要集中处理，完成资源检查、申请、下发表项等过程。但是同一 条LSP的path、resv消息分别来自不同邻居，且这两个消息通常会定向到不同的匪中，所 以NM必须能够将相同LSP的消息发送到相同的CORE里进行集中业务处理。从协议定义的 角度来看，RSVP处理业务的最小粒度为会话(session)。同一个session下可能存在多条 LSP，在清晰共享(SE，ShareExplicit)风格下，这些LSP在同一个节点内和共享出接口时通 常需要共享带宽资源(由协议选项决定)。所以在SE风格下匪必须能够保证相同session 的消息能定向到相同的CORE中处理。匪也可以以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控制块的具体操作可以包括C0RE计算 LSP的下一跳，以及出接口，检查该节点是否有足够资源建立LSP，当判断出资源充足后，生 成LSP控制块。否则显示建立LSP失败。其中，LSP控制块用于记录LSP的属性(这些属性来自path消息和resv消息)、 记录下游节点给本节点分配的标签(即出标签)，记录本节点为上游节点分配的标签(即入 标签)，记录分配的带宽。步骤504 =CORE生成发送给下游节点的path消息，将该path消息发送给下游匪， 其中，此处的下游匪可以是与步骤501中的上游匪为同一个匪，也可以是不同于步骤501 中的上游匪。其中，CORE生成发送给下游节点的path消息与接收到的path消息相似，但也有 不同，不同在于路径对象，路径地址等。同理，后续的resv消息有相同的说明。步骤504中操作，具体可以是C0RE根据报文分发规则将发送给下游节点的path 消息发送给下游NM。其中，该报文分发规则具体可以是按照发送报文的SOCKET的端口号 (可以理解为报文的出接口，后续为了便于说明，简称“出接口”)分布到不同匪中；或者按 照发送报文的源地址分布到不同匪中；或者按照发送报文的目的地址分布到不同匪中； 或者上述规则的任意组合。步骤505 下游匪接收CORE发送的path消息，建立path消息状态块，将该path 消息通过套接字(SOCKET)发送给下游节点，其中，下游匪具体可以通过第二套接字将path 消息发送给下游节点。为了便于和步骤502中上游匪建立的path消息状态块进行区分，将步骤502中 建立的path消息状态块称为“接收path消息状态块”，步骤505中下游匪建立的path消息状态块称为“发送path消息状态块”。其中，后续为了维持LSP，定期进行path消息的刷 新的操作，由下游匪，根据发送path消息状态块来完成，CORE可以不再干预。上述步骤501至505是节点对接收到上游节点发送的path消息处理的过程，后续 步骤506至510是节点对接收到下游节点发送的resv消息的处理过程，需要理解的是，节 点中匪和CROE对resv消息的处理方法与对path消息的处理方法是相似的。下面具体说 明节点中匪和CROE对resv消息的处理过程。步骤506 该节点的第二套接字接收到下游节点发送的resv消息，将该resv消息 发送给下游匪；其中，节点的套接字可以根据报文分发规则，将接收到的报文发送到对应的匪中。步骤507 下游匪根据接收到的resv消息，建立resv消息状态块，其中，建立的 resv消息状态块中记录resv消息中携带的信息，将resv消息上报给CORE ；其中，下游匪 在接收到的resv消息后，可以检查该resv消息的合法性，当判断resv消息合法后，执行上 述建立消息状态块的操作。还需要说明的是，步骤507中的CORE应当和对该resv消息相 应的path消息进行处理的CORE相同。其中，步骤507中建立的resv消息状态块为接收resv消息状态块，后续刷新操作 中，下游NM根据建立的接收resv消息状态块，定期的接收下游节点发送的resv消息进行 刷新，当下游匪接收到刷新resv消息没有变化时，匪不会将刷新resv消息上报给CORE， 当该匪接收到刷新resv消息有变化时，匪将刷新resv消息上报给CORE。从而减轻了刷 新操作对CORE的压力。步骤507中将resv消息上报给CORE的操作，具体可以是下游匪向节点中的每 个CORE发送查询信息，用于查询resv消息归属业务所在的CORE，当其中一个CORE中判断 出resv消息归属业务在自身处理时，回复查询响应给该下游NM，从而将resv消息发送给对 应CORE ；或者，对于节点中设立有业务集中点的，下游NM可以向业务集中点查询resv消息 归属业务所在的CORE，从而将resv消息发送给与上游NM绑定的CORE ；或者，下游NM根据 记录的发送path消息的CORE，将resv消息发送给与上游匪绑定的CORE。在后续的实施 例中将会详细说明。步骤508 =CORE根据接收到resv消息，预留资源，生成发送给上游节点的resv消 息，其中，发送给上游节点的resv消息中包含自身为上游节点分配的LSP的标签(即入标 签)；LSP是依靠标签进行转发的，下游节点负责给上游节点分配标签，这个标签通过 resv消息从下游携带给上游。对于一个节点来说，它收到下游的resv消息，获得出标签； 同时它给上游分配一个相应的标签(称为入标签)，通过resv消息发给上游。如果收到一 个报文，它的标签是本节点分配的入标签，那么就会把这个标签换成对应的出标签，继续转 发给分配该出标签的下游节点。这个过程一直重复直到到达LSP末端。步骤509 =CORE将生成的发送给上游节点的resv消息发送给上游匪；其中，CORE具体可以根据报文分发规则，将发送给上游节点的resv消息发送给对 应的匪。步骤510 上游匪接收到发送给上游节点的resv消息后，建立resv消息状态块，将该resv消息通过SOCKET发送给上游节点。为了便于和步骤507中下游匪建立的resv 消息状态块进行区分，将步骤507中建立的resv消息状态块称为“接收resv消息状态块”， 步骤510中上游NM建立的resv消息状态块称为“发送resv消息状态块”，其中，后续为了维 持LSP，定期进行resv消息的刷新将由上游的匪，根据发送resv消息状态块来完成，CORE 可以不再干预。通过上述步骤501至步骤510的说明，可以建立一条LSP，后续如果收到相同的 LSP的path消息或者resv消息执行刷新，path消息将会被发送到与上述建立LSP时处理 path消息的匪中，同理，resv消息也将会被发送到与上述建立LSP时处理resv消息的匪 中。上游匪检查resv消息与本地记录状态块是否一致，且下游匪检查path消息与本地 记录状态块是否一致，当两个匪判断都一致时，完成一次刷新操作。否则将检查到的与本 地记录不一致的消息上报给CORE处理。通过上述步骤501至步骤510对本实施例提供的一种处理报文的说明，该方法采 用将RSVP实例划分为匪和CORE两部分，通过灵活部署匪和CORE的数量，以及匪与CORE 的对应关系，使得一个节点上可以支持的LSP数量远远大于现有技术。为了更清楚的理解上述步骤501、504、506和步骤509中提出报文分发规则，下面 详细说明报文分发规则，包括第一、报文分发规则可以是接口分布规则。该规则可以通过手工干预或者其它方 法，建立RSVP实例中接口与NM的关联关系，并且将该关联关系表发送给CORE和SOCKET。其 中，当SOCKE接收到报文时，可以根据接收到报文的SOCKET的端口号(可以理解为该报文 的入接口，后续为了便于说明，简称“入接口”)查询关联关系表，SOCKE将报文发送给与入 接口对应的NM ；当CORE生成处理后的报文时，根据该报文的出接口查询关联关系表，CORE 将处理后的报文发送给与出接口对应的匪。其中，SOCKET和入接口可以是一对多的关系，SOCKET可以根据报文分发规则与多 个NM具有对应关系。从SOCKET收到报文后，首先会上送给特定SOCKET，SOCKET需要查询 关联表才能确定送给哪个NM进行处理。CORE获得LSP的出接口的具体操作可以是LSP的首节点事先算好一条路径(或 者用户显式指定一条路径)，路径信息是一串IP地址，通过path消息的显式路径对象 (ER0, Explicit path object)携带给沿途各个节点，各个节点可以通过ERO得知出接口 ； 在没有ERO的情况下，CORE实例可以根据LSP的目的地址(在path消息里面会指明)查 询本地存储的路由信息中的出接口。采用接口分布规则时，匪(可以是上游匪，或者下游NM)还执行邻居处理，具体可 以包括产生和接收处理基于接口的哈罗(Hello)消息。具体包括匪可以为Hello消息 建立状态块，处理Hello消息和发送Hello消息，维护Hello消息状态块。当匪超时未收 到Hello消息时，判断Hello消息丢失，匪可以停止该邻居的LSP状态块超时器，进入自刷 新状态；当邻居之间通过Hello消息在预置的时间内重新连接上，匪可以通知TORE，CORE 产生path消息和resv消息协助邻居恢复状态块；如果通过Hello消息在预置的时间内邻 居之间无法连接，匪通知CORE，CORE按照协议规定，删除LSP资源和表项，匪也删除自身 保留的LSP状态块。其中，上述LSP状态块超时器是RSVP协议是软状态刷新的协议中规定的模块，每个节点会定时发送path或resv消息给下游或上游节点来“保活” LSP，同样，上游或下游节 点会为LSP启动超时器等待LSP “保活”，超时收不到刷新消息就会把LSP删除。其中，上述自刷新状态是指因为停止了超时器，即使LSP收不到刷新消息，LSP也 不会因为超时而被删除，这种状态称为“自刷新状态”。第二、报文分发规则可以是本地地址分布规则。该规则可以通过手工干预或者其 它方法，建立本地地址与NM的关联关系，并且将该关联关系表发送给CORE和S0CKE。其中， 当SOCKE接收到报文时，可以根据接收到报文的目的地址查询关联关系表，SOCKE将报文发 送给对应的匪；当CORE生成处理后的报文时，根据该报文的源地址查询关联关系表，CORE 将处理后的报文发送给对应的NM。其中，目的地址、源地址都可以是本地地址，一个节点有 多个本地地址，本地地址与NM的关系是记录在关联关系表中。这里的本地地址分布规则与接口分布规则相似，本地地址可以唯一关联到一个接 口。对于上游节点发送的报文中包括有路由警告(router-alert)选项的(如path消息， path-tear消息，resvconfirm消息)，其目的地址是LSP末节点的标签交换路由器标识 (lsr-id,Laber-Switch Router Identity)，中间节点的 SOCKET根据接收到的 path 消息的 目的地址(即末节点的lsr-id)查询关联关系表，将该报文发送到lsr-id对应的匪中，而 末节点中向上游节点发送resv消息时，resv消息的出接口作为该resv消息的源地址。当 中间节点从接收到resv消息中获取的resv消息的源地址，与path消息中lsr-id不相同 时，则末节点中处理path消息的匪，与根据resv消息处理邻居关系的匪是不同的匪，从 而导致了末节点中处理业务的错误。因此，对于报文中包括有路由警告(router-alert)选项的，可以不采用本地地址 分布规则。第三、报文分发规则可以是邻居(Peer)地址分布规则。该规则可以通过手工干 预或者其它方法，建立peer地址与NM的关联关系，并且将该关联关系表发送给CORE和 S0CKE。其中，当SOCKE接收到报文时，可以根据接收到报文的源地址分配关联关系表， SOCKE将报文发送给对应的NM ；当CORE生成处理后的报文时，根据该报文的目的地址查询 关联关系表，CORE将处理后的报文发送给对应的NM。根据RSVP协议规定，节点的邻居信息是随着业务报文携带而获得的，在处理业务 的过程中建立邻居关系，在删除业务的过程中删除邻居关系，其中邻居是指上下游节点，与 邻居有关的信息称为邻居信息，邻居信息具体可以是path/resv消息里面的标识的下一跳 (hop)地址。因此，节点可以通过学习邻居关系建立与匪之间的关联关系。如图6所示建 立Peer地址与匪关联关系示意简图，包括步骤611 当SOCKET接收到报文，且该报文的源地址尚未分配匪时，请求peer分 配器分配匪；步骤612 =Peer分配器将分配结果发送给SOCKET，SOCKET记录分配结果，将接收到 的报文发送给分配的匪处理；步骤621 当CORE要对外发送报文时，如果该报文的目的地址尚未分配匪，则 CORE请求peer分配器分配匪；步骤622 :peer分配器为该目的地址分配对应的NM，将分配结果发送给CORE，CORE 记录分配结果，将报文下发给分配的ML
其中，为SOCKET分配匪的peer分配器，与为CORE分配匪的peer分配器可以是 相同的peer分配器。其中，匪和CORE中分别都可以感知承载其中的业务，当匪发现本地的peer地址 与业务无关时，通知peer分配器释放建立的关联关系；或者当CORE发现本地的peer地址 与业务无关时，通知peer分配器释放建立的关联关系。例如在步骤612中peer分配器 为SOCKET分配的匪，与不同于上述图6中说明业务的其他业务中使用到该peer分配器为 SOCKET分配的匪，且SOCKET接收到的报文都来自相同的源地址(即peer地址相同)；或 者，在步骤622中peer分配器根据报文的目的地址(即peer地址)分配对应的匪，CORE 将报文下发给分配的该匪，且该peer地址与分配对应的匪恰好被其它业务所使用到。也 就是说，在peer地址与匪的对应关系被不同的业务同时利用到，那么，需要对该peer地址 与NM的对应关系被利用到的次数进行计数，当有业务执行完毕，不需要利用该peer地址与 匪的对应关系，相应的减少该peer地址与匪的对应关系被利用到的次数，当没有业务再利 用该peer地址与匪的对应关系时，相应的计数可以是零，才可以释放peer地址与匪的对 应关系。其中，在SOCKET中是不能感知业务，因此，通常由匪或者CORE通知peer分配器改 变peer地址与匪的对应关系被利用到的次数，peer分配器可以在计数为零时，释放peer 地址与匪的对应关系。当业务删除时，SOCKET和CORE可以释放peer地址与匪的关联关系。由于SOCKET 不感知RSVP业务，无法释放Peer地址与匪的关联关系，因此，当匪发现本地的peer地址 与业务无关时，通知peer分配器释放建立的关联关系。CORE可以感知RSVP业务，当发现本 地的peer地址与业务无关时，通知peer分配器释放建立的关联关系。当SOCKET和CORE 引用相同的peer地址用于根据该peer地址分配匪时，peer分配器需要记录peer地址的 引用计数，便于peer分配器判断peer地址的引用次数，用来判断是否可以释放该peer地 址，如果有任何一个peer地址与匪的关联关系仍然与业务有关，则不可以释放该peer地 址。上述是对一种自动建立peer与匪关联关系的举例，采用邻居(Peer)地址分布规 则部署……具有更好的灵活性，匪的数量可以随着Peer增多(减少)而自动增加(减少)。 peer与NM的关联关系也可以是手工干预建立的。还需要说明的是，第一 SOCKET还可以根据报文的其它特征(如首节点地址、末节 点地址)建立与匪的关联关系，将接收到的报文发送给对应的匪(也可以称为“上游匪”)。上述说明的报文分发规则并非是对本发明实施例的穷举，不应该理解为对本发明 实施例的限制。为了更清楚的理解上述步骤502提出的业务分布规则，下面详细说明业务分布规 则，包括第一、业务分布规则采用Hash方式。在CORE中可以预设规则，例如某种Hash算 法，以取模算法为例，如下式(1)所示K = χ% η (1)其中，K为CORE实例标识，χ为Session或者LSP标识，η为部署的CORE实例的数 目，％表示取模。假设部署η个CORE实例，每个CORE赋予一个实例标识，从0开始到n_l。对于特定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，将分配结果发送给匪。其中，业务分配器可以根据该节点中可使用的CORE数量和各CORE中的使用率，为 业务分配合理的CORE。如果该业务所属的Session已经分配给一个CORE，则增加用于处理 该Session的CORE的计数，或者，分配一个空闲的CORE，将其分配给Session，记录该空闲 的CORE与归属于Session的关系，如果当前的CORE都非常繁忙，可以增加一个新的CORE来 支撑业务。如果是以LSP为粒度，假设为该LSP归属的业务分配一个CORE，则记录该CORE 上业务的计数。步骤703 匪接收到分配结果，将报文发送给对应的CORE处理。还需要说明的是，当匪在删除业务状态块时，向业务分配器请求释放CORE。业务 分配器减少归属于CORE的Session的计数，当计数为0时，则释放该CORE。如果CORE中没 有任何业务承载，可以根据策略将该CORE占用的物理资源所在的实体脱离该节点。上述说明的两种业务分布规则，都可以将同一个业务的报文分配到相同的CORE 中处理。第三、业务分布规则采用部署方式。通过部署该节点中的CORE和匪的之间的关 系，从而完成NM到CORE的业务关联。其中，部署节点中的CORE何NM的关系的具体情况可 以包括当有η个匪和1个CORE来部署时，如果一个CORE就已经能够提供足够大容量支 持LSP，那么CORE可以固定部署一个，匪可以直接命中CORE来处理业务。或者，匪与CORE以1 1的数量比来部署。其中，一个匪(例如上游NM)绑定 一个CORE。当匪收到新业务消息时，固定上送到与自己绑定的CORE去处理。为了使得归 属于该新业务的所有报文都由同一个CORE处理，对应1 1方式还需要其它控制来完成整 个过程，如图8所示具体包括步骤801 接收到新业务的path消息的匪(称为上游NM)，将消息上送给与该匪 绑定的CORE处理；步骤802 与匪绑定的CORE接收到path消息后，根据上述说明的报文分发规则， 将path消息转发到下游匪；步骤803 下游匪接收到新业务的resv消息，该消息被发送到处理path消息的 CORE中。其中，将resv消息发送到处理path消息的CORE中的具体操作可以包括
15
下游匪通过广播查询业务所在的CORE，从而实现将reSV消息发送到处理path消 息的CORE中；或者，对于设立业务集中点的情况下，下游匪在业务集中点中查询业务所属的 CORE,从而实现将resv消息发送到处理path消息的CORE中；或者，下游匪在步骤802中记录业务(具体是path消息)与CORE的关系，收到 Resv消息时查表得知CORE所在实例。步骤804 =CORE将向上游节点回复的resv消息发给上游匪。上述对业务分布规则的说明，还需要说明的是，报文分发规则和业务分布规则可 以不限于上述说明的实例，还可以采取其它方式。综上对本实施例的说明，可以获知将RSVP实例划分为匪和CORE两部分，且匪和 CORE的数量可以灵活部署。具体可以根据实际需要，将多个构件(其中，一个构件指单个 的NM或者CORE)合并部署为一个实例；或者将一个构件的功能分拆为多个，分别部署到不 同实例上；或者将一个构件的功能分拆为多个，然后再与其他构件合并部署为一个实例。这 种部署方式的改变仍然是基于本方案实现原理，属于本实施例的覆盖范围内。下面结合图 9、图10、图11举例说明构件的部署方式。如图9所示部署一个匪和多于一个的CORE，采用这种部署方式下RSVP实例的接 口与匪之间不需要报文分分发规则，匪将要发送的报文通过业务分布规则发送给对应的 CORE中处理。其中，如果业务分布规则采用集中方式，则上述说明的业务分配器可以集中在 匪中。采用图9所示的部署方式极大的简化了 RSVP的实现方法。图10所示部署多于一个匪和一个CORE。采用这种部署方式下RSVP实例的 SOCKET (SOCKET)与匪之间根据报文分发规则具有关联。匪与CORE之间不需要业务分布 规则，直接命中。匪承担了大量报文刷新工作，单个CORE可以通过减少LSP状态块内存开 销来承载更多LSP。采用图10所示的部署方式可以节省业务分配所需要的控制和开销。图11所示部署匪与CORE的数量比值为1 1。采用这种部署方式下SOCKET给 RSVP实例之间的报文传输可以根据上述说明的报文分发规则，NM与CORE之间的关系实际 上变成了 RSVP实例之间的关系。详细说明可以参考图8中及其说明，此处不重述。图12所示为本发明实施还提供的一种处理报文的装置，该节点包括第
一SOCKET 101,上游邻居管理(NM) 102，核心处理实例(CORE) 103，下游匪104，和第二 S0CKET105 ；第一 SOCKET，用于接收上游节点发送的报文，将接收到的报文发送给上游邻居管 理(NM)；上游匪，用于接收第一 SOCKET发送的报文，将接收到的报文发送给CORE ；CORE，用于接收上游匪发送的报文，执行业务处理，生成处理后的第一报文；将处 理后的第一报文发送给下游匪；下游匪，用于接收CORE发送的处理后的第一报文，将处理后的第一报文发送给第
二SOCKET ；第二 SOCKET，用于接收下游匪发送的处理后的第一报文，将处理后的第一报文发 送给下游节点。通过上述对该节点的说明，该节点中将RSVP实例划分为匪和CORE两部分，实现对上游节点发送的报文的处理，可以灵活的扩展匪和CORE的数量，且可以将业务更合理的 分配到多个CORE中，从而大大提高了 RSVP实例所支持的LSP数量，且大大提高了 RSVP的
工作效率。进一步，该装置还可以实现对下游节点发送的报文的处理，则第二 SOCKET，还用于接收下游节点发送的报文，将报文发送给下游NM ；下游匪，还用于接收第二 SOCKET发送的报文，将报文发送给CORE ；CORE，还用于接收下游匪发送的报文，根据报文，执行业务处理，生成处理后的第 二报文；将处理后的第二报文发送给上游匪；上游匪，还用于接收处理后的第二报文，将处理后的第二报文发送给第一 SOCKET ；第一 SOCKET，还用于接收处理后的第二报文，将处理后的第二报文发送给上游节
点ο进一步，若第一 SOCKET接收上游节点发送的报文为path消息，且上游匪中没有接收path 消息状态块，则上游NM，还用于根据接收到的path消息，建立接收path消息状态块；若第一 SOCKET接收上游节点发送的报文为path消息，上游NM中有接收path消 息状态块，则上游匪，还用于判断接收到path消息中状态与接收path消息状态块中的状态 是否一致，如果不一致，将接收到的path消息发送给CORE ；若处理后的第一报文为处理后的path消息，且下游匪中没有发送path消息状态 块，则下游NM，还用于根据接收到的处理后的path消息，建立发送path消息状态块； 根据发送path消息状态块中信息，通过第二 SOCKET发送处理后的path消息给下一跳进行 刷新；若第二 SOCKET接收下游节点发送的报文为resv消息，且下游匪中没有接收resv 消息状态块，则下游匪，还用于根据接收到的resv消息，建立接收resv消息状态块；若第二 SOCKET接收下游节点发送的报文为resv消息，且下游匪中有接收resv 消息状态块，则下游匪，还用于判断接收到resv消息中状态与接收resv消息状态块中的状态 是否一致，如果不一致，将接收到的报文发送给与CORE ；若处理后的第二报文为处理后的resv消息，且上游匪中没有发送resv消息状态 块，则上游匪，还用于根据接收到的处理后的resv消息，建立发送resv消息状态块； 根据发送resv消息状态块中信息，发送处理后的resv消息给下一跳进行刷新。进一步，第一 SOCKET，具体用于接收上游节点发送的报文，根据报文分发规则，将 接收到的报文发送给上游匪，所述报文分发规则包括套接字中接收所述报文的端口号与 NM的关联关系，所述报文的目的地址与NM的关联关系，或者所述报文的源地址与NM的关联关系中的一种或多种；则CORE，具体用于根据所述业务分布规则，将所述处理后的报文发送给下游匪， 所述下游匪根据所述报文分发规则，将所述处理后的报文通过第二套接字发送给下游节
点ο进一步，装置中包括多于一个的CORE时，上游匪，具体用于以报文所归属会话为 粒度，或者以报文所使用的标签选择路径(LSP)为粒度，根据业务分布规则，将接收到的报 文发送给CORE。进一步，业务分布规则为哈希(Hash)方式。进一步，装置还包括业务分配器106，用于接收上游匪发送的分配CORE请求，为 报文归属的业务分配CORE，将分配结果发送给上游NM ；则上游匪，具体用于根据分配结果，将接收到的报文发送给CORE ；进一步，若装置中匪与CORE以1 1的数量比来部署，且第一 SOCKET所归属的 装置包括多于一个的NM时，上游NM,具体用于将接收到的path消息发送给与上游NM绑定 的 CORE ；且下游匪，具体用于将接收到的resv消息，发送给与上游匪绑定的CORE。进一步，下游匪中将接收到的resv消息，发送给与上游匪绑定的CORE，具体包 括下游NM通过广播查询resv消息归属业务所在的CORE，从而将resv消息发送给与 上游匪绑定的CORE ；或者，下游匪向业务集中点查询resv消息归属业务所在的CORE，从而将resv消 息发送给与上游匪绑定的CORE ；或者，下游匪根据记录的发送path消息的CORE，将resv消息发送给与上游匪绑 定的CORE。上述是对本发明实施例提供的装置的说明，需要理解的是，对装置的更详细的说 明也可以参考图3至图11中关于报文处理方法中有关的说明，此处不重述。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以 通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质 中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁 碟、光盘、只读存储记忆体(Read-Only Memory, ROM)或随机存储记忆体(Random Access Memory, RAM)等。以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式
对本发明进行 了阐述，以上实施例的说明只是用于帮助理解本发明的方法及设备；同时，对于本领域的 一般技术人员，依据本发明的思想，在具体实施方式
及应用范围上均会有改变之处，综上所 述，本说明书内容不应理解为对本发明的限制。
权利要求
1.一种处理报文的方法，其特征在于，包括第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；上游邻居管理将接收到的报文发送给核心处理实例；所述核心处理实例根据接收到的所述报文，执行业务处理，生成处理后的第一报文；所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将 处理后的第一报文通过第二套接字发送给下游节点。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括第二套接字接收所述下游节点发送的报文，将所述报文发送给下游邻居管理；下游邻居管理将所述报文发送给所述核心处理实例；所述核心处理实例根据接收到的所述下游邻居管理发送的报文，执行业务处理，生成 处理后的第二报文；所述核心处理实例将所述处理后的第二报文发送给上游邻居管理，由上游邻居管理将 处理后的第二报文通过第一套接字发送至所述上游节点。
3.根据权利要求2所述的方法，其特征在于，若第一套接字接收上游节点发送的报文为path消息，且上游邻居管理中没有接收 path消息状态块，则所述方法还包括所述上游邻居管理根据接收到的path消息，建立所 述接收path消息状态块；若第一套接字接收上游节点发送的报文为path消息，所述上游邻居管理中有接收 path消息状态块，则所述方法还包括上游邻居管理判断接收到path消息中状态与所述接 收path消息状态块中的状态是否一致，如果不一致，上游邻居管理将接收到的报文发送给 所述核心处理实例；若所述处理后的第一报文为处理后的path消息，且下游邻居管理中没有发送path消 息状态块，则所述方法还包括下游邻居管理根据接收到的处理后的path消息，建立所述 发送payh消息状态块；其中，所述下游邻居管理根据所述发送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所述的装置，其特征在于，所述装置还包括业务分配器，用于接 收所述上游邻居管理发送的分配核心处理实例请求，为所述报文归属的业务分配核心处理 实例，将分配结果发送给所述上游邻居管理；则所述上游邻居管理，具体用于根据分配结果，将接收到的报文发送给核心处理实例。
全文摘要
本发明实施例涉及通信技术领域，公开了一种处理报文的方法和装置，其中该方法包括第一套接字接收上游节点发送的报文，将接收到的报文发送给上游邻居管理；上游邻居管理将接收到的报文发送给核心处理实例；所述核心处理实例根据接收到的所述报文，执行业务处理，生成处理后的第一报文；所述核心处理实例将所述处理后的第一报文发送给下游邻居管理，由下游邻居管理将处理后的第一报文通过第二套接字发送给下游节点。采用将RSVP实例划分为NM和CORE两部分，从而大大提高了RSVP实例所支持的LSP数量。
文档编号H04L12/56GK102143037SQ20101021386
公开日2011年8月3日 申请日期2010年6月23日 优先权日2010年6月23日
发明者吕鑫, 祝广东, 贺志国, 赖晓, 饶国义 申请人:华为技术有限公司