The MPLS WG Archive

[Apratim Mukherjee <ApratimM@netbrahma.com>]

Hi 
RFC 2205 clearly states the three ways in which reservations can be made in
Rsvp ( SE , FF and Wildcard ) . Further , the draft states that the Wildcard
style is not permitted for Rsvp-Te . Thus , we are left with two ways in
which to make the reservation . 
a) SE . In this case , what you are saying is correct . All data packets
from flows originating from S1,S2,S3 and S4 will flow into a 'pipe' with a
maximum capacity of 10 Mbps . If explicit routes are being used , there
would be two different routes having reservation of 10 Mbps each ! 
b) FF , wherein all flows have different reservations and the whole scenario
is like  a cable with 4 lines , one for each sender . Hence S1 gets a line
of 1 Mbps , S2 of 10 Mpbs and so on . As is clear , there is a wastage in
THIS case since no  sharing is taking place .
c) Also , there is no restriction on keeping each  sender in different
tunnels , or for that matter , make two tunnels , one having one SE styled
reservation of 1 Mbps for S1 and S3 and another tunnel having one SE styled
reservation of 10 Mbps for S2 and S4 . 
Thus ,Rsvp and Rsvp-te gives us many choices for handling of reservations
and it is the decision of the administrator / policy agent to make the best
decision from these choices. 

Apratim


> ----------
> From: 	Feng, Mark[SMTP:m_feng@trillium.com]
> Sent: 	Friday, August 10, 2001 7:32 AM
> To: 	'David Charlap'; mpls@UU.NET
> Subject: 	RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> 
> Sorry, I still have some doubts on this that I hope someone can shed some
> light on.
> 
> With what we discussed below, what would happen is that, if S1, S3 only
> need
> 1M of bandwidth, and S2, S4 need 10M, on the path where S1, S3 take, even
> if
> they only need 1M, they will get a request of 10M and as a result, get a
> reservation of 10M. This seems to be wasteful on that particular path. 
> 
> Would this be potential problem?
> 
> I really cannot find any reference/explanation in RFC2205 and the RSVP-TE
> draft.
> 
> Thanks in advance.
> 
> - Mark
> 
> > -----Original Message-----
> > From: David Charlap [mailto:david.charlap@marconi.com]
> > Sent: Tuesday, July 17, 2001 12:15 PM
> > To: mpls@UU.NET
> > Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> > 
> > 
> > "Feng, Mark" wrote:
> > >>> 
> > >>>                     ______
> > >>>                    |      |
> > >>>                +---|      |---+
> > >>>                |   |______|   |
> > >>>                |              |
> > >>>                |s1,s3         |s1,s3
> > >>>  s1,s2 ______  |              |  ______
> > >>>  -----|      |-+              +-|      | s1,s2,s3,s4
> > >>>  -----|      |-+              +-|      |------
> > >>>  s3,s4|______| |              | |______|
> > >>>                |s2,s4_____    |s2,s4
> > >>>                |   |      |   |
> > >>>                +---|      |---+
> > >>>                    |______|
> > >>>
> > >>> Is this possible in RSVP-TE?
> > >>
> > >> SE style only shares resources among LSPs that share a single
> > >> session.
> > > 
> > > Sorry I didn't make it clear. All the senders in the diagram belong
> > > to the same session.
> > 
> > Then all senders will get the same reservation.
> > 
> > > Considering the first node on the diagram, S1, S2 come in at one
> > > interface, and S3, S4 come in at a different interface. Even though
> > > they belong to the same session, the Path messages travel a
> > > different path. This is somewhat different from RSVP/RFC 2205,
> > > where, in unicast, Path messages for the same session take the
> > > same path.
> > > 
> > > In this case, because Path messages take different routes, Resv
> > > messages will arrive at different interfaces, with potentially
> > > different resource requirements. The process of handling the
> > > resource allocation at various interfaces, as a result, is
> > > somewhat different from RSVP/RFC 2205.
> > 
> > Not really.  Reservations all come from the egress.  All LSPs share a
> > common egress router.  Whatever reservation it chooses for one sender
> > must be used for all of them.  This Resv message may split up (with
> > different filterspecs in the flow descriptor) as it follows to the
> > different PHOP routers, but they all reserve the same resources.  When
> > they come back together at the ingress router, they are still 
> > the same.
> > 
> > If the egress router tries to send different flowspecs for 
> > each sender,
> > then it is in error.
> > 
>