- Adaptation Type Name Space [4.1]
- Model Type Name Space [8.1]
- Port Type Name Space [8.2]
- Service ID Name Space [10.4]
- Traffic Control Name Space [8.4]
- Event Flag Name Space [6.1]
B.1. Message Type Name Space
GSMPv3 divides the name space for Message Types into four ranges.
The following are the guidelines for managing these ranges.
- Message Types 0-99.
Message Types in this range are part of the GSMPv3 base
protocol. Message types in this range are allocated
through an IETF consensus action [19].
- Message Types 100-199.
Message Types in this range are Specification Required
[19]. Message Types using this range must be documented
in an RFCor other permanent and readily available
references.
- Message Types 200-249.
Message Types in this range are Specification Required
[19] and are intended for Abstract and Resource Model
Extension Messages. Message Types using this range must
be documented in an RFCor other permanent and readily
available references.
- Message Types 250-255.
Message Types in this range are reserved for vendor
private extensions and are the responsibility of
individual vendors. IANA management of this range of the
Message Type Name Space is unnecessary.
B.2. Label Type Name Space
GSMPv3 divides the name space for Label Types into three ranges. The
following are the guidelines for managing these ranges.
- Label Types 0x000-0xAFF.
Label Types in this range are part of the GSMPv3 base
protocol. Label Types in this range are allocated through
an IETF consensus action [19].
- Label Types 0xB00-0xEFF.
Label Types in this range are Specification Required [19].
Label Types using this range must be documented in an RFC
or other permanent and readily available reference.
- Label Types 0xF00-0xFFF.
Label Types in this range are reserved for vendor private
extensions and are the responsibility of individual
vendors. IANA management of this range of the Label Type
Name Space is unnecessary.
B.3. Result Name Space
The following is the guideline for managing the Result Name Space:
- Result values 0-255.
Result values in this range need an expert review, i.e.,
approval by a Designated Expert is required [19].
B.4. Failure Response Name Space
GSMPv3 divides the name space for Failure Responses into three
ranges. The following are the guidelines for managing these ranges:
- Failure Responses 0-59, 80-127, 160-255.
Failure responses in these ranges are part of the GSMPv3
base protocol. Failure Responses in these ranges are
allocated through an IETF consensus action [19].
- Failure Responses 60-79, 128-159.
Failure responses in these ranges are reserved for vendor
private extensions and are the responsibility of
individual vendors. IANA management of these ranges of
the Failure Response Name Space are unnecessary.
B.5. Adaptation Type Name Space
GSMPv3 divides the name space for Adaptation Types into two ranges.
The following are the guidelines for managing these ranges:
- Adaptation Type 0x000-0x2FF.
Adaptation Types in this range are part of the GSMPv3 base
protocol. Adaptation Types in this range are allocated
through an IETF consensus action [19].
- Adaptation Type 0x300-0xFFF.
Adaptation Types in this range are allocated by the first
come first served principle [19].
B.6. Model Type Name Space
GSMPv3 divides the name space for Model Types into three ranges. The
following are the guidelines for managing these ranges:
- Model Type 0.
Model Types in this range are part of the GSMPv3 base
protocol. Model Types in this range are allocated through
an IETF consensus action [19].
- Model Type 1-200.
Model Types in this range are Specification Required [19].
Message Types using this range must be documented in an
RFCor other permanent and readily available references.
- Model Type 201-255.
Model Types in this range are reserved for vendor private
extensions and are the responsibility of individual
vendors. IANA management of these ranges of the Model
Type Name Space are unnecessary.
B.7. Port Type Name Space
GSMPv3 divides the name space for Port Types into two ranges. The
following are the guidelines for managing these ranges:
- Port Type 0-127.
Port Types in this range are part of the GSMPv3 base
protocol. Port Types in this range are allocated through
an IETF consensus action [19].
- Port Type 128-255.
Port Types in this range are Specification Required [19].
Port Types using this range must be documented in an RFC
or other permanent and readily available references.
B.8. Service ID Name Space
GSMPv3 divides the name space for Service IDs into two ranges. The
following are the guidelines for managing these ranges:
- Service ID 0-1023.
Service ID's in this range are part of the GSMPv3 base
protocol. Service ID's in this range are allocated
through an IETF consensus action [19].
- Service ID 1024-65535.
Service ID's in this range are Specification Required
[19]. Service ID's using this range must be documented in
an RFCor other permanent and readily available
references.
B.9. Traffic Control Name Space
The following are the guidelines for managing Traffic Control Flags
in GSMPv3:
- All Traffic Control Flags are allocated through an expert
review, i.e., approval by a Designated Expert [19].
B.10. Event Flag Name Space
The following are the guidelines for managing Event Flags in GSMPv3:
- All Event Flags are allocated through an expert review, i.e.,
approval by a Designated Expert [19].
The TCP port for establishing GSMP connections has been defined as
6068.
References
[1] "B-ISDN ATM Layer Specification", International
Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999.
[2] "B-ISDN ATM Adaptation Layer (AAL) Specification", International
Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[3] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",
International Telecommunication Union, ITU-T, Recommendation
I.363.5, Aug. 1996.
[4] Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of
Managed Objects for the General Switch Management Protocol
(GSMP)", RFC3295, June 2002.
[5] IANA Assigned Port Numbers, http://www.iana.org
[6] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F.,
Lyon, T. and G. Minshall, "Ipsilon's General Switch Management
Protocol Specification Version 1.1", RFC1987, August 1996.
[7] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw,
F., Lyon, T. and G. Minshall, "Ipsilon's General Switch
Management Protocol Specification Version 2.0", RFC2297, March
1998.
[8] ATM Forum Technical Committee, "Traffic Management Specification
Version 4.1", af-tm-0121.000, 1999.
[9] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC2211, September 1997.
[10] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-
Based LSP Setup using LDP", RFC3212, January 2002.
[11] ITU-T Recommendation I.233 Frame Mode Bearer Services, ISDN
frame relaying bearer services and ISDN switching bearer
service, Nov. 1991.
[12] ITU-T Recommendation Q.933, Integrated Services Digital Network
(ISDN) Digital Subscriber Signaling System No. 1 (DSS 1)
Signaling Specifications For Frame Mode Switched And Permanent
Virtual Connection Control And Status Monitoring, 1995.
[13] ITU-T Recommendation Q.922, Integrated Services Digital Network
(ISDN) Data Link Layer Specification For Frame Mode Bearer
Services, 1992
[14] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC3032,
January 2001.
[15] Worster, T., Doria, A. and J. Buerkle, "General Switch
Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Transmission
Control Protocol (TCP)", RFC3293, June 2002.
[16] Doria, A. and K. Sundell, "General Switch Management Protocol
Applicability", RFC3294, June 2002.
[17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001.
[18] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC3036, January 2001.
[19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[21] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on
Frame Relay Networks Specification", RFC3034, January 2001.
Authors' Addresses
Avri Doria
Div. of Computer Communications
Lulea University of Technology
S-971 87 Lulea
Sweden
Phone: +1 401 663 5024
EMail: avri@acm.org
Fiffi Hellstrand
Nortel Networks AB
S:t Eriksgatan 115 A
SE-113 85 Stockholm Sweden
EMail: fiffi@nortelnetworks.com
Kenneth Sundell
Nortel Networks AB
S:t Eriksgatan 115 A
SE-113 85 Stockholm Sweden
EMail: ksundell@nortelnetworks.com
Tom Worster
Phone: +1 617 247 2624
EMail: fsb@thefsb.org
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.