tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5440

 
 
 

Path Computation Element (PCE) Communication Protocol (PCEP)

Part 3 of 4, p. 40 to 58
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 40 
7.11.  LSPA Object

   The LSPA (LSP Attributes) object is optional and specifies various TE
   LSP attributes to be taken into account by the PCE during path
   computation.  The LSPA object can be carried within a PCReq message,
   or a PCRep message in case of unsuccessful path computation (in this
   case, the PCRep message also contains a NO-PATH object, and the LSPA
   object is used to indicate the set of constraints that could not be
   satisfied).  Most of the fields of the LSPA object are identical to
   the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in
   [RFC3209] and [RFC4090].  When absent from the PCReq message, this
   means that the Setup and Holding priorities are equal to 0, and there
   are no affinity constraints.  See Section 4.7.4 of [RFC3209] for a
   detailed description of the use of resource affinities.

   LSPA Object-Class is 9.

   LSPA Object-Types is 1.

Top      Up      ToC       Page 41 
   The format of the LSPA object body is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Exclude-any                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-any                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-all                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Setup Prio   |  Holding Prio |     Flags   |L|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Optional TLVs                           //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 16: LSPA Object Body Format

   Setup Prio (Setup Priority - 8 bits):  The priority of the TE LSP
      with respect to taking resources, in the range of 0 to 7.  The
      value 0 is the highest priority.  The Setup Priority is used in
      deciding whether this session can preempt another session.

   Holding Prio (Holding Priority - 8 bits):  The priority of the TE LSP
      with respect to holding resources, in the range of 0 to 7.  The
      value 0 is the highest priority.  Holding Priority is used in
      deciding whether this session can be preempted by another session.

   Flags (8 bits)

      L flag:  Corresponds to the "Local Protection Desired" bit
         ([RFC3209]) of the SESSION-ATTRIBUTE Object.  When set, this
         means that the computed path must include links protected with
         Fast Reroute as defined in [RFC4090].

      Unassigned flags MUST be set to zero on transmission and MUST be
      ignored on receipt.

   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Note that optional TLVs may be defined in the future to carry
   additional TE LSP attributes such as those defined in [RFC5420].

Top      Up      ToC       Page 42 
7.12.  Include Route Object

   The IRO (Include Route Object) is optional and can be used to specify
   that the computed path MUST traverse a set of specified network
   elements.  The IRO MAY be carried within PCReq and PCRep messages.
   When carried within a PCRep message with the NO-PATH object, the IRO
   indicates the set of elements that cause the PCE to fail to find a
   path.

   IRO Object-Class is 10.

   IRO Object-Type is 1.

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

                    Figure 17: IRO Body Format

   Sub-objects:  The IRO is made of sub-objects identical to the ones
      defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub-
      object type is identical to the sub-object type defined in the
      related documents.

      The following sub-object types are supported.

          Type   Sub-object
           1     IPv4 prefix
           2     IPv6 prefix
           4     Unnumbered Interface ID
           32    Autonomous system number

   The L bit of such sub-object has no meaning within an IRO.

7.13.  SVEC Object

7.13.1.  Notion of Dependent and Synchronized Path Computation Requests

   Independent versus dependent path computation requests: path
   computation requests are said to be independent if they are not
   related to each other.  Conversely, a set of dependent path
   computation requests is such that their computations cannot be
   performed independently of each other (a typical example of dependent
   requests is the computation of a set of diverse paths).

