Network Working Group                Nabil Bitar
                                     (Editor)
                                     Verizon
Internet Draft                       Verizon                       Raymond Zhang
                                     (Editor)
                                     BT Infonet
Intended Status: Informational       Kenji Kumaki
                                     (Editor)
                                     KDDI Corporation

Expires: April 2007                  October 2006
        Inter-AS Requirements for the Path Computation Element
                  Communication Protocol (PCECP)

             draft-ietf-pce-interas-pcecp-reqs-01.txt

               draft-ietf-pce-interas-pcecp-reqs-02.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 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 a 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 in December 2006. January 2008.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   Multiprotocol Label Switching Traffic Engineered (MPLS-TE)
   LabelSwitched Label
   Switched Paths (LSPs) may be established wholly within an Autonomous
   System (AS) or may cross AS boundaries.

   The Path Computation Element (PCE) is a component that is capable of
   computing paths for MPLS-TE LSPs. The PCE Communication
   Protocol(PCECP) is defined to allow communication between Path
   Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is
   used to request paths and to supply computed paths in responses.
   Generic requirements for the PCECP PCEP are set out in "Path Computation
   Element(PCE) Communication Protocol Generic Requirements", RFC 4657.
   This document extends those requirements to cover the use of PCECP PCEP in
   support of inter-AS MPLS-TE.

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. Definitions......................................................3
   3. Reference Model..................................................4
   4. Detailed PCECP Requirements for Inter-AS Computation.............5
   4.1. PCE Communication Protocol Requirements........................5
   4.1.1. Requirements for path computation requests...................5
   4.1.2. Requirements for path computation responses..................6
   4.2. Scalability and Performance Requirements.......................7 Considerations.....................7
   4.3. Management, Aliveness Detection, and Recovery Requirements.....8 Management Considerations......................................8
   4.4. Confidentiality................................................8
   4.5. Policy Controls Affecting inter-AS PCECP.......................9
   4.5.1. Inter-AS PCE Peering Policy Controls.........................9
   4.5.2. Inter-AS PCE Reinterpretation Policies......................10
   5. Security Considerations.........................................10
   6. IANA Considerations.............................................11
   7. Acknowledgments.................................................11
   8. Authors' Addresses..............................................11
   9. Normative References............................................11 References............................................12
   10. Informative References.........................................12

1. Introduction

   [RFC4216] defines the scenarios motivating the deployment of inter-
   AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE).
   [RFC4216] (MPLS-TE) and
   specifies the requirements for inter-AS MPLS-TE when the
   ASs ASes are
   under the administration of one Service Provider (SP) or the
   administration of different SPs.

   Three signaling options are defined for setting up an inter-AS TE
   LSP:
       1) contiguous TE LSP as documented in [INTERD-TESIG];
       2) Stitched stitched inter-AS TE LSP discussed in [LSP-STITCHING];
       3) nested TE LSP as in [RFC4206].

   [INTERD-TE-PDPC] defines mechanisms for the computation of inter-
   domain TE LSPs using network elements along the signaling paths to
   compute per-domain path segments. The mechanisms in [INTERD-TE-PDPC]
   do not guarantee an optimum path across multiple ASs ASes where an
   optimum path for an LSP is one that has the smallest cost, according
   to a normalized TE metric (based upon a TE-metric or IGP metric
   adopted in each transit AS) among all possible paths that satisfy
   the LSP TE-constraints.

   The Path Computation Element (PCE) [RFC4655] is a component that is
   capable of computing paths for MPLS-TE LSPs. The requirements for a
   PCE have come from Service Provider (SP) demands to compute optimum
   paths across multiple areas and/or domains, and to be able to
   separate the path computation elements from the forwarding elements.

   The PCE Communication Protocol (PCECP) is defined to allow
   communication between Path Computation Clients (PCCs) and PCEs, and
   between PCEs. The PCECP is used to request paths and to supply
   computed paths in responses. Generic requirements for the PCECP are
   discussed in [RFC4657]. This document provides a set of PCECP
   requirements that are specific to MPLS-TE inter-AS path computation.

