Implementation and evaluation of the KOM RSVP engine

Karsten, Martin; Schmitt, Jens; Steinmetz, Ralf

doi:10.1109/infcom.2001.916624

Cited by 26 publications

(24 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The third PC is configured as a router with two Ethernet interfaces that connect to the client and server hosts. All PCs run the KOM-RSVP implementation [7]; furthermore, the client and the server hosts run ORBs with QPS and QIOP extensions.…”

Section: Results Of Qps and Qiopmentioning

confidence: 99%

Design and Evaluation of A QoS Provisioning Service

Halteren

Fábián

Groeneveld³

2002

IFIP International Federation for Information Processing

View full text Add to dashboard Cite

Middleware provides distributed objects with a software infrastructure that offers a set of well-known distribution transparencies. These transparencies enable the rapid introduction of applications for heterogeneous, distributed systems. However, to support guaranteed Quality of Service (QoS) system-specific QoS mechanisms need to be controlled. Accessing the low-level mechanisms directly by applications crosscuts the transparency offered by the middleware and limits portability and interoperability. The challenge for next-generation middleware is to support application-level QoS requirements, while maintaining the advantages of the distribution transparencies. This paper presents three contributions: (1) An architecture for a QoS-aware software infrastructure for distributed objects (2) A framework for a QoS provisioning service (QPS) and (3) An evaluation of the QPS framework by means of a prototype that supports performance

show abstract

Section: Results Of Qps and Qiopmentioning

confidence: 99%

Design and Evaluation of A QoS Provisioning Service

Halteren

Fábián

Groeneveld³

2002

IFIP International Federation for Information Processing

View full text Add to dashboard Cite

show abstract

“…The optimized parameters include connection setup time, protocol overhead and end-to-end delay, and losses experienced by the data packets. Additionally, the performance of hardware and software implementations of RSVP are analyzed in [9]- [11], with emphasis on the router capacity (in terms of CPU and memory) that is required to sustain a certain number of RSVP flows.…”

Section: A State Of the Artmentioning

confidence: 99%

“…To do so, a single refresh message serves as a keepalive message for several LSPs. However, it has been shown in [9] that a commercial PC is able to sustain the RSVP signaling load for as much as 50.000 simultaneous flows, with no bundling at all.…”

Section: A Simulation Architecturementioning

confidence: 99%

On capacity planning for the GMPLS network control plane

et al. 2007

View full text Add to dashboard Cite

Esta es la versión de autor de la comunicación de congreso publicada en: This is an author produced version of a paper published in: AbstractThis paper presents capacity planning rules for the control plane of all-optical networks featuring GMPLS and RSVP-TE as a connection setup protocol. As per RSVP standard, a refresh message mechanism is incorporated to RSVP such that the state is periodically refreshed on a link per link basis. We provide analytical expressions for the bandwidth and buffer sizes to be provided such that no flows are torn down due to lack of refresh messages. Our findings show that small buffers (several KBytes) suffice to sustain the signaling load for as much as 400 RSVP flows per link, with the simplest RSVP refresh mechanism (neither using link bundling nor acknowledgments). On the other hand, we also find the packet drop probability per link for a given network topology for the case that the flow survival probability is larger than a given threshold. We provide numerical examples based on the COST 239 european network topology and real RSVP traffic traces from early-commercial switching equipment.

show abstract

“…Typical RSVP implementations are user-space daemons interacting with the kernel; thus, state management, message sending, and reception would affect the efficiency of the protocol processing. For example, in the recent version of the implementation described in [KSS01], the relative execution costs for the message sending/reception system calls "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%, individually, of the total execution cost.…”

Section: Processing Overheadmentioning

confidence: 99%

“…RSVP/routing, RSVP/policy control, and RSVP/traffic control interfaces can also pose different overhead depending on implementation. For example, the RSVP/routing overhead has been measured to be approximately 11-12% of the total execution cost [KSS01].…”

Section: Processing Overheadmentioning

confidence: 99%

Analysis of Existing Quality-of-Service Signaling Protocols

Fu¹,

Manner²

2005

View full text Add to dashboard Cite

Implementation and evaluation of the KOM RSVP engine

Cited by 26 publications

References 13 publications

Design and Evaluation of A QoS Provisioning Service

Design and Evaluation of A QoS Provisioning Service

On capacity planning for the GMPLS network control plane

Analysis of Existing Quality-of-Service Signaling Protocols

Contact Info

Product

Resources

About