Shoichiro Seno (Mitsubishi Electric Corp.) Yoshiaki Konishi (Mitsubishi Electric Corp.) Internet Draft Expiration Date: April 2003 October 2002 Path Quality Verification over an All-Optical Network draft-seno-path-quality-verification-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft proposes a framework for path quality verification over an all-optical network. Because it will be difficult to ensure quality of a dynamically established path over an all-optical network, it may be useful for network providers to have means to verify quality of a path before it is served to the subscribers. This draft proposes a framework for such means, including requirements behind them and a path continuity check mechanism to verify optical-level path quality upon a path's establishment by the GMPLS signaling. S. Seno [Page 1] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 1. Summary for Sub-IP Area 1.1. Summary See the Abstract above. 1.2. Related Documents None. 1.3. Where Does it Fit in the Picture of the Sub-IP Work This work fits in the CCAMP WG and/or TE WG. 1.4. Why Is It Targeted at This WG This draft is targeted at the CCAMP WG because a protocol to realize path quality verification is closely related to the signaling and measurement protocols being defined by the WG. This draft is targeted at the TE WG because path quality verification may be regarded as part of traffic engineering functions considered by the WG. 1.5. Justification of Work The WG(s) should consider this document as it addresses a new path quality verification framework in accordance with the GMPLS protocols. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Introduction A major advantage of an all-optical network primarily consisting of optical cross connects (OXCs) is transparency of transmission signals over the network. However, it also implies difficulty regarding link monitoring when client signals are not being transmitted over the link. To support various types of data planes by a common control plane, including the all-optical transport plane, GMPLS introduced clear separation between the control channel and the data channel over a link. Because of this separation, normal state of the control channel may not necessarily mean that of the data channel, as was the case with a SONET/SDH network. When provisioning a transparent optical path with quality assurance, a network provider must have means to verify quality of a path before its service to the subscribers through the control plane or the management plane. S. Seno [Page 2] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 In an optical network, a transparent optical path may be relayed through passive elements such as an optical switch. Because verifi- cation of all elements contributing a path's quality is difficult before it is actually cross-connected, such a path's quality must be verified after the signaling and cross-connecting are over. SONET/SDH supports path quality verification by means of transmission of trace signal, defined in OH, and a test pattern. This document describes a mechanism to verify an optical path's continuity when it is being established. Previous and on-going efforts to standardize GMPLS signaling [GMPLS- SIG], such as RSVP-TE [GMPLS-RSVP], have been focusing on provisioning (path establishment). LMP [LMP], also a part of the GMPLS efforts, provides a procedure to isolate a failure's location when it happens on a working path over an all-optical network, based upon propagation of LOS(Loss of Signal) over the path. However, there are no mutually agreed-upon procedures in GMPLS to verify quality of a path when it is newly established. Therefore, it is desirable to define a GMPLS- based procedure to support path quality verification mechanisms. A mechanism to verify quality of a newly established path MUST satisfy the following requirements. - Verification SHOULD be fast and reliable enough to verify quality of an alternate path when it is entered into service by the recovery mechanism upon detection of a failure over the working path. An alternate path may be pre-established by a "path protection mechanis" or newly established by a "path restoration mechanism". - Verification SHOULD be performed in a distributed manner in accordance with the GMPLS signaling procedure, which has been designed to realize a distributed control plane. Addition of verification to the GMPLS signaling procedure SHOULD not make signaling time intolerantly long. In the following, a mechanism to realize path quality verification in optical region, here called "path continuity check", is described in some details including basic procedures in a protocol-independent manner. It is the intention of this document that the above require- ments and the following mechanism will serve as a framework to promote definition of mutually agreed-upon path quality verification procedures in the collective efforts of GMPLS standardization. S. Seno [Page 3] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 4. A Path Continuity Check Mechanism In this chapter, a mechanism called "path continuity check" is described as an example of path quality verification in a protocol- independent manner. For ease of description, the GMPLS signaling procedure of RSVP-TE [GMPLS-RSVP] is assumed. "Path continuity check" assumes simple and clear separation between the data plane and control plane, similar to the networking model behind LMP link connectivity verification. The following considerations were also taken into account. - Path continuity SHOULD be verified according to a path's granularity, such as a lambda or fiber, which will be served. - Path continuity check mechanism SHOULD also support check of a protection path not being used, and an out-of-service path, maybe in an analogous way to STM/ATM's OAM procedures. - Path continuity check mechanism SHOULD be applicable to various data monitoring schemes employed by OXCs and PXCs, though such details are outside the scope of this document. - A path's continuity SHOULD be verified by means of a method negotiated by related nodes if more than one methods are available. Path continuity mechanism SHOULD support negotiation of the path verification method in the Control Plane. The following figures shows a basic sequence of path continuity check for a uni-directional path newly established by the RSVP-TE signaling. Path continuity check for a bi-directional path may employ the same procedure concurrently in different directions. (1) End-to-end Path Continuity Check - Path continuity check is performed after a path is established between the ingress node to the egress node. - Continuity check signal is generated by the ingress node and cross- connected to the path. The egress node will check the path's continuity by trying to detect it upon receiving the Continuity Check message. - The egress node will notify the ingress node of a failure of the path's continuity check if continuity check signal is not properly detected. - Upon notified a path continuity check failure, the ingress node will tear down the logically established path, and may try to re- establish an alternate path or give up path establishment. - Intermediate OXCs are not required to have functions to generate nor detect continuity check signal. - Isolation of the failed link is not supported by this procedure. S. Seno [Page 4] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 +----+ +----+ +----+ +----+ |OXC1+-------------+OXC2+------------+OXC3+------------+OXC4| +----+ +----+ +----+ +----+ A| | | | ^ |--------PM------>| | | | Path B| A| | | | Estab- | |--------PM------>| | | lish- | B| A| | | ment | | |--------PM------>| | | | B| A| | | | |<-------RM-------| | | | A| B| | | |<-------RM-------| | | | A| | | | |<-------RM-------| | | | A| | | | v X|========CS=======|========>Y | | ^ |--------CM------>| | | |Path | |--------CM------>| | |Conti- | | |--------CM------>| |nuity | | | Z| |Check | | |<-------FN-------| | | |<-------FN-------| | | |<-------FN-------| | | | W| | | | v OXCs: OXC1: Ingress node OXC2, OXC3: Intermediate nodes OXC4: Egress node Messages: PM: RSVP Path Message RM: RSVP Reserve Message CM: Continuity Check Message FN: Continuity Check Failure Notification Data Plane Signal: CS: Continuity Check Signal Event: A: GMPLS message processing B: Optical switch cross-connecting X: Insertion of Continuity Check Signal Y: Loss of signal Z: Failure detection W: Triggering of a recovery procedure Figure 1 End-to-end Path Continuity Check Example Sequence S. Seno [Page 5] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 (2) Link-by-link Path Continuity Check - Path continuity check is performed link-by-link with propagation of the GMPLS path establishment messages. - Continuity check signal is generated by the ingress or an intermediate node and cross-connected to the path. The next-hop node on the path will check continuity by trying to detect it upon receiving the Continuity Check message. - Upon finding of a failure by path continuity check, the GMPLS path establishment procedure will terminate with an error indication. Then the ingress node may try to re-establish an alternate path or give up path establishment. - Isolation of the failed link can be supported by this procedure. +----+ +----+ +----+ +----+ |OXC1+-------------+OXC2+------------+OXC3+------------+OXC4| +----+ +----+ +----+ +----+ A| | | | |--------PM------>| | | B| A| | | X|========CS======>| | | |--------CM------>| | | | V| | | | |--------PM------>| | | B| A| | | X|========CS==>Y | | | |--------CM------>| | | | Z| | | |<-------FN-------| | | |<-------PE-------| | |<-------PE-------| | | OXCs: OXC1: Ingress node OXC2, OXC3: Intermediate nodes OXC4: Egress node Messages: PM: RSVP Path Message PE: RSVP PathError Message CM: Continuity Check Message FN: Continuity Check Failure Notification Data Plane Signal: CS: Continuity Check Signal Event: A: GMPLS message processing B: Optical switch cross-connecting V: Success of continuity check X: Insertion of Continuity Check Signal Y: Loss of signal Z: Failure detection Figure 2 Link-by-link Path Continuity Check Example Sequence S. Seno [Page 6] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 (3) Notes and Considerations - Path continuity check signal can be electrically received and verified, e.g., SONET/SDH overhead or an LMP Test message. - Please note that path continuity signal should be kept within the provider network and not to be transmitted to the subscriber link when it is used to verify quality of a newly established path before its service. This means that the ingress node and egress node have to cross-connect the subscriber links with the path after completion of path continuity check. - While LMP link connectivity verification provides means to verify quality of links between nodes, it does not cover path quality verification because switching elements included in a path is outside its scope. - Specific protocols to realize path quality verification, such as the message formats for the path continuity check mechanism, are for further study and beyond the scope of this document. - Although path quality verification proposed in this document is for an all-optical network, near-term use of an all-optical path may be limited by difficulty of transporting and switching signals in optical region. Thus a path may be composed of a series of transparent segments coupled by electrical or optical 3R functions. In that case, path quality verification in optical region can be applied to each transparent segment individually. - Path quality verification of an optical path covering multiple administrative domains may require further considerations, because verification means must be coordinated between the domains. 5. Security Considerations This document raises no new security concerns. References [LMP] Lang, et al. "Link Management Protocol", Internet Draft, Work in progress, draft-ietf-mpls-lmp-06.txt, September 2002. [GMPLS-RSVP] Berger, L. et al., "Generalized MPLS Signaling RSVP-TE Extensions", Internet Draft, Work in progress, draft-ietf-mpls- generalized-rsvp-te-09.txt, September 2002. [GMPLS-SIG] Berger, L. et al., "Generalized MPLS Signaling Functional Description", Internet Draft, Work in progress, draft-ietf-mpls- generalized-signaling-09.txt, August 2002. S. Seno [Page 7] Internet Draft draft-seno-path-quality-verification-00.txt October 2002 Author Information Shoichiro Seno Mitsubishi Electric Corporation 5-1-1 Ofuna, Kamakura Kanagawa, Japan 247-8501 Email: senos@isl.melco.co.jp Yoshiaki Konishi Mitsubishi Electric Corporation 5-1-1 Ofuna, Kamakura Kanagawa, Japan 247-8501 Email: ykonishi@isl.melco.co.jp S. Seno Expires April 2003 [Page 8]