The MPLS WG Archive

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

Manoj Agiwal wrote:
> 
> I have a doubt in the way Confirm Objects are forwarded in the Resv
> message from Egress to Ingress Node in case of Fixed Filter . The
> resv message contains only one confirm object for all the flow
> descriptors .

Correct.  There is one RESV_CONFIRM object in a given Resv message.

> In case of Fixed Filter does the intermediate LSRs just forward the
> confirm object , as the reservation is never in place and only
> the ingress node needs to generate Rack.

Intermediate nodes must hold the confirm object.  The reason is that
intermediate nodes may end up generating the ResvConf message.  This can
happen in classical RSVP, when Resv messages from multiple next-hops are
merged.

In the case of MPLS, where Resv merging won't happen (the only cases of
multiple next-hops in a single session will involve all having identical
FLOWSPECs, since all Resv messages in a session will originate from a
single egress router.)  It may be possible to shortcut around the issue,
given this assumption, but that's an implementation detail.

> Since there is only one confirm object in the Reserve message for all
> the flow descriptors in case of Fixed Filter , as per RFC 2209
> this confirm object is copied to all the RSBs . Thus at ingress
> will RAck will be sent for all the RSBs . The problem is Ingress
> will send Rack multiple times for the RSB for which the reservation
> was already in place .

This is not an issue.

See section 3.1.9 of RFC 2205, describing the ResvConf message.  Note
the last paragraph, which reads:

	... The flow descriptor list specifies the particular
	reservations that are being confirmed; it may be a
	subset of the flow descriptor list of the Resv that
	requested the confirmation.

In other words, there is nothing wrong with sending a separate ResvConf
message for each sender in the session.  Just include an appropriate
flow descriptor in the messages so that each sender is only confirmed
once.

If your code wants to bundle them all together and send a single
ResvConf, that's OK too.  The fact that RFC 2209 is talking about a
specific function call is irrelevant.

RFC 2209 is an informational draft, not standards track.  There is no
requirement that your internal code design match that of RFC 2209.  As
long as your code produces correct external behavior (RFC 2205 and
appropriate extensions), it will be OK.  RFC 2209 is one possible way if
implementing the protocol, but it is not the only possible way.

-- David