Ling-Zhong Liu Internet Draft George R. Young draft-young-opt-nni-prot-issues-00.txt edgeFlow Expires: Nov 2001 April 2001 NNI Path Protection Control Plane Issues 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 Optical path recovery is an important commercial driver behind the development and deployment of switched optical networks. Timely fault notification for optical path protection purposes imposes many requirements on control plane signalling. Many of these requirements can be supported by IETF protocols, although some are in very early phases. For the inter-network scenario, this draft relates network signalling requirements to a particular optical service requirement of interest, outlines how IETF protocols (either existing or at least identified) can be used to support network requirements, and highlights two fault notification requirements where mechanisms do not exist and new protocol work is required. Liu, Young 1 Draft draft-young-opt-nni-prot-issues-00.txt April 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 Background.........................................................2 Span Recovery 2 Path Recovery 2 Light-Path Service Requirement.....................................3 Optical Network Support Requirements...............................3 Path Establishment 3 Control Plane 3 Recovery Time 4 Conclusions........................................................4 References.........................................................5 Author's Addresses.................................................6 Background Carriers have indicated [CARRIER] that rapid recovery of light-paths is desirable for more critical optical services. Various mechanisms have been identified [MECHANISMS] to restore these light-paths and various networks may have different strategies as to which mechanisms to apply. Span Recovery "A span consists of a number of channels between two adjacent nodes". "Span protection involves switching to a protection channel when a failure occurs" [definitions from MECHANISMS]. Path Recovery Under path-level recovery, "the failure is addressed at the end nodes (i.e., the initiating and terminating nodes of the path)". One path recovery strategy is "path protection, where secondary (or protection) paths are pre-allocated" [definitions from MECHANISMS]. Networks may apply path protection as a fall-back when span protection fails, or as an independent strategy in its own right if span protection is either unavailable or inappropriate [HI_MESH]. Path protection offers optical protection with faster performance than "path restoration, where connections are rerouted, either dynamically or using pre-calculated (but not pre-allocated) paths" [definition from MECHANISMS] or layer-3 rerouting, and can approach SONET protection speeds. Segment recovery is a special case of path recovery, in that more than a single span, but not the entire path, is protected. Liu, Young Expires Nov 2001 2 Draft draft-young-opt-nni-prot-issues-00.txt April 2001 Light-Path Service Requirement A customer wants an optical path and path protection, where the path protection must be accomplished in less than MAXRESTORETIME. The path stretches from Node A on Network B to Node Y on Network Z, and there may be other networks (e.g. C, D, and E) between B and Z. Path protection time is an end-to-end requirement which requires cooperative support from all the networks providing the path. Optical Network Support Requirements To support this customer requirement, these networks would require: - mechanisms to set up the primary and protection paths - a control plane to deliver fault notification to the head and tail of the LSP - a mechanism to assure that end-to-end recovery time requirement can be met Path Establishment Work has started [GMPLS] on extending MPLS so that LSPs can be dynamically established in the optical network layer. It is envisaged [OPT_NNI] that multiple networks may be communicating across an NNI to support an LSP. Extensions to OSPF are envisaged [O_OSPF] which reflect current link usage state. Similar extensions for BGP4 which indicate optical reachability without indicating interior topology have been identified in [O_BGP]. Approaches have been defined [CR-LDP,RSVP-GEN] to signal for optical paths. Control Plane The signalling plane should "utilize a robust and efficient signaling mechanism" [per HI_MESH]. To this end, IP provides an inherently self-healing layer-3 control plane. The Link Management Protocol [LMP] has provision for multiple control channels to reduce the probability of total control plane loss. Network design should be such that simultaneous data and control plane failures do not cause the fault notification time to increase beyond customer limits. For path recovery in a mesh network, this may not be a severe requirement as multiple adjacent nodes become aware of a failure 'immediately' and not all signalling paths to the Liu, Young Expires Nov 2001 3 Draft draft-young-opt-nni-prot-issues-00.txt April 2001 head and tail of the LSP will be interrupted by a single network failure. Recovery Time The first component of recovery time is that required to detect the fault, and localize it, if necessary. Fault notification then has to propagate from a healthy node aware of the fault towards the head and the tail of the LSP through nodes across multiple hops in multiple intermediate networks. Each involved network causes some delay in the propagation of this notification, related to packet length, distance, link data rate, node packet handling and node queueing. The delay to effect "path protection" includes the fault notification delay and the time to switch to the alternate path. Example techniques to support such fault notification include Event Notification [RSVP-GEN] RSVP extension and a distinct, reliable protocol [FASTRESTOR]. This total delay should be bounded to support the stated optical customer requirements. This implies that the time to deliver fault notifications through the control plane should also be bounded. To ensure bounded fault recovery times, fault notifications "should be transmitted with high priority" [MPLS_RECOV]. Internet diff-serv techniques have been defined [EF_REV] to ensure the forwarding of traffic across a domain with bounded delay, and Per-Hop Behaviours have been identified [PHB_CODES]. Diff-Serv Expedited Forwarding marking of RSVP notifications can likely satisfy these requirements if coordination between networks on PHBs can be arranged. For a given network using Diff-Serv EF, fault notification delay is a function of path and control plane topology. End-to-end QoS can be supported via extensions to BGP4 [BGP4_QOS]. Even with these supporting protocols, total recovery delay still has to be apportioned to the networks which provide the end-to-end path. Conclusions Much of the work necessary to support path establishment is either available or well under way, but for the NNI case, two new fault notification requirements are identified: 1) For a particular optical path, a network should be able to determine and indicate its fault notification delay capabilities. 2) A mechanism is necessary to apportion fault notification delay across multiple networks involved in supporting an optical path. Liu, Young Expires Nov 2001 4 Draft draft-young-opt-nni-prot-issues-00.txt April 2001 References CARRIER Ishimatsu, Hirokazu et al, "Carrier Needs Regarding Survivability and Maintenance for Switched Optical Networks", (draft-hayata-ipo-carrier-needs-00.txt), November, 2000. MECHANISMS Lang, Jonathan P. et al, "Generalized MPLS Recovery Mechanisms", (draft-lang-ccamp-recovery-00.txt), February 2001. HI_MESH Bhandari, Ramesh et al, "High Level Requirements for Optical Shared Mesh Restoration", (draft-bhandari-optical-restoration- 00.txt), November, 2000. GMPLS Ashwood-Smith, Peter et al, "Generalized MPLS - Signaling Functional Description", (draft-ietf-mpls-generalized-signaling- 02.txt), March 2001. OPT_NNI Papadimitriou, Dimitri et al, "Optical Network-to-Network Interface Framework and Signaling Requirements", (draft- papadimitriou-onni-frame-01.txt), November 2000. O_OSPF Katz, Dave et al, "Traffic Engineering Extensions to OSPF", (draft-katz-yeung-ospf-traffic-04.txt), February 2001. O_BGP Blanchet, Marc et al, "Optical BGP (OBGP): InterAS lightpath provisioning", (draft-parent-obgp-01.txt), March 2001. CR-LDP Ashwood-Smith, Peter et al, "Generalized MPLS Signaling - CR- LDP Extensions", (draft-ietf-mpls-generalized-cr-ldp-01.txt), March 2001. RSVP-GEN Ashwood-Smith, Peter et al, "Generalized MPLS Signaling - RSVP-TE Extensions", (draft-ietf-mpls-generalized-rsvp-te- 01.txt), March 2001. LMP Lang, Jonathan P. et al, "Link Management Protocol (LMP)", (draft-ietf-mpls-lmp-02.txt), expires September 2001. FASTRESTOR Rajagopalan, Bala et al, "Signaling for Fast Restoration in Optical Mesh Networks", (draft-bala-restoration-signaling- 00.txt), expires 8/22/2001. MPLS_RECOV Sharma, Vishal et al, "Framework for MPLS-based Recovery", (draft-ietf-mpls-recovery-frmwrk-02.txt), March 2001. EF_REV Armitage, Grenville et al, "A revised expression of the Expedited Forwarding PHB", (draft-ietf-diffserv-efresolve- 00.txt), November 12th, 2000. Liu, Young Expires Nov 2001 5 Draft draft-young-opt-nni-prot-issues-00.txt April 2001 PHB_CODES Brim, S. et al, "Per Hop Behavior Identification Codes", RFC2836, May 2000. BGP4_QOS C. Jacquenet, "Quality of Service Extensions to the BGP4 Protocol: motivation and framework", (draft-jacquenet-qos-ext- bgp-00.txt), February 2001. Author's Addresses Ling-Zhong Liu Phone: 1-613-270-9279 Ext. 228 Email: ling.liu@edgeflow.com George R. Young Phone: 1-613-270-9279 Ext. 287 Email: george.young@edgeflow.com edgeflow 329 March Road Ottawa, ONT., Canada, K2K 2E1 Liu, Young Expires Nov 2001 6