2. Definitions

   This document adopts the definitions and acronyms defined in Section
   3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the
   following terminology:

   PCECP: PCE Communication Protocol

   Inter-AS (G)MPLS-TE path: An MPLS-TE or Generalized MPLS (GMPLS)
   path that traverses two or more ASs. ASes.

   Intra-AS (G)MPLS-TE path: An MPLS-TE or GMPLS path that is confined
   to a single AS. It may traverse one or more IGP areas.

   Intra-AS PCE: A PCE responsible for computing MPLS-TE or GMPLS paths
   remaining within a single AS.

   Inter-AS PCE: A PCE responsible for computing inter-AS MPLS-TE or
   GMPLS paths or path segments, possibly by cooperating with intra-AS
   PCEs.

3. Reference Model

   Figure 1 depicts the reference model for PCEs in an inter-AS
   application. We refer to two types of PCE functions in this
   document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the
   procedures needed for inter-AS MPLS-TE or GMPLS path computation
   while intra-AS PCEs perform the functions needed for intra-AS MPLS-
   TE or GMPLS path computation.

   Following is

   Lets follow a scenario that depicts illustrates the interaction among PCCs,
   inter-AS PCEs and intra-area intra-AS PCEs based on shown Figure 1. R1 in AS1 wants to
   setup a TE-LSP MPLS-TE or a GMPLS path path, call LSP1, with certain constraints
   to R7 in AS3. R1 determines, determines using mechanisms out of the scope of
   this document, document that R7 is an AS-external inter-AS route and that it needs to
   contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a
   PCECP path request to PCE1. PCE1 determines that R7 is reachable via
   AS2 and that PCE2 is the PCE to ask for path computation across AS2.
   PCE1 sends a PCECP path request to PCE2. Inter-AS PCE2 PCE2, in turn turn,
   sends a PCECP path request to Intra-AS PCE R4 to compute a path
   within AS2 (In certain cases, the same router such R3 can assume
   both inter-AS and intra-AS path computation functions). R4 returns a
   PCECP path response to PCE2 with ASBR3 as the entry point to AS2
   from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCECP
   path request to PCE3 to compute the path segment across AS3,
   starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path
   response to PCE2 with the path segment ASBR7-R7. PCE2 then return
   path ASBR3-ASBR7-R7 to PCE1 which which, in turn turn, returns path ASBR1-ASBR3-ASBR7-R7 ASBR1-
   ASBR3-ASBR7-R7 to PCC R1.

   As described in the above scenario, in general, a PCC may contact an
   inter-AS PCE to request an inter-AS path, and that PCE may supply
   the path itself, or may solicit the services of other PCEs which
   may, themselves be inter-AS PCEs, or may be intra-AS PCEs with the
   responsibility for computing path segments within just one AS.

   This document describes the PCE Communication Protocol requirements
   for inter-AS path computation. That is, for PCCs to communicate path
   requests for inter-AS paths to a PCE, and for the PCE to respond. It
   also includes the requirements for PCEs to communicate inter-AS path
   requests and responses.

             Inter-AS        Inter-AS              Inter AS
        PCC <->PCE1<--------->PCE2<--------------->PCE3
         ::     ::             ::                   ::
         R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
         |      |        |            |        |           |
         |      |        |            |        |           |
         R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
                               ::
                             Intra-AS
                               PCE
         <==AS1=>        <====AS2======>       <=====AS3===>

      Figure 1 Inter and Intra-AS PCE Reference Model

4. Detailed PCECP Requirements for Inter-AS Computation

   This section discusses detailed PCECP requirements for inter-AS
   MPLS-TE and GMPLS. GMPLS LSPs. Depending on the deployment environment,
   some or all of the requirements described here may be utilized.
   Specifically, some requirements are more applicable to inter-
   provider inter-AS MPLS-TE and GMPLS operations than to intra-
   provider operations.

4.1. PCE Communication Protocol Requirements

   Requirements specific to inter-AS PCECP path computation requests
   and responses are discussed in Sections 4.1.1 and 4.1.2,
   respectively. the following sections.

