7.5. GMPLS Extensions to RSVP-TE

At a first glance, the GMPLS extensions to RSVP-TE consist of a few new objects, a new message, and associated procedures. If we look deeper, it becomes apparent that GMPLS brings significant changes to the usage of RSVP-TE. These are:

• Enforcement of the separation between the data plane and the control plane. In particular, the RSVP model where the control messaging is tied to specific data plane interfaces (see section 7.4.1.3) is eliminated.

• The dilution of the soft state model. As described in sections 7.4.1.4 and 7.4.2.3, failures or miscommunication in the control plane lead to data plane actions under RSVP and RSVP-TE. GMPLS extensions aim to ensure that control plane failure events do not affect the fate of connections whose data plane is perfectly oper ational. This is done by quietly moving away from the spirit of the soft state model and by instituting control plane recovery procedures.

• Emphasis on control plane recovery procedures. GMPLS extensions allow two RSVP-TE peers to coordinate the recovery of state information after a control plane failure event. During this recovery process, existing data plane connections are left intact.

• Support for bidirectional connections. RSVP-TE supports unidirectional LSPs. GMPLS extensions allow bidirectionality.

• Introduction of a remote notification mechanism. RSVP-TE messaging follows the connection path. GMPLS introduces a notification extension that allows messaging between remote nodes along routes that are not tied to the connection path.

Let us now examine the GMPLS extensions themselves. As before, we look at the new objects and messages introduced, and then the procedures for connection establishment, maintenance, and removal. From here on, we use the term “GMPLS RSVP-TE” to denote GMPLS extensions to RSVP-TE. Furthermore, we use the term “connection” and “network element (NE)” to denote what are called LSPs and LSRs, respectively, in GMPLS RSVP-TE. Our usage corresponds to the terminology in use in optical networking.

7.5.1. GMPLS RSVP-TE Objects

7.5.1.1. GENERALIZED LABEL REQUEST

This object is carried in the Path message, and it replaces the label request object (section 7.4.2.1). This object carries the following connection parameters, and its format is depicted in Figure 7-29:

Additional information fields pertaining to the connection are carried in the existing RSVP-TE objects. These are:

The source address information is carried in the Sender Template object, the destination address is carried in the Session object, and the bandwidth is carried in the Tspec object. In addition, when a SONET/SDH connection is established, the related traffic parameters are encoded as described in section 7.3.3. The traffic parameters are carried in the new SONET/SDH Sender Tspec and SONET/SDH Flowspec objects [Mannie+03a].

7.5.1.2. GENERALIZED LABEL

Different label types defined under GMPLS were described in section 7.3.2. Under GMPLS RSVP-TE, the Generalized Label object replaces the Label object (section 7.4.2.1) in the Resv message. The format of this object is shown in Figure 7-30. The Label field can contain various label types, including the MPLS label (Figure 7-22) and the SONET/SDH label (Figure 7-8).

7.5.1.3. SUGGESTED LABEL

Suggested Label is carried in the Path message. As described in the example of Figure 7-7, the downstream NE assigns the label for the source-to-destination direction of the connection. The Suggested Label feature allows an NE to “suggest” to its immediate downstream neighbor the generalized label to be returned during the response phase. The rationale given for introducing the suggested label feature is as follows. Typically, during the response phase, an NE receives a label from its downstream neighbor, sets up its cross-connect based on the received value (see Figure 7-7), and then passes on its own label assignment to its upstream neighbor. With certain all-optical fabrics, establishing a cross-connect might take several tens of milliseconds thus delaying connection provisioning. If an NE can choose a label and make the cross-connect during the request phase, it can eliminate the delay during the response phase.

A suggested label has the same format as the generalized label. Furthermore, a downstream NE need not accept a suggested label, that is, it may return a different label in the response phase. In this case, the upstream NE may have to reestablish the cross-connect. Finally, given that connection provisioning does not have pressing time constraints like protection switching, the value of suggested label during provisioning is rather dubious. It may, however, be of use when connections are dynamically reprovisioned after failures.

7.5.1.4. UPSTREAM LABEL

