[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuring GMPLS

To implement GMPLS, you must configure traffic link management protocol traffic engineering links and protocol peers and OSPF and RSVP peer interfaces, establish GMPLS LSP path information, define GMPLS paths, discover local identifiers and configure remote identifiers. This section contains these configuration procedures plus some optional configuration procedures:

Configuring Link Management Protocol Traffic Engineering Links

To begin your GMPLS configuration, enable LMP to define the data channel interconnection between devices at the [edit protocols link-management] hierarchy level.

To configure data channels in LMP, include the te-link te-link-name statement at the [edit protocols link-management] hierarchy level. Define all TE link options shown. (You will configure remote-id statements at the te-link and interface levels later.) We recommend that you use a different IP address and mask on your TE link addresses from the ones configured on your physical interfaces. This way, you can identify which addresses are physical and which ones belong to the TE link.

[edit]
protocols {
link-management {
te-link te-link-name { # Collection of physical ports or timeslots.
local-address ip-address; # Local IP address associated with the TE link.
remote-address ip-address; # Remote IP address mapped to the TE link.
interface interface-name { # Interface used for data transfer.
local-address ip-address; # Local IP address for the TE link.
remote-address ip-address; # Remote IP address for the TE link.
}
}
}
}

Configuring Link Management Protocol Peers

After you set up TE links, configure LMP network peers with the peer statement at the [edit protocols link-management] hierarchy level. A peer is the network device that your router communicates with when setting up the control and data channels. Often, the peer is an OXC. Designate a peer name, configure the peer’s router ID as the address (often a loopback address), specify the interface that will be used as a control channel, and apply the TE link to be associated with this peer.

You can configure one or more control channels for a peer. The control channels must have point-to-point connectivity with the peer (for example, you can use a point-to-point link or a tunnel). You can also configure the generic routing encapsulation (GRE) tunnel interface of the Routing Engine as a control channel. 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, see Option: Configuring an LMP Control Channel. Without a control channel, the configuration will fail to commit.

[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
control-channel interface; # Specify the interface for the control channel.
te-link te-link-name; # Assign a TE link to this peer.
}
}
}

Note: Although you can configure the gre- tunnel interface on a Routing Engine as a control channel, this interface is not supported, nor is it configurable for other applications.

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.

Configuring Peer Interfaces in OSPF and RSVP

After you establish LMP peers, add peer interfaces to OSPF and RSVP. A peer interface is a virtual interface used to support a control adjacency between two peers. OSPF and RSVP form adjacencies between peers by using the peer interfaces instead of the physical interfaces.

Because actual protocol packets are sent and received by peer interfaces, the peer interfaces can be signaled and advertised to peers like any other interface enabled for RSVP and OSPF. The peer interface name must match the peer name configured in LMP. To configure RSVP signaling for LMP peers, include the peer-interface statement at the [edit protocols rsvp] hierarchy level. To configure OSPF routing for LMP peers, include the peer-interface statement at the [edit protocols ospf area area-number] hierarchy level.

