rfc-5852

RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network

D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai
date2010-04 streamIETF areartg wgccamp statusPROPOSED STANDARD pages23 canonicalhttps://www.rfc-editor.org/rfc/rfc5852 doi10.17487/RFC5852
In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493. This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]

Extracted elements (27)

design-rationale §5

Both full ERO (with labels at each hop) and partial/no ERO methods are supported and are not mutually exclusive. Support of both methods is required to accommodate scenarios where the MP cannot supply full path information to the head-end node.

routing, mpls

design-rationale §5

In the minimum-information Handover path, each transit node looks up the cross-connection table in the DP to determine the next hop's outgoing interface and labels, replacing LABEL_SET and UPSTREAM_LABEL Object content hop by hop. This enables Handover even when the MP cannot supply full LSP details.

routing, mpls

design-rationale §3

MP-to-CP Handover is defined as mandatory while CP-to-MP Handover is considered a nice-to-have feature that can serve as an emergency procedure to disable the CP and take manual control of the LSP.

routing, mpls

design-rationale §4

The modification defined in this document refers only to the ADMIN_STATUS Object — the message flow is left unmodified for both LSP setup and deletion. This minimizes the impact on existing RSVP-TE implementations while enabling Handover functionality.

routing, mpls

interoperability-note §8

Non-supporting nodes will simply propagate the H bit without setting local state. This may result in an impact on data traffic during the Handover procedure, making all-node support an administrative rather than protocol-enforced requirement.

routing, mpls

normative-requirement §4.2.2.1 MUST

A node that receives a PathTear when it has Path state with the H bit set MUST remove Path state but MUST NOT change Data Plane state, and MUST return LSP ownership to the MP.

routing, mpls

normative-requirement §8 MUST

All nodes along the path MUST support the extension defined in this document for the Handover procedure to work correctly. Non-supporting nodes will propagate the H bit without setting local state, potentially impacting data traffic.

routing, mpls

normative-requirement §4.3 MUST

Downstream nodes processing a PathTear message that follows a Path message with the H bit set MUST NOT remove any associated Data Plane state.

routing, mpls

normative-requirement §4.3 MUST

During CP-to-MP Handover, the procedure MUST delete the existing RSVP-TE session information and MUST NOT affect the cross-connected resources, but only move their ownership to the MP. The procedure MUST be a standard LSP deletion per RFC 3473 Section 7.2.1.

routing, mpls

normative-requirement §4.4 MUST

Failures during CP-to-MP Handover MUST NOT result in the removal of any associated Data Plane state. While the H bit is set in Path state, a node MUST NOT send a PathTear when a failure is detected; instead the failure is reported upstream using a PathErr.

routing, mpls

normative-requirement §4 SHOULD

For bidirectional LSPs where the ERO contains full information including labels, the ERO SHOULD include both upstream and downstream labels.

routing, mpls

normative-requirement §4.2.1.1 MUST

If an error occurs during Path message processing, the detecting node MUST respond with a PathErr message and MUST abort the Handover procedure. Associated DP resources MUST NOT be impacted.

routing, mpls

normative-requirement §4.1 MUST

If matching Data Plane state is found during MP-to-CP Handover, the LSR MUST save the Path state (including the set H bit), MUST forward the Path message to the egress, and MUST retain any MP state associated with the LSP.

routing, mpls

normative-requirement §4.1 MUST

If matching Path state is found with the H bit clear when a Path message with H bit set arrives, this is an error and MUST be treated according to the error case in Section 4.2.1.1.

routing, mpls

normative-requirement §4.2 MUST

In any failure case during MP-to-CP Handover, the LSP ownership MUST be immediately rolled back to the one previous to the Handover procedure.

routing, mpls

normative-requirement §4.1 MUST

The ingress MUST check that no corresponding Path state exists and that corresponding Data Plane state does exist before initiating MP-to-CP Handover. If there is an error, it MUST be reported to the operator and further protocol action MUST NOT be taken.

routing, mpls

normative-requirement §4.1 MUST

The ingress MUST start the Expiration timer when signaling the LSP with the H bit set. The timer SHOULD be configurable per LSP with a default value of 30 seconds.

routing, mpls

normative-requirement §4.1 MUST

The MP-to-CP Handover procedure MUST create an RSVP-TE session along the path of the LSP to be moved, associating it with existing cross-connected resources owned by the MP and transferring their ownership to the CP without affecting Data Plane traffic.

routing, mpls

normative-requirement §4.1 MUST

When the ingress LSR receives a Resv with the H bit set and the timer is running, it MUST cancel the timer and MUST send a Path message with the H bit clear to complete the second stage of Handover.

routing, mpls

protocol-element §7.2

A new Error Code 35 ('Handover Procedure Failure') is defined for the ERROR_SPEC Object with two Error Value sub-codes: 1 = Cross-connection mismatch, 2 = Other failure. This is used in PathErr messages to signal Handover failures.

routing, mpls

protocol-element §7.1

A new H (Handover) bit is defined in the ADMIN_STATUS Object at bit number 25 (hex value 0x00000040). When set in a Path message, it signals that the message is part of a Handover procedure and that no Data Plane operations should result from normal CP signaling.

routing, mpls

registry §10

IANA allocated bit 25 (hex 0x00000040) in the ADMIN_STATUS Object bit allocations registry for the Handover (H) bit, as defined in this document.

registry, routing, mpls

registry §10

IANA allocated Error Code 35 ('Handover failure') in the RSVP Error Codes registry with globally defined Error Value sub-codes: 1 = Cross-connection mismatch, 2 = Other failure.

registry, routing, mpls

security-consideration §9

The Handover procedures allow the Control Plane to take an LSP out of Management Plane control, which could cause considerable disruption and introduce a new security concern. The use of GMPLS security techniques is therefore more important; implementors should refer to RFC 3473 for RSVP-TE security and the GMPLS security framework.

security, routing, mpls

state-machine §4.3

CP-to-MP Handover state machine: Ingress sends Path with H and R bits set; all nodes store H bit in Path and Resv state; after Resv with H bit received at ingress, it sends PathTear; nodes processing PathTear with H bit set do NOT remove DP state, only CP state.

routing, mpls

state-machine §4.1

MP-to-CP Handover two-stage state machine: (1) Ingress sends Path with H bit set and starts Expiration timer; LSRs save Path state with H bit; egress sends Resv with H bit set. (2) On receipt of Resv with H bit, ingress cancels timer and sends Path with H bit clear; LSRs release MP state on receipt of H-clear Path; completion confirmed when ingress receives Resv with H bit clear.

routing, mpls

state-machine §4.2.2.3

Node Graceful Restart during MP-to-CP Handover has three cases: (I) finite restart time — ingress aborts via PathTear, LSR B tears down LSP after restart timer expires but MUST NOT release DP resources; (II) infinite restart time — recovery timer expires at LSR B triggering PathTear/PathErr, no DP resources released; (III) ingress re-generates Path with H bit to restart Handover after node recovery.

routing, mpls