Methods for managing port types, function managers, and orchestration nodes

Abstract

Embodiments relate to a method for managing a network interface, for example, performed by an orchestration node. The orchestration node sends trunk port specific information of a trunk port to a function manager to enable the function manager to explicitly orchestrate the trunk port.

Description

Technical Field

[0001] Embodiments herein relate to an orchestration node for a communication network, a function manager, and methods executed therein. In particular, embodiments herein relate to managing port types in a communication network, and specifically to how to model and manage trunk-type communication ports of virtualized network function (VNF) applications in the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV)-Management and Orchestration (MANO) architecture and orchestration standard. Background Art

[0002] Generally, unless different meanings are clearly given and / or implied in the context of using the term, all terms used in this article will be interpreted according to their common meaning in the relevant technical field. Unless otherwise clearly stated, all references to one / an / the element, equipment, assembly, device, step, etc. should be openly interpreted as referring to at least one instance of the element, equipment, assembly, device, step, etc. Unless a step is clearly described as after or before another step and / or a step must be after or before another step implicitly, the steps of any method disclosed herein do not have to be performed in the exact order disclosed. Where appropriate, any feature of any embodiment disclosed herein may be suitable for any other embodiment. Similarly, any advantage of any embodiment may be suitable for any other embodiment, and vice versa. By the following description, other purposes, features and advantages of the attached embodiments will be clear.

[0003] NFV-MANO based orchestration and management can be implemented for managing network functions in any communication network such as a radio access network (RAN), or for network functions in a mobile core network (CN), in a service network such as an IP multimedia subsystem (IMS), in a user data management network, etc. In a typical communication network, a user equipment (UE) (also known as a wireless communication device, a mobile station, a station (STA), and / or a wireless device) communicates with one or more core networks (CNs) via a RAN. The RAN covers a geographic area divided into service areas or cell areas, each of which is served by a radio network node such as a radio access node, such as a Wi-Fi access point or a radio base station (RBS), which may also be denoted, for example, as a NodeB, eNodeB, or gNodeB in some networks.

[0004] In the European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) – Management and Orchestration (MANO) architecture for orchestration and lifecycle management of virtualized networks and virtualized network function (VNF) applications (see Figure 1), the NFV orchestrator (NFVO) interacts with the cloud’s virtualized infrastructure manager (VIM) to set up and manage network resources, while the delegated VNF manager (VNFM) interacts with the VIM to orchestrate and manage compute and storage resources as well as the network interfaces required for VNF instances in the cloud.

[0005] Figure 1 The NFV-MANO architecture components and ETSI specifications related to different components and interfaces are shown.

[0006] VNFM enables the interaction of VIM with the cloud infrastructure based on a combination of:

[0007] a) Information in a VNF Descriptor (VNFD), which is a Topology and Orchestration Specification for Cloud Applications (TOSCA) service template delivered with the software for the VNF. The VNFD is standardized according to the ETSI GS NFV-SOL001 specification, which describes how to model a VNF's network interfaces, its storage requirements, its compute resource requirements, its supported instantiation levels, supported deployment variations, and lifecycle management operations in a declarative syntax.

[0008] b) Information received from the NFVO over the Or-Vnfm reference point. VNFD is deployment-agnostic - details such as IP address, what deployment level to use, how many deployment units (e.g., virtual machines (VMs) or containers) to instantiate, etc. are information that the NFVO will provide to the VNFM for each specific VNF instance it wants to be created by the VNFM. The information elements used in the communication over the Or-Vnfm reference point are standardized in ETSI GS NFV-SOL003.

[0009] In terms of computer networks, an application consists of one or more deployment units, such as VMs, containers, central processing unit (CPU) boards, etc., which are modeled in VNFD by a concept called virtualized deployment unit (VDU). These deployments have network interfaces that connect to underlying network transport technologies such as virtual local access networks (VLANs), virtual extensible LANs (VXLANs), generic routing encapsulation (GRE), etc., through which they can communicate with other application units and / or with routers that connect the application to the outside world. These network interfaces are modeled in VNFD using a concept called connection point descriptor (CPD). CPD typically models an Ethernet interface on a VDU that connects the VDU to a single network. Such network interfaces are typically called access ports. Alternatively, CPD can represent a network interface through which a VDU is connected to multiple networks. Such a network interface is typically called an aggregation port. Summary of the invention

