Subject: [CCAMP] [mpls][rsvp] make-before-break signalling

From: Ajeet Pal Singh Gill <[email-masked]>
Date: Thu, 9 Sep 2010 18:44:06 +0530

Hello

       RFC 3209  section "4.6.4. Reroute and Bandwidth Increase Procedure" defines that make-before-break mechanism for a path. Eventually it specifies that the one new path message is sent only with the new sender template object which has a new LSP ID.

 RESV message response is specified as follows in the RFC.

<<<<<<<
The egress node responds with a Resv message with an SE flow
   descriptor formatted as:

      <FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
      <new_LABEL_OBJECT>

How is the association of the making instance (LSP) and the breaking instance( LSP)  signaled in the PATH message?
 It may not be needed in case of only 1 instance in the tunnel. But it may be needed in case of multiple instances are active in one tunnel.

Let me try to take an example -

Now lets take a case of Tunnel A multiple working instances ( lets say for example instance 1 , 2, and 3 ) in this tunnel.
Now as the RFC specifies all the three instances would be specidied with SE-style  requested in the PATH message.
Now if user wants to do a make-before-break operation on instance 1 only , picks up a new instance ID 4 for MBB of instance 1.  the rsvp module will signal in the path message.

In this case there would be confusion on the intermediate routers as to which two LSPs the bandwidth should be shared?

 Can 'Association Object' specified in RFC 4872 be used for this purpose of make-brefore-break signalling?

Thanks
Ajeet

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."