Internet Draft George R. Young draft-young-optical-prot-ext-rsvp-00.txt Meriton Networks Expires: Nov 2002 Apr 2002 Optical Path Protection Signalling Performance Extension to RSVP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract With this extension to the RSVP-TE protocol, an optical path can be initiated with a requested maximum path restoration notification time, and signalling nodes which make up the path can determine compliance with this requirement and then establish the path. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 Summary for Sub-IP related Internet Drafts.........................2 Background.........................................................2 Path Request Service Scenario......................................2 Signalling Scenario Description....................................3 Signalling Protocol Extension......................................4 Signalling Protocol Handling.......................................5 References.........................................................5 Author's Address...................................................5 Young 1 Draft draft-young-optical-prot-ext-rsvp-00.txt Apr 2002 Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: This protocol enhancement would be an addition to the RSVP-TE enhancements already defined in draft-ietf-mpls-generalized-rsvp-te- 06.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the CCAMP WG. WHY IS IT TARGETED AT THIS WG(s) CCAMP is defining protocol extensions for GMPLS to support optical switching. JUSTIFICATION This draft specifically addresses two CCAMP WG work items: - Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O- O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc. - Abstract link and path properties needed for link and path protection. Define signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling and measurement protocols, either separately or in combination. Background An optical path is requested and established using RSVP [RFC 2205] and its generalized MPLS TE extensions [RSVP_GEN]. For path restoration [GMPLS_ARCH], a failure is indicated to the head and the tail of the path via the RSVP NOTIFY message. These nodes switch traffic onto an already established backup path. Path Request Service Scenario The node initiating the path request indicates that failure notification from any failure site should propagate to the head and the tail of the path within a specified time limit. Young Expires Nov 2002 2 Draft draft-young-optical-prot-ext-rsvp-00.txt Apr 2002 Signalling Scenario Description It is assumed that for a network where restoration performance is important, mechanisms are in place [RFC 2598] to assure that signalling delays are bounded and deterministic. Upstream and downstream directions are relative to path establishment. A signalling node (SN) controls one or more switching elements (SE). Path establishment signalling is between SNs, while the path is established by connections through the SEs. If the SN and SE(s) are separate, some unspecified communication mechanism is used. A +-----+ B -------------| SN |---------- Control Plane Signalling +-----+ / | \ / | \ C / | \ +----+ +-----+ +----+ ----| SE |---| SE |---| SE |---- User Plane Connection +----+ +-----+ +----+ The time required to indicate failure from the switching element through the signalling node in the upstream direction (C->A) is called UPSTREAM_FAIL_DELAY, and in the downstream direction (C->B) DOWNSTREAM_FAIL_DELAY. In the case of multiple switching elements controlled by a single signalling node, it is the worst case value. The time to forward a failure notification through the signalling node in the upstream direction (B->A) is called UPSTREAM_TRANSIT_DELAY, and DOWNSTREAM_TRANSIT_DELAY in the downstream direction (A->B). Each signalling node must have knowledge of the delays associated with failure notification and notification forwarding, in the upstream and downstream directions. The initiating node indicates the NOTIFICATION_LIMIT in the PATH message, and its values for UPSTREAM_FAIL_DELAY, UPSTREAM_TRANSIT_DELAY, DOWNSTREAM_FAIL_DELAY and DOWNSTREAM_TRANSIT_DELAY. A signalling node which does not support the performance request clears the path request. Each signalling node in the path appends its values of UPSTREAM_FAIL_DELAY, UPSTREAM_TRANSIT_DELAY, DOWNSTREAM_FAIL_DELAY and DOWNSTREAM_TRANSIT_DELAY to the PATH message. The destination node checks that the failure notification time from any fail site to the head or the tail is below the specified limit, otherwise clearing the path request. Young Expires Nov 2002 3 Draft draft-young-optical-prot-ext-rsvp-00.txt Apr 2002 Signalling Protocol Extension The initiating node adds the ProtectionNotification object to the PATH message: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | PROT_NOTIF | C-Type | +-------------+-------------+-------------+-------------+ | NOTIFICATION_LIMIT | +-------------+-------------+-------------+-------------+ | UPSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | UPSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ The PROT_NOTIF Class-Num has the two high order bits zero. Limit and delay values are in seconds, floating point. Only the initiating node provides NOTIFICATION_LIMIT. Downstream nodes append their delay values to the ProtectionNotification object and modify its Length: +-------------+-------------+-------------+-------------+ | Length (bytes) | PROT_NOTIF | C-Type | +-------------+-------------+-------------+-------------+ | NOTIFICATION_LIMIT | +-------------+-------------+-------------+-------------+ | UPSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | UPSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ // // // (Intermediate node delay values) // // // +-------------+-------------+-------------+-------------+ | UPSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | UPSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_FAIL_DELAY | +-------------+-------------+-------------+-------------+ | DOWNSTREAM_TRANSIT_DELAY | +-------------+-------------+-------------+-------------+ Young Expires Nov 2002 4 Draft draft-young-optical-prot-ext-rsvp-00.txt Apr 2002 Signalling Protocol Handling Any node which does not recognize the ProtectionNotification object MUST reject the path request with the "Unknown Object Class" error. The path has control nodes 1 to n. The final signalling node (node n) performs calculations on the ProtectionNotification object data. For each node i in the path, where 0 < i < n: DownStreamDelay[i] = DOWNSTREAM_FAIL_DELAY[i] + sum of DOWNSTREAM_TRANSIT_DELAY[j] for i < j < n. For each node i in the path, where 1 < i < n+1: UpStreamDelay[i] = UPSTREAM_FAIL_DELAY [i] + sum of UPSTREAM_TRANSIT_DELAY [j] for 1 < j < i. If any of DownStreamDelay[i] or UpStreamDelay[i] values are greater than NOTIFICATION_LIMIT, the path request MUST be rejected with the "Traffic Control Error". Otherwise, path establishment continues. References RFC 2205 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", R. Braden, Ed., September 1997. RSVP_GEN "Generalized MPLS Signaling - RSVP-TE Extensions", draft- ietf-mpls-generalized-rsvp-te-06.txt, Peter Ashwood-Smith et al, November 2001. GMPLS_ARCH "Generalized Multi-Protocol Label Switching (GMPLS) Architecture ", draft-ietf-ccamp-gmpls-architecture-02.txt, Eric Mannie - Ed., March 2002. RFC 2598 "An Expedited Forwarding PHB", V. Jacobson et al, June 1999. Author's Address George R. Young Phone: +1-613-270-9279 Ext. 287 Email: george.young@meriton.com Meriton Networks Inc. 3026 Solandt Road Ottawa, ONT., Canada, K2K 2A5 Young Expires Nov 2002 5