Top      Up      ToC       Page 43 
   Synchronized versus non-synchronized path computation requests: a set
   of path computation requests is said to be non-synchronized if their
   respective treatment (path computations) can be performed by a PCE in
   a serialized and independent fashion.

   There are various circumstances where the synchronization of a set of
   path computations may be beneficial or required.

   Consider the case of a set of N TE LSPs for which a PCC needs to send
   path computation requests to a PCE.  The first solution consists of
   sending N separate PCReq messages to the selected PCE.  In this case,
   the path computation requests are non-synchronized.  Note that the
   PCC may chose to distribute the set of N requests across K PCEs for
   load balancing purposes.  Considering that M (with M<N) requests are
   sent to a particular PCEi, as described above, such M requests can be
   sent in the form of successive PCReq messages destined to PCEi or
   bundled within a single PCReq message (since PCEP allows for the
   bundling of multiple path computation requests within a single PCReq
   message).  That said, even in the case of independent requests, it
   can be desirable to request from the PCE the computation of their
   paths in a synchronized fashion that is likely to lead to more
   optimal path computations and/or reduced blocking probability if the
   PCE is a stateless PCE.  In other words, the PCE should not compute
   the corresponding paths in a serialized and independent manner, but
   it should rather "simultaneously" compute their paths.  For example,
   trying to "simultaneously" compute the paths of M TE LSPs may allow
   the PCE to improve the likelihood to meet multiple constraints.

   Consider the case of two TE LSPs requesting N1 Mbit/s and N2 Mbit/s,
   respectively, and a maximum tolerable end-to-end delay for each TE
   LSP of X ms.  There may be circumstances where the computation of the
   first TE LSP, irrespectively of the second TE LSP, may lead to the
   impossibility to meet the delay constraint for the second TE LSP.

   A second example is related to the bandwidth constraint.  It is quite
   straightforward to provide examples where a serialized independent
   path computation approach would lead to the impossibility to satisfy
   both requests (due to bandwidth fragmentation), while a synchronized
   path computation would successfully satisfy both requests.

   A last example relates to the ability to avoid the allocation of the
   same resource to multiple requests, thus helping to reduce the call
   setup failure probability compared to the serialized computation of
   independent requests.

   Dependent path computations are usually synchronized.  For example,
   in the case of the computation of M diverse paths, if such paths are
   computed in a non-synchronized fashion, this seriously increases the

Top      Up      ToC       Page 44 
   probability of not being able to satisfy all requests (sometimes also
   referred to as the well-known "trapping problem").

   Furthermore, this would not allow a PCE to implement objective
   functions such as trying to minimize the sum of the TE LSP costs.  In
   such a case, the path computation requests must be synchronized: they
   cannot be computed independently of each other.

   Conversely, a set of independent path computation requests may or may
   not be synchronized.

   The synchronization of a set of path computation requests is achieved
   by using the SVEC object that specifies the list of synchronized
   requests that can either be dependent or independent.

   PCEP supports the following three modes:

   o  Bundle of a set of independent and non-synchronized path
      computation requests,

   o  Bundle of a set of independent and synchronized path computation
      requests (requires the SVEC object defined below),

   o  Bundle of a set of dependent and synchronized path computation
      requests (requires the SVEC object defined below).

7.13.2.  SVEC Object

   Section 7.13.1 details the circumstances under which it may be
   desirable and/or required to synchronize a set of path computation
   requests.  The SVEC (Synchronization VECtor) object allows a PCC to
   request the synchronization of a set of dependent or independent path
   computation requests.  The SVEC object is optional and may be carried
   within a PCReq message.

   The aim of the SVEC object carried within a PCReq message is to
   request the synchronization of M path computation requests.  The SVEC
   object is a variable-length object that lists the set of M path
   computation requests that must be synchronized.  Each path
   computation request is uniquely identified by the Request-ID-number
   carried within the respective RP object.  The SVEC object also
   contains a set of flags that specify the synchronization type.

   SVEC Object-Class is 11.

   SVEC Object-Type is 1.

Top      Up      ToC       Page 45 
   The format of the SVEC object body is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |                   Flags                 |S|N|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Request-ID-number #1                      |
   //                                                             //
   |                     Request-ID-number #M                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 18: SVEC Body Object Format

   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Flags (24 bits):  Defines the potential dependency between the set of
      path computation requests.

      *  L (Link diverse) bit: when set, this indicates that the
         computed paths corresponding to the requests specified by the
         following RP objects MUST NOT have any link in common.

      *  N (Node diverse) bit: when set, this indicates that the
         computed paths corresponding to the requests specified by the
         following RP objects MUST NOT have any node in common.

      *  S (SRLG diverse) bit: when set, this indicates that the
         computed paths corresponding to the requests specified by the
         following RP objects MUST NOT share any SRLG (Shared Risk Link
         Group).

      In case of a set of M synchronized independent path computation
      requests, the bits L, N, and S are cleared.

   Unassigned flags MUST be set to zero on transmission and MUST be
   ignored on receipt.

   The flags defined above are not exclusive.

