Perspectives on software-defined networks: interviews with five leading scientists from the networking community

Batista, Daniel Macêdo; Blair, Gordon S.; Kon, Fábio; Boutaba, Raouf; Hutchison, David; Jain, Raj; Ramjee, Ramachandran; Rothenberg, Christian Esteve

doi:10.1186/s13174-015-0035-3

Cited by 9 publications

(7 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, the ability to respond to customer requests for new or improved functionality in a timely fashion creates a competitive advantage also in the telecommunications network software development context. Furthermore, the recent rise of software-defined telecommunications networks emphasizes the importance of the software side of the networks development (Batista et al 2015).…”

Section: Planning In Large-scale Agile Developmentmentioning

confidence: 99%

“…This was viewed as a major improvement especially by the product management. Furthermore, the recent rise of software-defined telecommunications networks is expected to further emphasize the competitive advantage created by short development lead times (Batista et al 2015). Korhonen (2013) also found that the flexibility of the organization improved during the agile transformation of a large organization.…”

Section: Rq2: What Are the Perceived Benefits Of The Requirements Manmentioning

confidence: 99%

“…Software-defined telecommunications networks emphasize the advantage of short lead times (Batista et al 2015).…”

Section: Rq2: What Are the Perceived Benefits Of The Requirements Manmentioning

confidence: 99%

See 2 more Smart Citations

Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson

et al. 2017

View full text Add to dashboard Cite

In a large organization, informal communication and simple backlogs are not sufficient for the management of requirements and development work. Many large organizations are struggling to successfully adopt agile methods, but there is still little scientific knowledge on requirements management in large-scale agile development organizations. We present an in-depth study of an Ericsson telecommunications node development organization which employs a large scale agile method to develop telecommunications system software. We describe how the requirements flow from strategy to release, and related benefits and problems. Data was collected by 43 interviews, which were analyzed qualitatively. The requirements management was done in three different processes, each of which had a different process model, purpose and planning horizon. The release project management process was plan-driven, feature development process was continuous and implementation management process was agile. The perceived benefits included reduced development lead time, increased flexibility, increased planning efficiency, increased developer motivation and improved communication effectiveness. The recognized problems included difficulties in balancing planning effort, overcommitment, insufficient understanding of the development team autonomy, defining the product owner role, balancing team specialization, organizing system-level work and growing technical debt. The study indicates that agile development methods can be successfully employed in organizations where the higher level planning processes are not agile. Combining agile methods with a flexible feature development process can bring many benefits, but largescale software development seems to require specialist roles and significant coordination effort.

show abstract

Section: Planning In Large-scale Agile Developmentmentioning

confidence: 99%

Section: Rq2: What Are the Perceived Benefits Of The Requirements Manmentioning

confidence: 99%

See 1 more Smart Citation

Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson

et al. 2017

View full text Add to dashboard Cite

show abstract

“…Perhaps, the main novelty in the current reedition of such vertical decoupling in SDN is the ability to break the control logic in small and tractable software pieces. This novelty allows the introduction of new abstractions to the networks, independent of the hardware realizing the data plane, and simplifies the evolution of networks …”

Section: Introductionmentioning

confidence: 99%

“…This novelty allows the introduction of new abstractions to the networks, independent of the hardware realizing the data plane, and simplifies the evolution of networks. 5 Under the SDN scenario, the hardware composing the data plane is greatly simplified, performing a reduced number of tasks besides the main duty of packets forwarding. The control plane, rebranded the controller, is consolidated in software components that encompass all the intelligence of the network.…”

Section: Introductionmentioning

confidence: 99%

Analysis of monitoring and multipath support on top of OpenFlow specification

et al. 2018

View full text Add to dashboard Cite

Summary In general, traffic is pushed through a single path despite the existence of alternative paths in networks. For example, routing solutions based on spanning tree prune the topology to prevent loops, consequently preventing also the use of alternative paths. Research on quality of service frequently advocates that the use of alternative paths is interesting for enforcing Service Level Agreements (SLAs), bypassing bottlenecks created by shortest paths. In this paper, we are interested in analyzing the support for monitoring network traffic and for provisioning of multipaths in software‐defined networking (SDN), given the strong platform it provides for experimentation of new networked solutions. Our approach firstly enriches the topology view at the control plane with data gathered through fine grain data plane monitoring. On the basis of such enriched view, our system determines the path, or multipaths, necessary to enforce the specified SLA. We propose 2 extension modules to an OpenFlow controller: SDNMon, which monitors the data plane to enrich the topology information at the control plane, and MP‐Routing, which determines a set of paths, in the absence of a single path capable of enforcing the SLA. Both modules are extensively evaluated, and the results not only demonstrate what can be achieved in terms of accuracy in SDNMon and in terms of quality of service benefits in MP‐Routing but also highlight some limitations of OpenFlow specification. On the basis of our findings, we propose a set of new counters to Per Port and Per Flow granularity levels of OpenFlow specification.

show abstract