Network Working Group Y. Lee Internet Draft Huawei Intended status: Standards Track G. Bernstein Expires: April 2010 Grotto Networking October 12, 2009 OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 12, 2007. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of Lee and Bernstein Expires April 12, 2010 [Page 1] Internet-Draft Wavelength Switched Optical Networks October 2009 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. 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 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. WSON Network Element Compatibility Information Model...........3 2.1. Modulation Type List......................................4 2.2. FEC Type List.............................................4 2.3. Bit Rate Range List.......................................4 2.4. Acceptable Client Signal List.............................4 3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility5 3.1. Modulation Type List sub-TLV..............................5 3.2. FEC Type List sub-TLV.....................................7 3.3. Bit Rate Range List sub-TLV...............................9 3.4. Processing Capability List sub-TLV.......................10 3.5. Client Signal List sub-TLV...............................12 4. Security Considerations.......................................12 5. IANA Considerations...........................................12 6. Acknowledgments...............................................12 7. References....................................................13 7.1. Normative References.....................................13 7.2. Informative References...................................13 8. Contributors..................................................14 Lee and Bernstein Expires April 12, 2010 [Page 2] Internet-Draft Wavelength Switched Optical Networks October 2009 Authors' Addresses...............................................14 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................15 1. Introduction The document [WSON-Compat] explains how to extend the wavelength switched optical network (WSON) control plane to allow both multiple WSON signal types and common hybrid electro optical systems. In WSON, not all of the optical signals in the network are compatible with all network elements participating in the network. Therefore, signal compatibility is an important constraint in path computation in a WSON. This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. 2. WSON Network Element Compatibility Information Model In [WSON-Compat] it was explained that a network element (NE) in a WSON may or may not be compatible with a particular optical signal based upon the following criteria: 1. Limited wavelength range -- Already modeled in GMPLS for WSON 2. Modulation type restriction (including forward error correction - FEC- coding) 3. Bit rate range restriction (includes a particular rate) 4. Client signal dependence In the following we furnish an information model for the above properties. This model can be either applied to all ports of a network element, i.e., NE wide, or to individual ports, i.e., on a link level. Lee and Bernstein Expires April 12, 2010 [Page 3] Internet-Draft Wavelength Switched Optical Networks October 2009 2.1. Modulation Type List Modulation type, also known as optical tributary signal class, comes in two distinct flavors: (i) ITU-T standardized types; (ii) vendor specific types. The permitted modulation type list can include any mixture of standardized and vendor specific types. ::= [|]... Where the STANDARD_MODULATION object just represents one of the ITU-T standardized optical tributary signal class and the VENDOR_MODULATION object identifies one vendor specific modulation type. 2.2. FEC Type List Some devices can handle more than one FEC type and hence a list is needed. ::= [] Where the FEC object represents one of the ITU-T standardized FEC defined in [G.709] and [G.707] or vendor-specific FEC. 2.3. Bit Rate Range List Some devices can handle more than one particular bit rate range and hence a list is needed. ::= []... ::= Where the START_RATE object represents the lower end of the range and the END_RATE object represents the higher end of the range. 2.4. Acceptable Client Signal List The list is simply: ::=[]... Where the Generalized Protocol Identifiers (GPID) object represents one of the IETF standardized GPID values as defined in [RFC3471] and [RFC4328]. Lee and Bernstein Expires April 12, 2010 [Page 4] Internet-Draft Wavelength Switched Optical Networks October 2009 3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility This section describes GMPLS OSPF Routing protocol enhancement based on network element compatibility information model defined in the previous section. Note that the encoding defined in this section is specific for OSPF extension, but similar encoding can be applied to IS-IS and alternative methods distributing traffic engineering information. In [RFC4202], Routing extensions for GMPLS, the concept of an Interface Switching Capability Descriptors is defined. In particular a "Lambda-Switch Capable" (LSC) descriptor is listed. Reference [RFC4202] also states: "Depending on a particular Interface Switching Capability, the Interface Switching Capability Descriptor may include additional information, as specified below." However no mention is made of the compatibility criteria discussed in [WSON-Compat], i.e., modulation type, FEC type, bit rate range, or client signal. The only additional information currently defined is "reservable bandwidth per priority". In references [RFC4203] and [RFC5307] a variable length sub-TLV type for Interface Switching Capability Descriptors (ISCD) is defined. There is a section in the general ISCD sub-TLV called "Switching Capability-specific information". They then state: "When the Switching Capability field is LSC, there is no Switching Capability specific information field present." [It is an open question whether we can add new information to the existing LSC ISCD. In either case the following suggests an encoding that could be used within the switching capability specific information field or as separate sub-TLVs.] 3.1. Modulation Type List sub-TLV The modulation type list sub-TLV may consist of two different types of fields: a standard modulation field or a vendor specific modulation field. Both start with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee and Bernstein Expires April 12, 2010 [Page 5] Internet-Draft Wavelength Switched Optical Networks October 2009 Where S bit set to 1 indicates a standardized modulation format and S bit set to 0 indicates a vendor specific modulation format. The length is the length in bytes of the entire modulation type field. Where I bit set to 1 indicates it is an input modulation constraint and I bit set to 0 indicates it is an output modulation constraint. Note that if an output modulation is not specified then it is implied that it is the same as the input modulation. In such case, no modulation conversion is performed. The format for the standardized type for the input modulation is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional modulation parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the modulation ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modulation ID (S bit = 1); Input modulation (I bit = 1) Takes on the following currently defined values: 0 Reserved 1 optical tributary signal class NRZ 1.25G 2 optical tributary signal class NRZ 2.5G 3 optical tributary signal class NRZ 10G 4 optical tributary signal class NRZ 40G 5 optical tributary signal class RZ 40G Note that future modulation types may require additional parameters in their characterization. Lee and Bernstein Expires April 12, 2010 [Page 6] Internet-Draft Wavelength Switched Optical Networks October 2009 The format for vendor specific modulation field (for input constraint) is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Vendor Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional modulation parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor Modulation ID This is a vendor assigned identifier for the modulation type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional parameters There can be potentially additional parameters characterizing the vendor specific modulation. 3.2. FEC Type List sub-TLV The FEC type list sub-TLV may consist of two different types of fields: a standard FEC field or a vendor specific FEC field. Both start with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee and Bernstein Expires April 12, 2010 [Page 7] Internet-Draft Wavelength Switched Optical Networks October 2009 Where S bit set to 1 indicates a standardized FEC format and S bit set to 0 indicates a vendor specific FEC format. The length is the length in bytes of the entire FEC type field. Where I bit set to 1 indicates it is an input FEC constraint and I bit set to 0 indicates it is an output FEC constraint. Note that if an output FEC is not specified then it is implied that it is the same as the input FEC. In such case, no FEC conversion is performed. The length is the length in bytes of the entire FEC type field. The format for input standard FEC field is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Takes on the following currently defined values for the standard FEC ID: 0 Reserved 1 G.709 RS FEC 2 G.709V compliant Ultra FEC The format for input vendor-specific FEC field is given by: Lee and Bernstein Expires April 12, 2010 [Page 8] Internet-Draft Wavelength Switched Optical Networks October 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Vendor FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional FEC parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor FEC ID This is a vendor assigned identifier for the FEC type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional FEC parameters There can be potentially additional parameters characterizing the vendor specific FEC. 3.3. Bit Rate Range List sub-TLV The bit rate range list sub-TLV makes use of the following bit rate range field: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Bit Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Bit Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The starting and ending bit rates are given as 32 bit IEEE floating point numbers in bits per second. Note that the starting bit rate is less than or equal to the ending bit rate. Lee and Bernstein Expires April 12, 2010 [Page 9] Internet-Draft Wavelength Switched Optical Networks October 2009 The bit rate range list sub-TLV is then given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #1 +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #M +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4. Processing Capability List sub-TLV The processing capability list sub-TLV is a list of WSON network element (NE) that can perform signal processing functions including: 1. Regeneration capability 2. Fault and performance monitoring 3. Vendor Specific capability Note that the code points for Fault and performance monitoring and vendor specific capability are subject to further study. The processing capability list sub-TLV is then given by: Lee and Bernstein Expires April 12, 2010 [Page 10] Internet-Draft Wavelength Switched Optical Networks October 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Processing Cap ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional capability parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the processing ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the processing Cap ID is "regeneration capability", the following additional capability parameters are provided in the sub- TLV: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | C | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where T bit indicates the type of regenerator: T=0: Reserved T=1: 1R Regenerator T=2: 2R Regenerator T=3: 3R Regenerator Where C bit indicates the capability of regenerator: C=0: Reserved C=1: Fixed Regeneration Point C=2: Selective Regeneration Pools Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as ingress and egress restrictions and availability need to be specified. This encoding is to be determined in the later revision. Lee and Bernstein Expires April 12, 2010 [Page 11] Internet-Draft Wavelength Switched Optical Networks October 2009 3.5. Client Signal List sub-TLV The acceptable client signal list sub-TLV is a list of Generalized Protocol Identifiers (GPIDs). GPIDs are assigned by IANA and many are defined in [RFC3471] and [RFC4328]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of GPIDs | GPID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GPID #N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the number of GPIDs is an integer greater than or equal to one. 4. Security Considerations This document does not introduce any further security issues other than those discussed in [RFC 3630], [RFC 4203]. 5. IANA Considerations TBD. 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Lee and Bernstein Expires April 12, 2010 [Page 12] Internet-Draft Wavelength Switched Optical Networks October 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June, 2002. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. 7.2. Informative References [WSON-Compat] G. Bernstein, Y. Lee, B. Mack-Crane, "WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS ", draft-bernstein-ccamp-wson compatibility, work in progress. Lee and Bernstein Expires April 12, 2010 [Page 13] Internet-Draft Wavelength Switched Optical Networks October 2009 8. Contributors Authors' Addresses Young Lee (ed.) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) Email: ylee@huawei.com Greg M. Bernstein (ed.) Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 Lee and Bernstein Expires April 12, 2010 [Page 14] Internet-Draft Wavelength Switched Optical Networks October 2009 rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee and Bernstein Expires April 12, 2010 [Page 15]