4.1.1.  Requirements for path computation requests

   The following are inter-AS specific requirements for PCECP requests
   for path computation:

   1. [RFC4657] states the requirement for a priority level to be
   associated with each path computation request. This document does
   not change that requirement, but but, in addition addition, it MUST be possible
   for an inter-AS PCE to apply local policy to vary the priority of
   path computation requests received across AS borders. PCECP MAY
   include a mechanism to inform the requesting inter-AS PCE of the
   change in priority that was applied.

   2. A path computation request by an inter-AS PCE or a PCC to another
   inter-AS PCE MUST be able to specify the sequence of ASs ASes and/or
   ASBRs across the network by providing ASBRs and/or ASs ASes as hops in
   the desired path of the LSP to the destination. For instance, an
   inter-AS PCE MUST be be able to specify to the inter-AS PCE serving
   the neighboring AS a preferred ASBR for exiting to that AS and reach
   the destination. That is, where multiple ASBRs exist, the requester
   MUST be able to indicate a non-mandatory preference for one of them.

   3. PCECP MUST allow a requester to provide a list of Ass ASes and/or
   ASBRs to be excluded from the computed path.

   4. A PCECP path request from one inter-AS PCE to another MUST
   include the previous AS number in the path of the LSP to enable the
   correct application of local policy at the second inter-AS PCE.

   5. A path computation request from a PCC to an inter-AS PCE or an
   inter-AS PCE to another MUST be able to specify the need for
   protection against node, link, or SRLG failure using 1:1 detours or
   facility backup. It MUST be possible to request protection across
   all ASs ASes or across specific ASs. ASes.

   6. The disjoint path requirements specified in [RFC4657] are
   extended such that it MUST be possible to apply a constraint of AS-
   diversity in the computation of a set of two or more paths.

   7. A PCECP path computation request message MUST be able to identify
   the scope of diversified path computation to be end-to-end (i.e.,
   between the endpoints of the (G)MPLS-TE tunnel) or to be limited to
   a specific AS.

4.1.2. Requirements for path computation responses

   The following are inter-AS specific requirements for PCECresponses PCECP responses
   for path computation:

   1. A PCECP path computation response from one inter-AS PCE to
   another MUST be able to include both ASBRs and ASs ASes in the computed
   path to
