通信系統以及伺服器裝置的製作方法

2023-05-28 05:09:01 2

專利名稱：通信系統以及伺服器裝置的製作方法
技術領域：
本發明涉及通信系統以及伺服器裝置，特別涉及在構成通信業者提供服務 的虛擬專用網絡的系統中，控制網絡資源的通信系統以及伺服器裝置。
背景技術：
作為將廣域IP網用作企業的通信基礎設施的機構，具有被稱為廣域以太
網(註冊商標)或IP-VPN ( Virtual Private Network)的由通信業者提供的服務。 在這些服務中，為以下的流程諸如據點的增加或VPN帶寬的變更這樣的來 自最終用戶的服務請求通過書面或者表單輸入等與服務提供業者進行聯絡，收 到請求的服務提供業者考慮網絡設備的資源利用狀況進行可否受理的判斷，進 行針對網絡設備的設定變更。
關於提供VPN的業者和提供構築VPN的廣域IP網的業者不同時的、來 自用戶的服務變更流程，例如在專利文獻l的圖1中進行了介紹。此時的來自 最終用戶的服務請求是以用戶側的VPN管理者進行中介的形式向廣域IP網管 理者進行申請的方式。在專利文獻l的技術中，作為削減從服務請求產生開始 到實際進行服務變更為止的時滯的機構，公開了將廣域IP網策略與VPN策略 一同進行存儲，進4亍針對廣域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中，敘述了通過設置多個用戶請求受理部，減輕用戶請求部 的處理負荷的方法，但沒有考慮多個用戶請求影響的傳輸裝置以及鏈路重複的 情況。雖然對於用戶請求的範圍跨越多個帶寬管理部的情況進行了記載，但採 用按照請求的順序一個一個地進行判定處理的方式。因此，在產生多個向某個 帶寬管理部的請求時，直到處理最後的請求為止需要花費時間，可能會喪失快 速反應性。
本發明鑑於以上的問題，其目的在於提供一種即使在多個用戶發布了設定 變更請求的情況下，抑制用戶的等待時間，同時一邊進行控制使通信業者網絡 中不會產生矛盾或者不匹配， 一邊進行網絡設備的設定變更的通信系統以及伺服器裝置。
本發明的特徵之一在於，在判定可否受理用戶請求時，並非只參照在節點 裝置中設定反映的實際資源信息，還考慮對重複的用戶請求進行管理的隊列中 先前累積的請求內容來進行受理判定。
並且，本發明的另一個特徵為在進行針對節點裝置的設定更新時，匯總
用戶請求中的通過受理判定被認可的多個請求內容來進行排序。
根據本發明的第一解決方法，提供一種通信系統，其具有構成在多個用 戶網絡之間進行連接的網絡，按照控制請求變更所述用戶網絡之間的邏輯線路 的設定信息的多個節點裝置；發送所述設定信息的終端；以及從所述終端接收 所述設定信息，向所述節點裝置發送控制請求的伺服器裝置，
所述終端具有輸入部，其輸入所述用戶網絡之間的邏輯線路的設定信息；
以及
發送部，其將所述設定信息發送給所述伺服器裝置， 所述伺服器裝置具有接收部，其從所述終端接收所述設定信息； 分類部，其對位於所述邏輯線路的路徑上的所述節點裝置以及該節點裝置
的接口的每一個，將所述接收部接收到的所述設定信息進行分類；
請求存儲部，其對所述節點裝置以及該節點裝置的接口的每一個，存儲由
所述分類部分類的所述設定信息；
資源存儲部，其存儲與所述節點裝置的各接口連接的物理線路的帶寬信
自
受理判定部，其對於各個節點裝置的接口，根據所述物理線路的帶寬信息
和所述邏輯線路的設定信息，判定可否受理設定信息；以及
控制發布部，其根據由所述受理判定部判定為可受理的所述邏輯線路的設 定信息，生成針對所述節點裝置的控制請求。
根據本發明的第二解決方法，提供一種下述通信系統中的伺服器裝置，該 通信系統具有構成在多個用戶網絡之間進行連接的網絡，按照控制請求變更 所述用戶網絡之間的邏輯線路的設定信息的多個節點裝置；發送所述設定信息 的終端；以及從所述終端接收所述設定信息，向所述節點裝置發送控制請求的 伺服器裝置，該伺服器裝置具有
接收部，其從所述終端接收所述用戶網絡之間的邏輯線路的所述設定信
自
分類部，其對位於所述邏輯線路的路徑上的所述節點裝置以及該節點裝置
的接口的每一個，將所述接收部接收到的所述設定信息進行分類；
請求存儲部，其對所述節點裝置以及該節點裝置的接口的每一個，存儲由
所述分類部分類的所述設定信息；
資源存儲部，其存儲與所述節點裝置的各接口連接的物理線路的帶寬信
息；
受理判定部，其對於各個節點裝置的接口，根據所述物理線路的帶寬信息 和所述邏輯線路的設定信息，判定可否受理設定信息；以及
控制發布部，其根據由所述受理判定部判定為可受理的所述邏輯線路的設 定信息，生成針對所述節點裝置的控制請求。
根據本發明，可以提供一種即使在多個用戶發布了設定變更請求的情況 下，抑制用戶的等待時間，同時一邊進行控制使通信業者網絡中不會產生矛盾 或者不匹配， 一邊進行網絡設備的設定變更的通信系統以及伺服器裝置。


