draft-ietf-tsvwg-rsvp-user-error-spec-06.txt   draft-ietf-tsvwg-rsvp-user-error-spec-07.txt 
Network Working Group G. Swallow Network Working Group G. Swallow
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Category: Standards Track Category: Standards Track
Created: April 5, 2008 A. Farrel Created: April 28, 2008 A. Farrel
Expiration Date: October 5, 2008 Old Dog Consulting Expiration Date: October 28, 2008 Old Dog Consulting
User-Defined Errors for RSVP User-Defined Errors for RSVP
draft-ietf-tsvwg-rsvp-user-error-spec-06.txt draft-ietf-tsvwg-rsvp-user-error-spec-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 9 skipping to change at page 2, line 9
defining new error codes. Further, no provision for user-defined defining new error codes. Further, no provision for user-defined
errors exists in RSVP. errors exists in RSVP.
This document defines a USER_ERROR_SPEC to be used in addition to the This document defines a USER_ERROR_SPEC to be used in addition to the
ERROR_SPEC to carry additional user information related to errors. ERROR_SPEC to carry additional user information related to errors.
0. Changes Since Last Revision 0. Changes Since Last Revision
[This section to be removed before publication as an RFC.] [This section to be removed before publication as an RFC.]
- Add names to acknowledgments. - Clarify 'Enterprise Number'.
- Clarify that the Error Description String does not contain - Clarify 'Error Description' and give reference for ASCII.
information critical to network operation.
- Define an Error Value of zero to accompany the Error Code of
"User Error Spec".
1. Introduction 1. Introduction
The Resource ReserVation Protocol (RSVP) [RFC2205] defines an The Resource ReserVation Protocol (RSVP) [RFC2205] defines an
ERROR_SPEC object for communicating errors. That object has a ERROR_SPEC object for communicating errors. That object has a
defined format that permits the definition of 256 error codes. As defined format that permits the definition of 256 error codes. As
RSVP has been developed and extended, the convention has been to be RSVP has been developed and extended, the convention has been to be
conservative in communicating errors. Further no provision for user conservative in communicating errors. Further no provision for user
defined errors exists in RSVP. defined errors exists in RSVP.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
~ Error Description ~ ~ Error Description ~
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
~ User-Defined Subobjects ~ ~ User-Defined Subobjects ~
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Enterprise Number Enterprise Number
A unique identifier of an organization encoded as a 32-bit A unique identifier of an organization encoded as a 32-bit
integer. Enterprise Numbers are assigned by IANA and managed integer. Enterprise Numbers (sometimes known as Private
through an IANA registry [RFC2578]. Enterprise Numbers) are assigned by IANA and managed on a first
come first served basis through the IANA registry named
"Enterprise Numbers" [RFC2578].
Sub Org Sub Org
A unique identifier of an organization encoded as an 8-bit A unique identifier of an organization encoded as an 8-bit
integer. An organization MAY use this field to create integer. An organization MAY use this field to create
independent Error Value spaces. This is intended to independent Error Value spaces. This is intended to
facilitate teams which are doing parallel development. If facilitate teams which are doing parallel development. If
independent spaces are not required, this field SHOULD be independent spaces are not required, this field SHOULD be
set to zero. set to zero.
skipping to change at page 4, line 33 skipping to change at page 4, line 35
no error description is supplied. no error description is supplied.
User Error Value User Error Value
A 16-bit integer. The meaning is specified by the A 16-bit integer. The meaning is specified by the
(sub-)organization indicated by the Enterprise Number and Sub (sub-)organization indicated by the Enterprise Number and Sub
Org fields. Org fields.
Error Description Error Description
A string of characters in US-ASCII padded with nulls (0x00) A string of characters in US-ASCII [ASCII] padded with nulls
to a multiple of 4 bytes. If the Err Desc Len is zero then (0x00) to a multiple of 4 bytes. If the Err Desc Len is zero
no bytes are supplied. then no bytes are supplied.
Note that the content of this field might not be shown to all Note that the content of this field is implementation-specific.
users in all implementations (because it is limited to It is typically printable, but might not be shown to all users
US-ASCII). Therefore, it SHOULD be limited to supplementary in all implementations (because it is limited to US-ASCII).
information and SHOULD NOT contain information critical to Therefore, the content of the field SHOULD be limited to
operating the network. Criticial information is present in the supplementary information and SHOULD NOT contain information
User Error Value field. critical to operating the network. Criticial information is
present in the User Error Value field.
User-Defined Subobjects User-Defined Subobjects
User-defined subobjects MAY be included. The generic format of User-defined subobjects MAY be included. The generic format of
subobjects is specified in Section 3.1. The semantics of a subobjects is specified in Section 3.1. The semantics of a
subobject is indicated by the Type field, but the semantics, subobject is indicated by the Type field, but the semantics,
format and contents of the Value field are specified by the format and contents of the Value field are specified by the
(sub-)organization indicated by the Enterprise Number and (sub-)organization indicated by the Enterprise Number and
Sub Org fields of this object. Sub Org fields of this object.
skipping to change at page 5, line 33 skipping to change at page 5, line 35
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4. least 4, and MUST be a multiple of 4.
4. Procedures for Using the User Error Spec 4. Procedures for Using the User Error Spec
4.1. Procedures for Sending the User Error Spec 4.1. Procedures for Sending the User Error Spec
A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or
Notify message for any defined error code. The Enterprise Number Notify message for any defined error code. The Enterprise Number
MUST be a valid value assigned by IANA. MUST be a valid value assigned by IANA from the "Enterprise Numbers"
registry.
As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a
valid error code MUST be included in all PathErr, ResvErr, and Notify valid error code MUST be included in all PathErr, ResvErr, and Notify
messages. This rule is not changed by these procedures even when a messages. This rule is not changed by these procedures even when a
USER_ERROR_SPEC object is included. If no other error code applies, USER_ERROR_SPEC object is included. If no other error code applies,
the Error Code in the ERROR_SPEC object MUST be set to "User Error the Error Code in the ERROR_SPEC object MUST be set to "User Error
Spec" as defined in Section 2 of this document. When the Error Code Spec" as defined in Section 2 of this document. When the Error Code
in the ERROR_SPEC object is set to "User Error Spec", the Error Value in the ERROR_SPEC object is set to "User Error Spec", the Error Value
sub-code SHOULD be set to "Further details in User Error Spec" as sub-code SHOULD be set to "Further details in User Error Spec" as
defined in Section 2, but further Error Value sub-codes may be defined in Section 2, but further Error Value sub-codes may be
skipping to change at page 7, line 19 skipping to change at page 7, line 19
number of error messages sent in cases where messages were previously number of error messages sent in cases where messages were previously
silently dropped due to the lack of an appropriate error code. silently dropped due to the lack of an appropriate error code.
The mechanisms defined in this document may be used by The mechanisms defined in this document may be used by
implementations to report additional error conditions and information implementations to report additional error conditions and information
arising from security issues and attacks on the RSVP network. arising from security issues and attacks on the RSVP network.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Elisheva Halevy for motivating this The authors would like to thank Elisheva Halevy for motivating this
document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig,
Tschofenig, Bruce Davie, Jukka Manner, Francois Le Faucheur, and Lars Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom
Eggert for their review and comments. Petch for their review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[ASCII] American National Standards Institute, "USA Code for
Information Interchange", ANSI X3.4, 1968.
8.1. Informative References 8.1. Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
9. Authors' Addresses 9. Authors' Addresses
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 9 change blocks. 
23 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/