7.3. GMPLS Signaling

Signaling was not part of the original IP network architecture—there was no need to establish a connection in an IP network before sending IP packets. With the advent of traffic engineering based on MPLS (denoted as MPLS-TE, see Chapter 5), the notion of explicitly routed Label Switched Paths (LSPs) came into being. Such LSPs, in essence, are connections over which IP (and potentially other protocol) packets can be carried from a source to a destination. Thus, traffic engineering applications over MPLS have made use of signaling protocols such as RSVP-TE and CR-LDP.

Generalized MPLS (or GMPLS) extends the basic MPLS-TE concepts to cover non-IP networks, in particular, optical networks. The rationale behind GMPLS was described in Chapter 5. In this section, our discussion focuses on GMPLS signaling, as described in [Berger03a].

First of all, as compared with G.7713, the GMPLS signaling specification addresses more concrete issues, such as specific formats of addresses and messages, and signaling actions. Thus, while the GMPLS signaling specification is protocol-neutral, it is only a small step removed from the actual protocols. The two MPLS-TE protocols, RSVP-TE and CR-LDP, are enhanced for use under GMPLS.

GMPLS signaling deals with multiple types of underlying equipment. Generically denoted as Label Switching Routers (LSRs),^[2] this includes optical NE such as SONET/SDH cross-connects and transparent optical switches. The GMPLS specification in fact deals with different interfaces, a combination of which is allowed in an LSR. These interfaces are:

^[2] The term LSR is a remnant of the corresponding usage in MPLS. Denoting an optical switch as an LSR is awkward, but this is the convention followed in the GMPLS specification.

MPLS signaling protocols deal only with (1). Under GMPLS, these protocols are extended to deal with all four. Specifically, GMPLS signaling allows connections to be established, maintained, and torn down over all these interface types. GMPLS signaling allows the provisioning of both working and protection connection paths. Signaling for protection/restoration is covered in the next chapter. In the following, we highlight the essential features of GMPLS signaling.

7.3.1. Basic Signaling Model

The concept of an MPLS label, its allocation, and its usage were described in Chapter 5. To recall, MPLS LSPs are unidirectional, from a source node to a destination node. A node along an LSP is said to be upstream from another node if the former is closer to the source than the latter. The latter is then said to be downstream from the former. While establishing an MPLS LSP, each node in the path must allocate a label and convey it to the immediate upstream node in the path. When packets begins flowing on the LSP, the first node inserts the label in each packet given by the immediate downstream node. Each node receiving a packet switches the label in the received packet with the one given by the downstream node and forwards the packet over the appropriate interface.

Under GMPLS, a label is no longer carried in the data, but identifies a time slot, wavelength, or port through which the connection data must be switched (depending on the type of interface). The purpose of GMPLS signaling, in essence, is to allow each LSR in the path of a connection to allocate labels pertaining to the connection, communicate the assignment to the appropriate neighbor, and to make the appropriate cross-connect to switch the connection. Whereas MPLS LSPs are unidirectional, GMPLS allows the establishment of bidirectional LSPs. Thus, GMPLS signaling permits the allocation of labels for both directions of data flow concurrently.

Connection provisioning under GMPLS is either initiated through a management system (soft permanent connections) or by a client device through signaling (switched connections). In either case, the trigger is received by the source NE. Assuming that the connection route is available, either computed by the source NE or given in the provisioning trigger, the source NE makes a request to the next NE in the connection route to allocate a label (e.g., identify a port or time slot). The request message contains the connection endpoint identifiers and other parameters. For bidirectional connections, this request also contains the label allocation for the direction of the connection from the next NE (the reverse direction). An NE that receives a label allocation request processes the request and sends its own request to the next NE in the path and so on until the request reaches the destination NE. A response is then sent from the destination NE hop by hop toward the source NE. The response contains the label allocated by the downstream NE to its immediate upstream NE for the forward direction. This basic signaling model is illustrated in Figure 7-7. Here, each node allocates the “label” (which actually indicates the port number) for the reverse direction of the connection and solicits the label for the forward direction in the request phase. The forward labels are obtained in the response phase. Under GMPLS signaling, labels are local to the assigning node. Thus, label number 2 (which indicates port 2) sent by node A has to be converted to the corresponding port number at B (port 4). This mapping must either be manually configured in B or automatically obtained through neighbor discovery procedures (Chapter 6). Also, in this example, both directions of the connection are routed over the same path (the same set of links). This is typical in SONET/SDH networks.

