Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3945

Generalized Multi-Protocol Label Switching (GMPLS) Architecture

Pages: 69
Proposed Standard
Errata
Updated by:  6002
Part 2 of 3 – Pages 16 to 42
First   Prev   Next

Top   ToC   RFC3945 - Page 16   prevText

4. Link Bundling

The concept of link bundling is essential in certain networks employing the GMPLS control plane as is defined in [BUNDLE]. A typical example is an optical meshed network where adjacent optical cross-connects (LSRs) are connected by several hundreds of parallel wavelengths. In this network, consider the application of link state routing protocols, like OSPF or IS-IS, with suitable extensions for resource discovery and dynamic route computation. Each wavelength must be advertised separately to be used, except if link bundling is used. When a pair of LSRs is connected by multiple links, it is possible to advertise several (or all) of these links as a single link into OSPF and/or IS-IS. This process is called link bundling, or just bundling. The resulting logical link is called a bundled link as its physical links are called component links (and are identified by interface indexes).
Top   ToC   RFC3945 - Page 17
   The result is that a combination of three identifiers ((bundled) link
   identifier, component link identifier, label) is sufficient to
   unambiguously identify the appropriate resources used by an LSP.

   The purpose of link bundling is to improve routing scalability by
   reducing the amount of information that has to be handled by OSPF
   and/or IS-IS.  This reduction is accomplished by performing
   information aggregation/abstraction.  As with any other information
   aggregation/abstraction, this results in losing some of the
   information.  To limit the amount of losses one need to restrict the
   type of the information that can be aggregated/abstracted.

4.1. Restrictions on Bundling

The following restrictions are required for bundling links. All component links in a bundle must begin and end on the same pair of LSRs; and share some common characteristics or properties defined in [OSPF-TE] and [ISIS-TE], i.e., they must have the same: - Link Type (i.e., point-to-point or multi-access), - TE Metric (i.e., an administrative cost), - Set of Resource Classes at each end of the links (i.e., colors). Note that a FA may also be a component link. In fact, a bundle can consist of a mix of point-to-point links and FAs, but all sharing some common properties.

4.2. Routing Considerations for Bundling

A bundled link is just another kind of TE link such as those defined by [GMPLS-ROUTING]. The liveness of the bundled link is determined by the liveness of each its component links. A bundled link is alive when at least one of its component links is alive. The liveness of a component link can be determined by any of several means: IS-IS or OSPF hellos over the component link, or RSVP Hello (hop local), or LMP hellos (link local), or from layer 1 or layer 2 indications. Note that (according to the RSVP-TE specification [RFC3209]) the RSVP Hello mechanism is intended to be used when notification of link layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection. Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links.
Top   ToC   RFC3945 - Page 18
   Note that advertising a (bundled) TE link between a pair of LSRs does
   not imply that there is an IGP adjacency between these LSRs that is
   associated with just that link.  In fact, in certain cases a TE link
   between a pair of LSRs could be advertised even if there is no IGP
   adjacency at all between the LSR (e.g., when the TE link is an FA).

   Forming a bundled link consist in aggregating the identical TE
   parameters of each individual component link to produce aggregated TE
   parameters.  A TE link as defined by [GMPLS-ROUTING] has many
   parameters; adequate aggregation rules must be defined for each one.

   Some parameters can be sums of component characteristics such as the
   unreserved bandwidth and the maximum reservable bandwidth.  Bandwidth
   information is an important part of a bundle advertisement and it
   must be clearly defined since an abstraction is done.

   A GMPLS node with bundled links must apply admission control on a
   per-component link basis.

4.3. Signaling Considerations

Typically, an LSP's explicit route (e.g., contained in an explicit route Object/TLV) will choose the bundled link to be used for the LSP, but not the component link(s). This because information about the bundled link is flooded but information about the component links is not. The choice of the component link to use is always made by an upstream node. If the LSP is bi-directional, the upstream node chooses a component link in each direction. Three mechanisms for indicating this choice to the downstream node are possible.

4.3.1. Mechanism 1: Implicit Indication

This mechanism requires that each component link has a dedicated signaling channel (e.g., the link is a Sonet/SDH link using the DCC for in-band signaling). The upstream node tells the receiver which component link to use by sending the message over the chosen component link's dedicated signaling channel. Note that this signaling channel can be in-band or out-of-band. In this last case, the association between the signaling channel and that component link need to be explicitly configured.
Top   ToC   RFC3945 - Page 19

4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID

This mechanism requires that the component link has a unique remote IP address. The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying either an IPv4 or an IPv6 address in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a component link is provided for each direction by the upstream node. This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.

4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID

With this mechanism, each component link that is unnumbered is assigned a unique Interface Identifier (32 bits value). The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). This object/TLV carries the component interface ID in the downstream direction for a unidirectional LSP, and in addition, the component interface ID in the upstream direction for a bi-directional LSP. The two LSRs at each end of the bundled link exchange these identifiers. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP (preferred solution), by means of RSVP-TE/CR-LDP (especially in the case where a component link is a Forwarding Adjacency), or by means of IS-IS or OSPF extensions. This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.

4.4. Unnumbered Bundled Link

A bundled link may itself be numbered or unnumbered independent of whether the component links are numbered or not. This affects how the bundled link is advertised in IS-IS/OSPF and the format of LSP EROs that traverse the bundled link. Furthermore, unnumbered Interface Identifiers for all unnumbered outgoing links of a given LSR (whether component links, Forwarding Adjacencies or bundled links) must be unique in the context of that LSR.
Top   ToC   RFC3945 - Page 20

