Telefonaktiebolaget Lm Ericsson (publ)

Dávid Jocha

András Kern

Balázs Peter Gerö

Róbert Szabó

János Harmatos

András Császár

János Farkas

Bence Formanek

Balázs Sonkoly

András CSÁSZÁR

Embodiments described herein relate to methods and apparatuses for providing a back-up service. A method in a reliability lifecycle manager (RLCM) is provided for managing orchestration of a back-up service for an original service. The method comprises receiving an indication of successful deployment of at least a first part of an original service from a first network domain, wherein the at least part of the original service comprises at least a first network function; responsive to the indication, transmitting a restoration preparation request to the first network domain to request that the first network domain initiate determination of a back-up service for the first part of the original service, the back-up service comprising a first back-up network domain capable of deploying the first network function, wherein the first back-up network domain is different to a first original network domain deploying the first network function in the original service; and responsive to transmitting the restoration preparation request, receiving a restoration response comprising an indication of the back-up service.

Methods and apparatuses for providing a back-up service

In a method performed by a first node associated with a first domain of a communications network, a first message is sent (302) to a second node associated with a second domain of the communications network. The first message comprises an indication of a resource in the first domain that is available to the second domain. The first message further comprises an anonymised first global unique identifier associated with the first domain.

Methods, nodes and systems in a communication network

A first orchestrator (-) for a first domain (-) is configured for multi-domain orchestration. The first orchestrator (-) receives an inbound orchestration request () that requests orchestration of one or more inbound targets () and that includes one or more records (). The one or more records () either indicate an ancestry of each of the one or more inbound targets () or indicate an ancestry of the inbound orchestration request (). The first orchestrator (-), based on the one or more records () included in the inbound orchestration request (), evaluating whether or not to send from the first domain (-) to a second domain (-) an outbound orchestration request () that requests orchestration of an outbound target (). The outbound target () is one of, or is a descendant of at least one of, the one or more inbound targets (). The first orchestrator (-) then sends or does not send the outbound orchestration request () from the first domain (-) to the second domain (-) depending on the evaluation.

Multi-domain orchestration

A technique for dynamically determining a modification of an initial cloud computing deployment (CCD) of a serverless application with multiple application functions is described. The multiple application functions in the initial CCD are grouped into one or more deployment artifacts each comprising at least one application function, wherein each deployment artifact is associated with a dedicated cloud computing platform type selected from FaaS and CaaS. An apparatus of the present disclosure is configured to obtain at least one requirement for the serverless application or its deployment, and to obtain an application model of the serverless application. The apparatus is further configured to determine, based on the application model and the at least one requirement, a modified CCD of the serverless application, wherein the modified CCD comprises at least one of a modified grouping of the multiple application functions into one or more deployment artifacts and a modified association of a particular deployment artifact with a dedicated cloud computing platform type selected from at least FaaS and CaaS.

Technique for determining cloud computing deployment modifications for serverless applications

Embodiments described herein provide methods and apparatus for life cycle management in virtual networks. A method, in a Life Cycle Management, LCM, component in a virtual network, wherein the virtual network comprises a first orchestration layer comprising a first network function virtualisation orchestrator, NFVO, and a second orchestration layer, subordinate to the first orchestration layer, comprising a second NF VO, comprises: receiving a first request, from the first NFVO, to determine a first substitution for a first VNF in a first network service request, wherein the first substitution maps the first network service request onto the second orchestration layer; and responsive to a determination, based on a topology of the second orchestration layer, that the first substitution comprises a second VNF associated with the second NFVO, receiving a second request from the second NFVO to provide a second substitution for the second VNF in a second network service request, wherein the second substitution maps the second network service request onto a third network layer, and the second network service request implements at least part of the first network service request.

Methods and apparatus for life cycle management in virtual networks

Certain embodiments relate to a method for assigning, by a resource orchestration entity, resources for a service carried out on a data packet flow in a multilayer network, the method comprising determining software requirements and network requirements necessary for the service wherein the software requirements and network requirements are received by the network resource orchestration entity from an upper layer through a northbound interface; determining a virtual network topology of the network with at least one virtual network entity, the virtual network entity comprising entity computing resources and entity network resources; and assigning the software requirements and the network requirements at least partially to the entity computing resources and the entity network resources.

Mapping of service requirements for a virtualized network on a packet flow

A Path Computation Client () of a node in a network sends a request message () to a Path Computation Element () of the network for computation of a path, and the Path Computation Element sends a response message () comprising information identifying a calculated path. The Path Computation Element also sends a request for feedback on a result of the attempt to set up the connection. The Path Computation Element attempts to set up a connection based on the calculated path, and reports () to the Path Computation Element the result of the attempt to set up the connection.

Providing feedback to path computation element

