Subject: Clarification reg Label object verification

From: ARUMUGAM R <[email-masked]>
Date: Fri, 28 Jul 2000 19:45:42 +0530

Hi,
I have a couple of doubts between section 4.1.1.1 and section 4.1.1.2
1.
section 4.1.1.1
The downstream node selects a label to represent the flow.  If a
   label range has been specified in the label request, the label must
   be drawn from that range.  If no label is available the node sends a
   PathErr message with an error code of "routing problem" and an error
   value of "label allocation failure".

section     4.1.1.2
3. The assigned label is outside the requested label range

   In any of these events the node send a ResvErr message with an error
   code of "routing problem" and an error value of "unacceptable label
   value".
section 4.1.1.1 says label MUST be drawn from the range, else send path err. Isn't the node
conforming to this will return a valid label ? what is the need to recheck the label and send a ResvErr.
where can this schenario can happen? Isn't a performance overhead?

2.
section 4.1.1.1
In the case of ATM, one further condition applies.  Some ATM nodes
   are not capable of merging streams.  These nodes may indicate this by
   setting a bit in the label request.  The M-bit in the LABEL_REQUEST
   object of C-Type 2, label request with ATM label range, serves this
   purpose.  The M-bit SHOULD be set by nodes which are merge capable.
   If for any senders the M-bit is not set, the downstream node MUST
   assign unique labels to those senders.

section     4.1.1.2
     1. the node is a merge incapable ATM switch but the downstream node
        has assigned the same label to two senders

The same comment is valid here too. In this case still it increases performance overhead compared to the 
first case. The LSR has to search all the tunnels passing through it, whether the particular label had been 
alloted to some other tunnel.

Once the node is conforming to section 4.1.1.1, I believe rechecking the assigned values is purely a
performance overhead. Any comments from authors for the inclusion of new error values for these two
cases while the second case being fine.

Thanks in advance
Regards
Aru
--------------------------------------------------------------------------------
Arumugam R
Senior Software Engineer,
Future Software Pvt Ltd.
Chennai - 35
Fone-4330550 Extn-332
--------------------------------------------------------------------------------