METHOD AND SYSTEM FOR ESTABLISHING AND MANAGING MULTI-DOMAIN VIRTUAL TUNNEL (MVT)

Abstract

In a method and apparatus for operating a virtual tunnel, a control entity receives a request to establish a virtual tunnel between specified endpoints, and the control entity and domain controllers assemble resources forming a virtual tunnel consistent with the requested virtual tunnel through domains controlled by the domain controllers between specified endpoints.

Description

FIELD OF THE INVENTION

The present invention describes generally to Software-Defined Networking, and especially to establishing and managing a Virtual Tunnel in a hybrid (physical and virtualized) network/service environment.

BACKGROUND OF THE INVENTION

In general, a tunnel is an end-to-end channel or path and especially a channel where intermediate nodes can quickly route a stream of packets or other data flow based on rapidly recognizable headers and/or prefixes without the intermediate node interacting with the data content of the flow. An intermediate node may use, for example, a table, a hash, a stack, etc., for rapid routing.

The ports in a node can be physical or virtual. The ports typically have physical and logical identifiers, and may be identified by physical identifiers, logical identifiers, or both. Examples of physical identifiers include MAC address, Device Identifier, physical location and address, GPS Identifier, etc. Examples of logical identifiers include IP (v4 or v6 or both) address, subnet Identifier, network Identifier, domain name, autonomous system (AS) name/Identifier, etc.

Traditional methods and mechanisms for establishing and managing an end-to-end (ETE) multi-domain tunnel utilize predominantly physical resources (ports, nodes, links, etc.) and semi-automated processes. In particular, the coordination of different domains to provide path segments that connect end-to-end at a port of each domain, and that provide a consistent Quality of Service, typically requires human intervention. These mostly manual mechanisms are both complex and time consuming and hence prone to human errors.

BRIEF SUMMARY OF THE INVENTION

This specification focuses on developing a method/system for establishing and managing a Multi-domain Virtual Tunnel (MVT) in hybrid (physical and virtualized) network/service environment.

The proposed method uses a Software-Defined Networking (SDN) based architecture. See, for example, B. Khasnabish, J. Hu, and G. Ali, “Virtualizing Network and Service Functions: Impact on ICT Transformation and Standardization,” ZTE Communications Magazine, pp.40-46, Issue 4 (December), 2013. That architecture can support the flexibility of clear separation of Applications/services, control, virtualization, and forwarding layers.

An embodiment of a method of operating a virtual tunnel comprises receiving, by a control entity, a request to establish a virtual tunnel between specified endpoints; and assembling, by the control entity and domain controllers, resources forming a virtual tunnel consistent with said requested virtual tunnel through domains controlled by the domain controllers between specified endpoints.

An embodiment of an apparatus for operating a virtual tunnel, comprises a control entity operative to receive a request to establish a virtual tunnel between specified endpoints; and domain controllers operative to cooperate with said control entity to assemble resources to form a virtual tunnel consistent with said requested virtual tunnel through domains controlled by the domain controllers between specified endpoints.

In other aspects, the invention provides systems, methods, and computer program products having features and advantages corresponding to those discussed above.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

FIG. 1A shows a high-level software defined networking (SDN) based architecture for apps- or service-triggered tunnel establishment.

FIG. 1B shows virtualizatizon of layer-2 (L2) and layer-3 (L3) network entities functions and links for unified control and management.

FIG. 2 describes a system and architecture for Layer-2 (L2) port virtualization and assignment.

FIG. 3 describes a system and architecture for Layer-3 (L3) port virtualization and assignment.

FIG. 4 describes a system and architecture for Layer-2 (L2) link. virtualization and assignment.

FIG. 5 describes a system and architecture for Layer-3 (L3) link virtualization and assignment.

FIG. 6 demonstrates concatenation of virtualized ports and links for establishing and managing an end-to-end tunnel.

FIG. 7 shows lifecycle management of physical/virtual ports and links.