[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number {
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}

Note: When adding the virtual peer interfaces to RSVP and OSPF, do not configure the corresponding physical control channel interface in either protocol. If the interface all option is used, you must disable the protocols manually on the control channel interface.

  • To disable OSPF, use the disable statement at the [edit protocols ospf area area-number interface interface-name] hierarchy level.
  • To disable RSVP, use the disable statement at the [edit protocols rsvp interface interface-name] hierarchy level.

Establishing GMPLS LSP Path Information

When you configure LSP paths for GMPLS, you must use the TE link remote address as your next-hop address. When CSPF is supported, you can use any path option you wish. However, when CSPF is disabled with the no-cspf statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level, you must use strict paths.

[edit]
protocols {
mpls {
path path-name {
next-hop-address (strict | loose);
}
}
}

Defining GMPLS Label-Switched Paths

Next, define LSP attributes at the [edit protocols mpls label-switched-path] hierarchy level. To enable the proper GMPLS switching parameters, configure the attributes appropriate for your network connection. The default values, which are also appropriate for standard MPLS, are ipv4 for gpid, none for signal-bandwidth, and psc-1 for switching-type.

Note: In JUNOS Release 5.6 or later, the signal-bandwidth statement replaces the signal-type statement. Also, virtual tributary (VT) 1.5 and 2.0 SONET/SDH bandwidth options are available at the [edit protocols mpls label-switched-path lsp-name lsp-attributes signal-bandwidth] hierarchy level.

[edit]
protocols {
mpls {
label-switched-path lsp-name {
from ip-address;
to ip-address;
primary path-name;
secondary path-name;
no-cspf; # This statement to disable CSPF is optional.
lsp-attributes { # Attributes determine the selection of an LSP.
gpid type;  # Payload type, such as Ethernet or PPP.
signal-bandwidth type; # Bandwidth encoding, such as DS3 or STM1.
switching-type type; # Switching method, such as psc-1 or lambda.
}
}
}
}

Note: Because MPLS and GMPLS use the same configuration hierarchy for LSPs, it is helpful to know which LSP attributes control LSP functionality. Standard MPLS packet-switched LSPs are unidirectional, while GMPLS nonpacket LSPs are bidirectional.

If you use the default packet switching type of psc-1, your LSP becomes unidirectional. To enable a GMPLS bidirectional LSP, you must select a nonpacket switching type option, such as lambda, fiber, or ethernet, at the [edit mpls label-switched-path lsp-name lsp-attributes] hierarchy level.

Discovering Local Identifiers and Configuring Remote Identifiers

Once LMP is enabled on a router, the router automatically assigns two local IDs: one at the te-link level, the other at the interface level. You must configure these port-to-label mappings manually for LMP on both the router and its peer. To configure, set the local IDs of one device (such as the router) as remote IDs on the peer device (such as an OXC) with the remote-id statement at the [edit protocols link-management te-link te-link-name] and [edit protocols link-management te-link te-link-name interface interface-name] hierarchy levels.

You can view the TE link and interface local IDs by using the show link-management te-link command. Once you have learned these IDs, configure them as remote-id statements at the corresponding te-link and interface levels on the peer.

Because peers vary, check with your OXC vendor for the configuration statements and location of the local ID information for your specific optical peer device. If you do not manage the peer device, ask the peer’s administrator to enable LMP and generate the IDs for you. GMPLS will not work unless these local IDs from both the router and the peer are configured as remote IDs on the opposite device.

To disable an entire TE link for administrative purposes, include the disable statement at the [edit protocols link-management te-link te-link-name] hierarchy level. To disable an interface within a TE link, include the disable statement at the [edit protocols link-management te-link te-link-name interface interface-name] hierarchy level.

[edit]
protocols {
link-management {
te-link te-link-name {
disable; # Disable the entire TE link.
remote-id id-number; # TE link ID number of the peer device.
interface interface-name { # Name of the interface used for data transfer.
disable; # Disable an interface in the TE link.
remote-id id-number; # ID number of the remote device.
}
}
}
}

Figure 20: TE Link and Interface ID Example

Image g017149.gif

Figure 20 shows where the IDs come from and where you must assign them. This example highlights the connections between Router A and OXC1, but the same configuration concepts apply to all pairs of peers.

First, you configure a TE link named TE1 on Router A, which contains the local address 10.1.1.1, remote address 10.1.1.2, data channel interface so-0/0/0, and control channel interfaces so-0/0/2 and so-0/0/3. You also configure a TE link named TE2 on OXC1, which contains the local address 10.1.1.2, remote address 10.1.1.1, data channel interface so-0/0/1, and control channel interfaces so-0/0/2 and so-0/0/3. When the TE links are enabled on Router A and OXC1, these two peer devices each generate two local IDs: one for the TE link itself and one for the logical interface.

If Router A has a local ID of 12345 for its TE link and a local ID of 23456 for its interface, you must configure 12345 as the TE link remote-ID and 23456 as the interface remote-ID on the TE2 TE link of OXC1. Similarly, if OXC1 has local IDs of 98765 for its TE link and 54321 for its interface, you configure Router A’s TE1 TE link with 98765 as the TE link remote-ID and 54321 as the interface remote-ID.

To complete the full data path, you need to enable LMP on each link in the path. This means you must configure remote-ID and local-ID pairs between linked devices.

Option: Tearing Down GMPLS LSPs Gracefully

You can tear down a nonpacket GMPLS LSP in a two-step process that gracefully withdraws the RSVP session used by the LSP. For all neighbors that support graceful teardown, a request for the teardown is sent by the routing platform to the destination endpoint for the LSP and all RSVP neighbors in the path. The request is included within the ADMIN_STATUS field of the RSVP packet. When neighbors receive the request, they prepare for the RSVP session to be withdrawn. A second message is sent by the routing platform to complete the teardown of the RSVP session. If a neighbor does not support graceful teardown, the request is handled as a standard session teardown rather than a graceful one.

To perform a graceful teardown of a GMPLS LSP RSVP session, issue the clear rsvp session gracefully command. Optionally, you can specify the source and destination address of the RSVP session, the LSP identifier of the RSVP sender, and the tunnel identifier of the RSVP session. To use these qualifiers, include the connection-source, connection-destination, lsp-id, and tunnel-id options when you issue the clear rsvp session gracefully command.

You can also configure the amount of time that the routing platform waits for neighbors to receive the graceful teardown request before initiating the actual teardown. To configure, include the graceful-deletion-timeout statement at the [edit protocols rsvp] hierarchy level. The default graceful deletion timeout value is 30 seconds, with a minimum value of 1 second and a maximum value of 300 seconds. To view the current value configured for graceful deletion timeout, issue the show rsvp version operational command.

Option: Allowing Nonpacket GMPLS LSPs to Establish a Path Through JUNOS-Based Routers

When you configure a nonpacket LSP as administratively down, an external device (not a JUNOS software-based router) can either perform a Layer 1 path setup test or help bring up an optical cross-connect through a JUNOS software-based router.

To configure a nonpacket LSP as administratively down, you must set the A-bit in the ADMIN_STATUS field of a RSVP packet. This feature does not affect control path setup or data forwarding for packet LSPs.

To configure the ADMIN_STATUS field for a GMPLS LSP RSVP packet, issue the admin-down statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level or the [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name] hierarchy level.

Option: Selecting the Peer Model or the Overlay Model for GMPLS

Juniper Networks supports both the peer model and the overlay model for GMPLS. To implement the peer model, perform the following configuration tasks:

To implement the overlay model, perform the following configuration tasks:

Option: GMPLS Graceful Restart

GMPLS supports graceful restart, a mechanism that allows a restarting router to continue forwarding packets to neighbors without interruption. The restarting router relies on its forwarding table temporarily while it receives updates from “helper” neighbors that assist the restarting router in rebuilding its routing table.

To enable graceful restart for all routing protocols including GMPLS, include the graceful-restart statement at the [edit routing-options] hierarchy level. To disable graceful restart for GMPLS and RSVP, include the disable statement at the [edit protocols rsvp graceful-restart] hierarchy level. To disable GMPLS and RSVP graceful restart helper capability, include the helper-disable statement at the [edit protocols rsvp graceful-restart] hierarchy level.

To configure the maximum amount of time the routing platform retains information for restarting neighbors, include the maximum-helper-recovery-time statement at the [edit protocols rsvp graceful-restart] hierarchy level. The default helper recovery time is 180 seconds, with a minimum value of 1 second and a maximum value of 3600 seconds. To view the current value configured for the helper recovery time, issue the show rsvp version operational mode command.

To configure the maximum amount of time the routing platform waits until a neighbor is declared dead, include the maximum-helper-restart-time statement at the [edit protocols rsvp graceful-restart] hierarchy level. The default helper restart time is 20 seconds, with a minimum value of 1 second and a maximum value of 1800 seconds. To view the current value configured for the helper restart time, issue the show rsvp version operational command.

[edit]
protocols {
rsvp {
graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time seconds;
maximum-helper-restart-time seconds;
}
}
}