[0010] An access port, which can be considered a "normal" port, only connects a deployment unit to a single network. However, a trunk port can be considered a segmented network interface on a deployment unit through which the deployment unit can connect to multiple networks. In other words, a trunk port includes multiple sub-interfaces. The problem with the current specifications SOL001 of VNFD and SOL003 of the Or-Vnfm interface is that these specifications do not fully standardize what is required to create and manage trunk ports. As mentioned above, VNFD uses a construct called CPD to model the network interface on the VDU. CPD has an attribute "trunk_mode" which, if specified with a value of "true", indicates to the NFVO that this CPD represents a trunk port, and for the connection point (CP) instance modeled by this CPD, it should send information to the VNFM that enables the VNFM to create and manage the trunk port and its network sub-interfaces.

[0011] So the problem is that the specification SOL003 does not specify how to actually send the information for the CP instance modeled by the CPD that represents the trunk port, and does not specify how to support the use case of dynamic addition or removal of networks or network sub-interfaces for existing trunk ports. Because there is no specification and consensus on how to handle the inherent diversity and dynamic nature of sub-interfaces in trunk ports, it is entirely up to the interpretation of each NFVO and VNFM implementation.

[0012] A simple and straightforward approach could be to model each sub-interface of an aggregation port as its own CPD in the VNFD. However, the disadvantage is that, for example, using an aggregation port to connect a VNF to a tenant (e.g. enterprise) specific network where it needs to support access to many (e.g. one hundred or more) enterprise / tenant networks results in the VNFD needing to model a very large number of CPDs for the VDU. Furthermore, modeling each network termination within an aggregation port as its own CPD may provide very poor support for the use case of adding or removing network sub-interfaces on demand to an aggregation port of an already existing VNF instance. Basically, this means that the VNFD needs to be updated, providing a new version of the TOSCA service template, and then the VNF needs to be updated for each change. This will most likely also require updating the network service descriptors used by the NFVO.

[0013] Adding or removing tenant networks occurs during runtime, and it is not possible to change the VNFD of a running service without obstruction, which is obviously completely prohibitive for modeling even a small number of tenants. Therefore, it is necessary to provide a solution that solves one or more of the above problems to achieve efficient processing of data communications in a communication network.

[0014] According to one aspect, the object is achieved by providing a method for managing network interfaces, such as aggregated network interfaces, performed by an orchestration node, such as an NFVO. The orchestration node sends aggregated port specific information of an aggregated port to a function manager, such as a network function manager, such as a VNFM, so that the function manager can unambiguously orchestrate the aggregated port. Therefore, a method for managing ports, such as orchestrating aggregated ports, is provided herein. The method may update SOL003, detailing how the NFVO may provide aggregated port specific information to the VNFM so that the VNFM can unambiguously orchestrate a solution for aggregated ports, including allowing aggregated port connections to different networks to be added or removed on demand without having to update the VNFD. The method may additionally or alternatively use the existing VNFD model specified in SOL001, with a single CPD for each port, whether it is an aggregated port or a normal port, indicating only whether the CPD models an aggregated port or a normal port (via a trunk_mode attribute). The trunk_mode attribute is information about whether a CP instantiated from the CPD is in aggregated mode. When operating in "aggregated mode", the CP is able to carry traffic for several VLANs.

[0015] According to another aspect, the object is achieved by providing a method for managing a network interface executed by a function manager: the function manager receives trunk port specific information of a trunk port from an orchestration node; and orchestrates the trunk port based on the received trunk port specific information.

[0016] According to another aspect, the object is achieved by providing an orchestration node (e.g., NFVO) for managing a network interface. The orchestration node is adapted to send aggregation port specific information of an aggregation port to a function manager (e.g., VNFM) so that the function manager can explicitly orchestrate the aggregation port.

[0017] According to another aspect, the object is achieved by providing a function manager for managing network interfaces. The function manager is adapted to receive trunk port specific information of a trunk port from an orchestration node, and orchestrate the trunk port based on the received trunk port specific information.

[0018] Because the trunk port specific information enables the function manager to explicitly orchestrate the trunk ports, the embodiments herein enable efficient handling of data communications in the communication network for both mobile and fixed networks. For example, it allows networks (eg, VLANs) to be dynamically added and removed during orchestration. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Embodiments will now be described in more detail with reference to the accompanying drawings, in which:

[0020] Figure 1 NFV-MANO architecture components according to the prior art are shown;

[0021] Figure 2A is a schematic overview diagram depicting a communication network for implementing embodiments of the present invention;

[0022] Figure 2B It is the system details including NFVO and VNFM;

[0023] Figure 3 is a block diagram depicting new attributes in IpOverEthernetAddressData in Or-Vnfm according to some embodiments;

[0024] Figure 4 is a process sequence according to the embodiment of this article;

[0025] Figure 5A is a schematic flow chart depicting a method performed by an orchestration node according to an embodiment of the present invention;

[0026] Figure 5B is a schematic flow chart depicting a method performed by a function manager according to an embodiment of the present invention;

[0027] Figure 5C is a schematic flow chart depicting a method performed by an orchestration node according to an embodiment of the present invention; and

[0028] Figure 6 is a block diagram depicting an orchestration node and a function manager according to embodiments herein. DETAILED DESCRIPTION

[0029] The embodiments herein relate to implementation of a VNF and a virtualized NFV-MANO architecture for using network resources (e.g., resources of radio network nodes and / or network nodes) of a RAN, IP Multimedia Subsystem (IMS) and / or CN. Therefore, the proposed solution can be implemented in any communication network and the embodiments therefore generally relate to communication networks. Figure 2Ais a schematic overview depicting an exemplary communication network 1, which is used only to illustrate an embodiment. The communication network 1 may include, for example, one or more access networks, such as a radio access network (RAN), such as a first RAN (RAN1), connected to one or more core networks (CN). The communication network 1 may use a variety of different technologies, such as Wi-Fi, Long Term Evolution (LTE), Advanced LTE, 5G, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications / Enhanced Data Rates for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax) or Ultra Mobile Broadband (UMB), to name just a few possible embodiments. The embodiments herein relate to the latest technology trends of particular interest in the context of 5G, however, the embodiments are also suitable for further development of existing communication systems (such as 3G and LTE).

[0030] In the exemplary communication network 1, a user equipment (UE), for example, UE 10, such as a mobile station, a non-access point (non-AP) station (STA), a STA, a wireless device and / or a wireless terminal, is connected to one or more CNs via one or more RANs. It should be understood by those skilled in the art that "UE" is a non-limiting term that refers to any terminal, wireless communication terminal, user equipment, machine type communication (MTC) device, Internet of Things (IoT) operable device, device to device (D2D) terminal, mobile device, such as a smartphone, a laptop, a mobile phone, a sensor, a relay, a mobile tablet or any device that communicates with a cell or a service area.

[0031] The communication network 1 comprises a radio network node 12 of a first radio access technology (RAT) (e.g. New Radio (NR), LTE, UMTS, Wi-Fi or similar) which provides radio coverage over a geographical area, a service area 11 or cell. The radio network node 12 may be a radio access network node, such as a radio network controller or access point, such as a wireless local area network (WLAN) access point or access point station (AP STA), an access controller, a base station (e.g. a radio base station, such as a NodeB, an evolved Node B (eNB, eNodeB), a gNodeB), a base transceiver station, an access point base station, a base station router, a transmission arrangement of a radio base station, a standalone access point, or any other network element capable of serving UEs within a service area served by the radio network node 12, depending on, for example, the first radio access technology and terminology used.

[0032] The communication network 1 also includes network nodes 13, such as RAN nodes and / or core network nodes, for example radio software defined network (SDN) nodes, access and mobility management function (AMF) nodes, mobility management entity (MME), serving gateway (S-GW), serving GPRS support node (SGSN) nodes or corresponding nodes in, for example, a 5G network or similar networks. GPRS means General Packet Radio Service.

[0033] Embodiments herein extend the capabilities of the NFV-MANO standard framework to model the aggregation port attachment of multiple networks for software deployment units such as "virtual machines" and "operating system containers" that are virtual network function (VNF) products from an orchestration and management perspective.

[0034] The NFV-MANO indicates what and where resources (e.g., processing power and memory storage of, for example, network nodes in the communication network 1) are localized and used for the virtual network. The NFV-MANO architecture includes an orchestration node 14, which may include an NFVO that delegates the orchestration of individual VNFs to a function manager, such as a VNFM. The orchestration node 14 may also include a function manager. The NFVO provides deployment specific parameters, such as an IP address, what deployment level to use, how many deployment units (e.g., VMs or containers) to be instantiated, etc., to the function manager for the VNF instance to be created by the function manager. It should be noted that the orchestration node 14 may be an independent node or a distributed network node, which includes functions distributed across multiple network nodes (e.g., network node 13).

