--- 1/draft-ietf-ccamp-gmpls-alarm-spec-04.txt 2006-09-06 22:12:06.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-alarm-spec-05.txt 2006-09-06 22:12:06.000000000 +0200 @@ -1,20 +1,18 @@ Internet Draft Lou Berger - Editor (LabN) Updates: 3473 Category: Standards Track -Expiration Date: February 2007 - - August 2006 + September 2006 GMPLS - Communication of Alarm Information - draft-ietf-ccamp-gmpls-alarm-spec-04.txt + draft-ietf-ccamp-gmpls-alarm-spec-05.txt 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 @@ -43,44 +41,49 @@ modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. Contents - 1 Introduction .............................................. 3 - 1.1 Background ................................................ 3 - 2 Alarm Information Communication ........................... 4 - 3 GMPLS-RSVP Details ........................................ 5 - 3.1 ALARM_SPEC Objects ........................................ 5 - 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6 - 3.1.2 Procedures ................................................ 9 - 3.1.3 Error Codes and Values .................................... 10 - 3.1.4 Backwards Compatibility ................................... 11 - 3.2 Controlling Alarm Communication ........................... 11 - 3.2.1 Updated Admin Status Object ............................... 11 - 3.2.2 Procedures ................................................ 11 - 3.3 Message Formats ........................................... 12 - 3.4 Relationship to GMPLS UNI ................................. 13 - 3.5 Relationship to GMPLS E-NNI .............................. 14 - 4 Security Considerations ................................... 14 - 5 IANA Considerations ....................................... 15 - 6 References ................................................ 16 - 6.1 Normative References ...................................... 16 - 6.2 Informative References .................................... 16 - 7 Contributors .............................................. 17 - 8 Contact Address ........................................... 17 - 9 Full Copyright Statement .................................. 18 -10 Intellectual Property ..................................... 18 + 1 Introduction ............................................. 3 + 1.1 Background ............................................... 3 + 2 Alarm Information Communication .......................... 4 + 3 GMPLS-RSVP Details ....................................... 5 + 3.1 ALARM_SPEC Objects ....................................... 5 + 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ................... 6 + 3.1.2 Procedures ............................................... 9 + 3.1.3 Error Codes and Values .................................. 10 + 3.1.4 Backwards Compatibility ................................. 11 + 3.2 Controlling Alarm Communication ......................... 11 + 3.2.1 Updated Admin Status Object ............................. 11 + 3.2.2 Procedures .............................................. 11 + 3.3 Message Formats ......................................... 12 + 3.4 Relationship to GMPLS UNI ............................... 13 + 3.5 Relationship to GMPLS E-NNI ............................. 14 + 4 Acknowledgements ........................................ 14 + 5 Security Considerations ................................. 14 + 6 IANA Considerations ..................................... 15 + 6.1 New RSVP Object ......................................... 15 + 6.2 New Interface ID Types .................................. 16 + 6.3 New Registry for Admin-Status Object Bit Fields ......... 16 + 6.4 New RSVP Error Code ..................................... 16 + 7 References .............................................. 17 + 7.1 Normative References .................................... 17 + 7.2 Informative References .................................. 17 + 8 Contributors ............................................ 18 + 9 Contact Address ......................................... 18 + 10 Full Copyright Statement ................................ 18 + 11 Intellectual Property ................................... 19 1. Introduction GMPLS Signaling provides mechanisms that can be used to control the reporting of alarms associated with an LSP. This support is provided via Administrative Status Information [RFC3471] and the Admin_Status object [RFC3473]. These mechanisms only control if alarm reporting is inhibited. No provision is made for communication of alarm information within GMPLS. @@ -181,21 +184,21 @@ The addition of alarm information to Path and Resv messages is controlled via a new Administrative Status Information bit. Administrative Status Information is carried in the Admin_Status object. 3. GMPLS-RSVP Details This section provides the GMPLS-RSVP [RFC3473] specification for communication of alarm information. The communication of alarm - information is optional. This section applies to nodes that support + information is OPTIONAL. This section applies to nodes that support communication of alarm information. 3.1. ALARM_SPEC Objects The ALARM_SPEC objects use the same format as the ERROR_SPEC object, but with class number of TBA (to be assigned by IANA in the form 11bbbbbb, per Section 3.1.4). o Class = TBA, C-Type = 1 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined @@ -210,21 +213,21 @@ o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs The following new TLVs are defined for use with the IPv4 and IPv6 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the original definition of these values. Note the length provided below - is for the total TLV. All TLVs defined in this section are optional. + is for the total TLV. All TLVs defined in this section are OPTIONAL. The defined TLVs MUST follow any interface identifying TLVs. No rules apply to the relative ordering of the TLVs defined in this section. [Note: Type values are TBA (to be assigned) by IANA] Type Length Description ---------------------------------- 512 8 REFERENCE_COUNT 513 8 SEVERITY @@ -238,56 +241,59 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reference Count: 32 bits The number of times this alarm has been repeated as determined - by the reporting node. This field MUST NOT be set to zero. + a TLV is sent and a received TLV with this field set to zero + MUST be ignored. Only one Reference Count TLV may be included in an object. The Severity TLV has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Impact | Severity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Reserved: 24 bits + Reserved: 20 bits This field is reserved. It MUST be set to zero on generation, MUST be ignored on receipt and MUST be forwarded unchanged and unexamined by transit nodes. Impact: 4 bits Indicates the impact of the alarm indicated in the TLV. See [M.20] for a general discussion on classification of failures. - The following values are defined: + The following values are defined in this document. The details + of the semantics may be found in [M.20]. Value Definition ----- --------------------- 0 Unspecified impact 1 Non-Service Affecting (Data traffic not interrupted) 2 Service Affecting (Data traffic is interrupted) Severity: 8 bits Indicates the impact of the alarm indicated in the TLV. See [RFC3877] and [M.3100] for more information on severity. The - following values are defined: + The following values are defined in this document. The details + of the semantics may be found in [RFC3877] and [M.3100]. Value Definition ----- ---------- 0 Cleared 1 Indeterminate 2 Critical 3 Major 4 Minor 5 Warning @@ -297,22 +303,24 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Global Timestamp: 32 bits - The number of seconds since 0000 UT on 1 January 1970, - according to the clock on the node that originates this TLV. + A positive integer where all 32 bits are valid that indicates + the number of seconds since 0000 UT on 1 January 1970 according + to the clock on the node that originates this TLV. This time + MAY include leap seconds if they are used by the local clock. Only one Global Timestamp TLV may be included in an object. The Local Timestamp TLV has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -352,25 +360,25 @@ Note length includes padding. Multiple Error String TLVs may be included in an object. 3.1.2. Procedures This section applies to nodes that support the communication of alarm information. ALARM_SPEC objects are carried in Path and Resv messages. Multiple ALARM_SPEC objects MAY be present. - Nodes that support the communication of alarm information, SHOULD - record the information contained in a received ALARM_SPEC for later - use. All ALARM_SPEC objects received in Path messages SHOULD be - passed unmodified downstream in the corresponding Path messages. All - ALARM_SPEC objects received in Resv messages SHOULD be passed + Nodes that support the extensions defined in this document SHOULD + store any alarm information from received ALARM_SPEC objects for + future use. All ALARM_SPEC objects received in Path messages SHOULD + be passed unmodified downstream in the corresponding Path messages. + All ALARM_SPEC objects received in Resv messages SHOULD be passed unmodified upstream in the corresponding Resv messages. ALARM_SPEC objects are merged in transmitted Resv messages by including a copy of all ALARM_SPEC objects received in corresponding Resv Messages. To advertise local alarm information, a node generates an ALARM_SPEC object for each alarm and adds it to both the Path and Resv messages for the effected LSP. In all cases, appropriate Error Node Address, Error Code and Error Values MUST be set, see below for a discussion on Error Code and Error Values. As the InPlace and NotGuilty flags only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. @@ -421,29 +429,31 @@ 3.1.3. Error Codes and Values The Error Codes and Values used in ALARM_SPEC objects are the same as those used in ERROR_SPEC objects. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards. In this document we define one new Error Code. The Error Code uses the value TBA (by IANA) and is referred to as "Alarms". The values - used in the Error Values field are the same as the values used for - IANAItuProbableCause in the Alarm MIB [RFC3877]. Note these values - are managed by IANA, see http://www.iana.org. + used in the Error Values field when the Error Code is "Alarms" are + the same as the values defined in the IANAItuProbableCause Textual + Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note + these values are managed by IANA, see http://www.iana.org. 3.1.4. Backwards Compatibility - The support of ALARM_SPEC objects is optional. Non-supporting nodes - will pass the objects through the node unmodified, because the - ALARM_SPEC object has a C-Num of the form 11bbbbbb. + The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes + will (according to the rules defined in [RFC2205]) pass the objects + through the node unmodified, because the ALARM_SPEC object has a + C-Num of the form 11bbbbbb. This allows alarm information to be collected and examined in a network built from a collection of nodes some of which support the communication of alarm information, and some of which do not. 3.2. Controlling Alarm Communication Alarm information communication is controlled via Administrative Status Information as carried in the Admin_Status object. A new bit is defined, called the I bit, that indicates when alarm communication @@ -593,142 +603,180 @@ o An ingress or egress core-node MAY modify internal core network alarms. This may facilitate the peering E-NNI (i.e. the egress core-node) to understand the failure and its effect on the data plane, and take corrective actions in a more-appropriate manner or prolong the generated alarms upstream/downstream as appropriated. o Similarly, an egress/ingress core-node MAY choose to not request alarm reporting on Path messages that it sends downstream. - .Pa "Acknowledgments" +4. Acknowledgments Valuable comments and input were received from a number of people, - including Wes Doonan, Bert for the DISMAN reference, Tom Petch for - getting the disman WG interactions started. We also thank David - Black for his valuable comments. + including Wes Doonan, Bert Wijnen for the DISMAN reference, Tom Petch + for getting the disman WG interactions started. We also thank David + Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus + Westerlund, for their valuable comments. -4. Security Considerations +5. Security Considerations Some operators may consider alarm information as sensitive. To support environments where this is the case, implementations SHOULD allow the user to disable the generation of ALARM_SPEC objects, or to filter or correlate them at domain boundaries. This document introduces no additional security considerations. See [RFC3473] for relevant security considerations. It may be noted that if the security considerations of [RFC3473] are breached, alarm information may be spoofed. Such spoofing would be at most annoying and cause slight degradation of control plane performance since the details are provided for information only and do not result in protocol actions beyond the exchange of messages to convey the information. If the protocol security is able to be breached sufficiently to allow spoofing of alarm information then considerably more interesting and exciting damage can be caused by spoofing other elements of the protocol messages. -5. IANA Considerations +6. IANA Considerations IANA is requested to administer assignment of new values for namespaces defined in this document and reviewed in this section. - This section uses the terminology of BCP 26 "Guidelines for Writing - an IANA Considerations Section in RFCs" [BCP26]. - This document defines a new RSVP "ALARM_SPEC object" with a Class-Num - of the form 11bbbbbb, see section 3.1. The value 197 is suggested. - The C-type values associated with this object should read "Same - values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2 - which are reserved". The text associated with ALARM_SPEC object - should also read "The ALARM_SPEC object uses the Error Code and - Values from the ERROR_SPEC object." +6.1. New RSVP Object - Additionally, Section 3.1.3 defines a new RSVP Error Code. The Error - Code is "Alarms" and uses Error Values defined in the Alarm MIB - [RFC3877]. The suggested Error Code value is 28. + Upon approval of this document, the IANA will make the following + assignments in the "Class Names, Class Numbers, and Class Types" + section of the "RSVP PARAMETERS" registry located at + http://www.iana.org/assignments/rsvp-parameters - This document also defines the TLVs for use with the RSVP IF_ID - ERROR_SPEC objects defined in [RFC3473]. The following are the TLV - descriptions and (suggested) type values listed in Section 3.1.1: - Type Length Description - ---------------------------------- - 512 8 REFERENCE_COUNT - 513 8 SEVERITY - 514 8 GLOBAL_TIMESTAMP - 515 8 LOCAL_TIMESTAMP - 516 variable ERROR_STRING + A new class named ALARM_SPEC will be created in the 11bbbbbb range + (197 suggested) with following values - Note that the type values are not sequential with existing RSVP IF_ID - ERROR_SPEC object TLV assignments. This is intentional and is - intended to provide space for future error TLVs. + o Class = TBA, C-Type = 1 + [RFC-ccamp-gmpls-alarm-spec] + Reserved. (C-Type value defined for ERROR_SPEC, but is not defined + for use with ALARM_SPEC.) - This document also defines the I bit in the Admin Status Object, see - Section 3.2.1. This bit field was originally defined in Section 7.1 - of [RFC3473]. We request IANA to begin managing assignment of bits - in the Admin Status Object, and that the bits be allocated through - IETF Consensus actions. Within the 32 bit field in the Admin Status - Object, the defined bits are: + o Class = TBA, C-Type = 2 + [RFC-ccamp-gmpls-alarm-spec] + Reserved. (C-Type value defined for ERROR_SPEC, but is not defined + for use with ALARM_SPEC.) + + o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 + [RFC-ccamp-gmpls-alarm-spec] + Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. + + o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 + [RFC-ccamp-gmpls-alarm-spec] + Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. + + The ALARM_SPEC object uses the Error Code and Error Values from the + ERROR_SPEC object. + +6.2. New Interface ID Types + + Upon approval of this document, the IANA will make the following + assignments in the "Interface_ID Types" section of the "GMPLS + Signaling Parameters" registry located at + http://www.iana.org/assignments/gmpls-sig-parameters + + xx2 8 REFERENCE_COUNT [RFC-ccamp-gmpls-alarm-spec] + xx3 8 SEVERITY [RFC-ccamp-gmpls-alarm-spec] + xx4 8 GLOBAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec] + xx5 8 LOCAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec] + xx6 variable ERROR_STRING [RFC-ccamp-gmpls-alarm-spec] + + (The value of 51 is suggested for xx.) + +6.3. New Registry for Admin-Status Object Bit Fields + + Upon approval of this document, the IANA will create a new section + titled "Administrative Status Information Flags" in the "GMPLS + Signaling Parameters" registry located at + http://www.iana.org/assignments/gmpls-sig-parameters and make the + following assignments: Value Name Reference ---------- --------------------------------- ----------------- 0x80000000 Reflect (R) [RFC3473/RFC3471] - 0x00000010 Inhibit Alarm Communication (I) [This document] + 0x00000010 Inhibit Alarm Communication (I) + [RFC-ccamp-gmpls-alarm-spec] 0x00000004 Testing (T) [RFC3473/RFC3471] 0x00000002 Administratively down (A) [RFC3473/RFC3471] 0x00000001 Deletion in progress (D) [RFC3473/RFC3471] -6. References +6.4. New RSVP Error Code -6.1. Normative References + Upon approval of this document, the IANA will make the following + assignments in the "Error Codes and Values" section of the "RSVP + PARAMETERS" registry located at + http://www.iana.org/assignments/rsvp-parameters + + xx Alarms [RFC4124] + + The Error Value sub-codes for this Error Code have values and + meanings identical to the values and meanings defined in the + IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB + in the Alarm MIB [RFC3877]. Note these values are already + managed the IANA. + + (The value of 31 is suggested for xx.) + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3877] Chisholm, S., Romascanu, D., "Alarm Management Information Base (MIB)", RFC 3877, September 2004. [M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995 -6.2. Informative References +7.2. Informative References [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling - in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. + in MPLS Traffic Engineering (TE)", RFC 4201, October + 2005. [M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION NETWORKS", Recommendation M.20, October 1992. [GR833] Bellcore, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 3, February 1999. -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)," draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. -7. Contributors +8. Authors' Addresses Contributors are listed in alphabetical order: Lou Berger Deborah Brungard LabN Consulting, L.L.C. AT&T Labs, Room MT D1-3C22 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 301-468-9228 Phone: (732) 420-1573 Email: lberger@labn.net Email: dbrungard@att.com @@ -739,42 +787,42 @@ McLean VA, 22102, USA Phone: +44 (0) 1978 860944 Email: ibryskin@movaz.com Email: adrian@olddog.co.uk Dimitri Papadimitriou (Alcatel) Arun Satyanarayana Francis Wellesplein 1 Cisco Systems, Inc B-2018 Antwerpen, Belgium 170 West Tasman Dr. San Jose, CA 95134 USA Phone: +32 3 240-8491 Phone: +1 408 853-3206 Email: dimitri.papadimitriou@alcatel.be Email: asatyana@cisco.com -8. Contact Address +9. Contact Address Lou Berger LabN Consulting, L.L.C. Phone: +1 301-468-9228 Email: lberger@labn.net -9. Full Copyright Statement +10. Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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 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. -10. Intellectual Property +11. Intellectual Property 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. @@ -783,12 +831,10 @@ 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. - -Generated on: Mon Aug 14 06:52:31 EDT 2006