[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ITU related IANA assignments for RSVP
This is what I think I understand is being requested by ITU/OIF
with the 3 documents w.r.t. RSVP. Maybe based on this you can
get closer to proposed assignments in the RSVP space?
>From http://www.iana.org/assignments/rsvp-parameters I find:
- RSVP has classes of data objects that are Identified by
a Class Name and a Class Number.
Within a class, there are Class Types, also named C-types.
I believe some people also use the term sub-objects for C-types.
There is a range of Class Numbers (224-255) that is
assigned on FCFS basis
Within a Class, I think the assignment of C-types is under
guidance of the specific Class.
- Error Codes and Globally-Defined Error Value Sub-Codes
An Error Code is an 8-bit quantity that appears in an ERROR_SPEC
object to broadly define an error condition. With each Error Code
there may be a 16-bit Error Value that further specifies the cause
of the error. Error Values may be globally defined, in which case
the sub-code component is assigned by IANA [RFC2205].
Now the documents:
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
- This document is asking for the assignment of 2
Class Names/Class Numbers in the FCFS space (224-255)
Formally no documentation needed (I think), but IANA asked
for supporting documentations and so they provided that.
They ask for this in sect 12.2 and they want:
CALL_ID and CALL_OPS
Within each of these classes they want a few C-types, which
I think can be done under their own guidance (if any is needed)
the two C-types within the CALL_ID class both have another
type field (under their control of course) and they provide
IANA guidelines as to how to assign values for that field.
They also have 5 values that they want to assign immediately
as part of this document. This sounds to me as if they are
asking IANA to keep a new registry (or sub-registry) for
values in this type field in these C-types in this Class.
- They also ask for another assignment in a field of a new
C-type (EGRESS_LABEL) in the GENERALIZED_UNI class.
They ask for this in sect 12.2.
This Class and C-type do not yet exist, they are part of the
Bala document But I think the Bala document controls if/how
C-types within that GENERALIZED_UNI class and field within
C-types can be assigned. Since they are supporting/referencing
each other, I think that this is OK (once the GENERALIZED_UNI
class has been assigned of course).
See below under bala document though, it is kind of strange
that the bala doc states in sect 4.2 that IANA does not
need to administer C-types underneath GENERALIZED_UNI.
- They also ask for 3 new C-types in the SESSION class (Class
Number 1). They ask for this in sect 12.3.
This is under control/guidance of RFC2205 I think. But
unfortunately, RFC2205 does not have an IANA considerations
section. Appendix A seems to suggest they can just be added.
I also see that various other RFCs have claimed allocations
here (RFC2207, 3209, 3175)... so it seems it is OK to
assign the requested values.
- Then, in sect 12.4 they ask for 4 new error-code values.
These are value sub-codes within an existing error-code
(namely within error code 24 as defined by RFC3209)
RFC3209 does assign a initial set of sub-codes but as far
as I can tell it is silent on how to decide if new values
can be assigned. So... since RSVP expert and IESG approved,
I think this is OK.
The suggested values I think are just the next set of
values after those asked by the bala document below.
draft-bala-uni-ldp-rsvp-extensions-01.txt
- This document asks for a single new Class Name and Class
number (sect 4.2) namely GENERALIZED_UNI although they use
mixed case, while a class name must be all uppercase.
This is in the FCFS space, so I think it is OK to assign.
- This doc also states (in sect 4.2) that IANA does not need to
administer the C-types withing GENERALIZED_UNI. So it is kind
of strange that Zhi Lin is asking IANA to make assignments
within this space underneath GENERALIZED_UNI.
But I do wonder if it is wise that IANA lists this new
GENERALIZED_UNI code point without at least pointing to the
authority that then does administer sub-assugnments.
- The doc also asks (sect 4.2) for a C-type under the SESSION
(class-num 1) class.
This is under control/guidance of RFC2205 I think. But
unfortunately, RFC2205 does not have an IANA considerations
section. Appendix A seems to suggest they can just be added.
I also see that various other RFCs have claimed allocations
here (RFC2207, 3209, 3175)... so it seems it is OK to
assign the requested values.
- Then, in sect 4.2 they ask for 5 new error-code values.
These are value sub-codes within an two existing error-codes
(namely within error code 24 as defined by RFC3209, and
within error-code 2 as defined by RFC2205)
RFC3209 does assign a initial set of sub-codes but as far
as I can tell it is silent on how to decide if new values
can be assigned. So... I think this is OK.
RFC2205 says about error code 2:
Contents of the Error Value field are to be determined
in the future.
which seems to say it is OK to assugn values.
If the requested/suggested values make sense I do not know,
I guess the RSVP-Expert should tell us, but I I would not
be surprised if OIF members have probably already
implemented the suggested codes.
This reveals to me that the error codes and values from
RFC2205 seem to not be included in the online IANA registry
at http://www.iana.org/assignments/rsvp-parameters
- This doc also has requests for LDP assignments, I will
do that in another email.
draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
- This document is about CR-LDP only, I will do those in
another email.
Bert