[0035] According to embodiments of the present invention, the NFVO of the orchestration node 14 can configure the settings of the VNFM in the communication network 1 by instructing a function manager (e.g., VNFM) that can be a standalone node or co-located with the orchestration node 14. In the communication to the VNFM, according to the current SOL003, the NFVO should send a list of connection point information elements per network, where each connection point information element refers to a real-time instance of a connection point / port connected to the network. The embodiments of the present invention extend this so that for a CPD representing an aggregation port, the NFVO can instead include a connection point information element for each network sub-interface of the aggregation port CPD. Each of these connection point information elements references the same CPD in the VNFD in its "cpdId" attribute, so the VNFM can understand that although the connection point information elements are used to connect to different networks, they actually belong to the same aggregation port definition. Therefore, for each sub-interface of the aggregation port CPD, the NFVO can include a network id / name that identifies the external network in the context of the VNF.

[0036] Furthermore, according to some embodiments, a "segmentationId" attribute may be added to the connection point data information, which provides the following:

[0037] When an application sends or receives a packet in real time through a trunk port, the segment id in the packet header identifies which network the packet is associated with. A cloud that supports trunk ports can use it in one of two ways.

[0038] ◆In a cloud like Openstack, the segmentation id is an identifier used to identify the network sub-interface of the trunk port in question between the application and the cloud network infrastructure. The cloud infrastructure will remap this local segmentation id to whatever segmentation id the cloud transport technology actually uses - it could be a VLAN id, a VXLAN segment id, a GRE tunnel id, etc. In this case, when a network is attached to a trunk port, the VNFM needs to be told so it can inform the VIM about which local segmentation id the application will use for each specific network, and the segmentationId in the attachment point information element is used for this purpose. Furthermore, dynamically adding or removing networks connected to a trunk port requires identifying in the Or-Vnfm communication exactly which network's sub-interface should be added / removed from the trunk port. The SegmentationId is also used for this purpose.

[0039] ◆ In a cloud like VMware, the segment id used by the application must actually be the network identifier used in the transport header of the packets transported by the network infrastructure, such as a VLAN id, VXLAN segment id, etc., and is then not remapped to any infrastructure and transport technology specific segment id. In this case, there is actually no real need to include the segment id in the attachment point information element, because the cloud infrastructure can anyway just inspect the segment id it receives in the packet header and it knows that it is associated with the network that the trunk port is connected to. However, in this case, it is recommended to always include the segment id anyway, because it makes it more obvious that the information element refers to the network subinterface of the trunk port with the corresponding segment id.

[0040] Certain usages may require a segment id that is unique to the VNF, i.e. if two different aggregation ports in a VNF have network subinterfaces connected to the same network, the segment id should be the same.

[0041] Note also that while trunking ports is understood in the context of VLANs, similar embodiments may be used with other network segmentation methods.

[0042] Exemplary advantages of some embodiments include the following:

[0043] It allows networks (such as VLANs) to be dynamically added and removed during orchestration, for example when VLANs are used for tenant isolation, without changing the CPD of the VNFD, i.e. without changing the VNF model.

[0044] It supports the following two cases where port specific information (such as segment id, i.e. tag) is aggregated:

[0045] It is actually a network identifier used in the transport header of packets transported by the network infrastructure, such as VLAN id, VXLAN segment id, etc.

[0046] An identifier used between an application and the cloud network infrastructure to identify the network in question - typically then exchanged in the headers of packets transmitted between the application and the network infrastructure.

[0047] The proposed solution is completed and planned to cause minimum disruption to the existing ETSI MANO framework.

[0048] According to other aspects of the proposed solution, one or more of these advantages may be provided in a system of NFVO, VNFM and VIM nodes with an emphasis on NFVO and VNFM communications.

[0049] According to some embodiments, one or more of the following may be included:

[0050] A CPD with trunk_mode set to true in the VNFD is used to indicate connectivity to all networks in the trunk port.

[0051] A single virtual link requirement in a VNFD can be used as a requirement for a virtual link that supports any of the following:

