GMPLS Phase 2 Implementation

The major changes between GMPLS Phase 1 and GMPLS Phase 2 are as follows:

• You must configure one or more control channels between peers when you configure LMP (in addition to the existing statements for LMP peers and TE links). The control channels must travel across a point-to-point link or tunnel. To configure a static control channel, include the control-channel statement at the [edit protocols link-management peer peer-name] hierarchy level. To configure a control channel that uses control channel management and link property correlation, include the lmp-control-channel statement at the [edit protocols link-management peer peer-name] hierarchy level.

  Note: You can configure either the control-channel statement or the lmp-control-channel statement at the [edit protocols link-management peer peer-name] hierarchy level, but not both statements simultaneously.

• OSPF and RSVP have been extended to allow control adjacencies between peers using virtual peer interfaces. The peer interfaces are derived from LMP and can be used for the control adjacency between peers instead of the physical interfaces. To configure for OSPF, include the peer-interface statement at the [edit protocols ospf area area-number] hierarchy level. To configure for RSVP, include the peer-interface statement at the [edit protocols rsvp] hierarchy level. However, when you enable peer interfaces, you must disable RSVP and OSPF on all physical control channel interfaces. Alternately, you can omit the physical control channel interfaces when configuring these protocols.
• The Constrained Shortest Path First (CSPF) algorithm has been extended to permit use with nonpacket LSPs. In GMPLS Phase 2, the no-cspf statement can be omitted from the LSP configuration because it is no longer mandatory. When this statement is omitted, you must configure the signal type attribute for the LSP. For CSPF to work correctly, OSPF extensions for GMPLS need to be implemented on all devices in the GMPLS network.
• LSP paths now can be strict, loose, or dynamic for GMPLS LSPs because TE link information is now exchanged by OSPF. (GMPLS Phase 1 required strict LSP paths.)

The current JUNOS software release supports the following GMPLS functionality:

• Out-of-band signaling controls the setup of LSP paths, enabling a control plane that is separate from the data plane.
• RSVP-TE extensions support additional objects beyond Layer 3 packets, such as ports, timeslots, and wavelengths.
• Link Management Protocol (LMP) creates and maintains a database of TE links, control channels, and peer information. Only the static version of this protocol is supported.
• Bidirectional LSPs are required between nonpacket GMPLS devices.
• Several GMPLS label types are defined in RFC 3471, Generalized MPLS - Signaling Functional Description. The MPLS, Generalized, SONET/SDH, Suggested, and Upstream label types are supported.
• Generalized labels do not contain a type field because the nodes are expected to know from the context of their connection what type of label to expect. For example, an encoding type, such as Ethernet or SONET/SDH, is determined by the resources in a TE link.
• Traffic parameters facilitate GMPLS bandwidth encoding and SONET/SDH formatting.
• Interface Identification/Errored Interface Identification, UNI-style signaling, and Secondary LSP paths are supported.
• Original channelized interfaces (such as channelized OC12 to DS3, channelized OC3 to T1, and channelized STM1 to E1) support GMPLS signaling.
• GMPLS graceful restart for RSVP LSP paths
• RSVP-TE over unnumbered links

The following functionality is not supported in this release:

• Notify messages
• GMPLS routing extensions for IS-IS
• GMPLS link bundling
• Dynamic LMP

For additional information about GMPLS standards, see For More Information.

Note: There is not necessarily a one-to-one correspondence between a physical interface and a GMPLS interface. If a GMPLS connection uses a nonchannelized physical connector, the GMPLS label can use the physical port ID. However, the label for channelized interfaces often is based on a channel or timeslot. Consequently, it is best not to refer to GMPLS labels as “interfaces.” To avoid confusion, refer to them as TE links and refer to the physical interfaces as resources.

GMPLS Operation

GMPLS requires close interaction between LMP, RSVP, and OSPF. The following sequence of events describes how GMPLS works:

1. LMP notifies RSVP and OSPF of the control peer, the control adjacency, and resources for the TE link.
2. GMPLS extracts the LSP attributes from the configuration and requests RSVP to signal one or more specific paths, specified by the TE link addresses.
3. RSVP determines the local TE link, corresponding control adjacency and active control channel, and transmission parameters (such as IP destination). It requests that LMP allocate a resource from the TE link with the specified attributes. If LMP successfully finds a resource matching the attributes, label allocation succeeds. RSVP sends a PathMsg hop-by-hop until it reaches the target router.
4. The target router, on receiving the RSVP PathMsg, requests that LMP allocate a resource based on the signaled parameters. If label allocation succeeds, it sends back a ResvMsg.
5. If the signaling is successful, an optical path is provisioned.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.