通信系统以及服务器装置.pdf

本发明涉及通信系统以及服务器装置，其目的是，在提供可以将广域IP网用作企业的通信基础设施的服务的通信业者的网络系统中，尤其是在开放用户可以自由进行与利用服务有关的设定变更的设定接口的网络系统中，多个用户可以同时进行设定变更。在将来自用户终端的设定变更请求进行分类的控制请求分类部(20)中，按每个控制对象节点以及接口将请求内容分类，并存储在控制请求管理部(21)中。受理判定部(22)对每个控制对象汇总地判定可否受理请求。控制发布部(23)还在针对节点装置的设定变更时，汇总被认可受理的针对同一节点的请求进行排序。

1.  一种通信系统，其具有：构成在多个用户网络之间进行连接的网络，按照控制请求变更所述用户网络之间的逻辑线路的设定信息的多个节点装置；发送所述设定信息的终端；以及从所述终端接收所述设定信息，向所述节点装置发送控制请求的服务器装置，其特征在于，
所述终端具有：
输入部，其输入所述用户网络之间的逻辑线路的设定信息；以及
发送部，其将所述设定信息发送给所述服务器装置，
所述服务器装置具有：
接收部，其从所述终端接收所述设定信息；
分类部，其对位于所述逻辑线路的路径上的所述节点装置以及该节点装置的接口的每一个，将所述接收部接收到的所述设定信息进行分类；
请求存储部，其对所述节点装置以及该节点装置的接口的每一个，存储由所述分类部分类的所述设定信息；
资源存储部，其存储与所述节点装置的各接口连接的物理线路的带宽信息；
受理判定部，其对于各个节点装置的接口，根据所述物理线路的带宽信息和所述逻辑线路的设定信息，判定可否受理设定信息；以及
控制发布部，其根据由所述受理判定部判定为可受理的所述逻辑线路的设定信息，生成针对所述节点装置的控制请求。

2.  根据权利要求1所述的通信系统，其特征在于，
还具备路径信息管理部，该路径信息管理部对应所述逻辑线路的识别信息，存储位于该逻辑线路的路径上的所述节点装置的识别符以及该节点装置的接口的识别符，
所述服务器装置的所述分类部具有下述单元：
根据所述设定信息中包含的逻辑线路的识别信息，参照所述路径信息管理部，提取通信路径上的所述节点装置的识别符以及该节点装置的接口的识别符的单元；以及
对提取出的所述节点装置的识别符以及该节点装置的接口的识别符的每一个，将所述设定信息存储在所述请求存储部中的单元。

3.  根据权利要求2所述的通信系统，其特征在于，
还具备管理控制对象的所述节点装置的识别符的对象列表管理部，
所述服务器装置的所述分类部，
将提取出的所述节点装置的识别符与所述对象列表管理部管理的控制对象的所述节点装置的识别符进行核对，
在核对的结果一致时，对成为控制对象的所述节点装置的识别符以及该节点装置的接口的识别符的每一个，将所述设定信息存储在所述请求存储部中。

4.  根据权利要求1所述的通信系统，其特征在于，
所述受理判定部汇总在所述请求存储部中存储的同一节点装置以及同一接口的多个设定信息来进行可否受理判定，将判定结果存储在所述请求存储部中。

5.  根据权利要求4所述的通信系统，其特征在于，
所述受理判定部在可否受理的判定结果为否时，从后登录的设定信息开始依次删除，反复进行可否受理判定，将可受理的设定信息和不能受理的设定信息进行分类，并将结果存储在所述请求存储部中。

6.  根据权利要求4所述的通信系统，其特征在于，
所述受理判定部在可否受理的判定结果为否时，采用2分查找法将可受理的设定信息和不能受理的设定信息进行分类，并将结果存储在所述请求存储部中。

7.  根据权利要求1所述的通信系统，其特征在于，
所述控制发布部按照所述请求存储部中存储的同一节点装置以及同一接口的单位，汇总由所述受理判定部判定为可受理的设定信息，生成向该节点装置的控制请求。

8.  根据权利要求1所述的通信系统，其特征在于，
所述服务器装置的所述接收部接收多个设定信息，
当接收到设定信息时，在队列中累积分类处理等待，
当执行了分类处理时，在所述队列中累积受理判定处理等待，
当执行了受理判定处理时，在所述队列中累积控制发布处理等待，
所述受理判定部对于所述队列中连续累积的关于多个设定信息的受理判定处理等待进行汇总来判定可否受理，以及所述控制发布部对于在所述队列中连续累积的关于多个设定信息的控制发布处理等待进行汇总来生成控制请求。

9.  根据权利要求1所述的通信系统，其特征在于，
所述服务器装置的所述接收部接收多个设定信息，
在预定的每个定时，所述受理判定部对于多个设定信息进行汇总来判定可否受理，以及所述控制发布部对于多个设定信息进行汇总来生成控制请求。

10.  根据权利要求1所述的通信系统，其特征在于，
所述设定信息包含所述逻辑线路的带宽信息以及优先度中的某一个。

11.  根据权利要求1所述的通信系统，其特征在于，
具备多个所述终端，
所述服务器装置的所述接收部从多个所述终端接收多个设定信息。

