rfc3006.txt

RFC 的详细文档！

   [RFC 2509].  The low order 16 bits are a sub-option for the cases
   where the IP-compression-protocol number alone is not sufficient for
   int-serv purposes.  The following hint values are required at the
   time of writing:

      -  hint = 0x002d0000: IP/TCP data that may be compressed according
         to [RFC 1144]

      -  hint = 0x00610000: IP data that may be compressed according to
         [RFC 2507]

      -  hint = 0x00610100:  IP/UDP/RTP data that may be compressed
         according to [RFC 2508]




Davie, et al.               Standards Track                     [Page 9]

RFC 3006       Integrated Services in Compressible Flows   November 2000


5. Backward Compatibility

   It is desirable that an intserv router which receives this new TSpec
   format and does not understand the compressibility hint should
   silently ignore the hint rather than rejecting the entire TSpec (or
   the message containing it) as malformed.  While [RFC 2210] clearly
   specifies the format of TSpecs in a way that they can be parsed even
   when they contain unknown parameters, it does not specify what action
   should be taken when unknown objects are received.  Thus it is quite
   possible that some RSVP implementations will discard PATH messages
   containing a TSpec with the compressibility hint.  In such a case,
   the router should send a PathErr message to the sending host.  The
   message should indicate a malformed TSpec (Error code 21, Sub-code
   04).  The host may conclude that the hint caused the problem and send
   a new PATH without the hint.

   For the purposes of this specification, it would be preferable if
   unknown TSpec parameters could be silently ignored.  In the case
   where a parameter is silently ignored, the node should behave as if
   that parameter were not present, but leave the unknown parameter
   intact in the object that it forwards.  This should be the default
   for unknown parameters of the type described in [RFC 2210].

   It is possible that some future modifications to [RFC 2210] will
   require unknown parameter types to cause an error response.  This
   situation is analogous to RSVP's handling of unknown objects, which
   allows for three different response to an unknown object, based on
   the highest two bits of the Class-Num.  One way to handle this would
   be to divide the parameter space further than already done in [RFC
   2216].  For example, parameter numbers of the form x1xxxxxx could be
   silently ignored if unrecognized, while parameter numbers of the form
   x0xxxxxx could cause an error response if unrecognized.  (The meaning
   of the highest order bit is already fixed by [RFC 2216].)  A third
   possibility exists, which is to remove the unrecognized parameter
   before forwarding, but this does not seem to be useful.

6. Security Considerations

   The extensions defined in this document pose essentially the same
   security risks as those of [RFC 2210].  The risk that a sender will
   falsely declare his data to be compressible is equivalent to the
   sender providing an insufficiently large TSpec and is dealt with in
   the same way.








Davie, et al.               Standards Track                    [Page 10]

RFC 3006       Integrated Services in Compressible Flows   November 2000


7. IANA Considerations

   This specification relies on IANA-assigned numbers for the
   compression scheme hint.  Where possible the existing numbering
   scheme for compression algorithm identification in PPP has been used,
   but it may in the future be necessary for IANA to assign hint numbers
   purely for the purposes of int-serv.

8. Acknowledgments

   Carsten Borman and Mike DiBiasio provided much helpful feedback on
   this document.

9. References

   [RFC 1144]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
               Serial Links", RFC 1144, February 1990.

   [RFC 1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
               (IPCP)", RFC 1332, May 1992.

   [RFC 2205]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
               Functional Specification", RFC 2205, September 1997.

   [RFC 2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
               Services", RFC 2210, September 1997.

   [RFC 2211]  Wroclawski, J., "Specification of the Controlled-Load
               Network Element Service", RFC 2211, September 1997.

   [RFC 2212]  Shenker, S., Partridge, C. and R. Guerin, "Specification
               of Guaranteed Quality of Service", RFC 2212, September
               1997.

   [RFC 2216]  Shenker, S. and J. Wroclawski, "Network Element Service
               Specification Template", RFC 2216, September 1997.

   [RFC 2507]  Degermark, M., Nordgren, B. and S. Pink,"Header
               Compression for IP", RFC 2507, February 1999.

   [RFC 2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
               Headers for Low-Speed Serial Links", RFC 2508, February
               1999.

   [RFC 2509]  Engan, M., Casner, S. and C. Bormann, "IP Header
               Compression over PPP", RFC 2509, February 1999.




Davie, et al.               Standards Track                    [Page 11]

RFC 3006       Integrated Services in Compressible Flows   November 2000


10. Authors' Addresses

   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Carol Iturralde
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Dave Oran
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   EMail: [e-mail]


   Stephen L. Casner
   Packet Design
   66 Willow Place
   Menlo Park, CA 94025

   EMail: [e-mail]


   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

   EMail: [e-mail]











Davie, et al.               Standards Track                    [Page 12]

RFC 3006       Integrated Services in Compressible Flows   November 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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 RFC Editor function is currently provided by the
   Internet Society.



















Davie, et al.               Standards Track                    [Page 13]