Re: Connection Deletion in GMPLS

[Fong Liaw <fongliaw@yahoo.com>]

Manoj

When controlling optical cross connects, it is felt
that the performance target for a non-fault triggered
deletion does not need to be superfast therefore
message processing time is not a major concern
Instead,  to preserve the semantic of RSVP protocol
and be compatible to majority of the deployed MPLS
networks is the goal.

If you are concerned about failure situation, 
Notify is the correct (and first) message to use.
It would likely trigger protection first and then
deletion can happen (slowly) after that.

Regards,
-Fong


--- manoj juneja <manojkumarjuneja@hotmail.com> wrote:
> [ post by non-subscriber.  with the massive amount
> of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix
> subscription addresses! ]
> 
> Hi All,
>        In GMPLS, the graceful connection deletion is
> done by first
> sending the Path message with admin status as down
> (D & R bits on) and
> then the egress node can send the PathErr message
> with cause 'Path
> State Removed'.
> What is the requirement of sending the complete PATH
> message ? This
> message could (possibly a new message type) have
> been kept very simple
> with session and admin status objects. There are
> many parameters in
> path message which are not required for connection
> deletion viz
> TIME_VALUE, ERO, RSVP_HOP, PROTECTION, LABEL
> REQUEST, SESSION
> ATTRIBUTES, POLICY DATA etc. If one calculates the
> size of these
> parameters for a connection it can run in to more
> than 50 bytes. This
> means the control channel bandwidth is being wasted
> for each and every
> connection at the time of graceful connection
> deletion by transmitting
> such large messages.
> Is there any reason for not keeping different
> (possibly new or could
> have made use of Notify message) message type for
> connection deletion ?
> 
> Furthermore, as the complete PATH message need to go
> through all the nodes 
> in the path, more processing time will be required
> to parse/process the 
> large message like PATH as compared to some small
> message like Notify etc.
> This type of processing overhead will be there for
> each and every call/LSP 
> in GMPLS.
> 
> Please help me in understanding this issue.
> 
> Regards,
> manoj.
> 
>
_________________________________________________________________
> Join the world’s largest e-mail service with MSN
> Hotmail. 
> http://www.hotmail.com
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com