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

Versions: 00 01 02 03 04 05 RFC 6007

Network Working Group                                       I. Nishioka
Internet Draft                                                      NEC
Intended status: Informational                              Daniel King
Expires: March 2010                                  Old Dog Consulting
                                                     September 23, 2009


      The use of SVEC (Synchronization VECtor) list for Synchronized
                        dependent path computations


                   draft-ietf-pce-pcep-svec-list-03.txt


Abstract

   A Path Computation Element (PCE) performing dependent path
   computations, for instance calculating a diverse working and
   protected path not sharing common network points, would need to
   synchronize the computations in order to increase the probability of
   meeting the working and protected path diversity (or disjointness)
   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.



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





Nishioka & King         Expires March 23, 2010                 [Page 1]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   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 March 23, 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.



Table of Contents

   1. Terminology...................................................3
   2. Introduction..................................................3
   3. SVEC association scenarios....................................5
      3.1. Synchronized computation for diverse path requests.......5
      3.2. Synchronized computation for point-to-multipoint path
      requests......................................................6
   4. SVEC association..............................................7
      4.1. Associated SVECs.........................................7
      4.2. Non-associated SVECs.....................................7
   5. Processing of SVEC list.......................................8
      5.1. Single PCE, single domain environments...................8
      5.2. Multi-PCE, single domain environments....................9
      5.3. Single PCE, multi-domain environments....................9
   6. End-to-end diverse path computation...........................9
      6.1. Disjoint VSPT...........................................10
      6.2. Disjoint VSPT encoding..................................11
      6.3. Path computation procedure..............................12
   7. Manageability considerations.................................12
      7.1. Control of Function and Policy..........................12
      7.2. Information and Data Models, e.g. MIB modules...........12
      7.3. Liveness Detection and Monitoring.......................12
      7.4. Verifying Correct Operation.............................13
      7.5. Requirements on Other Protocols and Functional Components13



Nishioka & King         Expires March 23, 2010                 [Page 2]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


      7.6. Impact on Network Operation.............................13
   8. Security Considerations......................................13
   9. IANA Considerations..........................................13
   10. References..................................................13
      10.1. Normative References...................................13
      10.2. Informative References.................................14
   11 Acknowledgements .............................................14


1. Terminology

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

   GCO (Global Concurrent Optimization): A concurrent path computation
   application, defined in [RFC5557], 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), defined in this document, to indicate a set of
   synchronized or concurrent path computations.

   VSPT: Virtual Shortest Path Tree defined in [RFC5441].

   Disjoint VSPT : A set of VSPTs, defined in this document, to
   indicate a set of virtual diverse path tree.



2. Introduction

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

   [RFC5557] specifies the Global Concurrent Optimization (GCO) path
   computation mechanism.  The GCO application provides the capability
   to re-optimize a set of services within the network, in order to
   maximize efficient use of network resources. A single or set of
   objective functions (OFs) can be applied to a GCO. To compute a set
   of such traffic-engineered paths for the GCO application, PCEP
   supports the synchronous and dependent path computation requests



Nishioka & King         Expires March 23, 2010                 [Page 3]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   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 a set of independent and synchronized path computation
     requests,

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

   These are exclusive modes in a single SVEC. 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 may fail to meet the disjoint
   requirement altogether.

   Additionally, SVEC can be applied to end-to-end diverse path
   computations that traverse multiple domains. [RFC5441] 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 [RFC5521], 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, based on the PCE architecture [RFC4655]. The following
   scenarios are specifically described:

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




Nishioka & King         Expires March 23, 2010                 [Page 4]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   o Single domain, multi-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 for multiple sets of
   synchronized dependent path computation is also described in this
   document, as well as disjoint Virtual Shortest Path Tree (VSPT)
   encoding rule for end-to-end diverse path computation across domains.
   Path computation algorithms for these path computation scenarios are
   out of the scope of this document.

   The SVEC association and the disjoint VSPT described in this
   document do not require any extension to PCEP message and object
   formats, when computing a GCO for multiple or end-to-end 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 and disjoint VSPT are available to both single
   PCE path computation and multi-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

   A PCE may compute two or more point-to-point diverse paths,
   concurrently, in order to increase the probability of meeting
   primary and secondary path diversity (or disjointness) 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



Nishioka & King         Expires March 23, 2010                 [Page 5]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   requests. Note here that each diverse path request consists of
   primary, secondary, and tertiary and beyond path requests, in which
   all path requests are grouped with one SVEC association.

   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.

   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 Exclude Route Object (XRO) and/or Include Route
   Object (IRO) 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 their 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 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








Nishioka & King         Expires March 23, 2010                 [Page 6]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


4. SVEC association

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

4.1. Associated SVECs

   "Associated SVECs" means 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 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 the path
   computation requests are synchronized.

   Below is an example of associated SVECs. In this example, the first
   SVEC is associated with 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.



Nishioka & King         Expires March 23, 2010                 [Page 7]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   <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 a PCE 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 latter case, the PCE may start a SyncTimer as
   recommended in [RFC5440]. After receiving the entire set of path
   computation requests, the analysis for associated SVECs has to be
   started.

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







