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

Versions: 00 02 03 05

Network Working Group                               JP Vasseur (editor)
Internet Draft                                          Carol Iturralde
Document: draft-vasseur-mpls-computation-rsvp-       Cisco Systems, Inc
05.txt

IETF Internet Draft                                       Raymond Zhang
Expires: January, 2005                                 Infonet Services
                                                            Corporation
                                                           Xavier Vinet
                                                                 Equant
                                                      Satoru Matsushima
                                                          Japan Telecom
                                                             Alia Atlas
                                                           Avici System

                                                              July 2004




             RSVP Path computation request and reply messages


                draft-vasseur-mpls-computation-rsvp-05.txt







Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or IPR claims of which I am aware have been disclosed, and
   any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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.


Vasseur et al.                                                      1

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004



Abstract

   This document describes extensions to RSVP-TE to support a new
   message type called a ôPath computationö message.  This message is to
   be used between an LSR and a Path Computation Element (PCE), which
   may be an LSR or a centralized path computation tool. An RSVP Path
   Computation Request message is used by the head-end LSR to send its
   request to the PCE. The PCE in turn sends an RSVP Path Computation
   Reply message containing either:
        - a positive reply, containing one or more paths, if the request
        can be satisfied.
        - a negative reply if no path obeying the requested constraints
        can be found. The PCE may also optionally suggest new constraint
        values for which one or several paths could be found.
   There are many situations where a PCE may be used. A typical example
   is in the context of Inter-area MPLS TE. A head-end LSR could request
   that a PCE compute one or more paths obeying a specified set of
   constraints for a TE LSP spanning multiple areas. The PCE could be a
   centralized path computation Element or an LSR such as an ABR or an
   ASBR. Another example is the use of a PCE to compute diversely routed
   paths between two end points.  This may be useful in the context of
   MPLS TE LSP Path protection or GMPLS LSP Path protection. The
   computation of Multi-constraints paths requires intensive CPU
   resources, and may be yet another usage example. Lastly, those
   protocol extensions could be used as a ôUNIö like protocol between a
   CE (Customer Edge equipment) and a PE (Provider Edge equipment) where
   the CE is not part of the PEÆs IGP domain.


























Vasseur, et al                                                 Page 2

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004


   Table of contents

   1. Introduction --------------------------------------------------- 4
   2. Terminology ---------------------------------------------------- 4
   3. RSVP Path computation Request/Reply messages ------------------- 5
   3.1 RSVP Path Computation Request message format ------------------ 6
   3.2 RSVP Path Computation Reply message format -------------------- 7
   3.3 New RSVP objects used in Path computation messages ------------ 8
   3.3.1 REQUEST-ID Object ------------------------------------------- 8
   3.3.2 METRIC-TYPE ------------------------------------------------ 10
   3.3.3 PATH_COST -------------------------------------------------- 12
   3.3.4 NO-PATH-AVAILABLE object ----------------------------------- 14
   3.3.5 NB-PATH object --------------------------------------------- 15
   3.3.6 PATH-CORRELATED Object ------------------------------------- 22
   3.3.7 MIN-BW object ---------------------------------------------- 22
   3.3.8 LSP-BANDWIDTH object --------------------------------------- 23
   3.3.9 EXCLUDE-ELEMENT object ------------------------------------- 25
   3.3.10 OPAQUE object --------------------------------------------- 26
   4. Definition of the ôclosest possible solutionö------------------ 27
   5. Path Computation Server discovery ----------------------------- 27
   6. Acknowledgment ------------------------------------------------ 27
   7. Security Considerations --------------------------------------- 28
   8. References ---------------------------------------------------- 28
   9. Authors' Addresses -------------------------------------------- 29






























Vasseur, et al                                                 Page 3

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

1. Introduction

   As mentioned in the abstract, there are various situations where a
   Path Computation Client may need to compute one or more paths obeying
   a specified set of constraints, and may ask a PCE to perform this
   task. This exchange does not allocate any resources, it is simply a
   mechanism by which a client may send a path computation request to a
   server and get in return a reply (positive or negative). Note also
   this is not related to policy.

   LetÆs briefly describe a typical sequence of events:
   1) the Path Computation Client (an LSR) sends a request to the PCE
   (LSR, centralized path computation tool,à). A Path Computation
   Request message will be sent containing:
        a) already specified objects defined in [RSVP-TE] characterizing
        the request, and
        b) new objects defined in the present draft related to the
        request.

   2) the Path Computation Request message is sent to the PCE

   3) the PCE processes the request and sends either:
        a) a positive reply to the client containing one or more
        computed paths that obey the requested constraints,
        b) a negative reply to the client, which, if requested by the
        PCC, can optionally contain alternate constraints values for
        which the request would have been positive and the computed
        paths which meet the alternate constraints values.

   4) the Path Computation Client can in turn:
        a) If the reply is positive
             i) If the client has sent the same request to several
             servers in parallel
                1. Compare the reply with other replies it received from
                other servers.
                2. Select the preferred path.
               Otherwise, select the returned path.
             ii) Establish the LSP using RSVP with extensions as defined
             in [RSVP-TE].

        b) If the reply is negative
             i) If the alternative constraints values given by the
             PCE are acceptable, consider the computed path sent with
             the replies from other servers to select the best path.
             ii) Otherwise, send another request to the PCE with the
             new constraints (potentially taking into account the
             returned suggested constraints values by the server, if
             any).
             iii) Wait for an answer from other servers, if any.
             iv) Go to 4).





Vasseur, et al                                                 Page 4

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

2. Terminology

   Terminology used in this draft

   PCE: Path Computation Element (e.g. ABR, ASBR, UNIX machine)

   PCC: Path Computation Client (any LSR) requesting a path computation
   from the Path Computation Element.


3. RSVP Path computation Request/Reply messages

   As defined in rfc2205, an RSVP message consists of a common header
   followed by a body consisting of a variable number of variable-
   length, typed "objects". As a reminder, the common header format is:

            0             1              2             3
            +-------------+-------------+-------------+-------------+
            | Vers | Flags|  Msg Type   |       RSVP Checksum       |
            +-------------+-------------+-------------+-------------+
            |  Send_TTL   | (Reserved)  |        RSVP Length        |
            +-------------+-------------+-------------+-------------+

   See RFC2205 for details.

   One new RSVP message type is defined in this draft: a Path
   Computation Message.  The message type is [TBD by IANA].

   The Flags field is used to identify whether the message is a path
   computation request or a reply.  Each has different contents, defined
   below. Flags 0x01-0x8 are reserved. A request has its flag set to
   [TBD by IANA] and a reply has its flag set to [TBD by IANA].

   An RSVP Path Computation Request message is sent by an LSR to request
   one or more path computations of a PCE obeying a set of specified
   constraints. The objects carried in this message may include those
   defined in [RSVP] and [RSVP-TE], new objects defined in this draft,
   as well as other objects that may be defined in the future
   characterizing, for instance, the constraints of the LSP for which
   one or several paths should be computed. The IP source address is the
   IP address of the requesting LSR and the IP destination address is
   the IP address of the PCE.

   An RSVP Path Computation Reply message is sent by the PCE to the
   requesting LSR (PCC) to return one or more computed Paths, if any.
   The object(s) carried will include one or more EROs (Explicit Route
   Objects), as defined in [RSVP-TE], plus additional objects defined in
   this draft. If no path can be found, the PCE reply will be negative.
   An ERROR-SPEC object will be carried in the reply, and optionally
   additional information as defined in section 3.3.4. The source IP
   address will be the IP address of the PCE and the destination IP
   address will be the IP address of the PCC.

   RSVP Path computation messages are sent without the router alert
   option. Path computation messages should be sent in reliable mode as
