Subject: RE: Sender Template Doubt

From: "Feng, Mark" <[email-masked]>
Date: Wed, 17 Jul 2002 15:26:12 -0700

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.

- Mark

> -----Original Message-----
> From: Jay Karthik [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 3:20 PM
> To: manoj juneja; [email-masked]
> Cc: [email-masked]
> Subject: Re: Sender Template Doubt
> 
> 
> At 03:00 PM 7/17/02 -0700, manoj juneja wrote:
> >Jay,
> >        On a node the PSB is identified by the session object and its
> >corresponding sender_template object. Let us take the case where two
> >RSVP-TE tunnels are established between two nodes A and B. The
> >destination address for both the RSVP sessions is same. 
> Furthermore, if
> >the ingress node sends it's router Id in sender template then how a
> >transit node distinguishes between these two PSBs ? Is the 
> distinction
> >between these two PSBs is done on the basis of LSP Id and 
> Tunnel Id as
> >the other fields of SESSION and SENDER_TEMPLATE objects will be same.
> 
> Yes.  LSP tunnels are identified by a combination of the SESSION 
> and  SENDER_TEMPLATE objects.
> 
> Regards,
> Jay
> 
> >Regards,
> >manoj.
> >
> >
> >>From: Jay Karthik <[email-masked]>
> >>To: "manoj juneja" <[email-masked]>, [email-masked]
> >>CC: [email-masked]
> >>Subject: Re: Sender Template Doubt
> >>Date: Wed, 17 Jul 2002 17:32:20 -0400
> >>
> >>At 01:01 PM 7/17/02 -0700, manoj juneja wrote:
> >>>Hi All,
> >>>          I have a doubt regarding sender template object 
> in RSVP-TE. 
> >>> Can I fill the sender address in sender template object 
> same as PHOP 
> >>> address (in RSVP_HOP object) at the ingress node in the 
> outgoing path message ?
> >>>
> >>>As per my understanding, the PHOP object will change at 
> every hop in the 
> >>>path message but the sender template remanins the same.
> >>>
> >>>At the ingress node, should the sender address in sender 
> template object 
> >>>be filled with the IP address of the outgoing interface 
> over which the 
> >>>path message is to be sent out ?
> >>
> >>It is not mandatory to send the IP address of the outgoing 
> i/f.  Usually 
> >>it is the router-id of the Ingress. (However for a backup 
> tunnel <if any> 
> >>you could pick any address besides the router-id, as the 
> sender address 
> >>in the SENDER_TEMPLATE).
> >>
> >>Jay
> >>
> >>
> >>
> >>>Regards,
> >>>manoj.
> >>>
> >>>_________________________________________________________________
> >>>Send and receive Hotmail on your mobile device: 
http://mobile.msn.com
>
>
>
>
>_________________________________________________________________
>MSN Photos is the easiest way to share and print your photos: 
>http://photos.msn.com/support/worldwide.aspx
>

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Jul 2002 10:02:21 -0400

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

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.

-- David