The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

rsvp te wrote:
> David Charlap wrote:
>>
>> It is an unknown class number.  the reason you are not getting a
>> ResvErr is that the switch can not send you one.  A SESSION object
>> is required for sending a ResvErr, but the incoming message does
>> not have one.  Therefore, it is impossible to generate a legal
>> ResvErr message.  So nothing is generated.
> 
> Then which field I should to put this unknown class number 127 in
> the resv msg in order to let Ingress to send me this ResvErr msg
> out.

You just don't get it.

You can not generate a ResvErr message if you don't have the objects
that are mandatory for ResvErr messages.  You can't just invent them out
of thin air.  If you change the class of a mandatory object, then that
object's identity will change and the switch will be completely unable
to recognize it.

You are asking for the impossible.

>>> Also what is the unknown type number mentioned in the rsvp msg?
>>
> > Unknown type?  You mean unknown message type in the common
>> header? There is no error message for this.  This is one of the
>> errors where RFC 2205 explicitly states that the packet is to be
>> silently dropped.
> 
> No, I mean the what is unknown c-type for rsvp msg, basically I
> want to send out Resv msg with unknown ctype in one field of Resv
> msg, and then Ingress will send ResvErr msg back with error code
> unknown ctype.
> 
> Basically I will to test this senario to get the ResvErr msg back
> with error code 13/14.

If the object with the illegal C-Type is not mandatory for generating
the ResvErr message, there shouldn't be any problem.  If you change the
C-Type of an object that is mandatory for ResvErr messages, it is likely
that the error won't be generated, since the object could not be parsed.

If the switch does not have the ResvErr's mandatory objects, it will be
unable to generate the error message.

-- David