The MPLS WG Archive

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

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