Vasseur, et al                                                 Page 5

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   defined in RFC2961. This allows an acknowledgment message to be used
   to acknowledge the receipt of a Path computation message (request and
   reply). In case of message loss, the message will be fast
   retransmitted as defined in RFC2961. Note that the DSCP field of the
   IP packet carrying an RSVP Path Computation message may be set
   appropriately to provide the appropriate quality of service delivery
   to the packet.

   The same Path Computation Request may be sent to several PCEs. In
   this case, the decision process used by the PCC to select from among
   (possibly) multiple replies is a local decision and is beyond the
   scope of this document.

3.1 RSVP Path Computation Request Message Format

   The Path Computation Request message format is as follows:

   The Flags field of the common header must be set to [TBD] by IANA to
   identify a request.

   <Path computation request> ::=  <Common Header> [ <INTEGRITY> ]
                                   [[<MESSAGE_ID_ACK> |
                                   <MESSAGE_ID_NACK>] ... ]
                                   [<MESSAGE_ID>]
                                   <SESSION>
                                   <REQUEST-ID>
                                   [<NB-PATH>]
                                   [<EXPLICIT_ROUTE>]
                                   [<METRIC-TYPE>]
                                   [<MIN-BW>]
                                   [<EXCLUDE-ELEMENT>]
                                   [<SESSION_ATTRIBUTE>]
                                   [<POLICY_DATA> ... ]
                                   <sender descriptor>

         <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                                  [ <ADSPEC> ]
                                  [ <RECORD_ROUTE> ]

   One new (mandatory) object is defined: REQUEST-ID to identify the
   request. This object is also used to indicate the requestÆs priority
   and LSP type. See 3.3.1 for details.

   The SESSION_ATTRIBUTE object (class=207, C-type=1) allows carrying
   setup and holding priorities, resource affinities, etc.  Other
   constraints may also be carried in the Path Computation message. Note
   that any other constraints that could be defined in the future can be
   expressed as new objects.

   The ERO object may also be present in the RSVP Path Computation
   Request.  The reason is that the head-end may want to specify some
   LSR(s) that the LSP must traverse.  At least one sub-object in the
   ERO must have its L flag bit set to 1, referring to a loose hop. Note
   that if the path computation request is related to a reoptimization,
   a second ERO object specifying the existing TE LSP path will be
Vasseur, et al                                                 Page 6

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   inserted to avoid double bandwidth accounting. This ERO will be
   easily differentiated from the ERO related to the path constraint as
   it just contains strict hops subobjects. It should be placed after
   the path constraints ERO.

   The optional METRIC-TYPE object allows the PCC to specify the metric
   the PCE must use in its CSPF to select the ôbestö path obeying the
   requested constraints. See the METRIC-TYPE object definition in 3.3.2
   for more details.

   The optional NB-PATH object (defined in 3.3.5) allows the PCC to
   specify the number of requested paths to the PCE for the specific set
   of constraints specified in the RSVP Path Computation Request
   message.


3.2 RSVP Path Computation Reply message format

   The Path Computation Reply message format is as follows:

   The Flags field of the common header must be set to [TBD by IANA] to
   identify a Path Computation Reply.

   <Path Computation Reply>::=<Common Header> [ <INTEGRITY> ]
                              [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                              [ <MESSAGE_ID> ]
                              <REQUEST-ID>
                              [ <NB-PATH> ]
                              [<EXPLICIT_ROUTE> [<PATH-COST>] [<LSP-
                               BANDWIDTH>] ] ...
                              [ <ERROR_SPEC>]
                              [<NO-PATH-AVAILABLE] ]
                              [ <POLICY_DATA> ... ]

   The REQUEST-ID is the same REQUEST-ID (contains the same value) as
   the one contained in the Path Computation Request to which the reply
   corresponds.

   In case of a negative reply (no path obeying the constraints can be
   found), the PCE must send a reply containing an ERROR_SPEC object
   with:
        - ERROR_CODE [TBD by IANA] and ERROR_VALUE [TBD by IANA]
        - ôIpv4 Error Node addressö (ôIpv6 Error Node addressö) set to
        the Ipv4 (Ipv6) address of the PCE.  This must be the same IP
        address as was used in the Path Computation Request message.

   There are various reasons why the PCE may not be able to satisfy the
   request:
        - the Path Computation Request message was not valid (ôunknown
        object class (error_code=23, ôunknown object C-type
        (error_code=14), ôRouting problemö (error_code=24), à), à See
        [RSVP] and [RSVP-TE] for details. In such a situation, the PCE
        must send the Path Computation Reply message without any ERO
        objects and without NO-PATH-AVAILABLE object.

Vasseur, et al                                                 Page 7

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

        - No path can be found obeying the set of requested constraints.
        If no path can be found by the PCE for the specified
        constraints, and only in this situation, a NO-PATH-AVAILABLE
        object may be inserted into the RSVP Path Computation Reply
        message sent by the PCE. This object (defined in section 3.3.4)
        is optional and may specify the constraint(s) that explain(s)
        why no path has been found. In addition, the PCE may use the NO-
        PATH-AVAILABLE object to suggest new constraint values for which
        a path can be found.
                a) If the PCC did not specify that a less-constrainted
                path is of interest (L flag of the REQUEST-ID object set
                to 0), the Path Computation Reply message must not
                contain any ERO objects.
                b) If the PCC specified that a less-constrainted path
                is of interest (L flag of the REQUEST-ID object set to
                1), then the PCE can optionally use the NO-PATH-
                AVAILABLE object to indicate new constraint values for
                which the included path could be found.  This is a
                circumstance where the Path Computation Reply message
                can contain one or more EROs.

   Note that a Path Computation Reply message may contain several EROs
   if and only if several paths have been requested by the LSR in its
   Path Computation Request message using the NB-PATH object (see
   3.3.5).

   Moreover, multiple replies may be combined in the same Path
   Computation Reply message.  This is done using a list of EROs, each
   following its corresponding REQUEST-ID as shown in the example below.

   A reply should not be delayed in order to bundle several path
   computation results for requests whose priority REQUEST-ID field (see
   3.3.1) has been set to ôhighö.

   As an example, if a PCC sends several requests:
        - L low priority requests with REQUEST-ID = R(i) I=1 à L
        - P high priority requests with REQUEST-ID = RÆ(i) I=1 à P
   Then the PCE MUST reply to every high priority request as soon as the
   computation result is completed. On the other hand, the low priority
   request results could be bundled in the SAME Path Computation Reply
   message using the following format: <REQUEST-ID R(1)> <ERO(1)>
   <REQUEST-ID R(2)> <ERO(2)> <ERO (2)> à <REQUEST-ID R(L)> <ERO(L)>.
   If no path can be found for a specific request, an individual
   negative Path Computation Reply message must be sent for the
   corresponding request.

   A PATH-COST object (defined 3.3.3) may be inserted and follow each
   ERO object if and only if the PCC has requested the PCE to provide
   the cost of each computed path in its Path Computation Request
   message (the ôCö bit in the flag field of the REQUEST-ID object
   present in the path computation request must be set).