4.5. Forming Bundled Links

The generic rule for bundling component links is to place those links that are correlated in some manner in the same bundle. If links may be correlated based on multiple properties then the bundling may be applied sequentially based on these properties. For instance, links may be first grouped based on the first property. Each of these groups may be then divided into smaller groups based on the second property and so on. The main principle followed in this process is that the properties of the resulting bundles should be concisely summarizable. Link bundling may be done automatically or by configuration. Automatic link bundling can apply bundling rules sequentially to produce bundles. For instance, the first property on which component links may be correlated could be the Interface Switching Capability [GMPLS-ROUTING], the second property could be the Encoding [GMPLS-ROUTING], the third property could be the Administrative Weight (cost), the fourth property could be the Resource Classes and finally links may be correlated based on other metrics such as SRLG (Shared Risk Link Groups). When routing an alternate path for protection purposes, the general principle followed is that the alternate path is not routed over any link belonging to an SRLG that belongs to some link of the primary path. Thus, the rule to be followed is to group links belonging to exactly the same set of SRLGs. This type of sequential sub-division may result in a number of bundles between two adjacent nodes. In practice, however, the link properties may not be very heterogeneous among component links between two adjacent nodes. Thus, the number of bundles in practice may not be large.

5. Relationship with the UNI

The interface between an edge GMPLS node and a GMPLS LSR on the network side may be referred to as a User to Network Interface (UNI), while the interface between two-network side LSRs may be referred to as a Network to Network Interface (NNI). GMPLS does not specify separately a UNI and an NNI. Edge nodes are connected to LSRs on the network side, and these LSRs are in turn connected between them. Of course, the behavior of an edge node is not exactly the same as the behavior of an LSR on the network side. Note also, that an edge node may run a routing protocol, however it is expected that in most of the cases it will not (see also section 5.2 and the section about signaling with an explicit route).
Top   ToC   RFC3945 - Page 21
   Conceptually, a difference between UNI and NNI make sense either if
   both interface uses completely different protocols, or if they use
   the same protocols but with some outstanding differences.  In the
   first case, separate protocols are often defined successively, with
   more or less success.

   The GMPLS approach consisted in building a consistent model from day
   one, considering both the UNI and NNI interfaces at the same time
   [GMPLS-OVERLAY].  For that purpose, a very few specific UNI
   particularities have been ignored in a first time.  GMPLS has been
   enhanced to support such particularities at the UNI by some other
   standardization bodies (see hereafter).

5.1. Relationship with the OIF UNI

This section is only given for reference to the OIF work related to GMPLS. The current OIF UNI specification [OIF-UNI] defines an interface between a client SONET/SDH equipment and an SONET/SDH network, each belonging to a distinct administrative authority. It is designed for an overlay model. The OIF UNI defines additional mechanisms on the top of GMPLS for the UNI. For instance, the OIF service discovery procedure is a precursor to obtaining UNI services. Service discovery allows a client to determine the static parameters of the interconnection with the network, including the UNI signaling protocol, the type of concatenation, the transparency level as well as the type of diversity (node, link, SRLG) supported by the network. Since the current OIF UNI interface does not cover photonic networks, G.709 Digital Wrapper, etc, it is from that perspective a subset of the GMPLS Architecture at the UNI.

5.2. Reachability across the UNI

This section discusses the selection of an explicit route by an edge node. The selection of the first LSR by an edge node connected to multiple LSRs is part of that problem. An edge node (host or LSR) can participate more or less deeply in the GMPLS routing. Four different routing models can be supported at the UNI: configuration based, partial peering, silent listening and full peering. - Configuration based: this routing model requires the manual or automatic configuration of an edge node with a list of neighbor LSRs sorted by preference order. Automatic configuration can be achieved using DHCP for instance. No routing information is
Top   ToC   RFC3945 - Page 22
      exchanged at the UNI, except maybe the ordered list of LSRs.  The
      only routing information used by the edge node is that list.  The
      edge node sends by default an LSP request to the preferred LSR.
      ICMP redirects could be send by this LSR to redirect some LSP
      requests to another LSR connected to the edge node.  GMPLS does
      not preclude that model.

   -  Partial peering: limited routing information (mainly reachability)
      can be exchanged across the UNI using some extensions in the
      signaling plane.  The reachability information exchanged at the
      UNI may be used to initiate edge node specific routing decision
      over the network.  GMPLS does not have any capability to support
      this model today.

   -  Silent listening: the edge node can silently listen to routing
      protocols and take routing decisions based on the information
      obtained.  An edge node receives the full routing information,
      including traffic engineering extensions.  One LSR should forward
      transparently all routing PDUs to the edge node.  An edge node can
      now compute a complete explicit route taking into consideration
      all the end-to-end routing information.  GMPLS does not preclude
      this model.

   -  Full peering: in addition to silent listening, the edge node
      participates within the routing, establish adjacencies with its
      neighbors and advertises LSAs.  This is useful only if there are
      benefits for edge nodes to advertise themselves traffic
      engineering information.  GMPLS does not preclude this model.

6. Link Management

