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

Versions: 00 01 02 03 04 05 RFC 6007

Internet Engineering Task Force                              I. Nishioka
Internet-Draft                                                       NEC
Intended Status: Informational                               Daniel King
Created: March 9, 2009                                Old Dog Consulting
Expires: September 9, 2009


     The use of SVEC (Synchronization VECtor) list for Synchronized
                     dependent path computations
                draft-ietf-pce-pcep-svec-list-01.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.

Abstract

   A Path Computation Element (PCE) performing dependent path
   computations, for instance calculating a diverse working and
   protected path do not share common network points, would need to
   synchronize the computations in order to increase the probability of
   meeting the working and protected path disjoint objective and
   network resource optimization objective. When a PCE computes
   multiple sets of dependent path computation requests concurrently,
   it is required to use Synchronization VECtor (SVEC) list for
   association among the sets of dependent path computation requests.
   SVEC is also applicable to end-to-end diverse path computation
   across multiple domains. This document describes the usage of SVECs
   in the SVEC list and diverse path computation guideline, for the
   synchronized computation of dependent paths.





Nishioka & King                                                 [Page 1]

draft-ietf-pce-pcep-svec-list-01                              March 2009


Contents

   1. Terminology....................................................
   2. Introduction...................................................
   3. SVEC association scenarios.....................................
     3.1. Synchronized computation for diverse path requests.........
     3.2. Synchronized computation for point-to-multipoint
          path requests..............................................
   4. SVEC association...............................................
     4.1. Associated SVECs...........................................
     4.2. Non-associated SVECs.......................................
   5. Processing of SVEC list........................................
     5.1. Single PCE, single domain environments.....................
     5.2. Multi-PCE, single domain environments......................
     5.3. Single PCE, Multi-domain environments......................
   6. End-to-end diverse path computation............................
     6.1. Disjoint VSPTs.............................................
     6.2. Disjoint VSPTs Encoding....................................
     6.3. Path commutation in PCE....................................
   7. Manageability considerations...................................
     7.1. Control of Function and Police.............................
     7.2. Information and Data Models, e.g. MIB modules..............
     7.3. Liveness Detection and Monitoring..........................
     7.4. Verifying Correct Operation................................
     7.5. Requirements on Other Protocols and Functional Components..
     7.6. Impact on Network Operation................................
   8. Security Considerations........................................
   9. IANA Considerations............................................
   10. References....................................................
     10.1. Normative References......................................
     10.2. Informative References....................................
   11. Authors Addresses.............................................
   12. Intellectual Property Consideration...........................
   12. Disclaimer of Validity........................................
   13. Full Copyright Statement......................................















Nishioka & King                                                 [Page 2]

draft-ietf-pce-pcep-svec-list-01                              March 2009


1. Terminology

   This document uses PCE terminology defined in [RFC4655],
   [RFC4875], and [RFC5440].

   GCO (Global Concurrent Optimization): A
   concurrent path computation application where a set of TE paths is
   computed concurrently in order to efficiently utilize network
   resources.

   Associated SVECs: A group of multiple SVECs (Synchronization
   VECtors)to indicate a set of synchronized or concurrent path
   computations.

   VSPT: Virtual Shortest Path Tree


2. Introduction

   [RFC5440] describes the specifications for PCEP (Path Computation
   Element communication Protocol). PCEP facilitates the communication
   between a Path Computation Client(PCC) and a Path Computation Element
   (PCE), or between two PCEs based on PCE architecture [RFC4655]. PCEP
   interactions include path computation requests and path computation
   replies.

   [ID.pce-gco] specifies a global concurrent path computation
   application for the efficient use of network resources, called GCO,
   based on required objective functions (OFs). To compute a set of
   traffic-engineered paths for the GCO application, PCEP supports the
   synchronous and dependent path computation requests required in
   [RFC4657]. When a PCC or PCE sends such path computation requests to
   a PCE, Synchronization VECtor (SVEC) allows the PCC or PCE to
   specify a list of multiple path computation requests that must be
   synchronized along with a potential dependency.[RFC5440] defines
   two synchronous path computation modes using SVEC.

   o  Bundle of a set of independent and synchronized path computation
       requests.

   o  Bundle of a set of dependent and synchronized path computation
       requests.








