CCAMP Working Group Internet Draft Zafar Ali Roberto Cassata Cisco Systems, Inc. Marco Anisetti Valerio Bellandi Ernesto Damiani Francesco Diana Umberto Raimondi University of Milan T. Otani KDDI R&D Laboratories, Inc. Category: Standard Track Expires: May 02, 2009 November 03, 2008 draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt RSVP-TE based impairments 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 May 02, 2009. Z. Ali, et al. Expires May 24, 2009 [Page 1] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The problem of path validation of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical impairments related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical impairments 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. Impairments Collection........................................3 2.1. Optical Path Quality Evaluation..........................3 2.2. Optical Impairments Classification and LSP Locking.......4 2.3. Optical Impairments Collection...........................6 2.4. Impairments Collection Request TLV.......................7 2.5. Impairments recording TLV................................8 2.6. Signaling Procedure for impairments collection using RSVP-TE.......................................................9 2.6.1. Non-blocking impairments collection................10 2.6.2. Blocking impairments collection with all nodes ready for impairments collection..........................11 2.6.3. Blocking impairments collection with some node(s) blocked for impairments collection................12 3. Security Considerations......................................12 4. IANA Considerations..........................................13 5. Acknowledgments..............................................13 6. References...................................................13 6.1. Normative References....................................13 6.2. Informative References..................................13 Author's Addresses..............................................14 Intellectual Property Statement.................................15 Disclaimer of Validity..........................................15 Z. Ali, et al Expires May 3, 2009 [Page 2] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 1. Introduction For enhanced path status validation, we need mechanisms that can collect all physical impairments (consisting of optical measurements such as signal power, OSNR, etc.) that affect the light-path. The description of impairments type and effects [G.680] is out of the scope of this draft, we follow the description provided in [Bernstein-framework][Martinelli-frame]. In this document we propose an RSVP-TE based mechanism for collection of impairments 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. In [RFC4054], an overview of some critical optical impairment and their routing related issues can be found. The term impairments refer 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 impairments required a blocking collection type. In the later case the impairments are collected with a non-blocking collection type. This draft addresses impairments collection for both blocking and non- blocking type leaving the definition of the collection type to as a section attribute. 2. Impairments Collection The line path validation mechanism needs to be aware of all physical impairments (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 impairments collection. How impairments are collected (from data plane) is beyond the scope of this document. 2.1. Optical Path Validation Our approach is in full agreement with information model [Bernstein-info] for path validation and in particular we refer to [Bernstein-framework] for architectural options in which impairment validation for an optical path is defined. The validation of an optical path is assessed by collecting the physical impairments along an LSP and evaluating them. In this Z. Ali, et al Expires May 3, 2009 [Page 3] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 draft we make use of the LSP_ATTRIBUTES to perform the impairments collection hop by hop along the optical path. It is important to note that collection of impairments in a blocking way requires a mutually exclusive access to the resource. Therefore the entire LSP needs to be "locked" until the collection for the impairments is completed. This implies that if another impairments collection process tries to retrieve impairments on the same node-resource already under "Administrative Impairments Locking" status, needs to be aborted. The draft uses the RSVP Admin status object to realize "LSP Administrative Impairments locking" to make sure that all nodes are ready to collect the impairments in a blocking way. Our RSVP based impairments collection protocol made the optical path validation described in [Berstain info] available. More in details the G.680 gives techniques and formulas for use in calculating the impact of a cascade of network elements. These formulations is at the base of our path validation. In the following we first define Optical Impairments collection 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 impairments collection. 2.2. Optical Impairments collection Classification and LSP Locking Physical impairments that have effect on the light-path can be collected in two ways: o Blocking impairments collection. In general in the case of blocking collection, the impairment collection may require a mutually exclusive access to hardware resources while performing the measurement. o Non blocking impairments collection. A collection of 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 collection of impairment requires the resource Z. Ali, et al Expires May 3, 2009 [Page 4] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 to be in lock state. In general this is due to the hardware limitation of optical nodes. In case of blocking collection of impairments 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ 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. Z. Ali, et al Expires May 3, 2009 [Page 5] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 During LSP locking for collection of impairments, 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 impairments 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 impairments. 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 Impairments Collection Path validation is based on holistic analysis of the impairments collected along the path of an LSP. To signal which impairments needs to be collected we extend the LSP Attribute TLV sub-object. The impairments 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 impairments collection. The Path message also contains TLV sub- objects with required impairments. o Every transit node, when receives the message with LSP Attribute object, assembles the collected impairments (specified in TLV) inside a sub-TLV. The way an optical node gets knowledge of the impairments using information locally Z. Ali, et al Expires May 3, 2009 [Page 6] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 available at the node (e.g. via discovery of internal amplifiers, photodiode etc.) is out of the scope of this document. o Impairments collection will be executed by the returning Resv message that collects hop-by-hop impairments 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 collection of impairments the LSP lock MUST be obtained before impairments collection. In case of non-blocking collection type, the unavailability of certain impairments in an intermediate node MUST NOT cause the request of failure. The holistic impairments evaluation SHOULD be able to deal with missing impairments. When a transit node not in locked state receives a request for blocking collection type, an impairments collection failure (PathErr) SHOULD be sent to the Ingress node. 2.4. Impairments Collection Request TLV The proposed encoding scheme for optical impairments measurements defines a TLV associated to a particular impairments 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 impairments type (TBA). This can be blocking or non blocking type. Z. Ali, et al Expires May 3, 2009 [Page 7] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 Length: length of the TLV object in bytes without the 4 byte header. E-type (Impairments Type, 8 bits): Impairments identifier encoded as per [WD6-23]. E.g., 0 for Signal power, 1 for OSNR, 2 for Pilot Tone (as blocking impairments). This TLV defines which types of impairments (signal power, OSNR, Pilot Tone, alarm etc.) need to be collected and is carried by the Path message. 2.5. Impairments recording TLV A set of impairments is collected through the Resv message to allow the evaluation at the ingress node. Each item of optical impairments is collected separately. Every transit node, in the Path message, finds the impairments Collection Requested TLV and replies the impairments value in Resv using impairments recording TLV (encoded in an LSP_ATTRIBUTES Object). The impairments 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 impairments collection improves the feasibility evaluation where network elements support at least a subset of impairments. The following TLV encodes the impairments values of the LSP associated to the impairments type defined in the impairments Collection Request TLV. Z. Ali, et al Expires May 3, 2009 [Page 8] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Impairments Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Type: Impairments 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 impairments, this field is set to 0. IPv4/IPv6 Address: The address of the Node that measures the impairments. Impairments Value: Estimated or measured impairments value according to [WD6-23]. E.g., the Signal Optical Power as 32-bit IEEE 754 floating point number. 2.6. Signaling Procedure for impairments collection using RSVP-TE In this section we describe signaling procedures for path validation with impairments collection using examples. Consider Z. Ali, et al Expires May 3, 2009 [Page 9] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 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 impairments collection and describe signaling procedures associated with the impairments collection and how above mentioned extensions to LSP Attribute and admin status objects are used for this purpose. 2.6.1. Non-blocking collection of impairments The validation of an optical path is done after LSP is signaled. In case of non-blocking collection, the impairments collection follows the following procedure: o OXC1 node sends a Path message with Impairments Collection Request TLV aimed to inform the transit nodes about the imminent impairments collection and about the type of impairments that needs to be collected (e.g., Signal power). o Every transit node (OXC2,OXC3), when receives the Path message with Impairments Collection Request TLV, starts the internal impairments reading procedure and waits for the correspondent Resv message to forward the related Impairments recording TLV in the upstream flow to the ingress node OXC1. If for some reason the impairment is not available, since it is non blocking impairment, the node simply does not include the impairments measure in its own Impairments recording TLV. The holistic analysis can be performed also with a subset of the non blocking impairments. o Egress node OXC4 sends Resv message with Impairments Collection Request TLV containing optical impairments TLV upstream to the ingress node OXC1 and puts its own impairments value in this Impairments recording TLV. o Every transit node (OXC3,OXC2) inserts its own Impairments recording TLV inside Resv message in such way that ingress node collects all required impairments hop by hop. Z. Ali, et al Expires May 3, 2009 [Page 10] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 o OXC1 node when receives the Resv message extract the impairments recording TLV to perform holistic path validation. The transit nodes that do not support LSP_REQUIRED ATTRIBUTE object or do not support impairments request TLV will be addressed in a later version of the document. Summarizing the Impairments Collection will be executed by the returning Resv message that collects hop-by-hop impairments objects upstream. 2.6.2. Blocking collection of impairments with all nodes ready for impairments 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 collection. I.e., we need to be sure that all nodes along the path are ready to collect the impairments. 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 impairments. 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". 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 impairments collection. At this stage the Impairments Collection can be performed as described earlier. Z. Ali, et al Expires May 3, 2009 [Page 11] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 The locking is performed before impairments collection to maintain a better compatibility with the future available impairments kind that would require further action to be taken before starting the collection. 2.6.3. Blocking collection of impairments with some node(s) blocked for impairments 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 impairments. 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. 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). Z. Ali, et al Expires May 3, 2009 [Page 12] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 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 IANA considerations are to be added in a later revision. 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. [G.680] ITU-T Recommendation G.680, Physical transfer functions of optical network elements, July 2007. 6.2. Informative References [RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and Other Constraints on Optical Layer Routing", RFC 4054, May 2005. [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. Z. Ali, et al Expires May 3, 2009 [Page 13] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 [Bernstein-framework] G. Bernstein, Y. Lee, D. Li, A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments, Work in Progress, October 2008. [Bernstein-info] G. Bernstein, Y. Lee, D. Li, Information Model for Impaired Optical Path Validation, Work in progress, October 2008 [Martinelli-frame] G. Martinelli, A. Zanardi, D. Bianchi, E. Davies, A Framework for definining Optical Impariments to be used in WSON networks through GMPLS 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 Z. Ali, et al Expires May 3, 2009 [Page 14] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 Francesco Diana 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 7. Intellectual Property Considerations 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. Z. Ali, et al Expires May 3, 2009 [Page 15] draft-ali-ccamp-rsvp-te-based-evidence-collection-01 Nov. 08 8. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 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. 9. 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 May 3, 2009 [Page 16]