The MPLS WG Archive

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

I know about the comment in IANA's file, and I have no idea what they're 
actually talking about.

They _DO_ make allocations from elsewhere.  The DIFFSERV object (class 
65) was not assigned until RFC 3270 went on-line in May.

And the DCLASS object (225 - in that region) is not proprietary - it's 
defined by RFC 2996.

-- David


Andrew G. Malis wrote:
> 
> 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
> 
>