Nishioka & King         Expires March 23, 2010                 [Page 8]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


5.2. Multi-PCE, single domain environments

   Currently no mechanisms exist to manage co-ordination of dependent
   SVEC requests between multiple PCEs 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. Multi-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,
   the following procedure is applied. 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 all 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.



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, the BRPC procedure can be used.
   [RFC5441] 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 computes primary and
   secondary paths sequentially, using XRO, and its procedure is
   described in [RFC5521]. In this section, the synchronous approach is
   provided to compute primary and secondary paths simultaneously.



Nishioka & King         Expires March 23, 2010                 [Page 9]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


6.1. Disjoint VSPT

   The BRPC procedure constructs a VSPT to inform the enquiring PCE of
   potential paths to the destination node.

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

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

   Figure-1 shows an example network. Here, transit nodes in domains
   are not depicted, and PCE1 and PCE2 may be located in border nodes.
   In this network, there are three VSPTs for the potential set of
   diverse paths shown in Figure 2, when the primary path and secondary
   path are requested from S1 to D1. These VSPTs consist of a disjoint
   VSPT, which is replied to PCE1. When receiving the disjoint VSPT,
   PCE1 recognizes the disjoint request and disjoint VSPT information.
   PCE1 will then continue to process the request and compute the
   diverse path using the BRPC procedure [RFC5441]. The detail encoding
   for the disjoint VSPT is described in Section 6.2.





       Domain1          Domain2

       +----------+     +----------+

       |   PCE1   |     |   PCE2   |    S1: Source node

       |         BN1---BN4         |    D1: Destination node

       | S1      BN2---BN5      D1 |    BN1-BN6: Border nodes

       |         BN3---BN6         |

       +----------+     +----------+

   Figure-1: Example network for diverse path computation





Nishioka & King         Expires March 23, 2010                [Page 10]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


       VSPT1:            VSPT2:              VSPT3:

          D1                D1                 D1

          / \               / \                / \

       BN4   BN5         BN4   BN6          BN5   BN6

   Figure-2: Disjoint VSPT from PCE2 to PCE1

6.2. Disjoint VSPT encoding

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

   PCEP PCRep message returns a disjoint VSPT as <path list> for each
   RP object (Request Parameter object). The order of <path> in <path
   list> among <responses> implies a set of primary EROs (Explicit
   Route Objects) and secondary EROs.

   A PCE sending PCRep with a disjoint VSPT can reply with a partial
   disjoint VSPT based on its network operation policy, but the order
   of <path> in <path list> must be aligned correctly.

   If confidentiality is required between domains, path key mechanism
   defined in [RFC5520] is used for a disjoint VSPT.

   Detailed disjoint VSPT encoding in Figure-2 is shown below, when a
   primary path and a secondary path are requested from S1 to D1.

   o Request ID #1 (Primary)

      - ERO1 BN4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]

      - ERO2 BN4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]

      - ERO3 BN5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT3]

   O Request ID #2 (Secondary)

      - ERO4 BN5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]

      - ERO5 BN6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]

      - ERO6 BN6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT3]




Nishioka & King         Expires March 23, 2010                [Page 11]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009




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 [RFC5441]). During this procedure, a question 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 VSPT is a normal VSPT based
   on the shortest path computation.

   Note that the PCE will apply a suitable algorithm for computing
   disjoint VSPT. The 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].

7.1. Control of Function and Policy

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

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






Nishioka & King         Expires March 23, 2010                [Page 12]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


7.4. Verifying Correct Operation

   [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 any other protocol and functional
   components.

7.6. Impact on Network Operation

   [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 the
   procedures described in this document depends on 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.

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)," RFC4875, May 2007.



Nishioka & King         Expires March 23, 2010                [Page 13]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


   [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),"
             RFC5440, March. 2009.

   [RFC5441] 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," RFC5441, April 2009.

   [RFC5520] R. Bradford, JP. Vasseur, and A. Farrel, "Preserving
             Topology Confidentiality in Inter-Domain Path Computations
             Using a Path-Key-Based mechanism," RFC5520, April 2009.

   [RFC5521] E. Oki, T. Takeda and A. Farrel, "Extensions to the Path
             Computation Element Communication Protocol (PCEP) for
             Route Exclusions," RFC5521, April 2009.

   [RFC5557] 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," RFC5557, July 2009.

10.2. Informative References

   [ID.pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao,
             Q., King, D., "Extensions to the Path Computation Element
             Communication Protocol (PCEP) for Point-to-Multipoint
             Traffic Engineering Label Switched Paths," draft-ietf-pce-
             pcep-p2mp-extensions, work in progress, August, 2009.

   [ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability Sections
             in PCE Working Group Drafts," draft-ietf-pce-
             manageability-requirements, work in progress, July. 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, work in
             progress.txt, July. 2009.










Nishioka & King         Expires March 23, 2010                [Page 14]

Internet-Draft     draft-ietf-pce-pcep-svec-list-03      September 2009


11. Acknowledgements

     The authors would like to thank Julien Meuric and Filippo Cugini
     for their valuable comments



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
   United Kingdom

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

























Nishioka & King         Expires March 23, 2010                [Page 15]


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