In the context of GMPLS, a pair of nodes (e.g., a photonic switch) may be connected by tens of fibers, and each fiber may be used to transmit hundreds of wavelengths if DWDM is used. Multiple fibers and/or multiple wavelengths may also be combined into one or more bundled links for routing purposes. Furthermore, to enable communication between nodes for routing, signaling, and link management, control channels must be established between a node pair. Link management is a collection of useful procedures between adjacent nodes that provide local services such as control channel management, link connectivity verification, link property correlation, and fault management. The Link Management Protocol (LMP) [LMP] has been defined to fulfill these operations. LMP has been initiated in the context of GMPLS but is a generic toolbox that can be also used in other contexts.
Top   ToC   RFC3945 - Page 23
   In GMPLS, the control channels between two adjacent nodes are no
   longer required to use the same physical medium as the data links
   between those nodes.  Moreover, the control channels that are used to
   exchange the GMPLS control-plane information exist independently of
   the links they manage.  Hence, LMP was designed to manage the data
   links, independently of the termination capabilities of those data
   links.

   Control channel management and link property correlation procedures
   are mandatory per LMP.  Link connectivity verification and fault
   management procedures are optional.

6.1. Control Channel and Control Channel Management

LMP control channel management is used to establish and maintain control channels between nodes. Control channels exist independently of TE links, and can be used to exchange MPLS control-plane information such as signaling, routing, and link management information. An "LMP adjacency" is formed between two nodes that support the same LMP capabilities. Multiple control channels may be active simultaneously for each adjacency. A control channel can be either explicitly configured or automatically selected, however, LMP currently assume that control channels are explicitly configured while the configuration of the control channel capabilities can be dynamically negotiated. For the purposes of LMP, the exact implementation of the control channel is left unspecified. The control channel(s) between two adjacent nodes is no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network. A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data-bearing links is that the health of a control channel does not necessarily correlate to the health of the data-bearing links, and vice-versa. Therefore, new mechanisms have been developed in LMP to manage links, both in terms of link provisioning and fault isolation. LMP does not specify the signaling transport mechanism used in the control channel, however it states that messages transported over a control channel must be IP encoded. Furthermore, since the messages are IP encoded, the link level encoding is not part of LMP. A 32-bit non-zero integer Control Channel Identifier (CCId) is assigned to each direction of a control channel.
Top   ToC   RFC3945 - Page 24
   Each control channel individually negotiates its control channel
   parameters and maintains connectivity using a fast Hello protocol.
   The latter is required if lower-level mechanisms are not available to
   detect link failures.

   The Hello protocol of LMP is intended to be a lightweight keep-alive
   mechanism that will react to control channel failures rapidly so that
   IGP Hellos are not lost and the associated link-state adjacencies are
   not removed uselessly.

   The Hello protocol consists of two phases: a negotiation phase and a
   keep-alive phase.  The negotiation phase allows negotiation of some
   basic Hello protocol parameters, like the Hello frequency.  The
   keep-alive phase consists of a fast lightweight bi-directional Hello
   message exchange.

   If a group of control channels share a common node pair and support
   the same LMP capabilities, then LMP control channel messages (except
   Configuration messages, and Hello's) may be transmitted over any of
   the active control channels without coordination between the local
   and remote nodes.

   For LMP, it is essential that at least one control channel is always
   available.  In case of control channel failure, it may be possible to
   use an alternate active control channel without coordination.

6.2. Link Property Correlation

As part of LMP, a link property correlation exchange is defined. The exchange is used to aggregate multiple data-bearing links (i.e., component links) into a bundled link and exchange, correlate, or change TE link parameters. The link property correlation exchange may be done at any time a link is up and not in the Verification process (see next section). It allows, for instance, the addition of component links to a link bundle, change of a link's minimum/maximum reservable bandwidth, change of port identifiers, or change of component identifiers in a bundle. This mechanism is supported by an exchange of link summary messages.

6.3. Link Connectivity Verification

Link connectivity verification is an optional procedure that may be used to verify the physical connectivity of data-bearing links as well as to exchange the link identifiers that are used in the GMPLS signaling.
Top   ToC   RFC3945 - Page 25
   This procedure should be performed initially when a data-bearing link
   is first established, and subsequently, on a periodic basis for all
   unallocated (free) data-bearing links.

   The verification procedure consists of sending Test messages in-band
   over the data-bearing links.  This requires that the unallocated
   links must be opaque; however, multiple degrees of opaqueness (e.g.,
   examining overhead bytes, terminating the payload, etc.), and hence
   different mechanisms to transport the Test messages, are specified.
   Note that the Test message is the only LMP message that is
   transmitted over the data-bearing link, and that Hello messages
   continue to be exchanged over the control channel during the link
   verification process.  Data-bearing links are tested in the transmit
   direction as they are unidirectional.  As such, it is possible for
   LMP neighboring nodes to exchange the Test messages simultaneously in
   both directions.

   To initiate the link verification procedure, a node must first notify
   the adjacent node that it will begin sending Test messages over a
   particular data-bearing link, or over the component links of a
   particular bundled link.  The node must also indicate the number of
   data-bearing links that are to be verified; the interval at which the
   test messages will be sent; the encoding scheme, the transport
   mechanisms that are supported, the data rate for Test messages; and,
   in the case where the data-bearing links correspond to fibers, the
   wavelength over which the Test messages will be transmitted.
   Furthermore, the local and remote bundled link identifiers are
   transmitted at this time to perform the component link association
   with the bundled link identifiers.

6.4. Fault Management

Fault management is an important requirement from the operational point of view. Fault management includes usually: fault detection, fault localization and fault notification. When a failure occurs and is detected (fault detection), an operator needs to know exactly where it happened (fault localization) and a source node may need to be notified in order to take some actions (fault notification). Note that fault localization can also be used to support some specific (local) protection/restoration mechanisms. In new technologies such as transparent photonic switching currently no method is defined to locate a fault, and the mechanism by which the fault information is propagated must be sent "out of band" (via the control plane).
Top   ToC   RFC3945 - Page 26
   LMP provides a fault localization procedure that can be used to
   rapidly localize link failures, by notifying a fault up to the node
   upstream of that fault (i.e., through a fault notification
   procedure).

   A downstream LMP neighbor that detects data link failures will send
   an LMP message to its upstream neighbor notifying it of the failure.
   When an upstream node receives a failure notification, it can
   correlate the failure with the corresponding input ports to determine
   if the failure is between the two nodes.  Once the failure has been
   localized, the signaling protocols can be used to initiate link or
   path protection/restoration procedures.

6.5. LMP for DWDM Optical Line Systems (OLSs)

In an all-optical environment, LMP focuses on peer communications (e.g., OXC-to-OXC). A great deal of information about a link between two OXCs is known by the OLS (Optical Line System or WDM Terminal multiplexer). Exposing this information to the control plane can improve network usability by further reducing required manual configuration, and by greatly enhancing fault detection and recovery. LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC and an OLS. These extensions are intended to satisfy the Optical Link Interface Requirements described in [OLI-REQ]. Fault detection is particularly an issue when the network is using all-optical photonic switches (PXC). Once a connection is established, PXCs have only limited visibility into the health of the connection. Although the PXC is all-optical, long-haul OLSs typically terminate channels electrically and regenerate them optically. This provides an opportunity to monitor the health of a channel between PXCs. LMP-WDM can then be used by the OLS to provide this information to the PXC. In addition to the link information known to the OLS that is exchanged through LMP-WDM, some information known to the OXC may also be exchanged with the OLS through LMP-WDM. This information is useful for alarm management and link monitoring (e.g., trace monitoring). Alarm management is important because the administrative state of a connection, known to the OXC (e.g., this information may be learned through the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarms. For example, the OXC may know that a connection is "up", "down", in a "testing" mode, or being deleted ("deletion-in-progress"). The OXC can use this information to inhibit alarm reporting from the OLS when a connection is "down", "testing", or being deleted.
Top   ToC   RFC3945 - Page 27
   It is important to note that an OXC may peer with one or more OLSs
   and an OLS may peer with one or more OXCs.  Although there are many
   similarities between an OXC-OXC LMP session and an OXC-OLS LMP
   session, particularly for control management and link verification,
   there are some differences as well.  These differences can primarily
   be attributed to the nature of an OXC-OLS link, and the purpose of
   OXC-OLS LMP sessions.  The OXC-OXC links can be used to provide the
   basis for GMPLS signaling and routing at the optical layer.  The
   information exchanged over LMP-WDM sessions is used to augment
   knowledge about the links between OXCs.

   In order for the information exchanged over the OXC-OLS LMP sessions
   to be used by the OXC-OXC session, the information must be
   coordinated by the OXC.  However, the OXC-OXC and OXC-OLS LMP
   sessions are run independently and must be maintained separately. One
   critical requirement when running an OXC-OLS LMP session is the
   ability of the OLS to make a data link transparent when not doing the
   verification procedure.  This is because the same data link may be
   verified between OXC-OLS and between OXC-OXC.  The verification
   procedure of LMP is used to coordinate the Test procedure (and hence
   the transparency/opaqueness of the data links).  To maintain
   independence between the sessions, it must be possible for the LMP
   sessions to come up in any order.  In particular, it must be possible
   for an OXC-OXC LMP session to come up without an OXC-OLS LMP session
   being brought up, and vice-versa.

7. Generalized Signaling

The GMPLS signaling extends certain base functions of the RSVP-TE and CR-LDP signaling and, in some cases, adds functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress. The core GMPLS signaling specification is available in three parts: 1. A signaling functional description [RFC3471]. 2. RSVP-TE extensions [RFC3473]. 3. CR-LDP extensions [RFC3472]. In addition, independent parts are available per technology: 1. GMPLS extensions for SONET and SDH control [RFC3946]. 2. GMPLS extensions for G.709 control [GMPLS-G709].
Top   ToC   RFC3945 - Page 28
   The following MPLS profile expressed in terms of MPLS features
   [RFC3031] applies to GMPLS:

   -  Downstream-on-demand label allocation and distribution.

   -  Ingress initiated ordered control.

   -  Liberal (typical), or conservative (could) label retention mode.

   -  Request, traffic/data, or topology driven label allocation
      strategy.

   -  Explicit routing (typical), or hop-by-hop routing.

   The GMPLS signaling defines the following new building blocks on the
   top of MPLS-TE:

   1.  A new generic label request format.
   2.  Labels for TDM, LSC and FSC interfaces, generically known as
       Generalized Label.
   3.  Waveband switching support.
   4.  Label suggestion by the upstream for optimization purposes (e.g.,
       latency).
   5.  Label restriction by the upstream to support some optical
       constraints.
   6.  Bi-directional LSP establishment with contention resolution.
   7.  Rapid failure notification extensions.
   8.  Protection information currently focusing on link protection,
       plus primary and secondary LSP indication.
   9.  Explicit routing with explicit label control for a fine degree of
       control.
   10. Specific traffic parameters per technology.
   11. LSP administrative status handling.
   12. Control channel separation.

   These building blocks will be described in more details in the
   following.  A complete specification can be found in the
   corresponding documents.

   Note that GMPLS is highly generic and has many options.  Only
   building blocks 1, 2 and 10 are mandatory, and only within the
   specific format that is needed.  Typically, building blocks 6 and 9
   should be implemented.  Building blocks 3, 4, 5, 7, 8, 11 and 12 are
   optional.
Top   ToC   RFC3945 - Page 29
   A typical SONET/SDH switching network would implement building
   blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11.  Building blocks
   7 and 8 are optional since the protection can be achieved using
   SONET/SDH overhead bytes.

   A typical wavelength switching network would implement building
   blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11.  Building
   block 3 is only needed in the particular case of waveband switching.

   A typical fiber switching network would implement building blocks:
   1, 2 (the generic format), 6, 7, 8, 9 and 11.

   A typical MPLS-IP network would not implement any of these building
   blocks, since the absence of building block 1 would indicate regular
   MPLS-IP.  Note however that building block 1 and 8 can be used to
   signal MPLS-IP as well.  In that case, the MPLS-IP network can
   benefit from the link protection type (not available in CR-LDP, some
   very basic form being available in RSVP-TE).  Building block 2 is
   here a regular MPLS label and no new label format is required.

   GMPLS does not specify any profile for RSVP-TE and CR-LDP
   implementations that have to support GMPLS - except for what is
   directly related to GMPLS procedures.  It is to the manufacturer to
   decide which are the optional elements and procedures of RSVP-TE and
   CR-LDP that need to be implemented.  Some optional MPLS-TE elements
   can be useful for TDM, LSC and FSC layers, for instance the setup and
   holding priorities that are inherited from MPLS-TE.

7.1. Overview: How to Request an LSP

A TDM, LSC or FSC LSP is established by sending a PATH/Label Request message downstream to the destination. This message contains a Generalized Label Request with the type of LSP (i.e., the layer concerned), and its payload type. An Explicit Route Object (ERO) is also normally added to the message, but this can be added and/or completed by the first/default LSR. The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC object, or in the CR-LDP Traffic Parameters TLV. Specific parameters for a given technology are given in these traffic parameters, such as the type of signal, concatenation and/or transparency for a SONET/SDH LSP. For some other technology there be could just one bandwidth parameter indicating the bandwidth as a floating-point value. The requested local protection per link may be requested using the Protection Information Object/TLV. The end-to-end LSP protection is for further study and is introduced LSP protection/restoration section (see after).
Top   ToC   RFC3945 - Page 30
   If the LSP is a bi-directional LSP, an Upstream Label is also
   specified in the Path/Label Request message.  This label will be the
   one to use in the upstream direction.

   Additionally, a Suggested Label, a Label Set and a Waveband Label can
   also be included in the message.  Other operations are defined in
   MPLS-TE.

   The downstream node will send back a Resv/Label Mapping message
   including one Generalized Label object/TLV that can contain several
   Generalized Labels.  For instance, if a concatenated SONET/SDH signal
   is requested, several labels can be returned.

   In case of SONET/SDH virtual concatenation, a list of labels is
   returned.  Each label identifying one element of the virtual
   concatenated signal.  This limits virtual concatenation to remain
   within a single (component) link.

   In case of any type of SONET/SDH contiguous concatenation, only one
   label is returned.  That label is the lowest signal of the contiguous
   concatenated signal (given an order specified in [RFC3946]).

   In case of SONET/SDH "multiplication", i.e., co-routing of circuits
   of the same type but without concatenation but all belonging to the
   same LSP, the explicit ordered list of all signals that take part in
   the LSP is returned.

7.2. Generalized Label Request

The Generalized Label Request is a new object/TLV to be added in an RSVP-TE Path message instead of the regular Label Request, or in a CR-LDP Request message in addition to the already existing TLVs. Only one label request can be used per message, so a single LSP can be requested at a time per signaling message. The Generalized Label Request gives three major characteristics (parameters) required to support the LSP being requested: the LSP Encoding Type, the Switching Type that must be used and the LSP payload type called Generalized PID (G-PID). The LSP Encoding Type indicates the encoding type that will be used with the data associated with the LSP, i.e., the type of technology being considered. For instance, it can be SDH, SONET, Ethernet, ANSI PDH, etc. It represents the nature of the LSP, and not the nature of the links that the LSP traverses. This is used hop-by-hop by each node.
Top   ToC   RFC3945 - Page 31
   A link may support a set of encoding formats, where support means
   that a link is able to carry and switch a signal of one or more of
   these encoding formats.  The Switching Type indicates then the type
   of switching that should be performed on a particular link for that
   LSP.  This information is needed for links that advertise more than
   one type of switching capability.

   Nodes must verify that the type indicated in the Switching Type is
   supported on the corresponding incoming interface; otherwise, the
   node must generate a notification message with a "Routing
   problem/Switching Type" indication.

   The LSP payload type (G-PID) identifies the payload carried by the
   LSP, i.e., an identifier of the client layer of that LSP.  For some
   technologies, it also indicates the mapping used by the client layer,
   e.g., byte synchronous mapping of E1.  This must be interpreted
   according to the LSP encoding type and is used by the nodes at the
   endpoints of the LSP to know to which client layer a request is
   destined, and in some cases by the penultimate hop.

   Other technology specific parameters are not transported in the
   Generalized Label Request but in technology specific traffic
   parameters as explained hereafter.  Currently, two set of traffic
   parameters are defined, one for SONET/SDH and one for G.709.

   Note that it is expected than specific traffic parameters will be
   defined in the future for photonic (all optical) switching.

7.3. SONET/SDH Traffic Parameters

The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707]. The first traffic parameter specifies the type of the elementary SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6, VC-4, STS-3c, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP. These transforms are the contiguous concatenation, the virtual concatenation, the transparency and the multiplication. Each one is optional. They must be applied strictly in the following order: - First, contiguous concatenation can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
Top   ToC   RFC3945 - Page 32
   -  Second, virtual concatenation can be optionally applied either
      directly on the elementary Signal, or on the contiguously
      concatenated signal obtained from the previous phase.

   -  Third, some transparency can be optionally specified when
      requesting a frame as signal rather than a container.  Several
      transparency packages are defined.

   -  Fourth, a multiplication can be optionally applied either directly
      on the elementary Signal, or on the contiguously concatenated
      signal obtained from the first phase, or on the virtually
      concatenated signal obtained from the second phase, or on these
      signals combined with some transparency.

   For RSVP-TE, the SONET/SDH traffic parameters are carried in a new
   SENDER_TSPEC and FLOWSPEC.  The same format is used for both.  There
   is no Adspec associated with the SENDER_TSPEC, it is omitted or a
   default value is used.  The content of the FLOWSPEC object received
   in a Resv message should be identical to the content of the
   SENDER_TSPEC of the corresponding Path message.  In other words, the
   receiver is normally not allowed to change the values of the traffic
   parameters.  However, some level of negotiation may be achieved as
   explained in [RFC3946].

   For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
   new TLV.

   Note that a general discussion on SONET/SDH and GMPLS can be found in
   [SONET-SDH-GMPLS-FRM].

7.4. G.709 Traffic Parameters

Simply said, an [ITUT-G.709] based network is decomposed in two major layers: an optical layer (i.e., made of wavelengths) and a digital layer. These two layers are divided into sub-layers and switching occurs at two specific sub-layers: at the OCh (Optical Channel) optical layer and at the ODU (Optical channel Data Unit) electrical layer. The ODUk notation is used to denote ODUs at different bandwidths. The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful set of capabilities for ITU-T G.709 networks. The first traffic parameter specifies the type of the elementary G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40 Gbps, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP.
Top   ToC   RFC3945 - Page 33
   These transforms are the virtual concatenation and the
   multiplication.  Each one of these transforms is optional.  They must
   be applied strictly in the following order:

   -  First, virtual concatenation can be optionally applied directly on
      the elementary Signal,

   -  Second, a multiplication can be optionally applied, either
      directly on the elementary Signal, or on the virtually
      concatenated signal obtained from the first phase.

   Additional ODUk Multiplexing traffic parameters allow indicating an
   ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request.
   G.709 supports the following multiplexing capabilities: ODUj into
   ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.

   For RSVP-TE, the G.709 traffic parameters are carried in a new
   SENDER-TSPEC and FLOWSPEC.  The same format is used for both.  There
   is no Adspec associated with the SENDER_TSPEC, it is omitted or a
   default value is used.  The content of the FLOWSPEC object received
   in a Resv message should be identical to the content of the
   SENDER_TSPEC of the corresponding Path message.

   For CR-LDP, the G.709 traffic parameters are simply carried in a new
   TLV.

7.5. Bandwidth Encoding

Some technologies that do not have (yet) specific traffic parameters just require a bandwidth encoding transported in a generic form. Bandwidth is carried in 32-bit number in IEEE floating-point format (the unit is bytes per second). Values are carried in a per protocol specific manner. For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. It should be noted that this bandwidth encoding do not apply to SONET/SDH and G.709, for which the traffic parameters fully define the requested SONET/SDH or G.709 signal. The bandwidth is coded in the Peak Data Rate field of Int-Serv objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in the Peak and Committed Data Rate fields of the CR-LDP Traffic Parameters TLV.
Top   ToC   RFC3945 - Page 34

7.6. Generalized Label

The Generalized Label extends the traditional MPLS label by allowing the representation of not only labels that travel in-band with associated data packets, but also (virtual) labels that identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may identify (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also be a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI). The format of a label can be as simple as an integer value such as a wavelength label or can be more elaborated such as an SONET/SDH or a G.709 label. SDH and SONET define each a multiplexing structure. These multiplexing structures will be used as naming trees to create unique labels. Such a label will identify the exact position (times-lot(s)) of a signal in a multiplexing structure. Since the SONET multiplexing structure may be seen as a subset of the SDH multiplexing structure, the same format of label is used for SDH and SONET. A similar concept is applied to build a label at the G.709 ODU layer. Since the nodes sending and receiving the Generalized Label know what kinds of link they are using, the Generalized Label does not identify its type. Instead, the nodes are expected to know from the context what type of label to expect. A Generalized Label only carries a single level of label i.e., it is non-hierarchical. When multiple levels of labels (LSPs within LSPs) are required, each LSP must be established separately.

7.7. Waveband Switching

A special case of wavelength switching is waveband switching. A waveband represents a set of contiguous wavelengths, which can be switched together to a new waveband. For optimization reasons, it may be desirable for a photonic cross-connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. A Waveband label is defined to support this special case. Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way, all other upper layer labels are treated. As far as the MPLS protocols are concerned, there is little difference between a waveband label and a
Top   ToC   RFC3945 - Page 35
   wavelength label.  Exception is that semantically the waveband can be
   subdivided into wavelengths whereas the wavelength can only be
   subdivided into time or statistically multiplexed labels.

   In the context of waveband switching, the generalized label used to
   indicate a waveband contains three fields, a waveband ID, a Start
   Label and an End Label.  The Start and End Labels are channel
   identifiers from the sender perspective that identify respectively,
   the lowest value wavelength and the highest value wavelength making
   up the waveband.

7.8. Label Suggestion by the Upstream

GMPLS allows for a label to be optionally suggested by an upstream node. This suggestion may be overridden by a downstream node but in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example, micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the norm), the Resv/MAPPING message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. It can be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.