For more information about graceful restart, see the JUNOS High Availability Configuration Guide.

Option: Configuring an LMP Control Channel

In contrast with statically configured control channels that provide basic connectivity, LMP control channels provide control channel management and link property correlation as defined in RFC 4204, Link Management Protocol (LMP). To manage the state of the control channel, LMP uses the following sequence of events:

  1. The LMP peer with the highest router ID sends configuration messages to peers.
  2. When a peer sends an acknowledgement of a Config message back to the originator, the control channel enters the active state.
  3. When a peer sends LMP hello messages and receives them from a neighbor, the control channel transitions to the up state.
  4. Once the control channel is up, link summary messages and acknowledgements are sent between LMP peers to share TE link information.

To configure an LMP control channel, include the lmp-control-channel statement at the [edit protocols link-management peer peer-name] hierarchy level and specify the physical IP address of the peer as the remote address. You can also specify a hello interval, a hello dead interval, a retransmission interval, and a retry limit. Default values for these statements are shown in Table 17.

Table 17: Default Values for LMP Protocol Fields

LMP Protocol Field

Value

Hello interval

150 milliseconds

Hello dead interval

500 milliseconds

Retransmission interval

500 milliseconds

Retry limit

3 retries

If you plan to use these default values, you do not need to configure them. However, if you choose to manually configure any of these values, you must include all four statements (hello-interval, hello-dead-interval, retransmission-interval, and retry-limit) at the [edit protocols link-management peer peer-name lmp-protocol] hierarchy level. Also, the hello dead interval must be at least three times larger than the hello interval.