Nishioka & King                                                 [Page 3]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   These are exclusive modes. If one of the dependency flags (i.e.
   Node, Link or Shared Risk Link Groups (SRLG) diverse flags) in a SVEC
   is set, the SVEC indicates a set of synchronous path computation
   requests with a dependency. In order to be synchronized among
   multiple sets of path computation requests with a dependency, it is
   necessary to use other SVECs.

   It is important for the PCE, when performing path computations, to
   synchronize any path computation requests with a dependency. For
   example, consider a protected end-to-end service. Two diverse path
   computation requests are needed to compute the disjointed working and
   protected paths. If the diverse path requests are computed
   sequentially, fulfillment of the initial diverse path computation
   without consideration of the second diverse path computation and
   disjoint constraint, may result in the PCE providing sub-optimal
   results for the second one, or fail to meet the disjoint requirement
   altogether.

   Additionally SVEC can be applied to an end-to-end diverse path
   computation that traverse multiple domains. [ID.pce-brpc] describes
   two approaches, synchronous (i.e. simultaneous) and 2-step
   approaches, for the end-to-end diverse path computation across a
   chain of domains. The path computation procedure is specified for
   the 2-step approaches in [ID.xro], but no guidelines are provided
   for a synchronous approach.

   This document defines the handling of synchronous path computation
   for PCE and multiple set of path computation request with a
   dependency. The following scenarios are specifically described:

   o  Single domain, single PCE, dependent and synchronized path
      computation request.

   o  Single domain, multiple-PCE, dependent and synchronized path
      computation request.

   o  Multi-domain, dependent and synchronized path computation
       request, including end-to-end diverse path computation.

   The association among multiple SVECs and the processing rules to
   support multiple sets of synchronized dependent path computation
   requests is also described in this document. Path computation
   algorithms for the associated path computation requests are out of
   scope in this document.






Nishioka & King                                                 [Page 4]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   The SVEC association and its processing rule do not require any
   extension to PCEP message and object formats, when computing a GCO
   for multiple diverse paths. In addition, the use of multiple SVECs is
   not restricted to only SRLG, Node and Link diversity currently
   defined in the SVEC object, [RFC5440], but is also available for
   other dependent path computation requests.

   The SVEC association is available to both multiple PCE path
   computations as well as a single PCE path computation.


3. SVEC association scenarios

   This section clarifies several path computation scenarios, in which
   SVEC association can be applied. Also, any combination of scenarios
   described in this section could be applicable.

3.1. Synchronized computation for diverse path requests

   When computing two or more point-to-point diverse paths, a PCE may
   compute these diverse paths concurrently, in order to increase the
   probability of meeting primary and secondary path disjoint objective
   and network resource optimization objective.

   Two scenarios can be considered for the SVEC association of
   point-to-point diverse paths.

   o Two or more end-to-end diverse paths

   When concurrent path computation of two or more end-to-end diverse
   paths is requested, SVEC association is needed among diverse path
   requests. Note here that each diverse path request consists of
   primary, secondary, and etc., in which are grouped with one SVEC.

   Example of this scenario: When there are two associated end-to-end
   diverse path requests with primary and secondary, all requests must
   be computed in a synchronized manner.

   o End-to-end primary path and its segmented secondary paths

   When concurrent path computation of an end-to-end primary path and
   several segmented secondary paths is requested, SVEC association is
   needed among primary/segmented secondary-1 request, primary/segmented
   secondary-2 request, and etc.






Nishioka & King                                                 [Page 5]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   In this scenario, we assume that the primary path may be pre-
   computed, which is used for specifying the segment for secondary
   paths. Otherwise, segment for secondary path requests are specified
   in advance, by using XRO and/or IOR constraints in the primary
   request.

3.2. Synchronized computation for point-to-multipoint path requests

   For point-to-multipoint path requests, SVEC association can be
   applied.

   o Two or more point-to-multipoint paths

   If a point-to-multipoint paths request is represented as a set of
   point-to-point paths [ID-pce-p2mp-ext], two or more point-to-
   multipoint path computation requests can be associated for concurrent
   path computation, in order to optimize network resources.

  o point-to-multipoint paths and its secondary paths

   When concurrent path computation of a point-to-multipoint path and
   its point-to-point secondary paths [RFC4875], or a point-to-
   multipoint path and its point-to-multipoint secondary paths
   [ID.p2mp-te-bypass] is requested, SVEC association is needed among
   these requests.

   In this scenario, we use the same assumption as "end-to-end primary
   path and its segmented secondary paths scenario" in section 3.1