12.  一种服务器装置，其用于下述的通信系统中，该通信系统具有：构成在多个用户网络之间进行连接的网络，按照控制请求变更所述用户网络之间的逻辑线路的设定信息的多个节点装置；发送所述设定信息的终端；以及从所述终端接收所述设定信息，向所述节点装置发送控制请求的服务器装置，其特征在于，
具有：接收部，其从所述终端接收所述用户网络之间的逻辑线路的所述设定信息；
分类部，其对位于所述逻辑线路的路径上的所述节点装置以及该节点装置的接口的每一个，将所述接收部接收到的所述设定信息进行分类；
请求存储部，其对所述节点装置以及该节点装置的接口的每一个，存储由所述分类部分类的所述设定信息；
资源存储部，其存储与所述节点装置的各接口连接的物理线路的带宽信息；
受理判定部，其对于各个节点装置的接口，根据所述物理线路的带宽信息和所述逻辑线路的设定信息，判定可否受理设定信息；以及
控制发布部，其根据由所述受理判定部判定为可受理的所述逻辑线路的设定信息，生成针对所述节点装置的控制请求。

13.  根据权利要求12所述的服务器装置，其特征在于，
所述分类部具有下述单元：
参照与所述逻辑线路的识别信息对应地存储有位于该逻辑线路的路径上的所述节点装置的识别符以及该节点装置的接口的识别符的路径信息管理部，根据所述设定信息中包含的逻辑线路的识别信息，提取通信路径上的所述节点装置的识别符以及该节点装置的接口的识别符的单元；以及
对提取出的所述节点装置的识别符以及该节点装置的接口的识别符的每一个，将所述设定信息存储在所述请求存储部中的单元。

14.  根据权利要求13所述的服务器装置，其特征在于，
所述分类部将提取出的所述节点装置的识别符与由管理控制对象的所述节点装置的识别符的对象列表管理部管理的控制对象的所述节点装置的识别符进行核对，
在核对的结果一致时，对成为控制对象的所述节点装置的识别符以及该节点的接口的识别符的每一个，将所述设定信息存储在所述请求存储部中。

15.  根据权利要求12所述的服务器装置，其特征在于，
所述受理判定部汇总在所述请求存储部中存储的同一节点装置以及同一接口的多个设定信息来进行可否受理判定，将判定结果存储在所述请求存储部中。

16.  根据权利要求15所述的服务器装置，其特征在于，
所述受理判定部在可否受理的判定结果为否时，从后登录的设定信息开始依次删除，反复进行可否受理判定，将可受理的设定信息和不能受理的设定信息进行分类，并将结果存储在所述请求存储部中。

17.  根据权利要求15所述的服务器装置，其特征在于，
所述受理判定部在可否受理的判定结果为否时，采用2分查找法将可受理的设定信息和不能受理的设定信息进行分类，并将结果存储在所述请求存储部中。

18.  根据权利要求12所述的服务器装置，其特征在于，
所述控制发布部，按照所述请求存储部中存储的同一节点装置以及同一接口的单位，汇总由所述受理判定部判定为可受理的设定信息，生成向该节点装置的控制请求。

19.  根据权利要求12所述的服务器装置，其特征在于，
所述接收部接收多个设定信息，
当接收到设定信息时，在队列中累积分类处理等待，
当执行了分类处理时，在所述队列中累积受理判定处理等待，
当执行了受理判定处理时，在所述队列中累积控制发布处理等待，
所述受理判定部对于所述队列中连续累积的关于多个设定信息的受理判定处理等待进行汇总来判定可否受理，以及所述控制发布部对于在所述队列中连续累积的关于多个设定信息的控制发布处理等待进行汇总来生成控制请求。

20.  根据权利要求12所述的服务器装置，其特征在于，
所述接收部接收多个设定信息，
在预定的每个定时，所述受理判定部对于多个设定信息进行汇总来判定可否受理，以及所述控制发布部对于多个设定信息进行汇总来生成控制请求。