Upstream Label is carried in the Path message. This label is present if a bidirectional connection is being provisioned. As described before, the downstream NE assigns the label for the forward (source to destination) direction of the connection during the response phase of provisioning (Figure 7-7). This is carried as a generalized label in the Resv message. An upstream label, on the other hand, indicates the label selected by the upstream for the reverse (destination to source) direction of the connection. The upstream label has the same format as the generalized label. Clearly, the specific type of label must match for the two directions of the connection. Furthermore, the parameters have to be the same for both directions of the connection.

7.5.1.5. LABEL SET

Label Set is carried in the Path message. It is used by an upstream NE to control the selection of labels by downstream NEs. That is, an NE indicates the set of labels that are acceptable to it in the request message. A downstream NE must then select a label from this set. For instance, consider the case of provisioning a wavelength connection through an all-optical network where the switches cannot perform wavelength conversion. Here, the source NE would indicate a set of wavelengths it has available for the connection in the Label Set object. As the request message traverses toward the destination, each intermediate NE would look at the received label set, consider the wavelengths locally available, potentially decrease the set of available labels by modifying the Label Set object, and forward the object to its downstream neighbor. When the request reaches the destination NE, it can choose one of the permitted labels (wavelengths) for the connection and indicate this in the response message. The same label is then propagated to the source NE.

The format of the label set object is given in Figure 7-31. Here, the “Action” field indicates the following:

• Action = 0 (Inclusive list): Explicitly indicates each label included in the set. An NE can choose only a label that is listed.

• Action = 1 (Exclusive list): Explicitly indicates each label excluded from consideration. An NE can choose any label except those listed.

• Action = 2 (Inclusive range): Indicates a range of labels included in the set. An NE can choose only a label included in the range. The label set object thus contains two labels, one each for the start and the end of the range.

• Action = 3 (Exclusive range): Indicates a range of labels excluded in the set. An NE cannot choose a label included in the range. The label set object thus contains two labels, one each for the start and the end of the range.

The “Label Type” field indicates the type of label.

7.5.1.6. ACCEPTABLE LABEL SET

Acceptable Label Set is carried in certain PathErr, ResvErr, and Notification (see below) messages. When an NE cannot accept a given label, it may generate an error message with the set of acceptable labels. The Acceptable Label Set object has the same format as the Label Set object.

7.5.1.7. PROTECTION INFORMATION

Protection Information is carried in the Path message. This object indicates the protection desired for the connection on each link in the connection path. This object may be present when provisioning both the working and the protection paths of an end-to-end path-protected connection. The format of the Protection Information object is illustrated in Figure 7-32. The following fields are present:

• Secondary (S) Bit: This 1-bit field indicates whether the connection being provisioned is primary (working, S = 0) or secondary (protection, S = 1). The protection mode request that follows is applicable only to primary connections.

• Link Flags: This 6-bit field is a vector of flags. A bit that is set indicates that a specific protection mode is requested. More than one bit may be set if more than one protection mode is acceptable. The selection of the specific protection mode is then a local decision at each NE.

  • Bit 5 (high order): Enhanced protection.

    This indicates that better protection than 1 + 1 is desired. Typically, this bit would be set to request 4-fiber BLSR/MS-SPRING-type protection.

  • Bit 4: 1 + 1

    This indicates that 1 + 1 protection is desired.

  • Bit 3: 1:1

    This indicates that 1:1 protection is desired.

  • Bit 2: Shared

    This indicates that 1:N or M:N protection is desired.

  • Bit 1: Unprotected

    This indicates that the connection should not be protected on each link.

  • Bit 0: Extra traffic

    This indicates that the connection may be routed as extra traffic on each link, that is, it may be preempted to protect other connections.

Clearly, only the Unprotected mode can be requested for secondary connections (when S = 1). That is, the rest of the protection modes are not applicable to a secondary (protection) connection that provides end-to-end path protection to a primary (working) connection.

7.5.1.8. ADMINISTRATIVE STATUS

The administrative status object is used in signaling messages to indicate that a connection is being administratively “downed,” deleted, or being put in a test mode. GMPLS signaling provides a way to signal these administrative actions. This ensures that NEs in the connection path will not mistake administrative actions for failure events and trigger protection actions. The format of the administrative status object is illustrated in Figure 7-33. The following fields are present:

• Reflect (R): This bit indicates that the received administrative status object must be reflected back by the receiving node in an appropriate message. The usage of this bit will become clear when we look at connection deletion in section 7.5.4.

• Testing (T): This bit indicates that the connection is being set in the testing mode. The actions to be taken at each node receiving the administrative status object with the T bit set is not specified.