If you do not want the routing platform to initiate LMP negotiations, include the passive statement at the [edit protocols link-management peer peer-name lmp-protocol] hierarchy level. To log hello packets, other LMP messages, and state transitions of the control channels and TE links, include the hello-packets, packets, and state traceoptions flags at the [edit protocols link-management traceoptions] hierarchy level.

[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
lmp-control-channel interface { # Specify the control channel interface.
remote-address ip-address; # Configure the peer’s physical IP address.
}
lmp-protocol { # Manually configure LMP protocol values.
hello-dead-interval milliseconds;
hello-interval milliseconds;
passive; # Respond to LMP peers, but do not initiate LMP negotiations.
retransmission-interval milliseconds;
retry-limit number;
}
te-link te-link-name; # Assign a TE link to this peer.
}
traceoptions {
flag (hello-packets | packets | state);
}
}
}

For a full example of an LMP protocol control channel configuration, see Example: LMP Control Channel Configuration.

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.

Option: Configuring GMPLS Support for Unnumbered Links

The JUNOS software supports RSVP traffic engineering over unnumbered interfaces. With this feature, you do not have to configure IP addresses for each interface participating in the RSVP-signaled network. Traffic engineering information about unnumbered links is carried in the IGP traffic engineering extensions for OSPF and IS-IS, as described in RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). Unnumbered links can also be specified in the MPLS traffic engineering signaling, as described in RFC 3477, Signaling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE).

To configure RSVP for unnumbered interfaces, you must configure the router with a router ID using the router-id statement specified at the [edit routing-options] hierarchy level. The router ID must be routable (you can typically use the loopback address). The RSVP control messages for the unnumbered links are sent using the router ID address (rather than a randomly selected address). To configure link protection and fast reroute on a router with unnumbered interfaces enabled, you must configure at least two addresses. In addition to the router ID, Juniper Networks recommends that you configure a secondary interface on the loopback:

[edit]
routing-options {
router-id address;
}
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]