The MPLS WG Archive

[<francis.arts@alcatel.be>]

Considering RSVP the following applies [PHP = Penultimate Hop Popping]:

1/ Logic in last (ultimate) hop.
The last (ultimate) hop requests the penultimate hop to apply PHP by specifying the 'implicit null label' in the RESV message.

2/ Logic in penultimate hop.
* RSVP has no mechanism that allows the penultimate hop to specify **up front** (in the PATH message) that it does not support PHP.
* If the last (ultimate) hop requests the penultimate hop to do PHP, while the penultimate hop does not support this feature, the following procedure applies:  The penultimate hop returns a RESV ERR message to the last hop with an error code of "routing
problem" and an error value of "unacceptable label  value".


This behavior is described in section 4.1.1.2 of <draft-ietf-mpls-rsvp-lsp-tunnel-08> (also included for reference below).

     Francis.



---------------------------------

4.1.1.2. Upstream

   A node uses the label carried in the LABEL object as the outgoing
   label associated with the sender.  The router allocates a new label
   and binds it to the incoming interface of this session/sender.  This
   is the same interface that the router uses to forward Resv messages
   to the previous hops.

   Several circumstance can lead to an unacceptable label.

     1. the node is a merge incapable ATM switch but the downstream node
        has assigned the same label to two senders.

***2. The implicit null label was assigned, but the node is not
***    capable of doing a penultimate pop for the associated L3PID

     3. The assigned label is outside the requested label range

   In any of these events the node send a ResvErr message with an error
   code of "routing problem" and an error value of "unacceptable label
   value".