• Administratively Down (A): This bit indicates that the connection is being taken down administratively.

• Deletion in progress (D): This bit indicates that the connection is being deleted. The usage of the D bit during connection deletion is described in section 7.5.4.

7.5.1.9. INTERFACE IDENTIFICATION

Under MPLS-TE, signaling messages are sent over the same links that data flows. Thus, the labels that are assigned are specific to the interfaces over which signaling messages are received. Under GMPLS, the control channels over which signaling messages are sent may be distinct from the data links. For instance, there could be an out-of-band control link (e.g., Ethernet) connecting two optical switches. Signaling messages pertaining to connection provisioning over all the data links may be sent over this out-of-band link. Thus, it must be possible in signaling messages to explicitly identify the data link on which labels are being assigned. The interface identification object does this.

Generally, under GMPLS, interfaces can have different types of addressing, as shown in Figure 7-34.^[8] This figure depicts two adjacent NEs with their IP addresses (chosen arbitrarily for this example). Four types of links are shown:

^[8] Not all of these addressing modes may be used in practice.

• A numbered link bundle (also called a “TE link,” see Chapter 10): This bundled link consists of multiple component links. The bundled link itself has an IP address at each end, shown in the figure. The component links are identified by locally distinct identifiers at each end.

• An unnumbered link bundle: Same as above, except that the link bundle does not have an IP address assigned at either end. Instead, a locally distinct identifier is used at either end to identify the bundle.

• A numbered individual link: This is a point-to-point link with an IP address assigned at each end.

• An unnumbered individual link: This is a point-to-point link with a locally distinct identifier at each end.

The bundling concept is used to reduce the routing overhead, as discussed in Chapter 10. During signaling, however, the precise link for label allocation must be identified even if it is part of a bundled link. The interface identification object (called the IPv4 IF_ID_RSVP_HOP object) serves this purpose. This object is used in place of the RSVP Hop object in GMPLS RSVP-TE. The format of this object is shown in Figure 7-35. To understand how this object is used, note that in Figure 7-34, each interface terminating a link (whether individual or component link) has a distinct identifier at an NE. This is the identifier signaled using the interface identification object.

With this object, both the control plane address from which the GMPLS RSVP-TE message is sent, and the data plane component link identifier are captured. The former is captured in the IPv4 previous/next hop address and the LIH fields as in the case of regular RSVP-TE. The latter is captured as follows. If the data link is numbered, the IPv4 address of the link is used as shown in the first TLV. If the data link is unnumbered, then the IPv4 address of the NE and the distinct interface identifier are captured as shown in the second TLV. This usage is further described in section 7.5.3.

7.5.1.10. NOTIFICATION REQUEST

The Notification Request object may be present in Path messages. This object indicates the IP address to which failure-related notifications (see below) should be sent. Each NE that processes the Path message may note this information for notification purposes.

7.5.2. The Notify Message

The Notify message is a new message introduced under GMPLS RSVP-TE. It provides a mechanism for an NE to inform a remote NE (usually the ingress or the egress) about an event related to the connection (usually a failure event). An NE generates a Notify message if it had received a Notify Request object in the Path message. The notify message is different from PathErr and ResvErr in that it can be targeted to a node other than the immediate upstream or downstream neighbor and routed independently of the connection path. The notify message does not replace these error messages. This message contains an error code and a Message ID object.

The receipt of the Notify message is acknowledged by the receiver with an Ack message, which is a Notify message with a Message ID Ack object.

Now that we have examined all the objects, and the new message, defined under GMPLS RSVP-TE, it just remains to be seen how these objects are used in signaling. This is described next.

7.5.3. Connection Establishment under GMPLS RSVP-TE

Having gone through the LSP tunnel establishment procedure under RSVP-TE, it should not be hard to guess as to how connection provisioning would work under GMPLS RSVP-TE. In essence, the Path and Resv messages are used for the request and response phase of provisioning (illustrated in Figure 7-7). There are some differences, however, between the way RSVP-TE is used for LSP establishment in MPLS networks and GMPLS RSVP-TE is used to provision connections in optical networks. Specifically,

