Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels

Voir toute la rfc dans une seule page

Télécharger le PDF

RFC 4804         RSVP Aggregation over MPLS TE Tunnels     February 2007


   In the former case, admission control over the final TE tunnel (and
   forwarding of E2E Resv message upstream toward the sender) would only
   occur when the Aggregator received the subsequent E2E Resv message
   (that will be sent by the Deaggregator in response to the resent E2E
   Path).  In the latter case, admission control over the final tunnel
   is carried out immediately by the Aggregator, and if successful the
   E2E Resv message is generated upstream toward the sender.

   Upon receipt of an E2E ResvConf from the Aggregator, the Deaggregator
   MUST forward the E2E ResvConf downstream toward the receiver.  In
   doing so, the Deaggregator sets the destination address in the IP
   header of the E2E ResvConf message to the IP address found in the
   RESV_CONFIRM object of the corresponding Resv.  The Deaggregator also
   sets the Router Alert.

4.7.  Forwarding of E2E Traffic by the Aggregator

   When the Aggregator receives a data packet belonging to an E2E
   reservations currently mapped over a given TE tunnel, the Aggregator
   MUST encapsulate the packet into that TE tunnel.

   If the Aggregator and Deaggregator are also acting as IPsec Security
   Gateways, the Aggregator MUST also encapsulate the data packet into
   the relevant IPsec tunnel terminating on the Deaggregator before
   transmission into the MPLS TE tunnel.

4.8.  Removal of E2E Reservations

   E2E reservations are removed in the usual way via PathTear, ResvTear,
   timeout, or as the result of an error condition.  When a reservation
   is removed, the Aggregator MUST update its local view of the
   resources available on the corresponding TE tunnel accordingly.

4.9.  Removal of the TE Tunnel

   Should a TE tunnel go away (presumably due to a configuration change,
   route change, or policy event), the Aggregator behaves much like a
   conventional RSVP router in the face of a link failure.  That is, it
   may try to forward the Path messages onto another tunnel, if routing
   and policy permit, or it may send Path_Error messages to the sender
   if a suitable tunnel does not exist.  In case the Path messages are
   forwarded onto another tunnel, which terminates on a different
   Deaggregator, or the reservation is torn down via Path Error
   messages, the reservation state established on the router acting as
   the Deaggregator before the TE tunnel went away, will time out since
   it will no longer be refreshed.





Faucheur                    Standards Track                    [Page 14]