The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00324



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Session Attributes

  • From: Alia Atlas <aatlas@avici.com>
  • Date: Thu, 19 Jul 2001 10:53:20 -0500
  • Cc: "Feng, Mark" <m_feng@trillium.com>, "'Ping Pan'" <pingpan@juniper.net>, "'mpls@uu.net'" <mpls@UU.NET>

The SESSION_ATTRIBUTES are per LSP.  Consider the case where the operator
decides to change the holding & reserving priority used for the tunnel.
Then a make-before-break is done, where the new LSP is signalled with the
new priorities in the SESSION_ATTRIBUTES object before the old LSP is torn
down. 

Also, consider the case of doing fast-reroute, where the backup LSP belongs
to the same session as the primary LSP, but may have a different holding
and reserving priority than the primary (whether due to the contents of the
FAST_REROUTE object, if used, or to operator configuration at the potential
PLR).

Dropping a PATH message because it has different information in its
SESSION_ATTRIBUTES object than a previous PATH message for the same SESSION
does not make sense for either of the above scenarios.

Alia

At 09:26 AM 7/19/01 +0530, Khuzema Pithewan wrote:
>Hi,
>
>I am given to understand that, when RSVP-TE works with MPLS, the LSP
>setup is control driven, means, there should be some Administrator which
>is responsible to configure the session attributes for the session, if
>administrator wants to give different session attributes for the path
>messages grouped on per ingress basis, then Extended tunnel Id can be
>used. Now if there is case of reception of PATH messages with different
>session attributes in same session, then its a result of
>mis-configuration and I believe in that case path message should be
>dropped. But again if(?) we say setup/holding priorities are attributes
>of LSP then what is significance of keeping them per session?
>
>Khuzema.
>
>Feng, Mark" wrote:
>> 
>> Ping,
>> 
>> I know the name implies the attributes belong to the session. But does it
>> mean all senders, i.e. ingress routers, need to have the same session
>> attributes? Should the transit nodes reject the new Path message, if the
>> session attributes are different from other senders of the same session,
>> because there is no rule on "merging" the session attributes?
>> 
>> Thanks.
>> 
>> - Mark
>> 
>> > -----Original Message-----
>> > From: Ping Pan [mailto:pingpan@juniper.net]
>> > Sent: Tuesday, July 17, 2001 9:37 PM
>> > To: Khuzema Pithewan
>> > Cc: rsvp@ISI.EDU
>> > Subject: Re: Session Attributes
>> >
>> >
>> > Khuzema,
>> >
>> > First, this question should go to the mpls list. Please forward the
>> > discussion to that list. Second, the question itself is implementation
>> > dependent. Finally, since the Session Attribute object is to describe
>> > the properties of a RSVP session, in a normal implementation,
>> > it should
>> > be kept where you keep the session.
>> >
>> > - Ping
>> >
>> > Khuzema Pithewan wrote:
>> > >
>> > > Hi,
>> > >
>> > > Session Attribute Object in RSVP-TE contains some flags , setup and
>> > > holding priority and some session related info.
>> > >
>> > >  My doubt is , if this object is per session or per LSP,
>> > because name
>> > > suggest
>> > >  that it is per session, but holding/setup priorities are
>> > the attributes
>> > > of a LSP.
>> > >  so basically where to keep this Object,?? in PSB or Session???
>> > >
>> > > Khuzema.
>> >
>