Subject: Rsvp Confirm Messages .

From: Manoj Agiwal <[email-masked]>
Date: Wed, 5 Sep 2001 12:38:10 +0530

Hi ,
      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 . 
     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 .
     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 .
Regards ,
Manoj

---

From: David Charlap <[email-masked]>
Date: Wed, 05 Sep 2001 10:51:20 -0400

Manoj Agiwal wrote:
> 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.

> 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.

> 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