通信系统以及服务器装置
技术领域
本发明涉及通信系统以及服务器装置，特别涉及在构成通信业者提供服务的虚拟专用网络的系统中，控制网络资源的通信系统以及服务器装置。
背景技术
作为将广域IP网用作企业的通信基础设施的机构，具有被称为广域以太网(注册商标)或IP-VPN(Virtual Private Network)的由通信业者提供的服务。在这些服务中，为以下的流程：诸如据点的增加或VPN带宽的变更这样的来自最终用户的服务请求通过书面或者表单输入等与服务提供业者进行联络，收到请求的服务提供业者考虑网络设备的资源利用状况进行可否受理的判断，进行针对网络设备的设定变更。
关于提供VPN的业者和提供构筑VPN的广域IP网的业者不同时的、来自用户的服务变更流程，例如在专利文献1的图1中进行了介绍。此时的来自最终用户的服务请求是以用户侧的VPN管理者进行中介的形式向广域IP网管理者进行申请的方式。在专利文献1的技术中，作为削减从服务请求产生开始到实际进行服务变更为止的时滞的机构，公开了将广域IP网策略与VPN策略一同进行存储，进行针对广域IP网的VPN策略验证，或者针对VPN策略的服务请求验证的VPN策略管理装置。
此外，在专利文献2中，作为把针对跨越广域IP网的VPN的资源分配请求的响应时间缩短的机构，公开了把作为IP-VPN广域网的策略分配的通信设备的资源信息，作为VPN资源信息设定在VPN策略服务器中的IP-VPN策略服务器。
另一方面，在专利文献3中，公开了在从多个用户节点通信量集中于一个用户节点时，按不同发送源用户节点确保带宽，同时对应从某个用户节点接收到的数据量，变更从其他用户节点的输出速度的方法。
并且，在专利文献4中公开了通过设置多个用户请求受理部，来减轻用户请求部的处理负荷来抑制性能的降低，避免整个受理控制功能的性能降低的方法。
【专利文献1】特开2001-251307号公报
【专利文献2】特开2005-39644号公报
【专利文献3】特开2006-345173号公报
【专利文献4】特开2003-69635号公报
发明内容
本发明要解决的课题之一是提供一种设定接口，其在提供可以将广域IP网用作企业的通信基础设施的服务的通信业者的网络系统中，能够以与用户进行本公司设备设定变更相同的快速反应性，进行关于利用服务的设定变更。
特别是在对用户开放了上述的设定接口时，可能会有多个用户进行与通信业者网络的设备有关的设定变更。由此，在产生了多个变更请求时，还需要在抑制用户的等待时间的同时，反映各自的变更请求，因此需要一边为了在通信业者的网络中不产生矛盾或不匹配而进行调整，一边进行网络设备的设定变更。
在专利文献1或专利文献2中，没有涉及上述那样的多个用户发布变更请求时的课题。
在专利文献3中，叙述了从多个用户节点在一个用户节点中通信量集中时的带宽控制方法，但没有考虑新产生的多个请求成为向同一用户节点的通信量集中时的判定控制等。
在专利文献4中，叙述了通过设置多个用户请求受理部，减轻用户请求部的处理负荷的方法，但没有考虑多个用户请求影响的传输装置以及链路重复的情况。虽然对于用户请求的范围跨越多个带宽管理部的情况进行了记载，但采用按照请求的顺序一个一个地进行判定处理的方式。因此，在产生多个向某个带宽管理部的请求时，直到处理最后的请求为止需要花费时间，可能会丧失快速反应性。
本发明鉴于以上的问题，其目的在于提供一种即使在多个用户发布了设定变更请求的情况下，抑制用户的等待时间，同时一边进行控制使通信业者网络中不会产生矛盾或者不匹配，一边进行网络设备的设定变更的通信系统以及服务器装置。
本发明的特征之一在于，在判定可否受理用户请求时，并非只参照在节点装置中设定反映的实际资源信息，还考虑对重复的用户请求进行管理的队列中先前累积的请求内容来进行受理判定。
并且，本发明的另一个特征为：在进行针对节点装置的设定更新时，汇总用户请求中的通过受理判定被认可的多个请求内容来进行排序。
根据本发明的第一解决方法，提供一种通信系统，其具有：构成在多个用户网络之间进行连接的网络，按照控制请求变更所述用户网络之间的逻辑线路的设定信息的多个节点装置；发送所述设定信息的终端；以及从所述终端接收所述设定信息，向所述节点装置发送控制请求的服务器装置，
所述终端具有：输入部，其输入所述用户网络之间的逻辑线路的设定信息；以及
发送部，其将所述设定信息发送给所述服务器装置，
所述服务器装置具有：接收部，其从所述终端接收所述设定信息；
分类部，其对位于所述逻辑线路的路径上的所述节点装置以及该节点装置的接口的每一个，将所述接收部接收到的所述设定信息进行分类；
请求存储部，其对所述节点装置以及该节点装置的接口的每一个，存储由所述分类部分类的所述设定信息；
资源存储部，其存储与所述节点装置的各接口连接的物理线路的带宽信息；
受理判定部，其对于各个节点装置的接口，根据所述物理线路的带宽信息和所述逻辑线路的设定信息，判定可否受理设定信息；以及
控制发布部，其根据由所述受理判定部判定为可受理的所述逻辑线路的设定信息，生成针对所述节点装置的控制请求。
根据本发明的第二解决方法，提供一种下述通信系统中的服务器装置，该通信系统具有：构成在多个用户网络之间进行连接的网络，按照控制请求变更所述用户网络之间的逻辑线路的设定信息的多个节点装置；发送所述设定信息的终端；以及从所述终端接收所述设定信息，向所述节点装置发送控制请求的服务器装置，
该服务器装置具有：
接收部，其从所述终端接收所述用户网络之间的逻辑线路的所述设定信息；
分类部，其对位于所述逻辑线路的路径上的所述节点装置以及该节点装置的接口的每一个，将所述接收部接收到的所述设定信息进行分类；
请求存储部，其对所述节点装置以及该节点装置的接口的每一个，存储由所述分类部分类的所述设定信息；
资源存储部，其存储与所述节点装置的各接口连接的物理线路的带宽信息；
受理判定部，其对于各个节点装置的接口，根据所述物理线路的带宽信息和所述逻辑线路的设定信息，判定可否受理设定信息；以及
控制发布部，其根据由所述受理判定部判定为可受理的所述逻辑线路的设定信息，生成针对所述节点装置的控制请求。
根据本发明，可以提供一种即使在多个用户发布了设定变更请求的情况下，抑制用户的等待时间，同时一边进行控制使通信业者网络中不会产生矛盾或者不匹配，一边进行网络设备的设定变更的通信系统以及服务器装置。
附图说明
图1是表示本发明实施方式的一例的网络结构图。
图2是说明按顺序处理多个请求时的课题的流程图。
图3是资源控制受理程序的功能框图。
图4表示本实施方式的控制请求管理表的一构成例。
图5是表示用户请求接收时的资源控制受理装置的处理顺序的流程图。
图6是表示判定控制部的处理顺序的流程图。
图7表示判定控制部的处理队列的一构成例。
图8表示判定控制部的处理队列的另一构成例。
图9表示用户请求的设定画面的一例。
图10是表示请求分类处理的处理顺序的流程图。
图11是表示受理判定处理的处理顺序的流程图。
图12是表示控制发布处理的处理顺序的流程图。
图13表示对象列表管理表的一构成例。
图14表示资源管理表的一构成例。
图15表示路径信息管理表的一构成例。
图16表示契约信息管理表的一构成例。
图17表示设定信息管理表的一构成例。
图18是本实施方式的资源控制受理装置的结构图。
符号说明
1用户终端、2用户网络、3用户节点、4接入网、5边缘节点、6核心节点、7区域网、8核心网、9管理用网络、10资源控制受理装置、11请求受理部、15判定控制部、16控制执行部、17路径信息管理部、18对象列表管理部、19资源管理部、20控制请求分类部、21控制请求管理部、22受理判定部、23控制发布部、309资源控制受理程序
具体实施方式
以下使用附图对本实施方式进行说明。
图1是表示本实施方式的一例的网络结构图。
作为连接在跨越多个地域据点的同一企业的网络(用户网络2)彼此之间的通信基础设施，通信业者提供广域IP网服务。
各个用户网络2和通信业者提供服务的网络经由接入网4连接。用户网络2一侧的与接入网4的连接经由用户节点3来进行。
将核心网络8划分为几个区域，通过相互彼此连接在每一个区域设置的区域网7来构成通信业者一侧的网络。各区域网络具备核心节点6，区域网7彼此之间相互连接构成各个区域网7的核心节点6。例如，如果是区域网7a和区域网7b之间，则相互连接核心节点6c和核心节点6d。区域网7与接入网4之间通过核心节点6和边缘节点5相互连接。核心节点和边缘节点的关系不限于1对1，一个核心节点(例如6a)可以和多个边缘节点(例如5a、5b)相互连接。同样地，边缘节点(例如5a)也可以经由接入网4a，收容多个用户据点(例如30、31)。因为通过这样的树结构构成了网络，所以成为在上游的装置中聚集来自自身以及多个用户据点的通信量的形式。
在本实施方式中，在上述这样的提供在企业据点之间进行连接的通信基础设施的服务中，使用户可以自由并且实时地变更与企业用户利用的通信线路有关的设定。特别是即使多个用户同时进行设定变更，也可以提供在通信业者网络中不产生矛盾或不匹配，并且抑制了用户等待时间的设定变更。
关于提供这样的设定变更功能时的网络结构，分别通过核心节点6e和边缘节点5d将上述核心网络8和管理用网络9连接，并在管理用网络9内设置资源控制受理装置(服务器装置)10。
用户企业的网络管理者在利用本服务进行设定变更时，从自身的网络(用户网络2)内的终端1向资源控制受理装置10发布请求。终端1，例如具有输入据点(用户网络)之间的IP-VPN(逻辑线路)的设定信息的输入部、以及把设定信息发送给资源控制受理装置10的发送部。
此时，关于用户终端1和资源控制受理装置10之间的通信方式，可以通过独自的客户应用程序和独自的通信方式来进行，或者还可以通过在后面所示的图9那样的从浏览器画面的输入形式以及使用了HTTP/HTTPS的通信方式来实现。在采用图9所示的从浏览器画面的输入形式时，在管理用网络9内还需要Web服务器，因为可以应用一般的Web服务器/技术，所以在图1中被省略。此外，关于图9，将在后面进行详细地说明。转回话题，使用图1补充说明多个用户同时进行了设定变更时的课题。多个用户的设定变更所产生的影响的重点例如是来自多个用户据点的通信量集中处于同一线路。在上述树结构的网络的终端中，虽然有可能在装置上线路聚集多个用户的通信量，但因为端口/逻辑接口成为用户专用，所以不会产生通信量处于同一线路的形式。但是，在上游的核心节点中，因为不可能以全部用户各自的通信量为对象分配资源，所以必然会成为通信量同处于同一线路中的形式。一般构筑成越是上游的网络，线路带宽越大，但全部的线路并不均一。例如，区域网1(7a)和区域网2(7b)之间、核心节点6c和核心节点6d之间等，有时变得比其他的核心网/区域网内的线路小。在这样的线路中，某个用户进行的设定变更会对其他用户的通信量造成影响。
作为一个例子，将图1的据点30、31、32假设为同一企业的据点。各个据点布置了用户NW。该用户企业的网络管理者例如在把最初在据点30和31之间设立的VPN线路变更为据点30和32之间时，通过本设定变更，在连接区域网1(7a)和区域网2(7b)的线路中施加新的通信量。
关于上述的重点，需要判定可否受理设定请求，但也有可能多个用户同时进行同样的设定变更。此时，也有按照请求的到达顺序，按顺序进行处理的方法，但有可能被轮到后面的用户对于等待时间抱有不满。使用图2说明按顺序进行处理的方法的课题。
图2是说明按顺序处理多个请求时的课题的顺序图。
图中记载的用户终端是指由利用本服务的企业的网络管理者操作的用户网络内的终端，发布与服务有关的变更请求。最初，是用于输入变更内容的向系统的登录(S1)。虽然省略了图示，但在该步骤中进行认证确认等。
来自用户的请求在资源控制受理装置10中进行处理。在用户向系统进行登录时，生成并提示用户输入画面(S2)。
图9是提示的用户输入画面的例子。例如对每个据点提示作为契约信息的据点、契约带宽的信息(90、91)。此外，关于用户设定完的信息，例如按据点单位进行分类来提示(92、93、94)。
图16是契约信息表的结构图。图17是设定信息表的结构图。契约信息和设定信息例如可以分别从管理契约信息表的数据库(契约信息DB，图16)、和管理设定信息表的数据库(设定信息DB，图17)取得。契约信息表例如对应地存储用户识别符、据点识别符以及契约带宽。设定信息表对应地存储用户识别符、据点识别符、VPN-ID、带宽信息以及优先度信息。从各表读出信息，用于生成图9的用户输入画面。
此外，在后述的图3中表示了资源控制受理装置10的功能框图，因为到此为止的顺序可应用一般的现有技术，所以在功能框图中省略。可以将契约信息DB和设定信息DB全部安装在与资源控制受理装置10不同的装置中。此时，与资源控制受理装置10相同，设置在管理用网络9内。
既有的设定的变更一边参照变更前的信息，一边输入(97)或者选择(98)变更后的信息。在删除既有的设定自身时，利用相应的设定附带的删除按钮96，在新追加设定时，利用追加按钮95。在按下了追加按钮时，在通过对话框催促输入要追加的VLAN-ID后，生成并提示在92中示例的输入画面。但在追加时，没有变更前的设定信息。在通过追加或者变更输入的带宽信息的合计值超过了据点的合计带宽(契约带宽)时，在输入时向用户发出警告。即，即使按下更新按钮，也会进行控制以使变更请求不会传达到资源控制服务器10中，进行输入内容的错误通知。
如上所述，在图9中提示了将每个据点的设定信息进行了汇总的图像的用户输入画面例子，但也可以是提示按VLAN-ID单位进行了分类的设定信息的方式。此外，还可以不提供图9那样的基于GUI(Graphical User Interface)的用户输入方法，而是提供基于CUI(Command-line User Interface)的用户输入方法，提供与针对用户节点3的设定变更同样的操作性。
再次返回图2的说明，利用图9那样的画面，用户终端例如通过键盘或者鼠标等输入部输入要进行设定变更的信息，通过按下更新按钮发布请求(S3)。收到设定变更请求S3的资源控制受理装置进行可否受理设定变更请求的判定(S4)。在无法受理时，回复该主旨，在可以受理时，对相应的节点装置发布设定变更请求(S5)。收到设定变更请求S5的节点装置进行可否变更的判定(S6)，执行设定的变更(S7)。收到来自节点装置的针对请求的应答的资源控制受理装置向用户终端通知结果(S8)，然后转移到下一个请求处理(S9)。
在像上述那样进行针对设定变更请求的处理时，在刚收到来自某个用户的请求S3时，即使收到来自其他用户的几乎同时发布的请求，在在先累积的请求的处理结束之前，不会对按照处理队列的顺序在后累积的请求进行处理。在上述的例子中，换句话说，从S3到S8的期间成为等待时间。通过使变更请求的受理判定处理和针对节点装置的设定变更处理独立地动作，在在先累积的请求的受理判定处理结束之后，可以快速地进行下一个累积的请求的受理判定。但是，因为最终反映设定并成为可以利用是在针对节点装置的设定变更完成之后，所以虽然也许能够缩短到判定出受理判定结果为止的时间，但存在直到反映设定并成为可以利用为止的时间没有被改善的课题。
在本实施方式中，实现了即使在如此集中了多个请求的情况下，也抑制了用户的等待时间的资源控制处理。在本实施方式中，网络资源控制系统等在判定可否受理用户请求时，参照在节点装置中设定反映的实际资源信息，并且考虑在对重复的用户请求进行管理的队列中在先累积的请求内容来进行受理判定，即使不等到队列中在先累积的请求向实际的节点装置的设定反映结束，也可进行受理判定，缩短针对用户请求的判定等待时间。此外，在本实施方式中，网络控制系统在进行针对节点装置的设定更新时，汇集用户请求中的通过受理判定被认可的多个请求内容来进行排序，即使在多个用户同时发布了关于同一节点装置的设定变更请求时，也能削减节点装置的与设定变更请求有关的负荷。
图18是本实施方式的资源控制受理装置10的结构图。
本实施方式的资源控制受理装置10具备处理器301、存储器302、存储装置303以及网络接口(304以及305)。例如，在一般的服务器装置中安装资源控制受理程序309。资源控制受理程序309被存储在存储装置304中，在执行程序时被加载到存储器302上，通过处理器301运行。
路径信息管理部17与一般的网络管理系统管理的路径信息管理部相同，汇集了在各个节点装置中设定的路径信息。如图18所示，路径信息管理部17是由具备CPU311、存储器312、存储装置313、网络接口314的通用的数据库装置310管理的表信息。
在图15中表示路径信息管理表的一构成例。
径信息管理表存储VPN-ID150、发送源152以及发送目的地154、路径信息156。路径信息156例如存储通过VPN-ID150确定的路径，或通过发送源152以及154确定的路径中的节点装置的识别符、接口的识别符。
另一方面，对象列表管理部18登录管理节点装置以及接口，该节点装置以及接口包含用户的设定变更对其他用户的通信量造成影响的关键点(线路)。如图18所示，对象列表管理部18是由具备CPU321、存储器322、存储装置323、以及网络接口324的通用的数据库装置320管理的表信息。这些是该网络的管理者(通信业者网络的管理者)事先登录了在图1的说明中示例的线路带宽窄的关键点(在图1中以6c和6d之间为进行了说明)的节点装置(例如6c或6d)以及对象接口(图13)。
资源管理部19的结构可以和现有的网络管理系统或节点管理系统中使用的资源管理部相同。如图18所示，资源管理部19是由具备CPU331、存储器332、存储装置333、以及网络接口334的通用的数据库装置330管理的表信息。作为极限值的设定，可以是基于与物理线路的带宽相等的值的运用，或者还可以是对物理线路的带宽追加根据系统的配置设定的允许带宽的值的运用(图14)。
在图14中表示资源管理表的一构成例。资源管理表对应地存储节点识别符140、接口识别符142、上限带宽144、以及已预约带宽146。
顺便提一下，在图18中，用分别由不同的装置构成的图形表示了存储路径信息管理部17的数据库装置310、存储队列列表管理部180的数据库装置320、以及存储资源管理部19的数据库装置330，但也可以是通过同一数据库装置管理这些信息的结构。
图3是资源控制受理程序309的功能框图。
资源控制受理程序309例如具有请求受理部11、判定控制部15以及控制执行部16。判定控制部15具有控制请求分类部20、控制请求管理部21、受理判定部22、以及控制发布部23。
在图3中，仅记载了与取得设定变更请求(S3)后的处理有关的功能框图。
在资源控制受理装置10中，通过请求受理部11接收来自用户装置(用户网络2内的终端)的变更请求(用户请求、设定变更请求、设定信息)。在此接收到的一请求中包含通过图9那样的用户设定画面输入的一组内容。即，在变更内容涉及多个据点、多个设定(例如92的设定、93的设定、94的设定)时，在一请求消息中包含多个设定变更项目。相反，如果变更内容为单一据点的单一设定，则在一请求消息中包含的设定变更项目也为一个。
通过控制请求分类部20对每个设定变更项目调查成为控制对象的节点装置、接口，作为每个控制对象的请求进行分类。在控制完成之前，将分类结果一次性地记录在控制请求管理部21中。
图4表示控制请求管理部21的表构成例。
变更内容41是对对象节点以及对象接口(40)的每一个进行分类。此时，参照路径信息管理部17和对象列表管理部18，确定对象节点以及对象接口。
作为控制请求分类部20进行的处理顺序，将变更内容中包含的流识别信息(例如VPN-ID、发送源地址和发送目的地地址等)作为检索关键字，来调查路径信息管理部17，提取对象路径上的节点装置、接口(图10的步骤101)。然后，确认提取出的节点装置、接口是否已登录在对象列表管理部18中(图10的步骤102)。在与对象列表管理部18的信息进行核对的结果为一致时，将其作为与一致的节点装置·接口有关的变更内容，登录在控制请求管理部21中(图10的步骤103)。关于对象路径中包含的边缘节点5，因为作为位于通信业者网络的边界点的装置，成为设定变更的直接的对象，所以全部提取到控制请求管理部2中。当把与边缘节点有关的装置以及接口的信息也登录到对象列表管理部18中时，可以按照上述顺序的流程在管理部21中将控制请求进行分类。
然后，对图4所示的剩余的要素进行说明。差分栏(diff)42是登录在请求带宽中存在变更时的、变更前带宽和变更后带宽的差分的栏。虽然可以在进行后面的受理判定部22的处理时进行计算，但在变更内容栏41中登录信息的流程中，作为控制请求分类部20的处理来进行计算，在数据的读出等方面不会存在无用的工作。
请求ID栏(Req-Id)43是对各个变更请求本系统唯一设定的识别符。在向控制请求管理部21进行登录时，进行设定以便与其他的变更请求没有重复。但是在从同一变更请求派生出的变更请求中，对于对象节点以及接口不同的变更请求赋予相同的请求ID。
状态栏(Status)44是管理变更请求的处理状况的栏。通过控制请求分类部20对每个对象节点、对象接口分类各个变更请求，在已登录在控制请求管理部21中时，成为“未”的状态。以后，在受理判定部22进行变更请求的受理判定后的结果为可受理时，将登录内容变更为“OK”，在无法受理时将登录内容变更为“NG”。在针对同一请求ID的受理判定结果全部成为“OK”时，在由控制发布部23执行了针对节点装置的设定变更后，从控制请求管理表中删除。另一方面，关于即使一个受理判定结果成为“NG”的请求ID的变更请求，因为根据请求内容无法受理，所以经由请求受理部11向用户回复该主旨。
在图4的说明中进行了部分说明，现在再次返回图3继续进行说明。在通过控制请求分类部20在控制请求管理部21中进行了分类登录后，在受理判定部22中进行在控制请求管理部21中新登录的控制请求的受理判定。此时成为对象的是在图4所示的控制请求管理表的项目中状态栏44为“未”的变更请求。
作为本系统的特征性的判定顺序，不是单独地判定各个控制请求，而是汇总针对同一对象节点、同一对象接口的控制请求来进行判定。例如，虽然在图4中表示了已得出判定结果的状态，但如果针对节点#1和#2或#10和#11那样的同一对象节点、同一对象接口的控制请求的处理状态为“未”，则#1和#2、#10和#11分别汇总地进行判定。具体地说，进行是否可以全部应用向同一对象的多个控制请求的判定。如果为#1和#2的情况，则虽然各自的变更请求为增加7M带宽和减少2M带宽，但作为向控制对象的影响成为增加5M带宽，所以在路径上的控制对象节点、接口中，按照能否增加5M带宽的观点进行判定。在为#10和#11时也一样，在控制对象中按照能否增加15M带宽的观点进行判定。也有无法接受汇总后的请求内容的情况，此时，可以采用从在后累积的请求开始按顺序进行削减，再次进行判定的方法。此外，还可以采用以下的方法：如在检索处理中经常使用的2分查找法那样，通过反复执行以下的判定导出允许的边界点，该判定为：使用请求数量一半的内容进行一次判定，如果判定结果为可受理，则再加上剩余的请求数量再一半的内容进行判定，如果判定结果为不可受理，则通过再一半的请求数量的内容进行判定。在图4的#10和#11中，接受到#10为止的请求，示例了#11的请求没有被接受的案例。关于判定结果为不可受理的请求，将结果通知给终端1。此外，关于判定结果为可受理的请求，也可以同样地通知得出受理判定结果时的结果。
进行上述判定时的、控制对象中的既有的资源使用状况、极限值的信息，从资源管理部19取得。
在经由以上的顺序得出判定结果后，然后进行控制发布部23的处理。在控制发布部23中生成向控制对象的请求，通过控制执行部16执行控制。虽然成为对象的是受理判定的结果为“OK”的控制请求，但在此并非是对每个请求进行控制，而是通过对每个控制对象汇总的请求内容执行控制。例如，关于针对图4的#1和#2那样的同一节点的请求，将设定变更消息(控制请求)汇总为一个来执行控制。作为控制内容，进行VPN/标签/流单位的设定等。控制请求的接口标准取决于节点装置具备的接口，但也可以采用通过telnet等在对象节点中进行登录，然后发布命令的方法。还可以使用由IETF(the InternetEngineering Task Force)制定的NETCONF Configuration Protocol(RFC4741)。此时，是否可以使用1控制命令/1控制消息对节点装置进行针对同一节点/同一接口的多个控制请求，取决于对象节点所依据的接口标准。此外，上述的“通过对每个控制对象汇总的请求内容执行控制”是资源控制受理装置10的控制发布部23的处理。
最后，如果向作为对象的节点装置的控制完成，则在资源控制部19中反映结果，并且还对用户终端进行通知。
至此成为图3所示的资源控制受理装置10的一连串的处理的流程。在图3中，表示了控制请求分类部20、受理判定部22、控制发布部23全部安装在一台装置上的方式，但也可以采用以下的系统方式：划分安装请求受理部11和控制请求分类部20的装置、安装受理判定部22的装置、以及安装控制发布部23和控制执行部16的装置，各个装置一边与安装了控制请求管理部21的装置进行通信一边进行动作。
此外，图4是将焦点聚集在与带宽的设定变更相伴的控制请求管理的表构成例，在需要检查与优先度的设定变更相伴的、每个优先度的带宽分配的变动时，除了对象节点以及接口之外，在分类项目中加入优先度。即，在图4的项目40中加入优先度的条件来进行分类整理。同样地，图14所示的资源管理表也成为加入优先度的条件来进行分类整理的形式(例如在142和144之间追加列来进行分类。)
然后，使用流程图进一步说明在图3中说明的资源控制受理装置10的处理顺序。
图5是表示接收用户请求时的资源控制受理装置的处理顺序的流程图。
作为整个流程，如通过图3已说明的那样，进行通过请求受理部11取得用户请求的请求受理处理50，然后进行由判定控制部15进行的判定控制处理52。关于判定控制处理52，将使用图6在后面进行详细地说明。如果进行了判定控制处理52，则通过控制执行部16执行针对节点装置的控制54。
图6是表示判定控制部15的判定控制处理的流程图。
请求分类处理61相当于控制请求分类部20的处理，受理判定处理63相当于受理判定部22的处理。此外，控制发布处理65相当于控制发布部23的处理。如通过图3说明的那样，基本的流程为按顺序进行请求分类处理61、受理判定处理63、控制发布处理65的形式，在此，以处理期间的迁移的定时作为中心深入地进行说明。无论哪个处理在未处理的内容全部处理后，迁移到下一个处理。如果是请求分类处理61，则进行处理到没有未处理的请求为止，在没有了未处理的请求的时刻，迁移到下一个受理判定处理(步骤60)。在受理判定处理63中，如果没有未判定的处理则迁移到下一个控制发布部处理，如果存在未判定的处理(步骤62)，进行全部这些受理判定处理(步骤63)。同样，在控制发布处理65中，如果没有未控制的处理则再次迁移到请求分类处理，如果存在未控制的处理(步骤64)，则进行全部这些控制发布处理(步骤65)。
作为未处理的队列的实现方式，考虑图7的方式和图8的方式，然后，按照各个处理队列的结构说明图6的流程。
首先，说明采用图7的处理队列的结构的情况。
该模型为设置不依赖于处理的统一队列的方式，各处理在产生的时刻被累积在该队列中。在按照图7所示的例子的形式累积了各处理时，直到72的处理A₆结束为止，通过步骤60的未处理的请求确认判定为“有”，所以反复进行请求分类处理61。当请求分类结束时，各处理A₄～A₆成为新的受理判定等待处理B₄～B₆，这些成为在76之后按顺序累积的形式。当顺序轮到73的处理B₂时，不相当于步骤60的未处理的请求确认判定为“无”，而通过步骤62的未处理的判定确认判定为“有”，所以进行受理判定处理63。直到74的处理B₃结束为止，通过步骤62的未处理的判定确认判定为“有”，所以反复执行受理判定处理63。下一个75的处理A₇，不相当于步骤64的未处理的控制确认，所以再次返回步骤60，进行步骤61的请求分类处理。然后76的处理C₁，既不相当于步骤60也不相当于步骤62，所以迁移到步骤64进行步骤65的控制发布处理。此外，除了反复处理B2、B3之外，还可以汇总受理判定处理、控制发布处理来进行处理。
如上所述，在图7的模型中，按照在统一队列中累积的顺序进行处理，在同一处理连续的期间持续该处理。通过如此进行处理，例如从71到72的处理在请求分类处理结束后成为请求判定等待状态，再次相同地累积在统一队列中，所以，同时期连续产生的请求可按几乎相同的周期进行处理。顺便提一下，在队列中累积的处理的单位为请求ID43，但是以轮到顺序为契机进行处理的单位，在受理判定处理63和控制发布处理65中，是控制对象节点以及控制对象接口单位，所以在队列的处理顺序轮到之前，也可以对控制对象相同的处理一下子进行处理。
然后，说明采用图8那样的处理队列的结构的情况。
这些模型是对每个处理准备队列的方式，适合于例如通过多个CPU并行地执行请求分类处理61、受理判定处理63、控制发布处理65的情况等。更严格地说，作为以下的方式来应用，该方式为：在共有控制请求管理表21的情况下，通过排他控制对各处理进行分时，在处理之间的分配时间(顺序)79到来时，一并进行累积的同类的处理。例如，按每个预定的定时79，执行在各个队列中累积的处理。此外，如果在队列中聚集了预定的量，可以汇总然后执行处理。
使用流程图补充说明请求分类处理61、受理判定处理63、控制发布处理65。
图10表示请求分类处理61的流程图。因为在图4的说明中，作为控制请求分类部20进行的处理顺序，参照图10的符号叙述了请求分类处理，所以省略说明。
图11表示受理判定处理63的流程图。
在图3的后半部的说明中，作为受理判定部22的处理已经涉及到受理判定处理，在此，按照流程图的顺序进行说明。在受理判定处理中，以控制请求管理表的状态栏44为“未”的请求(处理状态为“未”的请求)为对象进行处理(步骤111)。在提取处理状态为“未”的请求时，以同一节点以及接口为单位进行提取(步骤112)。因为对控制请求管理表的请求按每个对象节点以及对象接口进行了分类(40)，所以按顺序进行检索即可。如果一并提取了针对同一节点以及接口的未处理请求，则核对资源管理部19的对应节点以及接口的信息，来判定是否允许将提取出的多个请求汇总后的请求内容(步骤113)。关于汇总后的请求内容的允许判定，因为已经在图3的后半部的受理判定部22的说明中进行了叙述，所以省略说明。在状态栏44中反映判定结果(步骤114)，然后转移到针对下一个节点以及接口的请求的判定(步骤115)。在此，可以既向状态栏44反映判定结果，同时还对用户终端进行通知。
本实施方式的网络控制系统在判定可否受理用户请求时，参照在节点装置中设定反映的实际资源信息，并且考虑在对重复的用户请求进行管理的队列中在先累积的请求内容来进行受理判定，所以即使不等到在队列中在先累积的请求向实际的节点装置的设定反映结束，也可进行受理判定，所以具有可以缩短针对用户请求的判定等待时间的优点。
图12表示控制发布处理65的流程图。
在图3的后半部的说明中，作为控制发行部23的处理涉及到控制发行处理，在此按照流程图的顺序来进行说明。在控制发行处理中，以控制请求管理表的状态栏44为“OK”的请求作为对象来进行处理(步骤121)。与受理判定处理相同，在此也以同一节点以及接口为单位进行提取(步骤122)。如果提取了针对同一节点以及接口的请求，汇总请求内容，发布针对对象节点的控制请求(步骤123)。从控制请求管理表中删除将控制请求交给了控制执行部16的已完成处理的请求(步骤124)。在此，可以再次向用户终端通知处理状态。如果针对控制请求管理表的状态栏44为“OK”的全部节点以及接口的处理完成(步骤125)，汇总在状态栏44中记载的判定结果为“NG”的请求进行删除(步骤126)。关于删除判定结果为“NG”的请求的定时，可以在受理判定处理的最后进行，也可以在控制发布处理的最初进行。
本实施方式的网络控制系统在进行针对节点装置的设定更新时，汇集用户请求中的通过受理判定被认可的多个请求内容来进行排序，所以即使在多个用户同时发布了关于同一节点装置的设定变更请求时，也能削减与节点装置的设定变更请求有关的负荷。
到此为止，作为多个用户同时进行设定变更时的对策方法，说明了本实施方式，从此开始说明：即使在管理多个连接据点的单一用户变更多个设定时，也可以应用本实施方式的结构，并且同样有效。
再次假设图1的据点30、31、32为同一企业的据点。例如，设最初仅在据点30和据点32之间开设了VPN线路时，还要在据点31和据点32之间新开设不同的VPN线路。此外，还使据点30和据点32之间的VPN线路的带宽同时增加。
此时，关于发送侧的据点30和31，虽然各自的变更请求可能收容于契约带宽的范围内，但还要考虑到据点32侧的状态来判断是否可以受理该请求。据点32成为来自据点30和据点31的不同的VPN通信量汇合的形式。在合计通信量远远超过据点32的契约带宽时，因为无法保证由该设定变更所要求的通信带宽，向用户传达根据请求内容无法受理。
如此，根据设定变更的结果，在产生多个通信量汇合的关键点时，资源控制受理装置10如下那样处理这些请求。由请求受理部11接收的请求中的一个请求成为对象，但如上所述，有可能在该一个请求中包含多个设定变更项目。在设定请求分析部20中，对每个设定变更项目调查成为控制对象的节点装置和接口，并对每个控制对象将请求进行分类，然后一次性记录到控制请求管理部21中。在此，所谓设定变更项目，例如是指新的VPN线路的开设、当前的VPN线路的带宽的增加量。
具体地说，将变更请求中包含的流识别符(例如，VPN-ID、发送源地址和发送目的地地址)作为检索关键字，来调查路径信息管理部17。在对象路径上的节点装置和接口中，特别是与边缘节点有关的信息始终成为对象，所以要连在发送目的地汇合的关键点有关的设定变更项目也不漏地进行提取。将这些信息在控制请求管理部21中，例如像图4的#1和#2那样进行分类整理。
在受理判定部22中，因为汇总针对同一对象节点、同一对象接口的控制请求来进行判断，所以还可以对多个通信量汇合的关键点，判定能否受理复合的设定变更。以后的处理相同。
本网络控制系统，例如对于向用户提供可以自由地进行与利用服务有关的设定变更的接口的通信业者的网络系统是有用的，特别是，适合于允许多个用户分别同时进行与网络设备有关的设定变更的网络系统。