DETAILED DESCRIPTION OF THE INVENTION

The present inventions now will be described more fully hereinafter with reference to the accompanying drawings.

Embodiments of the present methods and apparatus will now be described more fully hereinafter with reference to the accompanying drawings, in which some examples of the embodiments are shown. It is to be understood that the figures and descriptions provided herein may have been simplified to illustrate elements that are relevant for a clear understanding of the present methods and apparatus, while eliminating, for the purpose of clarity, other elements found in typical Software Defined Networking (SDN) systems and methods. Those of ordinary skill in the art may recognize that other elements and/or steps may be desirable and/or necessary to implement the devices, systems, and methods described herein. However, because such elements and steps are well known in the art, and because they do not facilitate a better understanding of the present systems and methods, a discussion of such elements and steps may not be provided herein. The present disclosure is deemed to inherently include all such elements, variations, and modifications to the disclosed elements and methods that would be known to those of ordinary skill in the pertinent art. Indeed, these disclosures may be embodied in many different forms and should not be construed as limited to the embodiments set forth therein; rather, these embodiments are provided by way of example so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout.

Referring to the drawings, and initially to FIG. 1A, one embodiment of a Software Defined Networking (SDN) based architecture includes a generic network applications and services layer, a generic control layer, and a physical infrastructure layer. The generic control layer is connected to the generic network applications and services layer by “northbound” interfaces (NBIs), and to the physical infrastructure layer by “southbound” interfaces.

The generic network applications and services layer contains applications and services which may include, for example, any of tunnel apps, topology apps, Any Network Interconnection (XNI), for example, access and Transport, apps, and Networking as a Service (NaaS), including Virtual Private Networking as a Service (VPNaaS) Apps. IN an embodiment, the northbound interfaces through which the applications and services in the generic network applications and services layer interact with the elements and entities in the generic control layer are REpresentional State Transfer (REST) systems, which may communicate over HTTP, consistently with IETF RFCs 7230 through 7235 using verbs {GET, POST, PUT, DELETE, etc.} defined to send data to remote servers.

The generic control layer includes various domain controllers which may include any or all of OpenFlow Controller and Configurator, BGP Route Controller, and SPRING Control-Domain. Those domain controllers are mentioned only by way of example, and the generic control layer may include other domain controllers instead of, or in addition to, those mentioned. Each of these domain controllers controls devices in the physical infrastructure layer that belong to its respective domain. As will be discussed in more detail below, a “domain” may be any part of the physical infrastructure layer that can be effectively controlled by a single controller etc. A “domain” may be defined by physical location, ownership, physical interface or interface protocol to the domain controller, or any other expedient constraint. A domain may be physical or virtual. The present embodiment may be a hybrid system, in which some domains are physical and some domains are virtual.

In general, each domain has the capability of forwarding a data flow from a port at one boundary of the domain to a port at another boundary of a domain, or in the case of the domains in which a data flow originates and terminates, has the capability of forwarding the data flow from its origin to a port at a boundary of the domain or from a port at a boundary of the domain to its destination. In general, each domain has at its port or port a capability of interfacing to a port of another domain and of forwarding a data flow to or from that other domain.

Each individual domain, and the functionality of each individual domain controller that controls the respective domain, may be conventional and in the interests of conciseness is not further described.

However, as shown in FIG. 1A and as described in more detail below, the various domain controllers within the generic control layer are also linked to one another by “east-west interfaces,” enabling the controllers to communicate and coordinate their various domains.

By linking domains port-to-port, it is possible to construct a continuous data. path from the data source to the data destination. In this embodiment, a “tunnel” is a continuous data channel that is preferably configured for speedy and efficient end-to-end (ETE) data. flow. In this embodiment, a Multi-Domain Virtual Tunnel (MVT) is a tunnel that extends over more than one domain, where the intermediate nodes and links can be in different administrative domains, and in which some or all of the domains may be virtual or logical domains rather than domains defined as consisting of contiguous physical infrastructure.

