Subject: RE: Sender Template Doubt

From: "Feng, Mark" <[email-masked]>
Date: Thu, 18 Jul 2002 12:30:46 -0700

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Thursday, July 18, 2002 7:02 AM
> To: [email-masked]
> Subject: Re: Sender Template Doubt
> 
> 
> Feng, Mark wrote:
> > Also keep in mind that, with the interfaces "proposed" in 
> RFC2205, the
> > sender address is used to force the message to go out at a 
> particular
> > interface, overwriting the routing module. Obviously, this 
> is implementation
> > dependent. Like David mentioned in the previous message, there is no
> > "standard" way of setting the sender address.
> 
> I don't think this is correct.  Without explicit routes (which is how 
> RFC 2205 is defined), Path messages must always follow the routing 
> table's route to the session address.
>

I think it is part of the requirement for RSVP. 

Following is the description for the particular parameter:
"              -    Source_Address

                   This is the address of the interface from which the
                   data will be sent.  If it is omitted, a default
                   interface will be used.  This parameter is needed
                   only on a multihomed sender host."

Following is the excerpt from section 3.11.5

"         o    Outgoing Link Specification

              RSVP must be able to force a (multicast) datagram to be
              sent on a specific outgoing real or virtual link,
              bypassing the normal routing mechanism.  A virtual link
              might be a multicast tunnel, for example.  Outgoing link
              specification is necessary to send different versions of
              an outgoing Path message on different interfaces, and to
              avoid routing loops in some cases.

         o    Source Address and TTL Specification

              RSVP must be able to specify the IP source address and IP
              TTL to be used when sending Path messages."
 
> The interfaces in section 3.11.1 of RFC 2205 are _NOT_ 
> describing rules 
> of forming packets.  It is proposing one possible API that 
> can be used 
> by applications to make requests of an RSVP protocol stack.
> 
> The interface selection rule in the SENDER() call is simply to bind a 
> connection to an interface, much like the bind() call does on 
> the server 
> side of an ordinary socket.  Note also that it may be left 
> undefined - 
> much like INADDR_ANY can be used in bind().  The implementation is no 
> required to blindly copy this value into the SENDER_TEMPLATE 
> object of 
> the Path message.
> 
> Section 3.11 of RFC 2205 (and all of RFC 2209) should be seen only as 
> informational.  They are defining one possible 
> API/implementation, but 
> are not defining the only possible one.  Depending on your switch's 
> overall software architecture, that design may be pretty bad for you.
> 

Right. I agree it is only a "proposed" interface. As to the value in sender
template, it can be set to whatever sensible values.

> -- David

- Mark

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Jul 2002 16:11:20 -0400

>                    only on a multihomed sender host."

This is describing a parameter for an application-to-stack API call.  It
defines the interface that the Path message willcome from.  It doesn't
say a thing about whether that interface's address must appear in the
SENDER_TEMPLATE object.

 >               avoid routing loops in some cases.

This is not an RSVP protocol requirement.  This is a requirement that an
IP stack must meet in order to be possible to implement RSVP over it.

 >               RSVP must be able to specify the IP source address and
 >               IP TTL to be used when sending Path messages."

Again, this isn't a requirement for RSVP, but is a requirement for an IP
stack, in order to be possible to implement RSVP over it.

-- David