The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

janani wrote:
> 
>      i am at present reading the draft "RSVP-TE: Extensions to RSVP
> for LSP Tunnels (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt)"
> i have the following doubts.
> 
>   1.  in section 2.4.2., while explaining the Wildcard Filter (WF)
>      Reservation Style it is said that .."This style is useful for
>      applications in which not all senders send traffic at the same
>      time.......If,however, all senders send simultaneously, then
>      there is no means of getting the proper reservations made. Either
>      the reserved bandwidth on links close to the destination will be
>      less than what is required or then the reserved bandwidth on
>      links close to some senders will be greater than what is
>      required. This restricts the applicability of WF for traffic
>      engineering purposes."
> 
> ..but what i feel is that the same overhead that is described above
> could also apply for Shared Explicit Reservation style also. if i am
> missing anything here could anyone point out the difference in the two
> reservation styles ?

WF style has no admission control.  All packets that match the session
information (IP destination for straight RSVP, tunnel egress for MPLS)
must automatically get the reserved resources, regardless of sender
information (IP source for straight RSVP, tunnel ingress for MPLS).

This is diametrically opposite to the MPLS concept, where an ingress
node decides which packets get the reserved resources (by way of the
label), and transit routers forward them according to this label,
regardless of the packet's content.

> 2.        in the same section it is said that ".....because of the
> merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF
> reservations. "
> 
> can anyone point out the reason as to why WF resv style does not use
> ERO.   pointers to archives could aslo be sufficent.

You can't wildcard-in all packets that match a destination if these
packets are following an explicit route.  Even conceptually, it is
impossible.  Once a packet is placed in an LSP, routers must forward
them according to the label, and not according to anything else.

-- David