7.13.3.  Handling of the SVEC Object

   The SVEC object allows a PCC to specify a list of M path computation
   requests that MUST be synchronized along with a potential dependency.
   The set of M path computation requests may be sent within a single
   PCReq message or multiple PCReq messages.  In the latter case, it is
   RECOMMENDED for the PCE to implement a local timer (called the

Top      Up      ToC       Page 46 
   SyncTimer) activated upon the receipt of the first PCReq message that
   contains the SVEC object after the expiration of which, if all the M
   path computation requests have not been received, a protocol error is
   triggered.  When a PCE receives a path computation request that
   cannot be satisfied (for example, because the PCReq message contains
   an object with the P bit set that is not supported), the PCE sends a
   PCErr message for this request (see Section 7.2), the PCE MUST cancel
   the whole set of related path computation requests and MUST send a
   PCErr message with Error-Type="Synchronized path computation request
   missing".

   Note that such PCReq messages may also contain non-synchronized path
   computation requests.  For example, the PCReq message may comprise N
   synchronized path computation requests that are related to RP 1, ...,
   RP N and are listed in the SVEC object along with any other path
   computation requests that are processed as normal.

7.14.  NOTIFICATION Object

   The NOTIFICATION object is exclusively carried within a PCNtf message
   and can either be used in a message sent by a PCC to a PCE or by a
   PCE to a PCC so as to notify of an event.

   NOTIFICATION Object-Class is 12.

   NOTIFICATION Object-Type is 1.

   The format of the NOTIFICATION body object is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |     Flags     |      NT       |     NV        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 19: NOTIFICATION Body Object Format

   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Flags (8 bits):  No flags are currently defined.  Unassigned flags
      MUST be set to zero on transmission and MUST be ignored on
      receipt.

Top      Up      ToC       Page 47 
   NT (Notification Type - 8 bits):  The Notification-type specifies the
      class of notification.

   NV (Notification Value - 8 bits):  The Notification-value provides
      addition information related to the nature of the notification.

   Both the Notification-type and Notification-value are managed by
   IANA.

   The following Notification-type and Notification-value values are
   currently defined:

   o  Notification-type=1: Pending Request cancelled

      *  Notification-value=1: PCC cancels a set of pending requests.  A
         Notification-type=1, Notification-value=1 indicates that the
         PCC wants to inform a PCE of the cancellation of a set of
         pending requests.  Such an event could be triggered because of
         external conditions such as the receipt of a positive reply
         from another PCE (should the PCC have sent multiple requests to
         a set of PCEs for the same path computation request), a network
         event such as a network failure rendering the request obsolete,
         or any other events local to the PCC.  A NOTIFICATION object
         with Notification-type=1, Notification-value=1 is carried
         within a PCNtf message sent by the PCC to the PCE.  The RP
         object corresponding to the cancelled request MUST also be
         present in the PCNtf message.  Multiple RP objects may be
         carried within the PCNtf message; in which case, the
         notification applies to all of them.  If such a notification is
         received by a PCC from a PCE, the PCC MUST silently ignore the
         notification and no errors should be generated.

      *  Notification-value=2: PCE cancels a set of pending requests.  A
         Notification-type=1, Notification-value=2 indicates that the
         PCE wants to inform a PCC of the cancellation of a set of
         pending requests.  A NOTIFICATION object with Notification-
         type=1, Notification-value=2 is carried within a PCNtf message
         sent by a PCE to a PCC.  The RP object corresponding to the
         cancelled request MUST also be present in the PCNtf message.
         Multiple RP objects may be carried within the PCNtf message; in
         which case, the notification applies to all of them.  If such
         notification is received by a PCE from a PCC, the PCE MUST
         silently ignore the notification and no errors should be
         generated.

   o  Notification-type=2: Overloaded PCE

      *  Notification-value=1: A Notification-type=2, Notification-

