The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Clarification reg Label object verification
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
--------------------------------------------------------------------------------
|
|