The present invention relates to a gateway apparatus, a method, and a program.
In recent years, practical use of the 5th generation (5G) mobile communication system has been in progress. The practical use of 5G is expected to create new services in cooperation with various operators utilizing 5G characteristics including large capacity broadband, large session connection, ultra-low latency and high quality. Achieving these new services needs a variety of networks according to various service requirements. A network slicing technique has been known as a technique for quickly and flexibly providing a network for such a request. The network slicing technique can manage an infrastructure of a common physical facility as a resource that can be virtually divided, freely combine the resources, and configure a required virtual network (slice).
In order to provide a network (hereinafter abbreviated as an “NW”) having a variety of requirements required by a service operator, an end-to-end (E2E) slice that can secure consistent communication quality at E2E is needed. The E2E slice is not necessarily an NW limited to a single NW operator/domain and may also be an NW across a plurality of NW operators/domains. For achieving such an E2E slice (hereinafter simply referred to as a “slice”) across a plurality of NW operators/domains, an architecture in which a slice gateway (SLG) is deployed at a connection point between NW operators/domains has been proposed.
For example, an architecture that achieves a slice by an NW configuration illustrated in
For example, a bandwidth guaranteed and highly reliable slice can be achieved by connecting tunnels with priority/path redundancy to each other. Specifically, a bandwidth guaranteed and highly reliable slice can be achieved by connecting a tunnel 1 of the access NW, a tunnel 5 of the core NW, and a tunnel 13 of the NW in DC, connecting a tunnel 3 of the access NW, a tunnel 9 of the core NW, and the tunnel 13 of the NW in DC, and the like.
Similarly, for example, a bandwidth guaranteed and highly reliable slice via a network function (NF) such as a firewall can be achieved by connecting tunnels with priority/path redundancy via the NF to each other. Specifically, a bandwidth guaranteed and highly reliable slice can be achieved by connecting the tunnel 1 of the access NW, a tunnel 7 of the core NW, and the tunnel 13 of the NW in DC, connecting the tunnel 3 of the access NW, a tunnel 12 of the core NW, and a tunnel 16 of the NW in DC, or the like.
Similarly, a best effort (BE) and highly reliable slice can be achieved, for example, by connecting tunnels with BE/path redundancy to each other. Specifically, a BE and highly reliable slice can be achieved by connecting a tunnel 2 of the access NW, a tunnel 6 of the core NW, and a tunnel 14 of the NW in DC, connecting a tunnel 4 of the access NW, a tunnel 10 of the core NW, and a tunnel 17 of the NW in DC, and the like. A BE and unreliable slice and the like are also achieved by appropriately connecting tunnels to each other. Note that, for example, a terminal is equipped with an application, and various services are provided to the terminal by application processing executed by a server/VM.
In the NW configuration described above, for example, by performing, by OpenFlow (NPL 1) or Policy Based Routing (NPL 2), assignment setting (output destination tunnel setting) by flow identification based on 5-tuple information (a source Internet Protocol (IP) address, a destination IP address, a source port number, a destination port number, and a protocol number), each SLG can determine an output destination tunnel of a packet and achieve a slice. Alternatively, for example, by performing flow identification based on 5-tuple information only at an NW endpoint by using a source routing technique such as Segment Routing (NPL 3) to specify a path, a slice can also be achieved.
CITATION LIST
NPL 1: ONF, “Software-Defined Networking: The New Norm for Networks”, ONF White Paper Apr. 13, 2012, Internet <URL: https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf>
NPL 2: Cisco, “Policy-Based Routing (PBR)”, Internet <URL: https://www.cisco.com/c/ja_jp/td/docs/sw/campuslanswt-coredistribution/cat6500swt/cg/002/15-1-sy-c4-swcg/policy-based-routing-pbr.html>
NPL 3: IETF RFC8402, Internet <URL: https://www.rfc-editor.org/rfc/rfc8402.txt>
However, for example, when assignment setting is performed on each SLG, a transfer table of an SLG (particularly, a transfer table of an SLG of an NW higher stage (such as a core NW) through which communication of many terminals passes) increases due to an increase in the number of terminals, the number of applications that use a slice, the number of servers/VMs, the number of address ranges used by a terminal, and the like. Further, for example, when an operator of each domain of the access NW, the core NW, and the NW in DC is different, a large number of pieces of assignment information needs to be exchanged between the operators, and lead time of the assignment setting increases (particularly, when the assignment setting is sequentially introduced in consideration of rollback, lead time of the assignment setting increases).
On the other hand, when, for example, a source routing technique such as Segment Routing is used, NW information such as an NW topology and address information in all domains needs to be managed in a domain at an NW endpoint, and a system load required for the management increases. Further, in an operation requiring a path change that requires quickness (for example, a path change during an abnormal condition such as failure and congestion of an SLG, and the like), a setting change of an SLG in another domain is required, and thus lead time for reflecting the setting increases.
An embodiment of the present invention has been made in view of the above-described circumstances, and an object thereof is to achieve an efficient E2E slice.
In order to achieve the object described above, a gateway apparatus according to an embodiment includes a transfer destination specification unit that refers to a slice transfer table for determining a tunnel for a transfer destination when a packet with a slice ID added is received, the slice ID including a slice requirement abstracted indicating a requirement related to transfer priority, reliability, and whether a network function is passed through and a gateway ID abstracted indicating a gateway apparatus as a destination, and specifies a tunnel corresponding to the slice requirement and the gateway ID that are included in the slice ID, and a transfer unit that transfers the packet with the tunnel specified by the transfer destination specification unit.
An efficient E2E slice can be achieved.
Hereinafter, an embodiment of the present invention will be described.
Overview of Transfer Processing according to Present Embodiment
First, an overview of transfer processing by an E2E slice according to the present embodiment will be described. In an NW configuration illustrated in
When communication from a terminal to a server/VM is performed, in the present embodiment, an SLG being an entrance portion refers to 5-tuple information of a packet transmitted from the terminal, provides a slice ID to a header of the packet, and then assigns the packet into a tunnel corresponding to the slice ID. Here, the slice ID refers to information acquired by abstracting a slice requirement (for example, transfer priority, a quality requirement such as reliability, presence or absence of a passed NF, and the like) and information indicating a destination SLG.
Next, when the packet reaches an SLG being a relay portion, the SLG assigns the packet into a tunnel corresponding to the slice ID. Then, when the packet reaches an SLG being an exit portion, the SLG deletes the slice ID, and outputs the packet to a corresponding server/VM.
In this way, in the transfer processing according to the present embodiment, only an SLG being an entrance portion refers to 5-tuple information and provides a slice ID acquired by abstracting a slice requirement and information indicating a destination SLG to a packet. Then, each SLG assigns a packet into an appropriate tunnel (i.e., a tunnel that satisfies the slice requirement) based on only the slice ID. Thus, the transfer processing according to the present embodiment can eliminate the need to set 5-tuple information at a relay portion and suppress an increase in a transfer table of an SLG and an increase in lead time of assignment setting.
Further, since a slice ID is information acquired by abstracting a slice requirement, each domain can determine a specific transfer method and a specific path. Thus, an NW topology of another domain does not need to be managed. A path change can be handled by only a path change in an own domain, and thus a speed of the path change can be increased.
Note that, in
Details of Preprocessing and Transfer Processing
Next, details of the transfer processing illustrated in
(1-1) First, the NW controller 101 sets a 5-tuple-slice requirement correspondence table for the SLG 201 and the SLG 202 at the NW endpoint in its own domain, and also issues an SLG-ID. The SLG-ID is an ID for identifying an SLG deployed at an NW endpoint. Hereinafter, the SLG-ID of the SLG 201 is “101”, and the SLG-ID of the SLG 202 is “102”.
Note that the NW controller 103 also similarly sets a 5-tuple-slice requirement correspondence table for the SLG 203 and the SLG 204 at the NW endpoint in its own domain, and also issues an SLG-ID. Hereinafter, the SLG-ID of the SLG 203 is “201”, and the SLG-ID of the SLG 204 is “202”.
Here, the 5-tuple-slice requirement correspondence table is a table that stores information in which 5-tuple information and a slice requirement are associated with each other. An example of the 5-tuple-slice requirement correspondence table is illustrated in
(1-2) The NW controller 101 notifies the NW controller 102 in an adjacent domain of the SLG ID of the SLG 20 at the NW endpoint in its own domain, an address range subordinate to the SLG 20, and a tunnel ID of a tunnel terminated at the SLG 20 having the SLG ID. Note that the address range is a range of an IP address of a packet received by the SLG 20 deployed at the NW endpoint.
Specifically, the NW controller 101 notifies the NW controller 102 of (SLG ID “101”, address range “A1/A2/A3 . . . ”, tunnel ID “tunnel 1, tunnel 2”) and (SLG ID “102”, address range “B1/B2/B3 . . . ”, tunnel ID “tunnel 3, tunnel 4”).
Note that the NW controller 103 also similarly performs (1-2) described above. In other words, the NW controller 103 also similarly provides notification of the SLG ID of the SLG 20 at the NW endpoint in its own domain, an address range subordinate to the SLG 20, and a tunnel ID of a tunnel terminated at the SLG 20 having the SLG ID.
(1-3) When the NW controller 102 receives the notification from the NW controller 10 in the adjacent domain, the NW controller 102 sets a slice transfer table for the SLG 30 terminating the tunnel having the tunnel ID included in the notification content.
For example, when the NW controller 102 receives the notification from the NW controller 101, the NW controller 102 sets a slice transfer table for the SLG 301 that terminates the tunnel 1 and the tunnel 2, and also sets a slice transfer table for the SLG 302 that terminates the tunnel 3 and the tunnel 4.
Similarly, when NW controller 102 receives the notification from the NW controller 103, the NW controller 102 sets a slice transfer table for the SLG 303 that terminates the tunnel 13 to the tunnel 18.
Here, the slice transfer table is a table for determining a transfer destination tunnel. An example of the slice transfer table is illustrated in
(1-4) Next, the NW controller 102 notifies the NW controller 10 in an adjacent domain other than the original domain that has received the notification in 1-3 described above of an SLG ID and an address range that are included in the notification, and a tunnel ID of a tunnel connecting the SLG 30 in its own domain to an SLG in the adjacent domain.
For example, when the NW controller 102 receives the notification from the NW controller 101 in 1-3 described above, the NW controller 102 notifies the NW controller 103 of the NW in DC of an SLG ID “101”, an address range “A1/A2/A3”, an SLG ID “102”, and an address range “B1/B2/B3” that are included in the notification, and a tunnel ID “tunnel 13, tunnel 14, . . . , and tunnel 18” of the tunnel connecting the SLG 303 of the core NW to the SLG 203 and the SLG 204 of the NW in DC.
Similarly, for example, when the NW controller 102 receives the notification from the NW controller 103 in 1-3 described above, the NW controller 102 notifies the NW controller 101 of the access NW of an SLG ID “201”, an address range “C1/C2/C3”, an SLG ID “202”, and an address range “D1/D2/D3” that are included in the notification, and a tunnel ID “tunnel 1, tunnel 2, tunnel 3, tunnel 4” of the tunnel connecting the SLG 301 and the SLG 302 of the core NW to the SLG 201 and the SLG 201 of the NW in access.
(1-5) Then, when the NW controller 103 receives the notification from the NW controller 102 of the core NW, the NW controller 103 sets, for the SLG 20 that terminates the tunnel ID included in the notification, an SLG ID-address correspondence table in which an SLG ID and an address range that are included in the notification are associated with each other. Further, similarly to 1-3 described above, the NW controller 103 sets a slice transfer table for the SLG 20 that terminates the tunnel ID included in the notification.
Note that, when the NW controller 101 similarly receives the notification from the NW controller 102 of the core NW, the NW controller 101 sets a SLG ID-address correspondence table and also sets a slice transfer table for the SLG 20 that terminates the tunnel ID included in the notification.
Here, the SLG ID-address correspondence table is a table for specifying an SLG-ID from an address range. An example of the SLG ID-address correspondence table is illustrated in
Note that, for example, when it is assumed that the SLG-ID-address correspondence table illustrated in
According to 1-1 to 1-5 described above, the 5-tuple-slice requirement correspondence table, the slice transfer table, and the SLG-ID-address correspondence table are set for each SLG 20 deployed in an endpoint domain (i.e., the access NW and the NW in DC in the example illustrated in
(2-1) When the SLG 20 deployed in the access NW receives a packet from the terminal, the SLG 20 refers to the 5-tuple-slice requirement correspondence table, and specifies a slice requirement (an operator ID, transfer priority, reliability, and a passed NF) corresponding to the 5-tuple information about the packet. Furthermore, the SLG 20 refers to the SLG-ID-address correspondence table, and specifies an SLG ID corresponding to an address range of a destination IP address included in the 5-tuple information. Then, the SLG 20 provides, as a slice ID, the specified slice requirement and the specified SLG ID to a header of the packet.
(2-2) Next, the SLG 20 refers to the slice transfer table, determines, as a transfer destination, a tunnel having a tunnel ID corresponding to the slice requirement and the SLG ID that are included in the slice ID provided in 2-1 described above (i.e., a tunnel ID corresponding to the transfer priority, the reliability, and the passed NF that are included in the slice requirement, and the SLG ID), and outputs the packet to the tunnel being the transfer destination.
(2-3) When the SLG 30 deployed in the core NW (for example, the SLG 302) receives the packet, the SLG 30 refers to the slice transfer table, determines, as a transfer destination, a tunnel having a tunnel ID corresponding to the slice requirement and the SLG ID that are included in the slice ID provided to the packet, and outputs the packet to the tunnel being the transfer destination.
(2-4) Similarly, when the SLG 30 deployed in the core NW (for example, the SLG 303) receives the packet, the SLG 30 refers to the slice transfer table, determines, as a transfer destination, a tunnel having a tunnel ID corresponding to the slice requirement and the SLG ID included in the slice ID provided to the packet, and outputs the packet to the tunnel being the transfer destination.
(2-5) Then, when the SLG 20 deployed in the NW in DC (for example, the SLG 202) receives the packet, the SLG 20 deletes the slice ID provided to the packet, and then outputs the packet to a corresponding output destination based on a destination IP address, similarly to normal routing and the like.
According to 2-1 to 2-5 described above, an E2E slice is achieved. At this time, in the present embodiment, the SLG 20 being the entrance portion provides a slice ID to a packet based on the 5-tuple information, and thus the SLG 30 being the relay portion can determine a transfer destination tunnel based on only the slice ID. In this way, as described above, it is possible to achieve, for example, suppression of an increase in the transfer table, suppression of an increase in lead time of assignment setting, elimination of management of an NW topology in another domain, speeding up of a path change, and the like.
Functional Configuration
Next, a functional configuration of the NW controller 10, the SLG 20, and the SLG 30 according to the present embodiment will be described. Note that the SLG 20 is a slice gateway deployed in the endpoint domain, and the SLG 30 is a slice gateway deployed in the relay domain.
As illustrated in
When the NW controller 10 is deployed in the endpoint domain, the inter-domain cooperation unit 101 performs various kinds of processing below.
On the other hand, when the NW controller 10 is deployed in the relay domain, the inter-domain cooperation unit 101 performs various kinds of processing below.
The SLG management unit 102 manages various kinds of information (for example, tunnel setting between adjacent domains, an address range connected to the SLG 20 when the NW controller 10 is deployed in the endpoint domain, and the like). Further, the SLG management unit 102 sets various tables for each SLG (the SLG 20 or the SLG 30). Various tables described above are the 5-tuple-slice requirement correspondence table, the slice transfer table, and the SLG-ID-address correspondence table when the NW controller 10 is deployed in the endpoint domain, whereas various tables described above are the slice transfer table when the NW controller 10 is deployed in the relay domain. Note that, as described above, the information (i.e., the 5-tuple information and the slice requirement) stored in the 5-tuple-slice requirement correspondence table is information provided in advance from a service operator and the like using a slice, for example.
When the NW controller 10 is deployed in the endpoint domain, the SLG management unit 102 performs various kinds of processing below.
On the other hand, when the NW controller 10 is deployed in the relay domain, the SLG management unit 102 performs various kinds of processing below.
As illustrated in
The table management unit 201 manages a 5-tuple-slice requirement correspondence table, a slice transfer table, and an SLG-ID-address correspondence table that are set from the SLG management unit 102. Note that these tables are stored in a memory device 604 described later, for example.
The transfer destination determination unit 202 performs various kinds of processing below based on an SLG ID and a slice requirement (such as transfer priority, reliability, and a passed NF) that are included in a slice ID provided to a packet.
Further, the transfer destination determination unit 202 outputs a packet to a terminal, a server/VM, and the like by normal routing and the like when a slice ID is not provided to the packet (i.e., when a slice ID is deleted from the packet).
The slice ID setting unit 203 refers to the 5-tuple-slice requirement correspondence table, and specifies a slice requirement corresponding to 5-tuple information included in a packet received from the terminal, the server/VM, or the like. Furthermore, the slice ID setting unit 203 refers to the SLG-ID-address correspondence table, and specifies an SLG ID corresponding to a destination IP address included in the 5-tuple information. The slice ID setting unit 203 provides, as a slice ID, the specified slice requirement and the specified SLG ID to a header of the packet. Then, the slice ID setting unit 203 requests the transfer destination determination unit 202 to process the packet provided with the slice ID.
When the slice ID setting unit 203 is requested to process the packet from the tunnel control unit 204, the slice ID setting unit 203 confirms the SLG ID included in the slice ID provided to the packet and determines whether the SLG ID matches an SLG ID assigned to itself. Then, when the SLG ID included in the slice ID matches the SLG ID assigned to itself, the slice ID setting unit 203 deletes the slice ID from the packet, and then requests the transfer destination determination unit 202 to process the packet. On the other hand, when the SLG ID included in the slice ID does not match the SLG ID assigned to itself, the slice ID setting unit 203 abandons the packet as an invalid packet.
The tunnel control unit 204 performs termination processing of a tunnel (for example, provision of a header for a tunnel (tunnel header) when a packet is to be output (transmitted), and deletion of a tunnel header when a packet is received). At this time, the tunnel control unit 204 provides an appropriate value to a field (for example, a type of service (ToS) field in a case of an IP header, and the like) indicating transfer priority of a tunnel header in accordance with transfer priority set for each tunnel, and also performs priority control (for example, priority queuing, and the like) of a packet encapsulated in the tunnel header in accordance with the transfer priority.
Further, when the tunnel control unit 204 receives the packet from the SLG 30 in the adjacent domain, the tunnel control unit 204 performs the termination processing described above (i.e., deletion of the packet header), and then requests the slice ID setting unit 203 to process the packet.
As illustrated in
The table management unit 301 manages a slice transfer table set from the SLG management unit 102. Note that the slice transfer table is stored in the memory device 604 described later, for example.
The transfer destination determination unit 302 performs various kinds of processing below based on an SLG ID and a slice requirement (such as transfer priority, reliability, and a passed NF) that are included in a slice ID provided to a packet.
The tunnel control unit 303 performs termination processing of a tunnel (for example, provision of a header for a tunnel (tunnel header) when a packet is to be output (transmitted), and deletion of a tunnel header when a packet is received). At this time, the tunnel control unit 204 provides an appropriate value to a field (for example, a type of service (ToS) field in a case of an IP header, and the like) indicating transfer priority of a tunnel header in accordance with transfer priority set for each tunnel, and also performs priority control (for example, priority queuing, and the like) of a packet encapsulated in the tunnel header in accordance with the transfer priority.
Further, when the tunnel control unit 204 receives the packet from the SLG (the SLG 20 or the SLG 30) in the adjacent domain, the tunnel control unit 204 performs the termination processing described above (i.e., deletion of the packet header), and then requests the transfer destination determination unit 302 to process the packet.
Flow of Transfer Processing in Example
Hereinafter, as an example, in the NW configuration illustrated in
S101: First, the slice ID setting unit 203 of the SLG 202 refers to the 5-tuple-slice requirement correspondence table and specifies a slice requirement corresponding to 5-tuple information included in the packet from the terminal and also refers to the SLG-ID-address correspondence table and specifies an SLG ID “201” corresponding to a destination IP address included in the 5-tuple information. Then, the slice ID setting unit 203 of the SLG 202 provides, as a slice ID, the specified slice requirement and the specified SLG ID “201” to a header of the packet, and then requests the transfer destination determination unit 202 to process the packet.
S102: Next, the transfer destination determination unit 202 of the SLG 202 refers to the slice transfer table, and specifies (determines) a tunnel ID “4” corresponding to the slice requirement and the SLG ID “201” that are included in the slice ID provided to the packet in S101 described above. Then, the transfer destination determination unit 202 of the SLG 202 requests the tunnel control unit 204 to process the packet.
S103: Next, the tunnel control unit 204 of the SLG 202 encapsulates the packet in a tunnel header of a tunnel corresponding to the tunnel ID “4” determined in S102 described above, and then outputs the packet from the tunnel having the tunnel ID “4”. Note that, at this time, transfer priority and the like are set for the tunnel header.
S201: Next, when the tunnel control unit 303 of the SLG 302 receives the packet via the tunnel having the tunnel ID “4”, the tunnel control unit 303 deletes the tunnel header from the packet. Then, the tunnel control unit 303 of the SLG 302 requests the transfer destination determination unit 302 to process the packet.
S202: Next, the transfer destination determination unit 302 of the SLG 302 refers to the slice transfer table, and specifies (determines) a tunnel ID “10” corresponding to the slice requirement and the SLG ID “201” that are included in the slice ID provided to the packet having the tunnel header deleted in S201 described above. Then, the transfer destination determination unit 302 of the SLG 302 requests the tunnel control unit 303 to process the packet.
S203: Next, the tunnel control unit 303 of the SLG 302 encapsulates the packet in a tunnel header of a tunnel corresponding to the tunnel ID “10” determined in S202 described above, and then outputs the packet from the tunnel having the tunnel ID “10”. Note that, at this time, transfer priority and the like are set for the tunnel header.
S301: Next, when the tunnel control unit 303 of the SLG 303 receives the packet via the tunnel having the tunnel ID “10”, the tunnel control unit 303 deletes the tunnel header from the packet. Then, the tunnel control unit 303 of the SLG 303 requests the transfer destination determination unit 302 to process the packet.
S302: Next, the transfer destination determination unit 302 of the SLG 303 refers to the slice transfer table, and specifies (determines) a tunnel ID “14” corresponding to the slice requirement and the SLG ID “201” that are included in the slice ID provided to the packet having the tunnel header deleted in S301 described above. Then, the transfer destination determination unit 302 of the SLG 303 requests the tunnel control unit 303 to process the packet.
S303: Next, the tunnel control unit 303 of the SLG 303 encapsulates the packet in a tunnel header of a tunnel corresponding to the tunnel ID “14” determined in S302 described above, and then outputs the packet from the tunnel having the tunnel ID “14”. Note that, at this time, transfer priority and the like are set for the tunnel header.
S401: Next, when the tunnel control unit 204 of the SLG 203 receives the packet via the tunnel having the tunnel ID “14”, the tunnel control unit 204 deletes the tunnel header from the packet. Then, the tunnel control unit 204 of the SLG 203 requests the slice ID setting unit 203 to process the packet.
S402: Next, the slice ID setting unit 203 of the SLG 203 determines whether the SLG ID “201” included in the slice ID provided to the packet having the tunnel header deleted in S401 described above matches the SLG ID “201” of itself. In the present example, since these SLG IDs are determined to match, the tunnel control unit 204 of the SLG 203 deletes the slice ID provided to the packet. Then, the slice ID setting unit 203 of the SLG 203 requests the transfer destination determination unit 202 to process the packet.
S403: Next, since the slice ID is not provided to the packet, the transfer destination determination unit 202 of the SLG 203 outputs the packet to the terminal, the server/VM, and the like by normal routing and the like (i.e., routing according to a destination IP address, and the like).
As described above, the packet from the terminal is transmitted to the server/VM and the like via the slice. Note that, in
Hardware Configuration
Lastly, a hardware configuration of the NW controller 10, the SLG 20, and the SLG 30 according to the present embodiment will be described.
NW Controller 10
As illustrated in
The input device 501 is a keyboard, a mouse, or a touch panel, for example. The display device 502 is, for example, a display. Note that the NW controller 10 does not necessarily include at least one of the input device 501 and the display device 502.
The external I/F 503 is, for example, an interface with an external device such as a recording medium 503a. Examples of the recording medium 503a include a compact disc (CD), a digital versatile disc (DVD), a secure digital memory card (SD memory card), and a universal serial bus (USB) memory card.
The communication I/F 504 is an interface for connection with a communication network. The processor 505 is, for example, an arithmetic operation device such as a central processing unit (CPU). The memory device 506 is, for example, any storage device such as a hard disk drive (HDD), a solid state drive (SSD), a random access memory (RAM), a read only memory (ROM), or a flash memory.
The NW controller 10 according to the present embodiment has the hardware configuration illustrated in
SLG 20 and SLG 30
As illustrated in
The external I/F 601 is an interface with an external device such as a recording medium 601a. Note that examples of the recording medium 601a include a micro SD, a USB memory card, and the like.
The communication I/F 602 is an interface for connection with a communication network. The processor 603 is an arithmetic operation device such as a CPU. The memory device 604 is any of various storage devices such as a flash memory, a RAM, and a ROM.
The SLG 20 and the SLG 30 according to the present embodiment have the hardware configuration illustrated in
The present invention is not limited to the above-described embodiment disclosed specifically, and various modifications or changes, combinations with known techniques, and the like can be made without departing from description of the claims.
10 NW controller
20 SLG
30 SLG
101 Inter-domain cooperation unit
102 SLG management unit
201 Table management unit
202 Transfer destination determination unit
203 Slice ID setting unit
204 Tunnel control unit
301 Table management unit
302 Transfer destination determination unit
303 Tunnel control unit
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/JP2020/007226 | 2/21/2020 | WO |