WO2016194089A1 - 通信ネットワーク、通信ネットワークの管理方法および管理システム - Google Patents

通信ネットワーク、通信ネットワークの管理方法および管理システム Download PDF

Info

Publication number
WO2016194089A1
WO2016194089A1 PCT/JP2015/065681 JP2015065681W WO2016194089A1 WO 2016194089 A1 WO2016194089 A1 WO 2016194089A1 JP 2015065681 W JP2015065681 W JP 2015065681W WO 2016194089 A1 WO2016194089 A1 WO 2016194089A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
communication
nms
path
communication path
Prior art date
Application number
PCT/JP2015/065681
Other languages
English (en)
French (fr)
Inventor
遠藤　英樹
大石　巧
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2017500088A priority Critical patent/JPWO2016194089A1/ja
Priority to PCT/JP2015/065681 priority patent/WO2016194089A1/ja
Priority to US15/507,954 priority patent/US20170310581A1/en
Publication of WO2016194089A1 publication Critical patent/WO2016194089A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity

Definitions

  • the present invention relates to a packet communication system, and more particularly to a communication system that accommodates a plurality of different services, and more particularly, to a packet communication system and a communication device capable of SLA guarantee.
  • the conventional communication network has been built independently for each communication service provided. This is because the quality required for each service differs, and the network construction and maintenance methods differ greatly from service to service. For example, in a communication service for business users represented by a dedicated line used for mission-critical operations such as national defense and finance, a guarantee of 100% communication bandwidth and a yearly operating rate of, for example, 99.99% or more Required.
  • the communication service provider provides a communication service by linking Service Level Agreement (SLA), which defines such communication quality (bandwidth, delay, etc.) guarantee and operation rate guarantee, with the user. If the SLA cannot be satisfied, the telecommunications carrier is required to reduce the fee or pay compensation, so the SLA guarantee is very important.
  • SLA Service Level Agreement
  • a conventional communication system employs a route calculation method, such as a Dijkstra algorithm, that sums the costs of links on a route and selects a route having a minimum or maximum value.
  • the communication band and the delay are converted into the cost of each link on the route and calculated.
  • the physical bandwidth of a link is expressed as the cost of the link, and the route that maximizes or minimizes the total cost of the links on the route is calculated.
  • a route that can accommodate more traffic is calculated.
  • this route calculation method only the total cost of the links on the route is considered, so if the cost of one link is extremely small or large, the link becomes a bottleneck and the traffic is delayed. Problems occur.
  • there is a Dijkstra improvement method that solves the problem by not only considering the total cost of the links on the route but also focusing on the cost of each link on the route (Patent Literature). 1). By using this method, it is possible to avoid a bottleneck and search for a path capable of guaranteeing an SLA.
  • the leased line service that includes the operation rate in the SLA has an Operation Administration and Maintenance (OAM) tool in which all communication devices detect communication path failures. Automatically switches to the prepared alternative route.
  • OAM Operation Administration and Maintenance
  • a connection verification OAM tool such as a loopback test for the route in which the failure occurred, identify the physical failure location, and perform maintenance work such as component replacement.
  • VPN Virtual Private Network
  • MPLS Multiprotocol Label Switching
  • each service and its users are accommodated in the network as logical paths.
  • Ethernet registered trademark
  • MPLS MPLS network path
  • the MPLS path is a route in the MPLS network specified by the path ID, and a packet arriving at the MPLS device from the Ethernet is encapsulated with an MPLS label including this path ID, and then is sent to this route in the MPLS network. Transferred along. For this reason, the path in the MPLS network is uniquely determined depending on which path ID is assigned to each user or service, and multiple services are multiplexed by accommodating multiple logical paths on the physical line. Is possible. This virtual network for each service is called a virtual network.
  • Non-Patent Document 1 an OAM tool that improves maintainability is defined, and a failure occurrence is detected at high speed for each logical path by an OAM tool (Non-Patent Document 1) that periodically transmits and receives OAM packets at the start and end points of a logical path.
  • the failure detected at the start point and end point of the logical path is notified from the communication device to the operator via the network management system.
  • the operator performs a loopback test OAM tool (Non-patent Document 2) that transmits a loopback OAM packet to a relay point on the logical path in order to identify the fault location on the logical path where the fault has occurred.
  • the physical failure location is identified from the failure locations on the logical path, so that maintenance work such as component effects can be performed.
  • the conventional communication system can guarantee the operation rate by the OAM tool, only the communication quality such as the bandwidth and the delay has been considered when calculating the route.
  • IETF RFC6428 Proactive Connectivity er Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
  • IETF RFC6426 MPLS On-Demand on Connectivity Verification and Route Tracing
  • Logical paths are set in a distributed manner throughout the virtual network.
  • a packet communication system includes a plurality of communication devices and a management system thereof, and transfers packets between the plurality of communication devices via a communication path set from the management system. It is a communication system.
  • the management system sets communication paths, to improve maintainability, the paths that share the same route even in a part of the network are aggregated, and the route is used to efficiently accommodate traffic.
  • a plurality of path setting policies such as those distributed throughout the network are changed according to the service.
  • a service that aggregates paths is a service that secures a certain bandwidth for each user or service, and is aggregated on the same route. If the total sum of the bandwidths of the selected services exceeds one of the line bandwidths on the path, a search is made for other routes where the sum of the bandwidths of the services aggregated on the same route does not exceed any of the line bandwidths on the path. Is set.
  • the service for distributing paths distributes the paths according to the remaining bandwidth obtained by subtracting the bandwidth reserved for the service that aggregates the paths from each line bandwidth on the route.
  • the packet communication system of the present invention has an automatic management system when a path is changed according to a request from a connected external system such as a user on the Internet or a data center. Apply path setting policy.
  • the communication apparatus of the packet communication system of the present invention preferentially manages a path failure related to a service that requires a guarantee of an operation rate when a failure of a plurality of paths is detected.
  • the management system preferentially processes a failure notification of a service that requires a guarantee of an operation rate, automatically executes a return test, or prompts an operator to execute the return test.
  • Another aspect of the present invention includes a communication network management method including a communication network including a plurality of communication devices and a management system, and transferring packets between the plurality of communication devices via a communication path set from the management system. It is.
  • a management system sets communication paths, a first service that aggregates communication paths that share the same route even in a part of the communication network for the first service that requires guarantee of the operation rate.
  • the second service that does not guarantee the setting policy and the operation rate, it has a second setting policy for setting the communication path so that the route to be used is distributed over the entire communication network. The setting policy is changed.
  • Still another aspect of the present invention provides a communication path for a first service that guarantees a bandwidth to a user for a plurality of communication devices constituting a communication network, and a first that does not guarantee a bandwidth to a user.
  • 2 is a communication network management system in which communication paths for two services are set and communication paths for the first and second services coexist in the communication network.
  • this communication network management system sets a new communication path in a route selected from routes that have free bandwidth corresponding to the guaranteed bandwidth.
  • the new setting is applied to the route selected based on the free bandwidth per user of the second service.
  • the second setting policy for setting the communication path is applied.
  • the first setting policy selects a route with the smallest free area from a route having a free bandwidth corresponding to the guaranteed bandwidth, and sets a new communication path.
  • the second setting policy selects a route having the largest available bandwidth per user of the second service, and sets a new communication path. According to such a policy, the communication path for the first service is set to share the route as much as possible, and the communication path for the second service is as uniform in the available bandwidth between users as possible. Is set to be
  • Still another aspect of the present invention is a communication network having a plurality of communication devices constituting a route and a management system for setting communication paths to be used by a user for the plurality of communication devices.
  • the management system sets a communication path for the first service and a communication path for the second service with different SLA for use by the user. Then, when setting the communication path used for the first service, the communication path used for the first service is set to be aggregated to a specific route on the network, and the communication path used for the second service is set. In the case of setting, the communication path used for the second service is set to be distributed over the route on the network.
  • the first service is a service whose operating rate and bandwidth are guaranteed, and a plurality of communication paths used for a plurality of users provided with the first service.
  • the plurality of communication paths are set in the same route.
  • the second service is a best-effort service, and the allocation per user of the second service is evenly allocated in the free bandwidth excluding the communication bandwidth used by the communication path used for the first service. As described above, a communication path used for the second service is set.
  • FIG. 3 is a table showing an example of a path construction policy table provided in the network management system of FIG. 2.
  • FIG. 3 is a table showing an example of a user management table provided in the network management system of FIG. 2.
  • FIG. 3 is a table showing an example of a connection destination management table provided in the network management system of FIG. 2.
  • FIG. 3 is a table showing an example of a path configuration table provided in the network management system of FIG. 2.
  • FIG. 3 is a table showing an example of a link management table provided in the network management system of FIG. 2.
  • FIG. 12 is a table showing an example of a connection ID determination table provided in the network interface board (10-n) of FIG.
  • FIG. 12 is a table showing an example of an input header processing table provided in the network interface board (10-n) of FIG.
  • FIG. 12 is a table showing an example of an input header processing table provided in the network interface board (10-n) of FIG.
  • FIG. 12 is a table showing an example of a label setting table provided in the network interface board (10-n) of FIG.
  • FIG. 12 is a table showing an example of a bandwidth monitoring table provided in the network interface board (10-n) of FIG.
  • FIG. 12 is a table showing an example of a packet transfer table provided in the switch unit 11 of FIG. 11.
  • 12 is a flowchart showing an example of input packet processing S100 executed by the input packet processing unit 103 in FIG.
  • FIG. 12 is a table showing an example of a failure management table provided in the network interface board (10-n) of FIG.
  • the sequence diagram which shows an example of network setting sequence SQ100 from the operator which the communication system of an Example performs.
  • FIG. 4 is a flowchart of an example of a path search process S200 corresponding to a service executed by the network management system of FIG. 2;
  • FIG. 3 is a continuation of a flowchart of an example of a path search process S200 corresponding to a service executed by the network management system of FIG. 12 is a flowchart of an example of a failure management polling process S300 executed by the network interface board (10-n) of FIG.
  • FIG. 12 is a flowchart of failure notification queue read processing S400 executed by the device management unit 12 of FIG.
  • notations such as “first”, “second”, and “third” are attached to identify the constituent elements, and do not necessarily limit the number or order.
  • a number for identifying a component is used for each context, and a number used in one context does not necessarily indicate the same configuration in another context. Further, it does not preclude that a component identified by a certain number also functions as a component identified by another number.
  • FIG. 1 shows an example of a communication system of the present invention.
  • This system is a communication system that includes a plurality of communication devices and their management systems, and transfers packets between the plurality of communication devices via a communication path set from the management system.
  • the management system sets the communication path, it is a service that requires guarantee of the operation rate, so that the paths that share the same route even in part of the network are aggregated for the purpose of quickly identifying the failure location.
  • multiple paths can be set up, such as a route that is distributed over the entire network for the purpose of accumulating traffic fairly for a large number of users.
  • the policy can be changed according to the service.
  • the communication devices ND # 1 to n of the present embodiment constitute a network NW of a communication carrier that connects between the access devices AE1 to n that accommodate the user terminals TE1 to n and the data center DC or the Internet IN.
  • the device configurations of the edge device and the relay device may be the same, and operate as an edge device according to a preset or input packet and operate as a relay device.
  • the communication devices ND # 1 and ND # n operate as edge devices
  • the communication devices ND # 2, ND # 3, ND # 4, and ND # 5 operate as relay devices for convenience from the position of the network NW. To do.
  • the communication devices ND # 1 to ND # n are connected to the network management system NMS via the management network MNW.
  • the Internet IN in which a server for processing a request from the user is installed, and the data center DC possessed by the application provider are also included. It is connected to the management network MNW.
  • Each logical path is set by the network management system NMS (described later in SQ100 of FIG. 20).
  • the paths PTH # 1 and PTH # 2 are set to pass through the relay apparatuses ND # 2 and ND # 3
  • the path PTH # n is set to pass through the relay apparatuses ND # 4 and ND # 5, both of which are edges. This is a path between the device ND # 1 and the edge device ND # n.
  • the path PTH # 1 is a path for which the bandwidth for the communication service for business users is guaranteed, and therefore the network management system NMS assigns 500 Mbps to the path PTH # 1.
  • the business users using the user terminals TE1 and TE2 each have a contract for a communication service of 250 Mbps, so that the integrated value 500 Mbps is secured for the path PTH # 1 in which the users are accommodated.
  • the paths PTH # 2 and PTH # n used by the user terminals TE3, TE4, and TEn for general users are intended for general consumer communication services and are operated at best effort. Only the connectivity between the devices ND # 1 and ND # n is ensured.
  • the communication path for business users and the communication path for individual users, which have different SLA guarantee levels, are allowed to use the same communication device as a route.
  • Such path setting and change are performed by an operator OP, who is usually a network administrator, giving instructions to the network management system NMS via the monitoring terminal MT.
  • operator OP who is usually a network administrator, giving instructions to the network management system NMS via the monitoring terminal MT.
  • NMS network management system
  • current telecommunications carriers are trying to obtain new revenues by providing an optimal network in response to requests from users and application providers, and from the Internet IN and data center DC as well as operators. Then, instructions for setting and changing the path arrive.
  • FIG. 2 shows an example of the configuration of the network management system NMS.
  • the network management system NMS is usually realized by a general-purpose server, its configuration is the Micro Processing Unit (MPU) NMS-mpu that executes the program, and information necessary for installing the program and processing the program Signals of Hard Disk Drive (HDD) NMS-hdd, MPU: NMS-mpu for temporarily storing these information, and monitoring terminal MT operated by operator OP And an input unit NMS-in, an output unit NMS-out, and a Network Interface Card (NIC) NMS-nic connected to the management network MNW.
  • MPU Micro Processing Unit
  • HDD Hard Disk Drive
  • NIC Network Interface Card
  • the HDD: NMS-hdd includes, as information necessary for managing the network NW in this embodiment, a path construction table NMS-t1, a user management table NMS-t2, and a connection destination management table NMS-t3.
  • the path configuration table NMS-t4 and the link management table NMS-t5 are stored. These pieces of information are input and changed by the operator OP, and are changed in response to changes in the state of the network NW and requests from users and application providers.
  • FIG. 3 shows an example of the path construction policy NMS-t1.
  • the path construction policy NMS-t1 uses the SLA type NMS-t11 as a search key to retrieve a table entry indicating the communication quality NMS-t12, the operation rate guarantee NMS-t13, and the path construction policy NMS-t14. belongs to.
  • the SLA type NMS-t11 indicates a communication service for business users and a communication service for general consumers.
  • a method of guaranteeing the communication quality NMS-t12 (bandwidth guarantee or fairness) Use), presence / absence of operation rate guarantee NMS-t13, its reference value, and path construction policy NMS-t14 such as aggregation and distribution can be searched.
  • the communication service for business users is referred to as a guaranteed service
  • the communication service for general consumers is referred to as a fair service. Details of how to use this table will be described later.
  • FIG. 4 shows an example of the user management table NMS-t2.
  • the user management table NMS-t2 uses the user ID: NMS-t21 as a search key, the SLA type NMS-t22, the accommodation path ID: NMS-t23, the contracted bandwidth NMS-t24, and the connection destination NMS-t25. This is for searching for a table entry indicating.
  • the user ID: NMS-t21 identifies each service terminal TEn connected via the user access device AEn.
  • the SLA type NMS-t22 or the user terminal It is possible to search the accommodation path ID of TEn: NMS-t23, the contract bandwidth NMS-t24 assigned to each user terminal TEn, and the connection destination NMS-t25 of the user terminal TEn.
  • the accommodation path ID: NMS-t23 any one of the path IDs: NMS-t41, which is a search key of the path configuration table NMS-t4 described later, is set as a path for accommodating the user. Details of how to use this table will be described later.
  • FIG. 5 shows an example of the connection destination management table NMS-t3.
  • the connection destination management table NMS-t3 indicates the accommodation device ID: NMS-t33 and the accommodation port ID: NMS-t34 using the combination of the connection destination NMS-t31 and the connection port ID: NMS-t32 as a search key. This is for retrieving table entries.
  • connection destination NMS-t31 and the connection port ID: NMS-t32 indicate points that are traffic transmission / reception sources for the network NW, and the accommodation device ID: NMS-t33, which is the point of the network NW in which they are accommodated. And the accommodation port ID: NMS-t34 can be searched. Details of how to use this table will be described later.
  • FIG. 6 shows the path configuration table NMS-t4.
  • the path configuration table NMS-t4 uses the path ID: NMS-t41 as a search key, the SLA type NMS-t42, the terminating device ID: NMS-t43, the transit device ID: NMS-t44, and the transit link ID: This is for retrieving table entries indicating the NMS-t45, the LSP label NMS-t46, the allocated bandwidth NMS-t47, and the accommodated user NMS-t48.
  • the path ID: NMS-t41 uniformly identifies the path in the network NW. Unlike the LSP label that is actually assigned to the packet, the path ID: NMS-t41 is the same in both communications. Value.
  • NMS-t41 there is an SLA type NMS-t42, a terminal device ID: NMS-t43 of the path, a relay device ID: NMS-t44, a relay link ID: NMS-t45, and an LSP label NMS-t46. Is set.
  • the integrated value of the contracted bandwidths of all users described in the accommodated user NMS-t48 is the allocated bandwidth NMS. -T47 is set.
  • the LSP label NMS-t46 is an LSP label that is actually given to the packet, and a different value is set for each direction of communication. In general, it is possible to set a different LSP label every time the communication device ND # n is relayed. However, in this embodiment, for simplicity, the LSP label is not changed every time the relay is performed, and the network edge device is used. It is assumed that the same LSP label is used. Details of how to use this table will be described later.
  • FIG. 7 shows the link management table NMS-t5.
  • the link management table NMS-t5 is for searching for a table entry indicating the free bandwidth NMS-t52 and the number of transparent non-priority users NMS-t53 using the link ID: NMS-t51 as a search key.
  • the link ID: NMS-t51 indicates a connection relationship between the ports of each communication device, and is a combination of the ID of the communication device ND # n at both ends of each link and its port ID.
  • the link ID: NMS-t51 is “LNK # N1- 2-N3-4 ".
  • paths configured by the same link ID that is, paths having the same combination of transmission port and destination port are paths of the same route.
  • NMS-t51 For each link ID: NMS-t51, a value obtained by subtracting the sum of the contracted bandwidths of the paths passing through the link from the physical bandwidth of the link is held as a free bandwidth: NMS-t52, and is a fair type that passes through the link
  • NMS-t52 The number of users on the service path is held as the transparent non-priority user number NMS-t53 and can be searched. Details of how to use this table will be described later.
  • FIG. 8 shows the format of the communication packet 40 received by the edge devices ND # 1 and ND # n from the access devices AE # 1 to AE #, the data center DC and the Internet IN in this embodiment.
  • the communication packet 40 includes a MAC header including a destination MAC address 401, a transmission source MAC address 402, a VLAN tag 403, a type value 404 indicating the type of the subsequent header, a payload portion 405, and a packet check sequence (FCS) 406. .
  • a MAC header including a destination MAC address 401, a transmission source MAC address 402, a VLAN tag 403, a type value 404 indicating the type of the subsequent header, a payload portion 405, and a packet check sequence (FCS) 406.
  • the VLAN tag 403 stores a VLAN ID value (VID #) serving as a flow identifier and a CoS value indicating priority.
  • FIG. 9 shows a format of a communication packet 41 transmitted and received by each communication device ND # n within the network NW.
  • PW Psudo Wire
  • the communication packet 41 includes a MAC header composed of a destination MAC address 411, a source MAC address 412, a type value 413 indicating the type of the subsequent header, an MPLS label (LSP label) 414-1, and an MPLS label (PW label) 414. 2, payload portion 415, and FCS: 416.
  • the MPLS labels 414-1 and 414-2 store a label value serving as a path identifier and a TC value indicating priority.
  • the Ethernet packet of the communication packet 40 shown in FIG. 4 is encapsulated and a case where information regarding the OAM generated by each communication device ND # n is stored.
  • This format has two levels of MPLS labels, and the first level MPLS label (LSP label) 414-1 is an identifier for specifying a path in the network NW, and the second level MPLS label (PW label). 414-2 is used to identify a user or an OAM packet.
  • LSP label first level MPLS label
  • PW label second level MPLS label
  • 414-2 is used to identify a user or an OAM packet.
  • the label value of the MPLS label 414-2 in the second stage has a reserved value “13” or the like, it is an OAM packet, otherwise it is a user packet (the Ethernet packet of the communication packet 40 is stored in the payload 415). Encapsulated).
  • FIG. 10 shows a format of the OAM packet 42 transmitted / received in the network NW by the communication device ND # n.
  • the OAM packet 42 includes a MAC header including a destination MAC address 421, a source MAC address 422, a type value 423 indicating the type of the subsequent header, and a first-stage MPLS label (LSP label) 414-1 similar to the communication packet 41. And the second-stage MPLS label (OAM label) 414-3, the OAM type 424, the payload 425, and the FCS 426.
  • LSP label first-stage MPLS label
  • the second-stage MPLS label (OAM label) 414-3 has “13” or the like in which the label value of the second-stage MPLS label (PW label) 414-2 in FIG. 9 is a reserved value.
  • the OAM type 424 is an identifier indicating the type of the OAM packet, and in this embodiment, the identifier of the failure monitoring packet or the loopback test packet (loopback request packet or loopback response packet) is stored.
  • the payload 425 stores information dedicated to OAM.
  • the termination device ID is stored in the case of a failure monitoring packet
  • the return device ID is stored in a return request packet
  • the end device ID is stored in a return response packet. Is done.
  • FIG. 11 shows the configuration of the communication device ND # n.
  • the communication device ND # n includes a plurality of network interface boards (NIF) 10 (10-1 to 10-n), a switch unit 11 connected to these NIFs, and a device management unit 12 that manages the entire device.
  • NIF network interface boards
  • Each NIF 10 includes a plurality of input / output line interfaces 101 (101-1 to 101-n) serving as communication ports, and is connected to other devices via these communication ports.
  • the input / output line interface 101 is a line interface for Ethernet.
  • the input / output line interface 101 is not limited to an Ethernet line interface.
  • Each NIF: 10-n includes an input packet processing unit 103 connected to these input / output line interfaces 101, a plurality of SW interfaces 102 (102-1 to 102-n) connected to the switch unit 11, and these Output packet processing unit 104 connected to the SW interface, a failure management unit 107 that performs OAM-related processing, an NIF management unit 105 that manages NIF, and a setting register 106 that holds various settings.
  • the SW interface 102-i corresponds to the input / output line interface 101-i
  • the input packet received by the input / output line interface 101-i is transferred to the switch unit 11 via the SW interface 102-i. Is done.
  • the output packet distributed from the switch unit 11 to the SW interface 102-i is sent to the output line via the input / output line interface 101-i.
  • the input packet processing unit 103 and the output packet processing unit 104 have an independent structure for each line, and packets of each line do not mix.
  • the input / output line interface 101-i When the input / output line interface 101-i receives the communication packet 40 or 41 from the input line, it adds the in-device header 45 shown in FIG. 12 to the received packet.
  • FIG. 12 shows an example of the in-device header 45.
  • the in-device header 45 includes a plurality of fields indicating a connection ID: 451, a reception port ID: 452, a priority 453, and a packet length 454.
  • the ID of the port acquired from the setting register 106 is stored in the received port ID: 452, and the length of this packet is stored. Are stored as packet length 454.
  • the connection ID: 451 and the priority 453 are blank. An effective value is set in this field by the input packet processing unit 103.
  • the input packet processing unit 103 performs input packet processing S100 described later, refers to the following tables 21 to 24, and adds the connection ID: 451 and the priority 453 to the in-device header 45 of each input packet. In addition, other header processing, bandwidth monitoring processing, and the like are performed. As a result of the input packet processing S100, the input packet is distributed and transferred to the SW IF: 102 for each line.
  • FIG. 13 shows the connection ID determination table 21.
  • the connection ID determination table 21 uses the combination of the input port ID: 212 and the VLAN ID: 213 as a search key to acquire the connection ID: 211 that is the registered address.
  • a table is composed of a CAM (Content-addressable memory).
  • the connection ID: 211 is an ID that identifies each connection in the communication apparatus ND # n, and uses the same ID in both directions. Details of how to use this table will be described later.
  • FIG. 14 shows the input header processing table 22.
  • the input header processing table 22 is used to search for a table entry indicating the VLAN tag processing 222 and the VLAN tag 223 using the connection ID: 221 as a search key.
  • the VLAN tag processing 222 designates VLAN tag processing for an input packet, and tag information necessary for the VLAN tag processing is set in the VLAN tag 223. Details of how to use this table will be described later.
  • FIG. 15 shows the label setting table 23.
  • the label setting table 23 is used to search a table entry indicating the LSP label 232 and the PW label 233 using the connection ID: 231 as a search key. Details of how to use this table will be described later.
  • FIG. 16 shows the bandwidth monitoring table 24.
  • the bandwidth monitoring table 24 is used for retrieving a table entry indicating the contract bandwidth 242, the bucket depth 243, the previous token value 244, and the previous time 245 using the connection ID: 241 as a search key. It is.
  • the contract bandwidth 242 is set to the same value as the contract bandwidth for each user, and a packet within the contract bandwidth is set to the priority 453 of the in-device header 45 by a general token bucket algorithm. Packets for which priority has been overwritten and it is determined that the contracted bandwidth has been exceeded are discarded. On the other hand, in the case of a fair service, an invalid value is set in the contract bandwidth 242 and the low priority is overwritten on the priority 453 of the in-device header 45 of all packets.
  • the switch unit 11 receives input packets from the SW interfaces 102-1 to 102-n of each NIF, specifies the output port ID and output label from the packet transfer table 26, and sends them to the corresponding SW interface 102-i as output packets. Forward. At this time, according to the TC indicating the priority of the MPLS label 414-1, a packet having a high priority is preferentially transferred during congestion. Further, the output label 276 is overwritten on the assigned MPLS label (LSP label) 414-1.
  • FIG. 17 shows the packet transfer table 26.
  • the packet forwarding table 26 is used to search for a table entry indicating the output port ID: 263 and the output LSP label 264 using the combination of the input port ID: 261 and the input LSP label 262 as a search key.
  • the switch unit 11 searches the packet forwarding table 26 using the reception port ID: 451 of the in-device header 45 and the LSP ID of the MPLS label (LSP label) 414-1 of the input packet, and determines the output destination.
  • the output packets received by each SW interface 102 are supplied to the output packet processing unit 104 one after another.
  • the output packet processing unit 104 When the NIF: 10-n processing mode is set to the Ethernet processing mode in the setting register 106, the output packet processing unit 104 outputs the destination MAC address 411, the source MAC address 412 of the output packet, and the type The value 413, the MPLS label (LSP label) 414-1, and the MPLS label (PW label) 414-2 are deleted, and the packet is output to the corresponding input / output line interface 101-i.
  • the processing mode of the NIF: 10-n is set to the MPLS processing mode in the setting register 106, the packet is output to the corresponding input / output line interface 101-i without performing packet processing.
  • FIG. 18 shows a flowchart of the input packet processing S100 executed by the input packet processing unit 103 of the communication device ND # n. Such processing can be executed by the communication device ND # n having hardware resources such as a microcomputer and using the hardware resources by information processing by software.
  • the input packet processing unit 103 determines the processing mode of the NIF: 10-n set in the setting register 106 (S101).
  • each piece of information is extracted from the in-device header 45 and the VLAN tag 403, and the connection ID determination table 21 is searched using the extracted reception port ID: 452 and VID.
  • the packet connection ID: 211 is specified (S102).
  • connection ID: 211 is written in the in-device header: 45, the input header processing table 22 and the label setting table 23 are searched, and the entry content is acquired (S103).
  • VLAN tag 403 is edited according to the contents of the input header processing table 22 (S104).
  • bandwidth monitoring processing is performed for each connection ID: 211 (here, a user), and the priority 453 of the in-device header (FIG. 12, 45) is added (S105).
  • the destination MAC address 411 and the source MAC address 412 are set in the setting register 106, the type value 413 is “8847” (hexadecimal) indicating MPLS, and the MPLS label (LSP).
  • Label) 414-1 is assigned LSP label 232 of label setting table 23
  • MPLS label (PW label) 414-2 is assigned label value PW label 233 of label setting table 23
  • priority 453 of in-device header 45 is assigned TC. .
  • the MPLS processing mode is set in S101, it is determined whether or not the second-stage MPLS label 414-2 is a reserved value (“13”) in the communication packet 41 (S107). If it is not a reserved value, the packet is transferred as it is as a user packet (S108), and the process is terminated (S111).
  • FIG. 19 shows the failure management table 25.
  • the failure management table 25 uses the path ID: 251 as a search key, the SLA type 252, the terminating device ID: 253, the transit device ID: 254, the transit link ID: 255, the LSP label value 256, the failure This is for searching a table entry indicating occurrence / non-occurrence 257.
  • the path ID: 251, the SLA type 252, the terminating device ID: 253, the transit device ID: 254, the transit link ID: 255, and the LSP label value 256 are the path ID: NMS-t 41 of the path configuration table NMS-t 4, This is the same as the SLA type NMS-t42, termination device ID: NMS-t43, transit device ID: NMS-t44, transit link ID: NMS-t45, and LSP label value NMS-t46.
  • Failure occurrence presence / absence 257 is information indicating whether or not a failure has occurred in the path.
  • the NIF management unit 105 reads the failure by a failure management table polling process described later, and determines the priority according to the SLA type 252. To the device management unit 12.
  • the device management unit 12 determines the priority according to the SLA type 252 in the entire device through the failure notification queue read processing S400, and finally notifies the network management system NMS. Details of how to use this table will be described later.
  • the failure management unit 107 periodically transmits a failure monitoring packet to the path 251 added to the failure management table 25.
  • the LSP label value 414-1 is an LSP label value 256
  • the OAM type 424 is an identifier indicating the fault monitoring packet
  • the payload 425 is a terminating terminal ID: ND # n
  • other areas are the setting registers 106 Is stored (see FIG. 10).
  • the failure management unit 107 overwrites “present” as a failure occurrence in the failure occurrence presence / absence 256 of the failure management table 25 when a failure monitoring packet does not arrive on the path for a certain period.
  • the failure management unit 107 When the failure management unit 107 receives the OAM packet addressed to itself from the input packet processing unit 103, the failure management unit 107 checks the OAM type 424 of the payload 425 and determines whether the packet is a failure monitoring packet or a loopback test packet (loopback request packet or loopback response). If the packet is a failure monitoring packet, “None” is overwritten as failure recovery in the failure occurrence presence / absence 256 of the failure management table 25.
  • the failure management unit 107 Since the failure management unit 107 performs a loopback test on a path specified by the network management system in a loopback test described later, a test target specified by the network management system as described later as the LSP label 414-1 Path ID: LMS label 256 of NMS-t41, identifier indicating that this packet is a return request packet in OAM type 424, transit device ID to be returned in payload 425: NMS-t44, setting register in other areas A return request packet is generated using the set value of 106 and transmitted.
  • LSP label 414-1 Path ID LMS label 256 of NMS-t41
  • identifier indicating that this packet is a return request packet in OAM type 424
  • transit device ID to be returned in payload 425 NMS-t44
  • setting register in other areas A return request packet is generated using the set value of 106 and transmitted.
  • the failure management unit 107 When the failure management unit 107 receives the OAM packet addressed to itself from the input packet processing unit 103, the failure management unit 107 checks the OAM type 424 of the payload 425, and if it is determined to be a return request packet, the failure management unit 107 uses the LSP label 414-1.
  • the LSP label value 256 in the direction opposite to the received direction, the identifier indicating that it is a return response packet in the OAM type 424, the termination device ID to be returned in the payload 425: 253, and the setting register 106 set in other areas Returns a response packet using the value.
  • the response packet is a return response packet
  • the return test is successful, so that the network management system NMS is notified via the NIF management unit 105 and the device management unit 12.
  • FIG. 20 shows a sequence SQ100 when setting the network NW from the operator OP.
  • this change request type new addition or deletion of the user.
  • the operator adds a new addition after deletion
  • user ID for example, access device # 1 and data center
  • connection destination for example, access device # 1 and data center
  • service type for example, service type, and changed contract bandwidth are transmitted (SQ101).
  • the network management system NMS that has received the setting change changes the path construction policy according to the SLA of the service by referring to the path construction policy table NMS-t1 or the like by a path search process S2000 corresponding to the service to be described later.
  • the path is searched using the connection destination management table NMS-t3 and the link management table NMS-t5.
  • the result is set in the corresponding communication device ND # 1-n (SQ102-1 to n).
  • This setting information includes the connection relationship between each user and path such as the connection ID determination table 21, the input header processing table 22, the label setting table 23, the bandwidth monitoring table 24, the failure management table 25, and the packet transfer table 26 described above. Includes bandwidth settings.
  • the traffic from the user can be transmitted and received along the set route, and between the edge devices ND # 1 and ND # n that are the end points of the path, Periodic transmission / reception of the failure monitoring packet is started (SQ103-1, SQ103-n).
  • a setting completion notification is transmitted from the network management system NMS to the operator OP (SQ104), and this sequence is completed.
  • FIG. 21 shows a sequence SQ200 when the network NW is set by a request from the user terminal TEn.
  • a server that provides a homepage provided by a telecommunications carrier is installed in the Internet IN as a means for the telecommunications carrier to accept a service request that requires the user to change the network NW.
  • other alternative means for example, a means capable of accessing the Internet from any of smartphones, homes, or offices are provided. Suppose you are.
  • the server installed in the Internet IN that has received the request converts it into setting information of the network NW (SQ202), and changes the setting change to the management network MNW. Is transmitted to the network management system NMS via SQ203 (SQ203).
  • the processing of the path search process S2000 corresponding to the subsequent service, the setting to the communication device ND # n (SQ102), and the start of constant monitoring by the monitoring packet (SQ103) are the same as SQ100 (FIG. 20).
  • a setting completion notification is transmitted from the network management system NMS to the server on the Internet IN via the management network MNW (SQ104), and further notified to the user terminal TEn (SQ205). This sequence ends.
  • FIG. 22 shows a sequence SQ300 when the network NW is set according to a request from the data center DC.
  • the processing of the path search process S2000 corresponding to the subsequent service, the setting to the communication device ND # n (SQ102), and the start of constant monitoring by the monitoring packet (SQ103) are the same as SQ100 (FIG. 20).
  • the network management system NMS notifies the setting completion notification to the data center DC via the management network MNW (SQ302), and this sequence ends.
  • FIG. 23 shows a failure location identification sequence SQ400 when a failure occurs in the relay device ND # 3.
  • failure monitoring packets periodically transmitted / received between the edge devices ND # 1 and ND # n do not arrive (SQ401-1, SQ401). -N).
  • each of the edge devices ND # 1 and ND # n detects that a failure has occurred in the guaranteed service path PTH # 1 (SQ402-1, SQ402-n).
  • each of the edge devices ND # 1 and ND # n performs a failure notification process S3000 described later, and preferentially notifies the network management system NMS of the failure of the guaranteed service path PTH # 1 (SQ403-1). , SQ403-n).
  • the network management system NMS Upon receiving this notification, the network management system NMS notifies the operator OP that a failure has occurred in the guaranteed service path PTH # 1 (SQ404), and automatically executes the following failure location determination processing (SQ405). .
  • the network management system NMS confirms the normality between the edge device ND # 1 and the adjacent relay device ND # 2, and the loopback test request and information necessary for that (test target path ID: NMS-t41, The edge device ND # 1 is notified of the return device ID (NMS-t44) to be returned (SQ4051-1).
  • the edge device ND # 1 transmits a return request packet as described above (SQ4051-1req).
  • the relay device ND # 2 that has received this loopback test packet returns the loopback response packet as described above because it is a loopback test addressed to itself (SQ4051-1rpy).
  • the edge device ND # 1 that has received the loopback response packet notifies the network management system NMS of a loopback test success notification (SQ4051-1suc).
  • the network management system NMS that has received the success notification of the loopback test identifies the loopback test request and information necessary for this in order to identify the failure location and to confirm the normality with the relay device ND # 1. (SQ4051-2).
  • the edge device ND # 1 transmits a return request packet as described above (SQ4051-2req).
  • This loopback test packet is not returned to the edge device ND # 1 because the relay device ND # 3 has failed (SQ4051-2def).
  • the edge device ND # 1 notifies the network management system NMS of a return test failure notification because the return response packet is not returned within a predetermined time (SQ4051-2fail).
  • the network management system NMS that has received the return test failure notification identifies the failure location as the relay device ND # 3 (SQ4052), notifies the operator OP of the failure location as the failure location (SQ4053), and ends this sequence. .
  • FIG. 24 and 25 show a path search process S2000 corresponding to a service executed by the network management system NMS.
  • processing can be realized by the network management system NMS having the hardware resources shown in FIG. 2 and using the hardware resources for information processing by software.
  • the network management system NMS that has received the setting change from the operator OP or the Internet IN or the data center DC acquires the request type, the connection destination, the SLA type, and the contract bandwidth as the setting change (S201). Check (S202).
  • the request type is deletion
  • the corresponding entry is deleted from the corresponding user management table NMS-t2 (FIG. 4), and the path configuration table NMS-t4 (FIG. 6) corresponding to the accommodation path NMS-t23 of the user is deleted. Update entry information.
  • the contracted bandwidth NMS-t24 of the user management table NMS-t2 (FIG. 4) is subtracted from the allocated bandwidth NMS-t47 of the path configuration table NMS-t4 (FIG. 6).
  • the user ID is deleted from the accommodated user NMS-t48. If it is a fair service, the user ID is deleted from the accommodated user NMS-t48.
  • connection destination management table NMS-t3 (FIG. 5) is searched using the information of the connection destination, and the accommodation device (node) ID: NMS-t33 as a point that can be the connection destination. And a candidate for a combination of accommodation port ID: NMS-t34 is extracted (S203). For example, when the access device AE # 1 is designated as the starting point and the data center DC is designated as the ending point in FIG. 1, the candidates are as follows.
  • Candidate source port (1) Accommodating device ID: ND # 1 accommodating port ID: PT # 1 Destination port candidates: (A) Accommodating device ID: ND # n accommodating port ID: PT # 10 (B) Accommodating device ID: ND # n accommodating port ID: PT # 11
  • the SLA type acquired in S201 is checked (S204). If it is a guarantee type, a general route search algorithm (multi-route selection method or Dijkstra) is used using the link management table NMS-t5 (FIG. 7). Using a method or the like, a route having a free bandwidth corresponding to the designated contract bandwidth and having the minimum free bandwidth is searched (S205). Specifically, for example, when there is a route that reaches from the start port to the end port via a link determined to be usable from the link management table NMS-t5, the total value of the costs (present By selecting a route with the smallest available bandwidth in the embodiment, the guaranteed service paths can be aggregated into the existing paths.
  • a general route search algorithm multi-route selection method or Dijkstra
  • the threshold value may be a threshold value that defines an absolute numerical value, or may be a threshold value based on a relative (for example, lower 10%) definition.
  • FIG. 25 shows processing when it is determined that the fair type is determined in S204. If the fair type is determined in S204, the “free bandwidth NMS-t52” is used by using a general route search algorithm (multi-route selection method or Dijkstra method) using the link management table NMS-t5. ⁇ A route with the maximum number of transparent non-priority users NMS-t53 "is searched (S212).
  • a general route search algorithm multi-route selection method or Dijkstra method
  • the total value of the costs (present In the embodiment, the fair service is distributed among the existing paths by selecting the route having the largest “free bandwidth NMS-t52 ⁇ transparent non-priority user count NMS-t53”).
  • a certain degree of dispersion effect can also be obtained by a method such as randomly selecting a route having a value not less than the predetermined threshold value instead of the route having the maximum value.
  • the threshold value may be a threshold value that defines an absolute numerical value, or may be a threshold value based on a relative (for example, upper 10%) rule.
  • the path configuration table NMS-t4 is used to determine whether the obtained path is an existing path (S213).
  • a new entry is added to the user management table NMS-t2
  • the existing path is set as the accommodation path NMS-t23
  • the information of the entry in the corresponding path configuration table NMS-t4 is updated.
  • a new user ID is added to the accommodated user NMS-t48.
  • all entries corresponding to the via link ID: NMS-t45 in the link management table NMS-t5 are updated.
  • 1 is added to the number of transparent non-priority users NMS-t53.
  • the various tables 21 to 26 of the corresponding communication device #n are updated, the result of the process is notified to the operator (S214), and the process is terminated (S216).
  • guaranteed service paths can be aggregated on the same route, and fair service paths can be distributed according to the ratio of the number of accommodated users.
  • FIG. 26 shows details of the failure management table polling process S300 in the failure notification process (FIG. 23, S3000) executed by the NIF management unit 105 of the communication device ND # n.
  • the NIF management unit 105 starts this polling process at the same time when the apparatus is turned on, initializes the variable i to “0” (S301), and adds 1 to the variable i (S302).
  • the path ID: 251 in the failure management table 25 (FIG. 19) is searched as PTH # i, and an entry is acquired (S303).
  • PTH # i is used as a path ID, and the SLA type (FIG. 19, 252) is notified to the device management unit 12 as a failure occurrence notification (S305), and the processing after S302 is continued.
  • the device management unit 12 that has received the failure occurrence notification stores the received information in the failure notification queue (priority) 27-1 if the SLA type is a guaranteed service (eg, SLA # 1), and the SLA type is fair. If it is a type service (for example, SLA # 2), it is stored in the failure notification queue (non-priority) 27-2 (see FIG. 11).
  • the SLA type is a guaranteed service (eg, SLA # 1), and the SLA type is fair. If it is a type service (for example, SLA # 2), it is stored in the failure notification queue (non-priority) 27-2 (see FIG. 11).
  • FIG. 27 shows details of the failure notification queue read processing S400 in the failure notification processing S3000 executed by the device management unit 12 of the communication device ND # n.
  • the failure notification queue (priority) 27- 1 determines whether there is a notification (S401).
  • the network management system NMS is notified as a failure notification together with the path ID and SLA type stored in the failure notification queue (priority) 27-1 (S402).
  • the network management system NMS preferentially processes the previously notified failure, so that it is possible to preferentially deal with the guaranteed service and guarantee the operation rate.
  • S2800 is obtained by adding the following S2001 to S2006 after the processing of S209, S210, and S211 in S2000 (FIG. 24), and the other processing is the same as S2000. Therefore, only the changes will be described below. .
  • the path configuration table NMS-t4 is searched for whether there is a fair service path on the same path as the path whose setting has been changed (S2001).
  • a fair service path ID NMS-t41 is obtained in which the via link ID NMS-t45 has the same path. Then, 1 is subtracted from the number NMS-t53 of non-priority transparent users corresponding to the link via the path: NMS-t45 in the link management table NMS-t5, and the result is stored as the temporary link management table NMS-t5 (S2002).
  • the total cost value (In this embodiment, the route with the largest “free bandwidth NMS-t52 ⁇ transparent non-priority user number NMS-t53”) is selected, so that the fair service is distributed among the existing paths.
  • the path configuration table NMS-t4 is used to determine whether the obtained path is an existing path (S2004).
  • the entry is deleted from the corresponding user management table NMS-t2, and the entry information of the path configuration table NMS-t4 corresponding to the accommodation path NMS-t23 of the user is updated (from the accommodation user NMS-t48). Delete the user ID). Also, all entries corresponding to the via link ID: NMS-t45 in the link management table NMS-t5 are updated (transparent non-priority user number NMS-t53 is decremented by 1). Further, the various tables 21 to 26 of the corresponding communication device #n are updated. Further, the user deleted above is added to the user management table NMS-t2, and the existing path is set as the accommodation path NMS-t23.
  • the entry information of the corresponding path configuration table NMS-t4 is updated (the user ID deleted above is added to the accommodated user NMS-t48). Also, all entries corresponding to the via link ID: NMS-t45 in the link management table NMS-t5 are updated (1 is added to the number of transparent non-priority users NMS-t53). In addition, the various tables 21 to 26 of the corresponding communication device #n are updated, and the processing result is notified to the operator.
  • the corresponding entry is deleted from the corresponding user management table NMS-t2, and the information of the entry in the path configuration table NMS-t4 corresponding to the accommodation path NMS-t23 of the user is updated.
  • the user ID is deleted from the accommodated user NMS-t48.
  • all entries corresponding to the via link ID: NMS-t45 in the link management table NMS-t5 are updated.
  • 1 is subtracted from the number NMS-t53 of transparent non-priority users.
  • the various tables 21 to 26 of the corresponding communication device #n are updated.
  • the user deleted above is added to the user management table NMS-t2, and a new path is set in the accommodation path NMS-t23.
  • a new entry is added to the path configuration table NMS-t4. Specifically, the deleted user ID is added to the accommodated user NMS-t48. Also, all entries corresponding to the via link ID: NMS-t45 in the link management table NMS-t5 are updated. Specifically, 1 is added to the number NMS-t53 of transparent non-priority users. In addition, the various tables 21 to 26 of the corresponding communication device #n are updated, and the processing result is notified to the operator.
  • the configuration of the network management system of this embodiment is almost the same as that of the network management system NMS of the first embodiment shown in FIG.
  • the description will focus on the different parts, except that a path is set in advance in the path configuration table NMS-t4.
  • the path configuration table is referred to as NMS-t40.
  • the configuration of each block is the same as that of the network management system NMS.
  • FIG. 30 shows a network pre-setting sequence SQ1000 from the operator.
  • the operator OP transmits a connection destination (for example, a combination of the access device # 1 and the data center DC) and a service type as advance setting information (SQ1001).
  • a connection destination for example, a combination of the access device # 1 and the data center DC
  • a service type as advance setting information (SQ1001).
  • the network management system NMS that has received it searches for a path using the connection destination management table NMS-t3 and the link management table NMS-t5 by a pre-path search process S500 described later.
  • the result is set in the corresponding communication device ND # 1-n (SQ1002-1-n).
  • connection ID determination table 21 As this setting information, each user and path such as the connection ID determination table 21, the input header processing table 22, the label setting table 23, the bandwidth monitoring table 24, the failure management table 25, and the packet forwarding table 26 as in the first embodiment are used. Connection relations and bandwidth settings.
  • each communication device ND # n When these pieces of information are set in each communication device ND # n, periodic transmission / reception of a failure monitoring packet is started between the edge devices ND # 1 and ND # n serving as path termination points (SQ1003-1). , SQ1003-n).
  • a setting completion notification is transmitted from the network management system NMS2 to the operator OP (SQ1004), and this sequence is completed.
  • FIG. 31 shows a pre-path search process S500 executed by the network management system NMS.
  • the network management system NMS that has received the presetting from the operator OP acquires the connection destination and the SLA type as presetting (S501).
  • connection destination management table NMS-t3 is searched using the information of the connection destination, and a combination candidate of the accommodation node ID: NMS-t33 and the accommodation port ID: NMS-t34 is extracted as a point that can be a connection destination. (S502).
  • the candidates are as follows.
  • Candidate source port (1) Accommodating device ID: ND # 1 accommodating port ID: PT # 1 Destination port candidates: (A) Accommodating device ID: ND # n accommodating port ID: PT # 10 (B) Accommodating device ID: ND # n accommodating port ID: PT # 11
  • the link management table NMS-t5 is used to search a list of routes to which the start point and end point can be connected using a general route search algorithm (multi-route selection method or Dijkstra method). (S503).
  • a new entry is added to the user management table NMS-t2
  • a new path is set in the accommodation path NMS-t23
  • a new entry is added to the path configuration table NMS-t4 (0 Mbps in the allocated bandwidth NMS-t47) (Unused), set an invalid value to the accommodating user NMS-t48), update the various tables 21 to 26 of the corresponding communication device #n, and notify the operator of the processing result.
  • FIG. 32 shows a path configuration table NMS-t40 generated by the network preset sequence SQ1000 from the operator.
  • the path configuration table NMS-t40 uses the path ID: NMS-t401 as a search key, the SLA type NMS-t402, the terminating device ID: NMS-t403, the transit device ID: NMS-t404, and the transit link ID: This is for retrieving table entries indicating the NMS-t 405, the allocated bandwidth NMS-t 406, and the accommodated user NMS-t 407.
  • the allocated bandwidth NMS-t 406 is 0 Mbps because the user is not accrued, and there is no accommodated user. Furthermore, there is no number of accommodated users for the fair service path.
  • the configuration of the communication system, the block configuration of the communication device ND # n, and the processing are the same as those in the first embodiment.
  • a plurality of candidate paths can be set in advance for all the connection destinations. Therefore, in the path search processing S2000 and S2800 corresponding to the service, a new user is already existing. The probability of being accommodated in the path is increased, and the network can be changed more quickly.
  • the present invention is not limited to the above-described embodiment, and includes various modifications.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • functions equivalent to those configured by software can also be realized by hardware such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit).
  • the functions configured by software may be realized by a single computer configuration, or any part of the input device, output device, processing device, and storage device may be connected to another computer connected via a network. It may be configured.
  • the failure of the communication service for business users is preferentially notified from the communication device, and the network management system that has received this notification can preferentially execute the loopback test, so that the failure of the communication service path for business users can be performed. It is possible to quickly identify the location and quickly perform maintenance work such as component replacement. As described above, it is possible to satisfy both the communication quality and the operation rate.
  • a path for a communication service for general consumers that needs to accommodate a large amount of traffic efficiently and fairly among users is considered in consideration of a surplus band other than the band reserved for the communication path for business users, By distributing the excess bandwidth ratio over the entire network so that it becomes equal for each user, it becomes possible to accommodate large volumes of traffic efficiently and with fairness among users.
  • It can be used for operation management of networks used for various services.
  • TE1 to n User terminals AE1 to n: Access devices ND # 1 to n: Communication device DC: Data center IN: Internet MNW: Management network NMS: Network management system MT: Monitoring terminal OP: Operator

Abstract

複数の通信装置で構成される通信ネットワークと管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する、通信ネットワークの管理方法であって、管理システムが通信パスを設定する際、稼働率の保証が必要な第１のサービスのために、通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する、第１の設定ポリシと、稼働率の保証をしない第２のサービスのために、使用する経路を通信ネットワーク全体に分散するように通信パスを設定する、第２の設定ポリシを有し、サービスの種類に応じて上記設定ポリシを変更することを特徴とする、通信ネットワークの管理方法が開示される。

Description

通信ネットワーク、通信ネットワークの管理方法および管理システム
　本発明は、パケット通信システムに関し、更に詳しくは、複数の異なるサービスを収容する通信システムに関し、特にＳＬＡ保証が可能なパケット通信システム及び通信装置に関する。
　これまでの通信ネットワークは、提供される通信サービス毎に独立に構築されてきた。これは、各サービスで要求される品質が異なるため、ネットワークの構築や保守の方法がサービス毎に大きく異なっていたためである。例えば、国防や金融などのミッションクリティカルな業務に使用される専用線に代表されるビジネスユーザ向け通信サービスでは、１００％の通信帯域の保証や、１年の稼働率として例えば９９．９９%以上が要求される。
　一方、有線や携帯電話でのインタネットアクセスなどの一般消費者向け通信サービスでは、保守作業のための数時間のサービス断は許容されるが、急増するトラヒックを効率よく、そしてユーザ間で公平に収容することが求められる。
　通信事業者は、このような通信品質（帯域や遅延など）保証や稼働率保証などを規定したＳｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ（ＳＬＡ）をユーザと結び、通信サービスを提供している。ＳＬＡを満たせない場合、通信事業者は料金の減額や補償金などが求められるため、ＳＬＡ保証は非常に重要である。
　ＳＬＡ保証する上で最も重要な内容は、帯域や遅延などの通信品質である。通信帯域や遅延を保証するためには、ネットワーク中で要求値を満たせる経路を検索し、各ユーザやサービスに割り当てる必要がある。従来の通信システムは、ダイクストラ（Ｄｉｊｋｓｔｒａ）アルゴリズムのように、経路上のリンクのコストを合計して、合計値が最小である経路または最大である経路を選択する経路計算方法が採用されている。ここで、通信帯域や遅延は、経路上の各リンクのコストに変換され、計算される。
　この経路計算方法によれば、例えば、リンクの物理的帯域をリンクのコストとして表し、経路上のリンクのコストの合計値を最大にする経路または最小にする経路を計算することによって、パケット通信のトラフィックをより多く収容することのできる経路が計算される。しかし、この経路計算方法の場合、経路上のリンクのコストの合計値のみを考慮しているため、１つのリンクのコストが極端に小さいまたは大きい場合、当該リンクがボトルネックとなってトラヒックが滞るなどの問題が発生する。これに対し、経路上のリンクのコストの合計値のみを考慮するのではなく、経路上の各リンクのコストの大小にも着目することで、問題を解決するダイクストラの改良方法がある（特許文献１）。本方法を用いることで、ボトルネックを回避し、ＳＬＡ保証が可能なパスを検索することが可能となる。
　続いて、ＳＬＡの中で稼働率に関しては、保守性に強く依存している。ＳＬＡに稼働率が含まれている専用線サービスなどは、全ての通信装置が通信経路の障害を検出するＯｐｅｒａｔｉｏｎ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ　ａｎｄ　Ｍａｉｎｔａｉｎａｎｃｅ（ＯＡＭ）ツールを有し、短時間で故障発生を検出し、事前に準備した代替経路に自動的に切替える。この代替経路も故障するような多重障害の場合は、障害が発生した経路に対して折返し試験などの接続検証ＯＡＭツールを用いることで、物理的な故障位置を特定し、部品交換などの保守作業が実施することで、如何なる場合においても稼働率を保証できる。
　しかし、近年通信ネットワークが汎用化し、利益の源泉がサービスやアプリケーション提供事業者に移っており、通信サービスを提供する通信事業者の収益性は頭打ちになりつつある。このため、通信キャリアは、現状の通信サービスの提供コストの削減と、通信サービスに新たな価値を付加することによる収益性の改善を試みている。そこで、様々な通信サービスを提供する通信事業者は、従来のようなサービス独立のネットワーク構築ではなく、各サービスを統合収容するネットワークにより、装置共有によるサービス提供コスト低減を図っている。さらに、従来は数時間～数か月を要していたサービス開通やＳＬＡ変更によるネットワーク変更を数秒～数分に短縮することにより、ユーザやアプリケーション提供事業者からの要求に応じたタイムリーな最適ネットワーク提供で収入増を狙っている。
　このようなサービスを統合するネットワークを構築するためには、ネットワークを論理的に仮想化し、物理的な回線や通信装置に多重することが必須となる。そのための技術として、Ｍｕｌｔｉｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ（ＭＰＬＳ）をはじめとしたＶｉｒｔａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ（ＶＰＮ）技術が存在する。
　このようなＶＰＮ技術を使用して複数のサービスを一つのネットワークに収容する場合、各サービスとそのユーザを論理的なパスとしてネットワークに収容する。例えば、ＭＰＬＳにイーサネット（登録商標）を収容する場合、イーサネットの各ユーザやサービスをＰｓｕｄｏ　Ｗｉｒｅ（ＰＷ）にマッピングし、それをＭＰＬＳネットワークのパス（ＭＰＬＳパス）にさらにマッピングする。
　ＭＰＬＳパスは、パスＩＤで指定されたＭＰＬＳネットワーク中の経路であり、イーサネットからＭＰＬＳ装置に到着したパケットは、このパスＩＤを含むＭＰＬＳラベルでカプセル化をされた後、ＭＰＬＳネットワーク中のこの経路に沿って転送される。このため、各ユーザやサービスにどのパスＩＤを割り当てるかによって、ＭＰＬＳネットワーク中での経路が一意に決定されると共に、物理回線に複数の論理パスを収容することで、複数のサービスを多重することが可能となっている。このサービス毎の仮想的なネットワークを仮想ネットワークと呼ぶ。
　ＭＰＬＳでは保守性を向上するＯＡＭツールが規定されており、論理パスの始点と終点でＯＡＭパケットを定期的に送受信するＯＡＭツール（非特許文献１）により障害発生を論理パス毎に高速検出することで、代替経路への高速な切替が可能である。
　さらに、論理パスの始点と終点で検出された障害は、通信装置からネットワーク管理システムを介してオペレータに通知される。その結果、オペレータは障害が発生した論理パス上の障害位置を特定するため、論理パス上の中継地点に対して折返し用のＯＡＭパケットを送信する折返し試験ＯＡＭツール（非特許文献２）を実施する。これにより、論理パス上の障害箇所から物理的な障害箇所が特定されるため、部品効果などの保守作業が可能である。
　さらに、上記のように複数サービスを統合する仮想ネットワークが動的に変更される環境において、各サービスのＳＬＡを保証するためには、従来のようにオペレータ（人）を介した設定や運用では対応が困難である。そこで、帯域や遅延などの通信品質に関するポリシをサービス毎に規定し、ネットワークを管理するサーバ（ネットワーク管理システム）においてそれに応じた経路を計算し、自動的に論理パスの設定を行うことが考えられる（特許文献２）。これにより、オペレータを介すことなく各サービスの通信品質を保証可能なネットワークの構築や変更が可能となる。
　以上のように、従来の通信システムは、稼働率に関してはＯＡＭツールにより保証可能としてきたため、経路計算する際には帯域や遅延などの通信品質のみが考慮されてきた。
特開２００１－２４４９７４号公報 特開２００４－２３６０３０号公報
ＩＥＴＦ　ＲＦＣ６４２８（Ｐｒｏａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ, Ｃｏｎｔｉｎｕｉｔｙ Ｃｈｅｃｋ, ａｎｄ Ｒｅｍｏｔｅ Ｄｅｆｅｃｔ Ｉｎｄｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ ＭＰＬＳ Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｆｉｌｅ） ＩＥＴＦ　ＲＦＣ６４２６（ＭＰＬＳ Ｏｎ-Ｄｅｍａｎｄ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ ａｎｄ Ｒｏｕｔｅ Ｔｒａｃｉｎｇ）
　しかしながら、複数サービスを統合する仮想ネットワークにおいて、通信品質のみを考慮して論理パスの経路計算してしまうと、ネットワーク全体のリソースを無駄なく利用するようにトラヒックを収容することが優先されるため、論理パスは仮想ネットワーク全体に分散して設定されてしまう。
　インタネットなどを利用する一般消費者の数は、通信品質に加え稼働率の保証が必要なビジネスユーザの数に比べて２ケタ以上大きいため、障害発生時に影響を受けるユーザ数が膨大となる。このため、稼働率の保証が必要なビジネスユーザ用の論理パスで検出された障害を迅速に発見し、折り返し試験を行うことが困難であった。この結果、故障個所の特定とそれによる部品交換がなどの保守作業にかかる時間が増大し、稼働率を保証できなくなってしまうという課題があった。
　上記課題を解決するため、本発明の一側面であるパケット通信システムは、複数の通信装置とそれらの管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する通信システムである。このシステムにおいて、管理システムが通信パスを設定する際、保守性を向上するためにネットワーク上一部でも同じ経路を共有するパス同士を集約するものと、トラフィックを効率的に収容するために経路をネットワーク全体に分散するもの、など複数のパス設定ポリシをサービスに応じて変更することを特徴とする。
　さらに具体的な詳細な例としては、本発明のパケット通信システムに収容するサービスのうちパスを集約するサービスは、ユーザまたはサービス毎にある一定の帯域を確保するサービスであって、同一経路に集約されたサービスの帯域の総和がパス上のいずれかの回線帯域を超過した場合、同一経路に集約されたサービスの帯域の総和がパス上のいずれかの回線帯域も超過しない他の経路を検索して設定するものである。また、パスを分散するサービスは、経路上の各回線帯域からパスを集約するサービス向けに確保された帯域を差し引いた余りの帯域に応じてパスを分散するものである。
　さらに具体的な詳細な例としては、本発明のパケット通信システムは、インタネット上のユーザや、データセンタなどの、接続された外部システムから要求に応じてパスの変更をする際、管理システムは自動的にパス設定ポリシを適用する。
　さらに具体的な詳細な例としては、本発明のパケット通信システムの通信装置は、複数のパスの障害を検出した際、稼働率の保証が必要なサービスに関わるパスの障害を優先的に管理システムに通知する。また、管理システムは、稼働率の保証が必要なサービスの障害通知を優先的に処理し、折返し試験を自動的に実行する、または折返し試験の実行をオペレータに促すことを特徴とする。
　本発明の他の側面は、複数の通信装置で構成される通信ネットワークと管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する、通信ネットワークの管理方法である。この管理方法では、管理システムが通信パスを設定する際、稼働率の保証が必要な第１のサービスのために、通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する第１の設定ポリシと、稼働率の保証をしない第２のサービスのために、使用する経路を通信ネットワーク全体に分散するように通信パスを設定する第２の設定ポリシを有し、サービスの種類に応じて設定ポリシを変更することを特徴とする。
　本発明のさらに他の側面は、通信ネットワークを構成する複数の通信装置に対して、ユーザに対して帯域を保証する第１のサービスのための通信パスと、ユーザに対して帯域を保証しない第２のサービスのための通信パスを設定し、通信ネットワーク内に第１及び第２のサービスのための通信パスを共存させる、通信ネットワーク管理システムである。この通信ネットワーク管理システムは、第１のサービスのための新規の通信パス設定要求があった場合には、保証帯域分の空き帯域が存在する経路から選ばれた経路に、新規の通信パスを設定する第１の設定ポリシを適用し、第２のサービスのための新規の通信パス設定要求があった場合には、第２のサービスのユーザあたりの空き帯域に基づいて選ばれた経路に、新規の通信パスを設定する第２の設定ポリシを適用する。
　より具体的な構成例を挙げれば、第１の設定ポリシは、保証帯域分の空き帯域が存在する経路から、空き領域が最小の経路を選び、新規の通信パスを設定する。また、第２の設定ポリシは、第２のサービスのユーザあたりの空き帯域が最大の経路を選び、新規の通信パスを設定する。このようなポリシに従えば、第１のサービスのための通信パスは、なるべく経路を共用するように設定され、第２のサービスのための通信パスは、なるべくユーザ間の利用可能帯域が均一になるように設定される。
　本発明のさらに他の側面は、経路を構成する複数の通信装置と、複数の通信装置にユーザの利用に供する通信パスを設定する管理システムを有する通信ネットワークである。この通信ネットワークでは、管理システムは、ユーザの利用に供するため、ＳＬＡの異なる第１のサービスのための通信パスと、第２のサービスのための通信パスを設定する。そして、第１のサービスに用いる通信パスを設定する場合には、第１のサービスに用いる通信パスがネットワーク上の特定の経路に集約されるように設定し、第２のサービスに用いる通信パスを設定する場合には、第２のサービスに用いる通信パスが上記ネットワーク上の経路に分散されるように設定することを特徴とする。
　より具体的な構成例を例示すれば、第１のサービスは、稼働率および帯域が保証されるサービスであり、第１のサービスが提供される複数のユーザのために用いられる複数の通信パスの、ネットワーク上の送信ポートと宛先ポートが同一の場合、同一の経路にこれらの複数の通信パスを設定する。また、第２のサービスは、ベストエフォート型のサービスであり、第１のサービスに用いる通信パスが使用している通信帯域を除外した空き帯域の、第２のサービスのユーザ当たりの割り当てが均等になるように、第２のサービスに用いる通信パスを設定することを特徴とする。
　ＳＬＡの異なる複数サービスを収容する通信ネットワークを構成することができ、通信事業者のサービス統合による提供コスト低減と、タイムリーな最適ネットワーク提供による利便性の向上を実現できる。
本発明の通信システムの構成の一実施例を示すブロック図。 本発明のネットワーク管理システムの一実施例を示すブロック図。 図２のネットワーク管理システムが備えるパス構築ポリシテーブルの一例を示す表図。 図２のネットワーク管理システムが備えるユーザ管理テーブルの一例を示す表図。 図２のネットワーク管理システムが備える接続先管理テーブルの一例を示す表図。 図２のネットワーク管理システムが備えるパス構成テーブルの一例を示す表図。 図２のネットワーク管理システムが備えるリンク管理テーブルの一例を示す表図。 本実施例の通信システムに流れるイーサネット通信パケットのフォーマット例を示す表図。 本実施例の通信システムに流れるＭＰＬＳ通信パケットのフォーマット例を示す表図。 本実施例の通信システムに流れるＭＰＬＳ通信のＯＡＭパケットのフォーマット例を示す表図。 実施例の通信装置ＮＤ＃ｎの構成例を示すブロック図。 通信装置ＮＤ＃ｎの入力パケットに付加される装置内ヘッダのフォーマット例を示す表図。 図１１のネットワークインタフェースボード（１０－ｎ）が備えるコネクションＩＤ決定テーブルの例を示す表図。 図１１のネットワークインタフェースボード（１０－ｎ）が備える入力ヘッダ処理テーブルの例を示す表図。 図１１のネットワークインタフェースボード（１０－ｎ）が備えるラベル設定テーブルの例を示す表図。 図１１のネットワークインタフェースボード（１０－ｎ）が備える帯域監視テーブルの例を示す表図。 図１１のスイッチ部１１が備えるパケット転送テーブルの例を示す表図。 図１１の入力パケット処理部１０３が実行する入力パケット処理Ｓ１００の一例を示すフローチャート。 図１１のネットワークインタフェースボード（１０－ｎ）が備える障害管理テーブルの例を示す表図。 実施例の通信システムが実行するオペレータからのネットワーク設定シーケンスＳＱ１００の一例を示すシーケンス図。 実施例の通信システムが実行するユーザ端末からのネットワーク設定シーケンスＳＱ２００の一例を示すシーケンス図。 実施例の通信システムが実行するデータセンタからのネットワーク設定シーケンスＳＱ３００の一例を示すシーケンス図。 実施例の通信システムが実行する障害箇所特定シーケンスＳＱ４００の一例を示すシーケンス図。 図２のネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２００の一例のフローチャート。 図２のネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２００の一例のフローチャートの続き。 図１１のネットワークインタフェースボード（１０－ｎ）が実行する障害管理ポーリング処理Ｓ３００の一例のフローチャート。 図１１の装置管理部１２が実行する障害通知キュー読出し処理Ｓ４００のフローチャート。 本発明の実施例が適用される他の通信システムのネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２８００の一例のフローチャート。 本発明の実施例が適用される他の通信システムのネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２８００の一例のフローチャートの続き。 本発明の実施例が適用される他の通信システムが実行するオペレータからのネットワーク事前設定シーケンスＳＱ１０００の一例のシーケンス図。 本発明の実施例のネットワーク管理システムが実行する事前パス検索処理Ｓ５００の一例のフローチャート。 本発明の実施例のネットワーク管理システムが備えるパス構成テーブルの他の一例を示す表図。
　以下、本発明の実施例について、図面を参照して説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
　以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
　本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
　図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
　図１は、本発明の通信システムの一例を示す。このシステムは、複数の通信装置とそれらの管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する通信システムである。ここで、管理システムが通信パスを設定する際、稼働率の保証が必要なサービスのため、迅速に故障個所を特定する目的でネットワーク上一部でも同じ経路を共有するパス同士を集約するものと、稼働率の保証の必要がなく、多数のユーザの大量のトラヒックを収容するサービスのため、多数のユーザで公平にトラヒックを収容する目的で経路をネットワーク全体に分散するもの、など複数のパス設定ポリシをサービスに応じて変更することができる。
　本実施例の通信装置ＮＤ＃１～ｎは、ユーザ端末ＴＥ１～ｎを収容するアクセス装置ＡＥ１～ｎと、データセンタＤＣまたはインタネットＩＮの間を接続する、通信事業者のネットワークＮＷを構成する。本ネットワークＮＷの通信装置ＮＤ＃１～ｎのうち、エッジ装置と中継装置の装置構成などは同一でよく、事前設定や入力されるパケットに応じてエッジ装置として動作する場合と中継装置として動作する場合があるのみである。図１では、ネットワークＮＷの位置から便宜上通信装置ＮＤ＃１およびＮＤ＃ｎがエッジ装置動作、通信装置ＮＤ＃２、ＮＤ＃３、ＮＤ＃４およびＮＤ＃５が中継装置動作しているものとする。
　各通信装置ＮＤ＃１～ｎは、管理用ネットワークＭＮＷでネットワーク管理システムＮＭＳに接続される。本通信事業者の通信システムと、ユーザやアプリケーション提供事業者の管理を連携させるため、ユーザからの要求を処理するサーバが設置されているインタネットＩＮや、アプリケーション提供事業者が有するデータセンタＤＣも、管理用ネットワークＭＮＷに接続されている。
　各論理パスはネットワーク管理システムＮＭＳにより設定（図２０のＳＱ１００で後述する）される。ここではパスＰＴＨ＃１およびＰＴＨ＃２が中継装置ＮＤ＃２およびＮＤ＃３を経由、パスＰＴＨ＃ｎが中継装置ＮＤ＃４およびＮＤ＃５を経由するように設定されており、いずれもエッジ装置ＮＤ＃１とエッジ装置ＮＤ＃ｎ間のパスである。図１の例では、パスＰＴＨ#１はビジネスユーザ用通信サービス向けの帯域が保証されるパスのため、ネットワーク管理システムＮＭＳが、パスＰＴＨ＃１に対して、５００Ｍｂｐｓを割り当てているものとする。これは、ユーザ端末ＴＥ１およびＴＥ２を使用しているビジネスユーザが、それぞれ２５０Ｍｂｐｓの通信サービスを契約しているため、そのユーザが収容されるパスＰＴＨ＃１はその積算値である５００Ｍｂｐｓが確保される。一方、一般ユーザ用のユーザ端末ＴＥ３、ＴＥ４およびＴＥｎが使用するパスＰＴＨ＃２およびＰＴＨ＃ｎは、一般消費者用通信サービス向けでありベストエフォートで運用されるため、帯域は確保されず、エッジ装置ＮＤ＃１およびＮＤ＃ｎ間の接続性のみが確保されている。
　以上のように、図１の通信システムにおいては、ＳＬＡ保証レベルの異なる、ビジネスユーザ用途の通信パスと、個人ユーザ用途の通信パスが、同一の通信装置を経路として用いることを許容している。
　このようなパスの設定やその変更は、通常ネットワーク管理者であるオペレータＯＰが、監視端末ＭＴを介してネットワーク管理システムＮＭＳに指示を与えることで実行される。しかし、現在の通信事業者はユーザやアプリケーション提供事業者からの要求に応じて最適なネットワークを提供することで新たな収入を得ようと試みており、インタネットＩＮやデータセンタＤＣからもオペレータと同様に、パスの設定やその変更のための指示が到来する。
　図２は、ネットワーク管理システムＮＭＳの構成の一例を示す。
　ネットワーク管理システムＮＭＳは通常汎用的なサーバで実現されるため、その構成はプログラムを実行するＭｉｃｒｏ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ（ＭＰＵ）ＮＭＳ－ｍｐｕと、当該プログラムをインストールしたり、プログラムの処理のために必要な情報を保持するＨａｒd Ｄｉｓｋ　Ｄｒｉｖｅ（ＨＤＤ）ＮＭＳ－ｈｄｄと、ＭＰＵ：ＮＭＳ-ｍｐｕの処理のためにこれらの情報を一時的に保持するメモリＮＭＳ－ｍｅｍと、オペレータＯＰが操作する監視端末ＭＴとの信号をやりとする入力部ＮＭＳ－ｉｎと出力部ＮＭＳ－ｏｕｔと、管理用ネットワークＭＮＷと接続するＮｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ（ＮＩＣ）ＮＭＳ－ｎｉｃとから構成される。
　さらに、ＨＤＤ：ＮＭＳ－ｈｄｄには、本実施例でネットワークＮＷを管理するために必要な情報として、パス構築テーブルＮＭＳ―ｔ１と、ユーザ管理テーブルＮＭＳ－ｔ２と、接続先管理テーブルＮＭＳ－ｔ３と、パス構成テーブルＮＭＳ－ｔ４と、リンク管理テーブルＮＭＳ－ｔ５とが保存されている。これらの情報は、オペレータＯＰから入力、変更されると共に、ネットワークＮＷの状態の変化やユーザ、アプリケーション提供事業者からの要求に応じて変更される。
　図３に、パス構築ポリシテ－ブルＮＭＳ－ｔ１の例を示す。パス構築ポリシテ－ブルＮＭＳ－ｔ１は、ＳＬＡ種別ＮＭＳ－ｔ１１を検索キーとして、通信品質ＮＭＳ－ｔ１２と、稼働率保証ＮＭＳ－ｔ１３と、パス構築ポリシＮＭＳ－ｔ１４とを示すテーブルエントリを検索するためのものである。
　ここで、ＳＬＡ種別ＮＭＳ－ｔ１１は、ビジネスユーザ向けの通信サービスや一般消費者向けの通信サービスを示し、ＳＬＡ種別ＮＭＳ－ｔ１１に応じて、通信品質ＮＭＳ－ｔ１２の保証の仕方（帯域保証や公平利用）や、稼働率保証ＮＭＳ－ｔ１３の有無やその基準値、そして集約や分散などのパスの構築ポリシＮＭＳ－ｔ１４が検索可能である。以降、ビジネスユーザ向け通信サービスを保証型サービス、一般消費者向け通信サービスを公平型サービスと称する。本テーブルの使用方法の詳細は後述する。
　図４に、ユーザ管理テ－ブルＮＭＳ－ｔ２の例を示す。ユーザ管理テ－ブルＮＭＳ－ｔ２は、ユーザＩＤ：ＮＭＳ－ｔ２１を検索キーとして、ＳＬＡ種別ＮＭＳ－ｔ２２と、収容パスＩＤ：ＮＭＳ－ｔ２３と、契約帯域ＮＭＳ－ｔ２４と、接続先ＮＭＳ－ｔ２５とを示すテーブルエントリを検索するためのものである。
　ここで、ユーザＩＤ：ＮＭＳ－ｔ２１は、ユーザアクセス装置ＡＥｎを介して接続された各サービス端末ＴＥｎを識別するもので、ユーザＩＤ：ＮＭＳ－ｔ２１毎に、ＳＬＡ種別ＮＭＳ－ｔ２２や、当該ユーザ端末ＴＥｎの収容パスＩＤ：ＮＭＳ－ｔ２３、ユーザ端末ＴＥｎ毎に割り当てられる契約帯域ＮＭＳ－ｔ２４、そしてそのユーザ端末ＴＥｎの接続先ＮＭＳ－ｔ２５が検索可能である。さらに、ここで収容パスＩＤ：ＮＭＳ－ｔ２３には、当該ユーザを収容するパスとして後述するパス構成テーブルＮＭＳ－ｔ４の検索キーであるパスＩＤ：ＮＭＳ－ｔ４１のいずれかが設定される。本テーブルの使用方法の詳細は後述する。
　図５に、接続先管理テ－ブルＮＭＳ－ｔ３の例を示す。接続先管理テ－ブルＮＭＳ－ｔ３は、接続先ＮＭＳ－ｔ３１と接続ポートＩＤ：ＮＭＳ－ｔ３２の組合せを検索キーとして、収容装置ＩＤ：ＮＭＳ－ｔ３３と、収容ポートＩＤ：ＮＭＳ－ｔ３４とを示すテーブルエントリを検索するためのものである。
　ここで、接続先ＮＭＳ－ｔ３１と接続ポートＩＤ：ＮＭＳ－ｔ３２は、ネットワークＮＷにとってトラヒックの送受信元となるポイントを示し、それらが収容されているネットワークＮＷのポイントである収容装置ＩＤ：ＮＭＳ－ｔ３３と収容ポートＩＤ：ＮＭＳ－ｔ３４が検索可能である。本テーブルの使用方法の詳細は後述する。
　図６に、パス構成テ－ブルＮＭＳ－ｔ４を示す。パス構成テ－ブルＮＭＳ－ｔ４は、パスＩＤ：ＮＭＳ－ｔ４１を検索キーとして、ＳＬＡ種別ＮＭＳ－ｔ４２と、終端装置ＩＤ：ＮＭＳ－ｔ４３と、経由装置ＩＤ：ＮＭＳ－ｔ４４と、経由リンクＩＤ：ＮＭＳ－ｔ４５と、ＬＳＰラベルＮＭＳ－ｔ４６、割当帯域ＮＭＳ－ｔ４７、収容ユーザＮＭＳ－ｔ４８とを示すテーブルエントリを検索するためのものである。
　ここで、パスＩＤ：ＮＭＳ－ｔ４１は、ネットワークＮＷ中のパスを統一的に識別するもので、実際にパケットに付与されるＬＳＰラベルとは異なり、通信の双方で同一となるような管理上の値である。このパスＩＤ：ＮＭＳ－ｔ４１毎に、ＳＬＡ種別ＮＭＳ－ｔ４２や、当該パスの終端装置ＩＤ：ＮＭＳ－ｔ４３と経由装置ＩＤ：ＮＭＳ－ｔ４４、経由リンクＩＤ：ＮＭＳ－ｔ４５、ＬＳＰラベルＮＭＳ－ｔ４６が設定されている。
　そして、当該パスのＳＬＡ種別ＮＭＳ－ｔ４２が保証型サービス（図６の例ではＳＬＡ＃１）を示す場合、収容ユーザＮＭＳ－ｔ４８に記載されている全ユーザの契約帯域の積算値が割当帯域ＮＭＳ－ｔ４７に設定されている。
　一方、当該パスが公平型サービス（図６の例ではＳＬＡ＃２）のパスであれば、収容ユーザＮＭＳ－ｔ４８として当該パスに収容されている全ユーザが同様に設定され、割当帯域ＮＭＳ－ｔ４７には無効値が設定されている。
　さらに、上記ＬＳＰラベルＮＭＳ－ｔ４６は、実際にパケットに付与されるＬＳＰラベルであり、通信の向き毎に異なる値が設定される。一般的に、通信装置ＮＤ＃ｎを中継する毎に異なるＬＳＰラベルを設定することも可能であるが、本実施例では簡単のため、中継する毎にＬＳＰラベルを変更せず、ネットワークのエッジ装置間で同一のＬＳＰラベルを用いるものとする。本テーブルの使用方法の詳細は後述する。
　図７に、リンク管理テ－ブルＮＭＳ－ｔ５を示す。リンク管理テ－ブルＮＭＳ－ｔ５は、リンクＩＤ：ＮＭＳ－ｔ５１を検索キーとして、空き帯域ＮＭＳ－ｔ５２と、透過非優先ユーザ数ＮＭＳ－ｔ５３とを示すテーブルエントリを検索するためのものである。
　ここで、リンクＩＤ：ＮＭＳ－ｔ５１は、各通信装置間のポート同士の接続関係を示すもので、各リンクの両端の通信装置ＮＤ＃ｎのＩＤとそのポートＩＤの組合せになっている。例えば、通信装置ＮＤ＃１のポートＰＴ＃２と、通信装置ＮＤ＃３のポートＰＴ＃４が接続され、一つのリンクを形成している場合のリンクＩＤ：ＮＭＳ－ｔ５１は「ＬＮＫ＃Ｎ１－２－Ｎ３－４」となる。ここで、同じリンクＩＤで構成されているパス、すなわち送信ポートと宛先ポートの組合せが同一のパスは、同一経路のパスである。
　当該リンクＩＤ：ＮＭＳ－ｔ５１毎に、当該リンクの物理帯域から、当該リンクを経由するパスの契約帯域の総和を減算したものが空き帯域：ＮＭＳ－ｔ５２として保持され、当該リンクを経由する公平型サービスのパス上のユーザ数が透過非優先ユーザ数ＮＭＳ－ｔ５３として保持され、検索可能である。本テーブルの使用方法の詳細は後述する。
　図８～図１０で、本実施例で用いるパケットのフォーマットを説明する。
　図８は、本実施例において、エッジ装置ＮＤ＃１およびＮＤ＃ｎがアクセス装置ＡＥ＃１～ｎ、データセンタＤＣおよびインタネットＩＮから受信する通信パケット４０のフォーマットを示す。
　通信パケット４０は、宛先ＭＡＣアドレス４０１、送信元ＭＡＣアドレス４０２、ＶＬＡＮタグ４０３、後続ヘッダの種類を示すタイプ値４０４からなるＭＡＣヘッダと、ペイロード部４０５と、パケットチェックシーケンス（ＦＣＳ）４０６とからなる。
　宛先ＭＡＣアドレス４０１と送信元ＭＡＣアドレス４０２には、ユーザ端末ＴＥ１～ｎ、データセンタＤＣまたはインタネットＩＮのいずれかに付与されたＭＡＣアドレスが格納される。ＶＬＡＮタグ４０３は、フロー識別子となるＶＬＡＮ ＩＤの値（ＶＩＤ♯）と優先度を示すＣｏＳ値が格納されている。
　図９は、各通信装置ＮＤ＃ｎがネットワークＮＷ内で送受信する通信パケット４１のフォーマットを示す。本実施例では、ＭＰＬＳを用いてイーサネットを収容する際に使用されるＰｓｕｄｏ　Ｗｉｒｅ（ＰＷ）フォーマットを想定している。
　通信パケット４１は、宛先ＭＡＣアドレス４１１、送信元ＭＡＣアドレス４１２、後続ヘッダの種類を示すタイプ値４１３からなるＭＡＣヘッダと、ＭＰＬＳラベル（ＬＳＰラベル）４１４－１と、ＭＰＬＳラベル（ＰＷラベル）４１４－２と、ペイロード部４１５と、ＦＣＳ：４１６とからなる。
　ＭＰＬＳラベル４１４－１および４１４－２は、パス識別子となるラベル値と優先度を示すＴＣ値が格納されている。
　ペイロード部４１５は、図４に示した通信パケット４０のイーサパケットがカプセル化されている場合と、各通信装置ＮＤ＃ｎが生成したＯＡＭに関する情報が格納されている場合がある。本フォーマットは、ＭＰＬＳラベル２段を有しており、１段目のＭＰＬＳラベル（ＬＳＰラベル）４１４－１はネットワークＮＷ内のパスを指定する識別子であり、２段目のＭＰＬＳラベル（ＰＷラベル）４１４－２はユーザまたはＯＡＭパケットであることを識別するために用いられる。ここで、２段目のＭＰＬＳラベル４１４－２のラベル値が予約値である“１３”などを有している場合それはＯＡＭパケット、それ以外はユーザパケット（ペイロード４１５に通信パケット４０のイーサパケットがカプセル化されている）である。
　図１０は、通信装置ＮＤ＃ｎがネットワークＮＷ内で送受信するＯＡＭパケット４２のフォーマットを示す。
　ＯＡＭパケット４２は、宛先ＭＡＣアドレス４２１、送信元ＭＡＣアドレス４２２、後続ヘッダの種類を示すタイプ値４２３からなるＭＡＣヘッダと、通信パケット４１と同様の１段目のＭＰＬＳラベル（ＬＳＰラベル）４１４－１と、２段目のＭＰＬＳラベル（ＯＡＭラベル）４１４－３と、ＯＡＭ種別４２４と、ペイロード４２５と、ＦＣＳ４２６とからなる。
　上述した通り、２段目のＭＰＬＳラベル（ＯＡＭラベル）４１４－３は、図９の２段目のＭＰＬＳラベル（ＰＷラベル）４１４－２のラベル値が予約値である“１３”などを有している場合であり、ここではＯＡＭラベルと称しているが、上記２段目のＭＰＬＳラベル（ＰＷラベル）４１４－２とラベル値以外は同一である。さらに、ＯＡＭ種別４２４は、ＯＡＭパケットの種類を示す識別子であり、本実施例では障害監視パケットまたは折返し試験パケット（折返し要求パケットまたは折返し応答パケット）の識別子が格納される。ペイロード４２５は、ＯＡＭ専用の情報が格納されており、本実施例では、障害監視パケットの場合は終端装置ＩＤ、折返し要求パケットの場合は折返し装置ＩＤ、折返し応答パケットの場合は終端装置ＩＤが格納される。
　図１１は、通信装置ＮＤ＃ｎの構成を示す。通信装置ＮＤ＃ｎは、複数のネットワークインタフェースボード（ＮＩＦ）１０（１０－１～１０－ｎ）と、これらのＮＩＦに接続されたスイッチ部１１、装置全体を管理する装置管理部１２からなる。
　各ＮＩＦ１０は、通信ポートとなる複数の入出力回線インタフェース１０１（１０１－１～１０１－ｎ）を備え、これらの通信ポートを介して、その他の装置と接続されている。本実施例では、入出力回線インタフェース１０１は、イーサネット用の回線インタフェースとなっている。尚、入出力回線インタフェース１０１は、イーサネット用の回線インタフェースに限られない。
　各ＮＩＦ：１０－ｎは、これらの入出力回線インタフェース１０１に接続された入力パケット処理部１０３と、スイッチ部１１に接続された複数のＳＷインタフェース１０２（１０２－１～１０２－ｎ）と、これらのＳＷインタフェースに接続された出力パケット処理部１０４と、ＯＡＭ関連の処理を行う障害管理部１０７と、ＮＩＦを管理するＮＩＦ管理部１０５と、各種設定を保持する設定レジスタ１０６とを有する。
　ここで、ＳＷインタフェース１０２－ｉは、入出力回線インタフェース１０１－ｉと対応しており、入出力回線インタフェース１０１－ｉで受信した入力パケットは、ＳＷインタフェース１０２－ｉを介してスイッチ部１１に転送される。また、スイッチ部１１からＳＷインタフェース１０２－ｉに振り分けられた出力パケットは、入出力回線インタフェース１０１－ｉを介して、出力回線に送出される。このため、入力パケット処理部１０３、出力パケット処理部１０４は、回線毎に独立な構造となっており、各回線のパケットが混ざり合うことはない。
　入出力回線インタフェース１０１－ｉは、入力回線から通信パケット４０または４１を受信すると、受信パケットに、図１２に示す装置内ヘッダ４５を付加する。
　図１２～図１７で、通信装置ＮＤ＃ｎが保持する各テーブルと、装置内のパケットのフォーマットを説明する。
　図１２は、装置内ヘッダ４５の例を示す。装置内ヘッダ４５は、コネクションＩＤ：４５１と、受信ポートＩＤ：４５２と、優先度４５３と、パケット長４５４とを示す複数のフィールドとからなっている。
　図１１の入出力回線インタフェース１０１－ｉが、受信パケットに装置内ヘッダ４５を付加した時点では、設定レジスタ１０６から取得したポートのＩＤを受信ポートＩＤ：４５２に格納すると共に、本パケットの長さをカウントし、パケット長４５４として格納する。一方、コネクションＩＤ：４５１と優先度４５３は空欄となっている。このフィールドには、入力パケット処理部１０３によって有効値が設定される。
　入力パケット処理部１０３は、後述する入力パケット処理Ｓ１００を実施して、下記の各テ－ブル２１～２４を参照し、各入力パケットの装置内ヘッダ４５にコネクションＩＤ：４５１および優先度４５３を追加するとともに、その他ヘッダ処理、帯域監視処理などが実施される。入力パケット処理Ｓ１００の結果、入力パケットは、ＳＷ　ＩＦ：１０２に回線毎に振り分けられ転送される。
　図１３に、コネクションＩＤ決定テ－ブル２１を示す。コネクションＩＤ決定テーブル２１は、入力ポートＩＤ：２１２と、ＶＬＡＮ ＩＤ：２１３との組合わせを検索キーとして、その登録アドレスであるコネクションＩＤ：２１１を取得するためのものである。通常このようなテーブルは、ＣＡＭ（Ｃｏｎｔｅｎｔ－ａｄｄｒｅｓｓａｂｌｅ　ｍｅｍｏｒｙ）で構成される。ここで、コネクションＩＤ：２１１は、本通信装置ＮＤ＃ｎにおいて各コネクションを特定するＩＤであり、双方向で同じＩＤを使用する。本テーブルの使用方法の詳細は後述する。
　図１４に、入力ヘッダ処理テ－ブル２２を示す。入力ヘッダ処理テーブル２２は、コネクションＩＤ：２２１を検索キーとして、ＶＬＡＮタグ処理２２２と、ＶＬＡＮタグ２２３とを示すテーブルエントリを検索するためのものである。ここで、ＶＬＡＮタグ処理２２２は、入力パケットに対するＶＬＡＮタグ処理を指定し、それに必要なタグ情報がＶＬＡＮタグ２２３に設定される。本テーブルの使用方法の詳細は後述する。
　図１５に、ラベル設定テ－ブル２３を示す。ラベル設定テ－ブル２３は、コネクションＩＤ：２３１を検索キーとして、ＬＳＰラベル２３２と、ＰＷラベル２３３とを示すテーブルエントリを検索するためのものである。本テーブルの使用方法の詳細は後述する。
　図１６に、帯域監視テ－ブル２４を示す。帯域監視テ－ブル２４は、コネクションＩＤ：２４１を検索キーとして、契約帯域２４２と、バケツの深さ２４３と、前回のトークン値２４４と、前回時刻２４５とを示すテーブルエントリを検索するためのものである。
　ここで、保証型サービスの場合、契約帯域２４２には、ユーザ毎の契約帯域と同値が設定され、一般的なトークンバケツアルゴリズムによって契約帯域内のパケットに関しては装置内ヘッダ４５の優先度４５３に高優先を上書きされ、契約帯域を超過したと判定されたパケットに関しては廃棄される。一方、公平型サービスの場合、契約帯域２４２には無効値が設定され、全パケットの装置内ヘッダ４５の優先度４５３に低優先が上書きされる。
　スイッチ部１１は、各ＮＩＦのＳＷインタフェース１０２－１～１０２－ｎから入力パケットを受け取り、パケット転送テーブル２６から出力ポートＩＤと出力ラベルを特定し、対応するＳＷインタフェース１０２－iに、出力パケットとして転送する。この際、ＭＰＬＳラベル４１４－１の優先度を示すＴＣに従って、輻輳時には優先度の高いパケットを優先的に転送する。さらに、付与されているＭＰＬＳラベル（ＬＳＰラベル）４１４－１に出力ラベル２７６を上書きする。
　図１７にパケット転送テーブル２６を示す。パケット転送テーブル２６は、入力ポートＩＤ：２６１と入力ＬＳＰラベル２６２の組合せを検索キーとして、出力ポートＩＤ：２６３と出力ＬＳＰラベル２６４とを示すテーブルエントリを検索するためのものである。
　スイッチ部１１は、装置内ヘッダ４５の受信ポートＩＤ：４５１および入力パケットのＭＰＬＳラベル（ＬＳＰラベル）４１４－１のＬＳＰ　ＩＤを用いてパケット転送テーブル２６を検索し、出力先を決定する。
　各ＳＷインタフェース１０２が受信した出力パケットは、次々と出力パケット処理部１０４に供給される。
　出力パケット処理部１０４は、設定レジスタ１０６に当該ＮＩＦ：１０―ｎの処理モードがイーサネット処理モードと設定してある場合には、出力パケットの宛先ＭＡＣアドレス４１１と、送信元ＭＡＣアドレス４１２と、タイプ値４１３と、ＭＰＬＳラベル（ＬＳＰラベル）４１４－１と、ＭＰＬＳラベル（ＰＷラベル）４１４－２とを削除し、対応する入出力回線インタフェース１０１－ｉにパケットを出力する。
　一方、設定レジスタ１０６に当該ＮＩＦ：１０―ｎの処理モードがＭＰＬＳ処理モードと設定されている場合には、パケット処理を行うことなくそのまま対応する入出力回線インタフェース１０１－ｉにパケットを出力する。
　図１８は、通信装置ＮＤ＃ｎの入力パケット処理部１０３が実行する入力パケット処理Ｓ１００のフローチャートを示している。このような処理は、通信装置ＮＤ＃ｎがマイクロコンピュータのようなハードウェア資源を備え、ハードウェア資源をソフトウェアによる情報処理が利用することにより当該処理を実行することができる。
　入力パケット処理部１０３は、設定レジスタ１０６に設定されている当該ＮＩＦ：１０―ｎの処理モードを判定する（Ｓ１０１）。
　イーサネット処理モードと設定されている場合には、装置内ヘッダ４５とＶＬＡＮタグ４０３から各情報を抽出し、抽出した受信ポートＩＤ：４５２とＶＩＤを用いて、コネクションＩＤ決定テーブル２１を検索し、当該パケットのコネクションＩＤ：２１１を特定する（Ｓ１０２）。
　次に、コネクションＩＤ：２１１を装置内ヘッダ：４５に書き込み、入力ヘッダ処理テーブル２２及びラベル設定テーブル２３を検索し、エントリ内容を取得する（Ｓ１０３）。
　次に、入力ヘッダ処理テーブル２２の内容に従ってＶＬＡＮタグ４０３を編集する（Ｓ１０４）。
　次に、コネクションＩＤ：２１１（ここではユーザ）毎の帯域監視処理を行い、装置内ヘッダ（図１２、４５）の優先度４５３を追加する（Ｓ１０５）。
　通信パケット（図９，４１）において、宛先ＭＡＣアドレス４１１と送信元ＭＡＣアドレス４１２に設定レジスタ１０６の設定値、タイプ値４１３にＭＰＬＳであることを示す“８８４７”（１６進数）、ＭＰＬＳラベル（ＬＳＰラベル）４１４－１としてラベル設定テーブル２３のＬＳＰラベル２３２、ＭＰＬＳラベル（ＰＷラベル）４１４－２のラベル値としてラベル設定テーブル２３のＰＷラベル２３３、ＴＣとして装置内ヘッダ４５の優先度４５３を付与する。
　その後、パケットを転送し（Ｓ１０６）、処理を終了する（Ｓ１１１）。
　一方、上記Ｓ１０１において、ＭＰＬＳ処理モードと設定されている場合には、通信パケット４１において、２段目のＭＰＬＳラベル４１４－２が予約値（“１３”）であるかを判定し（Ｓ１０７）、予約値でない場合は、ユーザパケットとして当該パケットをそのまま転送し（Ｓ１０８）、処理を終了する（Ｓ１１１）。
　一方、上記Ｓ１０７において、予約値である場合、ＯＡＭパケットと判定し、当該パケットのペイロード４２５の装置ＩＤが設定レジスタ１０６に設定されている自装置ＩＤと一致するかを判定し（Ｓ１０９）、一致しない場合、透過ＯＡＭパケットとして、上記ユーザパケットと同様にＳ１０８以降の処理を実行する。
　一方、上記Ｓ１０９において、一致する場合、当該装置で終端するＯＡＭパケットと判定し、当該パケットを障害管理部１０７へ転送し（Ｓ１１０）、処理を終了する（Ｓ１１１）。
　図１９に、障害管理テ－ブル２５を示す。障害管理テ－ブル２５は、パスＩＤ：２５１を検索キーとして、ＳＬＡ種別２５２と、終端装置ＩＤ：２５３と、経由装置ＩＤ：２５４と、経由リンクＩＤ：２５５と、ＬＳＰラベル値２５６と、障害発生有無２５７とを示すテーブルエントリを検索するためのものである。
　ここで、パスＩＤ：２５１、ＳＬＡ種別２５２、終端装置ＩＤ：２５３、経由装置ＩＤ：２５４、経由リンクＩＤ：２５５、ＬＳＰラベル値２５６は、パス構成テーブルＮＭＳ－ｔ４のパスＩＤ：ＮＭＳ－ｔ４１、ＳＬＡ種別ＮＭＳ－ｔ４２、終端装置ＩＤ：ＮＭＳ－ｔ４３、経由装置ＩＤ：ＮＭＳ－ｔ４４、経由リンクＩＤ：ＮＭＳ－ｔ４５、ＬＳＰラベル値ＮＭＳ－ｔ４６とそれぞれ同様である。
　障害発生有無２５７は、当該パスで障害が発生しているかどうかを示す情報であり、これをＮＩＦ管理部１０５が後述する障害管理テーブルポーリング処理で読出し、ＳＬＡ種別２５２に応じて優先度を判定し、装置管理部１２に通知する。装置管理部１２が障害通知キュー読出し処理Ｓ４００により、装置全体でのＳＬＡ種別２５２に応じた優先度を判定を実施し、最終的にネットワーク管理システムＮＭＳに通知される。本テーブルの使用方法の詳細は後述する。
　障害管理部１０７は、上記障害管理テーブル２５に追加されたパス２５１に対して、障害監視パケットを定期的に送信する。本障害監視パケットには、ＬＳＰラベル４１４－１としてＬＳＰラベル値２５６、ＯＡＭ種別４２４として障害監視パケットを示す識別子、ペイロード４２５に対向の終端装置ＩＤ：ＮＤ＃ｎ、その他の領域には設定レジスタ１０６の設定値が格納される（図１０参照）。　障害管理部１０７は、一定期間当該パスに障害監視パケットが到着しない場合は、障害管理テーブル２５の障害発生有無２５６に障害発生として「有」を上書きする。
　障害管理部１０７は、上記入力パケット処理部１０３から自装置宛のＯＡＭパケットを受信すると、ペイロード４２５のＯＡＭ種別４２４をチェックし、当該パケットが障害監視パケットか折返し試験パケット（折返し要求パケットまたは折返し応答パケット）かを判定し、障害監視パケットであった場合には、障害管理テーブル２５の障害発生有無２５６に障害復旧として「無」を上書きする。
　障害管理部１０７は、後述する折返し試験において、ネットワーク管理システムから指定されたパスに対して、折返し試験を実施するため、ＬＳＰラベル４１４－１として後述するようにネットワーク管理システムから指定された試験対象パスＩＤ：ＮＭＳ－ｔ４１のＬＳＰラベル２５６、ＯＡＭ種別４２４に本パケットが折返し要求パケットであることを示す識別子、ペイロード４２５に折返し対象となる経由装置ＩＤ：ＮＭＳ－ｔ４４、その他の領域には設定レジスタ１０６の設定値を用いて折返し要求パケットを生成し、送信する。
　障害管理部１０７は、上記入力パケット処理部１０３から自装置宛のＯＡＭパケットを受信すると、ペイロード４２５のＯＡＭ種別４２４をチェックし、折返し要求パケットと判断された場合には、ＬＳＰラベル４１４－１として受信した方向とは逆方向のＬＳＰラベル値２５６、ＯＡＭ種別４２４に折返し応答パケットであることを示す識別子、ペイロード４２５に折返し対象となる終端装置ＩＤ：２５３、その他の領域には設定レジスタ１０６の設定値を用いて折返し応答パケットを返送する。
　一方、上記において折返し応答パケットと判断された場合には、折返し試験成功となるため、その旨ＮＩＦ管理部１０５と装置管理部１２を介してネットワーク管理システムＮＭＳに通知する。
　図２０は、オペレータＯＰからネットワークＮＷを設定する際のシーケンスＳＱ１００を示す。
　オペレータＯＰが設定変更として、本変更の要求種別（ユーザ新規追加または削除。設定変更する場合は、オペレータが削除後に新規追加を実施）、ユーザＩＤ、接続先（例えば、アクセス装置＃１とデータセンタＤＣの組合せ）、サービス種別そして変更後の契約帯域を送信する（ＳＱ１０１）。
　設定変更を受信したネットワーク管理システムＮＭＳは、後述するサービスに応じたパス検索処理Ｓ２０００により、パス構築ポリシテーブルＮＭＳ－ｔ１などを参照することでサービスのＳＬＡに応じてパスの構築ポリシを変更し、接続先管理テーブルＮＭＳ－ｔ３やリンク管理テーブルＮＭＳ－ｔ５を利用してパスを検索する。その結果を対応する通信装置ＮＤ＃１～ｎに設定する（ＳＱ１０２－１～ｎ）。
　本設定情報としては、前述したコネクションＩＤ決定テーブル２１、入力ヘッダ処理テーブル２２、ラベル設定テーブル２３、帯域監視テーブル２４、障害管理テーブル２５、そしてパケット転送テーブル２６などの各ユーザやパスの接続関係や帯域設定が含まれる。これらの情報が各通信装置ＮＤ＃ｎに設定されると、ユーザからのトラヒックが設定した経路通りに送受信可能となると共に、パスの終端点となるエッジ装置ＮＤ＃1およびＮＤ＃ｎ間で、障害監視パケットの定期的な送受信が開始される（ＳＱ１０３－１、ＳＱ１０３－ｎ）。
　以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知がオペレータＯＰに送信され（ＳＱ１０４）、本シーケンスが終了となる。
　図２１は、ユーザ端末ＴＥｎからの要求によりネットワークＮＷを設定する際のシーケンスＳＱ２００を示す。
　ここでは、ユーザからネットワークＮＷの変更が必要となるようなサービス要求を通信事業者が受け付ける手段として、通信事業者が提供するホームページなどを提供するサーバがインタネットＩＮの中に設置されているケースを想定している。仮に、本ネットワークＮＷにおいてインタネットＩＮへの接続性を有しないユーザの場合、他の代替手段、例えばスマートフォンや自宅、または会社で有しているいずれかからインタネットにアクセスすることが可能な手段を有しているとする。
　ユーザ端末ＴＥｎからサービス要求が発生すると（ＳＱ２０１）、それを受信したインタネットＩＮの中に設置されたサーバは、それをネットワークＮＷの設定情報に変換し（ＳＱ２０２）、当該設定変更を管理用ネットワークＭＮＷを介してネットワーク管理システムＮＭＳに送信する（ＳＱ２０３）。
　それ以降のサービスに応じたパス検索処理Ｓ２０００、通信装置ＮＤ＃ｎへの設定（ＳＱ１０２）、監視パケットによる常時監視の開始（ＳＱ１０３）の処理はＳＱ１００(図２０）と同様である。以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知が管理用ネットワークＭＮＷを介してインタネットＩＮ上のサーバに送信され（ＳＱ１０４）、さらにそれがユーザ端末ＴＥｎまで通知され（ＳＱ２０５）、本シーケンスが終了となる。
　図２２は、データセンタＤＣからの要求によりネットワークＮＷを設定する際のシーケンスＳＱ３００を示す。
　データセンタＤＣから管理用ネットワークＭＮＷを介して設定変更の要求が発信されると（ＳＱ３０１）、当該設定変更を処理する。
　それ以降のサービスに応じたパス検索処理Ｓ２０００、通信装置ＮＤ＃ｎへの設定（ＳＱ１０２）、監視パケットによる常時監視の開始（ＳＱ１０３）の処理はＳＱ１００(図２０）と同様である。
　以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知が管理用ネットワークＭＮＷを介してデータセンタＤＣに通知され（ＳＱ３０２）、本シーケンスが終了となる。
　図２３は、中継装置ＮＤ＃３において障害が発生した場合の、故障個所特定シーケンスＳＱ４００を示す。
　中継装置ＮＤ＃３で通信断が発生するような障害が発生すると、エッジ装置ＮＤ＃１とＮＤ＃ｎの間で定期的に送受信している障害監視パケットが到着しなくなる（ＳＱ４０１－１，ＳＱ４０１－ｎ）。
　この結果、各エッジ装置ＮＤ＃１及びＮＤ＃ｎは、保証型サービスのパスＰＴＨ＃１において障害が発生したことを検出する（ＳＱ４０２－１、ＳＱ４０２－ｎ）。
　この結果、各エッジ装置ＮＤ＃１及びＮＤ＃ｎは、後述する障害通知処理Ｓ３０００を実施し、保証型サービスのパスＰＴＨ＃１の障害を優先的にネットワーク管理システムＮＭＳへ通知する（ＳＱ４０３－１、ＳＱ４０３－ｎ）。
　これを受信したネットワーク管理システムＮＭＳは、保証型サービスのパスＰＴＨ＃１で障害が発生した旨の通知をオペレータＯＰに通知すると共に（ＳＱ４０４）、以下の障害箇所判定処理（ＳＱ４０５）を自動実行する。
　まず、ネットワーク管理システムＮＭＳは、エッジ装置ＮＤ＃１とそれと隣接する中継装置ＮＤ＃２間の正常性を確認するため、折返し試験要求とそのために必要な情報（試験対象パスＩＤ：ＮＭＳ－ｔ４１、折返し対象となる経由装置ＩＤ：ＮＭＳ－ｔ４４）をエッジ装置ＮＤ＃１に対して通知する（ＳＱ４０５１－１）。
　その要求を受け、エッジ装置ＮＤ＃１は、前述の通り折返し要求パケットを送信する（ＳＱ４０５１－１ｒｅｑ）。
　本折り返し試験パケットを受信した中継装置ＮＤ＃２は、自装置宛の折返し試験であるため、上述の通り折返し応答パケットを返送する（ＳＱ４０５１－１ｒｐｙ）。
　当該折返し応答パケットを受信したエッジ装置ＮＤ＃１は、折返し試験成功通知をネットワーク管理システムＮＭＳに通知する（ＳＱ４０５１－１ｓｕｃ）。
　当該折返し試験成功通知を受信したネットワーク管理システムＮＭＳは、障害箇所を特定するため、中継装置ＮＤ＃３との正常性を確認するため、折返し試験要求とそのために必要な情報をエッジ装置ＮＤ＃１に対して通知する（ＳＱ４０５１－２）。
　その要求を受け、エッジ装置ＮＤ＃１は、前述の通り折返し要求パケットを送信する（ＳＱ４０５１－２ｒｅｑ）。
　本折り返し試験パケットは、中継装置ＮＤ＃３が故障しているため、エッジ装置ＮＤ＃１には返送されない（ＳＱ４０５１－２ｄｅｆ）。
　エッジ装置ＮＤ＃１は、一定時間内に折返し応答パケットが返送されないため、折返し試験失敗通知をネットワーク管理システムＮＭＳに通知する（ＳＱ４０５１－２ｆａｉｌ）。
　当該折返し試験失敗通知を受信したネットワーク管理システムＮＭＳは、障害箇所を中継装置ＮＤ＃３と特定し（ＳＱ４０５２）、その情報をオペレータＯＰに障害箇所として通知し（ＳＱ４０５３）、本シーケンスが終了となる。
　図２４、２５は、ネットワーク管理システムＮＭＳが実行する、サービスに応じたパス検索処理Ｓ２０００を示す。このような処理は、ネットワーク管理システムＮＭＳが図２に示したハードウェア資源を備え、ハードウェア資源をソフトウェアによる情報処理が利用することにより、当該処理を実現することができる。
　オペレータＯＰ、あるいは、インタネットＩＮまたはデータセンタＤＣから設定変更を受信したネットワーク管理システムＮＭＳは、設定変更として要求種別、接続先、ＳＬＡ種別、及び契約帯域を取得し（Ｓ２０１）、取得した要求種別をチェック（Ｓ２０２）する。
　要求種別が、削除であれば、該当するユーザ管理テーブルＮＭＳ－ｔ２(図４）から該当エントリを削除し、当該ユーザの収容パスＮＭＳ－ｔ２３に該当するパス構成テーブルＮＭＳ－ｔ４(図６）のエントリの情報を更新する。
　更新の内容が、保証型サービスであれば、パス構成テーブルＮＭＳ－ｔ４(図６）の割当帯域ＮＭＳ－ｔ４７から、ユーザ管理テーブルＮＭＳ－ｔ２(図４）の契約帯域ＮＭＳ－ｔ２４を減算し、収容ユーザＮＭＳ－ｔ４８から当該ユーザＩＤを削除する。また、公平型サービスであれば、収容ユーザＮＭＳ－ｔ４８から当該ユーザＩＤを削除する。
　そして、リンク管理テーブルＮＭＳ－ｔ５(図７）の内、パス構成テーブルＮＭＳ－ｔ４(図６）の経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新する。更新の内容が、保証型サービスであれば、空き帯域ＮＭＳ－ｔ５２から契約帯域ＮＭＳ－ｔ２４を減算する。公平型サービスであれば、透過非優先ユーザ数ＮＭＳ－ｔ５３を１減算する。そして、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知し（Ｓ２１１）、処理を終了する（Ｓ２１６）。
　上記Ｓ２０２において、新規追加であった場合、当該接続先の情報を用いて接続先管理テーブルＮＭＳ－ｔ３(図５）を検索し、接続先となり得るポイントとして収容装置（ノード）ＩＤ：ＮＭＳ－ｔ３３と収容ポートＩＤ：ＮＭＳ－ｔ３４の組合せの候補を抽出する（Ｓ２０３）。例えば、図１でアクセス装置ＡＥ＃１を始点としてデータセンタＤＣを終点として指定された場合、その候補は以下となる。
　始点ポート候補：
（１）収容装置ＩＤ：ＮＤ＃１の収容ポートＩＤ：ＰＴ＃１
　終点ポート候補：
（Ａ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１０
（Ｂ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１１
　ここで、始点ポート候補と終点ポート候補間のパスを検索する必要があることを意味する。つまり、この場合、（１）－（Ａ）間および（１）－（Ｂ）間のパスが候補となる。
　続いて、上記Ｓ２０１で取得したＳＬＡ種別をチェックし（Ｓ２０４）、保証型であれば、リンク管理テーブルＮＭＳ－ｔ５(図７）を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、指定された契約帯域分の空き帯域が存在し、かつその空き帯域が最小の経路を検索する（Ｓ２０５）。具体的には、例えば、リンク管理テーブルＮＭＳ－ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では空き帯域）が最も少ない経路が選択されることで、保証型サービスのパスは既存パスに集約することが可能となる。なお、コストが最小の経路ではなく、コストが所定閾値以下の経路をランダムに選択する等の方法でも、ある程度の集約効果が得られる。閾値は絶対的な数値を規定する閾値でもよいし、相対的な（例えば下位１０％）規定による閾値でもよい。
　続いて、上記Ｓ２０５の結果、条件に合致する経路があるかを判定する（Ｓ２０６）。
　判定の結果該当経路がなければ経路なしとしてオペレータに通知し（Ｓ２０７）、処理を終了する（Ｓ２１６）。
　一方、上記Ｓ２０６において、該当経路があれば、パス構成テーブルＮＭＳ－ｔ４を利用し、当該経路が既存パスの経路かどうか判定する（Ｓ２０８）。
　既存パスの経路があれば、ユーザ管理テーブルＮＭＳ－ｔ２に新規エントリを追加し、既存パスを収容パスＮＭＳ－ｔ２３に設定する。また、該当するパス構成テーブルＮＭＳ－ｔ４のエントリの情報を更新（割当帯域ＮＭＳ－ｔ４７に契約帯域ＮＭＳ－ｔ２４を加算し、収容ユーザＮＭＳ－ｔ４８に新規ユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新（空き帯域ＮＭＳ－ｔ５２に契約帯域ＮＭＳ－ｔ２４を加算）する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知し（Ｓ２０９）、処理を終了する（Ｓ２１６）。
　一方、上記Ｓ２０８において、既存パスの経路がなければ、ユーザ管理テーブルＮＭＳ－ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ－ｔ２３に設定する。また、パス構成テーブルＮＭＳ－ｔ４に新規エントリを追加（割当帯域ＮＭＳ－ｔ４７に契約帯域ＮＭＳ－ｔ２４を設定し、収容ユーザＮＭＳ－ｔ４８に新規ユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新（空き帯域ＮＭＳ－ｔ５２に契約帯域ＮＭＳ－ｔ２４を加算）する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知し（Ｓ２１０）、処理を終了する（Ｓ２１６）。
　以上の処理によると、図１のＰＴＨ＃１に示すように、保証型のサービスでは、通信ネットワーク上の送信ポートと宛先ポートが同じ経路を有する複数パスは、通信パス同士が集約されていく。このとき、図１のように、エッジ装置ＮＤ＃1およびＮＤ＃ｎ間でネットワーク上の送信ポートと宛先ポートが全く同一の経路を集約できれば理想的であるが、エッジ間の経路の一部のみを集約してもよい。保証型の通信パスを集約することにより、重点的に保守管理すべき物理的範囲を限定することができ、保守点検作業のリソースを集中することができる。
　図２５は、上記Ｓ２０４において、公平型と判断された場合の処理を示す。上記Ｓ２０４において、公平型と判断された場合には、リンク管理テーブルＮＭＳ－ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、“空き帯域ＮＭＳ－ｔ５２÷透過非優先ユーザ数ＮＭＳ－ｔ５３”が最大の経路を検索する（Ｓ２１２）。
　具体的には、例えば、リンク管理テーブルＮＭＳ－ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では“空き帯域ＮＭＳ－ｔ５２÷透過非優先ユーザ数ＮＭＳ－ｔ５３”）が最も大きい経路が選択されることで、公平型サービスは既存パスの中で分散される。なお、値が最大の経路ではなく、値が所定閾値以上の経路をランダムに選択する等の方法でも、ある程度の分散効果が得られる。閾値は絶対的な数値を規定する閾値でもよいし、相対的な（例えば上位１０％）規定による閾値でもよい。
　続いて、上記Ｓ２１２の後、パス構成テーブルＮＭＳ－ｔ４を利用し、得られた経路が既存パスの経路かどうか判定する（Ｓ２１３）。
　既存パスの経路があれば、ユーザ管理テーブルＮＭＳ－ｔ２に新規エントリを追加し、既存パスを収容パスＮＭＳ－ｔ２３に設定し、該当するパス構成テーブルＮＭＳ－ｔ４のエントリの情報を更新する。具体的には、収容ユーザＮＭＳ－ｔ４８に新規ユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新する。具体的には、透過非優先ユーザ数ＮＭＳ－ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知し（Ｓ２１４）、処理を終了する（Ｓ２１６）。
　一方、上記Ｓ２１３において、既存パスの経路がなければ、ユーザ管理テーブルＮＭＳ－ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ－ｔ２３に設定する。また、パス構成テーブルＮＭＳ－ｔ４に新規エントリを追加する。具体的には、収容ユーザＮＭＳ－ｔ４８に新規ユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新する。具体的には、透過非優先ユーザ数ＮＭＳ－ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知し（Ｓ２１５）、処理を終了する（Ｓ２１６）。
　以上の処理によると、図１のＰＴＨ＃２、ＰＴＨ＃ｎに示すように、公平型のサービスでは、保証型のサービスの空き帯域に、通信パスが分散されて配置される。
　このように、保証型サービスのパスは同一経路に集約し、公平型サービスのパスは収容ユーザ数の比率に応じて分散させることが可能となる。
　図２６は、通信装置ＮＤ＃ｎのＮＩＦ管理部１０５が実行する障害通知処理（図２３、Ｓ３０００）における、障害管理テーブルポーリング処理Ｓ３００の詳細を示す。
　ＮＩＦ管理部１０５は、装置の電源投入と同時に、本ポーリング処理を開始し、変数ｉを“０”に初期化し（Ｓ３０１）、変数ｉに１を加算する（Ｓ３０２）。
　次に、障害管理テーブル２５（図１９）のパスＩＤ：２５１をＰＴＨ＃ｉとして検索し、エントリを取得する（Ｓ３０３）。
　次に、当該エントリの障害発生有無（図１９、２５７）をチェックする（Ｓ３０４）。
　“有”であれば、ＰＴＨ＃ｉをパスＩＤとし、さらにそのＳＬＡ種別（図１９、２５２）を障害発生通知として装置管理部１２に通知し（Ｓ３０５）、Ｓ３０２以降の処理を継続する。
　一方、上記Ｓ３０４において、障害発生有無２５７が“無”であれば、Ｓ３０２以降の処理を継続する。
　上記障害発生通知を受信した装置管理部１２は、ＳＬＡ種別が保証型サービス（例えばＳＬＡ＃１）であれば、受信した情報を障害通知キュー（優先）２７－１へ格納し、ＳＬＡ種別が公平型サービス（例えばＳＬＡ＃２）であれば、障害通知キュー（非優先）２７－２に格納する（図１１参照）。
　図２７は、通信装置ＮＤ＃ｎの装置管理部１２が実行する障害通知処理Ｓ３０００における障害通知キュー読出し処理Ｓ４００の詳細を示す。
　装置管理部１２は、障害通知キュー（優先）２７－１または障害通知キュー（非優先）２７－２のどちらかに障害発生通知が格納されていると判定すると、障害通知キュー（優先）２７－１に通知があるかどうかを判定する（Ｓ４０１）。
　障害通知キュー（優先）２７－１に通知があれば、障害通知キュー（優先）２７－１から格納してあるパスＩＤとＳＬＡ種別と共に障害通知としてネットワーク管理システムＮＭＳに通知する（Ｓ４０２）。
　次に、障害通知キュー（優先）２７－１または障害通知キュー（非優先）２７－２のどちらかに障害発生通知が格納されているか判定し（Ｓ４０４）、どちらにも通知がなければ処理を終了する（Ｓ４０５）。
　一方、上記Ｓ４０１において、障害通知キュー（優先）２７－１に通知がないと判定すると、障害通知キュー（非優先）２７－２から格納してあるパスＩＤとＳＬＡ種別と共に障害通知としてネットワーク管理システムＮＭＳに通知し（Ｓ４０３）、Ｓ４０４以降の処理を実行する。
　一方、上記Ｓ４０４において、どちらかのキューに通知があれば、Ｓ４０１以降の処理を継続する。
　以上の処理Ｓ３００およびＳ４００により、各通信装置で検出した保証型サービスの障害通知を優先してネットワーク管理システムＮＭＳに通知することが可能となる。ネットワーク管理システムＮＭＳは、先に通知された障害について優先的に処理することで、保証型サービスについて優先的に対応し、稼働率を保証することが容易となる。
　図２８、２９は、ネットワーク管理システムＮＭＳが実行する本発明の別のサービスに応じたパス検索処理例Ｓ２８００を示す。Ｓ２８００以外の処理は、実施例１と同様である。
　Ｓ２８００は、Ｓ２０００（図２４）の内、Ｓ２０９、Ｓ２１０およびＳ２１１の処理の後に、下記Ｓ２００１～Ｓ２００６を追加したものであり、他の処理はＳ２０００と同様であるため、以下では変更点のみ説明する。
　Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスが存在するかをパス構成テーブルＮＭＳ－ｔ４から検索する（Ｓ２００１）。
　公平型サービスのパスが存在する場合、経由リンクＩＤ：ＮＭＳ―ｔ４５が全く同様なパスを有している公平型サービスのパスＩＤ：ＮＭＳ－ｔ４１を取得する。そして、リンク管理テーブルＮＭＳ－ｔ５の中で当該パスの経由リンク：ＮＭＳ―ｔ４５に該当する非優先透過ユーザ数ＮＭＳ－ｔ５３を１減算し、暫定リンク管理テーブルＮＭＳ－ｔ５として保持する（Ｓ２００２）。
　次に、この暫定リンク管理テーブルＮＭＳ－ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、“空き帯域ＮＭＳ－ｔ５２÷透過非優先ユーザ数ＮＭＳ－ｔ５３”が最大の経路を検索する（Ｓ２００３）。
　具体的には、例えば、暫定リンク管理テーブルＮＭＳ－ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では“空き帯域ＮＭＳ－ｔ５２÷透過非優先ユーザ数ＮＭＳ－ｔ５３”）が最も大きい経路が選択されることで、公平型サービスは既存パスの中で分散される。
　続いて、上記Ｓ２００３の後、パス構成テーブルＮＭＳ－ｔ４を利用し、得られた経路が既存パスの経路かどうか判定する（Ｓ２００４）。
　既存パスの経路があれば、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスの中から一人のユーザを選択し、Ｓ２００３の結果検索されたパスに収容を変更する（Ｓ２００５）。
　具体的には、該当するユーザ管理テーブルＮＭＳ－ｔ２から該当エントリを削除し、当該ユーザの収容パスＮＭＳ－ｔ２３に該当するパス構成テーブルＮＭＳ－ｔ４のエントリの情報を更新（収容ユーザＮＭＳ－ｔ４８から当該ユーザＩＤを削除）する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新（透過非優先ユーザ数ＮＭＳ－ｔ５３を１減算）する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新する。さらに、ユーザ管理テーブルＮＭＳ－ｔ２に上記で削除したユーザを追加し、既存パスを収容パスＮＭＳ－ｔ２３に設定する。さらに、該当するパス構成テーブルＮＭＳ－ｔ４のエントリの情報を更新（収容ユーザＮＭＳ－ｔ４８に上記で削除したユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新（透過非優先ユーザ数ＮＭＳ－ｔ５３に１加算）する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知する。
　続いて、上記Ｓ２００５の処理の後、処理を終了する（Ｓ２１６）。
　一方、上記Ｓ２００４において、既存パスの経路がなければ、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスの中から一人のユーザを選択し、新規パスを設定し、当該パスに収容を変更する（Ｓ２００６）。
　具体的には、該当するユーザ管理テーブルＮＭＳ－ｔ２から該当エントリを削除し、当該ユーザの収容パスＮＭＳ－ｔ２３に該当するパス構成テーブルＮＭＳ－ｔ４のエントリの情報を更新する。具体的には、収容ユーザＮＭＳ－ｔ４８から当該ユーザＩＤを削除する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新する。具体的には透過非優先ユーザ数ＮＭＳ－ｔ５３を１減算する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新する。さらに、ユーザ管理テーブルＮＭＳ－ｔ２に上記で削除したユーザを追加し、新規パスを収容パスＮＭＳ－ｔ２３に設定する。また、パス構成テーブルＮＭＳ－ｔ４に新規エントリを追加する。具体的には収容ユーザＮＭＳ－ｔ４８に上記で削除したユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ－ｔ５の内、経由リンクＩＤ：ＮＭＳ－ｔ４５に該当する全エントリを更新する。具体的には透過非優先ユーザ数ＮＭＳ－ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知する。
　続いて、上記Ｓ２００６の処理の後、処理を終了する（Ｓ２１６）。
　一方、上記Ｓ２００１において、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスは存在しない場合、処理を終了する（Ｓ２１６）。
　以上の処理を行うことにより、保証型サービスの確保帯域の変更や、公平型サービスのユーザ数の変化に追従し、公平型ユーザ間で分配される空き帯域の比を常に平等に保つことが可能となる。
　本発明の別のネットワーク管理システムの実施例を示す。
　本実施例のネットワーク管理システムの構成は、図２に示した実施例１のネットワーク管理システムＮＭＳとほぼ同様である。異なる部分を中心に説明すると、パス構成テーブルＮＭＳ-ｔ４に事前にパスを設定する点が異なる。このため、本実施例ではパス構成テーブルをＮＭＳ-ｔ４０と称する。その他、それぞれのブロックの構成は、ネットワーク管理システムＮＭＳと同様である。
　図３０は、オペレータからのネットワーク事前設定シーケンスＳＱ１０００を示す。
　オペレータＯＰが事前の設定情報として、接続先（例えば、アクセス装置＃１とデータセンタＤＣの組合せ）、サービス種別を送信する（ＳＱ１００１）。
　それを受信したネットワーク管理システムＮＭＳは、後述する事前パス検索処理Ｓ５００により、接続先管理テーブルＮＭＳ－ｔ３やリンク管理テーブルＮＭＳ－ｔ５を利用してパスを検索する。その結果を対応する通信装置ＮＤ＃１～ｎに設定する（ＳＱ１００２－１～ｎ）。
　本設定情報としては、実施例１と同様のコネクションＩＤ決定テーブル２１、入力ヘッダ処理テーブル２２、ラベル設定テーブル２３、帯域監視テーブル２４、障害管理テーブル２５、そしてパケット転送テーブル２６などの各ユーザやパスの接続関係や帯域設定が含まれる。
　これらの情報が各通信装置ＮＤ＃ｎに設定されると、パスの終端点となるエッジ装置ＮＤ＃1およびＮＤ＃ｎ間で、障害監視パケットの定期的な送受信が開始される（ＳＱ１００３－１、ＳＱ１００３－ｎ）。
　以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳ２から設定完了通知がオペレータＯＰに送信され（ＳＱ１００４）、本シーケンスが終了となる。
　図３１は、ネットワーク管理システムＮＭＳが実行する事前パス検索処理Ｓ５００を示す。オペレータＯＰから事前設定を受信したネットワーク管理システムＮＭＳは、事前設定として接続先及びＳＬＡ種別を取得する（Ｓ５０１）。
　次に、当該接続先の情報を用いて接続先管理テーブルＮＭＳ－ｔ３を検索し、接続先となり得るポイントとして収容ノードＩＤ：ＮＭＳ－ｔ３３と収容ポートＩＤ：ＮＭＳ－ｔ３４の組合せの候補を抽出する（Ｓ５０２）。
　例えば、アクセス装置ＡＥ＃１を始点としてデータセンタＤＣを終点として指定された場合、その候補は以下となる。
　始点ポート候補：
（１）収容装置ＩＤ：ＮＤ＃１の収容ポートＩＤ：ＰＴ＃１
終点ポート候補：
（Ａ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１０
（Ｂ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１１
　ここで、始点ポート候補と終点ポート候補間のパスを検索する必要があることを意味する。つまり、この場合、（１）－（Ａ）間および（１）－（Ｂ）間のパスが候補となる。
　続いて、Ｓ５０２の後、リンク管理テーブルＮＭＳ－ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、上記始点と終点が接続可能な経路のリストを検索する（Ｓ５０３）。
　具体的には、例えば、リンク管理テーブルＮＭＳ－ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらの全てを候補リストとして保持する。
　続いて、上記Ｓ５０３の結果、条件に合致する全ての経路の新規パスを設定する（Ｓ５０４）。
　具体的には、ユーザ管理テーブルＮＭＳ－ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ－ｔ２３に設定し、パス構成テーブルＮＭＳ－ｔ４に新規エントリを追加（割当帯域ＮＭＳ－ｔ４７には０Ｍｂｐｓ（未使用）、収容ユーザＮＭＳ－ｔ４８に無効値を設定）し、該当する通信装置＃ｎの各種テーブル２１～２６を更新し、処理の結果をオペレータに通知する。
　上記Ｓ５０４の後、処理を終了する（Ｓ５０５）。
　図３２は、上記オペレータからのネットワーク事前設定シーケンスＳＱ１０００によって生成されるパス構成テ－ブルＮＭＳ－ｔ４０を示す。パス構成テ－ブルＮＭＳ－ｔ４０は、パスＩＤ：ＮＭＳ－ｔ４０１を検索キーとして、ＳＬＡ種別ＮＭＳ－ｔ４０２と、終端装置ＩＤ：ＮＭＳ－ｔ４０３と、経由装置ＩＤ：ＮＭＳ－ｔ４０４と、経由リンクＩＤ：ＮＭＳ－ｔ４０５と、割当帯域ＮＭＳ－ｔ４０６、収容ユーザＮＭＳ－ｔ４０７とを示すテーブルエントリを検索するためのものである。
　ここで、保証型サービスのパスであっても、割当帯域ＮＭＳ－ｔ４０６はユーザ未収用のため０Ｍｂｐｓとなっており、収容ユーザがいない状態である。さらに、公平型サービスのパスについても、収容ユーザ数がいない状態である。
　この他、通信システムの構成や、通信装置ＮＤ＃ｎのブロック構成、そして処理なども実施例１と同様である。
　以上の処理の処理を接続したい対象全てに実施することにより、事前に各接続先全てに複数の候補パスを設定可能となるため、サービスに応じたパス検索処理Ｓ２０００、Ｓ２８００において、新規ユーザを既存パスへ収容する確率が高まり、より迅速なネットワーク変更が可能となる。
　本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。
　本実施例中、ソフトウエアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。また、ソフトウエアで構成した機能は、単体のコンピュータ構成で実現してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。
　以上説明した本発明の実施例によると、ＳＬＡの異なる複数サービスを収容する仮想ネットワークにおいて、通信品質だけでなく稼働率の保証が必要なビジネスユーザ向け通信サービスのパスは、各ユーザに確保すべき帯域の総和が経路上の物理回線の帯域を超過しない範囲で同一経路のものは集約することで、通信品質を保証しながら障害発生の際の障害検出数を削減可能である。
　さらに、ビジネスユーザ向け通信サービスの障害発生を通信装置から優先的に通知し、本通知を受信したネットワーク管理システムが優先的に折返し試験を実行可能することで、ビジネスユーザ向け通信サービスのパスの障害箇所を迅速に特定し、部品交換などの保守作業を迅速に行うことが可能となる。以上より、通信品質と稼働率の両方を満足することが可能となる。
　一方、大量のトラヒックを効率的かつユーザ間で公平に収容する必要のある一般消費者向け通信サービス向けのパスは、ビジネスユーザ向け通信パス用に確保された帯域以外の余りの帯域を考慮し、余りの帯域の比率がユーザ毎に等しくなるようにネットワーク全体に分散させることで、大容量のトラヒックを効率的かつユーザ間で公平性を維持して収容することが可能となる。
　さらに、ユーザやアプリケーション提供事業者からのネットワーク変更要求に対して、自動的に上記の処理を実施することで、ＳＬＡを保証しながら柔軟に対応することが可能となる。以上の結果、通信事業者のサービス統合による提供コスト低減と、タイムリーな最適ネットワーク提供による収益向上を実現できる。
　種々のサービスに用いるネットワークの運用管理に利用することができる。
ＴＥ１～ｎ：ユーザ端末
ＡＥ１～ｎ：アクセス装置
ＮＤ＃１～ｎ：通信装置
ＤＣ：データセンタ
ＩＮ：インタネット
ＭＮＷ：管理用ネットワーク
ＮＭＳ：ネットワーク管理システム
ＭＴ：監視端末
ＯＰ：オペレータ

Claims (15)

  1. 　複数の通信装置で構成される通信ネットワークと管理システムを備え、上記管理システムから設定した通信パスを介して上記複数の通信装置間でパケットを転送する、通信ネットワークの管理方法であって、
    　上記管理システムが上記通信パスを設定する際、
    　稼働率の保証が必要な第１のサービスのために、上記通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する、第１の設定ポリシと、
    　稼働率の保証をしない第２のサービスのために、使用する経路を上記通信ネットワーク全体に分散するように上記通信パスを設定する、第２の設定ポリシを有し、
    　上記サービスの種類に応じて上記設定ポリシを変更することを特徴とする、
    　通信ネットワークの管理方法。
  2. 　上記第１の設定ポリシは、
    　上記通信ネットワーク上の送信ポートと宛先ポートが全く同一の経路の場合、上記通信パス同士を集約する設定ポリシであることを特徴とする、
    　請求項１記載の通信ネットワークの管理方法。
  3. 　上記第１のサービスは、ユーザまたはサービス毎にある一定の帯域を確保するサービスであって、
    　上記第１の設定ポリシに基づいて上記管理システムは、
    　同一経路に集約されたサービスの帯域の総和が上記通信パス上のいずれかの回線帯域を超過した場合、同一経路に集約されたサービスの帯域の総和が上記通信パス上のいずれの回線帯域も超過しない新規の経路を検索し、当該経路に上記通信パスを新規に設定し、ユーザやサービスを収容するように制御し、
    　上記第２の設定ポリシに基づいて上記管理システムは、
    　経路上の各回線帯域から上記第１のサービス向けに確保された帯域を差し引いた余りの帯域に基づいて、当該余りの帯域に対して上記第２のサービスのための通信パスを分散することを特徴とする、
    　請求項１記載の通信ネットワークの管理方法。
  4. 　上記通信ネットワークに接続された外部システムからの要求に応じて上記通信パスの変更をする際、
    　上記管理システムは自動的に上記設定ポリシを適用することを特徴とする、
    　請求項１記載の通信ネットワークの管理方法。
  5. 　上記管理システムは、上記第１のサービスに確保する帯域の設定に変更があった場合に、
    　当該変更により変化した余りの帯域が、上記第２のサービス内のユーザ間で等しい比率になるように再度上記通信パスを分散し、設定し直すことを特徴とする、
    　請求項３記載の通信ネットワークの管理方法。
  6. 　上記管理システムは、
    　各サービスの経路をユーザ収容する前に検索し、事前に設定しておき、ユーザの収容の設定要求があった場合に、上記通信パスに新規にユーザを収容することを特徴とする、
    　請求項１記載の通信ネットワークの管理方法。
  7. 　複数の上記通信パスの障害を検出した際、上記通信装置は上記第１のサービスに関わる通信パスの障害を優先的に上記管理システムに通知することを特徴とする、
    　請求項１記載の通信ネットワークの管理方法。
  8. 　前記障害通知を受信した上記管理システムは、上記第１のサービスの障害通知を優先的に処理し、折返し試験を自動的に実行する、または、折返し試験の実行をオペレータに促すことを特徴とする、
    　請求項７記載の通信ネットワークの管理方法。
  9. 　通信ネットワークを構成する複数の通信装置に対して、ユーザに対して帯域を保証する第１のサービスのための通信パスと、ユーザに対して帯域を保証しない第２のサービスのための通信パスを設定し、上記通信ネットワーク内に上記第１及び第２のサービスのための通信パスを共存させる、通信ネットワーク管理システムであって、
    　上記通信ネットワーク管理システムは、
    　上記第１のサービスのための新規の通信パス設定要求があった場合には、
    　上記保証帯域分の空き帯域が存在する経路から選ばれた経路に、上記新規の通信パスを設定する第１の設定ポリシを適用し、
    　上記第２のサービスのための新規の通信パス設定要求があった場合には、
    　上記第２のサービスのユーザあたりの空き帯域に基づいて選ばれた経路に、上記新規の通信パスを設定する第２の設定ポリシを適用する、
    　通信ネットワーク管理システム。
  10. 　上記第１の設定ポリシは、
    　上記保証帯域分の空き帯域が存在する経路から、空き領域が最小あるいは所定閾値以下の経路を選び、上記新規の通信パスを設定し、
    　上記第２の設定ポリシは、
    　上記第２のサービスのユーザあたりの空き帯域が最大あるいは所定閾値以上の経路を選び、上記新規の通信パスを設定する、
    　請求項９記載の通信ネットワーク管理システム。
  11. 　上記ユーザを特定する識別子と、上記ユーザに対して提供されるサービスのＳＬＡ種別と、上記ＳＬＡ種別に適用される前記設定ポリシを、関連付けて記憶するデータを保持する、
    　請求項９記載の通信ネットワーク管理システム。
  12. 　経路を構成する複数の通信装置と、上記複数の通信装置にユーザの利用に供する通信パスを設定する管理システムを有する通信ネットワークであって、
    　上記管理システムは、前記ユーザの利用に供するため、ＳＬＡの異なる第１のサービスのための通信パスと、第２のサービスのための通信パスを設定し、
    　上記第１のサービスに用いる通信パスを設定する場合には、上記第１のサービスに用いる通信パスが上記ネットワーク上の特定の経路に集約されるように設定し、
    　上記第２のサービスに用いる通信パスを設定する場合には、上記第２のサービスに用いる通信パスが上記ネットワーク上の経路に分散されるように設定することを特徴とする、
    　通信ネットワーク。
  13. 　上記第１のサービスは、稼働率および帯域が保証されるサービスであり、
    　上記第１のサービスが提供される複数のユーザのために用いられる複数の通信パスの、上記ネットワーク上の送信ポートと宛先ポートが同一の場合、同一の経路に上記複数の通信パスを設定することを特徴とする、
    　請求項１２記載の通信ネットワーク。
  14. 　上記第２のサービスは、ベストエフォート型のサービスであり、
    　上記第１のサービスに用いる通信パスが使用している通信帯域を除外した空き帯域の、上記第２のサービスのユーザ当たりの割り当てが均等になるように、上記第２のサービスに用いる通信パスを設定することを特徴とする、
    　請求項１２記載の通信ネットワーク。
  15. 　上記通信装置は上記通信パスの障害を管理する障害管理部を有し、
    　上記障害管理部は、
    　障害が発生した通信パスが、上記第１のサービスに用いる通信パスか、上記第２のサービスに用いる通信パスか、により、障害対応処理の優先度を変更する、
    　請求項１２記載の通信ネットワーク。
PCT/JP2015/065681 2015-05-29 2015-05-29 通信ネットワーク、通信ネットワークの管理方法および管理システム WO2016194089A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2017500088A JPWO2016194089A1 (ja) 2015-05-29 2015-05-29 通信ネットワーク、通信ネットワークの管理方法および管理システム
PCT/JP2015/065681 WO2016194089A1 (ja) 2015-05-29 2015-05-29 通信ネットワーク、通信ネットワークの管理方法および管理システム
US15/507,954 US20170310581A1 (en) 2015-05-29 2015-05-29 Communication Network, Communication Network Management Method, and Management System

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/065681 WO2016194089A1 (ja) 2015-05-29 2015-05-29 通信ネットワーク、通信ネットワークの管理方法および管理システム

Publications (1)

Publication Number Publication Date
WO2016194089A1 true WO2016194089A1 (ja) 2016-12-08

Family

ID=57442240

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/065681 WO2016194089A1 (ja) 2015-05-29 2015-05-29 通信ネットワーク、通信ネットワークの管理方法および管理システム

Country Status (3)

Country Link
US (1) US20170310581A1 (ja)
JP (1) JPWO2016194089A1 (ja)
WO (1) WO2016194089A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018170595A (ja) * 2017-03-29 2018-11-01 Kddi株式会社 障害管理装置およびその障害監視用パス設定方法
JP2019102083A (ja) * 2017-11-30 2019-06-24 三星電子株式会社Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ． 差別化されたストレージサービス提供方法及びイーサネットｓｓｄ
JP2021057632A (ja) * 2019-09-26 2021-04-08 富士通株式会社 障害評価装置及び障害評価方法
WO2021124416A1 (ja) * 2019-12-16 2021-06-24 三菱電機株式会社 リソース管理装置、制御回路、記憶媒体およびリソース管理方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10531314B2 (en) * 2017-11-17 2020-01-07 Abl Ip Holding Llc Heuristic optimization of performance of a radio frequency nodal network
US20190253341A1 (en) * 2018-02-15 2019-08-15 128 Technology, Inc. Service Related Routing Method and Apparatus
US11451435B2 (en) * 2019-03-28 2022-09-20 Intel Corporation Technologies for providing multi-tenant support using one or more edge channels
CN115428411A (zh) 2020-04-23 2022-12-02 瞻博网络公司 使用会话建立度量的会话监测

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004274368A (ja) * 2003-03-07 2004-09-30 Fujitsu Ltd 品質保証制御装置および負荷分散装置
WO2010052826A1 (ja) * 2008-11-05 2010-05-14 日本電気株式会社 通信装置、ネットワーク及びそれらに用いる経路制御方法
WO2015029420A1 (ja) * 2013-08-26 2015-03-05 日本電気株式会社 通信システムにおける通信装置、通信方法、制御装置および管理装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004274368A (ja) * 2003-03-07 2004-09-30 Fujitsu Ltd 品質保証制御装置および負荷分散装置
WO2010052826A1 (ja) * 2008-11-05 2010-05-14 日本電気株式会社 通信装置、ネットワーク及びそれらに用いる経路制御方法
WO2015029420A1 (ja) * 2013-08-26 2015-03-05 日本電気株式会社 通信システムにおける通信装置、通信方法、制御装置および管理装置

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018170595A (ja) * 2017-03-29 2018-11-01 Kddi株式会社 障害管理装置およびその障害監視用パス設定方法
JP2019102083A (ja) * 2017-11-30 2019-06-24 三星電子株式会社Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ． 差別化されたストレージサービス提供方法及びイーサネットｓｓｄ
US11544212B2 (en) 2017-11-30 2023-01-03 Samsung Electronics Co., Ltd. Differentiated storage services in ethernet SSD
JP2021057632A (ja) * 2019-09-26 2021-04-08 富士通株式会社 障害評価装置及び障害評価方法
JP7287219B2 (ja) 2019-09-26 2023-06-06 富士通株式会社 障害評価装置及び障害評価方法
WO2021124416A1 (ja) * 2019-12-16 2021-06-24 三菱電機株式会社 リソース管理装置、制御回路、記憶媒体およびリソース管理方法
JPWO2021124416A1 (ja) * 2019-12-16 2021-06-24
JP7053970B2 (ja) 2019-12-16 2022-04-12 三菱電機株式会社 リソース管理装置、制御回路、記憶媒体およびリソース管理方法
CN114788244A (zh) * 2019-12-16 2022-07-22 三菱电机株式会社 资源管理装置、控制电路、存储介质和资源管理方法

Also Published As

Publication number Publication date
US20170310581A1 (en) 2017-10-26
JPWO2016194089A1 (ja) 2017-06-15

Similar Documents

Publication Publication Date Title
US11412416B2 (en) Data transmission via bonded tunnels of a virtual wide area network overlay
WO2016194089A1 (ja) 通信ネットワーク、通信ネットワークの管理方法および管理システム
JP7417825B2 (ja) スライスベースルーティング
US9717021B2 (en) Virtual network overlay
EP2911348B1 (en) Control device discovery in networks having separate control and forwarding devices
US6594268B1 (en) Adaptive routing system and method for QOS packet networks
EP3042476B1 (en) Buffer-less virtual routing
RU2358398C2 (ru) Способ пересылки трафика, имеющего предварительно определенную категорию обслуживания передачи данных, в сети связи без установления соединений
US7209434B2 (en) Path modifying method, label switching node and administrative node in label transfer network
EP3208977A1 (en) Data forwarding method, device and system in software-defined networking
US7944834B2 (en) Policing virtual connections
US20070140235A1 (en) Network visible inter-logical router links
JPH11127195A (ja) 通信資源管理方法及びノード装置
Lee et al. Path layout planning and software based fast failure detection in survivable OpenFlow networks
CN103581009A (zh) 对丢弃敏感的前缀（bgp路径）属性修改
EP2838231B1 (en) Network system and access controller and method for operating the network system
US8121138B2 (en) Communication apparatus in label switching network
US9118580B2 (en) Communication device and method for controlling transmission priority related to shared backup communication channel
Lee et al. Design and implementation of an sd-wan vpn system to support multipath and multi-wan-hop routing in the public internet
CN110300073A (zh) 级联端口的目标选择方法、聚合装置及存储介质
JP6344005B2 (ja) 制御装置、通信システム、通信方法及びプログラム
US7990945B1 (en) Method and apparatus for provisioning a label switched path across two or more networks
JP2005102012A (ja) スパニングツリープロトコル適用時における網資源管理装置
Budka et al. An Overview of Smart Grid Network Design Process

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2017500088

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15894124

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15507954

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15894124

Country of ref document: EP

Kind code of ref document: A1