Before we proceed further, it is instructive to understand the relationship between the G.7713 model and GMPLS signaling. In essence, G.7713 defines signaling interfaces and functional requirements. GMPLS defines specific signaling messages, objects, and procedures to realize connection provisioning. GMPLS signaling can thus be used at each of the signaling interfaces defined in G.7713. Indeed, this is exactly what has been described in ITU-T recommendations G.7713.2 [ITU-T03c] and G.7713.3 [ITU-T03d], which deal with GMPLS RSVP-TE and GMPLS CR-LDP protocols applied to G.7713 signaling.

It should be noted that under the GMPLS signaling architecture, a distinction is not made explicitly between the UNI and NNI. The same signaling method is applicable regardless of the type of interface, although the information content of signaling messages might be different. Furthermore, GMPLS signaling is between peer nodes that are neighbors in the signaling path. These nodes may be neighbors in the data path, or they may be signaling controllers, which represent a group of nodes. In other words, GMPLS does support the control plane/data plane separation, and the protocols are applicable to the model described earlier under G.7713.

Finally, GMPLS utilizes the messages already defined under MPLS-TE protocols (RSVP-TE and CR-LDP) for label request, response, and so on, but it adds new information elements (called objects) to these messages along with the corresponding processing rules. Because of the closeness of the GMPLS signaling architectural model to the underlying protocols, it is best to look at the GMPLS-defined extensions in the context of these protocols. Even though there are two such protocols, our focus in this chapter will be on the RSVP-TE protocol [Berger03b] (section 7.4). This protocol is more popular than CR-LDP, and provides identical functionality. Readers who are interested in CR-LDP are referred to [Ashwood-Smith+03].

In the reminder of this section, we look at two important definitions under GMPLS: the new label types and the traffic parameters for SONET/SDH connections. GMPLS extensions pertaining to actually establishing, maintaining, and releasing connections are described in section 7.5.

7.3.2. GMPLS Labels

The label, as defined under MPLS, is a flat 20-bit number. GMPLS allows multiple types of labels, denoted as generalized labels. These labels are carried in signaling messages, as shown in the model of Figure 7-7. The following label types, in addition to the MPLS labels, are recognized under GMPLS.

7.3.2.1. PORT OR WAVELENGTH LABEL

This is a 32-bit number. It indicates a port number or a wavelength identifier when fiber switching is used. The label value is of significance only to the allocating node. A node receiving such a label may have to map it onto a locally significant port or wavelength identifier. For instance, consider the example shown in Figure 7-7. When node B indicates (port) label = 4 to node A, node A must map it onto a local port identifier, in this case, 2. Thus, node A knows it must make a cross-connect from its port 2 to its port 1 to provision the connection.

7.3.2.2. WAVEBAND LABEL

Waveband switching allows a set of wavelengths to be switched together. Whereas the fiber/wavelength label allowed the description of a single port/wavelength, the waveband label indicates a set of contiguous wavelength values. The details can be found in [Berger03a].

7.3.2.3. SONET AND SDH LABELS^[3]

^[3] SDH and SONET labels are defined in [Mannie+03], and the description in this section closely follows the material in [Mannie+03].

SONET and SDH each define a multiplexing structure, with the SONET multiplex structure being a subset of the SDH multiplex structure. These two structures are trees whose roots are respectively an STS-N or an STM-N signal and whose leaves are the signals that can be transported and switched via time slots, that is, an STS-x SPE, VC-x or a VT-x SPE. A SONET/SDH label will identify the exact position (i.e., first time slot) of a particular STS-x SPE, VC-x or VT-x SPE signal in a multiplexing structure.

