CCAMP Working Group Zafar Ali Roberto Cassata Internet Draft Cisco Systems, Inc. Intended status: Standards Track Marco Anisetti Valerio Bellandi Ernesto Damiani Francesco Diana Umberto Raimondi University of Milan T. Otani KDDI R&D Laboratories, Inc. Expires: January 04, 2009 July 05, 2008 draft-ali-ccamp-rsvp-te-based-evidence-collection-00.txt An RSVP-TE based Evidence Collection Mechanism Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on January 04, 2009. Z. Ali, et al. Expires Jan. 04, 2009 [Page 1] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The problem of quality analysis and advanced fault detection of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical evidence related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical evidence measured over optical nodes along the light-path. 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. Table of Contents 1. Introduction...............................................3 2. Evidence Collection........................................3 2.1. Optical Path Quality Evaluation.......................3 2.2. Optical Evidence Classification and LSP Locking.......4 2.3. Optical Evidence Collection...........................6 2.4. Evidence Collection Request TLV.......................7 2.5. Evidence recording TLV................................7 2.6. Signaling Procedure for evidence collection using RSVP- TE........................................................10 2.6.1. Non-blocking evidence collection................10 2.6.2. Blocking evidence collection with all nodes ready for evidence collection................................11 2.6.3. Blocking evidence collection with some node(s) blocked for evidence collection........................12 3. Security Considerations...................................13 4. IANA Considerations.......................................13 5. Acknowledgments...........................................13 6. References................................................13 6.1. Normative References.................................13 6.2. Informative References...............................14 Author's Addresses...........................................14 Intellectual Property Statement..............................15 Disclaimer of Validity.......................................15 Z. Ali, et al Expires January 5, 2009 [Page 2] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 1. Introduction For successful fault detection on a light-path, we need mechanisms that can collect all physical evidences (consisting of optical measurements such as signal power, OSNR, etc.) that affect the light-path. In this document we propose an RSVP-TE based mechanism for collection of evidences along a light-path. The proposed technique is also suitable for optical networks that suffer of physical dysfunction due the non-ideal optical transmission medium and/or to critical situations (e.g., a fiber cut). In this scenario even if every node along the path is connected, the reachability of the end node with an acceptable signal quality is not guaranteed. The term evidence refers to real optical measurements or estimates computed using a prediction model. The former may require mutually exclusive access to hardware to avoid interference, in which case the evidence is called blocking evidence. In the later case the evidence is classified as non- blocking. This draft addresses evidence collection for both blocking and non-blocking evidences. 2. Evidence Collection For successful fault detection on an optical path, the fault isolation mechanism needs to be aware of all physical evidence (consisting of optical measurements such as signal power, OSNR, Optical Channel Monitor, etc.) that affect the light-path. Consequently this draft proposes control plane based mechanism for evidence collection. How evidences are collected (from data plane) is beyond the scope of this document. 2.1. Optical Path Quality Evaluation The quality of an optical path is assessed by collecting the physical evidences along an LSP and evaluating them (e.g. for faulty point detection). In this draft we make use of the LSP_ATTRIBUTES to perform the evidence collection hop by hop along the optical path. It is important to note that collection of blocking evidences require a mutually exclusive access to the resource. Therefore the entire LSP needs to be "locked" until the collection for the blocking evidences is completed. This implies that if another evidence collection process tries to retrieve evidences on the same node-resource already under "Administrative Evidences Locking" status, needs to be aborted. The draft uses Z. Ali, et al Expires January 5, 2009 [Page 3] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 the RSVP Admin status object to realize "LSP Administrative Evidences locking" to make sure that all nodes are ready to collect the blocking evidence. In the following we first define Optical Evidence classification, and the extensions to LSP ATTRIBUTE and RSVP Admin status objects needed to perform the aforementioned functionalities. Section 2.7 details the signaling mechanism with examples to illustrate how proposed extensions are used for evidence collection. 2.2. Optical Evidence Classification and LSP Locking Physical evidences (consisting of optical measurements such as signal power, OSNR, Optical Channel Monitor, etc.) that have effect on the light-path are classified as: o Blocking evidence. In general blocking evidence is a physical measurement that may require a mutually exclusive access to hardware resources while performing the measurement. o Non blocking evidence. A physical value that can be probed in parallel at different nodes. Consequently, every optical node can be in three states w.r.t. to a certain reserved resource: unlock, lock-requested or lock. In fact blocking evidence requires the resource to be in lock state. In general this is due to the hardware limitation of optical nodes. In case of blocking evidence the LSP status needs to be set to "Locked". For this purpose, we extend the Admin object [RFC3471], [RFC3473] with B bit (Blocked request bit) and C bit (block Confirm bit). Specifically, Administrative status object is extended with the following two bits for locking purpose. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Length | Class-Num(196)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ |R| Reserved C|B|T|A|D| Z. Ali, et al Expires January 5, 2009 [Page 4] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Reflect (R): 1 bit When set, indicates that the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages. Reserved: 25 bits. This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes. Testing (T): 1 bit. When set, indicates that the local actions related to the "testing" mode should be taken. Administratively down (A): 1 bit. When set, indicates that the local actions related to the "administratively down" state should be taken. Deletion in progress (D): 1 bit. When set, indicates that that the local actions related to LSP teardown should be taken. Edge nodes may use this flag to control connection teardown. Blocking node (B): 1 bit. When set, indicates that locking procedure is ongoing. Confirm blocking (C): 1 bit. When set, indicates that the locking procedure is successfully ongoing. During LSP locking for collection of blocking evidence, the R bit (Reflect bit) MUST be set. Furthermore, if the node along the path understands B and C bits, the node MUST return the Admin object in the Resv Message for locking confirmation or unlocking. Since we need to block an entire LSP, any node unable to measure the required blocking evidence MUST set a lock failure (unset the C bit in the Path Admin Object). The general locking procedure is defined as follows: o Every transit node that receives the Admin status object in the Path message with B, C and R bit set needs to check if the actual status is unlock. o In the case of unlock status, the node switches to lock- required state related to the required blocking evidence. Z. Ali, et al Expires January 5, 2009 [Page 5] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 o In the case of lock or lock-required states, the node forwards the Admin object message without the C bit set. This implies a lock failure. o The Resv message performs the locking for the entire LSP in case of C and B bit set and unlocking in case of unset C bit. o Every transit node that receives the Resv message with B and C bit set changes its status to lock. This strategy prevents race conditions. 2.3. Optical Evidence Collection Path quality evaluation is based on holistic analysis of the evidence collected along the path of an LSP. To signal which evidence needs to be collected we extend the LSP Attribute TLV sub-object. The evidence collection is performed as follows: o Source node sends a Path message with LSP Attribute object aimed to inform the transit nodes about the imminent evidence collection. The Path message also contains TLV sub-objects with required evidence. o Every transit node, when receives the message with LSP Attribute object, assembles the collected evidence (specified in TLV) inside a sub-TLV. The way an optical node gets knowledge of the evidence using information locally available at the node (e.g. via discovery of internal amplifiers, photodiode etc.) is out of the scope of this document. o Evidence collection will be executed by the returning Resv message that collects hop-by-hop evidence objects by inserting the sub-TLV inside the attached TLV. After successful forwarding of the Resv message the status of transit nodes MUST be switched to unlock for preventing deadlock. In case of blocking evidence the LSP lock MUST be obtained before evidence collection. In case of non-blocking evidence the unavailability of certain evidence in an intermediate node MUST NOT cause the request of failure. The holistic evidence evaluation SHOULD be able to deal with missing non-blocking evidence. Z. Ali, et al Expires January 5, 2009 [Page 6] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 When a transit node not in locked state receives a request for blocking evidence, an evidence collection failure (PathErr) SHOULD be sent to the Ingress node. 2.4. Evidence Collection Request TLV The proposed encoding scheme for optical evidence measurements defines a TLV associated to a particular evidence type. A TLV sub-object is encoded in an LSP_REQUIRED_ATTRIBUTES Object [RFC4420]. The TLV sub-object encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | E-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Type: Collected evidence type (TBA). This can be blocking or non blocking type. Length: length of the TLV object in bytes without the 4 byte header. E-type (Evidence Type, 8 bits): Evidence identifier encoded as per [WD6-23]. E.g., 0 for Signal power, 1 for OSNR, 2 for Pilot Tone (as blocking evidence). This TLV defines which types of evidence (signal power, OSNR, Pilot Tone, alarm etc.) need to be collected and is carried by the Path message. 2.5. Evidence recording TLV A set of evidence is collected through the Resv message to allow the optical quality evaluation at the ingress node. Each item of optical evidence is collected separately. Every transit node, in the Path message, finds the Evidence Collection Requested TLV and replies the Evidence value in Resv using Z. Ali, et al Expires January 5, 2009 [Page 7] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 evidence recording TLV (encoded in an LSP_ATTRIBUTES Object). The evidence value can be measured or estimated. Furthermore it sets the Measure Method inside this TLV according to the kind of measured media (single lambda measurement or aggregate measurement). This evidence collection improves the feasibility evaluation where network elements support at least a subset of evidence. The following TLV encodes the evidence values of the LSP associated to the evidence type defined in the Evidence Collection Request TLV. Z. Ali, et al Expires January 5, 2009 [Page 8] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | WavelengthID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | | // IPv4/IPv6 Address/unnumbered // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Evidence Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Type: Evidence type(TBA). Length: length of the TLV value in bytes. WavelengthID: encoded as per [WD6-23]. This field identifies the wavelength. If it is measured/estimated aggregate evidence, this field is set to 0. IPv4/IPv6 Address: The address of the Node that measures the evidence. Evidence Value: Estimated or measured evidence value according to [WD6-23]. E.g., the Signal Optical Power as 32-bit IEEE 754 floating point number. Z. Ali, et al Expires January 5, 2009 [Page 9] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 2.6. Signaling Procedure for evidence collection using RSVP-TE In this section we describe signaling procedures for tracerouting with evidence collection using examples. Consider a GMPLS LSP that has OXC1 as Ingress Node, OXC4 as Egress node with OXC2 and OXC3 in transit, as shown below. +------+ +------+ +------+ +------+ | | ----- | | ===== | | ----- | | | OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 | | | ----- | | ----- | | ===== | | +------+ +------+ +------+ +------+ In the following we consider three scenarios of evidence collection and describe signaling procedures associated with the evidence collection and how above mentioned extensions to LSP Attribute and admin status objects are used for this purpose. 2.6.1. Non-blocking evidence collection The quality evaluation of an optical path is done after LSP is signaled. In case of non-blocking evidences, evidence collection follows the following procedure: o OXC1 node sends a Path message with Evidence Collection Request TLV aimed to inform the transit nodes about the imminent evidence collection and about the type of evidence that needs to be collected (e.g., Signal power). o Every transit node (OXC2,OXC3), when receives the Path message with Evidence Collection Request TLV, starts the internal evidence reading procedure and waits for the correspondent Resv message to forward the related Evidence recording TLV in the upstreaming flow to the ingress node OXC1. If for some reason the evidence is not available, since it is non blocking evidence, the node simply does not include the evidence measure in its own Evidence recording TLV. The holistic analysis can be performed also with a subset of the non blocking evidences. o Egress node OXC4 sends Resv message with Evidence Collection Request TLV containing optical evidence TLV upstream to the Z. Ali, et al Expires January 5, 2009 [Page 10] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 ingress node OXC1 and puts its own evidence value in this Evidence recording TLV. o Every transit node (OXC3,OXC2) inserts its own Evidences recording TLV inside Resv message in such way that ingress node collects all required evidences hop by hop. o OXC1 node when receives the Resv message extract the Evidences recording TLV to perform holistic path quality analysis. The transit nodes that do not support LSP_REQUIRED ATTRIBUTE object or do not support evidence request TLV will be addressed in a later version of the document. Summarizing the Evidence collection will be executed by the returning Resv message that collects hop-by-hop evidence objects upstream. 2.6.2. Blocking evidence collection with all nodes ready for evidence collection In this scenario the locking strategy needs to be performed first to ensure that no node in the LSP is already locked in another blocking evidences collection. I.e., we need to be sure that all nodes along the path are ready to collect the evidence. This phase uses Admin status object in the Path and Resv message, as follows: o OXC1 switches to "lock-required" state and sends a Path message with Admin status object with B, C and R bit set. B bit is used to signal locking is required. C bit is used for locking confirmation. Recall it needs to be set if lock is granted, and needs to be unset otherwise. o Every transit node (OXC2, OXC3) that receives the Admin status object in the Path message with B, C and R bit set switches to "lock-required" state related to the required blocking evidence. o Egress node OXC4 switches to lock state and forwards the Admin status object in the Resv message, resetting the R bit. o Every transit node (OXC3,OXC2) that receives the Resv message with B and C bit set changes its state to "locked". Z. Ali, et al Expires January 5, 2009 [Page 11] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 o Ingress node OXC1 when receives the Resv message with Admin status object with B and C bit set switches to "locked" state. At the end of this procedure the entire LSP is in "locked" state and is ready for blocking evidence collection. At this stage the Evidence collection can be performed as described earlier. The locking is performed before evidence collection to maintain a better compatibility with the future available blocking evidences kind that would require further action to be taken before starting the collection. 2.6.3. Blocking evidence collection with some node(s) blocked for evidence collection. In this scenario the locking procedure fails since some node (OXC3 in this example) is in "locked" or "lock-required" state over another LSP. o OXC1 switches to lock-required state and sends a Path message with Admin status object with B, C and R bit set. B bit is used to signal locking is required. C bit is used for locking confirmation. Recall it needs to be set if lock is granted, and needs to be unset otherwise. o OXC2 receives the Admin status object in the Path message with B, C and R bit set and switches to "lock-required" state related to the required blocking evidence. o OXC3 node receives the Admin status object and, since it is already in lock or lock-required state for another LSP with the same resources, unsets the C bit. Therefore the locking procedure will fail. o Egress node OXC4, since the received Admin object does not have the C bit set, switches to unlock state and forwards the received Admin status object in the Resv message resetting the R bit. o When the other transit nodes (OXC3, OXC2) receive the Admin object in the Resv message with B bit set but with C bit unset, they switch to unlock state. Z. Ali, et al Expires January 5, 2009 [Page 12] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 o When the ingress node OXC1 receives the Resv message with Admin object containing B bit set and C bit unset switches to unlock. At this stage the Locking mechanism fails since the ingress node has not received the confirmation of successful locking (C bit set). 3. Security Considerations Security considerations and requirements from [RFC4379] apply equally to this document. Furthermore, there are some additional security considerations that may be induced by the extended RSVP-TE model proposed by this draft. These security considerations will be added in a later version of the draft. 4. IANA Considerations TBA 5. Acknowledgments Authors would like to thank Alberto Tanzi, Ferdinando Malgrati, Domenico La Fauci, Enzo Luca Passerini, Gabriele Galimberti for their valuable inputs. 6. References 6.1. Normative References [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. Z. Ali, et al Expires January 5, 2009 [Page 13] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 6.2. Informative References [RFC4379] Kompella, K., Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", February 2006 [WD6-23] Cassata, R., Damiani, E., Optical Parameters Classification and Encoding. ITU-T contribution. Author's Addresses Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada. Email: zali@cisco.com Marco Anisetti University of Milan, Department of Information Technology Via Bramante 65, 26013 Crema (CR) Italy Email: anisetti@dti.unimi.it Valerio Bellandi University of Milan, Department of Information Technology Via Bramante 65, 26013 Crema (CR) Italy Email: bellandi@dti.unimi.it Roberto Cassata Cisco Systems, Inc. Via Philips 2, 20052 Monza (MI) Italy Email: rcassata@cisco.com Ernesto Damiani University of Milan, Department of Information Technology Via Bramante 65, 26013 Crema (CR) Italy Email: damiani@dti.unimi.it Francesco Diana Z. Ali, et al Expires January 5, 2009 [Page 14] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 University of Milan, Department of Information Technology Via Bramante 65, 26013 Crema (CR) Italy Email: diana@dti.unimi.it Umberto Raimondi University of Milan, Department of Information Technology Via Bramante 65, 26013 Crema (CR) Italy Email: uraimondi@crema.unimi.it Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502. Japan Email: otani@kddilabs.jp Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION Z. Ali, et al Expires January 5, 2009 [Page 15] draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Z. Ali, et al Expires January 5, 2009 [Page 16]