PDF of this tutorial- Data forwarding is now not limited to that of merely packet forwarding. The general solution must be able to retain the simplicity of forwarding using a label for a variety of devices that switch in time or wavelength, or space (physical ports).
- Not every type of network is capable of looking into the contents of the received data and of extracting a label. For instance, packet networks are able to parse the headers of the packets, check the label, and carry out decisions for the output interface (forwarding path) that they have to use. This is not the case for TDM or optical networks. The equipments in these types of networks are not designed to have the ability to examine the content of the data that is fed into them.
- Unlike packet networks, in TDM, LSC, and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units. For example, a packet-based network may have flows of 1 Mbps to 10 or 100 Mbps. However, an optical network will use links that have fixed bandwidths: optical carrier (OC)–3, OC–12, OC–48, etc. When a 10 Mbps LSP is initiated by a PSC device and must be carried by optical connections with fixed bandwidths—e.g., an OC–12 line—it would not make sense to allocate an entire 622M line for a 10M flow.
- Scalability is an important issue in designing large networks to accommodate changes in the network quickly and gracefully. The resources that must be managed in a TDM or optical network are expected to be much larger in scope than in a packet-based network. For optical networks, it is expected that hundreds to thousands of wavelengths (lambdas) will be transporting user data on hundreds of fibers.
- Configuring the switching fabric in electronic or optical switches may be a time-consuming process. For instance, in a DCS that is capable of switching tens of thousands of digital signal (DS)–1 physical ports, identifying the connection between the input/output ports could be time consuming as fewer ports become available to accommodate incoming user traffic. Latency in setting up an LSP within these types of networks could have a cumulative delaying effect in setting up an end-to-end flow.
- SONET networks have the inherent ability to perform a fast switchover from a failed path to a working one (50 milliseconds). GMPLS' control plane must be able to accommodate this and other levels of protection granularity. It also needs to provide restoration of failed paths via static (pre-allocated) or dynamic reroute, depending on the required class of service (CoS).
These issues are summarized in Table 3 and discussed in subsequent sections in more detail.
| Issue | GMPLS Solution(s) | Protocol(s) | Notes |
| Switching diversity | Generalized label | Signaling: RSVP–TE, CR–LDP | LSP to start and end on the same type of device |
| Forwarding diversity | Logical or physical separation of control and data | All | Signaling and routing to travel out of band |
| Configuration |
| Signaling | Expedite LSP set-up |
| Scalability |
| Routing and signaling: OSPF–TE, IS–IS–TE |
|
| Reliability |
|
|
|
| Efficient use of network resources |
| Signaling/routing | Save on excess use of scarce IP addresses |
Table 3. Summary of Issues in a Common Control-Plane Approach
Switching Diversity
Generalized Label and Its Distribution
To be able to support devices that switch in different domains, GMPLS introduces new additions to the format of the labels. The new label format is referred to as a "generalized label" that contains information to allow the receiving device to program its switch and forward data regardless of its construction (packet, TDM, lambda, etc.). A generalized label can represent a single wavelength, a single fiber, or a single time-slot. Traditional MPLS labels—e.g., ATM, VCC, or IP shim—are also included. The information that is embedded in a generalized label includes the following:
- LSP encoding type that indicates what type of label is being carried (e.g., packet, lambda, SONET, etc.)
- Switching type that indicates whether the node is capable of switching packets, time-slot, wavelength, or fiber
- A general payload identifier to indicate what payload is being carried by the LSP (e.g., virtual tributary [VT], DS-3, ATM, Ethernet, etc.)
Details of a GMPLS label can be found in reference [2].
Similar to MPLS, label distribution starts from the upstream LSR requesting a label from the downstream LSR. GMPLS takes this further by allowing the upstream LSR to suggest a label for a LSP that can be overridden by the downstream LSR. (Suggested labels are covered in a later section.)
LSP Creation in GMPLS-Based Networks
Establishing an LSP in a GMPLS network is similar to that of MPLS networks. Figure 4 shows a packet network (PSC) connected via an OC–12 pipe to DCS1 in the upper TDM network. Both of the TDM networks shown use a SONET UPSR OC–48 ring architecture. The two TDM networks are connected via two OXCs capable of delivering multiple OC–192 lambdas. The goal is to establish an LSP (LSPpc) between LSR1 and LSR4.
Figure 4. Establishing an LSP through Heterogeneous Networks with GMPLS
To establish the LSPpc between LSR1 and LSR4, other LSPs in the other networks must be established to tunnel the LSPs in the lower hierarchy. For example, per Figure 4, LSP1T1 will carry LSP1, LSP2, and LSP3 if the sum of the traffic-engineering requirements of the packet LSPs can be accommodated by it.
This is done by sending a PATH/Label Request message downstream to the destination that will carry the lower hierarchy LSP. For example, DSCi sends this message to OXC1, destined for DSCe. When received by OXC1, it will then create an LSP between it and OXC2. Only when this LSP (LSPl) is established will an LSP between DSCi to DSCe be established (LSPtdi).
The PATH/Label Request message contains a Generalized Label Request with the type of LSP (i.e., the layer concerned), and its payload type (e.g., DS–3, VT, etc.). Specific parameters—such as type of signal, local protection, bidirectional LSP, and suggested labels—are all specified in this message. The downstream node will send back a RESV/Label Mapping message including one generalized label that may contain several generalized labels.
When the generalized label is received by the initiator LSR, it can then establish an LSP with its peer via RSVP/PATH messages per network domain. In Figure 4, the following sequence has taken place:
- LSP is established between OXC1 and OXC2 (LSPl) and capable of delivering OC–192 wavelength to tunnel in TDM LSPs.
- LSP is established between DSCi and DSCe (LSPtdi).
- LSP is established between DS–1 and DS–2 (internal LSPs within the two TDM networks are established prior to the establishment of this LSP).
- LSP is established between LSR2 and LSR3 (LSPpi).
- LSPpc is established between LSR1 and LSR4.
Forwarding Diversity
MPLS devices are capable of discerning the contents-of-information unit that is passed between them—e.g., a packet or a cell that has header information. They need to examine the label (e.g., shim header) to determine the output port and the output label for an incoming packet. The label-swapping paradigm logically separates the data and the control planes.
GMPLS extends this paradigm to those devices that are designed to lookup any headers when they receive the user data. In this case, GMPLS allows the data plane and the control plane to be physically, or logically, separate. For example, the control path between two devices could travel an external line such as an Ethernet connection, or other types of physical links. GMPLS does not mandate how the control information is to be transported between two nodes.
The selection of a medium to carry the control information between the two GMPLS nodes can impact the economics of the network operator. Clearly, a single fiber should not be used to carry this information between two geographically separate devices—e.g., two DCSes in a SONET ring network. Other connection types may be costly to use—e.g., an X.25 connection. One approach is to take a logical slice of a line—e.g., synchronous transport signal (STS)–1—and use the data communication channel (DCC) bytes in the SONET overhead to carry the control information. These bytes are comprised of section and line overhead (three and nine bytes, respectively) and can both be used for this purpose. Together they provide a 768 kbps channel for the exchange of control messages. They can be used in each direction between two adjacent nodes. This is a highly efficient method that does not take away bandwidth that could be used for user data traffic.
Configuration
When an LSP is being established starting from the access network, it may require the establishment of several other LSPs along its end-to-end path. These intermediate LSPs may be established on TDM– and/or LSC–based devices. These devices have different internal characteristics, and, therefore, GMPLS must accommodate these differentials in such a way as to expedite the establishment of the end-to-end LSPs. Two important new concepts that are introduced in GMPLS to address these differences are as follows.
Suggested Label
As mentioned in an earlier section, an upstream node can optionally suggest a label to its downstream node. The downstream node has the right of refusal and may propose its own. Nevertheless, this operation is crucial to systems that require time-consuming processes to configure their switch fabric—for example, a DCS with high switching granularity (e.g., DS–1, DS–3) and thousands of ports that must go through a time-consuming operation in configuring its switching fabric. Recall that a label in this case is used to quickly find the internal path between an input and an output port. A suggested label allows the DCS to configure itself with the proposed label, instead of waiting to receive a label from the downstream node, and then configure its hardware. Suggested labels are also important in expediting the set-up of back-up paths (LSPs) for a failed LSP. However, if the downstream device rejects the suggested label and offers its own, the upstream device must re-configure itself with the new label.
Bidirectional LSP
Network protection—e.g., against fiber cuts—in optical networks is provided with back-up fibers, such as four-wire BLSR or two-wire BLSR architectures. Similarly, LSPs in an optical network need to be protected. This is accomplished by establishing two unidirectional LSPs—one LSP to protect the other. Bidirectional LSPs must have the same traffic-engineering and restoration requirements.
GMPLS supports the setup of bidirectional LSPs via one set of signaling protocol messages (e.g., RSVP/PATH and RESV). This helps to avoid the extraneous exchange of control messages, race conditions, additional route look-ups, and configuration-latency in setting up the internal input/output (I/O) paths in an optical switch.
Scalability
Forwarding Adjacency–LSP (FA–LSP)
A FA–LSP is a GMPLS–based LSP to carry other LSPs. An FA–LSP established between two GMPLS nodes can be viewed as a virtual link with its own traffic-engineering characteristics and can be advertised into the OSPF/IS–IS as a normal link like any other physical link. An FA–LSP may be incorporated into the link-state database and used in routing-path calculation to carry other LSPs. This can reduce the size of the database, and, consequently, the time that is spent in the table look-up operation.
An FA–LSP may be either a numbered or unnumbered and may be bundled with other links, whether they are FA–LSPs or normal links. Both concepts are discussed in later sections.
Figure 5 shows how a TDM LSP (LSPtdm) can be viewed as a link that connects two packet-based networks. This LSP can be viewed as a single link in the packet-based LSRs of the two PSC networks, instead of all of the physical links in the TDM network.
Figure 5. Forwarding Adjacency
Hierarchical LSP
The network hierarchy (access, metro, and long haul) shown in Figure 6 provides an increasing bandwidth capacity per hierarchy. When an end-to-end flow is to be establish for a particular enterprise application, that flow will traverse networks that use devices that may not be designed to configure connections with flexible bandwidth levels—i.e., only discrete bandwidth are available. In this case, a single OC–192 physical link between two optical switches should not be expected to carry a traffic that is only 100M or even 2.5G, as it would be wasteful and highly inefficient. It is better to aggregate lower-speed flows into higher-speed ones. This brings the notion of hierarchical LSP.
Figure 6. Network Hierarchy
A natural hierarchy is established wherein a group of PSC–LSPs are nested within TDM–LSPs that are then nested within a LSC that is part of a group of LSCs within an FSC. The link multiplex capability parameter introduced in GMPLS specifies this ordering when an LSP is being established. Clearly, bandwidth that remains within each LSP can and should be used to accept and include additional LSPs from lower-hierarchy LSPs. Figure 7 shows this hierarchy.
Figure 7. Hierarchical LSPs
Link Bundling
It is expected that an optical network will deploy tens to hundreds of parallel fibers, each carrying hundreds to thousands of lambdas between two nodes. To avoid a large size for the link database and provide better scaling of the network, GMPLS has introduced the concept of link bundling.
Link bundling allows the mapping of several links into one and advertising that into the routing protocol—i.e., OSPF, IS–IS. Although, with the increased level of abstraction, some information is lost, this method greatly lowers the size of the link-state database and the number of links that need to be advertised. A bundled link needs only one control channel, which further helps to reduce the number of messages exchanged in signaling and routing protocols.
GMPLS flexibly allows the bundling of both point-to-point (PTP) links and LSPs that were advertised as links to OSPF (forward adjacency).
There are restrictions in bundling links. These are as follows:
- All links that comprise a bundled link must begin and end on the same pair of LSRs.
- All links that comprise a bundled link must be of the same link type (e.g., PTP or multicast).
- All links that comprise a bundled link must have the same traffic metric (e.g., protection type or bandwidth).
- All links that comprise a bundled link must have the same switching capability—PSC, TDMC, LSC, or FSC.
Bundled links result in loss of granularity in the network resources. Nevertheless, the gain in the reduction of link-state database entries and the speed gain in table look-ups far outweigh the lost information.
Reliability
A key attribute of GMPLS suite of protocols is the ability to enable automated fault management in network operation. A fault in one type of the network must be isolated and resolved separately from other networks. This is a very important feature for end-to-end LSPs that are tunneled in other LSPs that require higher degrees of reliability along the hierarchy. A common control plane that spans dissimilar networks must be able to address the varying degrees of reliability requirements within each network span.
The steps that are necessary to carry out fault management are shown in Figure 8.
Figure 8. Fault-Management Process in GMPLS
For end-to-end path protections, the primary and secondary paths are computed and signaled to indicate that the two paths share reservations. Shared-risk link group is an optional mechanism that allows the establishing of back-up LSPs that do not have any links in common with the primary LSP. This is achieved in the routing extension of OSPF/IS–IS.
The restoration of a failed path refers to the dynamic establishment of a back-up path. This process requires the dynamic allocation of resources and route calculation. Two different restoration methods are given: line and path. Line restoration finds an alternate route at an intermediate node. Path restoration is initiated at the source node to route around a failed path anywhere within the path for the specific LSP. In Figure 9, node 1 can initiate this new path. In general, restoration schemes take longer to switch to the back-up path, but they are more efficient in bandwidth usage, as they do not pre-allocate any resource for an LSP.
Figure 9. Protection Schemes Supported in GMPLS
Efficient Resource Usage
The inclusion and management of resources in TDM and optical devices, via an IP-based control plane, requires new levels of optimization. Link bundling was discussed earlier as a method to reduce the size of the link-state database per TDM and optical networks. Another major issue in TDM and optical networks is their potential usage of IP addresses. This is discussed next.
Unnumbered Links
Instead of assigning a different IP address to each TDM or optical link, the concept of "unnumbered links" is used to keep track of these types of links. This is necessary because of the following:
- The number of TDM channels, wavelengths, and fibers can easily reach a point where their management, per IP address, will become very time-consuming.
- IP addresses are considered scarce resources.
An unnumbered link is a link that has no IP address—instead, a combination of a unique router ID and link number is used to represent it. These links carry traffic-engineering information and can be specified in the signaling plane, just like a regular link with an IP address.
RSVP–TE and CR–LDP have both been extended to carry this information in the signaling plane. The same has been done in the routing protocols (OSPF–TE, IS–IS–TE). For further information see references [4,5].