3.3 New RSVP objects used in Path Computation messages

Vasseur, et al                                                 Page 8

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

3.3.1 REQUEST-ID Object

   The REQUEST-ID object must be used in every Path Computation Request
   message and in every Path Computation Reply message.

   REQUEST-ID Class-Num is [TBD]
   REQUEST-ID C-Type is [TBD]

   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | |L|B|R|T|C|Pri|                    Epoch                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Request-ID-number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags: 6 bits

   C (Cost): when set, the PCC does require the PCE to indicate the
   pathÆs computed cost in its reply.

   T (Type of reply: Partial or complete): In a request, when set, this
   specifies the returned path must be complete (set of directly
   connected LSRs). When this bit is cleared, the returned path may be
   complete or partial (set of loose hops). In a reply, when set, this
   indicates the returned path is complete. If the returned path is
   partial, this bit is cleared.

   R (Reoptimization): when set, the PCC specifies that the request
   concerns a reoptimization (a new path computation for a TE LSP
   already in place). This requires for the PCC to provide the path of
   the TE LSP in place in the path computation request to avoid double
   bandwidth counting. The ERO must be formed of strict hops only. If
   the PCC has previously requested a Partial ERO (T bit cleared), a
   reoptimization can still be requested by the PCC but this implies for
   the PCE to be statefull (keep a trace of the previously computed path
   with the associated list of strict hops).

   If a set of TE LSPs are in place and a reoptimization is triggered:
        - If all the elements of the set share the same constraints,
        then the PCC should send a single path computation request
        message containing the list of the EROs for the existing TE LSPs
        to avoid double bandwidth counting.
        - If the TE LPSs of the set do not share the same set of
        constraint, the PCC should send N path computation requests
        (where N is the number of TE LSPs) with the R bit of their
        REQUEST-ID object set and the corresponding ERO for the existing
        TE LSPs.

   B (Bi-directional): when set, the PCC specifies the TE LSP is bi-
   directional. When cleared, the TE LSP is unidirectional.


Vasseur, et al                                                 Page 9

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   L (less-constrainted path): when set in the Path Computation Request
   message, the PCC indicates to the PCE that a less-constrainted path
   is of interest in case of a negative reply (the request cannot be
   fully satisfied).  If set in a Path Computation Reply message, this
   indicates both that the PCE is capable of computing alternate
   constraint values for which a path could be found and that the PCC
   requested information on such a less-constrainted path. This flag
   should not be set in a Path Computation Reply message unless the
   corresponding Path Computation Request message had it set. In this
   case, the associated constraints must be provided in the path
   computation reply making use of the NO-PATH-AVAILABLE object. The PCE
   will in this case provide the closest possible solution (see section
   4.).

   Pri (Priority): 2 bits

   This field may be used for the requesting LSR to specify to the PCE
   the urgency of this request. The decision of which priority should be
   used for a specific request is a local matter and must be set to 0
   when unused. A possible use of this field is when several
   computations may be requested, each having different timing
   requirements: typically a request for a reoptimization would have a
   lower priority than a re-routing request.

   0x0: normal. No timing requirement specified.
   0x3: high. Urgent request to be served as soon as possible.

   Epoch: 24 bits

   Epoch is as described in RFC2961 and can be the same number.

   Request-ID-number: 32 bits

   This value (combined with the IP address of the PCC) uniquely
   identifies the Path Computation Request the message refers to and is
   incremented every time a new request is sent to the PCE. If no Path
   computation reply is received from the PCE, the request may be resent
   with the same Request-ID-number.
   The same Request-ID-number may be sent to different PCEÆs. The Path
   Computation Reply will be identified by the IP source address of the
   sender.

   The presence of the REQUEST-ID object is mandatory in every Path
   Computation Request and Reply message.


3.3.2 METRIC-TYPE

   The METRIC-TYPE object may be used in Path Computation Request
   message. This object is optional.

   When computing the path(s) obeying a set of specified constraints,
   the PCE will run a CSPF and will select the ôshortestö path from the
   subset of the topology which meets the constraints.  The shortest
   Path is defined as the path having the lowest cost for a specific
