Generalized Multiprotocol Label Switching
Generalized Multiprotocol Label Switching (GMPLS) is an extension of MPLS. GMPLS creates a multipurpose control plane that supports not only packet switching, but also network devices that perform switching in the time domain, wavelength domain, space domain, or on packet or cell headers. This control plane can manage any network element as part of a larger network. Essentially, the control plane manages one network (as opposed to one network that sits upon another, that sits upon another, and so forth).
The goal is to converge the separate but essential management protocols existing at different layers in a network architecture into a single set of protocols. There are two benefits of such a goal.
- Reduce operational expenditure: Network operating expenses can account for much of a business’s costs. GMPLS can reduce such expenses by increasing staff productivity. And, as networks become more complex to carry more traffic, more customers, and more diverse services, staff increases might not be necessary. Also, GMPLS traffic engineering can delay network upgrades to better utilize existing resources and therefore reduce overall capital expenditure.
- Increase revenue: The primary way in which GMPLS can increase revenue is by enabling new services (e.g., Layer 2 VPNs and Layer 3 VPNs). GMPLS can also enable a company to grow, diversify, and improve service velocity (i.e., time to provision and make a new service available to customers), without a corresponding increase in complexity in the network core.
GMPLS can allow new services (i.e., new sources of revenue) to be provisioned and managed quickly and cost-effectively on a single network that is itself cost-effective and simpler to manage.
What Is a Label?
The converged network allows existing networks that comprise routers, switches, DWDM systems, ADMs, PXCs, and OXCs to use GMPLS to dynamically provision the required resources and to allow for the required redundancy. GMPLS supports not only packet switching but also network devices that perform switching in the time domain, wavelength domain, space domain, or on packet or cell headers.
- Packet switching: Packet or cell switching based upon labels is not new. MPLS is based on this concept where a label, combined with the port on which the data was received, is used to determine the output port and label for the data. Frame relay and ATM work similarly.
- Wavelength: λ switching, a subset of GMPLS (previously known as MPlS), abstracts the concept of a label into the optical domain by viewing a λ as an implicit label (i.e., an incoming λ combined with a port is mapped to an outgoing port and corresponding λ).
- Time: Timeslots on a TDM circuit can also be abstracted as an implied label. An incoming timeslot and port number are mapped to an outgoing timeslot and port number. This can occur on any TDM technology (e.g., T-1, E-1, T-3, SONET/SDH).
- Space: A port on a device can be mapped as a whole to an outgoing port. This is the essence of traditional circuit switching, where a port belongs to an individual customer’s circuit. So, GMPLS can dynamically provision a traditional circuit using the same signaling processes that allow other types of provisioning in the network. In an optical network this is likely to be a fiber.
In the case of packet switching, the label is explicit—the data packet owner is explicitly defined by the value of the label, which is overhead appended to the data in the form of a circuit ID. Examples of this appended label include the frame relay DLCI, ATM VPI/VCI, and MPLS labels. In all other techniques the label is implied—the circuit ID consumes no overhead per circuit, but the data owner (circuit ID) can be inferred by the wavelength, timeslot, or port on which it arrives.
Consequences of the Architecture
GMPLS requires that a circuit be established only between like devices (i.e., an MPLS LSR is required to understand a label, and an OXC is required to understand a lambda). Still, a label cannot be switched to a lambda. What results, however, is label stacking—a label can be tunnelled through a lambda.
With GMPLS, all network devices are IP-enabled and participate in signaling. The control plane is made up of a link state routing protocol (OSPF or IS-IS with extensions to support GMPLS) and a signaling protocol (RSVP-TE or CR-LDP with extensions for GMPLS).
All devices have IP addresses. It is undesirable for every device to have addresses on every interface, so GMPLS allows unnumbered links. Such links eliminate the administrative burden and drain on the depleting IP address space.
Optical devices forward user data transparently—they do not interpret the switched data. This implies that the user data path cannot be used for control signaling. MPLS already defines the control protocols to be logically separate from the forwarding path (RSVP-TE inside IP vs. MPLS-labeled user data). GMPLS extends this concept to allow the control protocols to use a physically diverse path from the user’s data path. Consequently, link management protocols must be implemented; it can no longer be assumed that because the control plane is intact that the forwarding plane is, and visa versa.
LSPs created across a GMPLS network must start and terminate on like equipment. Lambdas must terminate on equipment that understands lambdas.
In addition, the signaling between the layers of hierarchy can reduce the link state topology information exchanged, in much the same way as OSPF areas or PNNI peer groups can.
More Efficient Allocation of Bandwidth
Label stacking allows a hierarchy to occur that eliminates the limitation in the optical domain of the discrete nature of bandwidth allocation. In MPLS an LSP can be allocated any amount of bandwidth; however, when a l is allocated, the whole 2.488 Gbps is allocated. Label stacking allows part of the l to be allocated to one LSP and the rest divided among other LSPs. The same analogy holds true for any circuit-based technology. If SONET is provisioned using GMPLS, more granularity in the bandwidth allocation is available than with the discrete allocation of an OC-X. The first T-1 provisioned on a SONET link consumes the bandwidth equivalent to an STS-1 (using VT-1.5). The assumption is that the data traffic volume (i.e., packets) is greater than voice traffic volume.
GMPLS allows more granularity and flexibility in how we provision bandwidth.
The visual shows a typical modern-day networking scenario in which two clients (network users) are interconnected across a path that implements several technologies.
Each user is connected to a router, probably across some type of LAN (not shown). The routers are MPLS-aware (i.e., they are label switching routers (LSR)). Each router is served by an ATM switch, perhaps in a carrier backbone network. Inside the carrier network, a SONET infrastructure interconnects the ATM switches. The SONET nodes are likely to be arranged in ring topologies (not shown). Finally, the SONET nodes are interconnected across a long-haul optical backbone (i.e., the OTN).
Without GMPLS, establishing and managing such a connection would be extremely complex. The coordination required among many different control plane protocols would be difficult to achieve. With GMPLS, however, each layer technology views its segment of the overall connection as a simple label switched path (LSP) that has certain operational parameters associated with it. This process is implemented via label stacking.
GMPLS provides a single control plane for all optical technologies and standardizes on an IP-based signaling and control protocol. As the principal tool for the automatic optical network, GMPLS supports capabilities and features that allow network operators to control their optical devices. These capabilities span technologies and support a consistent level of service for customers.
- Automate end-to-end provisioning: Allows network administrators to automate the process of determining bandwidth availability and assigning that bandwidth to customer paths.
- Manage Network Resources: GMPLS makes the optical devices as intelligent as IP routers for network discovery and resource allocation. Each optical node converses with its neighbors to determine bandwidth assets.
- Support QoS: The MPLS roots of GMPLS support traffic differentiation with flow identifiers. Flow identifiers provide QoS in that each flow can be handled with its own set of rules for bandwidth, delay, and reliability.
GMPLS operates across technology boundaries, providing provisioning and flow distinction for customer traffic. To perform these services GMPLS supports the functions below.
- Routing: Support OSPF link state routing protocol across packet and non- packet technologies to allow path discovery based on bandwidth routing constraints.
- Signaling: Use RSVP to establish and terminate traffic flow paths end-to-end in a mixed technology environment.
- Link Management: Use the Link Management Protocol (LMP) to discover and manage adjacencies between GMPLS-capable devices.
These functions require an out-of-band management channel (plane) among all devices. This channel might be on a separate physical network (Ethernet), a dedicated channel (SONET line overhead), or a virtual channel (ATM VCI). In all cases the same IP protocols are used among all devices.
Different organizations approach the GMPLS solution from various directions. As a result, there are many documents that use different terms to describe the solution. For example, one solution to incorporating an optical network into a single forwarding and management architecture is GMPLS; other working groups call this solution an automatic switched transport network (ASTN) or an automatic switched optical network (ASON).
In general, most organizations see GMPLS as a way to incorporate all layers of network infrastructure and management and as a way to achieve interoperability. GMPLS standards are not currently finalized; however, the list below names documents that describe the architecture and intent of GMPLS.
- ITU-T G.807: Requirements for ASTNs
- draft-ietf-ccamp-gmpls-architecture-07.txt: Generalized Multi-Protocol Label Switching (GMPLS) Architecture
- RFC 3471: Generalized MPLS Signaling Functional Description
An additional, reasonably current source for relevant standards is www.mplsrc.com/standards.shtml.