Top      Up      ToC       Page 48 
         value=1 indicates to the PCC that the PCE is currently in an
         overloaded state.  If no RP objects are included in the PCNtf
         message, this indicates that no other requests SHOULD be sent
         to that PCE until the overloaded state is cleared: the pending
         requests are not affected and will be served.  If some pending
         requests cannot be served due to the overloaded state, the PCE
         MUST also include a set of RP objects that identifies the set
         of pending requests that are cancelled by the PCE and will not
         be honored.  In this case, the PCE does not have to send an
         additional PCNtf message with Notification-type=1 and
         Notification-value=2 since the list of cancelled requests is
         specified by including the corresponding set of RP objects.  If
         such notification is received by a PCE from a PCC, the PCE MUST
         silently ignore the notification and no errors should be
         generated.

      *  A PCE implementation SHOULD use a dual-threshold mechanism used
         to determine whether it is in a congestion state with regards
         to specific resource monitoring (e.g.  CPU, memory).  The use
         of such thresholds is to avoid oscillations between overloaded/
         non-overloaded state that may result in oscillations of request
         targets by the PCCs.

      *  Optionally, a TLV named OVERLOADED-DURATION may be included in
         the NOTIFICATION object that specifies the period of time
         during which no further request should be sent to the PCE.
         Once this period of time has elapsed, the PCE should no longer
         be considered in a congested state.

         The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
         format defined in Section 7.1 and is comprised of 2 bytes for
         the type, 2 bytes specifying the TLV length (length of the
         value portion in bytes), followed by a fixed-length value field
         of a 32-bit flags field.

         Type:   2
         Length: 4 bytes
         Value:  32-bit flags field indicates the estimated PCE
                 congestion duration in seconds.

      *  Notification-value=2: A Notification-type=2, Notification-
         value=2 indicates that the PCE is no longer in an overloaded
         state and is available to process new path computation
         requests.  An implementation SHOULD make sure that a PCE sends
         such notification to every PCC to which a Notification message
         (with Notification-type=2, Notification-value=1) has been sent
         unless an OVERLOADED-DURATION TLV has been included in the
         corresponding message and the PCE wishes to wait for the

Top      Up      ToC       Page 49 
         expiration of that period of time before receiving new
         requests.  If such notification is received by a PCE from a
         PCC, the PCE MUST silently ignore the notification and no
         errors should be generated.  It is RECOMMENDED to support some
         dampening notification procedure on the PCE so as to avoid too
         frequent congestion state and congestion state release
         notifications.  For example, an implementation could make use
         of an hysteresis approach using a dual-threshold mechanism that
         triggers the sending of congestion state notifications.
         Furthermore, in case of high instabilities of the PCE
         resources, an additional dampening mechanism SHOULD be used
         (linear or exponential) to pace the notification frequency and
         avoid oscillation of path computation requests.

   When a PCC receives an overload indication from a PCE, it should
   consider the impact on the entire network.  It must be remembered
   that other PCCs may also receive the notification, and so many path
   computation requests could be redirected to other PCEs.  This may, in
   turn, cause further overloading at PCEs in the network.  Therefore,
   an application at a PCC receiving an overload notification should
   consider applying some form of back-off (e.g., exponential) to the
   rate at which it generates path computation requests into the
   network.  This is especially the case as the number of PCEs reporting
   overload grows.

7.15.  PCEP-ERROR Object

   The PCEP-ERROR object is exclusively carried within a PCErr message
   to notify of a PCEP error.

   PCEP-ERROR Object-Class is 13.

   PCEP-ERROR Object-Type is 1.

   The format of the PCEP-ERROR object body is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |      Flags    |   Error-Type  |  Error-value  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Optional TLVs                           //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 20: PCEP-ERROR Object Body Format

Top      Up      ToC       Page 50 
   A PCEP-ERROR object is used to report a PCEP error and is
   characterized by an Error-Type that specifies the type of error and
   an Error-value that provides additional information about the error
   type.  Both the Error-Type and the Error-value are managed by IANA
   (see the IANA section).

   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Flags (8 bits):  no flag is currently defined.  This flag MUST be set
      to zero on transmission and MUST be ignored on receipt.

   Error-Type (8 bits):  defines the class of error.

   Error-value (8 bits):  provides additional details about the error.

   Optionally, the PCEP-ERROR object may contain additional TLVs so as
   to provide further information about the encountered error.

   A single PCErr message may contain multiple PCEP-ERROR objects.

