The Internet has led to the creation of a digital society, where (almost) everything is connected and is accessible from anywhere. However, despite their widespread adoption, traditional IP networks are complex and very hard to manage. It is both difficult to configure the network according to predefined policies, and to reconfigure it to respond to faults, load, and changes. To make matters even more difficult, current networks are also vertically integrated: the control and data planes are bundled together. Software-defined networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns, introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper, we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound application programming interfaces (APIs), network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms—with a focus on aspects such as resiliency, scalability, performance, security, and dependability—as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

https://publications.uni.lu/bitstream/10993/20596/1/survey_on_SDN.pdf

Software-Defined Networking: A Comprehensive Survey

Software-Defined Networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound APIs, network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms -- with a focus on aspects such as resiliency, scalability, performance, security and dependability -- as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

The disclosed embodiments include system and method for routing communications over a communications network. In one embodiment, a determination is made as to whether to establish a communication along a communication path based on network performance information. The disclosed embodiments provide several alternatives for establishing the communication and improving communications along the communication path in response to a determination that at least one network node along the communication path is impaired or congested.

System and method for routing data on a packet network

Personal content server apparatus and associated methods that allow a user (e.g., cable or satellite network subscriber) to access content, such as a video program, from a location outside the subscriber's network. In one embodiment, a personal content server streams the content to the subscriber over a network connection from the local e.g., (subscription) network to a remote network upon authorization by a content manager process. Various access, business or operational rules are applied depending on the content and delivery mode; e.g., to live video broadcast, video-on-demand (VOD), or archived content from the subscriber's digital video recorder (DVR) or networked PVR. In another variant, reservation information (for example program or asset ID information) is cached at a headend or hub server, thereby obviating the subscriber (or the network) having to access the subscriber's premises device. In yet another variant, a “virtual” CPE experience is provided for the remote user.

Personal content server apparatus and methods

Personal content server apparatus and associated methods that allow a user (e.g., cable or satellite network subscriber) to access content, such as a video program, from a location outside the subscriber's network. In one embodiment, a personal content server streams the content to the subscriber over a network connection from the local e.g., (subscription) network to a remote network upon authorization by a content manager process. Various access, business or operational rules are applied depending on the content and delivery mode; e.g., to live video broadcast, video-on-demand (VOD), or archived content from the subscriber's digital video recorder (DVR) or networked PVR. Secondary content (e.g., promotions, advertisements, etc.) can also be selectively replaced if desired in order to make the remotely delivered content more appropriate to the remote user's context.

A path verification protocol (PVP), which enumerates a series of messages sent to a set of nodes, or routers, along a suspected path, identifies forwarding plane problems for effecting changes at the control plane level. The messages includes a command requesting interrogation of a further remote node for obtaining information about the path between the node receiving the PVP message and the further remote node (202). The node receiving the PVP message replies with a command response indicative of the outcome of attempts to tech the further remote node (206). The series of message collectively covers a set of important routing points along a path from the originator to the recipient. The aggregate command responses to the series of PVP messages is analyzed to identify not only whether the entire path is operational, but also the location and nature of the problem (308).

System and methods for detecting network failure

Conventional network packet traffic loss/drop monitoring mechanisms, such as that employed for pseudowire, IP flow and tunnel traffic monitoring, do not process or diagnose the aggregate counts from both endpoints of a particular pseudowire. A packet loss and detection mechanism periodically exchanges traffic packet counts to maintain an accurate diagnosis of the pseudowire health from either endpoint. Further, the raw packet counts are analyzed to identify misrouted and lost packets, as both should be considered to assess network health and congestion. The pseudowire statistics are maintained for each pseudowire emanating from a particular edge router, providing a complete view of pseudowire traffic affecting a particular edge router. Such statistics are beneficial for problem detection, diagnosis, and for verification of throughput criteria such as those expressed in Quality of Service (QOS) terms and/or SLAs (service level agreements).

Method and apparatus for packet loss detection

A path verification protocol (PVP) which enumerates a series of messages sent to a set of nodes, or routers, along a network path identifies connectivity and transmission characteristic attributes by defining, implementing, and analyzing path verification messages (PVMs) in a VPN environment. Configurations herein provide a mechanism for determination of paths and/or routes that satisfy a QoS or other delivery speed/bandwidth guarantee. Such a mechanism may therefore be employed to perform routing decisions for QoS based traffic. Further, such a mechanism is employable to verify QoS levels and related attributes related to contractual terms between service providers and customers.

System and methods for providing a network path verification protocol

Systems and methods for assuring consistency between MPLS forwarding and control planes. The control plane can be made aware of forwarding plane anomalies and can respond appropriately. One particular application is assuring consistency between forwarding and control planes of a Fast Reroute backup tunnels used to protect an MPLS Traffic Engineering LSP from a link and/or a node failure. When a backup tunnel forwarding failure is detected, the control plane can react by, for example, rerouting the backup tunnel and/or sending a notification to the operator or head-end of the protected Traffic Engineering LSP.

Consistency between MPLS forwarding and control planes

A traceroute mechanism enables responses to the traceroute to reach the originating router (originator) along a multihop pseudowire (PW). A traceroute message includes an accumulator operable to count hops along a MH-PW, implemented as a time-to-live (TTL) field, as is known in the art. An originator router employs multiple TTL values, and decrements one of the TTL “accumulators” for each hop. At the ultimate (terminal) router defining the end of the multihop PW, a TTL in the return message is set to the number of hops traveled by the traceroute. The difference between the accumulator and the initial TTL value determines the number of hops traveled by the traceroute message, and hence the number of hops back to the originating node. The traceroute return message, now having a TTL set to the number of hops of the counterpart traceroute, reaches the originator when the TTL value is decremented to zero.

Thomas D. Nadeau

Papers

System and methods for detecting network failure

Method and apparatus for packet loss detection

System and methods for providing a network path verification protocol

Consistency between MPLS forwarding and control planes

System and methods for sending trace messages