The assignment of ports to a tunnel may be administered by authorized entities via an authenticated open control interface. This adds desirable flexibility and scalability to establishing and managing an MVT. FIG. 1B illustrates the virtualization of physical Layer 2 and Layer 3 network entities, such as functions and links, for unified control and management. As shown in FIG. 1B, physical Layer 2 and Layer 3 network entities are grouped into categories, and within each category are virtualized as virtual Layer 2 and Layer 3 network entities. The categories are represented in FIG. 1B and some of the other drawings by different styles of hatching, and may be referred to by color codes such as “Black category,” “Blue category,” and “Green category.” One physical entity may be virtualized in more than one way, to allow different modes of management. Several categories may be gathered under the control of a single logical control and management entity in the generic control layer.

FIG. 2 illustrates a specific embodiment of the architecture of FIG. 1B, for the virtualization and common control and management of multiple categories of physical layer 2 ports.

FIG. 3 illustrates a specific embodiment of the architecture of FIG. 1B, for the virtualization and common control and management of multiple categories of physical layer 3 ports.

FIG. 4 illustrates a specific embodiment of the architecture of FIG. 1B, for the virtualization and common control and management of multiple categories of physical layer 2 links.

FIG. 5 illustrates a specific embodiment of the architecture of FIG. 1B, for the virtualization and common control and management of multiple categories of physical layer 3 links.

FIG. 6 illustrates a specific instance of the architecture of FIG. 1B, in which the common control and management entity in the generic control layer has assembled. and concatenated or stitched a series of specific virtual network entities to form an end-to-end tunnel from a tunnel ingress entity to a tunnel egress entity (not shown in FIG. 6). Each of the selected virtual entities corresponds to a physical entity, so that the virtual tunnel represents a physical tunnel that can transmit physical signals (for example, electrical voltages or radio waves) carrying data. In the interests of simplicity, the virtual tunnel is shown passing through several virtual network entities of each of three categories in turn. However, this is only an example. As is shown in FIG. 1A, where a control domain is defined by, for example, the type of device controlled, the tunnel may enter that domain more than once at different geographical locations. In the interests of simplicity, the tunnel is shown as being defined entirely in the virtual network entity layer. However, this is only an example. As is shown in FIG. 1A, the tunnel may be a hybrid tunnel, in which some physical entities are controlled directly, and not virtualized.

The use of virtualized resources like ports, links, nodes, etc., is in general preferred, because it can provide additional agility in resources availability and allocations.

The use of a centrally controlled software module in the Controller layer (domain) of the SDN architecture supports desired flexibility in establishing and managing the end-to-end MVT.

Establishing a Multi-Domain Virtual Tunnel—an end-to-end channel where the intermediate nodes and links can be in different administrative domains—calls for temporarily concatenating pre-allocated or available ports and links with the objective of temporarily creating an ETE path from a source to a destination. This helps rapid routing (using table, hash, stack, etc.) of the stream-of-packets or flows based on quickly recognizable headers and/or prefixes.

A software defined networking (SDN) based architecture is used that supports an apps- or service-triggered ETE process for establishing a path (e.g., a tunnel). A system and architecture are also provided for virtualization and assignment of layer-2 and layer-3 ports and links. a mechanism to support concatenation of virtualized ports and links for establishing and managing an end-to-end tunnel is also provided.

The described embodiment makes use of the following features:

The use of an SDN-based architecture allows separation of Apps, Control, Virtualization, and forwarding domains, as shown in FIGS. 1A and 1B.

Both physical and virtualized Layer-2 (L2) and Layer-3 (L3) resources, for example, links, ports, nodes, processes, etc. are used for ET tunnels, as shown in FIG. 1B.

Assignment (allocation) and management of both physical and virtual L2 and L3 resources are centralized, e.g., hosted in the Controller layer of the SDN architecture.

