[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-thomas-mpls-ldp-capabilities) 00 01 02 03 04 RFC 5561

Network Working Group                                        Bob Thomas
Internet Draft                                       Cisco Systems, Inc.
Intended Status: Proposed Standard
Expiration Date: September 05, 2009                          S. Aggarwal
                                                        Juniper Networks

                                                             R. Aggarwal
                                                        Juniper Networks

                                                            J.L. Le Roux
                                                          France Telecom

                                                        Syed Kamran Raza
                                                     Cisco Systems, Inc.

                                                          March 06, 2009

                             LDP Capabilities

                  draft-ietf-mpls-ldp-capabilities-03.txt


Status of this Memo

 This Internet-Draft is submitted to IETF in full conformance
 with the provisions of BCP 78 and BCP 79.  This document may
 contain material from IETF Documents or IETF Contributions
 published or made publicly available before November 10,
 2008.  The person(s) controlling the copyright in some of
 this material may not have granted the IETF Trust the right
 to allow modifications of such material outside the IETF
 Standards Process.  Without obtaining an adequate license
 from the person(s) controlling the copyright in such
 materials, this document may not be modified outside the
 IETF Standards Process, and derivative works of it may not
 be created outside the IETF Standards Process, except to
 format it for publication as an RFC or to translate it into
 languages other than English.

 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 September 05, 2009.


Thomas, et al.          Expires September 2009                 [Page 1]
Internet-Draft             LDP Capabilities                  March 2009


Abstract

 A number of enhancements to the Label Distribution Protocol (LDP)
 have been proposed. Some have been implemented, and some are
 advancing toward standardization.  It is likely that additional
 enhancements will be proposed in the future.  At present, LDP has no
 mechanism for advertising such enhancements at LDP session
 initialization time.  There is also no mechanism to enable and
 disable enhancements after the session is established. This document
 defines a mechanism for advertising LDP enhancements at session
 initialization time, as well as a mechanism to enable and disable
 enhancements after LDP session establishment.

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 [RFC2119].

 This document uses the terms "LDP speaker" and "speaker"
 interchangably.

Table of Contents

 1. Introduction...................................................3
 2. The LDP Capability Mechanism...................................4
    2.1. Capability Document.......................................5
 3. Specifying Capabilities in LDP Messages........................5
    3.1. Backward Compatibility TLVs...............................7
 4. Capability Message.............................................7
 5. Note on Terminology............................................8
 6. Procedures for Capability Parameters in Initialization Messages8
 7. Procedures for Capability Parameters in Capability Messages....9
 8. Extensions to Error Handling..................................10
 9. Dynamic Capability Announcement TLV...........................10
 10. Backward Compatibility.......................................11
 11. Security Considerations......................................11
 12. IANA Considerations..........................................11



Thomas, et al.          Expires September 2009                 [Page 2]
Internet-Draft             LDP Capabilities                  March 2009


 13. Acknowledgments..............................................12
 14. References...................................................12
    14.1. Normative References....................................12
    14.2. Informative References..................................12
 15. Author's Addresses...........................................13