• Whereas RSVP-TE signaling occurs over the same links on which the corresponding LSP is established, a separate signaling control link is required between GMPLS RSVP-TE peers. This control link is realized as part of the Data Communication Network (DCN). The DCN could be implemented in-band, for example, using SONET/SDH overhead bytes (see Chapter 6), or it could be an out-of-band network (e.g., an IP network).

• When using GMPLS RSVP-TE, the reliable messaging mechanism described in section 7.4.2.6 is typically used.

• Control plane restart procedures (see section 7.5.5) are implemented when using GMPLS RSVP-TE.

The connection establishment procedure is best described with the aid of an example. Figures 7-36a and 7-36b expand the provisioning example in Figure 7-7 with the details of the Path and Resv messages, respectively. Consider Figure 7-36a first. Here, a network of four NEs is shown. Each NE has an IP address, and other than one of the links between NEs A and B, all other links are unnumbered. Furthermore, all the links are assumed to be OC-48 links. In addition to the data links, the control link between the NEs are shown as dotted lines. Furthermore, each control link interface is identified by the IP address of the corresponding NE and an interface id (LIH) shown next to it.

NE A receives a provisioning trigger to establish a bidirectional STS-48c connection between its interface 1 (with IP address 192.165.1.85) and NE D (IP address = 192.165.4.30), interface 2 (IP address = 192.165.4.45). Based on available routing information, NE A computes an explicit route passing through NEs B, C, and D. In this case, each NE would be responsible for picking the actual link to the next NE when the connection is provisioned.

The Path message generated by NE A is shown. This message has the LSP Tunnel IPv4 Session object set to indicate the remote destination and the locally assigned tunnel ID. The ERO lists the IP address of NEs in the path. The Interface identification object (IF_ID_RSVP_HOP) indicates both the control channel id (IP address and LIH) and the data link ID (IP address for numbered, and IP address plus interface index for unnumbered links). The Generalized Label object lists the type of LSP as SONET and the G-PID as Packet over SONET (POS). The SONET traffic parameters are given in the Sender Tspec. The Sender Template lists the IP address of NE A and the locally assigned LSP ID. Finally, the Upstream Label object indicates the label selected for the D to A direction of the connection. Since the links are OC-48, they can each accommodate only one STS-48c connection and hence, the label type is indicated as port label rather than SONET label.

As the Path message progresses, each intermediate NE creates its Path state, and propagates the Path message to the next NE after modifying the ERO, the upstream label information, and the interface identification information. The message finally reaches NE D, which notices that the destination is local and thus terminates the message.

The corresponding Resv message flow is shown in Figure 7-36b. The Resv message generated by D contains the (port) label for the connection segment from C to D. The Flowspec information essentially reflects the traffic parameters received in the Tspec. The progression of the Resv message is shown in the figure. As each NE processes the Resv message, it sets the appropriate cross-connects to establish the two directions of the connection. Connection provisioning is completed when A receives the Resv message and sets the appropriate cross-connects. The end-to-end connection is shown in the figure using dotted lines.

Not shown in Figure 7-36 is the reliable delivery of Path and Resv messages. This option was described in section 7.4.2.6, and its use is typical in optical network. The usage of this option means that the soft state refreshes can be infrequent. The soft state mechanism is not entirely eliminated (it is part of the RSVP definition), but the time period between refreshes is typically set to a high value. Disruptions in the connection path are typically determined by built-in SONET/SDH mechanisms, and thus a high refresh timer value does not affect the responsiveness of GMPLS RSVP-TE to react to connection failures.

7.5.4. Connection Deletion under GMPLS RSVP-TE

Under RSVP-TE, a source deletes an LSP tunnel by sending a PathTear. As the PathTear progresses, intermediate LSRs simply remove their Path and Resv states. The same procedure cannot be used in an optical network. As soon as an upstream NE deletes its state (and removes the cross-connect), downstream NEs may detect a connection failure and resort to protection action or send out unnecessary alarms. Thus, GMPLS RSVP-TE introduces extra phases in connection deletion such that NEs along the connection path are aware of a deletion in progress before the actual deletion occurs. The Administrative Status object (Figure 7-33) is used in this procedure.

