1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc4859.txt b/doc/rfc/rfc4859.txt
new file mode 100644
index 0000000..a3577c5
--- /dev/null
+++ b/doc/rfc/rfc4859.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          A. Farrel
+Request for Comments: 4859                            Old Dog Consulting
+Category: Informational                                       April 2007
+
+
+               Codepoint Registry for the Flags Field in
+    the Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
+                        Session Attribute Object
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document provides instructions to IANA for the creation of a new
+   codepoint registry for the flags field in the Session Attribute
+   object of the Resource Reservation Protocol Traffic Engineering
+   (RSVP-TE) signaling messages used in Multiprotocol Label Switching
+   (MPLS) and Generalized MPLS (GMPLS) signaling.
+
+1.  Introduction
+
+   The Resource Reservation Protocol (RSVP) [RFC2205] has been extended
+   as RSVP for Traffic Engineering (RSVP-TE) for use in Multiprotocol
+   Label Switching (MPLS) signaling [RFC3209] and Generalized MPLS
+   (GMPLS) [RFC3473].
+
+   [RFC3209] introduced a new signaling object, the Session Attribute
+   object, that is carried on the RSVP Path message.  The Session
+   Attribute object contains an eight-bit field of flags.
+
+   The original specification of RSVP-TE assigned uses to three of these
+   bit flags.  Subsequent MPLS and GMPLS RFCs have assigned further
+   flags.
+
+   There is a need for a codepoint registry to track the use of the bit
+   flags in this field, to ensure that bits are not assigned more than
+   once, and to define the procedures by which such bits may be
+   assigned.
+
+
+
+
+
+Farrel                       Informational                      [Page 1]
+
+RFC 4859           Registry for RSVP-TE Session Flags         April 2007
+
+
+   This document lists the current bit usage and provides information
+   for IANA to create a new registry.  This document does not define the
+   uses of specific bits -- definitive procedures for the use of the
+   bits can be found in the referenced RFCs.
+
+2.  Existing Usage
+
+2.1.  RFC 3209
+
+   [RFC3209] defines the use of three bits as follows:
+
+   0x01  Local protection desired
+
+   0x02  Label recording desired
+
+   0x04  SE Style desired
+
+2.2.  RFC 4090
+
+   [RFC4090] defines the use of two bits as follows:
+
+   0x08  Bandwidth protection desired
+
+   0x10  Node protection desired
+
+2.3.  RFC 4736
+
+   [RFC4736] defines the use of one bit as follows:
+
+   0x20  Path re-evaluation request
+
+3.  Security Considerations
+
+   This informational document exists purely to create an IANA registry.
+   Such registries help to protect the IETF process against denial-of-
+   service attacks.
+
+   Otherwise there are no security considerations for this document.
+
+4.  IANA Considerations
+
+   IANA has created a new codepoint registry as follows.
+
+   The new registry has been placed under the "RSVP-TE Parameters"
+   branch of the tree.
+
+   The new registry has been termed "Session Attribute Object Flags."
+
+
+
+
+Farrel                       Informational                      [Page 2]
+
+RFC 4859           Registry for RSVP-TE Session Flags         April 2007
+
+
+   Flags from this registry may only be assigned by IETF consensus
+   [RFC2434].
+
+   The registry references the flags already defined as described in
+   Section 2 of this document.
+
+5.  Acknowledgements
+
+   Thanks to JP Vasseur, Bill Fenner, and Thomas Narten for reviewing
+   this document.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2205]   Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
+               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
+               1, Functional Specification", RFC 2205, September 1997.
+
+   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
+               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+               Tunnels", RFC 3209, December 2001.
+
+   [RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling - Resource ReserVation
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+6.2.  Informative References
+
+   [RFC4090]   Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+               Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+               May 2005.
+
+   [RFC4736]   Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
+               "Reoptimization of Multiprotocol Label Switching (MPLS)
+               Traffic Engineering (TE) Loosely Routed Label Switched
+               Path (LSP)", RFC 4736, November 2006.
+
+
+
+
+
+
+
+
+
+Farrel                       Informational                      [Page 3]
+
+RFC 4859           Registry for RSVP-TE Session Flags         April 2007
+
+
+Author's Address
+
+   Adrian Farrel
+   Old Dog Consulting
+
+   EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel                       Informational                      [Page 4]
+
+RFC 4859           Registry for RSVP-TE Session Flags         April 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Farrel                       Informational                      [Page 5]
+