1. Introduction

 A number of enhancements to LDP as specified in [RFC5036] have been
 proposed.  These include LDP Graceful Restart [RFC3478], Fault
 Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
 layer 2 circuits [RFC4447], a method for learning labels advertised
 by next-next-hop routers in support of fast reroute node protection
 [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
 signaling inter-area LSPs [IALDP].  Some have been implemented, and
 some are advancing toward standardization.  It is also likely that
 additional enhancements will be implemented and deployed in the
 future.

 At present, LDP does not have a mechanism for advertising such
 enhancements at LDP session initialization time.  There is also no
 mechanism to enable and disable these enhancements after the session
 is established.

 This document proposes and defines a mechanism for advertising LDP
 enhancements at session initialization time.  It also defines a
 mechanism to enable and disable these enhancements after LDP session
 establishment.

 LDP capability advertisement provides means for an LDP speaker to
 announce what it can receive and process.  It also provides means for
 a speaker to inform peers of deviations from behavior specified by
 [RFC5036].  An example of such a deviation is LDP graceful restart
 where a speaker retains MPLS forwarding state for LDP-signaled LSPs
 when its LDP control plane goes down.  It is important to point out
 that not all LDP enhancements require capability advertisement.  For
 example, upstream label allocation does but inbound label filtering,
 where a speaker installs forwarding state for only certain FECs, does
 not.





Thomas, et al.          Expires September 2009                 [Page 3]
Internet-Draft             LDP Capabilities                  March 2009


2. The LDP Capability Mechanism

 Enhancements are likely to be announced during LDP session
 establishment as each LDP speaker advertises capabilities
 corresponding to the enhancements it desires.

 Beyond that, capability advertisements may be used to dynamically
 modify the characteristics of the session to suit the changing
 conditions.  For example, an LSR capable of a particular enhancement
 in support of some "feature" may not have advertised the
 corresponding capability to its peers at session establishment time
 because the feature was disabled at that time.  Later, an operator
 may enable the feature, at which time the LSR would react by
 advertising the corresponding capability to its peers.  Similarly,
 when an operator disables a feature associated with a capability, the
 LSR reacts by withdrawing the capability advertisement from its
 peers.

 The LDP capability advertisement mechanism operates as follows:

 -   Each LDP speaker is assumed to implement a set of enhancements,
     each of which has an associated capability.  At any time, a
     speaker may have none, one, or more of those enhancements
     "enabled".  When an enhancement is enabled, the speaker
     advertises the associated capability to its peers.  By
     advertising the capability to a peer, the speaker asserts that it
     shall perform the protocol actions specified for the associated
     enhancement. For example, the actions may require the LDP speaker
     to receive and process enhancement-specific messages from its
     peer. Unless the capability has been advertised, the speaker will
     not perform protocol actions specified for the corresponding
     enhancement.

 -   At session establishment time an LDP speaker MAY advertise a
     particular capability by including an optional parameter
     associated with the capability in its Initialization message.

 -   There is a well-known capability called "Dynamic Capability
     Announcement" which an LDP speaker MAY advertise in its
     Initialization message to indicate that it is capable of





Thomas, et al.          Expires September 2009                 [Page 4]
Internet-Draft             LDP Capabilities                  March 2009


     processing capability announcements following a session
     establishment.

     If a peer had advertised the "Dynamic Capability Announcement"
     capability in its Initialization message, then at any time
     following session establishment an LDP speaker MAY announce
     changes in its advertised capabilities to that peer.  To do this,
     the LDP speaker sends the peer a "Capability" message that
     specifies the capabilities being advertised or withdrawn.

2.1. Capability Document

 When the capability advertisement mechanism is in place, an LDP
 enhancement requiring LDP capability advertisement will be specified
 by a document that:

    - Describes the motivation for the enhancement;

    - Specifies the behavior of LDP when the enhancement is enabled.
     This includes the procedures, parameters, messages, and TLVs
     required by the enhancement;

    - Includes an IANA considerations section that requests IANA for
     assignment of code point for the optional parameter corresponding
     to the enhancement.

3. Specifying Capabilities in LDP Messages

 This document uses the term "Capability Parameter" to refer to an
 optional parameter that may be included in Initialization and
 Capability messages to advertise a capability.

 The format of "Capability Parameter" TLV 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| TLV Code Point            |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved    |                                               |
     +-+-+-+-+-+-+-+-+       Capability Data                         |




Thomas, et al.          Expires September 2009                 [Page 5]
Internet-Draft             LDP Capabilities                  March 2009


     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 where:
    U-bit:
      The value could be either 0 or 1 as specified in Capability
      document associated with given capability.

    F-bit:
      MUST be 0 (i.e. don't forward if not understood).

    TLV Code Point:
      The TLV type which identifies a specific capability.  The "IANA
      Considerations" section of [RFC5036] specifies the assignment of
      code points for LDP TLVs.

    S-bit:
      The State Bit indicates whether the sender is advertising or
      withdrawing the capability corresponding to the TLV Code Point.
      The State bit is used as follows:

          1 - The TLV is advertising the capability specified by the
               TLV Code Point.
          0 - The TLV is withdrawing the capability specified by the
               TLV Code Point.

    Capability Data:
      Information, if any, about the capability in addition to the TLV
      Code Point required to fully specify the capability.
      The method for interpreting and processing this data is specific
      to the TLV Code Point and MUST be described in the document
      specifying the capability.

 An LDP speaker MUST NOT include more than one instance of a
 Capability Parameter (as identified by the same TLV code point) in an
 Initialization or Capability message. If an LDP speaker receives more
 than one instance of the same Capability Parameter type in a message,
 it SHOULD send a Notification message to peer before terminating the
 session with peer. The Status Code in the Status TLV of the
 Notification message MUST be "Malformed TLV" and the message SHOULD



Thomas, et al.          Expires September 2009                 [Page 6]
Internet-Draft             LDP Capabilities                  March 2009


 contain the second "Capability Parameter TLV" of the same type (Code
 point) that is received in the message.

3.1. Backward Compatibility TLVs

 Few LDP protocol extensions have been made in past to advertise and
 negotiate some capability or extension at session establishment time.
 These extensions usually define a new TLV which is directly included
 in an Initialization message. One example of such extension is "FT
 Session TLV" which is exchanged in Initialization message between
 peers to announce LDP Fault Tolerance [RFC3479] capability.  To
 ensure backward compatibility with existing implementations, such
 TLVs play the role of a "Capability Parameter" when included in
 Initialization messages, and this document refers to such TLVs as
 "Backward Compatibility TLVs".

4. Capability Message

 The LDP Capability message is used by an LDP speaker to announce
 changes in the state of one or more of its capabilities subsequent to
 session establishment.

 The format of the Capability message 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|    Capability (IANA)        |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Message ID                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     TLV_1                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     . . .                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     TLV_N                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 where TLV_1 through TLV_N are "Capability Parameter" TLVs. The S-bit
 of each of the TLVs specifies the new state for the corresponding
 capability.




Thomas, et al.          Expires September 2009                 [Page 7]
Internet-Draft             LDP Capabilities                  March 2009



 Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be
 included in Capability messages.

5. Note on Terminology

 The following sections in this document talk about enabling and
 disabling capabilities. The terminology "enabling (or disabling) a
 capability" is short hand for "advertising (or withdrawing) a
 capability associated with an enhancement".  Bear in mind that it is
 an LDP enhancement that is being enabled or disabled, and that it is
 the corresponding capability that is being advertisted or withdrawn.

6. Procedures for Capability Parameters in Initialization Messages

 The S-bit of a Capability Parameter in an Initialization message MUST
 be 1 and SHOULD be ignored on receipt.  This ensures that any
 Capability Parameter in an Initialization message enables the
 corresponding capability.

 An LDP speaker determines the capabilities of a peer by examining the
 set of of Capability Parameters present in the Initialization message
 received from the peer.

 An LDP speaker MAY use a particular capability with its peer after
 the speaker determines that the peer has enabled that capability.

 These procedures enable an LDP speaker S1, that advertises a specific
 LDP capability C, to establish an LDP session with speaker S2 that
 does not advertise C.  In this situation whether or not capability C
 may be used for the session depends on the semantics of the
 enhancement associated with C.  If the semantics do not require both
 S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's
 advertisement of C permits S2 to send messages to S1 used by the
 enhancement.

 It is the responsibility of the capability designer to specify the
 behavior of an LDP speaker that has enabled a certain enhancement,
 advertised its capability and determines that its peer has not
 advertised the corresponding capability.  The document specifying
 procedures for the capability MUST describe the behavior in this




Thomas, et al.          Expires September 2009                 [Page 8]
Internet-Draft             LDP Capabilities                  March 2009


 situation.  If the specified procedure is to terminate the session,
 then the LDP speaker SHOULD send a Notification message to the peer
 before terminating the session.  The Status Code in the Status TLV of
 the Notification message MUST be "Unsupported Capability" and the
 message SHOULD contain the unsupported capability (see Section 8 for
 more details).

 An LDP speaker that supports capability advertisement and includes a
 Capability Parameter in its Initialization message MUST set the TLV
 U-bit to 0 or 1, as specified by "Capability" document.  LDP speaker
 should set U-bit to 1 if the capability document allows to continue
 with a peer that does not understand the enhancement, and set U-bit
 to 0 otherwise. If a speaker receives a message containng unsupported
 capability, it responds according to U-bit setting in the TLV. If U-
 bit is 1, then speaker MUST silently ignore the Capability Parameter
 and allow the session to be established. However, if U-bit is 0, then
 speaker SHOULD send a Notification message to the peer before
 terminating the session.  The Status Code in the Status TLV of the
 Notification message MUST be "Unsupported Capability" and the
 message SHOULD contain the unsupported capability (see Section 8 for
 more details).

7. Procedures for Capability Parameters in Capability Messages

 An LDP speaker MUST NOT send a Capability message to a peer unless
 its peer had advertised the Dynamic Capability Announcement
 capability in its session Initialization message.  An LDP speaker MAY
 send a Capability message to a peer if its peer had advertised the
 Dynamic Capability Announcement capability in its session
 Initialization message (see Section 9).

 An LDP speaker determines the capabilities enabled by a peer by
 determining the set of capabilities enabled at session initialization
 (as specified in Section 6) and tracking changes to that set made
 by Capability messages from the peer.

 An LDP speaker that has enabled a particular capability MAY use the
 enhancement corresponding to the capability with a peer after the
 speaker determines that the peer has enabled the capability.






Thomas, et al.          Expires September 2009                 [Page 9]
Internet-Draft             LDP Capabilities                  March 2009


8. Extensions to Error Handling

 This document defines a new LDP status code named "Unsupported
 Capability". The E-bit of the Status TLV carried in a Notification
 message that includes this status code MUST be set to 0.

 In addition, this document defines a new LDP TLV, named "Returned
 TLVs" that MAY be carried in a Notification message.  The U-bit
 setting for a Returned TLVs TLV in a Notification message SHOULD be 1
 and the F-bit setting SHOULD be 0.

 When the Status Code in a Notification message is "Unsupported
 Capability", the message SHOULD specify the capabilities that are
 unsupported.  When the Notification message specifies the unsupported
 capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs
 TLV MUST include only the Capability Parameters for unsupported
 capabilities, and the Capability Parameter for each such capability
 SHOULD be encoded as received from the peer.

 When the Status Code in a Notification Message is "Unknown TLV", the
 message SHOULD specify the TLV that was unknown.  When the
 Notification message specifies the TLV that was unknown, it MUST
 include the unknown TLV in a Returned TLVs TLV.

9. Dynamic Capability Announcement TLV

 The Dynamic Capability Announcement TLV is a Capability Parameter
 defined by this document with 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|0| DynCap Announcement (IANA)|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1| Reserved    |
     +-+-+-+-+-+-+-+-+

 The Dynamic Capability Announcement Parameter MAY be included by an
 LDP speaker in an Initialization message to signal its peer that the
 speaker is capable of processing Capability messages.





Thomas, et al.          Expires September 2009                [Page 10]
Internet-Draft             LDP Capabilities                  March 2009


 An LDP speaker MUST NOT include the Dynamic Capability Announcement
 Parameter in Capability messages sent to its peers.  Once enabled
 during session initialization, the Dynamic Capability Announcement
 capability cannot be disabled. This implies that S-bit is always 1
 for Dynamic Capability Announcement.

 An LDP speaker that receives a Capability message from a peer that
 includes the Dynamic Capability Announcement Parameter SHOULD
 silently ignore the parameter and process any other Capability
 Parameters in the message.

10. Backward Compatibility

 From the point of view of the LDP capability advertisement mechanism,
 an [RFC5036] compliant peer has label distribution for IPv4 enabled
 by default.  To ensure compatibility with an [RFC5036] compliant
 peer, LDP implementations that support capability advertisement have
 label distribution for IPv4 enabled until it is explicitly disabled
 and MUST assume that their peers do as well.

 Section 3.1 identifies a set of Backward Compatibility TLVs that
 may appear in Initialization messages in the role of a Capability
 Parameter.  This permits existing LDP enhancements that use an ad hoc
 mechanism for enabling capabilities at sesssion initialization time
 to continue to do so.

11. Security Considerations

 The security considerations described in [RFC5036] that apply to the
 base LDP specification apply to the capability mechanism described in
 this document.

12. IANA Considerations

 This document specifies the following which require code points
 assigned by IANA:

   - LDP message code point for the Capability message.  The authors
      request message type 0x0202 for the Capability message.

   - LDP TLV code point for the Dynamic Capability Announcemnt TLV.
      The authors request TLV type code 0x0506.



Thomas, et al.          Expires September 2009                [Page 11]
Internet-Draft             LDP Capabilities                  March 2009



   - LDP TLV code point for the Returned TLVs TLV.  The authors
      request TLV type 0x304.

   - LDP Status Code code point for the Unsupported Capability Status
      Code. The authors request Status Code 0x0000002C.


13. Acknowledgments

 The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
 Yakov Rekhter, and Eric Rosen for their comments.

 This document was prepared using 2-Word-v2.0.template.dot.

14. References

14.1. Normative References


 [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
           Specification", RFC 5036, September 2007.

 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC2119, March 1997.

 [RFC3479] Farrel, A., Editor,  "Fault Tolerance for the Label
           Distribution Protocol (LDP)", RFC 3479, February 2003.

14.2. Informative References

 [IALDP]   Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
           Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt,
           Work in Progress, March 2007

 [MLDP]    Minei, I., Wijnamds, I., Editors, "Label Distribution
           Protocol Extensions for Point-to-Multipoint and Multipoint-
           to-Multipoint Label Switched Paths", draft-minei-wijnands-
           mpls-ldp-p2mp-00.txt, Work in Progress, September 2005

 [NNHOP]   Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop
           Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in
           Progress, May 2005



Thomas, et al.          Expires September 2009                [Page 12]
Internet-Draft             LDP Capabilities                  March 2009


 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron,
           "Pseudowire Setup and Maintenance using the Label
           Distribution Protocol", RFC 4447, April 2006.

 [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart
           Mechanism for Label Distribution Protocol (LDP)", RFC 3478,
           February 2003.

 [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L.,  "MPLS Upstream Label
           Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt,
           Work in Progress, February 2006.

15. Author's Addresses

 Bob Thomas
 Cisco Systems, Inc.
 1414 Massachusetts Ave.
 Boxborough, MA 01719
 E-mail: rhthomas@cisco.com

 Shivani Aggarwal
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, CA 94089
 Email: shivani@juniper.net

 Rahul Aggarwal
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, CA 94089
 Email: rahul@juniper.net

 Jean-Louis Le Roux
 France Telecom
 2, Avenue Pierre-Marzin
 22307 Lannion Cedex, France
 E-mail: jeanlouis.leroux@orange-ftgroup.com

 Syed Kamran Raza
 Cisco Systems, Inc.
 2000 Innovation Dr.
 Kanata, ON K2K-3E8, Canada
 E-mail: skraza@cisco.com




Thomas, et al.          Expires September 2009                [Page 13]

Internet-Draft             LDP Capabilities                  March 2009



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 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.

Legal

 This 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.






Thomas, et al.          Expires September 2009                [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/