Vasseur, et al                                                Page 10

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   metric. This metric can be the IGP metric, the Traffic Engineering
   metric, or any other metric defined in the future. See also [SEC-
   METRIC] for a discussion on the use of the metric in the path
   computation. The METRIC-TYPE object is used by the PCC to indicate
   the PCE which metric to be used in its CSPF. When the METRIC-TYPE
   object is not present, the PCE must use the TE metric.

   METRIC-TYPE object format

   METRIC-TYPE Class-Num is [TBD]
   METRIC-TYPE C-Type is [TBD]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subobjects

     The contents of  the  METRIC-TYPE  object  are  a  series  of
     variable-length  data  items called subobjects.  The subobjects
     are defined in section below.

   Subobjects

   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   | metric-type   |     Length    | (Subobject contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

   metric-type: identifies the metric type
   0x00: IGP metric
   0x01: Traffic Engineering metric

   length

   The Length contains the total length of the subobject in bytes,
   including the metric-type and Length fields.  The Length MUST be at
   least 4, and MUST be a multiple of 4.

   Subject content

   Both IGP and Traffic Engineering metric have the same form:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         metric-value                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Vasseur, et al                                                Page 11

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   The metric-value subobject object will not be present in a path
   computation request.

   Note that the PCC may specify multiple metrics in its request.

   In such a case, the PCE must:
   - compute the shortest path(s) obeying the specified set of
   constraints for every metric,
   - provide in its reply the shortest path(s) for each metric since the
   PCC has required the shortest path for more than one metric. This
   means that the PCE must, for each metric type, provides the ERO and
   optionally the corresponding cost (see 3.3.3). A PATH-COST object
   will follow the ERO object in the reply that will specify the metric-
   type and optionally the metric-value.


3.3.3 PATH-COST

   The PATH-COST object is used in Path Computation Reply message.

   It may be desirable for the PCC to request that the PCE return not
   only the computed paths but also their corresponding costs.  The cost
   of the path is defined as the sum of the link metrics (IGP or TE
   metric) along this path. As defined in 3.3.1, the PCC will set the
   ôCö bit of the Flag field in the REQUEST-ID object of its Path
   Computation Request message to indicate the path(s) cost must be
   provided by the PCE in its reply (if the reply is positive).

   When the PCE returns one or more computed paths to the PCC:
   - if the ôCö bit of the REQUEST-ID flag has not been set in the Path
   Computation Request message, the PCE may or not provide the Path(s)
   cost,
   - if the ôCö bit of the REQUEST-ID flag has been set in the Path
   Computation Request message, the PCE must, for every ERO, include a
   PATH-COST object specifying the cost of the computed path for the
   requested metric(s). The requested metric is specified in the METRIC-
   TYPE Object received in the Path Computation Request.

   As mentioned in the previous section, there is another situation
   where the PCE must include a PATH-COST object for every computed ERO:
   when the request has been received with a METRIC-TYPE object
   specifying more than one metric. In this case, the PCE will also add
   one PATH-COST object for every ERO specifying the metric for which
   the ERO corresponds to the shortest path.

   The PATH-COST object will be made of subobjects identifying the
   metric type and the associated value.

   PATH-COST Class-Num is [TBD by IANA]
   PATH-COST C-Type is [TBD by IANA]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
Vasseur, et al                                                Page 12

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The same subobjects as defined for METRIC-TYPE will be used.

   The IGP metric of a computed path is defined as the sum of the IGP
   metrics of each link along the path. The TE metric of a computed path
   is defined as the sum of the TE metrics of each link along the path.

   Examples of METRIC-TYPE, PATH-COST Objects

   In the following examples, not all optional objects are mentioned and
   we suppose positive answers.

   Example 1

   Request
   <SESSION>
   <REQUEST-ID>=a, ôCö bit=0x1
   <METRIC-TYPE>: TE metric
   <sender descriptor>

   The PCC sends a request for the computation of one path obeying the
   set of specified constraints. The returned path must be the shortest
   path using the TE metric and must specify the associated cost.

   Reply
   REQUEST-ID=a
   <ERO 1>
   <PATH-COST>: metric-type=öTEö, metric-value=C1 (sum of the TE metric
   of the links along the path for ERO 1)

   Note: if the ôCö bit is cleared in the RESQUEST-ID object of the path
   computation request, the PCE may (but is not required to) return the
   computed path(s) with PATH-COST objects.

   Example 2

   Request
   <SESSION>
   <REQUEST-ID>=a, ôCö bit=0x1
   <METRIC-TYPE>: IGP metric & TE metric
   <sender descriptor>

   The PCC sends a request for the computation of one path obeying the
   set of specified constraints. The returned path must be the shortest
   path using the TE metric.

   Reply
   REQUEST-ID=a
   <ERO 1>
   <PATH-COST>: metric-type=öTEö, metric-value=C1 (sum of the IGP metric
   of the links along the path for ERO 1)
   <ERO 2>
Vasseur, et al                                                Page 13

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   <PATH-COST>: metric-type=öIGPö, metric-value=C2 (sum of the TE metric
   of the links along the path for ERO 2)


3.3.4 NO-PATH-AVAILABLE object

   The NO-PATH-AVAILABLE object may be used in Path Computation Reply
   message. This object is optional.

   When present, it allows the PCE to indicate the unsatisfied
   constraint(s) (the reason why no path can be found).
        - if the L bit in the REQUEST-ID of the path computation request
        has been set (less-constrainted path is of interest) and the
        PCE is capable of suggesting new constraint values, then the
        NO-PATH-AVAILABLE object allows the PCE to specify the
        alternate constraint values for which a path could be found.
        These new constraint values were used to compute the ERO
        included in the case where the request failed and an ERROR-SPEC
        is included in the Path Computation Reply message.
        - if the L bit in the REQUEST-ID of the path computation request
        has not been set and the request failed, a negative path
        computation reply is returned to the PCC with an ERROR-SPEC. No
        NO-PATH-AVAILABLE object is included in the reply.

   NO-PATH-AVAILABLE Class-Num is [TBD by IANA] - C-Type is [TBD by
   IANA]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flag      |  Reserved     |       Contraint-type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Suggested-value                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags: 8 bits

   0x00: the PCE indicates the constraint for which no path can be found
   but does not suggest any other value for the constraint for which a
   path could be found.
   0x01: the PCE indicates the constraint for which no path can be found
   and suggests another value for this constraint (as close as possible
   to the original requested constraint) for which a path could be
   found. This value is indicated in the suggested-value field.
   0x02: the PCE indicates that no path can be found with the requested
   constraints but an unconstrained path could be found. In this case
   both the Contraint-type and Suggested-value fields must be set to 0.


   Constraint-type: 16 bits

   Defines the constraint for which no path has been found by the PCE.

   0x0001 = no path can be found with the requested bandwidth
   0x0002 = no path can be found with the requested protection
Vasseur, et al                                                Page 14

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   0x0003 = no path can be found with the requested class affinity
            attribute
   0x0004 = the path-correlation requested cannot be satisfied
   0x0005 = no path can be found since the LSP was requested as bi-
            directional

   Suggested-value: 32 bits

   The PCE may, for each constraint, suggest a value (potentially the
   closest to the requested constraint in the original Path computation
   request) for which a path could be found. In this case, the flag must
   be set to 0x01. For example, if a bandwidth of X is requested by the
   head-end LSR and a path may be found but with a bandwidth of Y (with
   Y<X), Y may be mentioned by the PCE in the Suggested-value field.

   The suggested-value field must be set to 0x00000000 if the flag field
   is set to 0x00.

   Note that several NO-PATH-AVAILABLE objects may be included in the
   Path Computation Reply message so that the PCE may indicate the list
   of constraints for which no path has been found. In the specific case
   where just an unconstrained path can be found, the PCE will return a
   single NO-AVAILABLE-PATH object with the Flags=0x02 (this simplifies
   the RSVP message in this particular case, instead of having to
   include one NO-AVAILABLE-PATH per constraint).

   A PCE is not required to support the capability of identifying the
   constraint(s) that cannot be satisfied, and suggesting other values
   for the constraint(s) and will not do so unless the L bit was set in
   the request's REQUEST-ID.


3.3.5 NB-PATH object

   The NB-PATH object may be used in Path Computation Request message
   and Path Computation Reply messages. This object is optional in the
   Path Computation Request message. When present in the Path
   Computation Request message, it must be also present in the
   corresponding Path Computation Reply message.

   There are many situations where a PCC may desire to get more than one
   LSP (and so more than one path) between two points:

        - to perform load balancing between two LSRS in order to reduce
        the traffic disruption impact in case of link failure,

        - when a single TE LSP with the requested bandwidth cannot be
        found due to lack of bandwidth. In this case, the PCC could
        request a set of N TE LPS such that the sum of their bandwidth
        is equal to a known value X:
                - without specifying N,
                - without specifying N but a maximum for N,
        Also, in this case the PCC may want specify the minimum of
        bandwidth for each TE LSPs in the set (a set of 10000 TE LSPs of
        10K bandwidth each is likely to be undesirable).
Vasseur, et al                                                Page 15

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

        This type of request is called a global bandwidth request.

        - with path protection to compute both the primary and backup TE
        LSP (in this case they must be diversely routed),

        - à

   Also:
   - the PCE requests the computation of N (potentially correlated)
   paths sharing the same set of constraints. By correlated, we mean
   link/node/SRLG diverse.
   - the PCE requests the computation of N correlated paths each path
   having a different set of constraints. Such a request is called a
   global request and is made of individual requests. For each
   individual request, a specific path computation request message is
   sent to the PCE. A global path computation request is said satisfied
   if each individual request can be satisfied with their corresponding
   correlation.

   When the NB-PATH object is not present, exactly one path must be
   returned (provided one path satisfying the constraints exists).

   NB-PATH Class-Num is [TBD by IANA] C-Type is [TBD by IANA]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res|N|S|     Path-correlation   |         number-path           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags: 4 bits

   S bit:
        - S=0: the PCE requests the computation of (potentially
        correlated) number-path paths that share the same set of
        constraints.
        - S=1: the PCE requests the computation of number-path
        correlated paths having different set of constraints. The set of
        constraints of each path is defined in a different Path
        computation request message identified by the REQUEST-ID_number.
        The list of requests is specified in the PATH-CORRELATED object
        (defined in section 3.3.6). Note that in this case, the PCE
        starts the path computation after having received the number-
        path Path computation request.

   N bit:
        - N=0: the PCE requests the computation of exactly number-path
        paths
        - N=1: the PCE requests the computation of a maximum of number-
        path paths.

   Note
   In some situation, the PCC may want to request the computation of a
   set of n TE LSPs such that the sum of their bandwidth is equal to a
   specified value X. In this case, the sender-descriptor included in
Vasseur, et al                                                Page 16

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   the path computation request must reflect this value X for the
   bandwidth. n may be considered as a strict value (N bit =0 in the NB-
   PATH object and number-path=n), a maximum (N bit =1 in the NB-PATH
   object and number-path=n) or may be unknown (number-path=0xFFFFFF).
   Then in order to specify that each element of the set of TE LSPs must
   have a minimum bandwidth, the MIN-BW should be inserted (see 3.3.7).

   Path-correlation
   Defines the correlation between the various requested paths.
   0x000: no path correlation
   0x001: the various paths must be diversely routed (link diverse)
   0x002: the various paths must be diversely routed (node diverse)
   0x003: the various paths must be diversely routed (SRLG disjoint)
   0x004: the various paths must be diversely routed (link and SRLG)
   0x005: the various paths must be diversely routed (node and SRLG)

   number-path

   Defines the number of requested paths obeying the specified
   constraints to the PCE. The number-path must always be strictly
   greater than 1. If just one path is required no NB-PATH object must
   be inserted in the request.

   When the value 0xFFFF is specified, the PCC requires the computation
   of a number of TE LSPs which is not known a priori: typically, when
   the PCC requires the computation of a set of TE LSPs such that the
   sum of their bandwidth is equal to X but does not know the number of
   TE LSPS that will be required and does not impose any bound. When
   number-path=0xFFFF, the N bit must be set to 1.

   It may of course not be possible to compute number-path paths that
   obey the specified constraints; this will be more likely the case if
   diverse routing is requested.

   A NB-PATH object must be used in every Path Computation Reply message
   if the corresponding Path Computation Request message also contained
   an NB-PATH object.

   If the PCE requests the computation of (potentially correlated)
   number-path paths sharing the same set of constraints:

        - The S bit flag of the NB-PATH object in the Path computation
        request must be set to 0,

        If the reply is positive:

                If exactly N EROs have been requested (number-path=N
                and N bit=0 in the NB-PATH object of the request), then
                the number-path field of NB-PATH in the reply is N.  If
                up to N EROs have been requested (number-path=N and N
                bit=1 in the NB-PATH object of the request), then the
                number-path field of NB-PATH in the reply should be M
                (M<N), the number of paths which were found and
                necessary to meet the request.

Vasseur, et al                                                Page 17

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004


        If the reply is negative:

                The number-path field of NB-PATH in the Path
                computation reply contains the number of paths that
                could be computed by the PCE. If N EROs have been
                requested (number-path=N and N bit=0 in the NB_PATH
                object of the request) but the PCE can only find M EROs
                obeying the constraints (M<N), the PCE will return a
                Path Computation Reply message with an NB-PATH object
                where number-path=M.  If up to N EROs have been
                requested (number-path=N and N bit=1 in the NB-PATH
                object of the request) but the PCE cannot meet the
                constraints with the M paths that it can find (M>N),
                then the PCE will return Path Computation Reply message
                with an NB-PATH object where number-path=M.

                If the request desired information on less-constrainted
                paths in the event of a failure (L bit=1 in REQUEST-
                ID), then one or more EROs may be included along with
                one or more NO-PATH-AVAILABLE objects.  The reply will
                also contain an ERROR_SPEC object.

                If the request did not desire information on less-
                constrainted paths in the event of a failure (L bit=0
                in REQUEST-ID), no ERO object will be inserted in the
                reply.

                The reply will also contain an ERROR_SPEC object.

   If the PCE requests the computation of number-path correlated paths
   having different set of constraints, the NB-PATH object must just be
   present in the first of number-path requests.

        - The S bit flag of the NB-PATH object in the Path computation
        request must be set to 1,
        - In a request for number-path sharing different set of
        constraints, the N bit must always be set to 0,
        - The path computation request must contain a PATH-CORRELATED
        object listing the number-path REQUEST-ID. The set of
        constraints of each path is defined in number-path path
        computation requests,

        If the reply is positive:

                If N correlated paths have been requested (number-path=N
                in the NB-PATH object of the request), the number-path
                field of NB-PATH in the reply is N.

        If the reply is negative:

                The number-path field of NB-PATH in the Path computation
                reply contains the number of correlated paths that could
                be computed by the PCE. If N path computation have been
                requested (number-path=N in the NB-PATH object of the
Vasseur, et al                                                Page 18

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

                request) but the PCE can only find M paths obeying the
                constraints (M<N), the PCE will return a Path
                Computation Reply message with an NB-PATH object where
                number-path=M. The PCE will also include a PATH-
                CORRELATED object listing the set of N-M requests that
                could not be satisfied (identified by their REQUEST-ID-
                number).

                If the request desired information on less-constrainted
                paths in the event of a failure (L bit=1 in REQUEST-ID)
                and the PCE is capable of computing alternate
                constraint values for which a path could be found,
                then:
                        - the EROs for the satisfied individual
                        requests must be provided,

                        - one or more EROs may be included along with
                        one or more NO-PATH-AVAILABLE objects for the
                        individual requests that could not be satisfied
                        as requested.

                If the request did not desire information on less-
                constrainted paths in the event of a failure (L bit=0
                in REQUEST-ID), no ERO object will be inserted in the
                reply.

                The reply will also contain an ERROR_SPEC object.

   Example 1 (Path computation of 5 paths sharing the same set of
   constraints). Less constrainted path is of interest.

   The PCC sends a request to the PCE with the following constraints:

   Request
   <SESSION>
   <REQUEST-ID>=a, L bit=1
   <NB-PATH>: Flag: N=0, S=0, number-path=5, Path-correlation=0x02 (Node
   diversely routed paths)
   sender descriptor: bw=x, à

   If just M=3 (M<N=5) paths can be found by the PCE with the requested
   constraints but 5 such paths can be found if the requested bandwidth
   is y (y<x), then the PCE may send the path computation reply of this
   form:

   Reply
   REQUEST-ID=a
   <ERROR-SPEC> (specifying a negative reply)
   <NB-PATH>: Flag: N=0, S=0 number-path=3, Path-correlation=0x02
   <ERO1>
   <ERO2>
   <ERO3>
   <NO-PATH-AVAILABLE>: Flags=0x01, Constraint-type=0x0001 (bandwidth),
   Suggested-value=y

Vasseur, et al                                                Page 19

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   Which means:
        - the reply is negative (the request cannot be satisfied with
        the specified constraints)
        - the unsatisfied constraint is ôBandwidthö
        - Exactly M=3 EROs (M<N) could be found with the requested
        constraints. Their corresponding paths are ERO1, ERO2 and ERO3.
        - N=5 node diversely routed path could be found if the bandwidth
        is set to y.

   Then the PCC could decide to resend a path computation request for N
   EROs but with the new suggested value for the bandwidth (y).

   Example 2 (Path computation of N=4 paths sharing different set of
   constraints). Less constrainted path is not of interest.

   The PCC sends a request to the PCE with the following constraints:

   Request 1
   <SESSION>
   <REQUEST-ID>=a, L bit=0
   <NB-PATH>: Flag: N=0, S=1, number-path=4, Path-correlation=0x02 (Node
   diversely routed paths)
   <PATH-CORRELATED>=a,b,c,d
   sender descriptor: bw=x, à

   The PCE receives a Global path computation request for N=4 paths
   sharing different set of constraints. The PCE will start the
   computation after having received the N=4 path computation requests
   having the request-ID-number a, b, c and d.

   Request 2
   <SESSION>
   <REQUEST-ID>=b
   sender descriptor: bw=y, à

   Request 3
   <SESSION>
   <REQUEST-ID>=c
   sender descriptor: bw=z, à

   Request 3
   <SESSION>
   <REQUEST-ID>=d
   sender descriptor: bw=w, à

   Reply 1
   REQUEST-ID=a
   <ERROR-SPEC> (specifying a negative reply)
   <NB-PATH>: Flag: N=0, S=1, number-path=2, Path-correlation=0x02
   <PATH-CORRELATED>: b,c

   Which means:
   - the reply is negative (the global request cannot be satisfied with
   the specified constraints)
   - just 2 requests could be satisfied: a and d
Vasseur, et al                                                Page 20

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   - the requests whose request-ID-number are b and c could not be
   satisfied

   Example 3 (Path computation of N=4 paths sharing different set of
   constraints). Less constrainted path is of interest.

   The PCC sends a request to the PCE with the following constraints:

   Request 1
   <SESSION>
   <REQUEST-ID>=a, L bit=1
   <NB-PATH>: Flag: N=0, S=1, number-path=4, Path-correlation=0x02 (Node
   diversely routed paths)
   <PATH-CORRELATED>=a,b,c,d
   sender descriptor: bw=x, à

   The PCE receives a Global path computation request for N=4 paths
   sharing different set of constraints. The PCE will start the
   computation after having received the N=4 path computation requests
   having the request-ID-number a, b, c and d.

   Request 2
   <SESSION>
   <REQUEST-ID>=b
   sender descriptor: bw=y, à

   Request 3
   <SESSION>
   <REQUEST-ID>=c
   sender descriptor: bw=z, à

   Request 3
   <SESSION>
   <REQUEST-ID>=d
   sender descriptor: bw=w, à


   Reply 1
   REQUEST-ID=a, L bit=1
   <NB-PATH>: Flag: N=0, S=1, number-path=2, Path-correlation=0x02
   <PATH-CORRELATED>: b,c
   <ERO>

   Reply 2
   REQUEST-ID=d, L bit=1
   <ERO>

   Reply 3
   REQUEST-ID=b
   <ERROR-SPEC> (specifying a negative reply)
   <NO-PATH-AVAILABLE>: Flags=0x01, Constraint-type=0x0001 (bandwidth),
   Suggested-value=yÆ
   <ERO>

   Reply 4
Vasseur, et al                                                Page 21

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   REQUEST-ID=c
   <ERROR-SPEC> (specifying a negative reply)
   <NO-PATH-AVAILABLE>: Flags=0x01, Constraint-type=0x0001 (bandwidth),
   Suggested-value=zÆ
   <ERO>

   Which means:
   - the reply is negative (the global request cannot be satisfied with
   the specified constraints)
   - just 2 requests could be satisfied: a and d and their corresponding
   ERO are provided.
   - the requests whose request-ID-number are b and c could not be
   satisfied as specified,
   - the unsatisfied constraint for request b and c is ôBandwidthö
   - the global request can be satisfied if the request bandwidth for
   request b is yÆ and the requested bandwidth for c is zÆ. The
   corresponding EROs are provided in the reply since the L bit in the
   REQUEST-ID object of the path computation request had been set.


3.3.6 PATH-CORRELATED object

   The PATH-CORRELATED object may be used in Path Computation Request
   message. This object is optional.

   It allows the PCC to request to the PCE the computation of N
   correlated paths having different set of constraints and contains the
   list of the REQUEST-ID of those paths.

   PATH-CORRELATED Class-Num is [TBD]
   PATH-CORRELATED C-Type is [TBD]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subobjects

   The contents of  a  PATH-CORRELATED  object  is  a  series  REQUEST-
   ID objects.


3.3.7 MIN-BW object

   The MIN-BW object is used in Path Computation Request messages. This
   object is optional and used by the PCC to request a set of TE LSPs
   such that the sum of their bandwidth is determined, the number of
   elements in the set may or not be specified, and the minimum
   bandwidth of each element in the set is specified thanks to the MIN-
   BW object.

Vasseur, et al                                                Page 22

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   Note that the TE LSPs may or not share the same constraints.

   MIN-BW Class-Num is [TBD]
   MIN-BW C-Type is [TBD]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MIN-BW-LSP                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MIN-BW-LSP: Minimum bandwidth of any element of the backup
   tunnel set.


3.3.8 LSP-BANDWIDTH object

   The LSP-BANDWIDTH object is used in Path Computation reply messages
   and is included in any positive path computation reply to specify the
   bandwidth of a computed TE LSP path when the request was a global
   bandwidth request (see the definition in section 3.3.5). It
   immediately follows the ERO.

   LSP-BANDWIDTH Class-Num is [TBD]
   LSP-BANDWIDTH C-Type is [TBD]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      LSP-Bandwidth                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LSP-Bandwidth: Actual bandwidth determined for the associated path

   Example 1: Path computation of a set diversely routed paths sharing
   the same set of constraints such that:
        - number of elements in the set is not specified and not bounded
          by the PCC,
        - the sum of their bandwidths is X,
        - each element of the set has a minimum bandwidth of m

   Request
   <SESSION>
   <REQUEST_ID>=a
   <NB_PATH>: Flag: N=1, S=0, number-path=0xFFFFFF,
   Path_correlation=0x02 (Node diversely routed paths)
   sender descriptor: bw=X, à
   <MIN-BW>: MIN-BW-LSP=m

   Supposing the PCE can find such a solution with 4 node diverse TE
   LSPs: LSP1, LSP2, LSP3, LSP4 such that:
        - TE LSP 1 : ERO1, Bw=x1, x1>m
        - TE LSP 2 : ERO2, Bw=x2, x2>m
        - TE LSP 3 : ERO3, Bw=x3, x3>m,
Vasseur, et al                                                Page 23

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

        - TE LSP 4 : ERO4, Bw=x4, x4>m,
        - x1+x2+x3+x4=X

   Reply
   REQUEST_ID=a
   <NB_PATH>: Flag: N=1, S=0, number-path=4, Path_correlation=0x02
   <ERO1>, <LSP-BANDWIDTH> (Bw=x1)
   <ERO2>, <LSP-BANDWIDTH> (Bw=x2)
   <ERO3>, <LSP-BANDWIDTH> (Bw=x3)
   <ERO4>, <LSP-BANDWIDTH> (Bw=x4)


   Example 2: Path computation of a maximum of n diversely routed paths
   sharing the same set of constraints such that:
        - the sum of their bandwidths is X,
        - each element of the set has a minimum bandwidth of m

   Request
   <SESSION>
   <REQUEST_ID>=a
   <NB_PATH>: Flag: N=1, S=0, number-path=n, Path_correlation=0x02 (Node
   diversely routed paths)
   sender descriptor: bw=X, à
   <MIN-BW>: MIN-BW-LSP=m

   Supposing the PCE can find such a solution with 3 node diverse TE
   LSPs: LSP1, LSP2, LSP3 such that
        - TE LSP 1 : ERO1, Bw=x1, x1>m
        - TE LSP 2 : ERO2, Bw=x2, x2>m
        - TE LSP 3 : ERO3, Bw=x3, x3>m,
        - x1+x2+x3=X

   Reply
   REQUEST_ID=a
   <NB_PATH>: Flag: N=1, S=0, number-path=n, Path_correlation=0x02
   <ERO1>, <LSP-BANDWIDTH> (Bw=x1)
   <ERO2>, <LSP-BANDWIDTH> (Bw=x2)
   <ERO3>, <LSP-BANDWIDTH> (Bw=x3)

   Example 3: Path computation of exactly 2 diversely routed paths not
   sharing the same set of constraints such that the sum of their
   bandwidths is X.

   Request
   <SESSION>
   <REQUEST_ID>=a
   <NB_PATH>: Flag: N=0, S=1, number-path=2, Path_correlation=0x02 (Node
   diversely routed paths)
   sender descriptor: bw=X, à
   <PATH_CORRELATED>=a,b
   à

   <REQUEST_ID>=b
   <NB_PATH>: flag: N=0, S=1, number_PATH=2, Path_correlation=0x02 (Node
   diversely routed paths)
Vasseur, et al                                                Page 24

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   sender descriptor: bw=X, à
   à

   Supposing the PCE can find such a solution with 3 node diverse TE
   LSPs: LSP1, LSP2, LSP3 such that
        - TE LSP 1 : ERO1, Bw=x1, x1>m
        - TE LSP 2 : ERO2, Bw=x2, x2>m
        - x1+x2=X

   Reply
   REQUEST_ID=a
   <NB_PATH>: Flag: N=0, S=1, number-path=2, Path_correlation=0x02
   <ERO1>, <LSP-BANDWIDTH> (Bw=x1)
   <ERO2>, <LSP-BANDWIDTH> (Bw=x2)



3.3.9 EXCLUDE-ELEMENT object

   The EXCLUDE-ELEMENT object may be used in Path Computation Request
   message. This object is optional.

   It allows the PCC to specify to the PCE another constraint related to
   the computed path: the exclusion of one or more network elements in
   the computed path.  A network element may be a link, an entire node
   or even an Autonomous System. The EXCLUDED-ELEMENT object contains
   the list of network elements to exclude from the computed path.  Each
   network element is represented as a subobject.

   EXCLUDE-ELEMENT Class-Num is [TBD]
   EXCLUDE-ELEMENT C-Type is [TBD]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subobjects

   The contents of  an  EXCLUDE-OBJECT  object  is  a  series  of
   variable-length  data  items called subobjects.  The subobjects
   are defined in section below.

   Subobjects

   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   |NET|    Type   |     Length    | (Subobject contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

   NET (Network Element Type)
Vasseur, et al                                                Page 25

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004


   Defines whether the network element is a link, a node or an AS.
   L=0x00 the subobject identifies a link address the computed path must
   not traverse.
   L=0x01 the subobject identifies a node address the computed path must
   not traverse.
   L=0x02 the subobject identifies an Autonomous System the computed
   path must not traverse.
   L=0x03 the subobject identifies a SRLG the computed path must avoid.

   Type

   Indicates the  type  of  data found in the  subobject.
   Currently defined values are:

        0   Reserved
        1   IPv4 prefix
        2   IPv6 prefix
        32   Autonomous system number

   Length

   The Length contains the total length of the subobject in bytes,
   including the NET, Type and Length fields.  The Length MUST be at
   least 4, and MUST be a multiple of 4.


3.3.10 OPAQUE object

   The OPAQUE object may be present in both Path Computation Request and
   Reply message types. This object is optional.

   The OPAQUE object may be used by the PCC to transfer information to
   the PCE (in a Path Computation Request message) or by the PCE to
   transfer information to the PCC (in a Path Computation Reply
   message). Opaque object may be used for future extensions and the
   exact content of the OPAQUE object is beyond the scope of this draft.

   OPAQUE Class-Num is [TBD by IANA] - C-Type is [TBD by IANA]

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            Value                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
        Type: identifies the TLV type
        Length: length of the value field in octets


Vasseur, et al                                                Page 26

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   The OPAQUE object may also contain sub-TLV to be defined in the
   future.


4. Definition of the ôclosest possible solutionö

   At several places in this draft the term ôclosest possible solutionö
   is mentioned. This refers to the solution (the set of paths) the PCE
   could find if the request cannot be fully satisfied (negative
   reply). The definition of ôclosest possible solutionö is determined
   by the PCE (local decision).

   In a future version of this draft, this could be defined by the PCC
   in its request (detailing the set of constraints that should be
   relaxed by order of priority): this is for further study.

   Example

   - Request for 5 TE LSPs sharing the same set of constraint for 10M
   of bandwidth each,
   - The PCE can find three solutions:
        - Solution 1: LSP1=10, LSP2=10, LSP3=10, LSP4=5, LSP5=5
        - Solution 2: LSP1=8, LSP2=8, LSP3=8, LSP4=8, LSP5=8
        - Solution 3: LSP1=11, LSP2=11, LSP3=11, LSP4=11

   Which solution is the closest of the initial request depends on the
   definition of ôclosestö. It could be:
        - Solution 1: 3 LSPs could be found with 10M
        - Solution 2: exactly 5 LSPs with the same bandwidth could be
        found
        - Solution 3: 4 LSPs could be found but the total of their
        bandwidth is 44M closest to the initial request for 50M.


5. PCE discovery

   There are several possibilities for the PCC to learn the PCE(s)
   location (IP addresses) and capabilities:
        - by static configuration: the list of PCE can be manually
        configured on each LSR, optionally:
                o with an order of priority,
                o their respective capabilities,
                o à
        - using IGP extensions for an automatic PCE discovery (see [14]
        and [15]).

6. Acknowledgment

   The authors would like to thank Bob Thomas, Francois Le Faucheur, Rob
   Goguen, Anna Charny and Ashok Naranayan for their very valuable
   comments.


7. Security Considerations

Vasseur, et al                                                Page 27

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   No new security issues are raised in this document. See [RSVP] for a
   general discussion on RSVP security issues.

8. References

   Normative references

   [RFC] Bradner, S., "Key words for use in RFCs to indicate
   requirements levels", RFC 2119, March 1997.

   [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
   RFC 3667, February 2004.

   [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
   Technology", BCP 79, RFC 3668, February 2004.

   [RSVP] Braden R. et al, ôResource ReSerVation Protocol (RSVP)ö, RFC
   2205, September 1997.

   [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
   tunnels", RFC 3209, December 2001.

   Informative references

   [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [ISIS] "Intermediate System to Intermediate System Intra-Domain
   Routing Exchange Protocol " ISO 10589.

   [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
   dual environments", RFC 1195, December 1990.

   [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
   Extensions to OSPF Version 2", RFC 3630, September 2003.

   [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
   Engineering", RFC 3784, June 2004.

   [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
   J.P., "Extensions to OSPF for advertising Optional Router
   Capabilities", draft-ietf-ospf-cap-03.txt, work in progress.

   [OSPF-TE-CAP] Vasseur, J.P., Psenak, P., Yasukawa, S., "OSPF MPLS
   Traffic Engineering Capabilities", draft-vasseur-ospf-te-caps-
   00.txt, work in progress.

   [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N., "IS-IS extensions
   for advertising router information", draft-vasseur-isis-caps-02.txt,
   work in progress.

   [ISIS-TE-CAP] Vasseur, J.P, Previdi, S., Mabey, P., Le Roux, J.L.,
   "IS-IS MPLS Traffic Engineering Capabilities", draft-vasseur-isis-
   te-caps-00.txt, work in progress.


Vasseur, et al                                                Page 28

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

   [IGP-TE-CAP] Vasseur JP, Le Roux et al. ôRouting extensions for
   discovery of TE router informationö, draft-vasseur-ccamp-te-router-
   info-00.txt, work in progress.

   [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J.,
   "Requirements for inter-area MPLS Traffic Engineering", draft-ietf-
   tewg-interarea-mpls-te-req-02.txt, work in progress.

   [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
   Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-
   07.txt, work in progress.

   [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A
   Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel-
   ccamp-inter-domain-framework-01.txt, work in progress.

   [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for
   PCE based MPLS Facility Backup Path Computation", draft-leroux-pce-
   backup-comp-frwk-00.txt, work in progress

   [REFRESH-REDUCTION] Berger L., Gan D., Swallow G., Pan P., Tommasi
   F., Molendini S., "RSVP Refresh Overhead Reduction Extensions", RFC
   2961, April 2001.

   [SEC-METRIC] Le faucheur F. et al, ôUse of IGP Metric as a second TE
   Metricö, RFC 3785, May 2004.


9. Author's Addresses

      JP Vasseur
      CISCO Systems, Inc.
      300 Beaver Brook Road
      Boxborough , MA - 01719
      USA
      Email: jpv@cisco.com

      Carol Iturralde
      Cisco Systems, Inc.
      300 Beaver Brook Road
      Boxborough , MA - 01719
      USA
      Email:  cei@cisco.com

      Raymond Zhang
      Infonet Services Corporation
      2160 E. Grand Ave.
      El Segundo, CA 90025
      USA
      Office: +310-335-1039
      Email: raymond_zhang@infonet.com

      Xavier VINET
      EQUANT
      9 rue du ChŠne Germain - BP 80
Vasseur, et al                                                Page 29

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

      35512 Cesson Sevigne cedex
      FRANCE
      Email : xavier.vinet@equant.com

      Satoru Matsushima
      Japan Telecom
      4-7-1, Hatchobori, Chuo-ku
      Tokyo, 104-8508 Japan
      Phone: +81-3-5540-8214
      Email: satoru@japan-telecom.co.jp

      Alia Atlas
      Avici Systems
      101 Billerica Avenue
      N. Billerica, MA 01862
      email: aatlas@avici.com
      phone: +1 978 964 2070

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

   IPR Disclosure Acknowledgement

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

Full Copyright Statement

Copyright (C) The Internet Society (2004).  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.

Vasseur, et al                                                Page 30

draft-vasseur-mpls-computation-rsvp-05.txt          July 2004

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
















































Vasseur, et al                                                Page 31


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