The MPLS WG Archive

["Andrew G. Malis" <Andy.Malis@vivacenetworks.com>]

David,

According to http://www.iana.org/assignments/rsvp-parameters, the range 
224-255 is available for FCFS allocation.  It doesn't specify any other 
particular allocation requirements.

Cheers,
Andy

--------

At 7/30/2002 10:22 AM -0400, David Charlap wrote:
>Andrew G. Malis wrote:
>>For RSVP-TE (and classical RSVP) private extensions are typically handled 
>>by asking IANA for a new Class Number allocation in the range 224-255.
>
>IANA is the organization that selects standard numbers.  But a private 
>extension, that is not an RFC, does not normally get an IANA 
>allocation.  Even drafts that are well on their way to becoming RFCs don't 
>usually get numbers assigned until it actually becomes an RFC.
>
>As for the range, IANA may assign from anywhere, not just 224-255.
>
>There are three ranges of object classes that dictate how a router that 
>doesn't support the object should respond to it.  The range chosen depends 
>on the required behavior:
>
>1-127 - non-supporting routers will not process the message at all, but 
>will return PathErr or ResvErr.
>
>128-191 - non-supporting routers will drop the object but process the rest 
>of the message.
>
>192-255 - non-supporting routers will forward the object without 
>processing it.
>
>There is absolutely nothing special about the range 224-255.  And there is 
>no region reserved for vendor-proprietary class numbers, so it is always 
>possible for a non-standard class to conflict with another class (let 
>alone with another vendor's non-standard class.)
>
>This is a problem with RSVP, but there's no real solution as long as the 
>class ID remains an 8-bit value.  (And the kind of radical change needed 
>to make it wider would probably be unwelcome, given the number of existing 
>implementations.)
>
>-- David