Let us consider the connection that was set up earlier in the example depicted in Figure 7-36. The message sequence for the deletion of this connection when initiated by the source (NE A) is shown in Figure 7-37a. Here, NE A first sends a Path message to initiate deletion. This message is similar to the periodic Path messages sent for the connection except that it has the Administrative Status object with the R and D bits set to 1. As this message progresses along the connection path, each intermediate NE notes that the connection is in the process of being deleted (thus, they will not initiate protection actions if they observe faults along the connection path). When the destination (NE D) receives the Path message, it generates a Resv in response. Since the R bit was set in the received Administrative Status object, NE D reflects the object back in the Resv message with R bit set to 0 and D bit set to 1 (see section 7.5.1.8). When NE A receives the Resv message with the Administrative Status object, it sends a usual PathTear message. As this message progresses along the connection path, the NEs en route remove the Path and Resv state associated with the connection.

The message sequence when deletion is invoked by the destination (NE D) is shown in Figure 7-37b. Here, the NE D first sends a Resv message with the Administrative Status object. The R and D bits in this object are set to 1. This message is propagated toward the source (NE A), and each intermediate NE notes that the connection is about to be deleted. When NE A receives the message, it generates a PathTear as before.

As before, reliable messaging is not shown in Figure 7-37 to simplify the description.

7.5.5. GMPLS RSVP-TE Restart Procedures

A result of the separation of the control and data planes is that failures in the control plane do not imply failures in the data plane. Consider Figure 7-36 again. The control link between NEs is shown as a dotted line. As mentioned before, this link could be a separate out-of-band link or an in-band control channel. In either case, a failure in the control link or the failure of the signaling software process does not imply that any of the previously established data plane connections have been affected. Thus, under GMPLS RSVP-TE, data connections are not removed when control communication is disrupted (whereas under RSVP-TE, the nonreceipt of Path refresh messages will lead to the removal of Path and Resv state at an LSR). Instead, GMPLS RSVP-TE introduces control plane restart procedures. That is, a node that loses the control link to another will attempt to synchronize its Path and Resv state when the control link is reestablished. Meanwhile, connections may themselves be deleted manually or fail. The synchronization process aims to assure that RSVP-TE peers have a consistent view of the connections when they recover from control plane failures.

Thus, we note that deletion of connections in optical networks using GMPLS RSVP-TE is typically the result of an administrative action or a data plane failure. Temporary disruptions in control plane communication do not lead to such deletion. The control plane restart procedures are further described in [Berger03b].

7.5.6. GMPLS RSVP-TE Signaling at the UNI and the NNI

So far, our discussion has been on using GMPLS RSVP-TE as an end-to-end signaling protocol in a network where all the NEs run the protocol. Now consider Figure 7-4, where the UNI and the NNI are shown. One of the main features of the model shown in Figure 7-4 is that signaling at the UNI is independent of signaling within the network. Therefore, when GMPLS RSVP-TE is used for signaling at the UNI, it is possible that a different signaling protocol (or management-system-based provisioning) is used within the network. Also, in the model shown in Figure 7-4, domains are treated like black boxes, that is, one cannot assume that specific signaling protocols are supported for provisioning within a domain. Thus, signaling across the E-NNI is independent of the signaling used within domains.

These assumptions require modifications to GMPLS RSVP-TE if this protocol were to be used for UNI and NNI signaling. Specifically, note that RSVP-TE signaling session destination is the actual end point of the connection being provisioned. In the case of UNI signaling, the GMPLS RSVP-TE session from the source client has to be terminated at the ingress NE, and another session has to be run between the egress NE and the destination node. The continuity of the information transfer must be ensured by the provisioning mechanism used within the network. In addition, UNI signaling requires that certain UNI-specific connection parameters must be carried in signaling messages. The connection model and details can be found in the UNI signaling specifications from the Optical Interworking Forum (OIF) [OIF01].

Now, note that E-NNI signaling is part of provisioning a connection within a network. Thus, provisioning-oriented signaling originates from an ingress node and terminates in an egress node as we have discussed so far. E-NNI signaling occurs where the connection crosses the boundary between domains. If the provisioning of the connection segment within a domain uses a different signaling protocol (or management-system-based provisioning), a problem similar to UNI signaling may arise. This is the case if the signaling controllers are present in border nodes of domains. In this case, the end-to-end signaling has to be “patched up” within domains. The details of E-NNI signaling using GMPLS RSVP-TE can be found in [ITU-T03c].

We have so far focused on the GMPLS RSVP-TE and its precursors. The ATM P-NNI signaling protocol has been adapted for optical network signaling, and it has been successfully deployed. This protocol is described next.