Subject: Re: How is penultimate label popping requested/discouraged by signalling?

From: [email-masked]
Date: Tue, 12 Jun 2001 18:54:09 +0200

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

---

From: <[email-masked]>
Date: Thu, 21 Jun 2001 17:03:14 -0700

Francis.

4.1.1.2. Upstream