Top      Up      ToC       Page 51 
   For each PCEP error, an Error-Type and an Error-value are defined.

   Error-Type    Meaning
      1          PCEP session establishment failure
                 Error-value=1: reception of an invalid Open message or
                                a non Open message.
                 Error-value=2: no Open message received before the
                                expiration of the OpenWait timer
                 Error-value=3: unacceptable and non-negotiable session
                                characteristics
                 Error-value=4: unacceptable but negotiable session
                                characteristics
                 Error-value=5: reception of a second Open message with
                                still unacceptable session
                                characteristics
                 Error-value=6: reception of a PCErr message proposing
                                unacceptable session characteristics
                 Error-value=7: No Keepalive or PCErr message received
                                before the expiration of the KeepWait
                                timer
      2          Capability not supported
      3          Unknown Object
                  Error-value=1: Unrecognized object class
                  Error-value=2: Unrecognized object Type
      4          Not supported object
                  Error-value=1: Not supported object class
                  Error-value=2: Not supported object Type
      5          Policy violation
                  Error-value=1: C bit of the METRIC object set
                                 (request rejected)
                  Error-value=2: O bit of the RP object set
                                 (request rejected)
      6          Mandatory Object missing
                  Error-value=1: RP object missing
                  Error-value=2: RRO object missing for a reoptimization
                                 request (R bit of the RP object set)
                                 when bandwidth is not equal to 0.
                  Error-value=3: END-POINTS object missing
      7          Synchronized path computation request missing
      8          Unknown request reference
      9          Attempt to establish a second PCEP session
      10         Reception of an invalid object
                  Error-value=1: reception of an object with P flag not
                  set although the P flag must be set according to this
                  specification.

Top      Up      ToC       Page 52 
   The error types listed above are described below.

   Error-Type=1: PCEP session establishment failure.

      If a malformed message is received, the receiving PCEP peer MUST
      send a PCErr message with Error-Type=1, Error-value=1.

      If no Open message is received before the expiration of the
      OpenWait timer, the receiving PCEP peer MUST send a PCErr message
      with Error-Type=1, Error-value=2 (see Appendix A for details).

      If one or more PCEP session characteristics are unacceptable by
      the receiving peer and are not negotiable, it MUST send a PCErr
      message with Error-Type=1, Error-value=3.

      If an Open message is received with unacceptable session
      characteristics but these characteristics are negotiable, the
      receiving PCEP peer MUST send a PCErr message with Error-Type-1,
      Error-value=4 (see Section 6.2 for details).

      If a second Open message is received during the PCEP session
      establishment phase and the session characteristics are still
      unacceptable, the receiving PCEP peer MUST send a PCErr message
      with Error-Type-1, Error-value=5 (see Section 6.2 for details).

      If a PCErr message is received during the PCEP session
      establishment phase that contains an Open message proposing
      unacceptable session characteristics, the receiving PCEP peer MUST
      send a PCErr message with Error-Type=1, Error-value=6.

      If neither a Keepalive message nor a PCErr message is received
      before the expiration of the KeepWait timer during the PCEP
      session establishment phase, the receiving PCEP peer MUST send a
      PCErr message with Error-Type=1, Error-value=7.

   Error-Type=2:  the PCE indicates that the path computation request
      cannot be honored because it does not support one or more required
      capability.  The corresponding path computation request MUST be
      cancelled.

   Error-Type=3 or Error-Type=4:  if a PCEP message is received that
      carries a PCEP object (with the P flag set) not recognized by the
      PCE or recognized but not supported, then the PCE MUST send a
      PCErr message with a PCEP-ERROR object (Error-Type=3 and 4,
      respectively).  In addition, the PCE MAY include in the PCErr
      message the unknown or not supported object.  The corresponding
      path computation request MUST be cancelled by the PCE without
      further notification.

Top      Up      ToC       Page 53 
   Error-Type=5:  if a path computation request is received that is not
      compliant with an agreed policy between the PCC and the PCE, the
      PCE MUST send a PCErr message with a PCEP-ERROR object (Error-
      Type=5).  The corresponding path computation MUST be cancelled.
      Policy-specific TLVs carried within the PCEP-ERROR object may be
      defined in other documents to specify the nature of the policy
      violation.

   Error-Type=6:  if a path computation request is received that does
      not contain a mandatory object, the PCE MUST send a PCErr message
      with a PCEP-ERROR object (Error-Type=6).  If there are multiple
      mandatory objects missing, the PCErr message MUST contain one
      PCEP-ERROR object per missing object.  The corresponding path
      computation MUST be cancelled.

   Error-Type=7:  if a PCC sends a synchronized path computation request
      to a PCE and the PCE does not receive all the synchronized path
      computation requests listed within the corresponding SVEC object
      after the expiration of the timer SyncTimer defined in
      Section 7.13.3, the PCE MUST send a PCErr message with a PCEP-
      ERROR object (Error-Type=7).  The corresponding synchronized path
      computation MUST be cancelled.  It is RECOMMENDED for the PCE to
      include the REQ-MISSING TLVs (defined below) that identify the
      missing requests.

      The REQ-MISSING TLV is compliant with the PCEP TLV format defined
      in section 7.1 and is comprised of 2 bytes for the type, 2 bytes
      specifying the TLV length (length of the value portion in bytes),
      followed by a fixed-length value field of 4 bytes.

         Type:   3
         Length: 4 bytes
         Value:  4 bytes that indicate the Request-ID-number that
                 corresponds to the missing request.

   Error-Type=8:  if a PCC receives a PCRep message related to an
      unknown path computation request, the PCC MUST send a PCErr
      message with a PCEP-ERROR object (Error-Type=8).  In addition, the
      PCC MUST include in the PCErr message the unknown RP object.

   Error-Type=9:  if a PCEP peer detects an attempt from another PCEP
      peer to establish a second PCEP session, it MUST send a PCErr
      message with Error-Type=9, Error-value=1.  The existing PCEP
      session MUST be preserved and all subsequent messages related to
      the tentative establishment of the second PCEP session MUST be
      silently ignored.

