RSVP-TE

The concept of a call set-up process, wherein resources are reserved before calls are established in a network, goes back to the signaling-theory days of telephony. This concept was adapted for data networking when QoS in IP network became an issue. RSVP has been designed by the IETF in 1997 for this very function. The protocol was designed to request required bandwidth and traffic conditions on a defined or explained path.
RSVP with features added to accommodate traffic engineering is one of the two protocols elected to design MPLS networks signaling (see RFC 3031 and RFC 3210). The so called RSVP-TE has been extended as the elected protocol for GMPLS networks signaling (see RFC 3473).

MARBEN RSVP-TE

MARBEN RSVP-TE has been designed to provide the most simple interface that hides non- RSVP-TE protocol mechanisms to the user of the Networking Protocols stack. Indeed, MARBEN RSVP-TE fully handles:

  • RSVP path and reservation states maintenance:
    • Automatic refresh of RSVP Path or Resv messages, using the refresh reduction procedures whenever possible,
    • Detection of implicit RSVP states deletion (when an RSVP state is no longer refreshed);
  • Automatic refresh of RSVP Path or Resv messages;
  • Detection of implicit RSVP states deletion (when an RSVP state is no longer refreshed);
  • Monitoring of peer RSVP entities using the RSVP-TE Hello procedure, and automatic handling of Restart and Recovery timers;
  • Graceful Restart with extensions for GMPLS.

MARBEN RSVP-TE service is intended to be generic and extensible enough to accommodate a set of different user’s profile, and future extensions to the RSVP-TE protocol. Such user's profiles are:

  • MPLS application whose purpose is to handle constraint-based routed LSPs whose payload typically consists of IP packets;
  • Generalized MPLS applications whose purpose is to provision switching-capable modules; for instance, such a module can be able to switch time-slots, wavelengths, wavebands, etc;
  • Optical UNI applications, either on the client’s side or on the service provider’s side, whose purpose is to implement a UNI interface over the RSVP-TE protocol.