Simple concatenation of virtualized ports and links is used for establishing and managing end-to-end tunnels.

Basic lifecycle management of physical/virtual ports and links is applied, with the objective of preventing leakage of residual information, especially if resources (tunnels, Apps, services, etc.) are rapidly reassigned to different owners.

Referring now to FIG. 7, in an example of operation of an embodiment of the described system and method:

In step 702, Request, the user or prospective user (which is, or is acting through, an authorized App/service that needs an ETE tunnel) sends the request for tunnel setup to a Control layer/domain Element/entity, as shown in FIGS. 1A, 1B, and 6. The Request specifies a tunnel from one endpoint (identified by a parameter) to another endpoint. This parameter could be a physical or logical identifier, or both physical and logical identifiers. The physical identifiers may include MAC address, Device Identifier, physical location and address, GPS Identifier, etc. The logical identifiers may include IP (v4 or v6 or both) address, subnet Identifier, network Identifier, domain name, autonomous system (AS) name/Identifier, etc. This Control layer entity logically controls and manages the tunnel setup by stitching physical and virtual ports and links.

In step 704, Authenticate, the Control domain entity takes any necessary action to authenticate the identity of the requesting entity and the authority of the requesting entity to request the tunnel.

In step 706, Respond, the Control domain entity responds to the Requesting entity with a Tunnel ID, Service Type to be supported, and the Ingress and Egress endpoint IDs. These data may be embedded in a Tunnel name, e.g., “A2Z_Tunnel_02MBPS_Video_Chat_Service,” where A and Z are the Ingress and Egress endpoint IDs. The tunnel may be one-way, two-way, or asymmetric two-way (with bulk data flowing one way and only low-volume control and acknowledgement traffic flowing the other way).

In step 708, Accept, the Requesting App/Service domain entity verifies that the tunnel data specified are acceptable, and accepts the tunnel name and type.

In step 710, Assemble, the Control domain entity starts—as shown in FIG. 6—the process of requesting through open interface the individual domain controllers to provide virtual and physical resources (ports, link, nodes, process, etc.). The Control domain entity, and the individual domain controllers negotiating through their east-west interfaces, identify healthy resources, that is to say, resources that are properly functioning and have relevant available capacity.

In step 712, Assign, the resources selected in the Assemble step are assigned to the requested tunnel. This step includes setting up a routing table, hash, stack, or other configuration to ensure the prompt and reliable routing and forwarding of tunnel traffic through the intermediate domains.

Once a complete end-to-end tunnel has been assembled and assigned, in step 714, Activate, the tunnel resources are activated for the requested Tunnel service. In some architectures, e.g., the ETSI/ISG NFV Architecture as shown in FIG. 4 of the Network Functions Virtualisation (NFV); Architectural Framework (GS NFV 002, available from www.etsi.org), the Management and Orchestration domain entities may handle the Requests for Assign/Activate/Retrieve/Release of virtual resources for tunnel setup/release.

In step 716, Monitor, the requesting entity uses the tunnel to transmit data from the specified ingress endpoint to the specified egress endpoint. The Control domain entity may monitor the tunnel for compliance with a Service Level Agreement (SLA) or other criterion of acceptable operation. If the tunnel falls below a minimum criterion, for example, because a domain is overloaded with other traffic and cannot maintain the specified throughput or other Quality of Service requirement, the process may loop back to step 710 and the Control domain entity may repeat the Assemble/Assign/Activate steps to form a new tunnel, and redirect the traffic to the new tunnel. Where possible, the new tunnel is assembled and the traffic is switched over transparently to the end user.

In step 718, Close, when the original requesting Apps/Service domain entity no longer needs the tunnel for any service, the requesting Apps/Service domain entity sends a request to close the tunnel. Alternatively, if the tunnel, or a specific port or link or other entity or resource, was assigned only for a limited period, the Control domain entity may retrieve that resource when the limited period expires. If the tunnel is still valid, and only a specific network entity is retrieved, the process may then loop back to step 710, in the same way as if the specific network entity failed QoS monitoring.