Top      Up      ToC       Page 54 
   Error-Type=10:  if a PCEP peers receives an object with the P flag
      not set although the P flag must be set according to this
      specification, it MUST send a PCErr message with Error-Type=10,
      Error-value=1.

7.16.  LOAD-BALANCING Object

   There are situations where no TE LSP with a bandwidth of X could be
   found by a PCE although such a bandwidth requirement could be
   satisfied by a set of TE LSPs such that the sum of their bandwidths
   is equal to X.  Thus, it might be useful for a PCC to request a set
   of TE LSPs so that the sum of their bandwidth is equal to X Mbit/s,
   with potentially some constraints on the number of TE LSPs and the
   minimum bandwidth of each of these TE LSPs.  Such a request is made
   by inserting a LOAD-BALANCING object in a PCReq message sent to a
   PCE.

   The LOAD-BALANCING object is optional.

   LOAD-BALANCING Object-Class is 14.

   LOAD-BALANCING Object-Type is 1.

   The format of the LOAD-BALANCING object body is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |     Flags     |     Max-LSP   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Min-Bandwidth                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 21: LOAD-BALANCING Object Body Format

   Reserved (16 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Flags (8 bits):  No flag is currently defined.  The Flags field MUST
      be set to zero on transmission and MUST be ignored on receipt.

   Max-LSP (8 bits):  maximum number of TE LSPs in the set.

   Min-Bandwidth (32 bits):  Specifies the minimum bandwidth of each
      element of the set of TE LSPs.  The bandwidth is encoded in 32
      bits in IEEE floating point format (see [IEEE.754.1985]),
      expressed in bytes per second.

Top      Up      ToC       Page 55 
   The LOAD-BALANCING object body has a fixed length of 8 bytes.

   If a PCC requests the computation of a set of TE LSPs so that the sum
   of their bandwidth is X, the maximum number of TE LSPs is N, and each
   TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH
   object specifying X as the required bandwidth and a LOAD-BALANCING
   object with the Max-LSP and Min-Bandwidth fields set to N and B,
   respectively.

7.17.  CLOSE Object

   The CLOSE object MUST be present in each Close message.  There MUST
   be only one CLOSE object per Close message.  If a Close message is
   received that contains more than one CLOSE object, the first CLOSE
   object is the one that must be processed.  Other CLOSE objects MUST
   be silently ignored.

   CLOSE Object-Class is 15.

   CLOSE Object-Type is 1.

   The format of the CLOSE object body is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |      Flags    |    Reason     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         Optional TLVs                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 22: CLOSE Object Format

   Reserved (16 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Flags (8 bits):  No flags are currently defined.  The Flag field MUST
      be set to zero on transmission and MUST be ignored on receipt.

   Reason (8 bits):  specifies the reason for closing the PCEP session.
      The setting of this field is optional.  IANA manages the codespace
      of the Reason field.  The following values are currently defined:

Top      Up      ToC       Page 56 
       Reasons
        Value        Meaning
          1          No explanation provided
          2          DeadTimer expired
          3          Reception of a malformed PCEP message
          4          Reception of an unacceptable number of unknown
                     requests/replies
          5          Reception of an unacceptable number of unrecognized
                     PCEP messages

   Optional TLVs may be included within the CLOSE object body.  The
   specification of such TLVs is outside the scope of this document.

8.  Manageability Considerations

   This section follows the guidance of [PCE-MANAGE].

8.1.  Control of Function and Policy

   A PCEP implementation SHOULD allow configuring the following PCEP
   session parameters on the implementation:

   o  The local Keepalive and DeadTimer (i.e., parameters sent by the
      PCEP peer in an Open message),

   o  The maximum acceptable remote Keepalive and DeadTimer (i.e.,
      parameters received from a peer in an Open message),

   o  Whether negotiation is enabled or disabled,

   o  If negotiation is allowed, the minimum acceptable Keepalive and
      DeadTimer timers received from a PCEP peer,

   o  The SyncTimer,

   o  The maximum number of sessions that can be set up,

   o  The request timer, the amount of time a PCC waits for a reply
      before resending its path computation requests (potentially to an
      alternate PCE),

   o  The MAX-UNKNOWN-REQUESTS,

   o  The MAX-UNKNOWN-MESSAGES.

   These parameters may be configured as default parameters for any PCEP
   session the PCEP speaker participates in, or may apply to a specific
   session with a given PCEP peer or to a specific group of sessions

Top      Up      ToC       Page 57 
   with a specific group of PCEP peers.  A PCEP implementation SHOULD
   allow configuring the initiation of a PCEP session with a selected
   subset of discovered PCEs.  Note that PCE selection is a local
   implementation issue.  A PCEP implementation SHOULD allow configuring
   a specific PCEP session with a given PCEP peer.  This includes the
   configuration of the following parameters:

   o  The IP address of the PCEP peer,

   o  The PCEP speaker role: PCC, PCE, or both,

   o  Whether the PCEP speaker should initiate the PCEP session or wait
      for initiation by the peer,

   o  The PCEP session parameters, as listed above, if they differ from
      the default parameters,

   o  A set of PCEP policies including the type of operations allowed
      for the PCEP peer (e.g., diverse path computation,
      synchronization, etc.).

   A PCEP implementation MUST allow restricting the set of PCEP peers
   that can initiate a PCEP session with the PCEP speaker (e.g., list of
   authorized PCEP peers, all PCEP peers in the area, all PCEP peers in
   the AS).

8.2.  Information and Data Models

   A PCEP MIB module is defined in [PCEP-MIB] that describes managed
   objects for modeling of PCEP communication including:

   o  PCEP client configuration and status,

   o  PCEP peer configuration and information,

   o  PCEP session configuration and information,

   o  Notifications to indicate PCEP session changes.

8.3.  Liveness Detection and Monitoring

   PCEP includes a keepalive mechanism to check the liveliness of a PCEP
   peer and a notification procedure allowing a PCE to advertise its
   overloaded state to a PCC.  Also, procedures in order to monitor the
   liveliness and performances of a given PCE chain (in case of
   multiple-PCE path computation) are defined in [PCE-MONITOR].

Top      Up      ToC       Page 58 
8.4.  Verifying Correct Operation

   Verifying the correct operation of a PCEP communication can be
   performed by monitoring various parameters.  A PCEP implementation
   SHOULD provide the following parameters:

   o  Response time (minimum, average, and maximum), on a per-PCE-peer
      basis,

   o  PCEP session failures,

   o  Amount of time the session has been in active state,

   o  Number of corrupted messages,

   o  Number of failed computations,

   o  Number of requests for which no reply has been received after the
      expiration of a configurable timer and by verifying that at least
      one path exists that satisfies the set of constraints.

   A PCEP implementation SHOULD log error events (e.g., corrupted
   messages, unrecognized objects).

8.5.  Requirements on Other Protocols and Functional Components

   PCEP does not put any new requirements on other protocols.  As PCEP
   relies on the TCP transport protocol, PCEP management can make use of
   TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).

   The PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an
   impact on PCEP.  To avoid that a high frequency of PCE Discoveries/
   Disappearances triggers a high frequency of PCEP session setups/
   deletions, it is RECOMMENDED to introduce some dampening for
   establishment of PCEP sessions.

8.6.  Impact on Network Operation

   In order to avoid any unacceptable impact on network operations, an
   implementation SHOULD allow a limit to be placed on the number of
   sessions that can be set up on a PCEP speaker, and MAY allow a limit
   to be placed on the rate of messages sent by a PCEP speaker and
   received from a peer.  It MAY also allow sending a notification when
   a rate threshold is reached.


Next RFC Part