The following text is a proposed set of allocation policies for IANA to apply to
the registries required for GIMPS. (Note that this is just the text for the
GIMPS specification. The technical criteria which go with the policies is/will
described for NSIS as a whole in a separate extensibility document.)
9. IANA Considerations
This section defines the registries and initial codepoint assignments
for GIMPS. It also defines the procedural requirements to be
followed by IANA in allocating new codepoints. Guidelines on the
technical criteria to be followed in evaluating requests for new
codepoint assignments are given for the overall NSIS protocol suite
in a separate NSIS extensibility document [34].
This specification allocates the following codepoints in existing
registries:
Well-known UDP port XXX as the destination port for Query-
encapsulated GIMPS messages (Section 5.3).
This specification creates the following registries with the
structures as defined below:
NSLP Identifiers: Each signaling application requires the assignment
of one of more NSLPIDs. Each NSLPID MUST be associated with a
specific RAO value (multiple NSLPIDs may be associated with the
same RAO value). The following special value is allocated by this
specification:
+--------+----------------------------------------------------------+
| NSLPID | Application |
+--------+----------------------------------------------------------+
| 0 | Used for GIMPS messages not related to any signalling |
| | application. |
+--------+----------------------------------------------------------+
The NSLPID is a 16 bit integer, and allocation policies for
further values are as follows:
1-32703: IESG Approval
32704-32767: Private/Experimental Use
32768-65536: Reserved
GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a
1 byte message type field. The following values are allocated by
this specification:
+--------+----------------------------------------------------------+
| MType | Message |
+--------+----------------------------------------------------------+
| 0 | Query |
| | |
| 1 | Response |
| | |
| 2 | Confirm |
| | |
| 3 | Data |
| | |
| 4 | Error |
| | |
| 5 | MAHello |
+--------+----------------------------------------------------------+
Allocation policies for further values are as follows:
6-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved
Object Types: There is a 12-bit field in the object header
(Appendix C.3.1). The following values for object type are
defined by this specification:
+--------+----------------------------------------------------------+
| OType | Object Type |
+--------+----------------------------------------------------------+
| 0 | Message Routing Information |
| | |
| 1 | Session ID |
| | |
| 2 | Network Layer Information |
| | |
| 3 | Stack Proposal |
| | |
| 4 | Stack Configuration Data |
| | |
| 5 | Query Cookie |
| | |
| 6 | Responder Cookie |
| | |
| 7 | NAT Traversal |
| | |
| 8 | NSLP Data |
| | |
| 9 | Error |
+--------+----------------------------------------------------------+
Allocation policies for further values are as follows:
10-1023: Standards Action
1024-1999: Specification Required
2000-2047: Private/Experimental Use
2048-4095: Reserved
When a new object type is defined, the extensibility bits (A/B,
see Appendix C.3.2) must also be defined.
Message Routing Methods: GIMPS allows the idea of multiple message
routing methods (see Section 3.3). The message routing method is
indicated in the leading byte of the MRI object (Appendix C.4.1).
This specification defines the following values:
+--------+----------------------------------------------------------+
| MRM | Message Routing Method |
+--------+----------------------------------------------------------+
| 0 | Path Coupled MRM |
| | |
| 1 | Loose End MRM |
+--------+----------------------------------------------------------+
Allocation policies for further values are as follows:
2-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved
When a new MRM is defined, the information described in
Section 3.3 must be provided.
MA-Protocol-IDs: Each upper layer protocol that can be used in a
messaging association is identified by a 1-byte MA-Protocol-ID
(Section 5.7). This is used as a tag in the Stack-Proposal and
Stack-Configuration-Data objects (Appendix C.4.4 and
Appendix C.4.5). The following values are defined by this
specification:
+---------------------+---------------------------------------------+
| MA-Protocol-ID | Higher Layer Protocol |
+---------------------+---------------------------------------------+
| 1 | TCP opened in the forwards direction |
| | |
| 2 | TLS |
+---------------------+---------------------------------------------+
Allocation policies for further values are as follows:
3-63: Standards Action
64-119: Expert Review
120-127: Private/Experimental Use
128-255: Reserved
Allocating a new MA-Protocol-ID requires defining the higher layer
addressing information (if any) in the Stack-Configuration-Data
object that is needed to define its configuration. Note that the
MA-Protocol-ID is not an IP Protocol number (indeed, some of the
possible messaging association protocols - such as TLS - do not
have an IP Protocol number).
Error Classes: There is a 1 byte field at the start of the Value
field of the Error object (Appendix C.5.1). Five values for this
field are defined by this specification:
+--------------+----------------------------------------------------+
| Error Class | Significance |
+--------------+----------------------------------------------------+
| 0 | Informational |
| | |
| 1 | Success |
| | |
| 2 | Protocol Error |
| | |
| 3 | Transient Failure |
| | |
| 4 | Permanent Failure |
+--------------+----------------------------------------------------+
Additional values are reserved.
Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode
in the Value field of the Error object (Appendix C.5.1). Error
codes 0-12 are defined in Appendix C.5.4 together with subcodes
0-2 for code 9 and subcodes 0-5 for code 10. Additional codes and
subcodes are allocated on a first-come, first served basis. When
a new error code is allocated, the Error Class and the format of
any associated error-specific information must also be defined. |