In step 720, Release, the Control domain entity directs the domain controllers to release the tunnel resources. Each domain controller sanitizes the tunnel resources, for example, by purging any buffers or other temporary storage, and deleting routing table entries. Resources may be tested and fixed if appropriate. All the resources that were utilized by the tunnel are then released back into the pool of “Healthy” resources available for reassignment.

The use of lifecycle management of the resources like ports, links, nodes, etc., offers desirable privacy for the user and protection of the virtualized resources. Without proper management of the lifecycle for the physical and virtual ports and links, residual information could be leaked to improper users of resources, and that may lead to hacking and/or privacy violation. For example, incorrect reactivation of a buffer that has not been explicitly purged could result in a buffer full of the previous user's data being transmitted to the new user. Incorrect reactivation of a routing table entry that has not been explicitly purged could result in the new user's data being misdirected to the previous user's egress endpoint, or in improper disclosure that there has been communication between the previous user's ingress and egress endpoints.

In other aspects, the invention provides a system and a computer program having features and advantages corresponding to those discussed above.

Although the invention has been described and illustrated in exemplary forms with a certain degree of particularity, it is noted that the description and illustrations have been made by way of example only. Specific terms are used in this application in a generic and descriptive sense only and not for purposes of limitation. Numerous changes in the details of construction and combination and arrangement of parts and steps may be made. Accordingly, such changes are intended to be included in the invention, the scope of which is defined by the claims.

Claims

1-16. (canceled)

17. A method of operating a virtual tunnel, comprising: receiving, by a control entity, a request to establish a virtual tunnel between specified endpoints; andassembling, by the control entity and domain controllers, resources forming a virtual tunnel consistent with said requested virtual tunnel through domains controlled by the domain controllers between specified endpoints.

18. The method of claim 17, further comprising: using said assembled virtual tunnel or permitting the use of said assembled virtual tunnel to communicate between said endpoints.

19. The method of claim 18, further comprising monitoring a level of service provided by said assembled virtual tunnel for said use, and when said level of service becomes inadequate, assembling a new virtual tunnel and using or permitting the use of said new assembled virtual tunnel to communicate between said endpoints.

20. The method of claim 18, further comprising: when said using is completed, releasing said resources for other uses.

21. The method of claim 20, further comprising, after said using and before said releasing, sanitizing said resources.

22. The method of claim 17, wherein said resources comprise resources selected from the group consisting of physical resources and virtual resources.

23. The method of claim 22, wherein said resources comprise physical resources and virtual resources.

24. The method of claim 17, wherein said resources comprise resources selected from the group consisting of OSI model Layer 2 entities and OSI model Layer 3 entities.

25. The method of claim 24, wherein said resources comprise Layer 2 entities and Layer 3 entities.

26. A computer program product comprising instructions operative to cause a general purpose computer to carry out the method of claim 17.

27. A non-volatile computer readable storage medium containing a computer program product according to claim 26.

28. An apparatus for operating a virtual tunnel, comprising: a control entity operative to receive a request to establish a virtual tunnel between specified endpoints; anddomain controllers operative to cooperate with said control entity to assemble resources to forma virtual tunnel consistent with said requested virtual tunnel through domains controlled by the domain controllers between specified endpoints.

29. The apparatus of claim 28, further comprising apparatus operative to forward communications between ports, said apparatus organized in domains, each said domain controlled by a respective domain controller, wherein said domain controllers and said control entity are operative to cooperate to form said virtual tunnel by connecting said ports of said domains.

30. The apparatus of claim 28, further comprising a user entity operative to send said request to said control entity, and to use said virtual tunnel to communicate between said specified endpoints.

31. The apparatus of claim 28, wherein said domain controllers and said control entity are operative to sanitize said resources after use.