4. SVEC association

   This section describes the associations among SVECs in a SVEC list.

4.1. Associated SVECs

   Associated SVECs mean that there are relationships among multiple
   SVECs. Request-IDs in the SVEC objects are used to indicate the
   association among SVEC objects. If the same request-IDs exist in more
   than two SVECs, this indicates associated SVECs. When associating
   among SVECs, only one request-ID may in the SVEC object may be
   contained in the other SVEC object. This contributes to reducing the
   message size of PCEP request. Even in this case, all of the path
   computation requests are synchronized.






  Nishioka & King                                               [Page 6]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   Below is an example of associated SVECs. In this example, the first
   SVEC is associating the other SVECs, and path computation requests
   from Request-ID#1 to Request-ID#Z must be synchronized.

   <SVEC-list>

       <SVEC> without dependency flags
       Request-ID #1, Request-ID #3, ..., Request-ID #X
       <SVEC> with one or more dependency flags
       Request-ID #1, Request-ID #2
       <SVEC> with one or more dependency flags
       Request-ID #3, Request-ID #4
       ........
       <SVEC> without dependency flag
       Request-ID #X, Request-ID #Y, Request-ID #Z

4.2. Non-associated SVECs

   Non-associated SVECs mean that there are no relationships among
   SVECs. If SVEC objects in PECP request messages do not have the same
   request-ID, the relationship among these SVECs is not associated.
   Below is an example of non-associated SVECs that does not contain any
   same request-IDs.

   <SVEC-list>

       <SVEC> with one or more dependency flags
       Request-ID #1, Request-ID #2
       <SVEC> with one or more dependency flags
       Request-ID #3, Request-ID #4
       ........
       <SVEC> without dependency flags
       Request-ID #X, Request-ID #Y, Request-ID #Z


5. Processing of SVEC list

5.1. Single PCE, single domain environments

   When PCEP receives PCReq messages with more than two SVEC objects in
   the SVEC list, PCEP has to first check the request-IDs in all SVEC
   objects in order to identify any associations among them. The SVEC
   objects may be received in a single or multiple PCReq message(s). In
   the later case, the PCE may start a SyncTimer as recommended in
   [RFC5440]. After receiving the whole path computation requests,
   the analysis for associated SVECs has to be started.




Nishioka & King                                                 [Page 7]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   If there are no matching request-IDs in the different SVEC objects,
   these SVEC objects are not associated, and then each set of path
   computation requests in the non-associated SVEC objects has to be
   computed separately.

   If there are matching request-IDs in the different SVEC objects,
   these SVEC objects are associated, and then all path computation
   requests in the associated SVEC objects are treated in a synchronous
   manner for GCO application.

   If the PCE does not have capability to handle the associated SVEC
   objects, it may send a PCErr message with Error-Type="Capability not
   supported".

5.2. Multi-PCE, single domain environments

   Currently no mechanisms exist to manage co-ordination of dependent
   SVEC requests between multiple PCE`s in the same domain. If a PCC
   sends a path computation request to a PCE and then sends a second
   service path computation request, which is required to be disjoint
   from the first service, and this request is sent to a different PCE
   in the domain, no SVEC object correlation function between the PCEs
   is currently available. Equally, associated SVECs are not sent to the
   different PCEs in the domain.

5.3. Single PCE, Multi-domain environments

   When multiple PCEs located in separate domains are used to
   concurrently compute an end-to-end diverse path across multiple
   domains, additional processing may be required. The path computation
   process for the end-to-end diverse path is described in Section 6.

   Furthermore, if the PCReq message contains multiple associated SVEC
   objects and these SVEC objects contain path computation requests that
   will be sent to the next PCE along the path computation chain.
   Intermediate PCEs receiving such PCReq messages may re-construct
   associations among SVEC objects, and then send PCReq messages to
   corresponding PCEs located in neighboring domains. If the associated
   SVECs are re-constructed at the intermediate PCE, the PCE must not
   start path computation until all PCRep messages have been received
   from neighbor PCEs. In addition, it is not recommended that SVEC
   objects coming from different PCReq messages are re-constructed. This
   may contribute to resource optimization from network operator`s point
   of view, but it is unrealistic in the case of multiple PCE path
   computation scenarios.





