draft-ietf-tsvwg-rsvp-user-error-spec-02.txt   draft-ietf-tsvwg-rsvp-user-error-spec-03.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: October 6, 2007 A. Farrel Created: February 14, 2008 A. Farrel
Expiration Date: April 6, 2007 Old Dog Consulting Expiration Date: August 14, 2008 Old Dog Consulting
User-Defined Errors for RSVP User-Defined Errors for RSVP
draft-ietf-tsvwg-rsvp-user-error-spec-02.txt draft-ietf-tsvwg-rsvp-user-error-spec-03.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 5 skipping to change at page 1, line 45
Abstract Abstract
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
for communicating errors. That object has a defined format that for communicating errors. That object has a defined format that
permits the definition of 256 error codes. As RSVP has been permits the definition of 256 error codes. As RSVP has been
developed and extended, the convention has been to be conservative in developed and extended, the convention has been to be conservative in
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
ERROR_SPEC to carry additional user information related to errors.
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Conventions ............................................... 3 1.1 Conventions ............................................... 3
2 User-Defined Error ........................................ 3 2 User-Defined Error ........................................ 3
3 USER_ERROR_SPEC Class ..................................... 4 3 USER_ERROR_SPEC Class ..................................... 4
3.1 Subobjects ................................................ 5 3.1 Subobjects ................................................ 5
4 Procedures for Using the User Error Spec .................. 6 4 Procedures for Using the User Error Spec .................. 6
4.1 Procedures for Sending the User Error Spec ................ 6 4.1 Procedures for Sending the User Error Spec ................ 6
4.2 Procedures for Receiving the User Error Spec .............. 6 4.2 Procedures for Receiving the User Error Spec .............. 6
5 IANA Considerations ....................................... 6 5 IANA Considerations ....................................... 6
6 Security Considerations ................................... 7 6 Security Considerations ................................... 7
7 Acknowledgments ........................................... 7 7 Acknowledgments ........................................... 7
8 Normative References ...................................... 7 8 Normative References ...................................... 7
9 Authors' Addresses ........................................ 8 9 Authors' Addresses ........................................ 8
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.]
- Use explicit tags for values to be supplied by IANA. - Add reference to RFC 2578.
Sections 2, 3 and 5. - Add text to Abstract.
- Section 4.2, para 1. Resolve "SHOULD" to "should" and replace
- Definition of Length field mentioned non-existent L field. "appropriate".
Section 3.1. - Section 4.2, para 2. Replace "SHOULD" with "MUST".
- Section 4.2, para 3. Provide reason for ignoring repeated objects.
- Section 4.2, para 4. Replace "SHOULD" with "MUST".
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 38 skipping to change at page 4, line 38
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
~ 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. integer. Enterprise Numbers are assigned by IANA and managed
through an IANA registry [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 6, line 25 skipping to change at page 6, line 25
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. Spec" as defined in Section 2 of this document.
4.2. Procedures for Receiving the User Error Spec 4.2. Procedures for Receiving the User Error Spec
It is RECOMMENDED that implementations that receive a PathErr, It is RECOMMENDED that implementations that receive a PathErr,
ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a
minimum log the Enterprise Number, Sub-organization, User Error minimum log the Enterprise Number, Sub-organization, User Error
Value, and Error Description. Implementation capable of interpreting Value, and Error Description. Implementations capable of
the contents of the USER_ERROR_SPEC object SHOULD take appropriate interpreting the contents of the USER_ERROR_SPEC object should take
action. further action based on the reported error.
If a message is received containing an ERROR_SPEC object using the If a message is received containing an ERROR_SPEC object using the
"User Error Spec" error code, but not containing a USER_ERROR_SPEC "User Error Spec" error code, but not containing a USER_ERROR_SPEC
object, the message SHOULD be treated as malformed and handled object, the message MUST be treated as malformed and handled
according to [RFC2205]. according to [RFC2205].
Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC
objects, and SHOULD forward them unchanged on any messages that they objects, and SHOULD forward them unchanged on any messages that they
forward. forward. This provides for forward compatiblity.
Implementations receiving a USER_ERROR_SPEC object on some message Implementations receiving a USER_ERROR_SPEC object on some message
other than a PathErr, ResvErr, or Notify message SHOULD treat the other than a PathErr, ResvErr, or Notify message MUST treat the
error as a malformed message and process according to [RFC2205]. error as a malformed message and process according to [RFC2205].
5. IANA Considerations 5. IANA Considerations
This document makes the following assignments from the RSVP Error This document makes the following assignments from the RSVP Error
Codes and Globally-Defined Error Value Sub-Codes registry (pending Codes and Globally-Defined Error Value Sub-Codes registry (pending
IANA action): IANA action):
Value Name Value Name
skipping to change at page 7, line 29 skipping to change at page 7, line 29
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, and Tom Nadeau, and Magnus Westerlund for their review and document. Thanks to Tom Nadeau, Magnus Westerlund, and Hannes
comments. Tschofenig for their review and comments.
8. Normative References 8. 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.
8.1. Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
9. Authors' Addresses 9. Authors' Addresses
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: swallow@cisco.com EMail: swallow@cisco.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Intellectual Property 10. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 14 change blocks. 
20 lines changed or deleted 34 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/