Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels
Voir toute la rfc dans une seule page
Page : 14 / 31
Télécharger le PDF
Auteur(s) : Editor F. Le Faucheur
Classé sous : Multiprotocol label switching
, Traffic engineering
, Diffserv-aware mpls traffic engineering
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]