Signaling in GMPLS

The Multiprotocol Label Switching (MPLS) architecture has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of recognizing packet or cell boundaries and being able to process their respective headers.
The original MPLS architecture has been extended by IETF to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. This is the base of GMPLS requirement. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports and thus the four classes have been defined: Packet switching capable (PSC), Time division multiplexing capable (TDM), Lambda switching capable and Fiber-Switch Capable (FSC).

Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a FSC interface can be nested into an LSP that starts and ends on a TDM interface and etc… until the PSC interface.

Some other key features of GMPLS signaling are:

  • Qos (Quality of Service) (GENERALIZED LABEL REQUEST);
  • Use of FA to improve bandwidth utilization when bandwidth allocation can be performed only with indiscrete units;
  • Bidirectional LSP;
  • Explicit Label control;
  • Shared Risk Link Group;
  • Technology specific parameters (SENDER-TSPEC).

MARBEN Signaling DevKit

MARBEN GMPLS includes an autonomous blocks for signaling matter. It consists of:

  • A protocol stack entity implementing RSVP-TE and even CR-LDP;

  • A Signaling Development Kit offering a unified access to the signaling information gathered by RSVP-TE or even CR-LDP. This Development Kit can be used to build applications that implement:
    • the GMPLS procedures for the establishment, maintenance and release of call and connections for different switching technologies (SONET/SDH, WDM, etc.),
    • the OUNI procedures for the establishment, maintenance and release of call and connections between a client and a server optical user network interface,
    • the E-NNI procedures for the establishment, maintenance and release of connections between separate control domains, each server belonging to a separate control domain,
    • And even the MPLS procedures for the establishment, maintenance and tear down of packet-switching CR-LSPs;

  • A LSP database and the complete and efficient set of lookup queries:
    • A user-application can take advantage of all set of functions to query this database. This signaling database is updated every time a signaling message targeting an LSP is received from the MARBEN stack, or is sent on behalf of the user-application;
    • All LSP-related signaling information is stored in a database, in order to:
      • support high-level services (e.g., fault handling),
      • relieve the user-application of the specification of signaling parameters that have been learned from previous signaling messages related to the same LSP, when a new signaling message needs to be sent to a peer,
      • relieve the user-application of the specification of some explicit information specifying how a particular request must be implemented by the Development Kit. For instance, the release of an MPLS LSP is not handled the same way as a release of a GMPLS connection (use of the ADMIN_STATUS object/TLV). And considering the OUNI interface, a OUNI-C does not handle a request for a connection release in the same way, if it sits at the source OUNI side or at the destination OUNI side for that connection,

MARBEN Signaling DevKit conforms with the latest OIF, IETF and and ITU works and contributions. It fulfills the needs of an application that plays the ingress, intermediate or egress role regarding the establishment, maintenance and tear down of LSPs (including FA-LSPs). It offers a MIB like interface.

This Development Kit can automatically manage the fault handling procedures supported by the RSVP-TE in case a control channel failure occurs, or a nodal fault (for a peer system) occurs.

The C or C++ interface is based on a simple constructor called to instantiate a specific user application as MPLS, OIF UNI, IUT UNI or OIF E-NNI which returns a handle for all the message set of every LSP that must be setup for instance.