A method is performed by a network element implementing a controller of a split architecture network. The method requests that a subset of switches in the network report metrics for a data flow to provide a management module with information for executing a management function. A second method is performed by a network element implementing a switch. The switch reports metrics for a data flow to the controller, wherein the switch forwards a management packet with the data flow and collects the metrics for the data flow.

Controller driven OAM for split architecture network

A method is performed by a network element implementing an OpenFlow controller. The method requests that a subset of OpenFlow switches in the network report metrics for an OpenFlow data flow to provide a management module with information for executing a management function. A second method is performed by a network element implementing an OpenFlow switch. The OpenFlow switch reports metrics for an OpenFlow data flow to the OpenFlow controller, wherein the OpenFlow switch forwards a management packet with the OpenFlow data flow and collects the metrics for the OpenFlow data flow.

Controller driven OAM for openflow

A method performed by a network element implementing an OpenFlow controller, the OpenFlow controller including an operations, administration and management (OAM) module. The OAM module services an OAM function request in a network implementing OpenFlow. The method requests that a subset of OpenFlow switches in the network report metrics for an OpenFlow data flow to provide the OAM module with information for executing the requested OAM function. The method comprising the steps of receiving by an OAM module of the network element a request to execute the OAM function, generating a trigger monitoring message by the OAM module, the trigger monitoring message defining actions to be performed by an OpenFlow switch in the subset of OpenFlow switches, wherein the actions are to provide the metrics for the OpenFlow data flow, sending the trigger monitoring message to the OpenFlow switch, receiving a plurality of monitor response messages from the subset of OpenFlow switches, each of the plurality of monitor response messages including the metrics for the OpenFlow data flow, correlating the plurality of monitor response messages with the OAM function request, executing the requested OAM function using the metrics of the OpenFlow data flow by the OAM module, and returning a result of the requested OAM function.

Controller driven OAM for OpenFlow

A method implemented by a network element monitor OpenFlow data flows and enable operations, administration and management (OAM) functionality in OpenFlow. The method inserts OpenFlow OAM packets into an OpenFlow data flow to monitor the OpenFlow data flow, wherein inserted OpenFlow OAM packets have fate sharing with data packets in the OpenFlow data flow. The method comprises the steps of receiving by the network element the OpenFlow OAM packets from a source through a port of the network element, matching by an OpenFlow switch module using a matching structure of OpenFlow data packets received by the network element to identify the OpenFlow OAM packets, and forwarding the identified OpenFlow OAM packets to a flow table or group table of the OpenFlow switch module to aggregate the OpenFlow OAM packets with a corresponding OpenFlow data flow.

Generic monitoring packet handling mechanism for OpenFlow 1.1

A method of measuring loss in a multicast transmission in a network is described. Service frames including a service multicast destination address are sent from a source node towards a receiving node. A counter of the number of service frames sent is maintained at the source node. This counter is periodically read, and its value copied into a loss measurement OAM frame. The loss measurement OAM frame includes a unique identifier and an OAM destination address which is different to the service multicast destination address, and is sent from the source node towards the receiving node. Every time the sent frames counter is read, a measurement indicator frame is also sent from the source node towards the receiving node. The measurement indicator frame includes the unique identifier so that it can be related to the loss measurement OAM frame. The measurement indicator frame also includes the service multicast destination address, although the measurement indicator frame is distinguishable from the service frames. The receiving node eventually receives the loss measurement OAM frame and the measurement indicator frame, and calculates the number of lost or delayed service frames by comparing the number of service frames received at the receiving node at the time the measurement indicator frame is received with the sent frames counter value contained in the loss measurement OAM frame. The calculation is only performed when the loss measurement OAM frame and measurement indicator frame having the same identifier have been received by the receiving node.

Loss measurement for multicast data delivery

Extensions to a Multi-Protocol Label Switching (MPLS) frame forwarding procedure in an MPLS node are described. A context descriptor is defined for each frame received on a connection terminated at that node, and where this context descriptor is provided together with the frame to a corresponding function (e.g. Operations, Administration and Maintenance, OAM) if needed. The context descriptor is constructed based on key attributes characterizing the terminated connection, over which the frame is received, and addresses a particular function endpoint (Maintenance Endpoints (MEPs), Selector Bridge of a protection instance etc.) of a corresponding function (OAM, protection, etc.). In one embodiment, a Multi-Protocol Label Switching (MPLS) node is directed to check not only the first but also the second label, and not to drop the first label (and the label space if relevant) when the second label is the Generic Association Channel Label (GAL). In this way, the original context of the packet is kept (i.e. the information relating to the connection over which the packet was received), and can be used for de-multiplexing to the corresponding MEP. Then the identifiers within the OAM payload can be used for verification of the connectivity. Other embodiments describe alternative solutions.

Growing community of inventors

Budapest, Hungary

Dávid Jocha