7.9. Label Restriction by the Upstream

An upstream node can optionally restrict (limit) the choice of label of a downstream node to a set of acceptable labels. Giving lists and/or ranges of inclusive (acceptable) or exclusive (unacceptable) labels in a Label Set provides this restriction. If not applied, all labels from the valid label range may be used. There are at least four cases where a label restriction is useful in the "optical" domain. Case 1: the end equipment is only capable of transmitting and receiving on a small specific set of wavelengths/wavebands. Case 2: there is a sequence of interfaces, which cannot support wavelength conversion and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. Case 3: it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals. Case 4: two ends of a link support different sets of wavelengths.
Top   ToC   RFC3945 - Page 36
   The receiver of a Label Set must restrict its choice of labels to one
   that is in the Label Set.  A Label Set may be present across multiple
   hops.  In this case, each node generates its own outgoing Label Set,
   possibly based on the incoming Label Set and the node's hardware
   capabilities.  This case is expected to be the norm for nodes with
   conversion incapable interfaces.

7.10. Bi-directional LSP

GMPLS allows establishment of bi-directional symmetric LSPs (not of asymmetric LSPs). A symmetric bi-directional LSP has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction. In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP; the term "terminator" is used to refer to the node that is the target of the LSP. For a bi-directional LSPs, there is only one initiator and one terminator. Normally to establish a bi-directional LSP when using RSVP-TE [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages: 1. The latency to establish the bi-directional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes. 2. The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bi-directional LSP. 3. Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bi- directional connection.
Top   ToC   RFC3945 - Page 37
   4. It is more difficult to provide a clean interface for SONET/SDH
      equipment that may rely on bi-directional hop-by-hop paths for
      protection switching.  Note that existing SONET/SDH equipment
      transmits the control information in-band with the data.

   5. Bi-directional optical LSPs (or lightpaths) are seen as a
      requirement for many optical networking service providers.

   With bi-directional LSPs both the downstream and upstream data paths,
   i.e., from initiator to terminator and terminator to initiator, are
   established using a single set of signaling messages.  This reduces
   the setup latency to essentially one initiator-terminator round trip
   time plus processing time, and limits the control overhead to the
   same number of messages as a unidirectional LSP.

   For bi-directional LSPs, two labels must be allocated.  Bi-
   directional LSP setup is indicated by the presence of an Upstream
   Label in the appropriate signaling message.

7.11. Bi-directional LSP Contention Resolution

Contention for labels may occur between two bi-directional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (ports) at effectively the same time. GMPLS signaling defines a procedure to resolve that contention: the node with the higher node ID will win the contention. To reduce the probability of contention, some mechanisms are also suggested.

7.12. Rapid Notification of Failure

GMPLS defines several signaling extensions that enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs, and error handling. 1. Acceptable Label Set for notification on Label Error: There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication. When these cases occur, it can useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages. The format of an Acceptable Label Set is identical to a Label Set.
Top   ToC   RFC3945 - Page 38
   2. Expedited notification:

      Extensions to RSVP-TE enable expedited notification of failures
      and other events to determined nodes.  For CR-LDP, there is not
      currently a similar mechanism.  The first extension identifies
      where event notifications are to be sent.  The second provides for
      general expedited event notification with a Notify message.  Such
      extensions can be used by fast restoration mechanisms.
      Notifications may be requested in both the upstream and downstream
      directions.

      The Notify message is a generalized notification mechanism that
      differs from the currently defined error messages in that it can
      be "targeted" to a node other than the immediate upstream or
      downstream neighbor.  The Notify message does not replace existing
      error messages.  The Notify message may be sent either (a)
      normally, where non-target nodes just forward the Notify message
      to the target node, similar to ResvConf processing in [RFC2205];
      or (b) encapsulated in a new IP header whose destination is equal
      to the target IP address.

   3. Faster removal of intermediate states:

      A specific RSVP optimization allowing in some cases the faster
      removal of intermediate states.  This extension is used to deal
      with specific RSVP mechanisms.

7.13. Link Protection

Protection information is carried in the new optional Protection Information Object/TLV. It currently indicates the desired link protection for each link of an LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that GMPLS advertises the protection capabilities of a link in the routing protocols. Path computation algorithms may consider this information when computing paths for setting up LSPs. Protection information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are normally not used until the primary LSP fails, but they may be used by other LSPs until the primary LSP fails over the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP must be preempted.
Top   ToC   RFC3945 - Page 39
   Six link protection types are currently defined as individual flags
   and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared,
   unprotected, extra traffic.  See [RFC3471] section 7.1 for a precise
   definition of each.

7.14. Explicit Routing and Explicit Label Control

By using an explicit route, the path taken by an LSP can be controlled more or less precisely. Typically, the node at the head- end of an LSP finds an explicit route and builds an Explicit Route Object (ERO)/ Explicit Route (ER) TLV that contains that route. Possibly, the edge node does not build any explicit route, and just transmit a signaling request to a default neighbor LSR (as IP/MPLS hosts would). For instance, an explicit route could be added to a signaling message by the first switching node, on behalf of the edge node. Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination. The explicit route is originally defined by MPLS-TE as a list of abstract nodes (i.e., groups of nodes) along the explicit route. Each abstract node can be an IPv4 address prefix, an IPv6 address prefix, or an AS number. This capability allows the generator of the explicit route to have incomplete information about the details of the path. In the simplest case, an abstract node can be a full IP address (32 bits) that identifies a specific node (called a simple abstract node). MPLS-TE allows strict and loose abstract nodes. The path between a strict node and its preceding node must include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding abstract node may include other network nodes that are not part of the loose node or its preceding abstract node. This explicit route was extended to include interface numbers as abstract nodes to support unnumbered interfaces; and further extended by GMPLS to include labels as abstract nodes. Having labels in an explicit route is an important feature that allows controlling the placement of an LSP with a very fine granularity. This is more likely to be used for TDM, LSC and FSC links. In particular, the explicit label control in the explicit route allows terminating an LSP on a particular outgoing port of an egress node. Indeed, a label sub-object/TLV must follow a sub-object/TLV containing the IP address, or the interface identifier (in case of unnumbered interface), associated with the link on which it is to be used.
Top   ToC   RFC3945 - Page 40
   This can also be used when it is desirable to "splice" two LSPs
   together, i.e., where the tail of the first LSP would be "spliced"
   into the head of the second LSP.

   When used together with an optimization algorithm, it can provide
   very detailed explicit routes, including the label (timeslot) to use
   on a link, in order to minimize the fragmentation of the SONET/SDH
   multiplex on the corresponding interface.

7.15. Route Recording

In order to improve the reliability and the manageability of the LSP being established, the concept of the route recording was introduced in RSVP-TE to function as: - First, a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route (this mechanism is strictly exclusive with the use of explicit routing objects). - Second, a route recording mechanism collects up-to-date detailed path information on a hop-by-hop basis during the LSP setup process. This mechanism provides valuable information to the source and destination nodes. Any intermediate routing change at setup time, in case of loose explicit routing, will be reported. - Third, a recorded route can be used as input for an explicit route. This is useful if a source node receives the recorded route from a destination node and applies it as an explicit route in order to "pin down the path". Within the GMPLS architecture, only the second and third functions are mainly applicable for TDM, LSC and FSC layers.

7.16. LSP Modification and LSP Re-routing

LSP modification and re-routing are two features already available in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is possible with the concept of "make-before-break" whereby an old path is still used while a new path is set up by avoiding double reservation of resources. Then, the node performing the re-routing can swap on the new path and close the old path. This feature is supported with RSVP-TE (using shared explicit filters) and CR-LDP (using the action indicator flag). LSP modification consists in changing some LSP parameters, but normally without changing the route. It is supported using the same mechanism as re-routing. However, the semantic of LSP modification will differ from one technology to the other. For instance, further
Top   ToC   RFC3945 - Page 41
   studies are required to understand the impact of dynamically changing
   some SONET/SDH circuit characteristics such as the bandwidth, the
   protection type, the transparency, the concatenation, etc.

7.17. LSP Administrative Status Handling

GMPLS provides the optional capability to indicate the administrative status of an LSP by using a new Admin Status object/TLV. Administrative Status information is currently used in two ways. In the first usage, the Admin Status object/TLV is carried in a Path/Label Request or Resv/Label Mapping message to indicate the administrative state of an LSP. In this usage, Administrative Status information indicates the state of the LSP, which include "up" or "down", if it in a "testing" mode, and if deletion is in progress. Based on that administrative status, a node can take local decisions, like inhibit alarm reporting when an LSP is in "down" or "testing" states, or report alarms associated with the connection at a priority equal to or less than "Non service affecting". It is possible that some nodes along an LSP will not support the Admin Status Object/TLV. In the case of a non-supporting transit node, the object will pass through the node unmodified and normal processing can continue. In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP to "being deleted" before tearing it down in order to avoid non-useful generation of alarms. The ingress LSR precedes an LSP deletion by inserting an appropriate Admin Status Object/TLV in a Path/Label Request (with the modification action indicator flag set to modify) message. Transit LSRs process the Admin Status Object/TLV and forward it. The egress LSR answers in a Resv/Label Mapping (with the modification action indicator flag set to modify) message with the Admin Status object. Upon receiving this message and object, the ingress node sends a PathTear/Release message downstream to remove the LSP and normal RSVP-TE/CR-LDP processing takes place. In the second usage, the Admin Status object/TLV is carried in a Notification/Label Mapping (with the modification action indicator flag set to modify) message to request that the ingress node change the administrative state of an LSP. This allows intermediate and egress nodes triggering the setting of administrative status. In particular, this allows intermediate or egress LSRs requesting a release of an LSP initiated by the ingress node.
Top   ToC   RFC3945 - Page 42

7.18. Control Channel Separation

In GMPLS, a control channel be separated from the data channel. Indeed, the control channel can be implemented completely out-of- band for various reason, e.g., when the data channel cannot carry in-band control information. This issue was even originally introduced to MPLS in the context of link bundling. In traditional MPLS, there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel. Otherwise, it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (for unnumbered interfaces) and component interfaces (for bundled interfaces), unnumbered bundled interfaces are also supported. The choice of the data interface to use is always made by the sender of the Path/Label Request message, and indicated by including the data channel's interface identifier in the message using a new RSVP_HOP object sub-type/Interface TLV. For bi-directional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the Path/Label Request sender explicitly identifies the component interface used in each direction. The new object/TLV is used in Resv/Label Mapping message to indicate the downstream node's usage of the indicated interface(s). The new object/TLV can contain a list of embedded TLVs, each embedded TLV can be an IPv4 address, and IPv6 address, an interface index, a downstream component interface ID or an upstream component interface ID. In the last three cases, the embedded TLV contains itself an IP address plus an Interface ID, the IP address being used to identify the interface ID (it can be the router ID for instance). There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID ERROR_SPEC RSVP Objects are defined.