Nishioka & King                                                 [Page 8]

draft-ietf-pce-pcep-svec-list-01                              March 2009


6. End-to-end diverse path computation

   End-to-end diverse path is a set of primary path and secondary paths,
   which do not share common network resources across domains. To
   compute the end-to-end diverse path, BRPC procedure can be used.
   [ID.pce-brpc] describes two approaches, synchronous (i.e.
   simultaneous)and 2-step approaches, for the end-to-end diverse
   path computation across a chain of domains. The 2-step approach is
   described in [ID.xro]. This section provides how to compute end-to
   -end diverse path in the synchronous approach.

6.1. Disjoint VSPTs

   BRPC procedure constructs a VSPT (virtual shortest path tree) to
   inform the enquiring PCE of potential paths to the destination node.

   In the end-to-end diverse path computation, disjoint information
   among the potential paths must be preserved in the VSPT to ensure end
   -to-end disjoint path. In order to preserve disjoint information,
   disjoint VSPTs are sent in the PCEP PCRep message.

   A definition of the disjoint VSPTs is a collection of VSPTs, in which
   each VSPT contains a potential set of primary and secondary paths.

   Figure 1 is an example network and its disjoint VSPTs when primary
   path and secondary path are requested. Here, transit nodes within
   domains are not depicted, and PCE1 and PCE2 may be embedded in
   boarder nodes.

   Example network:

       Domain1          Domain2
       +----------+     +----------+
       |   PCE1   |     |   PCE2   |    S1: Source node
       |         BN1---BN4         |    D1: Destination node
       | S1      BN2---BR5      D1 |    BN1-BN6: Border nodes
       |         BN3---BN6         |
       |          |     |          |
       +----------+     +----------+

       VSPTs from PCE2:

       VSPT1;            VSPT2;              VSPT3;
          D1                D1                 D1
          / \               / \                / \
       BR4   BR5         BR4   BR6          BR5   BR6

             Figure 1: An example of diverse path computation


Nishioka & King                                                 [Page 9]

draft-ietf-pce-pcep-svec-list-01                              March 2009


6.2. Disjoint VSPT Encoding

   Encoding for disjoint VSPTs follows the definition of PCEP message
   encoding in [RFC5440].

   PCEP PCRep message returns disjoint VSPTs as <path list> for each RP
   object. The order of <path> in <path list> among <responses> implies
   a set of primary EROs and secondary EROs.

   Below shows simple example in Figure 1 if a primary path and a
   secondary path are requested.

   o Request ID #1 (Primary)
    - ERO1 BR4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]
    - ERO2 BR4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]
    - ERO3 BR5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT3]

   O Request ID #2 (Secondary)
    - ERO4 BR5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]
    - ERO5 BR6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]
    - ERO6 BR6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]

6.3. Path computation procedure

   For end-to-end diverse path computation, the same mode of operation
   as BRPC procedure can be applied (i.e. Step 1 to Step n in Section
   4.2 [ID.pce-brpc]). During this procedure, a questions is how to
   recognize disjoint VSPTs.

   The recognition of disjoint VSPT is achieved by the PCE sending PCreq
   to its neighbor PCE which maintains the path computation request
   (PCReq) information. If PCreq has one or more SVEC object(s) with the
   appropriate diverse flags, the received PCrep will contain the
   disjoint VSPT. If not, the received VSTP is a normal VSPT based on
   the shortest path computation.

   Note that the PCE can apply a suitable algorithm for computing
   disjoint VSPT. Selection and application of the appropriate
   algorithm is out of scope in this draft.


7. Manageability considerations

   This section describes manageability considerations specified in
   [ID.pce-mngabl-reqs].





Nishioka & King                                                [Page 10]

draft-ietf-pce-pcep-svec-list-01                              March 2009


7.1. Control of Function and Policy

   In addition to section 8.1 to [RFC5440], PCEP implementation
   should allow the configuration of association among SVECs on PCCs.

   o  the capability to configure SVEC association.