[0052] o an untagged (non-segmented) network—provided the CPD for which this request is valid has "trunk_mode = false"

[0053] o A group of tagged networks, such as a group of VLANs, if the CPD has "trunk_mode=true"

[0054] ·During lifecycle management, NFVO provides an element ExtVirtualLinkData for each network interfaced by a VNF instance to the VNFM. Within this element, there is a set of elements of type VnfExtCpData, one for each Connection Point (CP) instance, i.e. representing the network interface connected to that network, and this does not take into account whether the network interface is a sub-interface of a trunk port or a normal port interface. There can be one extCP (type VnfExtCpData) per CPD instance, but then inside the VnfExtCpData, there can be one cpConfig (type VnfExtCpConfig) per CP instance. The vnfExtCpData already includes a reference to the CPD that models the trunk port in the VNFD - the cpdId, allowing the VNFM to correctly identify to which trunk port the CP instance belongs. All vnfExtCpData related to the same CPD in the VNFD should indicate the same cpdId.

[0055] Each configuration VnfExtCpConfig of an element of type VnfExtCpData associated with a network sub-interface in an aggregation port may also include the SegregationId in the configuration of its IpOverEthernetAddressData sent over Or-Vnfm, if the cloud supports remapping of segmentation ids, such as is the case for vanilla Openstack.

[0056] According to further aspects, the present disclosure further proposes enhancements to the lifecycle management (LCM) operation method between NFVO and VNFM, including one or more of the following.

[0057] LCM operations are enhanced to use the syntax and semantics of the above system when:

[0058] οInstantiate the VNF, i.e., InstantiateVnfRequest operation;

[0059] οChange the external connectivity of the VNF, that is, ChangeExtVnfConnectivityRequest operation.

[0060] NFVO issues a ChangeExtVnfConnectivityRequest lifecycle management operation whenever a new network / network segment is added to or removed from an aggregate port, for example, for adding a network such as a tenant specific VLAN.

[0061] Figure 2BThe system details including NFVO and VNFM are shown, which communicate using the Or-Vnfm interface. NFVO (i.e., orchestration node 14) can include enhanced model semantics. The Or-Vnfm interface transmits enhanced configuration data, and VNFM shows enhanced operation methods that support dynamic creation and removal of segmented networks.

[0062] Figure 3 A new attribute in IpOverEthernetAddressData in Or-Vnfm according to some embodiments is shown, where the new attribute is defined as segmentationId. SegmentationId is a string data type with a cardinality of 0-1. SegmentationId may appear when a Cp instance is part of a trunk port.

[0063] Figure 4 A sequence diagram for adding / removing tenants and VLANs according to some embodiments presented herein is shown. Action 401: Deploy new VNF with tenants 1 and 3. Action 402: NFVO sends instantiateVNFrequest to VNFM. Action 403: At VNFM, instantiate VNF with configuration for segmentationId 0, 1 and 3. Action 404: VNFM sends Op.Occ.Notification to NFVO. Action 405: Add tenants 6 and 7. Action 406: NFVO sends changeExtVnfConnectivityRequest to VNFM. Action 407: Add new subnet with segmentationId 6 and 7. Action 408: VNFM sends Op.Occ.Notification to NFVO. Action 409: Remove tenants 3 and 6. Action 410: NFVO sends changeExtVnfConnectivityRequest to VNFM. Action 411: Remove subnet with segmentationId 3 and 6. Action 412: VNFM sends Op.Occ.Notification to NFVO.

[0064] Now refer to Figure 5A The flowchart depicted in the figure is used to describe the method actions for managing network interfaces performed by the orchestration node 14 according to the embodiment. These actions do not have to be performed in the order described below, but can be performed in any suitable order. The actions performed in some embodiments are marked with dashed boxes.

[0065] Action 501: Orchestration node 14 may establish that the trunk port is a trunk port type including multiple network sub-interfaces.

[0066] Action 502: Orchestration node 14 may associate corresponding aggregation port specific information with each network sub-interface of the aggregation port. Orchestration node 14 may associate corresponding aggregation port specific information with each network sub-interface of the aggregation port, for example, by adding a segment identifier to the configuration. The aggregation port specific may include a network identifier and conditionally include a segment id, for example, for an openstack VIM, the segment id is optional - if not provided, the VIM will assign a segment id, for a VMware VIM, the segment id is the same as the vlan id and does not need to be provided by the NFVO.