圖l是表示本發明實施方式的一例的網絡結構圖。
圖2是說明按順序處理多個請求時的課題的流程圖。
圖3是資源控制受理程序的功能框圖。
圖4表示本實施方式的控制請求管理表的一構成例。
圖5是表示用戶請求接收時的資源控制受理裝置的處理順序的流程圖。
圖6是表示判定控制部的處理順序的流程圖。
圖7表示判定控制部的處理隊列的一構成例。
圖8表示判定控制部的處理隊列的另 一構成例。
圖9表示用戶請求的設定畫面的一例。
圖IO是表示請求分類處理的處理順序的流程圖。
圖11是表示受理判定處理的處理順序的流程圖。
圖12是表示控制發布處理的處理順序的流程圖。圖13表示對象列表管理表的一構成例。
圖14表示資源管理表的一構成例。
圖15表示路徑信息管理表的一構成例。
圖16表示契約信息管理表的一構成例。
圖17表示設定信息管理表的一構成例。
圖18是本實施方式的資源控制受理裝置的結構圖。
符號說明
l用戶終端、2用戶網絡、3用戶節點、4接入網、5邊緣節點、6核心節 點、7區;或網、8核心網、9管理用網絡、IO資源控制受理裝置、ll請求受理 部、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向資源控制受理裝置IO發布請求。終端1，例如具有輸 入據點(用戶網絡)之間的IP-VPN (邏輯線路)的設定信息的輸入部、以及 把設定信息發送給資源控制受理裝置10的發送部。
此時，關於用戶終端1和資源控制受理裝置IO之間的通信方式，可以通 過獨自的客戶應用程式和獨自的通信方式來進4亍，或者還可以通過在後面所示 的圖9那樣的從瀏覽器畫面的輸入形式以及使用了 HTTP/HTTPS的通信方式 來實現。在採用圖9所示的從瀏覽器畫面的輸入形式時，在管理用網絡9內還 需要Web伺服器，因為可以應用一般的Web伺服器/技術，所以在圖1中被省 略。此外，關於圖9，將在後面進行詳細地說明。轉回話題，使用圖l補充說 明多個用戶同時進行了設定變更時的課題。多個用戶的設定變更所產生的影響 的重點例如是來自多個用戶據點的通信量集中處於同 一線路。在上述樹結構的 網絡的終端中，雖然有可能在裝置上線路聚集多個用戶的通信量，但因為埠 /邏輯接口成為用戶專用，所以不會產生通信量處於同一線路的形式。但是，
在上遊的核心節點中，因為不可能以全部用戶各自的通信量為對象分配資源， 所以必然會成為通信量同處於同 一線路中的形式。 一般構築成越是上遊的網 絡，線路帶寬越大，^f旦全部的線路並不均一。例如，區域網1 (7a)和區域網 2(7b)之間、核心節點6c和核心節點6d之間等，有時變得比其他的核心網/ 區域網內的線路小。在這樣的線路中，某個用戶進行的設定變更會對其他用戶 的通信量造成影響。
作為一個例子，將圖l的據點30、 31、 32假設為同一企業的據點。各個 據點布置了用戶NW。該用戶企業的網絡管理者例如在4巴最初在據點30和31 之間設立的VPN線路變更為據點30和32之間時，通過本設定變更，在連接
1區域網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中表示了資源控制受理裝置IO的功能框圖，因為到 此為止的順序可應用一般的現有技術，所以在功能框圖中省略。可以將契約信 息DB和設定信息DB全部安裝在與資源控制受理裝置10不同的裝置中。此 時，與資源控制受理裝置IO相同，^:置在管理用網絡9內。
既有的設定的變更一邊參照變更前的信息， 一邊輸入(97 )或者選擇(98 ) 變更後的信息。在刪除既有的設定自身時，利用相應的設定附帶的刪除按^L 96,在新追加設定時，利用追加按鈕95。在按下了追加按4丑時，在通過對話 框催促輸入要追加的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是本實施方式的資源控制受理裝置IO的結構圖。
本實施方式的資源控制受理裝置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登錄管理節點裝置以及4妄口，該節點裝置 以及接口包含用戶的設定變更對其他用戶的通信量造成影響的關鍵點(線路)。 如圖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進行變更請求的受 理判定後的結果為可受理時，將登錄內容變更為"0K"，在無法受理時將登錄 內容變更為"NG"。在針對同一請求ID的受理判定結果全部成為"OK，，時， 在由控制發布部23執行了針對節點裝置的設定變更後，從控制請求管理表中 刪除。另一方面，關於即^f吏一個受理判定結果成為"NG"的請求ID的變更請 求，因為#4居請求內容無法受理，所以經由請求受理部11向用戶回復該主旨。
在圖4的說明中進行了部分i兌明，現在再次返回圖3繼續進行說明。在通 過控制請求分類部20在控制請求管理部21中進行了分類登錄後，在受理判定 部22中進行在控制請求管理部21中新登錄的控制請求的受理判定。此時成為 對象的是在圖4所示的控制請求管理表的項目中狀態欄44為"未"的變更請 求。作為本系統的特徵性的判定順序，不是單獨地判定各個控制請求，而是匯 總針對同一對象節點、同一對象接口的控制請求來進行判定。例如，雖然在圖 4中表示了已得出判定結果的狀態，但如果針對節點#1和#2或#10和#11那樣 的同一對象節點、同一對象接口的控制請求的處理狀態為"未"，則#1和#2、
#10和#11分別匯總地進行判定。具體地說，進4亍是否可以全部應用向同一對 象的多個控制請求的判定。如果為#1和#2的情況，則雖然各自的變更請求為 增加7M帶寬和減少2M帶寬，但作為向控制對象的影響成為增加5M帶寬， 所以在路徑上的控制對象節點、接口中，按照能否增加5M帶寬的觀點進行判 定。在為#10和#11時也一樣，在控制對象中按照能否增加15M帶寬的觀點進 行判定。也有無法接受匯總後的請求內容的情況，此時，可以採用從在後累積 的請求開始按順序進行削減，再次進行判定的方法。此外，還可以採用以下的 方法如在檢索處理中經常使用的2分查找法那樣，通過反覆執行以下的判定 導出允許的邊界點，該判定為使用請求數量一半的內容進行一次判定，如果 判定結果為可受理，則再加上剩餘的請求數量再一半的內容進行判定，如果判 定結果為不可受理，則通過再一半的請求數量的內容進行判定。在圖4的#10 和#11中，接受到#10為止的請求，示例了#11的請求沒有被接受的案例。關 於判定結果為不可受理的請求，將結果通知給終端l。此外，關於判定結果為 可受理的請求，也可以同樣地通知得出受理判定結果時的結果。
進行上述判定時的、控制對象中的既有的資源使用狀況、極限值的信息， 從資源管理部19取得。
在經由以上的順序得出判定結果後，然後進行控制發布部23的處理。在 控制發布部23中生成向控制對象的請求，通過控制執行部16執行控制。雖然 成為對象的是受理判定的結杲為"OK"的控制請求，但在此並非是對每個請 求進行控制，而是通過對每個控制對象匯總的請求內容執行控制。例如，關於 針對圖4的#1和#2那樣的同一節點的請求，將設定變更消息(控制請求)匯 總為一個來執行控制。作為控制內容，進行VPN/標籤/流單位的設定等。控制 請求的接口標準取決於節點裝置具備的接口 ，但也可以採用通過telnet等在對 象節點中進行登錄，然後發布命令的方法。還可以使用由正TF(the Internet Engineering 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的處 理A6結束為止，通過步驟60的未處理的請求確認判定為"有，，，所以反覆進 行請求分類處理61。當請求分類結束時，各處理A廣A6成為新的受理判定等 待處理B4 B6，這些成為在76之後按順序累積的形式。當順序輪到73的處理 B2時，不相當於步驟60的未處理的請求確認判定為"無"，而通過步驟62的 未處理的判定確認判定為"有"，所以進行受理判定處理63。直到74的處理 B3結束為止，通過步驟62的未處理的判定確認判定為"有"，所以反覆執行 受理判定處理63。下一個75的處理A7，不相當於步驟64的未處理的控制確 認，所以再次^^回步驟60，進行步驟61的請求分類處理。然後76的處理d， 既不相當於步驟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進行的處理順序，參照圖IO的符號敘述了請求分類處理，所以省 略說明。
圖11表示受理判定處理63的流程圖。
在圖3的後半部的說明中，作為受理判定部22的處理已經涉及到受理判 定處理，在此，按照流程圖的順序進行說明。在受理判定處理中，以控制請求 管理表的狀態欄44為"未"的請求(處理狀態為"未"的請求)為對象進行 處理(步驟111)。在^是耳又處理狀態為"未"的請求時，以同一節點以及接口 為單位進行提取(步驟112)。因為對控制請求管理表的請求按每個對象節點 以及對象接口進行了分類(40)，所以按順序進行檢索即可。如果一併提取了 針對同一節點以及"l妄口的未處理請求，則核對資源管理部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"的請求的定時，可以在受理 判定處理的最後進行，也可以在控制發布處理的最初進行。
本實施方式的網絡控制系統在進行針對節點裝置的設定更新時，匯集用戶 請求中的通過受理判定被認可的多個請求內容來進行排序，所以即使在多個用 戶同時發布了關於同一節點裝置的設定變更請求時，也能削減與節點裝置的設 定變更請求有關的負荷。
到此為止，作為多個用戶同時進行設定變更時的對策方法，說明了本實施 方式，〃t人此開始說明即使在管理多個連接據點的單一用戶變更多個設定時，
也可以應用本實施方式的結構，並且同樣有效。
再次假:沒圖l的據點30、 31、 32為同一企業的據點。例如，設最初僅在 據點30和據點32之間開設了 VPN線路時，還要在據點31和據點32之間新 開設不同的VPN線路。此外，還使據點30和據點32之間的VPN線路的帶寬 同時增力口。此時，關於發送側的據點30和31,雖然各自的變更請求可能收容於契約 帶寬的範圍內，但還要考慮到據點32側的狀態來判斷是否可以受理該請求。 據點32成為來自據點30和據點31的不同的VPN通信量匯合的形式。在合計 通信量遠遠超過據點32的契約帶寬時，因為無法保證由該設定變更所要求的 通信帶寬，向用戶傳達根據請求內容無法受理。
如此，根據設定變更的結果，在產生多個通信量匯合的關鍵點時，資源控 制受理裝置IO如下那樣處理這些請求。由請求受理部11接收的請求中的一個 請求成為對象，但如上所述，有可能在該一個請求中包含多個設定變更項目。 在設定請求分析部20中，對每個設定變更項目調查成為控制對象的節點裝置 和接口，並對每個控制對象將請求進行分類，然後一次性記錄到控制請求管理 部21中。在此，所謂i殳定變更項目，例如是指新的VPN線路的開設、當前的 VPN線路的帶寬的增加量。
具體地說，將變更請求中包含的流識別符(例如，VPN-ID、發送源地址 和發送目的地地址)作為檢索關鍵字，來調查路徑信息管理部17。在對象路 徑上的節點裝置和接口中，特別是與邊緣節點有關的信息始終成為對象，所以 要連在發送目的地匯合的關鍵點有關的設定變更項目也不漏地進行提取。將這 些信息在控制請求管理部21中，例如像圖4的#1和#2那樣進行分類整理。
在受理判定部22中，因為匯總針對同一對象節點、同一對象接口的控制 請求來進行判斷，所以還可以對多個通信量匯合的關鍵點，判定能否受理複合 的設定變更。以後的處理相同。
本網絡控制系統，例如對於向用戶提供可以自由地進行與利用服務有關的 設定變更的接口的通信業者的網絡系統是有用的，特別是，適合於允許多個用 戶分別同時進行與網絡設備有關的設定變更的網絡系統。
權利要求
1.一種通信系統，其具有構成在多個用戶網絡之間進行連接的網絡，按照控制請求變更所述用戶網絡之間的邏輯線路的設定信息的多個節點裝置；發送所述設定信息的終端；以及從所述終端接收所述設定信息，向所述節點裝置發送控制請求的伺服器裝置，其特徵在於，所述終端具有輸入部，其輸入所述用戶網絡之間的邏輯線路的設定信息；以及發送部，其將所述設定信息發送給所述伺服器裝置，所述伺服器裝置具有接收部，其從所述終端接收所述設定信息；分類部，其對位於所述邏輯線路的路徑上的所述節點裝置以及該節點裝置的接口的每一個，將所述接收部接收到的所述設定信息進行分類；請求存儲部，其對所述節點裝置以及該節點裝置的接口的每一個，存儲由所述分類部分類的所述設定信息；資源存儲部，其存儲與所述節點裝置的各接口連接的物理線路的帶寬信息；受理判定部，其對於各個節點裝置的接口，根據所述物理線路的帶寬信息和所述邏輯線路的設定信息，判定可否受理設定信息；以及控制發布部，其根據由所述受理判定部判定為可受理的所述邏輯線路的設定信息，生成針對所述節點裝置的控制請求。
2. 根據權利要求1所述的通信系統，其特徵在於，還具備路徑信息管理部，該路徑信息管理部對應所述邏輯線路的識別信 息，存儲位於該邏輯線路的路徑上的所述節點裝置的識別符以及該節點裝置的 接口的識別符，所述伺服器裝置的所述分類部具有下述單元根據所述設定信息中包含的邏輯線路的識別信息，參照所述^各徑信息管理 部，提取通信路徑上的所述節點裝置的識別符以及該節點裝置的接口的識別符 的單元；以及對提取出的所述節點裝置的識別符以及該節點裝置的接口的識別符的每 一個，將所述設定信息存儲在所述請求存儲部中的單元。
3. 根據權利要求2所述的通信系統，其特徵在於，還具備管理控制對象的所述節點裝置的識別符的對象列表管理部， 所述伺服器裝置的所述分類部，將提取出的所述節點裝置的識別符與所述對象列表管理部管理的控制對 象的所述節點裝置的識別符進行核對，在核對的結果一致時，對成為控制對象的所述節點裝置的識別符以及該節 點裝置的接口的識別符的每一個，將所述設定信息存儲在所述請求存儲部中。
4. 根據權利要求1所述的通信系統，其特徵在於，所述受理判定部匯總在所述請求存儲部中存儲的同 一節點裝置以及同一 接口的多個設定信息來進行可否受理判定，將判定結果存儲在所述請求存儲部中。
5. 根據權利要求4所述的通信系統，其特徵在於，所述受理判定部在可否受理的判定結果為否時，從後登錄的設定信息開始 依次刪除，反覆進行可否受理判定，將可受理的設定信息和不能受理的設定信 息進行分類，並將結果存^f諸在所述請求存儲部中。
6. 根據權利要求4所述的通信系統，其特徵在於，所述受理判定部在可否受理的判定結果為否時，釆用2分查找法將可受理 的設定信息和不能受理的設定信息進行分類，並將結果存儲在所述請求存儲部 中。
7. 根據權利要求1所述的通信系統，其特徵在於，所述控制發布部按照所述請求存儲部中存儲的同 一節點裝置以及同 一接 口的單位，匯總由所述受理判定部判定為可受理的"i殳定信息，生成向該節點裝 置的控制請求。
8. 根據權利要求1所述的通信系統，其特徵在於， 所述伺服器裝置的所述接收部接收多個設定信息， 當接收到設定信息時，在隊列中累積分類處理等待， 當執行了分類處理時，在所述隊列中累積受理判定處理等待，當執行了受理判定處理時，在所述隊列中累積控制發布處理等待， 所述受理判定部對於所述隊列中連續累積的關於多個設定信息的受理判 定處理等待進行匯總來判定可否受理，以及所述控制發布部對於在所述隊列中 連續累積的關於多個設定信息的控制發布處理等待進行匯總來生成控制請求。
9. 根據權利要求1所述的通信系統，其特徵在於， 所述伺服器裝置的所述接收部接收多個設定信息，在預定的每個定時，所述受理判定部對於多個設定信息進行匯總來判定可 否受理，以及所述控制發布部對於多個設定信息進行匯總來生成控制請求。
10. 根據權利要求1所述的通信系統，其特徵在於，所述設定信息包含所述邏輯線路的帶寬信息以及優先度中的某一個。
11. 根據權利要求1所述的通信系統，其特徵在於， 具備多個所述終端，所述伺服器裝置的所述接收部從多個所述終端接收多個設定信息。
12. —種伺服器裝置，其用於下述的通信系統中，該通信系統具有構成 在多個用戶網絡之間進行連接的網絡，按照控制請求變更所述用戶網絡之間的 邏輯線^^的設定信息的多個節點裝置；發送所述^:定信息的終端；以及從所述 終端接收所述設定信息，向所述節點裝置發送控制請求的伺服器裝置，其特徵 在於，具有接收部，其從所述終端接收所述用戶網絡之間的邏輯線路的所述設 定信息；分類部，其對位於所述邏輯線路的路徑上的所述節點裝置以及該節點裝置 的接口的每一個，將所述接收部接收到的所述設定信息進行分類；請求存儲部，其對所述節點裝置以及該節點裝置的接口的每一個，存儲由 所述分類部分類的所述設定信息；資源存儲部，其存儲與所述節點裝置的各接口連接的物理線路的帶寬信息；受理判定部，其對於各個節點裝置的接口，根據所述物理線路的帶寬信息 和所述邏輯線路的設定信息，判定可否受理設定信息；以及控制發布部，其根據由所述受理判定部判定為可受理的所述邏輯線路的設定信息，生成針對所述節點裝置的控制請求。
13. 根據權利要求12所述的伺服器裝置，其特徵在於，所述分類部具有下述單元參照與所述邏輯線路的識別信息對應地存儲有位於該邏輯線路的路徑上 的所述節點裝置的識別符以及該節點裝置的接口的識別符的路徑信息管理部， 根據所述設定信息中包含的邏輯線路的識別信息，提取通信路徑上的所述節點 裝置的識別符以及該節點裝置的接口的識別符的單元；以及對提取出的所述節點裝置的識別符以及該節點裝置的接口的識別符的每 一個，將所述設定信息存儲在所述請求存儲部中的單元。
14. 根據權利要求13所述的伺服器裝置，其特徵在於， 所述分類部將"l是取出的所述節點裝置的識別符與由管理控制對象的所述節點裝置的識別符的對象列表管理部管理的控制對象的所述節點裝置的識別 符進行核對，在核對的結果一致時，對成為控制對象的所述節點裝置的識別符以及該節 點的接口的識別符的每一個，將所述設定信息存儲在所述請求存儲部中。
15. 根據權利要求12所述的伺服器裝置，其特徵在於， 所述受理判定部匯總在所述請求存儲部中存儲的同一節點裝置以及同一接口的多個設定信息來進行可否受理判定，將判定結果存儲在所述請求存儲部 中。
16. 根據權利要求15所述的伺服器裝置，其特徵在於， 所述受理判定部在可否受理的判定結果為否時，從後登錄的設定信息開始依次刪除，反覆進行可否受理判定，將可受理的設定信息和不能受理的設定信 息進行分類，並將結果存儲在所述請求存儲部中。
17. 根據權利要求15所述的伺服器裝置，其特徵在於， 所述受理判定部在可否受理的判定結果為否時，採用2分查找法將可受理的設定信息和不能受理的設定信息進行分類，並將結果存儲在所述請求存儲部 中。
18. 根據權利要求12所述的伺服器裝置，其特徵在於， 所述控制發布部，按照所述請求存儲部中存儲的同一節點裝置以及同一接口的單位，匯總由所述受理判定部判定為可受理的設定信息，生成向該節點裝 置的控制請求。
19. 根據權利要求12所述的伺服器裝置，其特徵在於，所述接收部接收多個設定信息， 當接收到設定信息時，在隊列中累積分類處理等待， 當執行了分類處理時，在所述隊列中累積受理判定處理等待， 當執行了受理判定處理時，在所述隊列中累積控制發布處理等待， 所述受理判定部對於所述隊列中連續累積的關於多個設定信息的受理判 定處理等待進行匯總來判定可否受理，以及所述控制發布部對於在所述隊列中 連續累積的關於多個設定信息的控制發布處理等待進行匯總來生成控制請求。
20. 根據權利要求12所述的伺服器裝置，其特徵在於， 所述接收部接收多個設定信息，在預定的每個定時，所述受理判定部對於多個設定信息進行匯總來判定可 否受理，以及所述控制發布部對於多個設定信息進行匯總來生成控制請求。
全文摘要
本發明涉及通信系統以及伺服器裝置，其目的是，在提供可以將廣域IP網用作企業的通信基礎設施的服務的通信業者的網絡系統中，尤其是在開放用戶可以自由進行與利用服務有關的設定變更的設定接口的網絡系統中，多個用戶可以同時進行設定變更。在將來自用戶終端的設定變更請求進行分類的控制請求分類部(20)中，按每個控制對象節點以及接口將請求內容分類，並存儲在控制請求管理部(21)中。受理判定部(22)對每個控制對象匯總地判定可否受理請求。控制發布部(23)還在針對節點裝置的設定變更時，匯總被認可受理的針對同一節點的請求進行排序。
文檔編號H04L12/56GK101616073SQ20091000419
公開日2009年12月30日 申請日期2009年2月20日 優先權日2008年6月23日
發明者川合卓司, 湯本一磨 申請人:株式會社日立製作所