maintain while preserving path segment and topology confidentiality.

   2. A PCECP path computation response from one inter-AS PCE to the
   requesting inter-AS PCE MUST be able to carry an identifier for a
   path segment it computes to preserve path segment and topology
   confidentiality. The objective of the identifier is to be included
   in the LSP signaling, whose mechanism is out of scope of this
   document, to be used for path expansion during LSP signaling.

   3. If a constraint for a desired ASBR (see Section 4.1.1,
   requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the
   PCE to notify the requester of that fact as an error in a positive path
   computation response.

   4. A PCECP path computation request from an inter-AS PCE to a requesting
   inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS
   path cost. Path cost normalization across ASs ASes is out of the scope of
   this document.

   5. A PCECP path computation response from an inter-AS PCE to a PCC
   SHOULD be able to carry the intra-AS cost of the path segment within
   the PCC AS.

   6. A PCECP path computation response MUST be able to identify
   diversified paths for the same (G)MPLS-TE LSP. End-to-end (i.e.,
   between the two endpoints of the (G)MPLS-TE tunnel) disjoint paths
   are paths that do not share nodes, links or SRLGs except for the LSP head-
end
   head-end and tail-end. In cases where diversified path segments are
   desired within one or more ASes, the disjoint path segments may
   share only the ASBRs of the first AS and the ASBR of the last AS
   across these ASes.

4.2.  Scalability and Performance Requirements Considerations

   PCECP design for use in the inter-AS case SHOULD consider the
   following criteria:

   - PCE message processing load.
   - Scalability as a function of the following parameters:
   - number of PCCs within the scope of an inter-AS PCE
   - number of intra-AS PCEs within the scope of an inter-AS PCE
   - number of peering inter-AS PCEs per inter-AS PCE
   - Added complexity caused by inter-AS features.

4.3. Management, Aliveness Detection, and Recovery Requirements  Management Considerations

   [RFC4657] specifies generic requirements for PCECP management. This
   document addresses new requirements that apply to inter-AS
    operations.
   perations.

   The PCECP MIB module MUST provide objects to control the behavior of
   PCECP in inter-AS applications, including applications.  They include the ASs ASes within the
   scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASs with whose inter-AS
    PCE(s) ASes to which
   the inter-AS requesting PCE MUST will or will not communicate, neighboring ASs with
    whose inter-AS PCEs the inter-AS PCE can communicate, confidentiality policies, and traffic engineering policies. Each
    of these two latter requirements SHOULD be applicable on inter-AS
    PCE-pair basis or neighboring AS basis (i.e., apply to all inter-
    AS PCEs that belong to a neighboring AS).
   policies, etc..

   The built-in diagnostic tools MUST enable failure detection and
   status checking of PCC/PCE-PCE PCECP. Diagnostic tools include
   statistics collection on the historical behavior of PCECP as
   specified in [RFC4657], but additionally it MUST be possible to
   analyze this statistics on a neighboring AS basis (i.e., across the
   inter-AS PCEs that belong to a neighboring AS).

   The MIB module MUST support trap functions when thresholds are
   crossed or when important events occur as stated in [RFC4657]. These
   thresholds SHOULD be specifiable per neighbor AS as well as per peer
   inter-AS PCE and traps should be accordingly generated.

   Basic liveliness detection for PCC/PCE-PCE communication PCECP is described in
   [RFC4657]. The  PCECP MIB module SHOULD allow control of liveliness
   check behavior by providing a liveliness message frequency MIB
   object and this frequency object SHOULD be specified per inter-AS
   PCE peer. In addition, there SHOULD be a MIB object that specifies
   the dead-interval as a multiplier of the liveliness message
   frequency so that if no liveliness message is received within that
   time from an inter-AS inter-A PCE, the inter-AS PCE is declared unreachable.

4.4.  Confidentiality

   Confidentiality mainly applies to inter-provider (inter-AS) PCE
   communication. It is about protecting the information exchanged
   between PCEs and about protecting the topology information within
   a provider's network. Confidentiality rules may also apply among
    ASs
   ASes under a single provider. Each SP will in most cases designate
   some PCEs for inter-AS MPLS-TE or GMPLS path computation within its
   own administrative domain and some other PCEs for inter-
    provider inter-provider
   inter-AS MPLS-TE or GMPLS path computation. Among the
   inter-provider-scoped inter-AS PCEs in each SP
   domain, there may also be a subset of the PCEs specifically enabled
   for path computation across a specific set of ASs ASes of different peer
   SPs.

   PCECP SHOULD allow an SP to hide from other SPs the set of hops
   within its own ASs ASes that are traversed by an inter-AS inter-
    provider inter-provider
   LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative
   domain environment, SPs may want to hide their network topologies
   for security or commercial reasons. Thus, for each inter-AS LSP path
   segment an inter-AS PCE computes, it may return to the requesting
   inter-AS PCE an inter-AS TE LSP path segment from its own ASs ASes
   without detailing the explicit intra-AS hops. As stated earlier,
   PCECP responses SHOULD be able to carry path-segment identifiers
   that replace the details of that path segment. The potential use of
   that identifier for path expansion, for instance, during LSP
   signaling is out of the scope of this document.

4.5.  Policy Controls Affecting inter-AS PCECP

   Section 5.2.2 of [RFC4216] discusses the policy control requirements
   for inter-AS RSVP-TE signaling at the AS boundaries for the
   enforcement of interconnect agreements, attribute/parameter
   translation and security hardening.

   This section discusses those policy control requirements that are
   similar to what are discussed in section 5.2.2 of [RFC4216], [RFC4216] for
   PCECP. Please note that SPs may still require policy controls during
   signaling of LSPs to enforce their bilateral or multi-
    lateral multi-lateral
   agreements at AS boundaries, but signaling is out of scope for this
   document.

4.5.1.  Inter-AS PCE Peering Policy Controls

   An inter-AS PCE sends path computation requests to its neighboring
   inter-AS PCEs, and an inter-AS PCE that receives such a request
   enforces policies applicable to the sender of the request. These
   policies may include rewriting some of the parameters, or rejecting
   requests based on parameter values. Such policies may be applied for
   PCEs belonging to different SPs or to PCEs responsible for ASs ASes
   within a single SP administrative domain. Parameters that might be
   subject to policy include bandwidth, setup/holding priority, Fast
   Reroute request, Differentiated Services Traffic Engineering (DS-TE)
   Class Type (CT), and others as specified in section 5.2.2.1 of
   [RFC4216].

   For path computation requests that are not compliant with locally
   configured policies, PCECP SHOULD enable a PCE to send an error
   message to the requesting PCC or PCE indicating that the request has
   been rejected because a specific parameter did not satisfy the local
   policy.

4.5.2.  Inter-AS PCE Reinterpretation Policies

   Each SP may have different definitions in its use of, for example,
   DS-TE TE classes. An inter-AS PCE receiving a path computation
   request needs to interpret the parameters and constraints and adapt
   them to the local environment. Specifically, a request constructed
   by a PCC or PCE in one AS may have parameters and constraints that
   should be interpreted differently by the receiving PCE that is in
   a different AS. A list of signaling parameters subject to policy
   reinterpretation at AS borders can be found in section 5.2.2.2 of
   [RFC4216], and the list for patch path computation request parameters and
   constraints is the same. In addition, the transit SPs along the
   inter-AS TE path may be GMPLS transport providers which may require
   reinterpretation of MPLS specific PCECP path request objects to
   enable path computation over a GMPLS network.

5.  Security Considerations

   Security concerns arise between any two communicating
   elements
   PCC/PCEs especially when the elements they belong to different administrative
   entities. In this case, there are security Security concerns that need to be addressed are for
   communication among inter-AS PCEs and other PCEs in a single SP
   administrative domain as well among inter-
   AS inter-AS PCEs under different SP
   administrative domains. [RFC4657] specifies requirements on PCECP to
   protect against spoofing, snooping and DoS attacks. These
   requirements become especially
   important critical in the multi-AS case. An

   Additionally, two aspects of operations specific to inter-AS PCE PCEs
   require careful security considerations.  There are two modes of
   determining peering PCEs across the AS boundary manual
   configuration and auto-discovery.  In the manual mode, mechanisms
   for securely exchanging authentication keys across SP boundaries
   MUST be able to
   authenticate a peering inter-AS defined.  For example, PCE registration MAY be served as a legitimate peer. Since
   inter-AS
   mechanism for securely exchanging authentication keys across SP
   boundaries.  In the auto-discovery mode, inter-as PCEs can be auto-discovered by an auto-
   discovered only if it is configured to participate in that discovery
   scope.  An inter-AS PCE and peering is not necessarily able to establish PCEP
   sessions are formed dynamically, with the discovered PCEs in its scope(s), it MUST be able
   to authenticate with the peering inter-AS PCE, therefore mechanisms
   for securely exchanging authentication keys across SP boundaries
   MUST also be defined. The
   autodiscovery defined in this case.  Furthermore, the auto-discovery
   process itself MUST also be authenticated.

6. IANA Considerations

   This document makes no requests for IANA action.

7. Acknowledgments

   We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and
   Jean Louis Le Roux for their useful comments and suggestions.

8. Authors' Addresses

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02451
   Email: nabil.n.bitar@verizon.com

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460, JAPAN
   Phone: +81-3-6678-3103
   Email: ke-kumaki@kddi.com

   Raymond Zhang
   BT INFONET Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90245 USA
   Email: Raymond_zhang@bt.infonet.com Raymond_zhang@bt.com

9. Normative References

   [RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic    Engineering
   Requirements", RFC 4216, November 2005.

   [RFC4655] Farrel, A., Vasseur, J.P, Vasseur & Ash, J., "A Path Computation Element (PCE)-Based (PCE)-
   Based Architecture", RFC 4655, 4755, August 2006.

   [RFC4657] J. Ash, J., J.L Le Roux, J.L, Roux et al., "PCE Communication Protocol
   Generic Requirements", RFC 4657, September 2006.

10. Informative References

   [INTERD-TESIG] Ayyangar, A., Ayyangar and Vasseur, J.P, "Inter domain GMPLS Traffic
   Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-
   domain-rsvp-te-03.txt, March draft-ietf-ccamp-inter-domain-
   rsvp-te-06.txt, April 2006 (Work in Progress)

   [LSP-STITCHING] Ayyangar A., Vasseur J,P., "Label Switched Path JP., "LSP Stitching with
   Generalized MPLS Traffic Engineering", draft-ietf-
   ccamp-lsp-stitching-03.txt, March 2006, TE", draft-ietf-ccamp-lsp-stitching-06.txt,
   September 2005, (work in progress).

   [RFC4206] Kompella, Kompella K., Rekhter, Rekhter Y., "Label switched Paths(LSP)
   Hierarchy with Generalized MPLS TE", RFC4206, October 2005.

   [INTERD-TE-PDPC] Vasseur,J.P, Ayyangar, A., Vasseur, Ayyangar and Zhang, R., "A Per-
   domain Per-domain path
   computation method for establishing computing Inter-domain Traffic Engineering
   (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter
   -domain-pd-path-comp-03.txt, August Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
   path-comp-05.txt, February 2006, (Work in Progress).

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   Disclaimer of Validity

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

   Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).  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.

   Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.