[0067] Action 503: The orchestration node 14 sends the aggregation port specific information of the aggregation port to the function manager to enable the function manager to explicitly orchestrate the aggregation port. For example, there may be a network id / label / name of the network of the subport. The orchestration node 14 may be a network function virtualization orchestrator and / or the function manager may be a virtualized network function manager. If the Cp instance represents a subport in the aggregation, a segmentationId may be present. The aggregation port specific information may include an identifier used between the application and the network infrastructure to identify the network sub-interface of the aggregation port in question. Depending on the NFVI network infrastructure, the segmentationId may indicate the actual network segmentation value used in the transport header of the packet, such as vlan Id, Vxlan segment id, etc., or it may be an identifier used between the application and the NFVI network infrastructure to identify the network sub-interface of the aggregation port in question. In the latter case, the NFVI infrastructure will map the local segmentationId to any segmentationId actually used by the transport technology of the NFVI. The aggregation port specific information may include an identifier, such as a segmentationId for each network sub-interface of the aggregation port. The aggregation port specific information may include a sub-interface network identifier or a sub-interface network tag, which identifies to which network the network sub-interface is connected.

[0068] Now refer to Figure 5B The flowchart depicted in describes method actions performed by a function manager for managing network interfaces according to an embodiment.

[0069] Action 511: The function manager receives the aggregation port specific information of the aggregation port from the orchestration node 14, for example, the Cp instance represents a subport in the aggregation, and the segmentationId should be present. The aggregation port specific information includes an identifier used between the application and the network infrastructure to identify the network sub-interface of the aggregation port in question. The aggregation port specific information includes an identifier for each sub-interface of the aggregation port, and the segmentationID sent in action 503, for example, and the aggregation port specific information includes a sub-interface network identifier or a sub-interface network tag, which identifies which network the network sub-interface is connected to.

[0070] Action 512: The function manager orchestrates the aggregate port based on the received aggregate port specific information. Orchestration node 14 may be a network function virtualization orchestrator and / or the function manager may be a virtualized network function manager. Orchestration node 14 and the function manager may be included in the same or different network nodes. The function manager may orchestrate the aggregate port by adding and / or removing network sub-interfaces to / from the aggregate port based on the received aggregate port specific information.

[0071] Figure 5C An exemplary flow chart showing a method for managing port types including a plurality of network sub-interfaces performed by orchestration node 14 according to some embodiments, wherein the method includes:

[0072] Establishing S220 based on the first information element that the port is of the port type;

[0073] Associating the information element of the first information element with each sub-interface of the port S240; and

[0074] Said information element for each sub-interface is sent S260 to the function manager.

[0075] Figure 6A block diagram depicting an orchestration node 14 and a function manager (FM) for managing network interfaces is shown. The orchestration node 14 is adapted to send aggregate port specific information of an aggregate port to the function manager in a manner that the function manager can explicitly orchestrate the aggregate port. The aggregate port specific information may include an identifier used between the application and the network infrastructure to identify the network sub-interface of the aggregate port in question. The orchestration node 14 may also be adapted to establish the aggregate port as an aggregate port type including multiple network sub-interfaces; and associate corresponding aggregate port specific information with each network sub-interface of the aggregate port. The aggregate port specific information may include an identifier for each network sub-interface of the aggregate port. The orchestration node may be a network function virtualization orchestrator and / or the function manager may be a virtualized network function manager. The orchestration node may be adapted to associate corresponding aggregate port specific information with each network sub-interface of the aggregate port by adding a segment id to the configuration. The aggregate port specific information may include a sub-interface network identifier or a sub-interface network tag, identifying which network the network sub-interface is connected to.

[0076] The function manager is adapted to receive the aggregation port specific information of the aggregation port from the orchestration node 14; and to orchestrate the aggregation port based on the received aggregation port specific information. The aggregation port specific information may include an identifier of a network sub-interface used between the application and the network infrastructure to identify the aggregation port in question. The aggregation port specific information may include an identifier for each network sub-interface of the aggregation port. The aggregation port specific information may include a sub-interface network identifier or a sub-interface network tag, identifying which network the network sub-interface is connected to. The function manager may be adapted to orchestrate the aggregation port by adding and / or removing network sub-interfaces to / from the aggregation port based on the received aggregation port specific information.