7.2. Information and Data Models, e.g. MIB modules

   There are no additional parameters for MIB modules.

7.3. Liveness Detection and Monitoring

   The associated SVEC in this document allows PCEs to compute optimal
   sets of diverse path. This type of path computation may require more
   time to obtain its results. Therefore, it is recommended for PCEP to
   support PCE monitoring mechanism specified in [ID.pce-monitor].

7.4. Verifying Correct Operation

   Section 8.4 in [RFC5440] provides the sufficient descriptions
   for this document. So, there are no additional considerations.

7.5. Requirements on Other Protocols and Functional Components

   This document does not require anything on other protocol and
   functional components.

7.6. Impact on Network Operation

   Section 8.6 in [RFC5440] provides the sufficient descriptions
   for this document. So, there are no additional considerations.


8. Security Considerations

   This document defines the usage of SVEC list, and does not have any
   extensions for PCEP protocol. Therefore the security of this document
   depends on that of PCEP protocol.


9. IANA Considerations

   This document has no specific extension for PCEP messages, objects
   and its parameters and does not require any registry assignment





Nishioka & King                                                [Page 11]

draft-ietf-pce-pcep-svec-list-01                              March 2009


10. References

10.1. Normative References

   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture," RFC 4655, September
             2006.

   [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
             Communication Protocol Generic Requirements," RFC 4757,
             September 2006.

   [RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, "
             Extensions to Resource Reservation Protocol - Traffic
             Engineering (RSVP-TE) for Point-to-Multipoint TE Label
             Switched Paths (LSPs)," RFCCC4875, May, 2007.

10.2. Informative References

   [RFC5440]     Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
                 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
                 "Path Computation Element (PCE) Communication Protocol
                 (PCEP)", RFC 5440, March 2009.

   [ID.pce-gco]  Y. Lee, JL. Le Roux, D. King and E. Oki, "Path
                 Computation Element Communication Protocol (PCECP)
                 Requirements and Protocol Extensions In Support of
                 Global Concurrent Optimization," draft-ietf-pce-global-
                 concurrent-optimization-08 Work in progress, Jan. 2009.

   [ID.pce-brpc] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A
                 Backward Recursive PCE-based Computation (BRPC)
                 Procedure To Compute Shortest Constrained Inter-
                 domain Traffic Engineering Label Switched Paths,"
                 draft-ietf-pce-brpc-09, Work in progress, April 2008.

   [ID.xro]      E. Oki, T. Takeda and A. Farrel, "Extensions to the
                 Path Computation Element Communication Protocol (PCEP)
                 for Route Exclusions," draft-ietf-pce-pcep-xro-06,
                 Work in progress, July 2008.

   [ID-pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao,
                 Q., King, D.,"draft-ietf-pce-pcep-p2mp-extensions-
                 01,work in progress, October , 2008.

   [ID.p2mp-te-bypass] JL. Le Roux, R. Aggarwal, J.P. Vasseur,
                 and M. Vigoureux, "P2MP MPLS-TE Fast
                 Reroute with P2MP Bypass Tunnels," draft-
                 ietf-mpls-p2mp-te-bypass-02," Work in progress, Mar.
                 2008.

Nishioka & King                                                [Page 12]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   [ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability
                 Sections in PCE Working
                 Group Drafts," draft-ietf-pce-manageability-
                 requirements-06 Work in progress, Jan. 2009.

   [ID.pce-monitor] JP. Vasseur, JL. Le Roux and Y. Ikejiri, "A set of
                 monitoring tools for Path Computation Element based
                 Architecture," draft-ietf-pce-monitoring-04 Work in
                 progress, Jan. 2009.


11. Authors' Addresses

   Itaru Nishioka
   NEC Corp.
   1753 Shimonumabe,
   Kawasaki, 211-8555,
   Japan

   Phone: +81 44 396 3287
   Email: i-nishioka@cb.jp.nec.com

   Daniel King
   Old Dog Consulting
   UK

   Phone: +44 7790 775187
   Email: daniel@olddog.co.uk


12. Intellectual Property Consideration

   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




Nishioka & King                                                [Page 13]

draft-ietf-pce-pcep-svec-list-01                              March 2009


   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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

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

14. Full Copyright Statement

   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.




Nishioka & King                                                [Page 14]


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