GMPLS UNI
Prerequisites for Implementing GMPLS UNI
-
An NCS 5500 Series router PID with CFP2 Digital Coherent Optics (DCO) form factor transceiver support.
-
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
-
Router that runs Cisco IOS XR software.
-
Installation of the Cisco IOS XR software mini-image on the router.
-
Installation of the Cisco IOS XR MPLS software package on the router.
-
Working knowledge of GMPLS. Refer the Information About Implementing GMPLS UNI section for details.
Restrictions for Implementing GMPLS UNI
-
The total number of configured GMPLS UNI controllers should not exceed the platform scale limit of 500 GMPLS interfaces.
-
Each UNI-N (ingress or egress) should be routable from its adjacent UNI-C. The UNI-C nodes need to be routable from the UNI-N nodes too.
-
GMPLS UNI is supported only over DWDM controllers and so, over POS and GigabitEthernet interfaces.
Information About Implementing GMPLS UNI
GMPLS UNI and GMPLS NNI
The GMPLS NNI optical network topology is known, and path calculations are performed at the NNI head. The GMPLS UNI optical network topology is unknown to the UNI-C nodes, and path calculations are performed by the UNI-N nodes.
GMPLS UNI Use Case
The UNI components are UNI-N and UNI-C. The tunnel originates on the headend UNI, depicted in the left part of the image. The tunnel terminates on the tailend UNI, depicted in the right part of the image. Enable the following configurations on the headend UNI and tailend UNI:
-
Control plane - IP control channel between the UNI-C and UNI-N router IDs. This creates LMP adjacency over the control channel.
-
Forwarding plane - TE Link between UNI-C and UNI-N optical interfaces.
-
Tunnel configuration from Head UNI-C to a Tail UNI-C optical interface, over the optical network.
For each tunnel, you must enable corresponding tunnel and TE link configurations.
Link Management Protocol (LMP) – LMP manages the control channel across the UNIs, verifies TE link connectivity between the UNI interfaces, and performs fault management.
Dynamic LMP – You can enable the Dynamic LMP function which validates LMP configuration consistency across the headend and tailend UNIs. Consistency check examples:
-
You have configured one end of a TE link as an unnumbered interface, and the other end with an IP address.
-
You have entered the wrong neighbor interface ID when configuring an unnumbered neighbor interface.
Ensure that you enable the preceding configurations correctly.
GMPLS LSP Signaling
The GMPLS overlay model architecture is used for LSP signaling for GMPLS connections. In GMPLS UNI, UNI-C nodes send a request for a connection to UNI-N node. The connection request does not contain an end-to-end path. This is because, as mentioned previously, UNI-C nodes do not have knowledge of the topology of the optical network and therefore cannot determine the end-to-end path. The UNI-C node signals a connection request without an ERO.
The LSP diversity is signaled on a GMPLS UNI tunnel with a path-option. A path-option is permitted on a GMPLS UNI tunnel with a "no ERO" and an optional "XRO" attribute sets to specify LSP diversity requirements. If multiple LSP exclusions are configured in the attribute-set, they can be added to the path message along with an appropriate LSP connection diversity sub-object.
Supported LSP encoding types, and corresponding switching types:
Switching Type |
LSP Encoding Type |
---|---|
LSC |
Lambda |
FSC |
EthernetType1, EthernetType2, Fiber |
DCSC |
EthernetType2 |
A packet network is switched across a fiber, optic, or data channel network. Enable the LSP encoding and switching types under the GMPLS UNI and LMP configuration modes. Also, enable the Generalized PID (G-PID) under the GMPLS UNI configuration mode. G-PID is an identifier of the type of payload that the LSP carries, and the LSP endpoints (the UNI-C devices) use.
The LSP encoding type, switching type, and G-PID are updated to the GMPLS label.
Path Message without an ERO
In GMPLS UNI, UNI-C nodes send a request for a connection to UNI-N node. The connection request does not contain an end-to-end path, because, UNI-C nodes do not have knowledge of the topology of the optical network and therefore cannot determine the end-to-end path. The UNI-C node signals a connection request without an ERO.
When no ERO is present in a received path message, the UNI-N node calculates a route to the destination and includes that route in an ERO, before forwarding the path message. If no route is found, the UNI-N returns a path error message with an error code and subcode of 24,5 - "No route available toward destination".
The destination address of a GMPLS LSP can be either the optical router-id of the tail UNI-C node, or the optical address of the ingress interface to the tail UNI-C node. Supplying the router-id allows the UNI-N to route the tunnel to the tail UNI-C node via any attached UNI-N node; supplying the UNI-C's ingress interface address forces the tunnel's path to traverse the UNI-N node attached to that interface.
Note |
The optical router-ids and interface addresses may or may not be the same as the packet ones. |
XRO Attribute-set
An optional XRO attribute-set can be specified as part of the path-option to specify LSP diversity requirements. An empty XRO attribute set results in the GMPLS tunnel being signaled with no exclusions, and therefore no XRO.
Note |
A non-existent XRO attribute-set can be configured in the GMPLS UNI tunnel path-option; in this case no attempt will be made to bring up the GMPLS tunnel until the configuration is complete. |
Connection Diversity
Connection diversity is required to ensure that GMPLS tunnels can be established without sharing resources, thus, greatly reducing the probability of simultaneous connection failures. For example, an edge-node wishes to establish multiple LSPs towards the same destination edge-node, and these LSPs need to have few or no resources in common.
Connection diversity supports the establishment of a GMPLS LSP which is diverse from the path taken by an existing LSP. An XRO is added to the tunnel's path message with appropriate LSP diversity sub-objects or exclusions. A maximum of 20 connection diversity exclusions per XRO is supported.
GMPLS RSVP VRF Signaling
The Cisco IOS XR software supports a single non-default VRF for the GMPLS RSVP signaling. This allows GMPLS signaling to work even when the only available communication between the UNI-C and UNI-N nodes is through a VRF. This non-default VRF is supported only for GMPLS signaling; whereas the MPLS-TE signaling continues to support only the default VRF.
DWDM Transponder Integration
A GMPLS UNI based solution preserves all the advantages of the integration of the DWDM transponder into the router blade. These advantages include the following:
-
Improved CAPEX and OPEX models.
-
Component, space and power savings.
-
Improved IP availability through pro-active protection.
nLight Enhancements
These topics describe the enhancements made to nLight (also known as GMPLS UNI):
Explicit Route Object
Explicit Route Objects (EROs) limit LSP routing to a specified list of LSRs. Formerly, the UNI Client (UNI-C) node signaled a connection request, without an ERO, to the UNI Network (UNI-N) node. In this IOS XR Software release, the UNI-C node provides support for path message with ERO for GMPLS tunnels. This includes the capability to specify either a strict or a loose ERO to a path option to be included in the path message for processing by the ingress UNI-N.
An ERO in constructed using the strict and loose hops, specified in the explicit path, by the path option.
When a loose hop is configured, it identifies one or more transit LSRs which suggests the preferred path for the LSP. If a suggested path fails, another LSR is tried.
When a strict hop is configured, it identifies an exact path through which the LSP must be routed. Strict hop EROs specify the exact sequence of LSRs in the LSP.
As a result of these operations, a LSP is established from the sender to the destination of the session, following the explicitly routed path specified in the ERO.
Note |
|
Wavelength Specification
The wavelength (also called label) specification enhancement enables the network planning tool to determine the wavelength, and specify the same at the UNI-C. The UNI-N then accepts the label provided by the UNI-C, or rejects the path entirely. Previously, the wavelength to be used for the GMPLS UNI tunnel was determined by the UNI-N, taking into account the headend UNI-C's capabilities.
The wavelength to be used is added to the path option configuration. This optional configuration allows a fixed wavelength to be specified for the path option.
When signaling using a path option with the specified wavelength takes place, the following changes happen because of the wavelength specification enhancement:
-
The configured wavelength is validated against the controller’s capabilities; signaling fails if the wavelength cannot be used by the controller.
-
The upstream label is set to the specified wavelength.
-
The label-set in the Path message, instead of containing one label for each supported wavelength, contains only the specified wavelength.
-
A path-error message with error code 25 and subcode 6 no longer receives special handling. If a suggested label is supplied, it is ignored.
Note |
A suggested label received in response to signaling with a path option that specifies a different label, is not stored for future use. Other path options, in general, have different constraints and therefore require path calculation to be redone. |
Multiple Path Options
Multiple path options are permitted per GMPLS UNI tunnel. The index given to each path option indicates its relative preference level, with lower indices being preferred. This is similar to the existing multiple path option functionality available for packet TE. This allows the provision of multiple path options with, for example, progressively free constraints.
The path-option index is no longer fixed to ten and is now set by the user and distinguishes path options in the same manner as for packet tunnels. In all situations where a tunnel is being brought up or reoptimized, the path-option with the lowest index is tried first; if no LSP can be established with this path option, then subsequent path options are tried in ascending order. This also applies to recovery from failures, unless any recovery path option is specified.
Reoptimization
Reoptimization differs from restoration though the mechanisms involved are similar. Reoptimization occurs without the original connection having failed.
Unlike packet tunnels, reoptimization in GMPLS tunnels is not supposed to be loss free.
Manual Reoptimization
Manual reoptimization of a single GMPLS UNI tunnel can be triggered from the UNI-C node (headend). Use the mpls traffic-eng optical-uni reoptimize tunnel-id command to trigger manual reoptimization of a GMPLS UNI tunnel.
The manual trigger for reoptimization causes the currently established LSP to be torn down and signals a new LSP using the normal bring-up process (though the new LSP is same as the current one).
It is not possible to trigger reoptimization for multiple GMPLS UNI tunnels or at the tailend of a tunnel.
SRLG Discovery
Note |
Shared Risk Link Group (SRLG) discovery, SRLG collection and SRLG recording represent the same function. |
The head and tail UNI-C routers have no direct knowledge of the path taken through the optical network by a GMPLS UNI tunnel, or of the properties of that path. All information about the path of a particular GMPLS UNI connection must therefore be explicitly requested and learned during the signaling process.
A key property of a GMPLS UNI connection is the set of SRLGs used by the optical links along the connection. It is necessary for the UNI-C routers to learn the set of SRLGs associated with a connection, so that this information can be used, both by GMPLS UNI in the specification of diversity requirements for other connections and by Layer-3 applications for effecting routing and protection decision making.
The learning of SRLGs during GMPLS UNI LSP signaling is done by requesting SRLG collection when LSP signaling is initiated, and by the addition of SRLG RRO sub-objects to the Path and Resv messages during signaling as described in IETF draft SRLG-collect. Path message learns egress interfaces from head to tail and Resv message learns egress interfaces from tail to head.
Provision of Discovered SRLGs to RSI
Once the SRLGs used by a GMPLS UNI connection are collected during signaling as in SRLG discovery, they are made available to the Layer-3 processes. This is done through RSI (Router Space Infrastructure), as illustrated in the following diagram:
An API is provided by the RSI component to allow SRLGs discovered during GMPLS UNI signaling to be communicated to RSI, as documented in IETF draft RSI-SRLG. RSI combines the SRLG sets learned from GMPLS and configuration for an interface and deliver a single set of SRLGs to applications registered as SRLG clients.
The SRLGs discovered during GMPLS UNI signaling are given to RSI for application to the Layer-3 interface of the DWDM controller associated with the GMPLS UNI tunnel. This may be a POS, GigE or an OTN interface.
SRLG Announce
All SRLGs discovered through GMPLS signaling are announced to RSI once the tunnel is up. These SRLGs are withdrawn from RSI when the tunnel goes down.
SRLG Diversity
Note |
SRLG diversity and SRLG exclusion represent the same function. |
Support is added for signaling SRLG based diversity requirements, based on the XRO SRLG sub-object defined in RFC 4874. The use of SRLGs removes the restrictions of LSP based diversity, as SRLGs are flooded throughout the optical network, and by their very nature, reduce the risk of concurrent failure.
SRLG diversity is configured under the XRO attribute-set.
Head UNI-C Behavior
SRLG diversity is configured at the tunnel head. Individual SRLG exclusions are added to an XRO attribute-set; each is specified as either best-effort or mandatory (strict). Whenever any exclusion is specified, an XRO object is added to the Path message by the head UNI-C. The XRO contains a SRLG sub-object for each specified SRLG. The SRLG exclusions may coexist in the same XRO with LSP exclusions.
The XRO attribute-set is associated with tunnel path options in the same manner as for LSP exclusions.
If a SRLG with a strict exclusion matches an SRLG configured on the local DWDM controller, the bring-up attempt fails.
The SRLG exclusions requested by the head UNI-C are processed by the ingress UNI-N node during path calculation for the tunnel.
Tail UNI-C Behavior
On receiving a Path message containing an XRO, the tail UNI-C inspects each SRLG sub-object. If a SRLG sub-object, with a strict exclusion, matches an SRLG configured on the local DWDM controller, the Path message is rejected and a path-error is generated with error codes. No action is taken if the SRLG sub-object specifies a best-effort exclusion.Multi-Layer Restoration - Optical
Multi-Layer Restoration-Optical (MLR-O) involves restoration from failures in the optical network that can leverage the same router interfaces at both ends.
Optical restoration involves the repair of a failure by the optical network locally. Although the routers may see loss of light until the failure is repaired, there is no signaling involving the routers, and from the routers perspective the GMPLS UNI LSP remains unchanged.
Optical Restoration: Same Wavelength
When a failure occurs on a physical link within the optical network, the routers identify that the link is down and Layer 3 protection mechanisms, such as FRR, are used to minimize the traffic loss. The optical network re-routes the GMPLS connection to an alternative path. This is done without any involvement of the routers.
Limitation - A significant limitation of optical restoration in this case, is that the wavelength in use for the connection cannot be changed. This is because the wavelength must be the same along the entire path and cannot be changed without end-to-end signaling. The constraints imposed on the connection during its initial signaling are also unchanged, which may reduce the chance of finding an alternative path.
Optical Restoration: Wavelength Change
Optical restoration may occur with an associated wavelength change, in the case where the optical network finds an alternative path with the same constraints as were originally signaled, but using a different wavelength. Some signaling is required, since the wavelength (and therefore the labels) used by the GMPLS connection are to change.
Consider a failure within the optical network on the path of a GMPLS UNI LSP. The restoration proceeds as in the previous case (same wavelength), but the new path found, uses a different wavelength. The ingress UNI-N then sends a path-error message indicating the new wavelength to be used; this has error code 24 (routing), sub-error 6 (unacceptable label set) and contains a suggested-label sub-object with the new label to be used. The head UNI-C then signals a new LSP with the new wavelength.
Although the wavelength in use may change in this case, the constraints used in signaling the original LSP remain unchanged.