[0077] Although the processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0078] The present disclosure also discloses some embodiments:

[0079] 1. A method for managing a port type including a plurality of network sub-interfaces, performed by an orchestration node, the method comprising:

[0080] establishing, based on the first information element, that the port belongs to the port type;

[0081] associating an information element of the first information element with each sub-interface of the port; and

[0082] The information element for each sub-interface is sent to the function manager.

[0083] 2. The method of embodiment 1 further comprising associating an identifier with each sub-interface of the port.

[0084] 3. A method according to any one of embodiments 1 and 2, wherein the orchestration node is a network function virtualization orchestrator.

[0085] 4. The method according to any one of embodiments 1 to 3, wherein the function manager is a virtualized network function manager.

[0086] 5. The method of any one of embodiments 2 to 4, wherein associating an identifier with each sub-interface of the port comprises adding a segment id to a data structure.

[0087] 6. The method according to any one of embodiments 2 to 5, wherein the identifier comprises a sub-interface network identifier or a sub-interface network tag, identifying which network the sub-interface is connected to.

[0088] 7. A node method for managing a port type including a plurality of network sub-interfaces, the node being adapted to:

[0089] establishing, based on the first information element, that the port belongs to the port type;

[0090] associating an information element of the first information element with each sub-interface of the port; and

[0091] The information element for each sub-interface is sent to the function manager.

[0092] It should be understood that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and devices taught herein. Therefore, the devices and techniques taught herein are not limited by the foregoing description and the accompanying drawings. Instead, the embodiments herein are limited only by the following claims and their legal equivalents.

[0093] abbreviation

[0094] abbreviation explain

[0095] CP connection point

[0096] CPD CP Descriptor

[0097] ETSI European Telecommunications Standards Institute

[0098] LCM Lifecycle Management

[0099] NFV Network Function Virtualization

[0100] NFVI NFV infrastructure resources (compute, storage, network)

[0101] NFV-MANO ETSI NFV Lifecycle Management and Orchestration Architecture

[0102] NFVO NFV Orchestrator

[0103] TOSCA is a topology and orchestration specification for cloud applications.

[0104] VDU Virtualization Deployment Unit

[0105] VIM Virtualization Infrastructure Manager

[0106] VM Virtual Machine

[0107] VNF Virtualized Network Function

[0108] VNFD VNF Descriptor

[0109] VNFM VNF Manager

Claims

1. A method for managing a network interface performed by an orchestration node (14), the method comprising: - sending (503) the trunk port information of the trunk ports to the function manager so that the function manager can explicitly arrange the trunk ports; The aggregation port information includes a connection point information element for each network sub-interface of the aggregation port, and each of the connection point information elements references the same connection point descriptor CPD in the virtualized network function descriptor VNFD in its "cpdId" attribute, so that the function manager can understand that although the connection point information elements are used to connect to different networks, the connection point information elements actually belong to the same aggregation port definition, and the segment identifier is also included in each connection point information element.

2. The method according to claim 1, wherein: The trunk port information includes an identifier used between applications and the network infrastructure to identify a network sub-interface of the trunk port in question.

3. The method according to any one of claims 1 to 2, further comprising: - establishing (501) that the trunk port is a trunk port type including a plurality of network sub-interfaces; as well as - Associating corresponding trunk port information with each network sub-interface of the trunk port (502).

4. The method according to claim 3, wherein: Associating the corresponding trunk port information with each network sub-interface of the trunk port includes adding a segment identification to a configuration.

5. The method according to any one of claims 1 to 2, wherein: The trunk port information includes an identifier of each network sub-interface for the trunk port.

6. The method according to any one of claims 1 to 2, wherein: The orchestration node is a network function virtualization orchestrator and / or the function manager is a virtualized network function manager.

7. The method according to any one of claims 1 to 2, wherein: The aggregation port information includes a sub-interface network identifier or a sub-interface network tag, which identifies to which network the sub-interface is connected.

8. A method for managing a network interface performed by a function manager, the method comprising: - receiving (511) trunk port information of a trunk port from an orchestration node, wherein the trunk port information includes a connection point information element for each network sub-interface of the trunk port, and each of the connection point information elements references the same connection point descriptor CPD in the virtualized network function descriptor VNFD in its "cpdId" attribute, so that the function manager can understand that although the connection point information elements are used to connect to different networks, the connection point information elements actually belong to the same trunk port definition, and a segment identification is also included in each connection point information element; and - Orchestrating (512) the trunk port based on the received trunk port information, wherein orchestrating (512) the trunk port includes adding network sub-interfaces to the trunk port and / or removing network sub-interfaces from the trunk port based on the received trunk port information.

