draft-dreibholz-ipv4-flowlabel-06.txt

IPv6协议中flow_label的相关RFC

   o  No Multi-Flow Connections: To use layered transmission, e.g. a
      video via UDP, the transmission of every layer would require own
      port numbers.  In the case of connection-oriented transmission
      protocols (e.g.  TCP, SCTP), every layer would even require its
      own connection setup and management.  Depending on the transport
      protocol, the number of communication associations and the number
      of flows, much more work is necessary compared to IPv6 using flow
      labels.

   All in all, using IntServ flows with IPv4 requires much more work
   compared to IPv6, where simply the flow label can be used.  It is
   therefore useful to add such a field to IPv4, too.  An appropriate
   place to add such a field is an IPv4 option header.

2.2.  Definition of the Flow Label Option

   IPv4 (see [1]) already defines an option header for a 16-bit SATNET
   stream identifier.  Since this identifier would be incompatible to
   the 20-bit IPv6 flow label, reuse of this existing option header is
   inappropriate.  Therefore, a new one is defined as follows.

   Flow Label Option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0|              Flow Label               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 143

   o  Length: 8 octets

   o  Flow Label: The 20-bit flow label.  All definitions of [3] and
      [10] for the IPv6 flow label are also valid for this field.  A
      value of zero denotes that no flow label is used.  In this case,
      the flow label option is in fact unnecessary.

   The Flow Label option SHOULD be copied on fragmentation.  It MUST be
   the first option of the IP header and therefore MAY NOT appear more
   than once per IPv4 packet.  The Router Alert option SHOULD NOT be
   used to mark the necessity for routers to examine the options.
   Placing the Flow Label option as first option allows for easy
   processing in hardware.





Dreibholz               Expires December 7, 2007                [Page 6]

Internet-Draft          An IPv4 Flowlabel Option               June 2007


3.  Translation between IPv6 and IPv4

   Since the new IPv4 flow label is fully compatible to the IPv6 flow
   label, the field MAY be translated in the other protocol's one during
   protocol translation.  That is, a router can translate an IPv6 packet
   set from an IPv6-only host to an IPv4-mapped address of an IPv4-only
   host and the flow label may simply be copied.  The same may also be
   applied in the backwards direction.

   Note, that copying the flow label during protocol translation is not
   mandatory.  There may be IntServ reservation reasons for not copying
   but setting the flow label to zero.  But a router MAY NOT set the
   flow label to another value than the copy or 0, since the source is
   responsible to ensure that the source address combined with the flow
   label is network-unique




































Dreibholz               Expires December 7, 2007                [Page 7]

Internet-Draft          An IPv4 Flowlabel Option               June 2007


4.  References

4.1.  References

   [1]   Postel, J., "Internet Protocol", STD 5, RFC 791,
         September 1981.

   [2]   Braden, B., Clark, D., and S. Shenker, "Integrated Services in
         the Internet Architecture: an Overview", RFC 1633, June 1994.

   [3]   Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809,
         June 1995.

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

   [5]   Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M.,
         Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation
         Protocol (RSVP) Version 1 Applicability Statement Some
         Guidelines on Deployment", RFC 2208, September 1997.

   [6]   Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
         -- Version 1 Message Processing Rules", RFC 2209,
         September 1997.

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

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

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

   [10]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [11]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

4.2.  Informative References

   [12]  Dreibholz, T., "Management of Layered Variable Bitrate
         Multimedia Streams Over DiffServ with A Priori Knowledge",
         Masters Thesis University of Bonn, Institute for Computer
         Science, February 2001.




Dreibholz               Expires December 7, 2007                [Page 8]

Internet-Draft          An IPv4 Flowlabel Option               June 2007


Author's Address

   Thomas Dreibholz
   University of Duisburg-Essen, Institute for Experimental Mathematics
   Ellernstrasse 29
   45326 Essen, Nordrhein-Westfalen
   Germany

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]
   URI:   http://www.exp-math.uni-essen.de/~dreibh/







































Dreibholz               Expires December 7, 2007                [Page 9]

Internet-Draft          An IPv4 Flowlabel Option               June 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
   [e-mail].


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Dreibholz               Expires December 7, 2007               [Page 10]