Here, time slots are identified in the sequence in which they appear in the multiplex, not as they appear after any possible interleaving. These multiplexing structures are used as naming trees to create unique multiplex entry names or labels. Since the SONET multiplexing structure may be seen as a subset of the SDH multiplexing structure, the same format of label is used for SONET and SDH.

In the case of contiguous concatenation, only one label appears in the signaling message. This label identifies the lowest time slot occupied by the contiguously concatenated signal, that is, the time slot occupied by the first component signal of the concatenated signal when descending the tree. In the case of virtual concatenation, the signaling message must indicate the ordered list of all labels pertaining to the concatenated signals. Each label indicates the first time slot occupied by a component of the virtually concatenated signal. The order of the labels must reflect the order of the payloads to concatenate (not the physical order of time slots). In the case of multiplication (i.e., using the multiplier transform, see section 7.3.3), the ordered list of the labels of the constituent elementary signals is carried in signaling messages. In case of multiplication of virtually concatenated signals, the first set of labels indicates the time slots occupied by the first virtually concatenated signal, the second set of labels indicates the time slots occupied by the second virtually concatenated signal, and so on.

It should be noted that when multiple labels are used to describe a signal as in the virtual concatenation and the multiplication case, these labels refer to signals carried on the same link. Thus, it seems like even though the standard definition for virtual concatenation allows component signals to be routed over different paths (see Chapter 3), GMPLS signaling restricts the routing to the same path. But normally, virtually concatenated signals are provisioned independently, and then concatenation is performed at the end points (see Chapter 3). GMPLS defines a feature to provision all the components of a virtually concatenated signal in one shot through the network.

The format of the SONET/SDH label is given in Figure 7-8. The components shown depict an extension of the numbering scheme defined in G.707, that is, the (K, L, M) numbering [ITU-T00a]. The higher order numbering scheme defined in G.707 is not used here. Each letter shown in the figure indicates a possible branch number starting at the parent node in the multiplex structure. Branches are numbered in increasing order from number 1, starting from the top of the multiplexing structure. Figure 7-9 depicts the branching for SONET and gives an example of a SONET label.

When a hierarchy of SONET/SDH connections (LSPs) is established, an LSP with a given bandwidth can be used to carry lower order LSPs. The higher order SONET/SDH LSP behaves as a virtual link with a given bandwidth (e.g., VC-3). A lower order SONET/SDH LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is not significant and it is set to zero, that is, the label is “0,0,0,L,M.” Similarly, if the structure of the higher order LSP is unknown or not relevant, the lowest part of that label is not significant, and it is set to zero, that is, the label is “S,U,K,0,0.” For instance, a VC-3 LSP can be used to carry lower order LSPs. In that case the labels allocated between the two ends of the VC-3 LSP for the lower order LSPs will have S, U, and K set to zero, while L and M will be used to indicate the signal allocated in that VC-3.

The possible values of S, U, K, L and M are defined as follows:

A label is always interpreted along with the SONET/SDH traffic parameters (section 7.3.3), that is, a label by itself does not indicate which signal is being requested. A summary of the S, K, U, L, M values, along with usage examples, can be found in [Mannie+03a].

7.3.3. GMPLS Encoding of SONET/SDH Connection Parameters

The SONET/SDH connection parameters specify the type of SONET/SDH connection being established (e.g., STS-n) and the transparency objectives. Instead of listing all possible connection types and transparency combinations explicitly, the SONET/SDH connection parameters are encoded under GMPLS as a set of parameters that can be used to derive the connection characteristics. These parameters, as depicted in Figure 7-10, are:

• Signal Type: This 8-bit field indicates the type of an elementary signal. The elementary signal can be transformed using concatenation, multiplication, and transparency operations to derive the final signal carried in the connection being provisioned. The transforms are all optional, and if indicated, they must be applied strictly in the following order:

  • First, contiguous concatenation (using the RCC and the NCC field values) is applied on the elementary signal, resulting in a contiguously concatenated signal.
    
    
  • Second, virtual concatenation (using the NVC field value) is applied either directly on the elementary signal, or on the contiguously concatenated signal obtained from the previous phase.
    
    
  • Third, transparency is applied (see Chapter 3).
    
    
  • Finally, a multiplication (using the multiplier field value) is applied directly on the elementary signal, or on the con tiguously 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 form of transparency.
    
    The permitted Signal Types for SONET/SDH are listed in Table 7-1.
    
    

  Table 7-1. SONET/SDH Signals Types

  Signal Type Field	Indicated Elementary Signal (SONET / SDH)	Comments
  1	VT1.5 SPE / VC-11
  2	VT2 SPE / VC-12
  3	VT3 SPE
  4	VT6 SPE / VC-2
  5	STS-1 SPE / VC-3
  6	STS-3c SPE / VC-4
  7	STS-1 / STM-0	Only when requesting transparency
  8	STS-3 / STM-1	Only when requesting transparency
  9	STS-12 / STM-4	Only when requesting transparency
  10	STS-48 / STM-16	Only when requesting transparency
  11	STS-192 / STM-64	Only when requesting transparency
  12	STS-768 / STM-256	Only when requesting transparency

  
  

  Note that a dedicated signal type has been assigned to the SONET STS-3c SPE rather than coding it as three contiguously concatenated STS-1 SPEs. This has been done in order to provide an easy mapping between SONET and SDH signaling.

• Requested Contiguous Concatenation (RCC): This 8-bit field indicates the required contiguous concatenation of the elementary signal. This field is a vector of flags, with each flag indicating a particular type of contiguous concatenation. Several flags can be set at the same time to indicate a choice. Presently, the following flag is defined:

  • Flag 1 (bit 1, low order bit): Standard contiguous concatenation.

  Flag 1 indicates that the standard SONET/SDH contiguous concatenation as defined in T1.105/G.707 [ITU-T00a] is requested. Other flags are reserved for future use.

• Number of Contiguous Components (NCC): This 16-bit field indicates the number of identical SONET/SDH SPEs/VCs that should be concatenated using the method specified in the RCC field.

• Number of Virtual Components (NVC): This 16-bit field indicates the number of signals that need to be virtually concatenated.

• Multiplier: This 16-bit field indicates the number of identical signals that together form the final signal constituting the connection. These signals can be identical elementary signals, or identical contiguously concatenated signals, or identical virtually concatenated signals.

• Transparency: This 32-bit field is a vector of flags that indicates the type of transparency being requested. Several flags can be combined to request different types of transparency. Not all combinations are necessarily valid. Transparency is only applicable to the fields in the SONET/SDH frame overheads. In the SONET case, these are the fields in the Section Overhead (SOH) and the Line Overhead (LOH). In the SDH case, these are the fields in the Regenerator Section Overhead (RSOH), the Multiplex Section overhead (MSOH), and the pointer fields between the two. With SONET, the pointer fields are part of the LOH.

  Transparency is only applicable when using the following signal types: STM-0, STM-1, STM-4, STM-16, STM-64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-768. At least one transparency type must be specified when requesting such a signal type.

  The different transparency flags are the following:

  • Flag 1 (bit 1, low order): Section or regenerator section layer.

  • Flag 2 (bit 2): Line or multiplex section layer.

  A flag is set to 1 to indicate that the corresponding transparency is requested.

  SONET section/SDH regenerator section layer transparency means that the entire frame must be delivered unmodified. This implies that pointers cannot be adjusted. SONET line/SDH multiplex section layer transparency means that the LOH/MSOH must be delivered unmodified.

• Profile: This field is intended to indicate particular capabilities that must be supported for the connection, for example, monitoring capabilities. Presently, no profile has been defined.

To understand GMPLS-based signaling, it is best to look at a signaling protocol. Our choice, as mentioned earlier, is RSVP-TE. In the following section, we first go through the basic details of RSVP and RSVP-TE. In section 7.5, we look at the GMPLS extensions to RSVP-TE. When describing a protocol, whose specification is rather rich, it is often a difficult to judge how much detail is good enough. Our approach in the following sections is to avoid clutter and look at details that are essential to understand the main features of the protocols pertaining to provisioning. Interested readers can explore further by following the references given.