9. The method according to claim 8, wherein: The trunk port information includes an identifier used between applications and the network infrastructure to identify a network sub-interface of the trunk port in question.

10. The method according to any one of claims 8 to 9, wherein: The trunk port information includes an identifier of each network sub-interface for the trunk port.

11. The method according to any one of claims 8 to 9, wherein: The orchestration node is a network function virtualization orchestrator and / or the function manager is a virtualized network function manager.

12. The method according to any one of claims 8 to 9, wherein: The aggregation port information includes a sub-interface network identifier or a sub-interface network tag, which identifies to which network the network sub-interface is connected.

13. The method according to any one of claims 8 to 9, wherein: Orchestrating (512) the trunk port includes adding and / or removing network sub-interfaces to / from the trunk port based on the received trunk port information.

14. An orchestration node (14) for managing a network interface, wherein: The orchestration node is suitable for: Sending the aggregation port information of the aggregation port to the function manager so that the function manager can clearly arrange the aggregation port; The aggregation port information includes a connection point information element for each network sub-interface of the aggregation port, and each of the connection point information elements references the same connection point descriptor CPD in the virtualized network function descriptor VNFD in its "cpdId" attribute, so that the function manager can understand that although the connection point information elements are used to connect to different networks, the connection point information elements actually belong to the same aggregation port definition, and the segment identifier is also included in each connection point information element.

15. The orchestration node (14) according to claim 14, wherein: The trunk port information includes an identifier used between applications and the network infrastructure to identify a network sub-interface of the trunk port in question.

16. The orchestration node (14) according to any one of claims 14-15, wherein: The orchestration node is also adapted to: Establishing that the trunk port is a trunk port type including a plurality of network sub-interfaces; and Corresponding aggregation port information is associated with each network sub-interface of the aggregation port.

17. The orchestration node (14) according to any one of claims 14-15, wherein: The trunk port information includes an identifier of each network sub-interface for the trunk port.

18. The orchestration node (14) according to any one of claims 14-15, wherein: The orchestration node is a network function virtualization orchestrator and / or the function manager is a virtualized network function manager.

19. The orchestration node (14) according to any one of claims 14-15, wherein: The orchestration node is configured to associate corresponding trunk port information with each network sub-interface of the trunk port by adding a segment identifier to the configuration.

20. The orchestration node (14) according to any one of claims 14-15, wherein: The aggregation port information includes a sub-interface network identifier or a sub-interface network tag, which identifies to which network the network sub-interface is connected.

21. A function manager for managing a network interface, wherein: The function manager is adapted to: receiving, from an orchestration node, aggregate port information of an aggregate port, wherein the aggregate port information includes a connection point information element for each network sub-interface of the aggregate port, and each of the connection point information elements references the same connection point descriptor CPD in a virtualized network function descriptor VNFD in its "cpdId" attribute, so that the function manager can understand that although the connection point information elements are used to connect to different networks, the connection point information elements actually belong to the same aggregate port definition, and a segment identifier is also included in each connection point information element; and The trunk port is orchestrated based on the received trunk port information, wherein the function manager is configured to orchestrate the trunk port by adding a network sub-interface to the trunk port and / or removing a network sub-interface from the trunk port based on the received trunk port information.

22. The function manager according to claim 21, wherein: The trunk port information includes an identifier of a network sub-interface used between an application and a network infrastructure to identify the trunk port in question.

23. The function manager according to any one of claims 21-22, wherein: The trunk port information includes an identifier of each network sub-interface for the trunk port.

24. The function manager according to any one of claims 21-22, wherein: The orchestration node is a network function virtualization orchestrator and / or the function manager is a virtualized network function manager.

25. The function manager according to any one of claims 21-22, wherein: The aggregation port information includes a sub-interface network identifier or a sub-interface network tag, which identifies to which network the network sub-interface is connected.

26. The function manager according to any one of claims 21-22, wherein: The function manager is adapted to orchestrate the trunk port by adding and / or removing network sub-interfaces to / from the trunk port based on the received trunk port information.

Images